Date   

[PATCH yocto-autobuilder-helper] janitor: Add the systemd unit file used on the autobuilder

Michael Halstead
 

Signed-off-by: Michael Halstead <mhalstead@linuxfoundation.org>
---
janitor/ab-janitor.service | 14 ++++++++++++++
1 file changed, 14 insertions(+)
create mode 100644 janitor/ab-janitor.service

diff --git a/janitor/ab-janitor.service b/janitor/ab-janitor.service
new file mode 100644
index 0000000..5e834af
--- /dev/null
+++ b/janitor/ab-janitor.service
@@ -0,0 +1,14 @@
+# /etc/systemd/system/ab-janitor.service
+[Unit]
+Description=Autobuilder Janitor Service
+After=network-online.target
+Wants=network-online.target
+
+[Service]
+User=pokybuild
+WorkingDirectory=/home/pokybuild
+Type=simple
+ExecStart=/usr/bin/python3 /home/pokybuild/yocto-autobuilder-helper/janitor/ab-janitor
+
+[Install]
+WantedBy=multi-user.target
--
2.26.2


Re: #yocto #sdk - meta-clang undefined references #sdk #yocto

Monsees, Steven C (US)
 

Yes, I did this... I am currently down to 1 issue:


/ede/smonsees/yocto/test/beignet-Release_v1.3/backend/src/llvm/llvm_to_gen.cpp: In function ‘bool gbe::llvmToGen(gbe::ir::Unit&, const void*, int, bool, int, std::__cxx11::string&)’:
/ede/smonsees/yocto/test/beignet-Release_v1.3/backend/src/llvm/llvm_to_gen.cpp:325:68: error: no matching function for call to ‘llvm::LLVMContext::setDiagnosticHandler(void (*)(const llvm::DiagnosticInfo&, void*), gbe::gbeDiagnosticContext*)’
mod.getContext().setDiagnosticHandler(&gbeDiagnosticHandler,&dc);
^
In file included from /opt/limws/2.4.1/sysroots/llvm-clang/include/llvm/IR/Metadata.h:30:0,
from /opt/limws/2.4.1/sysroots/llvm-clang/include/llvm/IR/TrackingMDRef.h:17,
from /opt/limws/2.4.1/sysroots/llvm-clang/include/llvm/IR/DebugLoc.h:18,
from /opt/limws/2.4.1/sysroots/llvm-clang/include/llvm/IR/Instruction.h:22,
from /opt/limws/2.4.1/sysroots/llvm-clang/include/llvm/IR/BasicBlock.h:23,
from /ede/smonsees/yocto/test/beignet-Release_v1.3/backend/src/llvm/llvm_includes.hpp:30,
from /ede/smonsees/yocto/test/beignet-Release_v1.3/backend/src/llvm/llvm_to_gen.cpp:25:
/opt/limws/2.4.1/sysroots/llvm-clang/include/llvm/IR/LLVMContext.h:213:8: note: candidate: void llvm::LLVMContext::setDiagnosticHandler(std::unique_ptr<llvm::DiagnosticHandler>&&, bool)
void setDiagnosticHandler(std::unique_ptr<DiagnosticHandler> &&DH,
^~~~~~~~~~~~~~~~~~~~
/opt/limws/2.4.1/sysroots/llvm-clang/include/llvm/IR/LLVMContext.h:213:8: note: no known conversion for argument 1 from ‘void (*)(const llvm::DiagnosticInfo&, void*)’ to ‘std::unique_ptr<llvm::DiagnosticHandler>&&’
make[2]: *** [backend/src/CMakeFiles/gbe.dir/llvm/llvm_to_gen.cpp.o] Error 1
make[1]: *** [backend/src/CMakeFiles/gbe.dir/all] Error 2
make: *** [all] Error 2
11:27 smonsees@yix490016 ~/yocto/test/beignet-Release_v1.3/mybuild>

-----Original Message-----
From: Khem Raj [mailto:raj.khem@gmail.com]
Sent: Wednesday, September 16, 2020 12:32 PM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com>
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto #sdk - meta-clang undefined references

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.


that means your link step is not linking libclang properly into your app, perhaps change the order so -lclang appears last

On Wed, Sep 16, 2020 at 4:06 AM Monsees, Steven C (US) <steven.monsees@baesystems.com> wrote:



It should be linking in libclang , I will validate...

Note performing 'nm' on libclang appear to show the majority present...

Question: if I needed to include a library, what/how would I modify a recipe under Yocto to be sure to include/link in the library ?

Thanks,
Steve

-----Original Message-----
From: Khem Raj [mailto:raj.khem@gmail.com]
Sent: Tuesday, September 15, 2020 5:06 PM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com>
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto #sdk - meta-clang undefined references

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.


On Tue, Sep 15, 2020 at 12:56 PM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@lists.yoctoproject.org> wrote:



I am building meta-clang (sumo based 6.0.1), with cmake (3.8.2), all
under a standard SDK “rocko based” (2.4.1)…



Are the following routines accessible/supported under meta-clang ?



libgbe.so: undefined reference to `clang::DiagnosticIDs::~DiagnosticIDs()'

libgbe.so: undefined reference to `clang::TextDiagnosticPrinter::TextDiagnosticPrinter(llvm::raw_ostream&, clang::DiagnosticOptions*, bool)'

libgbe.so: undefined reference to `clang::DiagnosticsEngine::~DiagnosticsEngine()'

libgbe.so: undefined reference to `clang::CompilerInvocation::CreateFromArgs(clang::CompilerInvocation&, char const* const*, char const* const*, clang::DiagnosticsEngine&)'

libgbe.so: undefined reference to `clang::CompilerInvocationBase::~CompilerInvocationBase()'

libgbe.so: undefined reference to `clang::PCHContainerOperations::PCHContainerOperations()'

libgbe.so: undefined reference to `clang::CompilerInstance::createDiagnostics(clang::DiagnosticConsumer*, bool)'

libgbe.so: undefined reference to `clang::DiagnosticsEngine::DiagnosticsEngine(llvm::IntrusiveRefCntPtr<clang::DiagnosticIDs>, clang::DiagnosticOptions*, clang::DiagnosticConsumer*, bool)'

libgbe.so: undefined reference to `clang::CodeGenOptions::CodeGenOptions()'

libgbe.so: undefined reference to `clang::CompilerInstance::~CompilerInstance()'

libgbe.so: undefined reference to `clang::CompilerInstance::CompilerInstance(std::shared_ptr<clang::PCHContainerOperations>, clang::MemoryBufferCache*)'

libgbe.so: undefined reference to `clang::EmitLLVMOnlyAction::EmitLLVMOnlyAction(llvm::LLVMContext*)'

libgbe.so: undefined reference to `clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)'

libgbe.so: undefined reference to `clang::CompilerInvocationBase::CompilerInvocationBase()'

libgbe.so: undefined reference to `clang::CompilerInstance::setInvocation(std::shared_ptr<clang::CompilerInvocation>)'

libgbe.so: undefined reference to `clang::CodeGenAction::takeModule()'

libgbe.so: undefined reference to `clang::DiagnosticIDs::DiagnosticIDs()'
are you linking this library with libclang ? secondly, also check that
its not emitting bunch of libraries which needs to then individually
linked



thanks,

Steve


Re: #yocto #sdk - meta-clang undefined references #sdk #yocto

Khem Raj
 

that means your link step is not linking libclang properly into your
app, perhaps change the order so -lclang appears last

On Wed, Sep 16, 2020 at 4:06 AM Monsees, Steven C (US)
<steven.monsees@baesystems.com> wrote:



It should be linking in libclang , I will validate...

Note performing 'nm' on libclang appear to show the majority present...

Question: if I needed to include a library, what/how would I modify a recipe under Yocto to be sure to include/link in the library ?

Thanks,
Steve

-----Original Message-----
From: Khem Raj [mailto:raj.khem@gmail.com]
Sent: Tuesday, September 15, 2020 5:06 PM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com>
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto #sdk - meta-clang undefined references

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.


On Tue, Sep 15, 2020 at 12:56 PM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@lists.yoctoproject.org> wrote:



I am building meta-clang (sumo based 6.0.1), with cmake (3.8.2), all
under a standard SDK “rocko based” (2.4.1)…



Are the following routines accessible/supported under meta-clang ?



libgbe.so: undefined reference to `clang::DiagnosticIDs::~DiagnosticIDs()'

libgbe.so: undefined reference to `clang::TextDiagnosticPrinter::TextDiagnosticPrinter(llvm::raw_ostream&, clang::DiagnosticOptions*, bool)'

libgbe.so: undefined reference to `clang::DiagnosticsEngine::~DiagnosticsEngine()'

libgbe.so: undefined reference to `clang::CompilerInvocation::CreateFromArgs(clang::CompilerInvocation&, char const* const*, char const* const*, clang::DiagnosticsEngine&)'

libgbe.so: undefined reference to `clang::CompilerInvocationBase::~CompilerInvocationBase()'

libgbe.so: undefined reference to `clang::PCHContainerOperations::PCHContainerOperations()'

libgbe.so: undefined reference to `clang::CompilerInstance::createDiagnostics(clang::DiagnosticConsumer*, bool)'

libgbe.so: undefined reference to `clang::DiagnosticsEngine::DiagnosticsEngine(llvm::IntrusiveRefCntPtr<clang::DiagnosticIDs>, clang::DiagnosticOptions*, clang::DiagnosticConsumer*, bool)'

libgbe.so: undefined reference to `clang::CodeGenOptions::CodeGenOptions()'

libgbe.so: undefined reference to `clang::CompilerInstance::~CompilerInstance()'

libgbe.so: undefined reference to `clang::CompilerInstance::CompilerInstance(std::shared_ptr<clang::PCHContainerOperations>, clang::MemoryBufferCache*)'

libgbe.so: undefined reference to `clang::EmitLLVMOnlyAction::EmitLLVMOnlyAction(llvm::LLVMContext*)'

libgbe.so: undefined reference to `clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)'

