yocto@lists.yoctoproject.org

[yocto-autobuilder-helper][dunfell 1/3] config.json: Add BB_HASHSERVE to SDK_LOCAL_CONF_BLACKLIST

Steve Sakoman

#55103

From: Richard Purdie <richard.purdie@...>

This should avoid issues with the hashequiv code attempting to contact
an non-existent server in the eSDKs built by the project.

[YOCTO #14471]

Signed-off-by: Richard Purdie <richard.purdie@...>
(cherry picked from commit 4db17f4c9da4efb48d428256efb696d86935a3ea)
Signed-off-by: Steve Sakoman <steve@...>
---
 config.json | 1 +
 1 file changed, 1 insertion(+)

diff --git a/config.json b/config.json
index d871349..571ddae 100644
--- a/config.json
+++ b/config.json
@@ -55,6 +55,7 @@
             "SANITY_TESTED_DISTROS = ''",
             "SDK_EXT_TYPE = 'minimal'",
             "SDK_INCLUDE_TOOLCHAIN = '1'",
+            "SDK_LOCAL_CONF_BLACKLIST:append = 'BB_HASHSERVE'",
             "BB_DISKMON_DIRS = 'STOPTASKS,${TMPDIR},1G,100K STOPTASKS,${DL_DIR},1G STOPTASKS,${SSTATE_DIR},1G STOPTASKS,/tmp,100M,100K ABORT,${TMPDIR},100M,1K ABORT,${DL_DIR},100M ABORT,${SSTATE_DIR},100M ABORT,/tmp,10M,1K'",
             "BB_HASHSERVE = 'typhoon.yocto.io:8686'"
         ]
-- 
2.25.1

[yocto-autobuilder-helper][dunfell 0/3] Patch review

Steve Sakoman

#55102

Please review this next set of changes for dunfell and have comments back
by end of day Thursday.

Passed a-full on autobuilder:

https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/2772

The following changes since commit 1c953db8a72c2330fa192402460a3ecf0a691344:

  config.json: Update check-layer to use --no-auto-dependency after yocto-check-layer changes (2021-08-04 16:24:20 +0100)

are available in the Git repository at:

  git://git.yoctoproject.org/yocto-autobuilder-helper contrib/sakoman
  http://git.yoctoproject.org/cgit.cgi/yocto-autobuilder-helper/log/?h=contrib/sakoman

Richard Purdie (2):
  config.json: Add BB_HASHSERVE to SDK_LOCAL_CONF_BLACKLIST
  config.json: Ensure BB_HASHSERVE is set in SDKs to auto

Trevor Gamblin (1):
  config.json: set max load in PARALLEL_MAKE

 config.json | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

-- 
2.25.1

Re: #zeus meta-intel #zeus

Monsees, Steven C (US)

#55101

I am able to build clean...

One question, "clang" is a dependency for the build of the NEO driver, once built, do I still require clang as part of my image ?, or can I remove the clang component in the recipe that creates my final image ?

Clang takes up a lot space, if not needed in the end, I'd like to be able to remove and reduce the size of my image.

Thanks again for your help,
Steve

Show quoted text

-----Original Message-----
From: Mittal, Anuj <anuj.mittal@...> 
Sent: Wednesday, October 13, 2021 9:28 PM
To: Monsees, Steven C (US) <steven.monsees@...>; yocto@...
Subject: Re: [yocto] #zeus meta-intel

External Email Alert

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

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


There are no patches needed other than what is already in oe-core/meta- intel/meta-clang. I tried building zeus on Ubuntu 16.04 and didn't see any problem.

zeus is no longer maintained or supported so I'd suggest checking a newer release or experimenting without using buildtools to see if that is exposing this problem. It does look like things are not being compiled properly or perhaps opencl-clang-native is linking to incorrect LLVM ... 

Thanks,

Anuj

On Wed, 2021-10-13 at 16:53 +0000, Monsees, Steven C (US) wrote:

Anything ?, I have yet to resolve this.

-----Original Message-----
From: Monsees, Steven C (US)
Sent: Wednesday, October 13, 2021 9:03 AM
To: 'Mittal, Anuj' <anuj.mittal@...>; 
'yocto@...' <yocto@...>
Subject: RE: [yocto] #zeus meta-intel


Are there any patches required for these components (igc, opencl- 
clang, and intel-compute-runtime) ?

-----Original Message-----
From: Monsees, Steven C (US)
Sent: Wednesday, October 13, 2021 7:13 AM
To: 'Mittal, Anuj' <anuj.mittal@...>; 
yocto@...
Subject: RE: [yocto] #zeus meta-intel


Anuj:

I rebuilt the entire image (but did not delete the state_cache)...
I am building meta-clang (zeus based, I believe it is 9.0.1).

Steve

-----Original Message-----
From: Mittal, Anuj <anuj.mittal@...>
Sent: Tuesday, October 12, 2021 10:10 PM
To: Monsees, Steven C (US) <steven.monsees@...>; 
yocto@...
Subject: Re: [yocto] #zeus meta-intel

External Email Alert

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

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


