Date   

How to select Linux kernel version?

JH
 

Hi,

I replaced Linux kernel version from 4.19 by 5.10 bb file, but it
still built 4.19 zImage, I add PREFERRED_VERSION_linux-yocto = "5.10%"
in local.conf, it still built 4.19 zImage. Where the linux kernel
version is defined in configure files?

Thank you.

Kind regards,

- j


Re: oeqa: testcase caching

Richard Purdie
 

On Mon, 2021-01-04 at 11:44 +0100, Konrad Weihmann wrote:
I have a bunch of custom testcases (oeqa/runtime/cases) which are
interacting with "d" from the build host - basically fetching some
info
while executing the test, e.g.

foo = self.tc.td['MY_CUSTOM_VAR']

What I've seen is that these files create python __pycache__ files
during parsing of the testimage run.

On the initial run everything is working like expected, but if I now
change the variable "MY_CUSTOM_VAR", without modifying the
target-filesystem the value inside the test case doesn't get updated.

Did anyone else encountered this?

To me it seems like the value of the var does make it into the
pycache
files, ignoring the updated value on a second run.

On that note: wouldn't it make sense to disable the cache creation
for
oeqa test cases? just to mitigate chances of such scenarios?

Or maybe I'm doing something wrong here, so any pointers are highly
appreciated.
FWIW this doesn't sound right to me. pyc files (in __pycache__) would
cache the code, not data so I don't see how these values would be
preserved there. I don't doubt you're seeing some kind of issue but I
suspect its more likely bitbake's cache or something...

Cheers,

Richard


Re: How do I build an x32 Intel system?

Richard Purdie
 

On Sun, 2021-01-03 at 10:44 -0800, Paul D. DeRocco wrote:
I've been resurrecting an old Pyro project under Gatesgarth. It's an
Intel
32-bit system that needs maximum speed, so I decided to try to build
the
system and application as 64-bit, for more registers. It pretty much
worked
on the first try, and is about 8% faster. Now I'm trying to do it as
x32, to
see if that speeds it up even more.

Unable to find any specific instructions, I set the DEFAULTTUNE to
"core2-64-x32" in my BSP conf file. Also, in the old project I had
tinkered
around with this a bit, and had found some kernel config settings
somewhere,
so I tried using them again:

CONFIG_X86_X32=y
CONFIG_COMPAT=y
CONFIG_COMPAT_FOR_U64_ALIGNMENT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_KEYS_COMPAT=y
CONFIG_HAVE_ARCH_MMAP_RND_COMPAT_BITS=y
CONFIG_ARCH_MMAP_RND_COMPAT_BITS=8
CONFIG_BLOCK_COMPAT=y

Other than the first one, I don't know whether these are correct, or
where I
originally got them, or if there's a stock .cfg file that does all
this.

The system built fine, the SDK built fine, and my application built
fine,
but when I boot, I get a kernel panic, preceded by some message about
"kmod
busy with 50 threads for more than 5 seconds now".

Is there some instruction on how to do a proper x32 build? I couldn't
find
one Googling. Barring that, do any of those kernel configs look bogus?

You can see the autobuilder x32 test configuration here:

https://autobuilder.yoctoproject.org/typhoon/#/builders/57/builds/2866/steps/10/logs/stdio

the key parts of which are probably:

MACHINE = "qemux86-64"
DEFAULTTUNE = 'x86-64-x32'
baselib = "${@d.getVar('BASE_LIB_tune-' + (d.getVar('DEFAULTTUNE', True) or 'INVALID'), True) or 'lib'}"

Cheers,

Richard