libgbe.so: undefined reference to `clang::CompilerInvocationBase::CompilerInvocationBase()'

libgbe.so: undefined reference to `clang::CompilerInstance::setInvocation(std::shared_ptr<clang::CompilerInvocation>)'

libgbe.so: undefined reference to `clang::CodeGenAction::takeModule()'

libgbe.so: undefined reference to `clang::DiagnosticIDs::DiagnosticIDs()'
are you linking this library with libclang ? secondly, also check that its not emitting bunch of libraries which needs to then individually linked



thanks,

Steve


Re: #yocto #sdk - meta-clang undefined references #sdk #yocto

Khem Raj
 

Can you inspect the clang libs for these symbols?

On Wed, Sep 16, 2020 at 7:04 AM Monsees, Steven C (US) via
lists.yoctoproject.org
<steven.monsees=baesystems.com@lists.yoctoproject.org> wrote:



I can see that libclang is being included...so, not sure why when linking an executable these references are missing...

-----Original Message-----
From: Monsees, Steven C (US)
Sent: Wednesday, September 16, 2020 7:06 AM
To: 'Khem Raj' <raj.khem@gmail.com>
Cc: yocto@lists.yoctoproject.org
Subject: RE: [yocto] #yocto #sdk - meta-clang undefined references



It should be linking in libclang , I will validate...

Note performing 'nm' on libclang appear to show the majority present...

Question: if I needed to include a library, what/how would I modify a recipe under Yocto to be sure to include/link in the library ?

Thanks,
Steve

-----Original Message-----
From: Khem Raj [mailto:raj.khem@gmail.com]
Sent: Tuesday, September 15, 2020 5:06 PM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com>
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto #sdk - meta-clang undefined references

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.


On Tue, Sep 15, 2020 at 12:56 PM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@lists.yoctoproject.org> wrote:



I am building meta-clang (sumo based 6.0.1), with cmake (3.8.2), all
under a standard SDK “rocko based” (2.4.1)…



Are the following routines accessible/supported under meta-clang ?



libgbe.so: undefined reference to `clang::DiagnosticIDs::~DiagnosticIDs()'

libgbe.so: undefined reference to `clang::TextDiagnosticPrinter::TextDiagnosticPrinter(llvm::raw_ostream&, clang::DiagnosticOptions*, bool)'

libgbe.so: undefined reference to `clang::DiagnosticsEngine::~DiagnosticsEngine()'

libgbe.so: undefined reference to `clang::CompilerInvocation::CreateFromArgs(clang::CompilerInvocation&, char const* const*, char const* const*, clang::DiagnosticsEngine&)'