Did you build everything with this compiler from start? Is opencl- 
clang building with the right LLVM lib from meta-clang?

Thanks,

Anuj

On Tue, 2021-10-12 at 17:15 +0000, Monsees, Steven C (US) wrote:

Anuj:

I picked up the tarball for for the baseline dunfell tools platform 
to update host tools...

I am seeing it compile cleaner but for one issue causng ld to fail:

/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
default/tmp/work/x86_64-linux/intel-graphics-compiler-
native/1.0.11-
r0/recipe-sysroot-
native/usr/include/llvm/Support/CommandLine.h:1331:
undefined reference to `vtable for
llvm::cl::opt<std::__cxx11::basic_string<char,
std::char_traits<char>,
std::allocator<char> >, false,
llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > > >'

Isn't LLVM brought in along with clang under meta-clang ?

Is there a missing build dependency ?

Thanks,
Steve

Build excerpt showing multiple " undefined reference to `vtable "
errors...

/opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
`llvm::cl::opt<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >, false, 
llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > > >::~opt()':
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
default/tmp/work/x86_64-linux/intel-graphics-compiler-
native/1.0.11-
r0/recipe-sysroot-
native/usr/include/llvm/Support/CommandLine.h:1331:
undefined reference to `vtable for
llvm::cl::opt<std::__cxx11::basic_string<char,
std::char_traits<char>,
std::allocator<char> >, false,
llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > > >'
/opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
`llvm::cl::OptionValue<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >::OptionValue()':
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
default/tmp/work/x86_64-linux/intel-graphics-compiler-
native/1.0.11-
r0/recipe-sysroot-
native/usr/include/llvm/Support/CommandLine.h:601:
undefined reference to `vtable for
llvm::cl::OptionValue<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >'
/opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
`llvm::cl::opt<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >, false, 
llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >
::opt<llvm::cl::FormattingFlags, llvm::cl::desc,llvm::cl::desc const&, llvm::cl::initializer<char [2]> const&)':
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
default/tmp/work/x86_64-linux/intel-graphics-compiler-
native/1.0.11-
r0/recipe-sysroot-
native/usr/include/llvm/Support/CommandLine.h:1407:
undefined reference to `vtable for
llvm::cl::opt<std::__cxx11::basic_string<char,
std::char_traits<char>,
std::allocator<char> >, false,
llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > > >'
/opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
`llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >
::parser(llvm::cl::Option&)':/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
default/tmp/work/x86_64-linux/intel-graphics-compiler-
native/1.0.11-
r0/recipe-sysroot-
native/usr/include/llvm/Support/CommandLine.h:1072:
undefined reference to `vtable for
llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >'
/opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
`llvm::cl::opt<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >, false, 
llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > > >::~opt()':
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
default/tmp/work/x86_64-linux/intel-graphics-compiler-
native/1.0.11-
r0/recipe-sysroot-
native/usr/include/llvm/Support/CommandLine.h:1331:
undefined reference to `vtable for
llvm::cl::opt<std::__cxx11::basic_string<char,
std::char_traits<char>,
std::allocator<char> >, false,
llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > > >'
/opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
`llvm::cl::OptionValue<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >::OptionValue()':
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
default/tmp/work/x86_64-linux/intel-graphics-compiler-
native/1.0.11-
r0/recipe-sysroot-
native/usr/include/llvm/Support/CommandLine.h:601:
undefined reference to `vtable for
llvm::cl::OptionValue<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >'
/opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
`llvm::cl::opt<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >, false, 
llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > > >::opt<char [9], 
llvm::cl::desc>(char const (&) [9], llvm::cl::desc const&)':
/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
default/tmp/work/x86_64-linux/intel-graphics-compiler-
native/1.0.11-
r0/recipe-sysroot-
native/usr/include/llvm/Support/CommandLine.h:1407:
undefined reference to `vtable for
llvm::cl::opt<std::__cxx11::basic_string<char,
std::char_traits<char>,
std::allocator<char> >, false,
llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > > >'
/opt/poky/3.1.3/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-
pokysdk-linux/9.3.0/../../../../x86_64-pokysdk-linux/bin/ld:
`llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >
::parser(llvm::cl::Option&)':/disk0/scratch/smonsees/yocto/workspace_1/builds2/sbcb-
default/tmp/work/x86_64-linux/intel-graphics-compiler-
native/1.0.11-
r0/recipe-sysroot-
native/usr/include/llvm/Support/CommandLine.h:1072:
undefined reference to `vtable for
llvm::cl::parser<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >'
collect2: error: ld returned 1 exit status

-----Original Message-----
From: yocto@... <yocto@...> On 
Behalf Of Anuj Mittal
Sent: Tuesday, October 12, 2021 10:43 AM
To: Monsees, Steven C (US) <steven.monsees@...>; 
yocto@...
Subject: Re: [yocto] #zeus meta-intel

External Email Alert

network.

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


On Tue, 2021-10-12 at 12:43 +0000, Monsees, Steven C (US) wrote:
g++: error: unrecognized command line option ‘-std=c++14’It looks like the gcc version is too old on your host for this to 
work.