Yocto Project Status WW01`21

Stephen Jolley
 

Current Dev Position: YP 3.3 M2 development

Next Deadline: 18th January 2021 YP 3.3 M2 build 

 

Next Team Meetings:

 

Key Status/Updates:

  • YP 3.2.1 and YP 3.3 M1 were released
  • Patches for 3.3 M2 development are being tested and merged. We have two weeks before M2 is due to be built.
  • Many version upgrades have been merged and the project has worked closely with the upcoming autoconf and ppp releases to reduce our patch deficit and ensure we’re ready for them.
  • We have seen a number of reproducibility failures from the increased test coverage on the autobuilder, several of the issues have had fixes.
  • We are now tracking intermittent ptest failures and a number of bugs have been opened for these, we don’t as yet have people able to work on them though.
  • CVE metrics have trended slowly downwards, thanks to everyone sending patches and quietly improving things either through patches or better CVE definitions upstream.
  • Intermittent autobuilder issues continue to occur. 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
  • The LTS release has changed documentation format from docbook over to sphinx to match master as it should be more maintainable and consistent with the project over the planned life of the LTS.
  • For the LTS, there is also discussion on whether the wider reproducibility testing should be enabled as recently done in master due to the number of potential issues which may need to be fixed (master isn’t 100% working yet) as well as whether the pseudo path filtering should be backported. Please do give input to discussions on these topics on the mailing lists.

 

Ways to contribute:

 

YP 3.3 Milestone Dates:

  • YP 3.3 M1 is released
  • YP 3.3 M2 build date 2021/01/18
  • YP 3.3 M2 Release date 2021/01/29
  • YP 3.3 M3 build date 2021/03/01
  • YP 3.3 M3 Release date 2021/03/12
  • 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.1 is released
  • YP 3.1.5 build date 2021/01/11
  • YP 3.1.5 release date 2021/01/22
  • YP 3.2.2 build date 2021/02/08
  • YP 3.2.2 release date 2021/02/19
  • YP 3.1.6 build date 2021/02/22
  • YP 3.1.6 release date 2021/03/05
  • YP 3.1.7 build date 2021/03/22
  • YP 3.1.7 release date 2021/04/02

 

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

 


Update version

JH
 

Hi,

Where to download Yocto receipt for kernel version 5.10? To update a
stable version, should I update Yocto version to 3.3 or 3.1?

Thank you.

Kind regards,

- j


[meta-mingw][PATCH] openssl: support for building nativesdk of mingw

Changqing Li
 

* add support for mingw32
* Engines are installed in a slightly different path, which is
urgly, patch it to make the path shorter
* remove runtime dependency from perl for mingw nativesdk

since commit 70da1f956bfbb627691c47eba7451182aca758e3 of oe-core
'openssl: Add c_rehash to misc package and add perl runtime dependency'

package openssl-misc have runtime dependency on perl, and perl then
have depenency on another 3 recipes, db/gdbm/libxcrypt. according to
http://arsv.github.io/perl-cross/usage.html, perl don't support
cross-compile build for mingw32 and another 3 recipes also don't
support mingw well. so remove the dependency of perl, don't support
c_rehash for mingw.

Signed-off-by: Changqing Li <changqing.li@windriver.com>
---
...ile.tmpl-don-t-add-prefix-for-libdir.patch | 32 +++++++++++++++++++
.../openssl/openssl_%.bbappend | 31 ++++++++++++++++++
2 files changed, 63 insertions(+)
create mode 100644 recipes-connectivity/openssl/files/0001-unix-Makefile.tmpl-don-t-add-prefix-for-libdir.patch
create mode 100644 recipes-connectivity/openssl/openssl_%.bbappend

diff --git a/recipes-connectivity/openssl/files/0001-unix-Makefile.tmpl-don-t-add-prefix-for-libdir.patch b/recipes-connectivity/openssl/files/0001-unix-Makefile.tmpl-don-t-add-prefix-for-libdir.patch
new file mode 100644
index 0000000..028431b
--- /dev/null
+++ b/recipes-connectivity/openssl/files/0001-unix-Makefile.tmpl-don-t-add-prefix-for-libdir.patch
@@ -0,0 +1,32 @@
+From 8fe5c9421acfaff35b637e7ad55d1df598bb7081 Mon Sep 17 00:00:00 2001
+From: Changqing Li <changqing.li@windriver.com>
+Date: Tue, 22 Dec 2020 09:22:10 +0800
+Subject: [PATCH] unix-Makefile.tmpl: don't add prefix for libdir
+
+we had pass libdir to Configure, don't use prefix again to
+avoid engineer dir set to:
+/opt/poky/3.2+snapshot/sysroots/x86_64-w64-mingw32/usr/opt/poky/3.2+snapshot/sysroots/x86_64-w64-mingw32/usr/lib/engines-1_1
+
+Upstream-Status: Inappropriate[oe-specific]
+
+Signed-off-by: Changqing Li <changqing.li@windriver.com>
+---
+ Configurations/unix-Makefile.tmpl | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/Configurations/unix-Makefile.tmpl b/Configurations/unix-Makefile.tmpl
+index bbafb98..eecb63e 100644
+--- a/Configurations/unix-Makefile.tmpl
++++ b/Configurations/unix-Makefile.tmpl
+@@ -244,7 +244,7 @@ LIBDIR={- our $libdir = $config{libdir} || "lib";
+ File::Spec::Win32->file_name_is_absolute($libdir) ? "" : $libdir -}
+ ENGINESDIR_dev={- use File::Spec::Win32;
+ our $enginesdir =
+- File::Spec::Win32->catdir($prefix,$libdir,
++ File::Spec::Win32->catdir($libdir,
+ "engines-$sover_dirname");
+ our ($enginesdir_dev, $enginesdir_dir, $enginesdir_file) =
+ File::Spec::Win32->splitpath($enginesdir, 1);
+--
+2.17.1
+
diff --git a/recipes-connectivity/openssl/openssl_%.bbappend b/recipes-connectivity/openssl/openssl_%.bbappend
new file mode 100644
index 0000000..7fd82f1
--- /dev/null
+++ b/recipes-connectivity/openssl/openssl_%.bbappend
@@ -0,0 +1,31 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+
+SRC_URI_append_mingw32_class-nativesdk = " \
+ file://0001-unix-Makefile.tmpl-don-t-add-prefix-for-libdir.patch \
+"
+
+do_configure_mingw32 () {
+ os=${HOST_OS}
+ target="$os-${HOST_ARCH}"
+ case $target in
+ mingw32-x86_64)
+ target=mingw64
+ ;;
+ mingw32-i686)
+ target=mingw
+ ;;
+ esac
+
+ useprefix=${prefix}
+ if [ "x$useprefix" = "x" ]; then
+ useprefix=/
+ fi
+ # WARNING: do not set compiler/linker flags (-I/-D etc.) in EXTRA_OECONF, as they will fully replace the
+ # environment variables set by bitbake. Adjust the environment variables instead.
+ HASHBANGPERL="/usr/bin/env perl" PERL=perl PERL5LIB="${S}/external/perl/Text-Template-1.46/lib/" \
+ perl ${S}/Configure ${EXTRA_OECONF} ${PACKAGECONFIG_CONFARGS} --prefix=$useprefix --openssldir=${libdir}/ssl-1.1 --libdir=${libdir} $target
+ perl ${B}/configdata.pm --dump
+}
+
+FILES_${PN}-engines_mingw32_class-nativesdk = "${libdir}/engines-1_1"
+RDEPENDS_${PN}-misc_remove_mingw32_class-nativesdk = "perl"
--
2.17.1


M+ & H bugs with Milestone Movements WW01

Stephen Jolley
 

All,

YP M+ or high bugs which moved to a new milestone in WW01 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 M1

3.3 M2

 

11746

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

richard.purdie@...

richard.purdie@...

3.3 M1

3.3 M2

 

12090

bitbake resident server reconnect needed ?

richard.purdie@...

richard.purdie@...

3.3 M1

3.3 M2

 

12368

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

richard.purdie@...

richard.purdie@...

3.3 M1

3.3 M2

 

12970

uninative file should be versionned

richard.purdie@...

richard.purdie@...

3.3 M1

3.3 M2

 

12986

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

richard.purdie@...

richard.purdie@...

3.3 M1

3.3 M2

 

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 M1

3.3 M2

 

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 M1

3.3 M2

 

13355

RDEPENDS does not work properly for native builds (only supports recipe names, not package names)

richard.purdie@...

richard.purdie@...

3.3 M1

3.3 M2

 

13374

Determine 32bit guest support on arm64

richard.purdie@...

richard.purdie@...

3.3 M1

3.3 M2

 

13424

devupstream doesn't work with mutilib

richard.purdie@...

richard.purdie@...

3.3 M1

3.3 M2

 

13448

bitbake master appears to expand variables it should not need to

richard.purdie@...

richard.purdie@...

3.3 M1

3.3 M2

 

13599

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

richard.purdie@...

richard.purdie@...

3.3 M1

3.3 M2

 

13699

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

richard.purdie@...

richard.purdie@...

3.3 M1

3.3 M2

 

13711

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

richard.purdie@...

richard.purdie@...

3.3 M1

3.3 M2

 

13729

Changing siteinfo files doesn't change task checksum

richard.purdie@...

richard.purdie@...

3.3 M1

3.3 M2

 

13823

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

richard.purdie@...

richard.purdie@...

3.3 M1

3.3 M2

 

13886

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

richard.purdie@...

richard.purdie@...

3.3 M1

3.3 M2

 

13973

rm_work sigdata written with same hash and empty diffsigs, though different contents

richard.purdie@...

richard.purdie@...

3.3 M1

3.3 M2

 

14054

bitbake-layers allows adding invalid layer configuration

richard.purdie@...

richard.purdie@...

3.3 M1

3.3 M2

 

14088

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

richard.purdie@...

richard.purdie@...

3.3 M1

3.3 M2

 

14112

nspr-native with OE/Yocto build tools doesn't build [Ubuntu 16.04.6]: undefined reference  to `__clock_getres@GLIBC_PRIVATE'