libgbe.so: undefined reference to `clang::CompilerInvocationBase::~CompilerInvocationBase()'

libgbe.so: undefined reference to `clang::PCHContainerOperations::PCHContainerOperations()'

libgbe.so: undefined reference to `clang::CompilerInstance::createDiagnostics(clang::DiagnosticConsumer*, bool)'

libgbe.so: undefined reference to `clang::DiagnosticsEngine::DiagnosticsEngine(llvm::IntrusiveRefCntPtr<clang::DiagnosticIDs>, clang::DiagnosticOptions*, clang::DiagnosticConsumer*, bool)'

libgbe.so: undefined reference to `clang::CodeGenOptions::CodeGenOptions()'

libgbe.so: undefined reference to `clang::CompilerInstance::~CompilerInstance()'

libgbe.so: undefined reference to `clang::CompilerInstance::CompilerInstance(std::shared_ptr<clang::PCHContainerOperations>, clang::MemoryBufferCache*)'

libgbe.so: undefined reference to `clang::EmitLLVMOnlyAction::EmitLLVMOnlyAction(llvm::LLVMContext*)'

libgbe.so: undefined reference to `clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)'

libgbe.so: undefined reference to `clang::CompilerInvocationBase::CompilerInvocationBase()'

libgbe.so: undefined reference to `clang::CompilerInstance::setInvocation(std::shared_ptr<clang::CompilerInvocation>)'

libgbe.so: undefined reference to `clang::CodeGenAction::takeModule()'

libgbe.so: undefined reference to `clang::DiagnosticIDs::DiagnosticIDs()'
are you linking this library with libclang ? secondly, also check that its not emitting bunch of libraries which needs to then individually linked



thanks,

Steve



Re: #yocto #sdk - meta-clang undefined references #sdk #yocto

Monsees, Steven C (US)
 

Found a cmake issue and fixed almost all of it, down to 1 missing reference:


/ede/smonsees/yocto/test/beignet-Release_v1.3/backend/src/llvm/llvm_to_gen.cpp: In function ‘bool gbe::llvmToGen(gbe::ir::Unit&, const void*, int, bool, int, std::__cxx11::string&)’:
/ede/smonsees/yocto/test/beignet-Release_v1.3/backend/src/llvm/llvm_to_gen.cpp:325:68: error: no matching function for call to ‘llvm::LLVMContext::setDiagnosticHandler(void (*)(const llvm::DiagnosticInfo&, void*), gbe::gbeDiagnosticContext*)’
mod.getContext().setDiagnosticHandler(&gbeDiagnosticHandler,&dc);
^
In file included from /opt/limws/2.4.1/sysroots/llvm-clang/include/llvm/IR/Metadata.h:30:0,
from /opt/limws/2.4.1/sysroots/llvm-clang/include/llvm/IR/TrackingMDRef.h:17,
from /opt/limws/2.4.1/sysroots/llvm-clang/include/llvm/IR/DebugLoc.h:18,
from /opt/limws/2.4.1/sysroots/llvm-clang/include/llvm/IR/Instruction.h:22,
from /opt/limws/2.4.1/sysroots/llvm-clang/include/llvm/IR/BasicBlock.h:23,
from /ede/smonsees/yocto/test/beignet-Release_v1.3/backend/src/llvm/llvm_includes.hpp:30,
from /ede/smonsees/yocto/test/beignet-Release_v1.3/backend/src/llvm/llvm_to_gen.cpp:25:
/opt/limws/2.4.1/sysroots/llvm-clang/include/llvm/IR/LLVMContext.h:213:8: note: candidate: void llvm::LLVMContext::setDiagnosticHandler(std::unique_ptr<llvm::DiagnosticHandler>&&, bool)
void setDiagnosticHandler(std::unique_ptr<DiagnosticHandler> &&DH,
^~~~~~~~~~~~~~~~~~~~
/opt/limws/2.4.1/sysroots/llvm-clang/include/llvm/IR/LLVMContext.h:213:8: note: no known conversion for argument 1 from ‘void (*)(const llvm::DiagnosticInfo&, void*)’ to ‘std::unique_ptr<llvm::DiagnosticHandler>&&’
make[2]: *** [backend/src/CMakeFiles/gbe.dir/llvm/llvm_to_gen.cpp.o] Error 1
make[1]: *** [backend/src/CMakeFiles/gbe.dir/all] Error 2
make: *** [all] Error 2
11:27 smonsees@yix490016 ~/yocto/test/beignet-Release_v1.3/mybuild>

-----Original Message-----
From: yocto@lists.yoctoproject.org [mailto:yocto@lists.yoctoproject.org] On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Wednesday, September 16, 2020 10:05 AM
To: Khem Raj <raj.khem@gmail.com>
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto #sdk - meta-clang undefined references

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.



I can see that libclang is being included...so, not sure why when linking an executable these references are missing...

-----Original Message-----
From: Monsees, Steven C (US)
Sent: Wednesday, September 16, 2020 7:06 AM
To: 'Khem Raj' <raj.khem@gmail.com>
Cc: yocto@lists.yoctoproject.org
Subject: RE: [yocto] #yocto #sdk - meta-clang undefined references



It should be linking in libclang , I will validate...

Note performing 'nm' on libclang appear to show the majority present...

Question: if I needed to include a library, what/how would I modify a recipe under Yocto to be sure to include/link in the library ?

Thanks,
Steve

-----Original Message-----
From: Khem Raj [mailto:raj.khem@gmail.com]
Sent: Tuesday, September 15, 2020 5:06 PM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com>
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto #sdk - meta-clang undefined references

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.


On Tue, Sep 15, 2020 at 12:56 PM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@lists.yoctoproject.org> wrote:



I am building meta-clang (sumo based 6.0.1), with cmake (3.8.2), all
under a standard SDK “rocko based” (2.4.1)…



Are the following routines accessible/supported under meta-clang ?



libgbe.so: undefined reference to `clang::DiagnosticIDs::~DiagnosticIDs()'

libgbe.so: undefined reference to `clang::TextDiagnosticPrinter::TextDiagnosticPrinter(llvm::raw_ostream&, clang::DiagnosticOptions*, bool)'

libgbe.so: undefined reference to `clang::DiagnosticsEngine::~DiagnosticsEngine()'

