Date   

#linux #zeus #yocto #imx6 #bitbake #make #make #linux #zeus #yocto #imx6

noel.neu@...
 

Hi! 

I would like to implement an out-of-tree  ASoC Machine driver in my project. It #includes some in-tree header files such ../codecs/codecX.h. These are however not found when I try to build the recipe. I have followed the example project "hello-mod", but that doesn't require any in-tree header files, so it doesn't help in this case. 

What do I need to do in oder for Bitbake to find these headers ?
Thanks!


Re: oFono Version 1.31 ofonod crash

JH
 

Hi Sergei,

Thanks for the advice, the latest ofono in oe-core master is 1.32, but
I am in branch Hardknott, so I copied ofono 1.32 from master to my
layer running Hardknott branch, but I could not build ofono 1.32 in
Hardknott:

ERROR: ParseError at
/build/oe-cor/../meta-solar/recipes-connectivity/ofono/ofono_1.32.bb:22:
unparsed line: 'SYSTEMD_SERVICE:${PN} = "ofono.service"'

I used ofono 1.30 and connman 1.37 in Zeus, both worked fine , but
both connman 1.39 and ofono 1.31 failed to work properly in oe-core
Hardknott branch, to narrow down if it is ofono issue or Yocto OE
build or other library issue, I was able to build ofono 1.30 for
Hardknott, I can confirm that ofono 1.30 failed just like the 1.31
stuck at the statement add_serial_device.

................
ofonod[2806]: ../ofono-1.30/plugins/udevng.c:add_serial_device()
Device is missing required OFONO_DRIVER property
ofonod[2806]: ../ofono-1.30/plugins/udevng.c:add_serial_device()
Device is missing required OFONO_DRIVER property
ofonod[2806]: ../ofono-1.30/plugins/udevng.c:add_serial_device()
Device is missing required OFONO_DRIVER property

If I run ofono 1.30 built from Zeus build, the ofonod would pass
missing OFONO_DRIVER property and kept it work:

......
ofonod[3712]: ../ofono-1.30/plugins/udevng.c:add_serial_device()
Device is missing required OFONO_DRIVER property
ofonod[3712]: ../ofono-1.30/plugins/udevng.c:create_modem()
/sys/devices/soc0/soc/2100000.aips-bus/2184200.usb/ci_hdrc.1/usb1/1-1
ofonod[3712]: ../ofono-1.30/plugins/udevng.c:create_modem() driver=ubloxqmi
ofonod[3712]: ../ofono-1.30/src/modem.c:ofono_modem_create() name:
(null), type: ubloxqmi
ofonod[3712]: ../ofono-1.30/plugins/udevng.c:setup_ubloxqmi()
/sys/devices/soc0/soc/2100000.aips-bus/2184200.usb/ci_hdrc.1/usb1/1-1
.....

So I don't think it is an oFono issue, but rather an OE Yocto build or
library issue, can anyone run oFono in oe-core Hardknott branch?

Thank you.

Kind regards,

- jupiter



On 8/22/21, Sergei Golubtsov <s.e.golubtsov@...> wrote:
Hi jupiter,

Please try to update ofono to the latest release. Seems to be a library
incompatibility issue or something like that.

Yours sincerely,
Sergei Golubtsov.


On Sat, Aug 21, 2021 at 4:09 AM Jupiter <jupiter.hce@...> wrote:

Hi,

I build ofono v1.31 from git://git.yoctoproject.org/poky branch
hardknott,

$ cat meta/recipes-connectivity/ofono/ofono_1.31.bb

SUMMARY = "open source telephony"
DESCRIPTION = "oFono is a stack for mobile telephony devices on Linux.
oFono supports speaking to telephony devices through specific drivers,
or with generic AT commands."
HOMEPAGE = "http://www.ofono.org"
BUGTRACKER = "https://01.org/jira/browse/OF"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://COPYING;md5=eb723b61539feef013de476e68b5c50a \


file://src/ofono.h;beginline=1;endline=20;md5=3ce17d5978ef3445def265b98899c2ee"
DEPENDS = "dbus glib-2.0 udev mobile-broadband-provider-info ell"