richard.purdie@...

richard.purdie@...

3.3 M1

3.3 M2

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 48 bug owners as of the end of WW01 of who have open medium or higher bugs and enhancements against YP 3.3.   There are 81 possible work days left until the final release candidates for YP 3.3 needs to be released.

Who

Count

richard.purdie@...

36

ross@...

27

david.reyna@...

21

bluelightning@...

19

bruce.ashfield@...

14

timothy.t.orling@...

12

JPEWhacker@...

11

mark.morton@...

11

sakib.sajal@...

10

kai.kang@...

10

trevor.gamblin@...

9

akuster808@...

9

Qi.Chen@...

6

hongxu.jia@...

4

stacygaikovaia@...

4

randy.macleod@...

4

raj.khem@...

4

yi.zhao@...

4

idadelm@...

4

mingli.yu@...

4

mostthingsweb@...

3

chee.yang.lee@...

3

alejandro@...

3

jeanmarie.lemetayer@...

2

saul.wold@...

2

matthewzmd@...

2

pokylinux@...

2

jaewon@...

2

ydirson@...

2

anuj.mittal@...

2

jon.mason@...

2

shachar@...

1

kergoth@...

1

aehs29@...

1

akuster@...

1

mark.hatle@...

1

pbarker@...

1

kamensky@...