libgbe.so: undefined reference to `clang::CompilerInvocation::CreateFromArgs(clang::CompilerInvocation&, char const* const*, char const* const*, clang::DiagnosticsEngine&)'

libgbe.so: undefined reference to `clang::CompilerInvocationBase::~CompilerInvocationBase()'

libgbe.so: undefined reference to `clang::PCHContainerOperations::PCHContainerOperations()'

libgbe.so: undefined reference to `clang::CompilerInstance::createDiagnostics(clang::DiagnosticConsumer*, bool)'

libgbe.so: undefined reference to `clang::DiagnosticsEngine::DiagnosticsEngine(llvm::IntrusiveRefCntPtr<clang::DiagnosticIDs>, clang::DiagnosticOptions*, clang::DiagnosticConsumer*, bool)'

libgbe.so: undefined reference to `clang::CodeGenOptions::CodeGenOptions()'

libgbe.so: undefined reference to `clang::CompilerInstance::~CompilerInstance()'

libgbe.so: undefined reference to `clang::CompilerInstance::CompilerInstance(std::shared_ptr<clang::PCHContainerOperations>, clang::MemoryBufferCache*)'

libgbe.so: undefined reference to `clang::EmitLLVMOnlyAction::EmitLLVMOnlyAction(llvm::LLVMContext*)'

libgbe.so: undefined reference to `clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)'

libgbe.so: undefined reference to `clang::CompilerInvocationBase::CompilerInvocationBase()'

libgbe.so: undefined reference to `clang::CompilerInstance::setInvocation(std::shared_ptr<clang::CompilerInvocation>)'

libgbe.so: undefined reference to `clang::CodeGenAction::takeModule()'

libgbe.so: undefined reference to `clang::DiagnosticIDs::DiagnosticIDs()'
are you linking this library with libclang ? secondly, also check that its not emitting bunch of libraries which needs to then individually linked



thanks,

Steve


Re: [meta-security][PATCH 2/2] apparmor: exclude mips, not supported

akuster
 

On 9/15/20 10:11 PM, Khem Raj wrote:
title says mips but it actually is for mips64 only it seems.
right. easy to fix when I commit. Have not built qemumip so its unknown
at this time.

-armin

On Tue, Sep 15, 2020 at 8:12 PM akuster <akuster808@gmail.com> wrote:
Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
recipes-mac/AppArmor/apparmor_2.13.4.bb | 2 ++
1 file changed, 2 insertions(+)

diff --git a/recipes-mac/AppArmor/apparmor_2.13.4.bb b/recipes-mac/AppArmor/apparmor_2.13.4.bb
index 552cac7..dcdc1f7 100644
--- a/recipes-mac/AppArmor/apparmor_2.13.4.bb
+++ b/recipes-mac/AppArmor/apparmor_2.13.4.bb
@@ -30,6 +30,8 @@ S = "${WORKDIR}/git"

PARALLEL_MAKE = ""

+COMPATIBLE_MACHINE_mips64 = "(!.*mips64).*"
+
inherit pkgconfig autotools-brokensep update-rc.d python3native perlnative ptest cpan manpages systemd features_check
REQUIRED_DISTRO_FEATURES = "apparmor"

--
2.17.1




Re: #yocto #sdk - meta-clang undefined references #sdk #yocto

Monsees, Steven C (US)
 

I can see that libclang is being included...so, not sure why when linking an executable these references are missing...

-----Original Message-----
From: Monsees, Steven C (US)
Sent: Wednesday, September 16, 2020 7:06 AM
To: 'Khem Raj' <raj.khem@gmail.com>
Cc: yocto@lists.yoctoproject.org
Subject: RE: [yocto] #yocto #sdk - meta-clang undefined references



It should be linking in libclang , I will validate...

Note performing 'nm' on libclang appear to show the majority present...

Question: if I needed to include a library, what/how would I modify a recipe under Yocto to be sure to include/link in the library ?

Thanks,
Steve

-----Original Message-----
From: Khem Raj [mailto:raj.khem@gmail.com]
Sent: Tuesday, September 15, 2020 5:06 PM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com>
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto #sdk - meta-clang undefined references

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.


On Tue, Sep 15, 2020 at 12:56 PM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@lists.yoctoproject.org> wrote:



I am building meta-clang (sumo based 6.0.1), with cmake (3.8.2), all
under a standard SDK “rocko based” (2.4.1)…



Are the following routines accessible/supported under meta-clang ?



libgbe.so: undefined reference to `clang::DiagnosticIDs::~DiagnosticIDs()'

libgbe.so: undefined reference to `clang::TextDiagnosticPrinter::TextDiagnosticPrinter(llvm::raw_ostream&, clang::DiagnosticOptions*, bool)'

libgbe.so: undefined reference to `clang::DiagnosticsEngine::~DiagnosticsEngine()'

libgbe.so: undefined reference to `clang::CompilerInvocation::CreateFromArgs(clang::CompilerInvocation&, char const* const*, char const* const*, clang::DiagnosticsEngine&)'

libgbe.so: undefined reference to `clang::CompilerInvocationBase::~CompilerInvocationBase()'

libgbe.so: undefined reference to `clang::PCHContainerOperations::PCHContainerOperations()'

libgbe.so: undefined reference to `clang::CompilerInstance::createDiagnostics(clang::DiagnosticConsumer*, bool)'

libgbe.so: undefined reference to `clang::DiagnosticsEngine::DiagnosticsEngine(llvm::IntrusiveRefCntPtr<clang::DiagnosticIDs>, clang::DiagnosticOptions*, clang::DiagnosticConsumer*, bool)'

libgbe.so: undefined reference to `clang::CodeGenOptions::CodeGenOptions()'

libgbe.so: undefined reference to `clang::CompilerInstance::~CompilerInstance()'

libgbe.so: undefined reference to `clang::CompilerInstance::CompilerInstance(std::shared_ptr<clang::PCHContainerOperations>, clang::MemoryBufferCache*)'

libgbe.so: undefined reference to `clang::EmitLLVMOnlyAction::EmitLLVMOnlyAction(llvm::LLVMContext*)'

libgbe.so: undefined reference to `clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)'

libgbe.so: undefined reference to `clang::CompilerInvocationBase::CompilerInvocationBase()'

libgbe.so: undefined reference to `clang::CompilerInstance::setInvocation(std::shared_ptr<clang::CompilerInvocation>)'

libgbe.so: undefined reference to `clang::CodeGenAction::takeModule()'

