Date   

QA notification for completed autobuilder build (yocto-3.2.4.rc1)

Pokybuild User <pokybuild@...>
 

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


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


Build hash information:

bitbake: e05d79a6ed92c9ce17b90fd5fb6186898a7b3bf8
meta-arm: 39bc4076b2d9a662111beaa0621ee9c1e37f56ea
meta-gplv2: 6e8e969590a22a729db1ff342de57f2fd5d02d43
meta-intel: c325d3e2eab9952dc175a38f31b78fecdcdd0fcc
meta-kernel: 4b288396eff43fe9b1a233aed1ce9b48329a2eb6
meta-mingw: 352d8b0aa3c7bbd5060a4cc2ebe7c0e964de4879
oecore: d47b7cdc3508343349f3bb3eacb2dc3227dd94d2
poky: 60c8482769f38a4db6f38d525405c887794511a9



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


Re: #yocto cmake configurations #yocto

Monsees, Steven C (US)
 

 

Thanks… I forgot that… linked.

 

I appreciate the help.

Steve

 

From: Khem Raj <raj.khem@...>
Sent: Wednesday, May 5, 2021 5:06 PM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
Subject: Re: [yocto] #yocto cmake configurations

 

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.

 

usually one uses llvm-config to get the libs and order is important too especially with static libs. Can you dump all .a files from clang and see if its defined in some other .a which is either missing or present after the faulting .a in linker cmd

 

On Wed, May 5, 2021 at 12:53 PM Monsees, Steven C (US) <steven.monsees@...> wrote:

 

I made some modification in the cmake modules to adjust for the linker issue below, but now I appear to have uncovered an issue with the static libraries which meta-clang generated under the SDK… (see below)…

 

The link command is attached as “tmp.txt”.

 

There are a lot of these being generated, this is but a subset…

Note:

(1) “workspace_3” is a reference to my build area where I built the STD SDK, why would this be here the SDK should be independent of this are, no ?

                (2) the code with the undefined reference does appear to be missing the proper header file reference

 

 

 

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `CodeGenModule':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:114: undefined reference to `clang::ASTContext::toCharUnitsFromBits(long) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:116: undefined reference to `clang::ASTContext::toCharUnitsFromBits(long) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:118: undefined reference to `clang::ASTContext::toCharUnitsFromBits(long) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `bool clang::Decl::hasAttr<clang::IFuncAttr>() const':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/AST/DeclBase.h:543: undefined reference to `clang::Decl::getAttrs() const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::CodeGen::CodeGenModule::checkAliases()':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:304: undefined reference to `clang::Decl::getDefiningAttr() const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::SectionAttr* clang::Decl::getAttr<clang::SectionAttr>() const':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/AST/DeclBase.h:539: undefined reference to `clang::Decl::getAttrs() const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `bool clang::Decl::hasAttr<clang::CUDAGlobalAttr>() const':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/AST/DeclBase.h:543: undefined reference to `clang::Decl::getAttrs() const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::CodeGen::CodeGenModule::Release()':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:520: undefined reference to `clang::ASTContext::getTypeSizeInChars(clang::QualType) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::CodeGen::CodeGenModule::emitMultiVersionFunctions()':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:2788: undefined reference to `clang::ASTContext::forEachMultiversionedFunctionVersion(clang::FunctionDecl const*, llvm::function_ref<void (clang::FunctionDecl*)>) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:2819: undefined reference to `clang::FunctionDecl::isTargetMultiVersion() const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::CodeGen::CodeGenModule::getFunctionLinkage(clang::GlobalDecl)':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:1188: undefined reference to `clang::ASTContext::GetGVALinkageForFunction(clang::FunctionDecl const*) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:1188: undefined reference to `clang::ASTContext::GetGVALinkageForFunction(clang::FunctionDecl const*) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:1188: undefined reference to `clang::ASTContext::GetGVALinkageForFunction(clang::FunctionDecl const*) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::Module::getTopLevelModuleName() const':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/Basic/Module.h:468: undefined reference to `clang::Module::getTopLevelModule() const'

 

 

From: Monsees, Steven C (US) <steven.monsees@...>
Sent: Wednesday, May 5, 2021 7:25 AM
To: Monsees, Steven C (US) <steven.monsees@...>; Khem Raj <raj.khem@...>
Cc: yocto@...
Subject: RE: [yocto] #yocto cmake configurations

 

 

All the libraries are under the SDK here:

 

-L/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib

 

I need the DRM libraries to be picked up correctly, libclang.so may not be required since I have all the static variations available, (added to while testing linker) I have yet to make it through entire build due to linker issue…

 

Steve

 

From: yocto@... <yocto@...> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Wednesday, May 5, 2021 6:44 AM
To: Khem Raj <raj.khem@...>
Cc: yocto@...
Subject: Re: [yocto] #yocto cmake configurations

 

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.

 

 

Khem:

 

I only have the following libraries present for these:

 

libclang.so  

libclang.so.9

libdrm_intel.so