1

dl9pf@...

1

joe.slater@...

1

twoerner@...

1

apoorvsangal@...

1

liezhi.yang@...

1

mhalstead@...

1

maxime.roussinbelanger@...

1

kexin.hao@...

1

Martin.Jansa@...

1

matt.ranostay@...

1

Grand Total

265

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

 


Reminder: Yocto Project Technical Team Meeting @ Monthly from 8am on the first Tuesday (PDT)

Stephen Jolley
 

All,

 

Just a reminder we will hold the monthly Yocto Project Technical Meeting at 8am PST tomorrow. (1/5) 

 

Yocto Project Technical Team Meeting: We encourage people attending the meeting to logon and announce themselves on the Yocto Project IRC chancel during the meeting (optional):

Yocto IRC: http://webchat.freenode.net/?channels=#yocto

 

Wiki: https://www.yoctoproject.org/public-virtual-meetings/

 

When            Monthly from 8am to 9am on the first Tuesday Pacific Time

Where           Zoom Meeting: https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09

 

We are tracking the minutes at: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit?pli=1 Please request access if you want to assist in editing them.  The world should have view access.

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Re: oeqa: test cases at the end of the test suite

Ross Burton
 

On Mon, 4 Jan 2021 at 10:50, Konrad Weihmann <kweihmann@outlook.com> wrote:
I have a few oeqa test cases, which always should run last in a test
suite (log and file collectors for instance).
Those are not test cases then, surely. If you want to run actions
after test cases to collect log files then I'd implement that as a
decorator on the test cases.

Ross


Re: oeqa: test cases at the end of the test suite

Alexander Kanavin
 

I'd say improving the actual test ordering function is the way to go, yes. Not sure how the ordering 'hint' should be like, but maybe setting an integer priority via a decorator would work:
@OETestPriority(1) ---> runs first, no guarantees about relative order of other tests with priority 1.
@OETestPriority(99) ---> runs last, ditto.
Default priority: 50 or similar.

Alex


On Mon, 4 Jan 2021 at 11:51, Konrad Weihmann <kweihmann@...> wrote:
Hi all,

I have a few oeqa test cases, which always should run last in a test
suite (log and file collectors for instance).
Due to the ordering of the test case discovery I had to name all those
tests like "zzz_<name>" to move them to the end of the computed list.

Unfortunately this is very error prone, as the OETestDepends tag does
have major influence on the ordering (just a single misplaced tag in any
test case can make it past those "zzz" cases).
Also it makes things hard to read IMO.

That brings me to my question, is there any way to ensure that test
cases are run at the end of the complete list of test suites?

If not does anyone have an idea how to create such a feature (maybe a
new decorator or something like that)?

Regards
Konrad




Re: How do I build an x32 Intel system?

morgan.hill@...
 

Other than the first one, I don't know whether these are correct, or
where I
originally got them, or if there's a stock .cfg file that does all
this.
I'm not familiar with x32 myself but Debian has an x32port which should
give you a working kernel config to start from.
https://wiki.debian.org/X32Port


--

<http://holoplot.com/?utm_source=email&utm_medium=sg&utm_campaign=Holoplot_Signature+>

<https://holoplot.com/>*HOLOPLOT GmbH - Headquarters*


Ringbahnstr. 12
(10-14) / A2

12099 Berlin, Germany

+49 (0) 30 40745812




*HOLOPLOT GmbH
- Manufacturing*


Alboinstr. 17-23 / Hall 12