libgbe.so: undefined reference to `clang::DiagnosticIDs::DiagnosticIDs()'
are you linking this library with libclang ? secondly, also check that its not emitting bunch of libraries which needs to then individually linked



thanks,

Steve


Re: #yocto #sdk - meta-clang undefined references #sdk #yocto

Monsees, Steven C (US)
 

It should be linking in libclang , I will validate...

Note performing 'nm' on libclang appear to show the majority present...

Question: if I needed to include a library, what/how would I modify a recipe under Yocto to be sure to include/link in the library ?

Thanks,
Steve

-----Original Message-----
From: Khem Raj [mailto:raj.khem@gmail.com]
Sent: Tuesday, September 15, 2020 5:06 PM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com>
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto #sdk - meta-clang undefined references

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.


On Tue, Sep 15, 2020 at 12:56 PM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@lists.yoctoproject.org> wrote:



I am building meta-clang (sumo based 6.0.1), with cmake (3.8.2), all
under a standard SDK “rocko based” (2.4.1)…



Are the following routines accessible/supported under meta-clang ?



libgbe.so: undefined reference to `clang::DiagnosticIDs::~DiagnosticIDs()'

libgbe.so: undefined reference to `clang::TextDiagnosticPrinter::TextDiagnosticPrinter(llvm::raw_ostream&, clang::DiagnosticOptions*, bool)'

libgbe.so: undefined reference to `clang::DiagnosticsEngine::~DiagnosticsEngine()'

libgbe.so: undefined reference to `clang::CompilerInvocation::CreateFromArgs(clang::CompilerInvocation&, char const* const*, char const* const*, clang::DiagnosticsEngine&)'

libgbe.so: undefined reference to `clang::CompilerInvocationBase::~CompilerInvocationBase()'

libgbe.so: undefined reference to `clang::PCHContainerOperations::PCHContainerOperations()'

libgbe.so: undefined reference to `clang::CompilerInstance::createDiagnostics(clang::DiagnosticConsumer*, bool)'

libgbe.so: undefined reference to `clang::DiagnosticsEngine::DiagnosticsEngine(llvm::IntrusiveRefCntPtr<clang::DiagnosticIDs>, clang::DiagnosticOptions*, clang::DiagnosticConsumer*, bool)'

libgbe.so: undefined reference to `clang::CodeGenOptions::CodeGenOptions()'

libgbe.so: undefined reference to `clang::CompilerInstance::~CompilerInstance()'

libgbe.so: undefined reference to `clang::CompilerInstance::CompilerInstance(std::shared_ptr<clang::PCHContainerOperations>, clang::MemoryBufferCache*)'

libgbe.so: undefined reference to `clang::EmitLLVMOnlyAction::EmitLLVMOnlyAction(llvm::LLVMContext*)'

libgbe.so: undefined reference to `clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)'

libgbe.so: undefined reference to `clang::CompilerInvocationBase::CompilerInvocationBase()'

libgbe.so: undefined reference to `clang::CompilerInstance::setInvocation(std::shared_ptr<clang::CompilerInvocation>)'

libgbe.so: undefined reference to `clang::CodeGenAction::takeModule()'

libgbe.so: undefined reference to `clang::DiagnosticIDs::DiagnosticIDs()'
are you linking this library with libclang ? secondly, also check that its not emitting bunch of libraries which needs to then individually linked



thanks,

Steve


Re: [meta-security][PATCH 2/2] apparmor: exclude mips, not supported

Khem Raj
 

title says mips but it actually is for mips64 only it seems.

On Tue, Sep 15, 2020 at 8:12 PM akuster <akuster808@gmail.com> wrote:

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
recipes-mac/AppArmor/apparmor_2.13.4.bb | 2 ++
1 file changed, 2 insertions(+)

diff --git a/recipes-mac/AppArmor/apparmor_2.13.4.bb b/recipes-mac/AppArmor/apparmor_2.13.4.bb
index 552cac7..dcdc1f7 100644
--- a/recipes-mac/AppArmor/apparmor_2.13.4.bb
+++ b/recipes-mac/AppArmor/apparmor_2.13.4.bb
@@ -30,6 +30,8 @@ S = "${WORKDIR}/git"

PARALLEL_MAKE = ""

+COMPATIBLE_MACHINE_mips64 = "(!.*mips64).*"
+
inherit pkgconfig autotools-brokensep update-rc.d python3native perlnative ptest cpan manpages systemd features_check
REQUIRED_DISTRO_FEATURES = "apparmor"

--
2.17.1




[meta-security][PATCH 2/2] apparmor: exclude mips, not supported

akuster
 

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
recipes-mac/AppArmor/apparmor_2.13.4.bb | 2 ++
1 file changed, 2 insertions(+)

diff --git a/recipes-mac/AppArmor/apparmor_2.13.4.bb b/recipes-mac/AppArmor/apparmor_2.13.4.bb
index 552cac7..dcdc1f7 100644
--- a/recipes-mac/AppArmor/apparmor_2.13.4.bb
+++ b/recipes-mac/AppArmor/apparmor_2.13.4.bb
@@ -30,6 +30,8 @@ S = "${WORKDIR}/git"

PARALLEL_MAKE = ""

+COMPATIBLE_MACHINE_mips64 = "(!.*mips64).*"
+
inherit pkgconfig autotools-brokensep update-rc.d python3native perlnative ptest cpan manpages systemd features_check
REQUIRED_DISTRO_FEATURES = "apparmor"

--
2.17.1


[meta-security][PATCH 1/2] packagegroup-core-security: add more pkgs to base group