libdrm_intel.so.1

libdrm_intel.so.1.0.0

libdrm.so

libdrm.so.2

libdrm.so.2.4.0   

 

I do generate the static (*.a) files for both LLVM & Clang and they appear to all be present (No libclang.a was generated).

 

Steve

 

From: Khem Raj <raj.khem@...>
Sent: Tuesday, May 4, 2021 7:46 PM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
Subject: Re: [yocto] #yocto cmake configurations

 

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.

 

the cmd seems to pass --sysroot correctly so can you search in SDK sysroot if you have libclang.a libdrm_intel.a and libdrm.a ?

 

On Tue, May 4, 2021 at 3:20 PM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:

Yes, LLVM & Clang…

 

From: Khem Raj <raj.khem@...>
Sent: Tuesday, May 4, 2021 5:17 PM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
Subject: Re: [yocto] #yocto cmake configurations

 

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.

 

I see its using -rdynamic -static

so next question is that do you have .a files in your sdk ?

 

On Tue, May 4, 2021 at 12:57 PM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:

 

Attached…

 

From: Khem Raj <raj.khem@...>
Sent: Tuesday, May 4, 2021 2:36 PM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
Subject: Re: [yocto] #yocto cmake configurations

 

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.

 

can you post full linker cmd which is failing ?

 

On Tue, May 4, 2021 at 11:24 AM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:

 

My standard zeus SDK appears to have an issue linking in my applications dynamic libs…

 

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: cannot find -ldrm_intel

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: cannot find -ldrm

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: cannot find -lclang

collect2: error: ld returned 1 exit status

The libraries are under: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/

 

My CMake build app does not appear to have an issue finding the files:

 

DRM_INTEL_LIBRARIES:STRING=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libdrm_intel.so

DRM_LIBRARIES:STRING=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libdrm.so

 

It appears to be an issue specifically with the ld…

 

LDFLAGS= " --sysroot=$ENV{OECORE_TARGET_SYSROOT} -L$ENV{OECORE_TARGET_SYSROOT}/usr/lib -L$ENV{OECORE_TARGET_SYSROOT}/usr/lib/x86_64-poky-linux/9.2.0 -lpthread -pthread -O2 -pipe -Wl,-O1 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"

 

It does not appear to be making use of –L’s…

 

Is there something I might look at/configure (i.e. add paths to search paths) ?

Is there a simple test to validate tool ?

 

Thanks,

Steve

 

From: yocto@... <yocto@...> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Sunday, May 2, 2021 1:28 PM
To: yocto@...
Subject: [yocto] #yocto cmake configurations

 

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.

 

 

I am using zeus, standard SDK, cmake…

 

Can I pre-configure the SDK to setup cmake package search paths ?, say for find_package, etc. (i.e. detecting external libraries/programs)…

 

The majority of my env is configuring properly, but I am finding cmake is setup for a standard linux env with regards to these types of searches, and

I wanted the cmake built in to look at my SDK paths (first by default) when doing such things as detecting python interpreter, libraries, etc.

 

I am working on third party package unaware of my SDK setup.

 

Thanks,

Steve

 

 

 


Next Yocto Project LTS - April 2022

Richard Purdie
 

I'm pleased to be able to announce that the project is planning to have
the April 2022 release next year be our next LTS release.

This fits in with our original announced plan of 2 year cycles and 
recognises that the LTS has been well received by members and our 
community. It also aligns well with LTS releases of other projects
meaning we have "co-travellers".

The current dunfell LTS would be due to end at that time. There has
been discussion about extending it beyond the currently planned 
timeframe but no agreement/decision has been made on the extra finance 
that would require at this time. There is also some concern about the 
potential pressure on layer maintainers in wider ecosystem which we
plan to investigate further.

By confirming this now, we're hoping to give people a chance to align
strategies and plan for feature development to land into the LTS. There
is a clear need for any new/experimental changes to be planned/developed
now in order to ensure they're ready and stabilised for the LTS.

Cheers,

Richard


[PATCH] config.json: Remove -j option for reproducibility as live output is useful

Richard Purdie
 

The -j option has the side effect that the output is cached. For a long running
single threaded target, the live output is more useful so switch to it.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
config.json | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/config.json b/config.json
index 3e12d3f..6533dab 100644
--- a/config.json
+++ b/config.json
@@ -191,7 +191,7 @@
"SDKMACHINE" : "x86_64",
"step1" : {
"shortname" : "Reproducible Selftest",
- "EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc; OEQA_DEBUGGING_SAVED_OUTPUT=${BASE_SHAREDDIR}/pub/repro-fail/ DISPLAY=:1 oe-selftest -r reproducible -j 1"],
+ "EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc; OEQA_DEBUGGING_SAVED_OUTPUT=${BASE_SHAREDDIR}/pub/repro-fail/ DISPLAY=:1 oe-selftest -r reproducible"],
"ADDLAYER" : ["${BUILDDIR}/../meta-selftest"]

}
--
2.30.2