12103 Berlin, Germany

+49
(0) 30 959988740


www.holoplot.com <https://holoplot.com/>



Follow us on
<https://www.facebook.com/OriginalHOLOPLOT/?utm_source=email&utm_medium=sg&utm_campaign=Holoplot_Signature+>
LinkedIn
<https://www.linkedin.com/company/holoplot-gmbh?utm_source=email&utm_medium=sg&utm_campaign=Holoplot_Signature+>.




Roman Sick – CEO | HRB183974B, Register Court Charlottenburg, Germany |
EU Tax-Registration No. DE277000701 This e-mail contains confidential
and/or privileged information. If you are not the intended recipient (or
have received this e-mail in error) please notify the sender immediately
and destroy this e-mail. Any unauthorized copying, disclosure or
distribution of the information in this e-mail is strictly forbidden.


oeqa: test cases at the end of the test suite

Konrad Weihmann
 

Hi all,

I have a few oeqa test cases, which always should run last in a test suite (log and file collectors for instance).
Due to the ordering of the test case discovery I had to name all those tests like "zzz_<name>" to move them to the end of the computed list.

Unfortunately this is very error prone, as the OETestDepends tag does have major influence on the ordering (just a single misplaced tag in any test case can make it past those "zzz" cases).
Also it makes things hard to read IMO.

That brings me to my question, is there any way to ensure that test cases are run at the end of the complete list of test suites?

If not does anyone have an idea how to create such a feature (maybe a new decorator or something like that)?

Regards
Konrad


oeqa: testcase caching

Konrad Weihmann
 

Hi all,

I have a bunch of custom testcases (oeqa/runtime/cases) which are interacting with "d" from the build host - basically fetching some info while executing the test, e.g.

foo = self.tc.td['MY_CUSTOM_VAR']

What I've seen is that these files create python __pycache__ files during parsing of the testimage run.

On the initial run everything is working like expected, but if I now change the variable "MY_CUSTOM_VAR", without modifying the target-filesystem the value inside the test case doesn't get updated.

Did anyone else encountered this?

To me it seems like the value of the var does make it into the pycache files, ignoring the updated value on a second run.

On that note: wouldn't it make sense to disable the cache creation for oeqa test cases? just to mitigate chances of such scenarios?

Or maybe I'm doing something wrong here, so any pointers are highly appreciated.

Regards
Konrad


Re: [meta-tensorflow][PATCH 8/25] tensorflow-estimator: 1.13 -> 2.4

Marek Belisko
 

Hi Hongxu,

On Wed, Dec 16, 2020 at 2:09 PM Hongxu Jia <hongxu.jia@windriver.com> wrote:

Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
---
.../0001-customize-for-yocto.patch | 28 +++++++++++++++++++
.../tensorflow/tensorflow-estimator_1.13.bb | 12 ++++++--
2 files changed, 37 insertions(+), 3 deletions(-)
create mode 100644 recipes-framework/tensorflow/tensorflow-estimator/0001-customize-for-yocto.patch