akuster
 

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
.../packagegroup/packagegroup-core-security.bb | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/recipes-core/packagegroup/packagegroup-core-security.bb b/recipes-core/packagegroup/packagegroup-core-security.bb
index 6aa0d6c..1d01800 100644
--- a/recipes-core/packagegroup/packagegroup-core-security.bb
+++ b/recipes-core/packagegroup/packagegroup-core-security.bb
@@ -9,6 +9,8 @@ PACKAGES = "\
packagegroup-core-security \
packagegroup-security-utils \
packagegroup-security-scanners \
+ packagegroup-security-audit \
+ packagegroup-security-hardening \
packagegroup-security-ids \
packagegroup-security-mac \
"
@@ -16,6 +18,8 @@ PACKAGES = "\
RDEPENDS_packagegroup-core-security = "\
packagegroup-security-utils \
packagegroup-security-scanners \
+ packagegroup-security-audit \
+ packagegroup-security-hardening \
packagegroup-security-ids \
packagegroup-security-mac \
"
@@ -23,18 +27,23 @@ RDEPENDS_packagegroup-core-security = "\
SUMMARY_packagegroup-security-utils = "Security utilities"
RDEPENDS_packagegroup-security-utils = "\
checksec \
+ ding-libs \
+ ecryptfs-utils \
+ fscryptctl \
+ keyutils \
nmap \
pinentry \
+ python3-privacyidea \
+ python3-fail2ban \
python3-scapy \
- ding-libs \
- keyutils \
${@bb.utils.contains_any("TUNE_FEATURES", "riscv32 ", "", " libseccomp",d)} \
- ${@bb.utils.contains("DISTRO_FEATURES", "pam", "sssd", "",d)} \
- ${@bb.utils.contains("DISTRO_FEATURES", "pax", "pax-utils", "",d)} \
+ ${@bb.utils.contains("DISTRO_FEATURES", "pam", "sssd google-authenticator-libpam", "",d)} \
+ ${@bb.utils.contains("DISTRO_FEATURES", "pax", "pax-utils packctl", "",d)} \
"

SUMMARY_packagegroup-security-scanners = "Security scanners"
RDEPENDS_packagegroup-security-scanners = "\
+ isic \
nikto \
checksecurity \
${@bb.utils.contains_any("TUNE_FEATURES", "riscv32 riscv64", "", " clamav clamav-freshclam clamav-cvd",d)} \
--
2.17.1


Re: #yocto #sdk - meta-clang undefined references #sdk #yocto

Khem Raj
 

On Tue, Sep 15, 2020 at 12:56 PM Monsees, Steven C (US) via
lists.yoctoproject.org
<steven.monsees=baesystems.com@lists.yoctoproject.org> wrote:



I am building meta-clang (sumo based 6.0.1), with cmake (3.8.2), all under a standard SDK “rocko based” (2.4.1)…



Are the following routines accessible/supported under meta-clang ?



libgbe.so: undefined reference to `clang::DiagnosticIDs::~DiagnosticIDs()'

libgbe.so: undefined reference to `clang::TextDiagnosticPrinter::TextDiagnosticPrinter(llvm::raw_ostream&, clang::DiagnosticOptions*, bool)'

libgbe.so: undefined reference to `clang::DiagnosticsEngine::~DiagnosticsEngine()'

libgbe.so: undefined reference to `clang::CompilerInvocation::CreateFromArgs(clang::CompilerInvocation&, char const* const*, char const* const*, clang::DiagnosticsEngine&)'

libgbe.so: undefined reference to `clang::CompilerInvocationBase::~CompilerInvocationBase()'

libgbe.so: undefined reference to `clang::PCHContainerOperations::PCHContainerOperations()'

libgbe.so: undefined reference to `clang::CompilerInstance::createDiagnostics(clang::DiagnosticConsumer*, bool)'

libgbe.so: undefined reference to `clang::DiagnosticsEngine::DiagnosticsEngine(llvm::IntrusiveRefCntPtr<clang::DiagnosticIDs>, clang::DiagnosticOptions*, clang::DiagnosticConsumer*, bool)'

libgbe.so: undefined reference to `clang::CodeGenOptions::CodeGenOptions()'

libgbe.so: undefined reference to `clang::CompilerInstance::~CompilerInstance()'

libgbe.so: undefined reference to `clang::CompilerInstance::CompilerInstance(std::shared_ptr<clang::PCHContainerOperations>, clang::MemoryBufferCache*)'

libgbe.so: undefined reference to `clang::EmitLLVMOnlyAction::EmitLLVMOnlyAction(llvm::LLVMContext*)'

libgbe.so: undefined reference to `clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)'

libgbe.so: undefined reference to `clang::CompilerInvocationBase::CompilerInvocationBase()'

libgbe.so: undefined reference to `clang::CompilerInstance::setInvocation(std::shared_ptr<clang::CompilerInvocation>)'

libgbe.so: undefined reference to `clang::CodeGenAction::takeModule()'

libgbe.so: undefined reference to `clang::DiagnosticIDs::DiagnosticIDs()'
are you linking this library with libclang ? secondly, also check that
its not emitting bunch of libraries which needs to then individually
linked



thanks,

Steve


#yocto #sdk - meta-clang undefined references #sdk #yocto

Monsees, Steven C (US)
 

 

I am building meta-clang (sumo based 6.0.1), with cmake (3.8.2), all under a standard SDK “rocko based” (2.4.1)…

 

Are the following routines accessible/supported under meta-clang ?

 

libgbe.so: undefined reference to `clang::DiagnosticIDs::~DiagnosticIDs()'

libgbe.so: undefined reference to `clang::TextDiagnosticPrinter::TextDiagnosticPrinter(llvm::raw_ostream&, clang::DiagnosticOptions*, bool)'

libgbe.so: undefined reference to `clang::DiagnosticsEngine::~DiagnosticsEngine()'

libgbe.so: undefined reference to `clang::CompilerInvocation::CreateFromArgs(clang::CompilerInvocation&, char const* const*, char const* const*, clang::DiagnosticsEngine&)'

libgbe.so: undefined reference to `clang::CompilerInvocationBase::~CompilerInvocationBase()'

libgbe.so: undefined reference to `clang::PCHContainerOperations::PCHContainerOperations()'

libgbe.so: undefined reference to `clang::CompilerInstance::createDiagnostics(clang::DiagnosticConsumer*, bool)'

libgbe.so: undefined reference to `clang::DiagnosticsEngine::DiagnosticsEngine(llvm::IntrusiveRefCntPtr<clang::DiagnosticIDs>, clang::DiagnosticOptions*, clang::DiagnosticConsumer*, bool)'

libgbe.so: undefined reference to `clang::CodeGenOptions::CodeGenOptions()'

libgbe.so: undefined reference to `clang::CompilerInstance::~CompilerInstance()'

libgbe.so: undefined reference to `clang::CompilerInstance::CompilerInstance(std::shared_ptr<clang::PCHContainerOperations>, clang::MemoryBufferCache*)'