Re: KeyError: 'getpwuid(): uid not found: 1000' in do_package phase

Martin Jansa
 

On Thu, May 6, 2021 at 10:57 AM Thomas Hill via lists.yoctoproject.org <tom.hill=inbox.lv@...> wrote:
Hi Martin!

On Mon, Nov 16, 2020 at 02:28 PM, Martin Jansa wrote:
https://github.com/webOS-ports/meta-webos-ports/commit/9fd17a67cdbed92df13a14b002a189b4c6c2d442
 
is an example where it triggers this error, but doesn't trigger the more common host-user-contaminated QA error (unless you happened to use UID 1001 on host for the user running bitbake).
I have here a similar problem with one of my own packages. It happens that my bitbake user uses UID 1001. Do you have more information why this is a problem? Should it be enough to change the UID to 1002 to get everything running?

No, you should chown the files to be owned by the expected user which exists in the image (probably root like in my commit). Changing the UID of the user on host is very bad work around (as it will fail for the next person building the same image with host user 1001.


Re: Hardknott - pseudo excluded from intercept_scripts

Richard Purdie
 

On Wed, 2021-05-05 at 00:56 -0700, Chuck Wolber wrote:
The following code is an effective workaround. It must be added after the core-image is inherited.

python () {
     pseudo_ignore_paths = d.getVar('PSEUDO_IGNORE_PATHS')
     result = ','.join([x for x in pseudo_ignore_paths.split(',') if "intercept_scripts" not in x])
     d.setVar('PSEUDO_IGNORE_PATHS', result)
}

..Ch:W..

On Tue, May 4, 2021 at 8:53 PM Chuck Wolber via lists.yoctoproject.org <
chuckwolber=gmail.com@lists.yoctoproject.org> wrote:

I was attempting an image build with Yocto Hardknott, and I ran into a chown problem during do_rootfs(). I
traced it down to ${WORKDIR}/intercept_scripts showing up in the PSEUDO_IGNORE_PATHS environment variable.

This commit made the change:
https://git.openembedded.org/openembedded-core/commit/meta/classes/image.bbclass?id=9463be2292b942a1072eea88881b9644e55aadb9

I continued down the rabbit hole until I got here:
https://git.openembedded.org/openembedded-core/tree/meta/lib/oe/package_manager/__init__.py#n173

Line 192 specifically is the smoking gun. The files are being copied from poky/scripts/postinst-intercepts
into the ${WORKDIR}/intercept_scripts directory and immediately failing when the copyFile utility attempts
to do a chown.

Is there any logical explanation for this? Is this a bug or am I doing something wrong? Is there a
workaround?
This should be fixed in master, the issue was triggered by a checkout 
owned by root/root:

http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=eff192abe2ee43ebf981bafbb7fca8602ebdcf0c

Steve/Anuj: We'll likely want to backport that one.

Cheers,

Richard


Re: KeyError: 'getpwuid(): uid not found: 1000' in do_package phase

Thomas Hill
 

Hi Martin!

On Mon, Nov 16, 2020 at 02:28 PM, Martin Jansa wrote:
https://github.com/webOS-ports/meta-webos-ports/commit/9fd17a67cdbed92df13a14b002a189b4c6c2d442
 
is an example where it triggers this error, but doesn't trigger the more common host-user-contaminated QA error (unless you happened to use UID 1001 on host for the user running bitbake).
I have here a similar problem with one of my own packages. It happens that my bitbake user uses UID 1001. Do you have more information why this is a problem? Should it be enough to change the UID to 1002 to get everything running?

Thanks!
Tom


Re: SSH_AUTH_SOCK unavailable when pulling modules #golang

Sven
 

Adding BB_ORIGENV to do_compile[vardepsexclude] solved the issue. Thanks for your help!


Re: SSH_AUTH_SOCK unavailable when pulling modules #golang

Sven
 

Hi Richard,

Unfortunately, that doesn't make the error messages go away. I agree that it's not great that go-mod fetches during do_compile but that's the way it currently is.

For completeness sake, here is the complete minimal example that _does_ compile. However, error messages à la

ERROR: When reparsing [...]/golang-test/golang-test.bb:do_compile, the basehash value changed from be5e3ca0e52fd3e3a0315fb32a2845f097bb6925940a8141b6f4d99fa2423e20 to fc952756231a898ae7d3fd611607066b349042f5313b8363d11eef18ed317ed2. The metadata is not deterministic and this needs to be fixed.
ERROR: The following commands may help:
ERROR: $ bitbake golang-test -cdo_compile -Snone
ERROR: Then:
ERROR: $ bitbake golang-test -cdo_compile -Sprintdiff

are spewed out. Here's the recipe:

LICENSE = "CLOSED"
GO_IMPORT = "bitbucket.org/sven_schwermer/golang-a"
SRC_URI = "git://git@${GO_IMPORT};protocol=ssh;branch=master"
SRCREV = "f7d820d09a5b2332737a8105b3efd9c1e8e51d32"
inherit go-mod
do_compile() {
export SSH_AUTH_SOCK="${@d.getVar('BB_ORIGENV', False).getVar('SSH_AUTH_SOCK', False)}"
go_do_compile
}

bitbucket.org/sven_schwermer/golang-a pulls in a secondary dependency (bitbucket.org/sven_schwermer/golang-b) which is not publicly available. This is golang-a's go.mod:

module bitbucket.org/sven_schwermer/golang-a
go 1.16
require bitbucket.org/sven_schwermer/golang-b v0.0.0-20210505180831-90ba3cd6391e

I have tested this also on latest poky@master (5a0679cb75) with identical results.


Re: Recipe Grep'ing

Khem Raj
 

On Wed, May 5, 2021 at 7:13 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote:

On Wed, May 5, 2021 at 8:42 PM Chuck Wolber <chuckwolber@gmail.com> wrote:

I was pondering putting some work in to a fairly large patch set aimed at making recipes easier to grep through, and wanted to get some feedback before I put time and effort into it.

I have often found that the following pattern cleanly describes the "what" and the "why" when grep'ing through recipes to search for things:

FOO += "item1"
FOO += "item2"

Whereas this pattern gives us the "what", but not the "why":

FOO = "item1 \
item2 \
"

After discussing this with Richard Purdie on IRC, I also understand that the latter pattern benefits some forms of build output. In addition, for SRC_URI, the "why" is normally fairly obvious from context clues.
The other issue with large formatting patches, is that they make a
history "wall". So when we are debugging and trying to figure why a
change was made, you always have to jump over the wall (or dig under
it) to get the real information.
right, that's what if we want to do this then it has to be persisted
with otherwise it will end up being one time exercise with all these
losses you described.

As such, I'm not a fan of changes like this, unless they are coupled
to some sort of functional change. So I'd be hesitant to take them
into recipes that I end up holding the bag when things break.

Cheers,

Bruce


So, is there any interest in accepting a patch set of that nature for Yocto and OE repositories? If so, what variables and situations should be considered "off limits" to a change like that?

..Ch:W..


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



--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II



Re: Recipe Grep'ing

Bruce Ashfield
 

On Wed, May 5, 2021 at 8:42 PM Chuck Wolber <chuckwolber@gmail.com> wrote:

I was pondering putting some work in to a fairly large patch set aimed at making recipes easier to grep through, and wanted to get some feedback before I put time and effort into it.

I have often found that the following pattern cleanly describes the "what" and the "why" when grep'ing through recipes to search for things:

FOO += "item1"
FOO += "item2"

Whereas this pattern gives us the "what", but not the "why":

FOO = "item1 \
item2 \
"

After discussing this with Richard Purdie on IRC, I also understand that the latter pattern benefits some forms of build output. In addition, for SRC_URI, the "why" is normally fairly obvious from context clues.
The other issue with large formatting patches, is that they make a
history "wall". So when we are debugging and trying to figure why a
change was made, you always have to jump over the wall (or dig under
it) to get the real information.

As such, I'm not a fan of changes like this, unless they are coupled
to some sort of functional change. So I'd be hesitant to take them
into recipes that I end up holding the bag when things break.

Cheers,

Bruce


So, is there any interest in accepting a patch set of that nature for Yocto and OE repositories? If so, what variables and situations should be considered "off limits" to a change like that?

..Ch:W..


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



--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


Re: Recipe Grep'ing

Khem Raj
 

On 5/5/21 5:41 PM, Chuck Wolber wrote:
I was pondering putting some work in to a fairly large patch set aimed at making recipes easier to grep through, and wanted to get some feedback before I put time and effort into it.
I have often found that the following pattern cleanly describes the "what" and the "why" when grep'ing through recipes to search for things:
FOO += "item1"
FOO += "item2"
Whereas this pattern gives us the "what", but not the "why":
FOO = "item1 \
             item2 \
            "
After discussing this with Richard Purdie on IRC, I also understand that the latter pattern benefits some forms of build output. In addition, for SRC_URI, the "why" is normally fairly obvious from context clues.
So, is there any interest in accepting a patch set of that nature for Yocto and OE repositories? If so, what variables and situations should be considered "off limits" to a change like that?
I think it is a good idea, however, to make it persistent it would be nice to have a linter, which can do such checks and perhaps we can enable this in autobuilders so we can keep such cleansups maintained

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


Recipe Grep'ing

Chuck Wolber
 

I was pondering putting some work in to a fairly large patch set aimed at making recipes easier to grep through, and wanted to get some feedback before I put time and effort into it.

I have often found that the following pattern cleanly describes the "what" and the "why" when grep'ing through recipes to search for things:

FOO += "item1"
FOO += "item2"

Whereas this pattern gives us the "what", but not the "why":

FOO = "item1 \
             item2 \
            "

After discussing this with Richard Purdie on IRC, I also understand that the latter pattern benefits some forms of build output. In addition, for SRC_URI, the "why" is normally fairly obvious from context clues.

So, is there any interest in accepting a patch set of that nature for Yocto and OE repositories? If so, what variables and situations should be considered "off limits" to a change like that?

..Ch:W..


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


Re: #yocto cmake configurations #yocto

Khem Raj
 

usually one uses llvm-config to get the libs and order is important too especially with static libs. Can you dump all .a files from clang and see if its defined in some other .a which is either missing or present after the faulting .a in linker cmd

On Wed, May 5, 2021 at 12:53 PM Monsees, Steven C (US) <steven.monsees@...> wrote:

 

I made some modification in the cmake modules to adjust for the linker issue below, but now I appear to have uncovered an issue with the static libraries which meta-clang generated under the SDK… (see below)…

 

The link command is attached as “tmp.txt”.

 

There are a lot of these being generated, this is but a subset…

Note:

(1) “workspace_3” is a reference to my build area where I built the STD SDK, why would this be here the SDK should be independent of this are, no ?

                (2) the code with the undefined reference does appear to be missing the proper header file reference

 

 

 

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `CodeGenModule':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:114: undefined reference to `clang::ASTContext::toCharUnitsFromBits(long) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:116: undefined reference to `clang::ASTContext::toCharUnitsFromBits(long) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:118: undefined reference to `clang::ASTContext::toCharUnitsFromBits(long) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `bool clang::Decl::hasAttr<clang::IFuncAttr>() const':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/AST/DeclBase.h:543: undefined reference to `clang::Decl::getAttrs() const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::CodeGen::CodeGenModule::checkAliases()':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:304: undefined reference to `clang::Decl::getDefiningAttr() const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::SectionAttr* clang::Decl::getAttr<clang::SectionAttr>() const':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/AST/DeclBase.h:539: undefined reference to `clang::Decl::getAttrs() const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `bool clang::Decl::hasAttr<clang::CUDAGlobalAttr>() const':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/AST/DeclBase.h:543: undefined reference to `clang::Decl::getAttrs() const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::CodeGen::CodeGenModule::Release()':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:520: undefined reference to `clang::ASTContext::getTypeSizeInChars(clang::QualType) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::CodeGen::CodeGenModule::emitMultiVersionFunctions()':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:2788: undefined reference to `clang::ASTContext::forEachMultiversionedFunctionVersion(clang::FunctionDecl const*, llvm::function_ref<void (clang::FunctionDecl*)>) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:2819: undefined reference to `clang::FunctionDecl::isTargetMultiVersion() const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::CodeGen::CodeGenModule::getFunctionLinkage(clang::GlobalDecl)':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:1188: undefined reference to `clang::ASTContext::GetGVALinkageForFunction(clang::FunctionDecl const*) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:1188: undefined reference to `clang::ASTContext::GetGVALinkageForFunction(clang::FunctionDecl const*) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:1188: undefined reference to `clang::ASTContext::GetGVALinkageForFunction(clang::FunctionDecl const*) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::Module::getTopLevelModuleName() const':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/Basic/Module.h:468: undefined reference to `clang::Module::getTopLevelModule() const'

 

 

From: Monsees, Steven C (US) <steven.monsees@...>
Sent: Wednesday, May 5, 2021 7:25 AM
To: Monsees, Steven C (US) <steven.monsees@...>; Khem Raj <raj.khem@...>
Cc: yocto@...
Subject: RE: [yocto] #yocto cmake configurations

 

 

All the libraries are under the SDK here:

 

-L/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib

 

I need the DRM libraries to be picked up correctly, libclang.so may not be required since I have all the static variations available, (added to while testing linker) I have yet to make it through entire build due to linker issue…

 

Steve

 

From: yocto@... <yocto@...> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Wednesday, May 5, 2021 6:44 AM
To: Khem Raj <raj.khem@...>
Cc: yocto@...
Subject: Re: [yocto] #yocto cmake configurations

 

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.

 

 

Khem:

 

I only have the following libraries present for these:

 

libclang.so  

libclang.so.9

libdrm_intel.so

libdrm_intel.so.1

libdrm_intel.so.1.0.0

libdrm.so

libdrm.so.2

libdrm.so.2.4.0   

 

I do generate the static (*.a) files for both LLVM & Clang and they appear to all be present (No libclang.a was generated).

 

Steve

 

From: Khem Raj <raj.khem@...>
Sent: Tuesday, May 4, 2021 7:46 PM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
Subject: Re: [yocto] #yocto cmake configurations

 

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.

 

the cmd seems to pass --sysroot correctly so can you search in SDK sysroot if you have libclang.a libdrm_intel.a and libdrm.a ?

 

On Tue, May 4, 2021 at 3:20 PM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:

Yes, LLVM & Clang…

 

From: Khem Raj <raj.khem@...>
Sent: Tuesday, May 4, 2021 5:17 PM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
Subject: Re: [yocto] #yocto cmake configurations

 

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.

 

I see its using -rdynamic -static

so next question is that do you have .a files in your sdk ?

 

On Tue, May 4, 2021 at 12:57 PM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:

 

Attached…

 

From: Khem Raj <raj.khem@...>
Sent: Tuesday, May 4, 2021 2:36 PM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
Subject: Re: [yocto] #yocto cmake configurations

 

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.

 

can you post full linker cmd which is failing ?

 

On Tue, May 4, 2021 at 11:24 AM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:

 

My standard zeus SDK appears to have an issue linking in my applications dynamic libs…

 

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: cannot find -ldrm_intel

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: cannot find -ldrm

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: cannot find -lclang

collect2: error: ld returned 1 exit status

The libraries are under: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/

 

My CMake build app does not appear to have an issue finding the files:

 

DRM_INTEL_LIBRARIES:STRING=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libdrm_intel.so

DRM_LIBRARIES:STRING=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libdrm.so

 

It appears to be an issue specifically with the ld…

 

LDFLAGS= " --sysroot=$ENV{OECORE_TARGET_SYSROOT} -L$ENV{OECORE_TARGET_SYSROOT}/usr/lib -L$ENV{OECORE_TARGET_SYSROOT}/usr/lib/x86_64-poky-linux/9.2.0 -lpthread -pthread -O2 -pipe -Wl,-O1 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"

 

It does not appear to be making use of –L’s…

 

Is there something I might look at/configure (i.e. add paths to search paths) ?

Is there a simple test to validate tool ?

 

Thanks,

Steve

 

From: yocto@... <yocto@...> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Sunday, May 2, 2021 1:28 PM
To: yocto@...
Subject: [yocto] #yocto cmake configurations

 

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.

 

 

I am using zeus, standard SDK, cmake…

 

Can I pre-configure the SDK to setup cmake package search paths ?, say for find_package, etc. (i.e. detecting external libraries/programs)…

 

The majority of my env is configuring properly, but I am finding cmake is setup for a standard linux env with regards to these types of searches, and

I wanted the cmake built in to look at my SDK paths (first by default) when doing such things as detecting python interpreter, libraries, etc.

 

I am working on third party package unaware of my SDK setup.

 

Thanks,

Steve

 

 

 


Re: SSH_AUTH_SOCK unavailable when pulling modules #golang

Richard Purdie
 

On Mon, 2021-05-03 at 11:25 -0700, Sven via lists.yoctoproject.org wrote:
Hi,

I have put together a recipe inheriting from go-mod. This project depends on 
out-of-repo modules that sit in private repos. As long as the SSH key required 
to pull the requirements is present as a file (under $HOME/.ssh), everything 
works fine. However, as soon as the SSH credentials are only available via 
agent and $SSH_AUTH_SOCK, the do_compile step fails. I have traced this down 
to the fact that the $SSH_AUTH_SOCK environment variable is not available to
do_compile which is when the requirements are pulled. This is the sort of error 
message I get:
ERROR: mypackage-git-r0 do_compile: Execution of '[...]/mypackage/git-r0/temp/run.do_compile.20076' 
failed with exit code 1:
# cd .; git ls-remote https://bitbucket.org/myorg/some-requirement
Permission denied (publickey).
fatal: Could not read from remote repository.

Note, that the do_fetch step succeeds in pulling the actual repo. I tried fixing 
the problem by wrapping the do_compile function and providing $SSH_AUTH_SOCK from
the original environment:
def origenv(d, var):
    return d.getVar("BB_ORIGENV", False).getVar(var, False)

do_compile() {
    if [ -n "${@origenv(d, 'SSH_AUTH_SOCK') or ''}" ]; then
        export SSH_AUTH_SOCK="${@origenv(d, 'SSH_AUTH_SOCK')}"
    fi
    go_do_compile
}

This allows the do_compile step (and all subsequent steps) to finish successfully. 
However, that way, I get a bunch of errors like this (cleansstate does not help):
ERROR: When reparsing [...]/mypackage_git.bb:do_compile, the basehash value 
changed from eb51e4ec321c723587cec03bb9b33b94ee43e0b0939eb43b52824e3d5cfebec2 
to 2bb034f43856917d6454a56b32946b1c68cf7f286b20fd7a7eaf1bfd2a92d34f. The metadata 
is not deterministic and this needs to be fixed.
ERROR: The following commands may help:
ERROR: $ bitbake mypackage -cdo_compile -Snone
ERROR: Then:
ERROR: $ bitbake mypackage -cdo_compile -Sprintdiff

Neither command helps to fix this. What can I do? I'm on poky yocto-3.1.5-18-gbb7747497a.

You can probably 'fix' that with:

do_compile[vardepsexclude] += "SSH_AUTH_SOCK"

however you really shouldn't be accessing the network in a compile task.
That is a wider go issue :(.

Cheers,

Richard


Re: #yocto cmake configurations #yocto

Monsees, Steven C (US)
 

 

I made some modification in the cmake modules to adjust for the linker issue below, but now I appear to have uncovered an issue with the static libraries which meta-clang generated under the SDK… (see below)…

 

The link command is attached as “tmp.txt”.

 

There are a lot of these being generated, this is but a subset…

Note:

(1) “workspace_3” is a reference to my build area where I built the STD SDK, why would this be here the SDK should be independent of this are, no ?

                (2) the code with the undefined reference does appear to be missing the proper header file reference

 

 

 

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `CodeGenModule':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:114: undefined reference to `clang::ASTContext::toCharUnitsFromBits(long) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:116: undefined reference to `clang::ASTContext::toCharUnitsFromBits(long) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:118: undefined reference to `clang::ASTContext::toCharUnitsFromBits(long) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `bool clang::Decl::hasAttr<clang::IFuncAttr>() const':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/AST/DeclBase.h:543: undefined reference to `clang::Decl::getAttrs() const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::CodeGen::CodeGenModule::checkAliases()':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:304: undefined reference to `clang::Decl::getDefiningAttr() const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::SectionAttr* clang::Decl::getAttr<clang::SectionAttr>() const':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/AST/DeclBase.h:539: undefined reference to `clang::Decl::getAttrs() const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `bool clang::Decl::hasAttr<clang::CUDAGlobalAttr>() const':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/AST/DeclBase.h:543: undefined reference to `clang::Decl::getAttrs() const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::CodeGen::CodeGenModule::Release()':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:520: undefined reference to `clang::ASTContext::getTypeSizeInChars(clang::QualType) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::CodeGen::CodeGenModule::emitMultiVersionFunctions()':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:2788: undefined reference to `clang::ASTContext::forEachMultiversionedFunctionVersion(clang::FunctionDecl const*, llvm::function_ref<void (clang::FunctionDecl*)>) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:2819: undefined reference to `clang::FunctionDecl::isTargetMultiVersion() const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::CodeGen::CodeGenModule::getFunctionLinkage(clang::GlobalDecl)':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:1188: undefined reference to `clang::ASTContext::GetGVALinkageForFunction(clang::FunctionDecl const*) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:1188: undefined reference to `clang::ASTContext::GetGVALinkageForFunction(clang::FunctionDecl const*) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:1188: undefined reference to `clang::ASTContext::GetGVALinkageForFunction(clang::FunctionDecl const*) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::Module::getTopLevelModuleName() const':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/Basic/Module.h:468: undefined reference to `clang::Module::getTopLevelModule() const'

 

 

From: Monsees, Steven C (US) <steven.monsees@...>
Sent: Wednesday, May 5, 2021 7:25 AM
To: Monsees, Steven C (US) <steven.monsees@...>; Khem Raj <raj.khem@...>
Cc: yocto@...
Subject: RE: [yocto] #yocto cmake configurations

 

 

All the libraries are under the SDK here:

 

-L/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib

 

I need the DRM libraries to be picked up correctly, libclang.so may not be required since I have all the static variations available, (added to while testing linker) I have yet to make it through entire build due to linker issue…

 

Steve

 

From: yocto@... <yocto@...> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Wednesday, May 5, 2021 6:44 AM
To: Khem Raj <raj.khem@...>
Cc: yocto@...
Subject: Re: [yocto] #yocto cmake configurations

 

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.

 

 

Khem:

 

I only have the following libraries present for these:

 

libclang.so  

libclang.so.9

libdrm_intel.so

libdrm_intel.so.1

libdrm_intel.so.1.0.0

libdrm.so

libdrm.so.2

libdrm.so.2.4.0   

 

I do generate the static (*.a) files for both LLVM & Clang and they appear to all be present (No libclang.a was generated).

 

Steve

 

From: Khem Raj <raj.khem@...>
Sent: Tuesday, May 4, 2021 7:46 PM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
Subject: Re: [yocto] #yocto cmake configurations

 

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.

 

the cmd seems to pass --sysroot correctly so can you search in SDK sysroot if you have libclang.a libdrm_intel.a and libdrm.a ?

 

On Tue, May 4, 2021 at 3:20 PM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:

Yes, LLVM & Clang…

 

From: Khem Raj <raj.khem@...>
Sent: Tuesday, May 4, 2021 5:17 PM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
Subject: Re: [yocto] #yocto cmake configurations

 

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.

 

I see its using -rdynamic -static

so next question is that do you have .a files in your sdk ?

 

On Tue, May 4, 2021 at 12:57 PM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:

 

Attached…

 

From: Khem Raj <raj.khem@...>
Sent: Tuesday, May 4, 2021 2:36 PM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
Subject: Re: [yocto] #yocto cmake configurations

 

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.

 

can you post full linker cmd which is failing ?

 

On Tue, May 4, 2021 at 11:24 AM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:

 

My standard zeus SDK appears to have an issue linking in my applications dynamic libs…

 

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: cannot find -ldrm_intel

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: cannot find -ldrm

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: cannot find -lclang

collect2: error: ld returned 1 exit status

The libraries are under: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/

 

My CMake build app does not appear to have an issue finding the files:

 

DRM_INTEL_LIBRARIES:STRING=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libdrm_intel.so

DRM_LIBRARIES:STRING=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libdrm.so

 

It appears to be an issue specifically with the ld…

 

LDFLAGS= " --sysroot=$ENV{OECORE_TARGET_SYSROOT} -L$ENV{OECORE_TARGET_SYSROOT}/usr/lib -L$ENV{OECORE_TARGET_SYSROOT}/usr/lib/x86_64-poky-linux/9.2.0 -lpthread -pthread -O2 -pipe -Wl,-O1 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"

 

It does not appear to be making use of –L’s…

 

Is there something I might look at/configure (i.e. add paths to search paths) ?

Is there a simple test to validate tool ?

 

Thanks,

Steve

 

From: yocto@... <yocto@...> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Sunday, May 2, 2021 1:28 PM
To: yocto@...
Subject: [yocto] #yocto cmake configurations

 

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.

 

 

I am using zeus, standard SDK, cmake…

 

Can I pre-configure the SDK to setup cmake package search paths ?, say for find_package, etc. (i.e. detecting external libraries/programs)…

 

The majority of my env is configuring properly, but I am finding cmake is setup for a standard linux env with regards to these types of searches, and

I wanted the cmake built in to look at my SDK paths (first by default) when doing such things as detecting python interpreter, libraries, etc.

 

I am working on third party package unaware of my SDK setup.

 

Thanks,

Steve

 

 

 


[PATCH yocto-autobuilder-helper] config.json: do not add separate gdk-pixbuf jpg/png modules to images

Alexander Kanavin
 

JPG/PNG have become builtin in gdk-pixbuf 2.42.x
(other formats are still external).

Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
---
config.json | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/config.json b/config.json
index 52f39ef..3e12d3f 100644
--- a/config.json
+++ b/config.json
@@ -559,7 +559,7 @@
"MULTILIBS = 'multilib:lib32'",
"DEFAULTTUNE_virtclass-multilib-lib32 = 'x86'",
"RPM_PREFER_ELF_ARCH = '1'",
- "IMAGE_INSTALL_append = ' lib32-connman-gnome gdk-pixbuf-loader-jpeg lib32-gdk-pixbuf-loader-jpeg gdk-pixbuf-loader-png lib32-gdk-pixbuf-loader-png pango-module-basic-fc lib32-pango-module-basic-fc'"
+ "IMAGE_INSTALL_append = ' lib32-connman-gnome pango-module-basic-fc lib32-pango-module-basic-fc'"
]
},
"step4" : {
@@ -574,7 +574,7 @@
"MULTILIBS = 'multilib:lib32'",
"DEFAULTTUNE_virtclass-multilib-lib32 = 'x86'",
"RPM_PREFER_ELF_ARCH = '1'",
- "IMAGE_INSTALL_append = ' lib32-connman-gnome gdk-pixbuf-loader-jpeg lib32-gdk-pixbuf-loader-jpeg gdk-pixbuf-loader-png lib32-gdk-pixbuf-loader-png pango-module-basic-fc lib32-pango-module-basic-fc'"
+ "IMAGE_INSTALL_append = ' lib32-connman-gnome pango-module-basic-fc lib32-pango-module-basic-fc'"
]
},
"step5" : {
--
2.31.1


Re: [meta-raspberrypi] Booting a Raspberry Pi 4 using PXE

Manuel Wagesreither
 

Hello Anton,

Am Mi, 5. Mai 2021, um 15:34, schrieb Anton Antonov:
I don't know what exactly you mean by "whenever the Raspi is booting over the network".
When a machine boots from network (i,e. using DHCP/BOOTP) then usually DHCP server points to, for example, a TFTP server where the kernel and initramfs should be obtained from and kernel parameters. So, you need to check your DHCP/TFTP/etc servers configuration for kernel parameters.

The boot files (kernel, kernel parameters, device tree overlays, ...) served by TFTP are bit-identical to the ones present at `/boot` of the usb stick.

When I boot over PXE/BOOTP/DHCP/TFTP/etc, something seems to replace all occurences of `8250.nr_uarts=1` with `8250.nr_uarts=0`. When I boot using usb drive using the exact same files, this doesn't happen and uart is active.


Regards,
Manuel


Re: SSH_AUTH_SOCK unavailable when pulling modules #golang

Quentin Schulz
 

Hi Sven,

On Wed, May 05, 2021 at 06:37:41AM -0700, Sven via lists.yoctoproject.org wrote:
Hi Quentin,

Thanks for your reply. Did you have success with this technique when compiling a go-mod recipe where some of the go dependencies sit in private repos? The standard git fetcher works for me with private repos, that is not the problem.
No, I do not use any custom go-based recipe.

BR,
Quentin


Re: SSH_AUTH_SOCK unavailable when pulling modules #golang

Sven
 

Hi Quentin,

Thanks for your reply. Did you have success with this technique when compiling a go-mod recipe where some of the go dependencies sit in private repos? The standard git fetcher works for me with private repos, that is not the problem.

Best regards,
Sven

2081 - 2100 of 55458