diff --git a/recipes-framework/tensorflow/tensorflow-estimator/0001-customize-for-yocto.patch b/recipes-framework/tensorflow/tensorflow-estimator/0001-customize-for-yocto.patch
new file mode 100644
index 0000000..e9b66d5
--- /dev/null
+++ b/recipes-framework/tensorflow/tensorflow-estimator/0001-customize-for-yocto.patch
@@ -0,0 +1,28 @@
+From a1bcf09a43fc44ad5e04c441ee45cc23d16cf7d2 Mon Sep 17 00:00:00 2001
+From: Hongxu Jia <hongxu.jia@windriver.com>
+Date: Wed, 9 Dec 2020 17:59:01 +0800
+Subject: [PATCH] customize for yocto
+
+Upstream-Status: Inappropriate [oe specific]
+
+Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
+---
+ tensorflow_estimator/tools/pip_package/build_pip_package.sh | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/tensorflow_estimator/tools/pip_package/build_pip_package.sh b/tensorflow_estimator/tools/pip_package/build_pip_package.sh
+index d4953a6..e08cd8a 100755
+--- a/tensorflow_estimator/tools/pip_package/build_pip_package.sh
++++ b/tensorflow_estimator/tools/pip_package/build_pip_package.sh
+@@ -38,7 +38,7 @@ function prepare_src() {
+
+ # Verifies all expected files are in pip.
+ # Creates init files in all directory in pip.
+- python tensorflow_estimator/tools/pip_package/create_pip_helper.py --pip-root "${TMPDIR}/tensorflow_estimator/" --bazel-root "./tensorflow_estimator"
++ nativepython3 tensorflow_estimator/tools/pip_package/create_pip_helper.py --pip-root "${TMPDIR}/tensorflow_estimator/" --bazel-root "./tensorflow_estimator"
+ }
+
+ function build_wheel() {
+--
+2.18.2
+
diff --git a/recipes-framework/tensorflow/tensorflow-estimator_1.13.bb b/recipes-framework/tensorflow/tensorflow-estimator_1.13.bb
index f3a5098..5b2fe5d 100644
--- a/recipes-framework/tensorflow/tensorflow-estimator_1.13.bb
+++ b/recipes-framework/tensorflow/tensorflow-estimator_1.13.bb
@@ -3,9 +3,10 @@ learning programming."
LICENSE = "Apache-2.0"
LIC_FILES_CHKSUM = "file://LICENSE;md5=01e86893010a1b87e69a213faa753ebd"

-SRC_URI = "git://github.com/tensorflow/estimator.git;branch=r1.13 \
+SRC_URI = "git://github.com/tensorflow/estimator.git;branch=r2.4 \
+ file://0001-customize-for-yocto.patch \
"
-SRCREV = "340703eed78ba4854862f749ed94f91598826e79"
+SRCREV = "c3e7f2b5bbcc35185ef71797955a28cadce28f60"
S = "${WORKDIR}/git"

inherit python3native bazel
@@ -19,12 +20,18 @@ DEPENDS += " \
python3-astor-native \
python3-gast-native \
python3-termcolor-native \
+ python3-wrapt-native \
+ python3-opt-einsum-native \
+ python3-astunparse-native \
+ flatbuffers-native \
I'm getting issue when building tensorflow-estimator (I add small
changes to be able to build this patches on top of dunfell) and I'm
getting:
| /bin/bash -c 'source
external/bazel_tools/tools/genrule/genrule-setup.sh;
bazel-out/k8-opt-exec-2B5CBBC6/bin/tensorflow_estimator/python/estimator/api/create_tensorflow_estimator.python.estimator_api_1_estimator_python_api_gen_compat_v1
--apidir=bazel-out/k8-fastbuild/bin/tensorflow_estimator/python/estimator/api_v1/
--apiname=estimator --apiversion=1
--package=tensorflow_estimator.python.estimator
--output_package=tensorflow_estimator.python.estimator.api._v1
bazel-out/k8-fastbuild/bin/tensorflow_estimator/python/estimator/api/_v1/v1.py
bazel-out/k8-fastbuild/bin/tensorflow_estimator/python/estimator/api/_v1/estimator/__init__.py
bazel-out/k8-fastbuild/bin/tensorflow_estimator/python/estimator/api/_v1/estimator/experimental/__init__.py
bazel-out/k8-fastbuild/bin/tensorflow_estimator/python/estimator/api/_v1/estimator/export/__init__.py
bazel-out/k8-fastbuild/bin/tensorflow_estimator/python/estimator/api/_v1/estimator/inputs/__init__.py
bazel-out/k8-fastbuild/bin/tensorflow_estimator/python/estimator/api/_v1/estimator/tpu/__init__.py
bazel-out/k8-fastbuild/bin/tensorflow_estimator/python/estimator/api/_v1/estimator/tpu/experimental/__init__.py')
| Execution platform: @local_config_platform//:host
| /home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/recipe-sysroot-native/usr/lib/python3.8/site-packages/h5py/__init__.py:72:
UserWarning: h5py is running against HDF5 1.8.21 when it was built
against 1.8.19, this may cause problems
| _warn(("h5py is running against HDF5 {0} when it was built against {1}, "
| Traceback (most recent call last):
| File "/home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/bazel/output_base/execroot/org_tensorflow_estimator/bazel-out/k8-opt-exec-2B5CBBC6/bin/tensorflow_estimator/python/estimator/api/create_tensorflow_estimator.python.estimator_api_1_estimator_python_api_gen_compat_v1.runfiles/org_tensorflow_estimator/tensorflow_estimator/python/estimator/api/create_python_api_wrapper.py",
line 26, in <module>
| from tensorflow_estimator.python.estimator import estimator_lib
# pylint: disable=unused-import
| File "/home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/bazel/output_base/execroot/org_tensorflow_estimator/bazel-out/k8-opt-exec-2B5CBBC6/bin/tensorflow_estimator/python/estimator/api/create_tensorflow_estimator.python.estimator_api_1_estimator_python_api_gen_compat_v1.runfiles/org_tensorflow_estimator/tensorflow_estimator/python/estimator/estimator_lib.py",
line 22, in <module>
| from tensorflow_estimator.python.estimator.canned.baseline
import BaselineClassifier
| File "/home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/bazel/output_base/execroot/org_tensorflow_estimator/bazel-out/k8-opt-exec-2B5CBBC6/bin/tensorflow_estimator/python/estimator/api/create_tensorflow_estimator.python.estimator_api_1_estimator_python_api_gen_compat_v1.runfiles/org_tensorflow_estimator/tensorflow_estimator/python/estimator/canned/baseline.py",
line 53, in <module>
| import tensorflow as tf
| File "/home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/recipe-sysroot-native/usr/lib/python3.8/site-packages/tensorflow/__init__.py",
line 55, in <module>
| from ._api.v2 import compat
| File "/home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/recipe-sysroot-native/usr/lib/python3.8/site-packages/tensorflow/_api/v2/compat/__init__.py",
line 39, in <module>
| from . import v1
| File "/home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/recipe-sysroot-native/usr/lib/python3.8/site-packages/tensorflow/_api/v2/compat/v1/__init__.py",
line 34, in <module>
| from . import compat
| File "/home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/recipe-sysroot-native/usr/lib/python3.8/site-packages/tensorflow/_api/v2/compat/v1/compat/__init__.py",
line 39, in <module>
| from . import v1
| File "/home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/recipe-sysroot-native/usr/lib/python3.8/site-packages/tensorflow/_api/v2/compat/v1/compat/v1/__init__.py",
line 51, in <module>
| from tensorflow._api.v2.compat.v1 import lite
| File "/home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/recipe-sysroot-native/usr/lib/python3.8/site-packages/tensorflow/_api/v2/compat/v1/lite/__init__.py",
line 11, in <module>
| from . import experimental
| File "/home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/recipe-sysroot-native/usr/lib/python3.8/site-packages/tensorflow/_api/v2/compat/v1/lite/experimental/__init__.py",
line 10, in <module>
| from . import nn
| File "/home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/recipe-sysroot-native/usr/lib/python3.8/site-packages/tensorflow/_api/v2/compat/v1/lite/experimental/nn/__init__.py",
line 10, in <module>
| from tensorflow.lite.python.lite import TFLiteLSTMCell
| File "/home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/recipe-sysroot-native/usr/lib/python3.8/site-packages/tensorflow/lite/python/lite.py",
line 40, in <module>
| from tensorflow.lite.python.convert import
build_toco_convert_protos # pylint: disable=unused-import
| File "/home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/recipe-sysroot-native/usr/lib/python3.8/site-packages/tensorflow/lite/python/convert.py",
line 33, in <module>
| from tensorflow.lite.python import util
| File "/home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/recipe-sysroot-native/usr/lib/python3.8/site-packages/tensorflow/lite/python/util.py",
line 30, in <module>
| import flatbuffers
| ModuleNotFoundError: No module named 'flatbuffers'

FLatbuffers from openembedded are available version 1.12. Do you have
an idea what is can cause?
tensorflow-native \
"

do_compile () {
unset CC
export TMPDIR="${WORKDIR}"
+ export PYTHON_BIN_PATH="${PYTHON}"
+
${BAZEL} build \
--subcommands --explain=${T}/explain.log \
--verbose_explanations --verbose_failures \
@@ -32,7 +39,6 @@ do_compile () {
--python_path="${PYTHON}" \
//tensorflow_estimator/tools/pip_package:build_pip_package

- PYTHON_BIN_PATH="${PYTHON}" \
${S}/bazel-bin/tensorflow_estimator/tools/pip_package/build_pip_package \
${WORKDIR}/estimator_pip
}
--
2.21.0
Thanks and BR,

marek
--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com


#yocto #gstreamer #gstreamer1.0-plugins-bad #yocto #gstreamer #aom #av1

safouane maaloul
 

Bonjour, j'essaye d'ajouter le aom plugin au niveau de la gstreamer1.0-plugins-bad. J'ai basculé sur gatesgarth version. Je commence à faire lebuild. J'avais un problème de lisence. Je l'ai résolu. Et maintenant j'ai un problème "no such file or directory automake-native yocto" et j'arrive pas à la résoudre ? Est-ce que vous pouvez m'aider ? y a t il quelqu'un qui a essayé d'ajouter av1 codec (aom plugins/gstreamer1.0-plugins-bad).

Cordialement,

Safouane.Maaloul


Re: Standard library header bug when compiling x32 application

Paul D. DeRocco
 

From: Paul D. DeRocco

Using Yocto 3.2.1 on an Intel target, trying to use the x32 model. I'm
getting this compile error when I use the SDK to separately compile my
application. I get no such errors when I build Linux, or the SDK.

In file included from
/opt/poky/3.2.1/i64/sysroots/core2-64-poky-linux/usr/include/sys/cdefs.h:453
,
from
/opt/poky/3.2.1/i64/sysroots/core2-64-poky-linux/usr/include/features.h:465,
from
/opt/poky/3.2.1/i64/sysroots/core2-64-poky-linux/usr/include/dirent.h:25,
from ../my_header_file.h:7,
from ../my_source_file.cpp:3:
/opt/poky/3.2.1/i64/sysroots/core2-64-poky-linux/usr/include/bits/long-doubl
e.h:23:10: fatal error: bits/long-double-32.h: No such file
or directory
etc., etc.

I solved this myself by building an SDK specific to the x32 configuration,
rather than trying to use the plain 64-bit SDK. What led me to believe that
the 64-bit SDK should work is that the host sysroot includes
/usr/bin/x86_64-poky-linux and /usr/bin/x86_64-poky-linux-gnux32
subdirectories. The latter contains symlinks into the former, which is no
surprise, since one toolchain should be able to do 32, 64, and 64x32, but
the target sysroot include files don't quite work. The only reason I care is
that each SDK is about 2.4GB. So I'm not sure if this is a bug, or whose bug
it is, but 2.4GB seems awfully large for an SDK, especially since this is
the standard SDK, not the ESDK.

--

Ciao, Paul D. DeRocco
Paul mailto:pderocco@ix.netcom.com


How do I build an x32 Intel system?

Paul D. DeRocco
 

I've been resurrecting an old Pyro project under Gatesgarth. It's an Intel
32-bit system that needs maximum speed, so I decided to try to build the
system and application as 64-bit, for more registers. It pretty much worked
on the first try, and is about 8% faster. Now I'm trying to do it as x32, to
see if that speeds it up even more.

Unable to find any specific instructions, I set the DEFAULTTUNE to
"core2-64-x32" in my BSP conf file. Also, in the old project I had tinkered
around with this a bit, and had found some kernel config settings somewhere,
so I tried using them again:

CONFIG_X86_X32=y
CONFIG_COMPAT=y
CONFIG_COMPAT_FOR_U64_ALIGNMENT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_KEYS_COMPAT=y
CONFIG_HAVE_ARCH_MMAP_RND_COMPAT_BITS=y
CONFIG_ARCH_MMAP_RND_COMPAT_BITS=8
CONFIG_BLOCK_COMPAT=y

Other than the first one, I don't know whether these are correct, or where I
originally got them, or if there's a stock .cfg file that does all this.

The system built fine, the SDK built fine, and my application built fine,
but when I boot, I get a kernel panic, preceded by some message about "kmod
busy with 50 threads for more than 5 seconds now".

Is there some instruction on how to do a proper x32 build? I couldn't find
one Googling. Barring that, do any of those kernel configs look bogus?

--

Ciao, Paul D. DeRocco
Paul mailto:pderocco@ix.netcom.com


Standard library header bug when compiling x32 application

Paul D. DeRocco
 

Using Yocto 3.2.1 on an Intel target, trying to use the x32 model. I'm
getting this compile error when I use the SDK to separately compile my
application. I get no such errors when I build Linux, or the SDK.

In file included from
/opt/poky/3.2.1/i64/sysroots/core2-64-poky-linux/usr/include/sys/cdefs.h:453
,
from
/opt/poky/3.2.1/i64/sysroots/core2-64-poky-linux/usr/include/features.h:465,
from
/opt/poky/3.2.1/i64/sysroots/core2-64-poky-linux/usr/include/dirent.h:25,
from ../my_header_file.h:7,
from ../my_source_file.cpp:3:
/opt/poky/3.2.1/i64/sysroots/core2-64-poky-linux/usr/include/bits/long-doubl
e.h:23:10: fatal error: bits/long-double-32.h: No such file or directory

long-double.h includes either long-double-32.h or long-double-64.h based on
the __WORDSIZE macro, which is 32. This works fine when compiling straight
32-bit or 64-bit code, but fails in x32 code because only long-double-64.h
exists. I don't see why the characteristics of a long double should have
anything to do with the "word size" of a pointer or long int. And indeed,
the two headers it chooses from are basically empty, except for defining
__LDOUBLE_REDIRECTS_TO_FLOAT128_ABI. I'm also not sure why it would be
harmful for both of these files to exist always.

So this is an obvious bug. But my question is: what's the cleanest way to
get over this hump? Patch cdefs.h when building the SDK? Use a bbappend on
some SDK recipe to copy long-double-64.h to long-double-32.h? I have no idea
where this recipe would be.

--

Ciao, Paul D. DeRocco
Paul mailto:pderocco@ix.netcom.com

2021 - 2040 of 53882