libgbe.so: undefined reference to `clang::EmitLLVMOnlyAction::EmitLLVMOnlyAction(llvm::LLVMContext*)'

libgbe.so: undefined reference to `clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)'

libgbe.so: undefined reference to `clang::CompilerInvocationBase::CompilerInvocationBase()'

libgbe.so: undefined reference to `clang::CompilerInstance::setInvocation(std::shared_ptr<clang::CompilerInvocation>)'

libgbe.so: undefined reference to `clang::CodeGenAction::takeModule()'

libgbe.so: undefined reference to `clang::DiagnosticIDs::DiagnosticIDs()'

 

thanks,

Steve


[auh][PATCH] buildhistory: do not error on version-going-backwards

Alexander Kanavin
 

In some situation this may happen in initial builds and
should not be treated as an error.

Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
---
modules/buildhistory.py | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/modules/buildhistory.py b/modules/buildhistory.py
index edf9ae6..6649023 100644
--- a/modules/buildhistory.py
+++ b/modules/buildhistory.py
@@ -40,7 +40,16 @@ class BuildHistory(object):

def init(self, machines):
for machine in machines:
- self.bb.complete(self.pn, machine)
+ try:
+ self.bb.complete(self.pn, machine)
+ except Error as e:
+ for line in e.stdout.split("\n"):
+ # version going backwards is not a real error
+ if re.match(".* went backwards which would break package feeds .*", line):
+ break
+ else:
+ raise e
+

def diff(self):
try:
--
2.28.0


[auh][PATCH] buildhistory: simplify the handling of

Alexander Kanavin
 

The module was doing a lot of things, none of which are necessary:
- setting up a separate buildhistory repo for each recipe
- running cleansstate before doing initial build
- messing about with buildhisory revisions

Instead just run buildhistory-diff on the defaults right
after building the first target. This should also address
the various buildhistory problems seen on the AB.

Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
---
modules/buildhistory.py | 25 ++-----------------------
modules/steps.py | 13 +++----------
2 files changed, 5 insertions(+), 33 deletions(-)

diff --git a/modules/buildhistory.py b/modules/buildhistory.py
index 4fdc36c..edf9ae6 100644
--- a/modules/buildhistory.py
+++ b/modules/buildhistory.py
@@ -37,42 +37,21 @@ class BuildHistory(object):
self.bb = bb
self.pn = pn
self.workdir = workdir
- self.revs = []
-
- self.buildhistory_dir = os.path.join(self.workdir, 'buildhistory')
- if not os.path.exists(self.buildhistory_dir):
- os.mkdir(self.buildhistory_dir)
-
- self.git = Git(self.buildhistory_dir)
-
- os.environ['BB_ENV_EXTRAWHITE'] = os.environ['BB_ENV_EXTRAWHITE'] + \
- " BUILDHISTORY_DIR"
- os.environ["BUILDHISTORY_DIR"] = self.buildhistory_dir

def init(self, machines):
- self.bb.cleansstate(self.pn)
for machine in machines:
self.bb.complete(self.pn, machine)
- self.revs.append(self.git.last_commit("master"))
-
- def add(self):
- self.revs.append(self.git.last_commit("master"))

def diff(self):
- rev_initial = self.revs[0]
- rev_final = self.revs[-1]
-
try:
- cmd = "buildhistory-diff -p %s %s %s" % (self.buildhistory_dir,
- rev_initial, rev_final)
+ cmd = "buildhistory-diff"
stdout, stderr = bb.process.run(cmd)
if stdout and os.path.exists(self.workdir):
with open(os.path.join(self.workdir, "buildhistory-diff.txt"),
"w+") as log:
log.write(stdout)