Thanks,

Anuj

Yocto Project Status WW42`21

Richard Purdie

#55100

Current Dev Position: YP 3.4 M4

Next Deadline: 29th Oct. 2021 YP 3.4 M4 release

Next Team Meetings:

Bug Triage meeting Thursday Oct. 21st at 7:30am PDT (https://zoom.us/j/454367603?pwd=ZGxoa2ZXL3FkM3Y0bFd5aVpHVVZ6dz09)
Monthly Project Meeting Tuesday Nov. 2nd at 8am PDT (https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09 )
Weekly Engineering Sync Tuesday Oct. 19th at 8am PDT (https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09 )
Twitch - See https://www.twitch.tv/theyoctojester

Key Status/Updates:

YP 3.4 rc1 is through QA and the TSC is discussing, likely planning to release as 3.4
YP 3.5 Planning document: https://docs.google.com/document/d/1OXw-NKoL_Vb9RWI6sRPs3zTcAn4hHPtG0Y2BIs7xIzo/edit?usp=sharing
Patches to master have continued to merge post-release, most of the backlog is now processed. There were a number of more invasive changes that were deferred for after 3.4 and this has disrupted things a little (pkgconfig-native missing dependencies, reproducible builds being made the default, openssl 3.X, python 3.10, insane class function cleanup and switch to zstd for sstate which have also now merged.
We are pleased to report that sstate reuse on the autobuilder has improved significantly and this is reducing build times, to the point several of us did check to see if it did actually build things!
Intermittent issues continue to rise, particularly with some seemingly network related gremlin somewhere. 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:

There are bugs identified as possible for newcomers to the project: https://wiki.yoctoproject.org/wiki/Newcomers
There are bugs that are currently unassigned for YP 3.4. See: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_3.4_Unassigned_Enhancements.2FBugs
We’d welcome new maintainers for recipes in OE-Core. Please see the list at: http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/distro/include/maintainers.inc and discuss with the existing maintainer, or ask on the OE-Core mailing list. We will likely move a chunk of these to “Unassigned” soon to help facilitate this.

YP 3.4 Milestone Dates:

YP 3.4 M4 is in QA
YP 3.4 M4 Release date 2021/10/29

Proposed YP 3.5 Milestone Dates:

YP 3.5 M1 build date 2021/12/06
YP 3.5 M1 Release date 2021/12/17
YP 3.5 M2 build date 2022/01/10
YP 3.5 M2 Release date 2022/1/21
YP 3.5 M3 build date 2022/2/21
YP 3.5 M3 Release date 2022/03/04
YP 3.5 M4 build date 2022/04/04
YP 3.5 M4 Release date 2022/04/29

Proposed upcoming dot releases:

YP 3.3.4 build date 2021/11/01
YP 3.3.4 Release date 2021/11/12
YP 3.1.12 build date 2021/11/15
YP 3.1.12 Release date 2021/11/26
YP 3.4.1 build date 2021/11/22
YP 3.4.1 Release date 2021/12/03
YP 3.1.13 build date 2021/12/13
YP 3.1.13 Release date 2021/12/22
YP 3.1.14 build date 2022/01/24
YP 3.1.14 Release date 2022/02/04
YP 3.4.2 build date 2022/02/07
YP 3.4.2 Release date 2022/02/18
YP 3.1.15 build date 2022/03/14
YP 3.1.15 Release date 2022/03/25
YP 3.4.3 build date 2022/03/21
YP 3.4.3 Release date 2022/04/01
YP 3.1.16 build date 2022/04/25
YP 3.1.16 Release date 2022/05/06

Tracking Metrics:

WDD 2682 (last week 2687) (https://wiki.yoctoproject.org/charts/combo.html)
OE-Core/Poky Patch Metrics

Total patches found: 1318 (last week 1318)
Patches in the Pending State: 488 (37%) [last week 488 (37%)]

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!]

Re: meta-selinux: dunfell: libselinux: 0001-Fix-NULL-pointer-use-in-selinux_restorecon_set_sehandle.patch fails to apply

Jonas Brich

#55099

Hi,

yes college uploaded again. That is the correct patch.

Thanks


BMW Car IT GmbH
Jonas Brich
Spezialist Entwicklung
Lise-Meitner-Str. 14
89081 Ulm

Tel.:  +49 731 3780 4292
Mail: jonas.brich@...
Web: http://www.bmw-carit.de
----------------------------------------------------------------------
BMW Car IT GmbH
Geschaeftsfuehrer: Kai-Uwe Balszuweit und Michael Böttrich
Sitz und Registergericht: Muenchen HRB 134810
----------------------------------------------------------------------

________________________________________
From: Jason Andryuk <jandryuk@...>
Sent: Tuesday, October 19, 2021 3:51 PM
To: joe@...; Brich Jonas, JC-4; yocto@...; flihp@...; yi.zhao@...
Subject: meta-selinux: dunfell: libselinux: 0001-Fix-NULL-pointer-use-in-selinux_restorecon_set_sehandle.patch fails to apply

Hi,

libselinux in meta-selinux dunfell fails in do_patch.  Patch
0001-Fix-NULL-pointer-use-in-selinux_restorecon_set_sehandle.patch
fails to apply.  The patch in git has a leading a/b path component,
which throws off the strip level.  The posting here doesn't have the
a/b: https://lists.yoctoproject.org/g/yocto/message/55083 so it should
work.

Thanks,
Jason

[meta-parsec][v2][PATCH] meta-parsec/README: remove rust layer req.

Armin Kuster

#55098

Rust is now in core. No need to include the layer referenece.

Drop Priority and ref from repo definition. Not used

Signed-off-by: Armin Kuster <akuster808@...>

[v2]
fixup mailing list
---
 meta-parsec/README.md | 16 ++--------------
 1 file changed, 2 insertions(+), 14 deletions(-)

diff --git a/meta-parsec/README.md b/meta-parsec/README.md
index 24958ac..aeb48a6 100644
--- a/meta-parsec/README.md
+++ b/meta-parsec/README.md
@@ -11,23 +11,12 @@ This layer depends on:
 
     URI: git://git.openembedded.org/meta-openembedded
     branch: master
-    revision: HEAD
-    prio: default
 
     URI git://git.yoctoproject.org/meta-security
     branch: master
-    revision: HEAD
-    prio: default
-
-    URI https://github.com/meta-rust/meta-rust.git
-    branch: master
-    revision: HEAD
-    prio: default
 
     URI https://github.com/kraj/meta-clang.git
     branch: master
-    revision: HEAD
-    prio: default
 
 Adding the meta-parsec layer to your build
 ==========================================
@@ -44,7 +33,6 @@ other layers needed. e.g.:
       /path/to/yocto/meta-yocto-bsp \
       /path/to/meta-openembedded/meta-oe \
       /path/to/meta-openembedded/meta-python \
-      /path/to/meta-rust \
       /path/to/meta-clang \
       /path/to/meta-security/meta-tpm \
       /path/to/meta-security/meta-parsec \
@@ -165,11 +153,11 @@ Maintenance
 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-parsec][PATCH'
+'git send-email -1 --to yocto@... --subject-prefix=meta-parsec][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-parsec][PATCH
 
 Now you can just do 'git send-email origin/master' to send all local patches.
-- 
2.25.1

[meta-parsec][PATCH] meta-parsec/README: remove rust layer req.

Armin Kuster

#55097

Rust is now in core. No need to include the layer referenece.

Drop Priority and ref from repo definition. Not used

Signed-off-by: Armin Kuster <akuster808@...>
---
 meta-parsec/README.md | 12 ------------
 1 file changed, 12 deletions(-)

diff --git a/meta-parsec/README.md b/meta-parsec/README.md
index 24958ac..84cf4a6 100644
--- a/meta-parsec/README.md
+++ b/meta-parsec/README.md
@@ -11,23 +11,12 @@ This layer depends on:
 
     URI: git://git.openembedded.org/meta-openembedded
     branch: master
-    revision: HEAD
-    prio: default
 
     URI git://git.yoctoproject.org/meta-security
     branch: master
-    revision: HEAD
-    prio: default
-
-    URI https://github.com/meta-rust/meta-rust.git
-    branch: master
-    revision: HEAD
-    prio: default
 
     URI https://github.com/kraj/meta-clang.git
     branch: master
-    revision: HEAD
-    prio: default
 
 Adding the meta-parsec layer to your build
 ==========================================
@@ -44,7 +33,6 @@ other layers needed. e.g.:
       /path/to/yocto/meta-yocto-bsp \
       /path/to/meta-openembedded/meta-oe \
       /path/to/meta-openembedded/meta-python \
-      /path/to/meta-rust \
       /path/to/meta-clang \
       /path/to/meta-security/meta-tpm \
       /path/to/meta-security/meta-parsec \
-- 
2.25.1

Re: [meta-cgl][PATCH] libsocket6-perl: inherit autotools-brokensep

Jeremy Puhlman

#55096

Merged, thanks.

Show quoted text

On 10/14/2021 11:04 PM, Yi Zhao wrote:
Inherit autotools-brokensep to fix the build error which is introduced
by oe-commit:
   commit 8e26252b45b7660c7c67c702411bdec187a76ffc
   Author: Richard Purdie <richard.purdie@...>
   Date:   Sun Sep 19 16:17:31 2021 +0100

     layer.conf: Extend recipes not to install without explict dependencies

Fixes:
libsocket6-perl/0.29-r2/temp/run.do_configure.27951: autoreconf: not found
libsocket6-perl/0.29-r2/temp/run.do_configure.27951: oefatal: not found

Signed-off-by: Yi Zhao <yi.zhao@...>
---
  meta-cgl-common/recipes-perl/perl/libsocket6-perl_0.29.bb | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-cgl-common/recipes-perl/perl/libsocket6-perl_0.29.bb b/meta-cgl-common/recipes-perl/perl/libsocket6-perl_0.29.bb
index bbeab8e..9f38380 100644
--- a/meta-cgl-common/recipes-perl/perl/libsocket6-perl_0.29.bb
+++ b/meta-cgl-common/recipes-perl/perl/libsocket6-perl_0.29.bb
@@ -23,4 +23,4 @@ do_configure:prepend () {
  	sed -i 's:\./configure\(.[^-]\):./configure --build=${BUILD_SYS} --host=${HOST_SYS} --target=${TARGET_SYS} --prefix=${prefix} --exec_prefix=${exec_prefix} --bindir=${bindir} --sbindir=${sbindir} --libexecdir=${libexecdir} --datadir=${datadir} --sysconfdir=${sysconfdir} --sharedstatedir=${sharedstatedir} --localstatedir=${localstatedir} --libdir=${libdir} --includedir=${includedir} --oldincludedir=${oldincludedir} --infodir=${infodir} --mandir=${mandir}\1:' Makefile.PL
  }
  -inherit cpan
+inherit autotools-brokensep cpan

Enhancements/Bugs closed WW42!

Stephen Jolley

#55095

All,

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

Who	Count
richard.purdie@...	5
randy.macleod@...	3
alex.kanavin@...	2
thomas.perrot@...	1
david.reyna@...	1
rgauthier@...	1
mhalstead@...	1
alexandre.belloni@...	1
Grand Total	15

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

Stephen Jolley

#55094

All,

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

Who	Count
michael.opdenacker@...	40
ross@...	36
david.reyna@...	22
bruce.ashfield@...	19
randy.macleod@...	17
trevor.gamblin@...	16
JPEWhacker@...	13
timothy.t.orling@...	13
sakib.sajal@...	11
richard.purdie@...	8
kai.kang@...	7
bluelightning@...	6
Qi.Chen@...	5
kiran.surendran@...	5
mhalstead@...	5
hongxu.jia@...	4
saul.wold@...	3
jon.mason@...	3
akuster808@...	3
chee.yang.lee@...	3
mshah@...	2
pgowda.cve@...	2
mingli.yu@...	2
alejandro@...	2
vinay.m.engg@...	1
diego.sueiro@...	1
john.kaldas.enpj@...	1
ydirson@...	1
douglas.royds@...	1
mark.hatle@...	1
Ahmed.Hossam@...	1
sangeeta.jain@...	1
devendra.tewari@...	1
mostthingsweb@...	1
thomas.perrot@...	1
pokylinux@...	1
paul@...	1
elberger@...	1
Martin.Jansa@...	1
kergoth@...	1
TicoTimo@...	1
anuj.mittal@...	1
alexandre.belloni@...	1
raj.khem@...	1
limon.anibal@...	1
jaewon@...	1
yf3yu@...	1
jeanmarie.lemetayer@...	1
tony.tascioglu@...	1
aehs29@...	1
weaverjs@...	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

#55093

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 397 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.4”, “3.5, "3.99" and "Future", the more pressing/urgent issues being in "3.4" and then “3.5”.

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

How to add Network Manager plug-in in my xfce-desktop based image for Rpi4 #cm3 #bitbake

@prashant2314

#55092

Dear Team,
I've built a desktop based image for Rpi4, now I need to configure the network from front end not via terminal access, so for this I'm not getting solution,
please assist me if some one have any suggestion on the same.

Thanks is advance,

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

Teoh, Jay Shen

#55091

Hi All,

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

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

No new issue found.


Thanks,
Jay

Show quoted text

-----Original Message-----
From: qa-build-notification@... <qa-build-
notification@...> On Behalf Of Richard Purdie
Sent: Tuesday, 12 October, 2021 1:25 AM
To: yocto@...
Cc: qa-build-notification <qa-build-notification@...>
Subject: [qa-build-notification] QA notification for completed autobuilder build
(yocto-3.4.rc1)

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


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


Build hash information:

bitbake: c78ebac71ec976fdf27ea24767057882870f5c60
meta-agl: 228ecc1dec390138c44299d1c244acda9ad75ce1
meta-arm: 98193f3b6167e07cbb794e96b80d78ca1779ea4f
meta-aws: 27bca81c4d3f0138fda583f9ea98df6152332333
meta-gplv2: f04e4369bf9dd3385165281b9fa2ed1043b0e400
meta-intel: 90170cf85fe35b4e8dc00eee50053c0205276b63
meta-mingw: f5d761cbd5c957e4405c5d40b0c236d263c916a8
meta-openembedded: f2152d79043601eacb70da1a3ab36f5ac56f3e28
oecore: bb1dea6806f084364b6017db2567f438e805aef0
poky: f6d1126fff213460dc6954a5d5fc168606d76b66



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

Re: [PATCH v2 1/1] sssd: re-package to fix QA issues

kai

#55090

On 10/14/21 4:59 PM, kai wrote:

From: Kai Kang <kai.kang@...>

It packages all file in ${libdir} to package sssd, including the .so
symlink files. Then it causes QA issues:

| ERROR: QA Issue: sssd rdepends on dbus-dev [dev-deps]
| ERROR: QA Issue: sssd rdepends on ding-libs-dev [dev-deps]

So re-package sssd then the .so symlink files and .pc files are packaged
to sssd-dev which should be.

File ${libdir}/libsss_sudo.so is not a symlink file but packaged to
sssd-dev too. Then causes another QA issue:

| ERROR: sssd-2.5.2-r0 do_package_qa: QA Issue:
    -dev package sssd-dev contains non-symlink .so '/usr/lib/libsss_sudo.so' [dev-elf]

So create a new sub-package libsss-sudo to package file libsss_sudo.so
and make sssd rdepends on it.

Hi Armin,

Ping in case you may miss it.

Regards,
Kai


Signed-off-by: Kai Kang <kai.kang@...>
---
 recipes-security/sssd/sssd_2.5.2.bb | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/recipes-security/sssd/sssd_2.5.2.bb b/recipes-security/sssd/sssd_2.5.2.bb
index 76d6e03..ed8af5e 100644
--- a/recipes-security/sssd/sssd_2.5.2.bb
+++ b/recipes-security/sssd/sssd_2.5.2.bb
@@ -125,10 +125,14 @@ SYSTEMD_SERVICE:${PN} = " \
 "
 SYSTEMD_AUTO_ENABLE = "disable"
 
-FILES:${PN} += "${libdir} ${datadir} ${base_libdir}/security/pam_sss*.so"
-FILES:${PN}-dev = " ${includedir}/* ${libdir}/*la ${libdir}/*/*la"
+PACKAGES =+ "libsss-sudo"
+ALLOW_EMPTY:libsss-sudo = "1"
 
-# The package contains symlinks that trip up insane
-INSANE_SKIP:${PN} = "dev-so"
+FILES:${PN} += "${base_libdir}/security/pam_sss*.so  \
+                ${datadir}/dbus-1/system-services/*.service \
+                ${libdir}/krb5/* \
+                ${libdir}/ldb/* \
+                "
+FILES:libsss-sudo = "${libdir}/libsss_sudo.so"
 
-RDEPENDS:${PN} = "bind bind-utils dbus libldb libpam"
+RDEPENDS:${PN} = "bind bind-utils dbus libldb libpam libsss-sudo"

-- 
Kai Kang
Wind River Linux

Re: SRC_URI Directory Change

Chuck Wolber

#55089

On Fri, Oct 15, 2021 at 6:58 AM Richard Purdie <richard.purdie@...> wrote:

I have a bit of a horrible idea to do this in master-next which does solve the
problem. We probably need a new bitbake selftest testcase before I could think
about merging it though.

I tested the patch you posted on IRC against bitbake 1.50.0. It seems to work

quite well, but I think I found two minor bugs in it. I pasted an updated patch below.

In a nutshell...

If you have a SRC_URI file:// entry that ends in a "/", then you get a "." that is

not enclosed in "/./" when running the checksum_dir method, which causes

checksum_file to throw warnings that look like this:

WARNING: Unable to get checksum for gettext-minimal-native SRC_URI entry .intlmacosx.m4: [Errno 2] No such file or directory: '/mnt/openembedded-core/meta/recipes-core/gettext/gettext-minimal-0.21/aclocal/.intlmacosx.m4'

I think the simplest fix is to add a "pth = pth.rstrip("/")" in the checksum_dir method after

the guard statement. But then that exposes a different issue in the patch.

For recipes that trigger the above warning, the rstrip() fix fixes the warning, but then you

expose a new problem in siggen.py calc_taskhash().

In your patched version, the check for the "/" fails to include the filename in the hash calculation

for files at the root of a SRC_URI entry (there is no "/" to be found). This results in a task hash

mismatch error on the first build, but not on subsequent builds for fairly obvious reasons.

I solved this by adding a third field to the tuple with a True/False value, which is a much more reliable semaphore (IMHO).

I tested these fixes and it worked perfectly. Here is an updated version of your patch that takes into

account the fixes I described. I can produce a "patch against your patch" if these fixes are

considered correct and do not cause even bigger problems that are not obvious to me.

diff --git a/bitbake/lib/bb/checksum.py b/bitbake/lib/bb/checksum.py
index 1d50a26426..fb8a77f6ab 100644
--- a/bitbake/lib/bb/checksum.py
+++ b/bitbake/lib/bb/checksum.py
@@ -50,6 +50,7 @@ class FileChecksumCache(MultiProcessCache):
         MultiProcessCache.__init__(self)
 
     def get_checksum(self, f):
+        f = os.path.normpath(f)
         entry = self.cachedata[0].get(f)
         cmtime = self.mtime_cache.cached_mtime(f)
         if entry:
@@ -84,15 +85,24 @@ class FileChecksumCache(MultiProcessCache):
                 return None
             return checksum
 
+        #
+        # Changing the format of file-checksums is problematic as both OE and Bitbake have
+        # knowledge of them. We need to encode a new piece of data, the portion of the path
+        # we care about from a checksum perspective. This means that files that change subdirectory
+        # are tracked by the task hashes. To do this, we do something horrible and put a "/./" into
+        # the path. The filesystem handles it but it gives us a marker to know which subsection
+        # of the path to cache.
+        #
         def checksum_dir(pth):
             # Handle directories recursively
             if pth == "/":
                 bb.fatal("Refusing to checksum /")
+            pth = pth.rstrip("/")
             dirchecksums = []
             for root, dirs, files in os.walk(pth, topdown=True):
                 [dirs.remove(d) for d in list(dirs) if d in localdirsexclude]
                 for name in files:
-                    fullpth = os.path.join(root, name)
+                    fullpth = os.path.join(root, name).replace(pth, os.path.join(pth, "."))
                     checksum = checksum_file(fullpth)
                     if checksum:
                         dirchecksums.append((fullpth, checksum))
diff --git a/bitbake/lib/bb/siggen.py b/bitbake/lib/bb/siggen.py
index 0d88c6ec68..f649f39ced 100644
--- a/bitbake/lib/bb/siggen.py
+++ b/bitbake/lib/bb/siggen.py
@@ -308,13 +308,14 @@ class SignatureGeneratorBasic(SignatureGenerator):
         return
 
     def get_taskhash(self, tid, deps, dataCaches):
-
         data = self.basehash[tid]
         for dep in self.runtaskdeps[tid]:
             data = data + self.get_unihash(dep)
 
         for (f, cs) in self.file_checksum_values[tid]:
             if cs:
+                if "/./" in f:
+                    data = data + f.split("/./")[1]
                 data = data + cs
 
         if tid in self.taints:
@@ -372,7 +373,12 @@ class SignatureGeneratorBasic(SignatureGenerator):
 
         if runtime and tid in self.taskhash:
             data['runtaskdeps'] = self.runtaskdeps[tid]
-            data['file_checksum_values'] = [(os.path.basename(f), cs) for f,cs in self.file_checksum_values[tid]]
+            data['file_checksum_values'] = []
+            for f,cs in self.file_checksum_values[tid]:
+                if "/./" in f:
+                    data['file_checksum_values'].append((f.split("/./")[1], cs, True))
+                else:
+                    data['file_checksum_values'].append((os.path.basename(f), cs, False))
             data['runtaskhashes'] = {}
             for dep in data['runtaskdeps']:
                 data['runtaskhashes'][dep] = self.get_unihash(dep)
@@ -1017,6 +1023,8 @@ def calc_taskhash(sigdata):
 
     for c in sigdata['file_checksum_values']:
         if c[1]:
+            if c[2]:
+                data = data + c[0]
             data = data + c[1]
 
     if 'taint' in sigdata:

..Ch:W..

P.S. The gettext-minimal-native_0.21.bb (from OEC) is a very good example of something that triggers this behavior. But I found plenty of others as well.

--

"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire

Re: How to enable graphics acceleration on qemux86-64?

Alexander Kanavin

#55088

On Sat, 16 Oct 2021 at 14:08, Manuel Wagesreither <ManWag@...> wrote:

Here are some updates:

Building core-image-weston on hardknott succeeded. Couldn't `runqmu kvm slirp sdl core-image-weston` first because I got an error message about 'dri.pc' being missing. Debian package search told me it's part of 'mesa-commond-dev', so I installed it on my host machine and indeed, that runqemu command above got working again. Not just that, now even OpenGL acceleration with `runqmu kvm slirp sdl gl core-image-weston` worked, altough I didn't change anything OpenGL-wise. core-image-weston feels really snappy now. Great!

I got curious and reverted back to dunfell to check if the now-installed dri.pc made a difference, but no, it didn't. `runqemu` with `sdl` started (like it did before), and with `sdl gl` it still said "OpenGL support is disabled".

You need to replicate the settings from oe-selftest (link provided previously). I think on dunfell it's not enabled out of the box, and needs to be configured explicitly.

http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/lib/oeqa/selftest/cases/runtime_test.py?h=dunfell#n167

Ok, so then I moved on to get my own image which is on hardknott now working.

I `runqemu`d my image with 'sdl' and 'gl' and it started up fine. Weston did no longer start automatically so I did manually. Ran `DISPLAY=:0 glxgears` but it told me "couldn't open display :0". Installed 'weston-xwayland' so I'd get "/usr/lib/libweston-9/xwayland.so" but that didn't change anything.

Can't yet say if `DISPLAY=:0 glxgears` works on core-image-weston as it's still building.

DISPLAY is a setting for the host, so qemu can display the sdl or gtk window. On the qemu guest you need to get weston to start first.

Alex

Re: How to enable graphics acceleration on qemux86-64?

Manuel Wagesreither

#55087

Am Mi, 13. Okt 2021, um 22:56, schrieb Alexander Kanavin:

If you switch to master, it's best if you make a new build directory and dont reuse the one you have.

Alex

On Wed, 13 Oct 2021 at 22:09, Manuel Wagesreither <ManWag@...> wrote:

`export DISPLAY=:0` did the trick.

The following shows when still on poky dunfell:

* I can now boot `runqmu kvm slirp sdl core-image-weston`. But gui is still slow. I cannot even type `systemctl poweroff` in weston-terminal, it inevitably becomes `wweesssttooo[...]`.
* `runqemu kvm slirp sdl gl core-image-weston` still fails with `Failed to run qemu: qemu-system-x86_64: OpenGL support is disabled`.

Updated to current poky master, but got this: `ERROR: ParseError in configuration INHERITs: Could not inherit file classes/image-mklibs.bbclass`.

Switched to hardknott-3.3.3 which is four weeks old and perhaps a little riper. It's currently building.

Regards,
Manuel

Here are some updates:

Building core-image-weston on hardknott succeeded. Couldn't `runqmu kvm slirp sdl core-image-weston` first because I got an error message about 'dri.pc' being missing. Debian package search told me it's part of 'mesa-commond-dev', so I installed it on my host machine and indeed, that runqemu command above got working again. Not just that, now even OpenGL acceleration with `runqmu kvm slirp sdl gl core-image-weston` worked, altough I didn't change anything OpenGL-wise. core-image-weston feels really snappy now. Great!

I got curious and reverted back to dunfell to check if the now-installed dri.pc made a difference, but no, it didn't. `runqemu` with `sdl` started (like it did before), and with `sdl gl` it still said "OpenGL support is disabled".

Ok, so then I moved on to get my own image which is on hardknott now working.

I `runqemu`d my image with 'sdl' and 'gl' and it started up fine. Weston did no longer start automatically so I did manually. Ran `DISPLAY=:0 glxgears` but it told me "couldn't open display :0". Installed 'weston-xwayland' so I'd get "/usr/lib/libweston-9/xwayland.so" but that didn't change anything.

Can't yet say if `DISPLAY=:0 glxgears` works on core-image-weston as it's still building.

Regards, Manuel

Dunfell: problem with kernel-module install and libkmod.so

Patrick Boettcher

#55086

Hi list,

I'm facing an issue with a BSP I created using dunfell (up-to-date on
poky and oe). I'm using a stable kernel and u-boot 2021.07 from denx's
mainline-stable-layer.

I stripped down my machine.conf and basically the boot is working fine.
Was working fine.

When finally I created a functional defconfig (one which didn't strip
down the kernel next to nothing - thanks to KCONFIG_MODE="alldefconfig"
). I started to create fragments to remove unused parts.

The very first fragment I created was leading to rootfs which crashed
at the moment when /sbin/init was invoked, with the strangest errors
I've ever seen:

  /sbin/init: error while loading shared libraries: libkmod.so.2:
  cannot open shared object file: No such file or directory

Of course libkmod.so.2 (and its target) is present.

Then I realized that no modules where installed in the rootfs. (modules
are there if I don't have the fragment)

So I added kernel-modules to IMAGE_INSTALL:append .

The modules appeared, but the panic still occurred.

What can I do to understand what's going on? I diff'ed the rootfs, the
only difference I could was in ldconfig's aux-cache.

Thanks for any help in advance,
--
Patrick.

Re: SRC_URI Directory Change

Richard Purdie

#55085

On Fri, 2021-10-15 at 03:03 -0700, Chuck Wolber wrote:
Is there a recommended strategy to get do_fetch to invalidate on directory
path changes in paths pointed to by file:// URLs in SRC_URI?

Example:

SRC_URI += "file://src;subdir=${S}"

A file at src/foo/bar/baz is recognized just fine. But then a directory change
to something like src/foo/bar2/baz is not recognized and does not invalidate
any tasks in subsequent builds.

Use case is a recipe that has a fair bit of metadata that is not even remotely
amenable to the typical flat layout expected of a set of patches.

..Ch:W..

P.S. I attempted to do this with an event handler that was run when
bb.event.RecipePreFinalise is is fired. It would compare directory trees and
set do_fetch[nostamp] = "1" to invalidate the fetcher task. But I got really
spotty behavior. It seems like event handlers are cached like tasks.I can see why this breaks and it isn't entirely straightforward to fix since
we'd have to add data to the file-checksums entries which are generated by both
OE and Bitbake.

I have a bit of a horrible idea to do this in master-next which does solve the
problem. We probably need a new bitbake selftest testcase before I could think
about merging it though.

Cheers,

Richard

[PATCH][meta-selinux][dunfell] MAINTAINERS: update email address

Mikko Rapeli

#55084

From: Armin Kuster <akuster808@...>

Include example send-email

Signed-off-by: Armin Kuster <akuster808@...>
Signed-off-by: Joe MacDonald <joe@...>
(cherry picked from commit 48038b45dc114592991c069eb66d174820c0701d)
---
 MAINTAINERS | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 36c451f..0dc492e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1,7 +1,14 @@
 This file contains a list of maintainers for the meta-selinux layer.
 
 Please submit any patches against meta-selinux to the Yocto Project mailing
-list (yocto@...).
+list (yocto@...).
+
+git send-email -1 --to yocto@... --subject-prefix=meta-selinux][PATCH
+
+These values can be set as defaults for this repository:
+
+$ git config sendemail.to yocto@...
+$ git config format.subjectPrefix meta-selinux][PATCH
 
 You may also contact the maintainers directly.
 
-- 
2.20.1