SRC_URI = "\
${KERNELORG_MIRROR}/linux/network/${BPN}/${BP}.tar.xz \
file://ofono \
file://0001-mbim-add-an-optional-TEMP_FAILURE_RETRY-macro-copy.patch
\
"
SRC_URI[md5sum] = "1c26340e3c6ed132cc812595081bb3dc"
SRC_URI[sha256sum] =
"a15c5d28096c10eb30e47a68b6dc2e7c4a5a99d7f4cfedf0b69624f33d859e9b"

inherit autotools pkgconfig update-rc.d systemd
gobject-introspection-data

INITSCRIPT_NAME = "ofono"
INITSCRIPT_PARAMS = "defaults 22"
SYSTEMD_SERVICE_${PN} = "ofono.service"

PACKAGECONFIG ??= "\
${@bb.utils.filter('DISTRO_FEATURES', 'systemd', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', 'bluez', '', d)}
\
"
PACKAGECONFIG[systemd] =
"--with-systemdunitdir=${systemd_unitdir}/system/,--with-systemdunitdir="
PACKAGECONFIG[bluez] = "--enable-bluetooth, --disable-bluetooth, bluez5"

EXTRA_OECONF += "--enable-test --enable-external-ell"

do_install_append() {
install -d ${D}${sysconfdir}/init.d/
install -m 0755 ${WORKDIR}/ofono ${D}${sysconfdir}/init.d/ofono
}

PACKAGES =+ "${PN}-tests"

FILES_${PN} += "${systemd_unitdir}"
FILES_${PN}-tests = "${libdir}/${BPN}/test"

RDEPENDS_${PN} += "dbus"
RDEPENDS_${PN}-tests = "\
python3-core \
python3-dbus \
${@bb.utils.contains('GI_DATA_ENABLED', 'True',
'python3-pygobject', '', d)} \
"

RRECOMMENDS_${PN} += "kernel-module-tun mobile-broadband-provider-info"

The build was fine, but running the v1.31 ofono.service crashed at
udevng.c missing OFONO_DRIVER property, the ofono.service was repeated
to be restarted every 6 seconds:

.....

ofonod[9005]: ../ofono-1.31/plugins/udevng.c:add_serial_device()
Device is missing required OFONO_DRIVER property
ofonod[9005]: ../ofono-1.31/plugins/udevng.c:add_serial_device()
Device is missing required OFONO_DRIVER property
......

I am not quite sure if it is ofono 1.31 problem or oe-core
ofono_1.31.bb problem, could anyone have a look at and advise? Let me
know if you need more debug information.

Thank you.

Kind regards,

- jupiter


On 8/20/21, Jupiter <jupiter.hce@...> wrote:
Hi,

I upgraded from Zeus to Hardknotte, I was able to run dbus to get
interface properties, but I failed on Hardknotte ofono 1.31. Has
anyone got oFono 1.31 dbus work?

Thank you.

Kind regards,

- jupiter
_______________________________________________
ofono mailing list -- ofono@...
To unsubscribe send an email to ofono-leave@...

--
"A man can fail many times, but he isn't a failure until he begins to
blame somebody else."
-- John Burroughs


[meta-hardening][PATCH] README: fix mailing lists

Marta Rybczynska
 

The address included in the meta-hardening documentation
does not work and was changed in other places in 2019.

Signed-off-by: Marta Rybczynska <rybczynska@...>
---
meta-hardening/README | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta-hardening/README b/meta-hardening/README
index 37a0b7e..191253c 100644
--- a/meta-hardening/README
+++ b/meta-hardening/README
@@ -64,14 +64,14 @@ layers: meta-oe
Maintenance
-----------

-Send pull requests, patches, comments or questions to yocto@...
+Send pull requests, patches, comments or questions to yocto@...

When sending single patches, please using something like:
-'git send-email -1 --to yocto@... --subject-prefix=meta-hardening][PATCH'
+'git send-email -1 --to yocto@... --subject-prefix=meta-hardening][PATCH'

These values can be set as defaults for this repository:

-$ git config sendemail.to yocto@...
+$ git config sendemail.to yocto@...
$ git config format.subjectPrefix meta-hardening][PATCH

Now you can just do 'git send-email origin/master' to send all local patches.
--
2.30.2


[meta-hardening][PATCH] meta-hardening/binutils: harden installation permissions

Marta Rybczynska
 

Compilers and related utils are better restricted on production platforms.
Change permissions of all installed binutils tools to remove access from
users outside of the root group.

This also demonstrates how to restrict file permissions in a hardened
distribution.

Signed-off-by: Marta Rybczynska <marta.rybczynska@...>
---
meta-hardening/recipes-devtools/binutils/binutils_%.bbappend | 3 +++
1 file changed, 3 insertions(+)
create mode 100644 meta-hardening/recipes-devtools/binutils/binutils_%.bbappend

diff --git a/meta-hardening/recipes-devtools/binutils/binutils_%.bbappend b/meta-hardening/recipes-devtools/binutils/binutils_%.bbappend
new file mode 100644
index 0000000..3eb3ad0
--- /dev/null
+++ b/meta-hardening/recipes-devtools/binutils/binutils_%.bbappend
@@ -0,0 +1,3 @@
+do_install_append_class-target () {
+ chmod o-rx ${D}${prefix}/${TARGET_SYS}/bin/*
+}
--
2.30.2


Yocto error while bitbaking a recipe

yasminebenghozzi6@...
 

Hello, 
SO I'm working on a new recipe, while bitbaking it , this happened, and I really don't know what it's about, 

ERROR: Setscene task /home/yasmine/yocto/poky/meta/recipes-core/packagegroups/packagegroup-core-buildessential.bb:do_package in both covered and notcovered.

I'l appreciate your help
 


[meta-mingw] [PATCH] grpc: use the new PACKAGECONFIG to disable shared

Sinan Kaya <okaya@...>
 

There is a new PACKAGECONFIG for grpc to allows us
to selectively enable/disable shared builds.

Signed-off-by: Sinan Kaya <okaya@...>
---
.../openembedded-layers/recipes-devtools/grpc/grpc_%.bbappend | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/dynamic-layers/openembedded-layers/recipes-devtools/grpc/grpc_%.bbappend b/dynamic-layers/openembedded-layers/recipes-devtools/grpc/grpc_%.bbappend
index dc0ea42..4cbd1a4 100644
--- a/dynamic-layers/openembedded-layers/recipes-devtools/grpc/grpc_%.bbappend
+++ b/dynamic-layers/openembedded-layers/recipes-devtools/grpc/grpc_%.bbappend
@@ -1,5 +1,4 @@
# doesn't build and not required
DEPENDS:remove:mingw32 = "libnsl2"

-EXTRA_OECMAKE:remove:mingw32 = "-DBUILD_SHARED_LIBS=ON"
-EXTRA_OECMAKE:append:mingw32 = " -DBUILD_SHARED_LIBS=OFF"
+PACKAGECONFIG:remove:mingw32 = "shared"
--
2.17.1


Yocto Project Status WW34`21

Stephen Jolley
 

Current Dev Position: YP 3.4 M3 (Feature Freeze)

Next Deadline: 23rd Aug. 2021 YP 3.4 M3 build (Feature Freeze)

 

Next Team Meetings:

 

Key Status/Updates:

  • We are now at feature freeze for YP 3.4
  • Read-only PRServ and switch to asyncio was merged
  • Rust merging to core is proving problematic due to issues interacting with uninative. These cause many strange autobuilder failures so this issue would have to be addressed in the next day or two in order to be in 3.4.
  • glibc 2.34 and the merge of the various libraries into libc is causing significant problems for pseudo. This issue is causing significant worry as the project will struggle as distros adopt the new glibc version unless we work out how to fix things.
  • The tune file layout change was merged.
  • We are still hoping to get some of the planned SBOM work into 3.4
  • Intermittent issues are ongoing and help is very much welcome on these issues. 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

 

Ways to contribute:

 

YP 3.4 Milestone Dates:

  • YP 3.4 M3 build date 2021/08/23 (Feature Freeze)
  • YP 3.4 M3 Release date 2021/09/03
  • YP 3.4 M4 build date 2021/10/04
  • YP 3.4 M4 Release date 2021/10/29

 

Planned upcoming dot releases:

  • YP 3.1.11 build date 2021/09/13
  • YP 3.1.11 release date 2021/9/24

 

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: Update bitbake broken build

Martin Jansa
 

On Tue, Aug 24, 2021 at 12:33 AM JH <jupiter.hce@...> wrote:
Hi,

I updated the bitbake to run git pull in master branch, now it is
broken, what does the following error message mean, how to fix it?

$ bitbake-layers show-layers

NOTE: Starting bitbake server...
ERROR: Variable PROVIDES_prepend contains an operation using the old
override syntax. Please convert this layer/metadata before attempting
to use with a newer bitbake.

Thank you.

Kind regards,

- jupiter




#yocto #dunfell Console Standard input dirty without "tools-sdk" image feature #yocto #dunfell

ivin.lim@...
 


Using dunfell 3.1.8

Will post this inquiry while doing my own investigation. When outputting to the debug console that involves standard input(ex. busctl, systemctl status), the output seems misaligned and dirty.
But I noticed this can be easily fixed by adding to the "tools-sdk" to the EXTRA_IMAGE_FEATURES. 
I'm curious to know what else tools-sdk seems to besides adding development tools(ex. gcc,make)

Below is the snapshot when tools-sdk isn't included in the image built



M+ & H bugs with Milestone Movements WW34

Stephen Jolley
 

All,

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

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

Medium+

13722

Debugging With the GNU Project Debugger enhancements

randy.macleod@...

john.kaldas.enpj@...

3.4 M2

3.4 M4

 

13903

npmsw fetcher fails if multiple recipes have common npm packages

randy.macleod@...

jeanmarie.lemetayer@...

3.4 M2

3.4 M4

 

13954

Invalid layerindex data causing backtrace in `bitbake-layers layerindex-fetch`

randy.macleod@...

unassigned@...

3.4 M2

3.4 M4

 

14060

devtool modify fails when applied on recipes using patches

randy.macleod@...

saul.wold@...

3.4 M2

3.4 M4

 

14146

Post-patch hook fails with submodules and PATCHTOOL=git and PATCH_COMMIT_FUNCTIONS=1

randy.macleod@...

unassigned@...

3.4 M2

3.99

 

14385

mode of sstate files created under pseudo

randy.macleod@...

mark.hatle@...

3.4 M2

3.4 M4

 

14444

[multilib] lib32-core-image-minimal -c populate_sdk failure on dunfell

randy.macleod@...

steve@...

3.4 M2

3.1.11

 

14449

AB-INT PTEST ARM: quilt patch-wrapper ptest intermittent failure

randy.macleod@...

randy.macleod@...

3.4 M3

3.4 M4

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Enhancements/Bugs closed WW34!

Stephen Jolley
 

All,

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

Who

Count

ross@...

2

fransmeulenbroeks@...

1

alexandre.belloni@...

1

randy.macleod@...

1

jay.shen.teoh@...

1

Grand Total

6

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.4

Stephen Jolley
 

All,

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

Who

Count

michael.opdenacker@...

32

ross@...

31

david.reyna@...

22

richard.purdie@...

21

bruce.ashfield@...

16

randy.macleod@...

13

trevor.gamblin@...

13

timothy.t.orling@...

12

JPEWhacker@...

10

sakib.sajal@...

10

bluelightning@...

7

kai.kang@...

7

tony.tascioglu@...

5

hongxu.jia@...

4

Qi.Chen@...

4

mingli.yu@...

3

chee.yang.lee@...

3

alexandre.belloni@...

2

mshah@...

2

jaewon@...

2

yf3yu@...

2

akuster808@...

2

yi.zhao@...

2

alejandro@...

2

vinay.m.engg@...

1

raj.khem@...

1

pokylinux@...

1

mostthingsweb@...

1

weaverjs@...

1

Martin.Jansa@...

1

yoctoproject@...

1

nicolas.dechesne@...

1

kergoth@...

1

dl9pf@...

1

mark.hatle@...

1

open.source@...

1

paul@...

1

jon.mason@...

1

mister_rs@...

1

ydirson@...

1

john.kaldas.enpj@...

1

naveen.kumar.saini@...

1

devendra.tewari@...

1

jeanmarie.lemetayer@...

1

diego.sueiro@...

1

aehs29@...

1

thomas.perrot@...

1

matthewzmd@...

1

douglas.royds@...

1

saul.wold@...

1

tonyb@...

1

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 386 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@...

 


Update bitbake broken build

JH
 

Hi,

I updated the bitbake to run git pull in master branch, now it is
broken, what does the following error message mean, how to fix it?

$ bitbake-layers show-layers

NOTE: Starting bitbake server...
ERROR: Variable PROVIDES_prepend contains an operation using the old
override syntax. Please convert this layer/metadata before attempting
to use with a newer bitbake.

Thank you.

Kind regards,

- jupiter


Re: Wayland and X11 on Yocto

Manuel Wagesreither
 

Hi all, hi Khem,

Am Do, 19. Aug 2021, um 00:22, schrieb Khem Raj:
On Wed, Aug 18, 2021 at 3:06 PM Manuel Wagesreither <ManWag@...> wrote:

Hello all,

I'm building an image to run on various SBCs and would like to equip it with a graphical interface.

There are quite a few things very unclear to me. Can someone help me with that?

* Why is X11 enabled by setting an IMAGE_FEATURE (namely x11, x11-base or x11-sato), while Wayland is enabled by IMAGE_INSTALL only (weston-init and weston)?
x11-* features is primarily to control what kind of x11 packages you
want to include in image e.g.
./meta/recipes-sato/packagegroups/packagegroup-core-x11-sato.bb is
pulled in when x11-sato is added to IMAGE_FEATURES
we have many X11 based images and sato is one of them so thats why its
separated out.
Okay, so if I get things right then IMAGE_FEATURES+="x11" is under the hood nothing more than an IMAGE_INSTALL+="packagegroup-core-x11". Is that right? If so, what's the purpose of adding the concept of IMAGE_FEATURE? I mean, it doesn't make things SO much easier. Setting an IMAGE_FEATURE or an IMAGE_INSTALL variable is the same to me.

you should really is looking at DISTRO_FEATURES e.g. wayland distro
feature is needed for core-image-weston to build.
Yepp, I know. I left them out on purpose because I was mainly interested in where the configuration for X11 and wayland differs conceptually. With "conceptually" I mean that one is added through IMAGE_FEATURES while the other is through IMAGE_INSTALL.

* Theory: Is IMAGE_FEATURE +=x11 manipulating IMAGE_INSTALL under the hood so you don't have to do it manually? And as there is no IMAGE_FEATURE "wayland", you have do it manually. Correct?
* Why is Wayland different in that it doesn't need an IMAGE_FEATURE to enable it?
there are not many wayland based compositors or images we have in core
as of now.
And if there would be more wayland based compositors or images then you would turn extract this into an IMAGE_FEATURE as well? Why? How does that make things easier? Again, I feel there's something to IMAGE_FEATURES I didn't yet understand.

* Why does core-image-weston.bb need to enable IMAGE_FEATURE hwcodec, while core-image-x11.bb does not? (Dunfell branch.)
openGL is needed for wayland/weston to work too but hwcodec feature is
infact to pull in machine specific drivers MACHINE_HWCODECS into image
if a given BSP defined it.
e.g. intel bsps define vaapi codecs and mediasdk for specific machines
via MACHINE_HWCODECS
defaults for this image features are empty
Thanks for the explanation on MACHINE_HWCODEC. I'm curious, so is core-image-x11 require DISTRO_FEATURE hwcodec or not? If yes, than it seems to be missing in the core-image-x11.bb (it's in the core-images-weston.bb, after all), if no, then why is it not required for X11?


I know I'm asking quite detailed questions, but I got the feeling I need to understand this once and for all.

Thanks, regards, Manuel


Extensible SDK - runtime packages installation

d0ku
 

Hi,

I've been playing with extensible SDK lately and got to a point, where I want to create a minimal SDK installer and install all the required packages in runtime via `devtool sdk-install`, so that every developer can get only the stuff that's actually needed.

For the target part it works as expected, installing the content to ${OECORE_TARGET_SYSROOT}, however for the host part the content gets installed to ${OECORE_NATIVE_SYSROOT}, but it's not visible in the PATH in some cases. E.g. for perl-native the binaries are installed to `<native sysroot>/bin/perl-native` and are not visible, unless I manually extend the PATH with this directory, then it works fine.

So my questions are:
* Is the runtime installation of packages meant to run on host actually supported? It surely works for e.g. compiler, so I assume it should be also fine for other packages?
* Should I install `nativesdk-` or `-native` packages, if I want to use them this way? Or can I actually do both? In the eSDK talk by Paul Eggerton I saw that `nativesdk-cmake` was added, but the `nativesdk-` doesn't really seem to fit `mini Yocto environment` that eSDK basically is.
* Am I possibly missing some configuration steps? In Yocto environment the PATH gets expanded with `bin/perl-native` automatically, but I wasn't able to pinpoint what file/task actually does it.

Best Regards and thanks in advance,
Jakub


Re: meta-gnome error #yocto

Khem Raj
 

On 8/23/21 2:55 AM, yasminebenghozzi6@... wrote:
Hello, please can anyone help with this error ?
ERROR: ParseError at /home/yasmine/yocto/poky/meta-openembedded/meta-gnome/recipes-gnome/yelp/yelp_3.34.0.bb:7: Could not inherit file classes/itstool.bbclass
this is the line 7:
inherit gnomebase itstool autotools-brokensep gsettings gettext gtk-doc features_check mime-xdg
this class is provided by meta-oe layer. Make sure you have meta-oe layer in your bblayers.conf


Yocto Technical Team Minutes, Engineering Sync, for August 17, 2021

Trevor Woerner
 

Yocto Technical Team Minutes, Engineering Sync, for August 17, 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 Richard Purdie Peter Kjellerstedt Joshua
Watt Randy MacLeod Saul Wold Michael Halstead Richard Elberger Scott Murray
Steve Sakoman Tony Toscioglu Trevor Gamblin Bruce Ashfield Ross Burton
Alexandre Belloni Daiane Angolini Jon Mason Jan-Simon Möller

== project status ==
- 3.1.10 (dunfell) released
- 3.4 (honister) is in feature freeze next week (pending work includes rust
and prserv)
- glibc 2.34 update merged. the builds are fine, but causes problems with
uninative and pseudo, fixes being investigated
- kernel: drop 5.4, updates to 5.10 and 5.13
- appears to be issues with buildtools tarball in aarch64 (probably related to
gcc 11 update)
- plan to migrate tune files into architecture-specific directories; patch
likely to merge in the next few days
- bitbake fetcher no longer ignores SSL certificates
- LTO linker flag handling changes merged to help with reproducibility issues
- overlayfs class changes were merged

== discussion ==
Randy: the pending rust work is coming along. fixed ppc issue and fixed
reproducibility issues but still having an issue with diffsigs. Alex did a
full build and it’s looking good. is diffsig issue a requirement?
RP: yes. maybe show it to me and i can take a look. perhaps a status update to
the mailing list

Scott: re: prserv. i was away. i was able to reproduce the hang issues that RP
was seeing on the AB before i left. however, i’m seeing a new issue with
debian 10 and python 3.7 we’re seeing a hang, but it’s not like any
of the other hangs we’ve seen before so still investigating. is feature
freeze the end of this week, or next
RP: technically Monday. but this is a planned feature so there is some
flexibility so we’ll see how the progress goes
Scott: what’s the minimum python?
RP: 3.5 or 3.6?
Ross: 3.5
Scott: we could also lift the read-only feature and put that in for this
release then work on the rest for the next release
RP: well, we need read-only for hashequiv and prserv
Scott: it’s already there for hashequiv. i don’t think it’s a huge need
for this code. but i’ll keep working on it
RP: we could do that as a backup plan, but i’d prefer to see it all go in
for this release. i’m reluctant to do this.
Scott: python 3.9 seems quite happy. the problem seems to be with the older
versions. maybe there’s something we can do with the older versions to
make them happy
JPEW: hash equiv is a lot cleaner, it doesn’t have to do all the forking etc
Scott: i thought i had it working (before i left) but i guess not. i’m
seeing a strange ld.so bug (inconsistency detected by ld.so: dl-open
worker assert dl_debug_initialize()->rstate == RT_CONSISTENT failed). not
sure what this is, not what you’d expect out of a python program. looks
like maybe loading debug symbols? when i attach gdb i don’t see any
obvious problems. the coverage on the AB uses buildtools, what combos on
the AB include the old python?
RP: i think the really older ones all have buildtools tarball, but newer ones
would run native
PeterK: i think the latest python is 3.6 with the fstreams thing
JPEW: i thought it was 3.6 too, i’m pretty sure i was the one who bumped it
RP: i was thinking 3.6 for fstreams too when Ross said 3.5
PeterK: not that it helps you if you want 3.9
RP: but it does help somewhat
Randy: (finds log) January 2021
RP: ah, the core does have the version bump, but it was not done in bitbake
JPEW: i think it was something specific in oe-core that needs 3.6 and if
someone is using bitbake without oe-core then they can still use 3.5

JPEW: is bitbake major version going to bump with overrides
RP: it did
JPEW: i meant bitbake 2.0.0
RP: not yet. i’m tempted for next LTS, but we’ll see. i’m getting tired
of 1.x ;-)
JPEW: let’s use dates

JPEW: re spdx. if you go to poky-contrib there is a branch jpew-sbom which
includes all the stuff i’ve done with spdx and sbom creation. please
take a look and let me know if what we’re creating generates something
that’s useful to you. if you do fossology scanning then please take a
look at the output and let me know if that works for you
Saul: i’m looking at it. do you have any plans about creating a single large
image sbom instead of the relationship based one
JPEW: originally i went down that road, it can be done if we can do it sanely.
however we have to create different parts at different times in the build,
so it’s just easier to have separate docs and then link them later.
so we get 100’s and 100’s of docs, and then put them together in a
tarball.
Saul: townhall is tomorrow, looking forward to it. but i’ll look at scripts
to pull it all in together into one single doc
JPEW: that would actually make the documentation smaller because all the
linking adds quite a bit.
JPEW: also i wanted to leave open the possibility to link to spdx docs from
the source code and pull all that into the big tarball. i think the
lite-spdx group is trying to make things nicer (in this direction) for our
(and others’) usecase, but not involved in that
Saul: sometimes the external references cause issues. i threw some random ones
at the validator and there were some warnings and errors. the tools are
also 1.x version but they don’t properly validate the 2.x stuff.
JPEW: they were validating against the online tools at one point, but i
probably did something to mess it up. it’s annoying that the offline
native tool is java based. it would be nice to validate as part of the
build, but that’s a huge undertaking. there’s also the issue of
identifying the spdx license using the ?? tool
RP: who said to not use that tool?
JPEW: you did
RP: okay. well that’s what i’d use so go ahead
JPEW: also need to verify that the license that we put in the file is a known
and valid spdx license. sometimes the validator tool doesn’t accept it
because of a small issue even though it is the same license
RP: there’s an spdx-legal mailing list where stuff like this is being
discussed. e.g. common licenses for distros.
RP: glancing down your branch, i think we can start adding it
JPEW: i’d like to target the next release. we could merge it now as-is,
it’s functional but not 100% correct
Saul: it’s pretty isolated
JPEW: yes, just one class. if you don’t inherit it, it shouldn’t affect
anything
RP: i’m leaning towards adding it for this release as-is since it is so
isolated because it is important and i’d like to see it get wider use
Scott: townhall presentation meeting by Joshua tomorrow
Saul: free registration, supply-chain discussions, NA timezone
Scott: there are some other talks too that seem interesting (sigstore)
RP: thanks to JPEW for putting in the presentation! sbom and reproducibility
JPEW: sbom, reproducibility, CVE checking, buildtools, etc

RP: re current patch status. lots of version changes in master-next
Scott: yes myself and Jan-Simon noticed it. i’ll poke around in it
Jon: on my todo list today, will review it
Scott: i think the tune one might blow up AGL
RP: it’s in master-next and Alex’s testing branch which i think shows
green for AGL. it’s intel that blows up
AlexB: yes, AGL is fine but Intel blows up.
RP: AlexB make sure Anuj is aware of the meta-intel issue
AlexB: sure
SS: what’s it mean for the removal of the 5.4 linux-yocto recipe for
dunfell?
Bruce: i’ll keep sending them to you. i keep updating 4.19 and other things
that still get updates. i’ll make sure to add “dunfell” in the cover
letter
SS: lots of hand-editing of colons and underscores
RP: i suspect the conversion scripts could be reversed to change colons back
to underscores

RP: glibc 2.3.4 changes caused more issues than i anticipated. AB builds are
green, but 2.3.4 on the host (builtdools tarball extended) or ?? cause
issues. in some cases there are reproducibility issues.
RP: libevent INT-AB monotonic test keeps failing off and on, but fails often
enough to be annoying. will be the next one to come to grips with
AlexB: yes, that one and the bitbake one
RP: i’m pretending that tone doesn’t exist

TrevorW: i want to convert meta-rockchip to use more of the kernel kmeta
config features, what machine do you recommend i follow as a good example
of doing it right?
Bruce: i'll send you something

TrevorW: is there any requirements or objections to adding new IMAGE_FEATUREs?
i’m working on a zram IMAGE_FEATURE and would like to know if there’s
any chance it would be rejected as an IMAGE_FEATURE so i could look at
other approaches
RP: IMAGE_FEATUREs have never been rejected that i know of
TrevorW: they’re added very rarely and there aren’t many of them
RP: they’re infrequent because there aren’t many. just be careful how you
add the packagegroups to make sure you don’t add build dependencies.
TrevorW: my feature will also need to add a kernel config. are there any
examples of a feature that also pokes the kernel config?
Bruce: check nfs ones

Elberger: is there going to be a yocto-checklayer for dunfell?
RP: i think it’s been enabled
Elberger: i’m looking at the yocto console view and it’s not there, am i
looking at the wrong thing
RP: maybe it scrolled off the page, i’ll send you a
link… https://autobuilder.yoctoproject.org/typhoon/#/builders/121/build
s/208
looks like it failed in aws and meta-oe.
Elberger: oh, it might have failed in aws because of a dependency on meta-oe.
RP: true, yes. this isn’t an issue with meta-aws

Elberger: how can maintainers do stuff on the AB
RP: talk to Nico and I. probably need to wait for September

TrevorG: python-cryptography test is failing because of a version mismatch,
needs setuptools-rust which requires rust in oe-core
Randy: look for my rust branch at poky-contrib


meta-gnome error #yocto

yasminebenghozzi6@...
 

Hello, please can anyone help with this error ? 
ERROR: ParseError at /home/yasmine/yocto/poky/meta-openembedded/meta-gnome/recipes-gnome/yelp/yelp_3.34.0.bb:7: Could not inherit file classes/itstool.bbclass

this is the line 7:
inherit gnomebase itstool autotools-brokensep gsettings gettext gtk-doc features_check mime-xdg


[meta-zephyr][PATCH] layer.conf: update machine confs with new tune locations

Naveen Saini
 

Added logic to make sure, it does not break with old releases.

Signed-off-by: Naveen Saini <naveen.kumar.saini@...>
---
conf/layer.conf | 2 ++
conf/machine/include/tune-corei7-common.inc | 4 ++--
conf/machine/qemu-x86.conf | 2 +-
3 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 5f13c27..35f1075 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -16,3 +16,5 @@ LAYERVERSION_zephyr = "1"
LAYERDEPENDS_zephyr = "core meta-python"

LAYERSERIES_COMPAT_zephyr = "dunfell gatesgarth hardknott honister"
+
+X86_TUNE_DIR = "${@bb.utils.contains('LAYERSERIES_CORENAMES', 'honister', 'include/x86', 'include', d)}"
diff --git a/conf/machine/include/tune-corei7-common.inc b/conf/machine/include/tune-corei7-common.inc
index 509d190..b68fc05 100644
--- a/conf/machine/include/tune-corei7-common.inc
+++ b/conf/machine/include/tune-corei7-common.inc
@@ -1,6 +1,6 @@
DEFAULTTUNE ?= "corei7-64"
-require conf/machine/include/tune-corei7.inc
-require conf/machine/include/x86-base.inc
+require conf/machine/${X86_TUNE_DIR}/tune-corei7.inc
+require conf/machine/${X86_TUNE_DIR}/x86-base.inc

# Add x86 to MACHINEOVERRIDE
MACHINEOVERRIDES =. "x86:"
diff --git a/conf/machine/qemu-x86.conf b/conf/machine/qemu-x86.conf
index 31ce80d..ae7716c 100644
--- a/conf/machine/qemu-x86.conf
+++ b/conf/machine/qemu-x86.conf
@@ -3,7 +3,7 @@
#@DESCRIPTION: Machine for Zephyr BOARD qemu_x86

require conf/machine/include/qemu.inc
-require conf/machine/include/tune-i586.inc
+require conf/machine/${X86_TUNE_DIR}/tune-i586.inc

ZEPHYR_INHERIT_CLASSES += "zephyr-qemuboot"

--
2.17.1

3261 - 3280 of 57780