- cmd_full = "buildhistory-diff -a -p %s %s %s" % (self.buildhistory_dir,
- rev_initial, rev_final)
+ cmd_full = "buildhistory-diff -a"
stdout, stderr = bb.process.run(cmd_full)
if stdout and os.path.exists(self.workdir):
with open(os.path.join(self.workdir, "buildhistory-diff-full.txt"),
diff --git a/modules/steps.py b/modules/steps.py
index 46d49fe..811b88d 100644
--- a/modules/steps.py
+++ b/modules/steps.py
@@ -126,15 +126,9 @@ def compile(devtool, bb, git, opts, pkg_ctx):
for machine in opts['machines']:
I(" %s: compiling upgraded version for %s ..." % (pkg_ctx['PN'], machine))
_compile(bb, pkg_ctx['PN'], machine, pkg_ctx['workdir'])
- if opts['buildhistory']:
- pkg_ctx['buildhistory'].add()
-
-def buildhistory_diff(devtool, bb, git, opts, pkg_ctx):
- if not opts['buildhistory']:
- return
-
- I(" %s: Checking buildhistory ..." % pkg_ctx['PN'])
- pkg_ctx['buildhistory'].diff()
+ if opts['buildhistory'] and machine == opts['machines'][0]:
+ I(" %s: Checking buildhistory ..." % pkg_ctx['PN'])
+ pkg_ctx['buildhistory'].diff()

def _rm_source_tree(devtool_output):
for line in devtool_output.split("\n"):
@@ -161,5 +155,4 @@ upgrade_steps = [
(devtool_upgrade, "Running 'devtool upgrade' ..."),
(devtool_finish, "Running 'devtool finish' ..."),
(compile, None),
- (buildhistory_diff, None),
]
--
2.28.0


Yocto Technical Team Minutes, Engineering Sync, for September 15, 2020

Trevor Woerner
 

Yocto Technical Team Minutes, Engineering Sync, for September 15, 2020
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, David Reyna, Saul Wold, Richard Purdie, Tim Orling,
Randy MacLeod, Joshua Watt, Jan-Simon Möller, Michael Halstead, Paul
Barker, Mark Morton, Steve Sakoman, Bruce Ashfield, Trevor Gamblin, Mark
Asselstine, Stacy Gaikovaia

== notes ==
- closed m3, hasn’t built yet (in freeze) waiting for docs
- good progress on the docs, past point-of-no-return
- there appear to be 3 AB issues:
- qemu-mips issue
- limited to 256MB of memory, systemd needs more
- Armin tried raising it, but caused other issues (will revert)
- weird networking dropout issue when qemu testing
- was it caused by something in the image?
- or caused by qemu, kernel, etc?
- need to detect this issue and report on if anything else is dead
- seen on x86, arm and mips
- intermittent
- occasional bitbake timeout
- bitbake says it can’t connect to the server
- due to sync thread in bitbake, 90 second+ disk stalls (apparently)
while writing logs, there’s a 60[s] timeout limit
- devtool doesn’t do re-nice’ing, might be related
- parsing issue seems to be solved (thanks for help from jpew)

== general ==

Randy: bitbake timeout is to add nice to devtool or to not block?
RP: thread is there to allow cache to be written out while allowing bitbake
to do other things, we could just increase timeout on UI, or have bitbake
write the cache directly
JPEW: it’s during client shutdown?
RP: yes, when a given client is done using bitbake, the sync should already be
happening at that time, we need to make sure the sync is done, if not it
will wait on sync completion
RP: it’s a high bug for m3, but will probably push to m4, won’t hold up m3

RP: lots of unassigned bugs in 3.2 if anyone has time

Randy: you listed off a bunch of AB issues, have we seen any improvements
RP: yes, there have been cleanups in various areas that help expose these
issues
Randy: is it an issue of overloading?
RP: i think this is a consequence of heavy automated testing. sure we could
half the number of workers or increase timeouts. or maybe we have bitbake
act differently on the AB than the way it would normally. we could
implement some pinging infrastructure so the UI can know that bitbake
hasn’t died
Timo: is this an NFS issue, or just a general I/O issue
RP: don’t have enough data to say, but feels like an I/O issue
Timo: how will devtool do io-nice?
RP: tinfoil execution
RP: appears to happen when bitbake is extracting kernel source, devtool is
probably using external source, so we’ll probably need to wrap the
extraction of the source code with io-nice

JPEW: i’m still working on multiprocessing things (still multiprocessing,
but not using the python multiprocessing module), maybe not for m4, but do
we still want to keep looking at?
RP: i’d like to look at the code before deciding
JPEW: i’ll clean it up some more

Randy: rust, people looking to get it into 3.3, i need to push the patches
somewhere, would be happy to have help.
RP: i think AlexK is interested. keep him in the loop (he has a great track
record with gnarly problems)

PaulB: doing research for my talk next week at Linaro Connect for license
compliance. wrt rust, whether it can use build offline etc. will be
looking at dunfell and master and try to find answers in the next week or
so
Randy: sounds good, there’s currently no major differences between what
i’m working on and what’s in meta-rust
PaulB: we need to be able to generate source tarballs, handle being behind
corporate firewalls, offline builds. i want to investigate this wrt rust,
golang, and nodejs
RP: it’d be great if this were done as a set of automated tests that could
be added to the project
PaulB: don’t know that all the test code is available, some of the builds
would be big, but can look into it

PaulB: also want to mention outreachy that Paul has worked on and mention it
in my talk

RP: wrt people interested in rust. maybe try Yann or Leon

David: call for papers for YP Summit is open
Randy: 6 days until deadline?
David: yes
Randy: next Monday
Timo: Christopher Clarke and I will be doing virtualization (rehashed and
expanded)

Randy: i’d like to introduce Stacy, working at WR as a co-op for this term
RP: and there’s already a patch in
Stacy: and hopefully another and another!
(various): welcome! ☺


Yocto Project Status WW37'20

Stephen Jolley
 

Current Dev Position: YP 3.2 M3

Next Deadline: YP 3.2 M3 Feature Freeze - Now

 

Next Team Meetings:

 

Key Status/Updates:

  • M3 has now closed and we’re at feature freeze for 3.2.
  • We continue to be in holding pattern for M3 whilst we sort out the sphinx documentation migration. We’re at a point where we just need to press on and complete it.
  • There are three significant autobuilder issues being faced currently:
    • qemumips fails with systemd with 256MB memory, it needs 512MB. If we enable 512MB, we see random hangs. Unless someone can debug and sort the qemu memory issues, we may end up disabling core-image-sato-sdk and core-image-full-cmdline for qemumips+systemd
    • networking with qemu images appears to glitch at times (particularly slower targets such as ltp and qemumips), the session stalls with “no route to host”. We need better serial interrogation to determine the state of qemu when this happens, its unclear if qemu/kernel hangs, networking fails or what is breaking.
    • The timeouts in bitbake have been narrowed down to the “SyncThread” which writes out the cache data to disk stalling for around 90s. We don’t have a plan to address this right now but its at least process in identifying the cause
  • The bitbake parsing hangs should hopefully all be resolved now, thanks to Joshua for help there.
  • A preview of the sphinx built documentation is available at https://docs.yoctoproject.org/, work is ongoing to complete the migration work and blocking M3.
  • We continue to struggle with a number of autobuilder intermittent bugs. 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

Help with any of these would be much appreciated, unfortunately it is proving hard to find anyone interested in helping figure these out and they significantly hamper our testing.

 

YP 3.2 Milestone Dates:

  • YP 3.2 M3 build date 2020/8/31
  • YP 3.2 M3 Release date 2020/9/11
  • YP 3.2 M4 build date 2020/10/5
  • YP 3.2 M4 Release date 2020/10/30

 

Planned upcoming dot releases:

  • YP 3.1.3 build date 2020/9/14
  • YP 3.1.3 release date 2020/9/25

 

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: Ethernet device with systemd-networkd on Yocto won't work (rejects ARP replies), but does work with /etc/network/interfaces #yocto #systemd

eliranl@...
 

Thanks Matt!! This solved it.

And yes, the branch is thud-l4t-r32.3.1.


WIC cp is not copying files to ext4 partition #yocto

mail2uvijay@...
 

Hi Team, Able to create image for using Yocto. After creating the image, I am trying to copy one file using 'wic cp' to 'extt4' partition. while copying i am not getting any error, after flashing the image on board copied file was not present. Is there any other ways to copy a file to ext4 partition. Where as in case vfat partition i could able to copy the file successfully. Regards, Vijay


M+ & H bugs with Milestone Movements WW37

Stephen Jolley
 

All,

 

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

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

High

13646

runtime tests sometimes can't login to the serial console on systemd images (generates warning)

randy.macleod@...

kai.kang@...

3.2 M3

3.2 M4

 

14039

bitbake selftest failing with freedesktoporg git

randy.macleod@...

richard.purdie@...

3.2 M3

3.2 M4

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 

1361 - 1380 of 52041