1. yocto@lists.yoctoproject.org
  2. Messages
   Date   
Re: poky thud: qtscript fails to build with undefined reference to `cti_vm_throw'

Jochen Behnke
 

Hello Khem,
>Gesendet: Freitag, 01. November 2019 um 18:23 Uhr
>Von: "Khem Raj" <raj.khem@...>
>An: JK.Behnke@...
>Cc: "Yocto Project" <yocto@...>
>Betreff: Re: [yocto] poky thud: qtscript fails to build with undefined reference to `cti_vm_throw'
>On Fri, Nov 1, 2019 at 2:12 AM <JK.Behnke@...> wrote:
>>
>> Hello,
>>
>> I tried to build a poky SDK with QT5 support (I am using poky thud).
>> Unfortunately this failed while bitbaking qtscript.
>> When executing "bitbake qtscript" directly I get the same error.
>>
>> Here are the IMHO relevant lines of the huge log.do_compile file.
>> I have replaced the long paths by <...> for clarity.
>>
>> -- multiple warnings ---
>> ... warning: 'template<class> class std::auto_ptr' is deprecated [-Wdeprecated-declarations]
>> ---
>>
>> -- warning ---
>> In member function 'allocatePropertyStorageInline',
>> inlined from 'allocatePropertyStorage' at <...>/git/src/3rdparty/javascriptcore/JavaScriptCore/runtime/JSObject.cpp:546:34:
>> <...>/git/src/3rdparty/javascriptcore/JavaScriptCore/runtime/JSObject.h:679:68: warning: argument 1 value '4294967295' exceeds maximum object size 2147483647 [-Walloc-size-larger-than=]
>> PropertyStorage newPropertyStorage = new EncodedJSValue[newSize];
>> ^
>> <...>/git/src/3rdparty/javascriptcore/JavaScriptCore/runtime/JSObject.h: In member function 'allocatePropertyStorage':
>> <...>/recipe-sysroot/usr/include/c++/8.2.0/new:122:7: note: in a call to allocation function 'operator new []' declared here
>> void* operator new[](std::size_t) _GLIBCXX_THROW (std::bad_alloc)
>> ---
>>
>> --- error ---
>> <...>/recipe-sysroot-native/usr/bin/i686-poky-linux/../../libexec/i686-poky-linux/gcc/i686-poky-linux/8.2.0/ld: <...>/recipe-sysroot-native/usr/bin/i686-poky-linux/../../libexec/i686-poky-linux/gcc/i686-poky-linux/8.2.0/ld: DWARF error: invalid abstract instance DIE ref
>> /tmp/ccSwzRoN.ltrans0.ltrans.o: in function `ctiVMThrowTrampoline':
>> <artificial>:(.text+0x1f): undefined reference to `cti_vm_throw'
>> collect2: error: ld returned 1 exit status
>> Makefile:666: recipe for target '../../lib/libQt5Script.so.5.12.2' failed
>> ---
>>
>> Has anyone an idea what could be the problem?
>>
>
>perhaps we need to patch binutils/ld with
>
>https://patches-gcc.linaro.org/patch/9614/
>
>see
>https://sourceware.org/bugzilla/show_bug.cgi?id=23425[https://sourceware.org/bugzilla/show_bug.cgi?id=23425]
>
>if you could try it out and report back that would be awesome
>
I have applied the patch the bottom of this page  https://patches-gcc.linaro.org/patch/9614/

Unfortunately this did not solve the problem.
Now I get this error: "DWARF error: could not find abbrev number 72"
 
Here the complete error message:
/home/behnkjoc/prc2020/poky/build-tca5-32/tmp/work/core2-32-poky-linux/qtscript/5.12.2+gitAUTOINC+6c0edaf30c-r0/recipe-sysroot-native/usr/bin/i686-poky-linux/../../libexec/i686-poky-linux/gcc/i686-poky-linux/8.2.0/ld: /home/behnkjoc/prc2020/poky/build-tca5-32/tmp/work/core2-32-poky-linux/qtscript/5.12.2+gitAUTOINC+6c0edaf30c-r0/recipe-sysroot-native/usr/bin/i686-poky-linux/../../libexec/i686-poky-linux/gcc/i686-poky-linux/8.2.0/ld: DWARF error: could not find abbrev number 72
/tmp/cccEIw32.ltrans0.ltrans.o: in function `ctiVMThrowTrampoline':
<artificial>:(.text+0x1f): undefined reference to `cti_vm_throw'
collect2: error: ld returned 1 exit status
 

Regards
Jochen
 
Yocto Project Newcomer & Unassigned Bugs - Help Needed

Stephen Jolley
 

All,

 

The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading:

 

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs

 

The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project.  If anyone can help, please take ownership of the bug and send patches!  If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 298 unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out with these.  Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system.  There are also roughly four different "priority" classes right now, “3.1”, “3.2, "3.99" and "Future", the more pressing/urgent issues being in "3.1" and then “3.2”.

 

Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp.pm@...) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account).  The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage#Unassigned_or_Newcomer_Bugs


Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

7867 SW Bayberry Dr., Beaverton, OR 97007

(    Cell:                (208) 244-4460

* Email:                 sjolley.yp.pm@...
Re: [meta-raspberrypi] poky linux build fails if ARM erratum mfix linker switch is specified

Steve Pavao
 



On Nov 4, 2019, at 11:32 AM, Steve Pavao <stevep@...> wrote:


On Nov 4, 2019, at 11:16 AM, Steve Pavao <stevep@...> wrote:


On Nov 4, 2019, at 11:11 AM, Adrian Bunk <bunk@...> wrote:

On Mon, Nov 04, 2019 at 10:48:57AM -0500, Steve Pavao wrote:

On Nov 3, 2019, at 1:25 PM, Adrian Bunk <bunk@...> wrote:

On Sun, Nov 03, 2019 at 05:56:45PM +0000, Andrei Gherzan wrote:
On 3 November 2019 13:18:53 GMT, Khem Raj <raj.khem@...> wrote:
On Sun, Nov 3, 2019 at 2:46 AM Andrei Gherzan <andrei@...>
wrote:
I was thinking about this. The erratum seems to show that this
applies
to all revisions of a53. So it sounds like we should add it in
`tune-cortexa53.inc`.


Up to r0b4 only so maybe not all a53 implementations are impacted


As far as I know that is the latest revision. Do you mean that newer revision might come up with this fixed? 

It is fixed in some r0p4 implementations, indicated in REVIDR[8].

I am closer to understanding why I experience an error when building with the ARM errata switches.

I believe it is related to 32-bit app support in my poky Linux 64-bit build (I add this to support vcgencmd and vcdbg 32-bit apps.)

When I remove the 32-bit support, the build completes OK.  As of now, adding the following seems to work fine to acheive this:

TARGET_CC_ARCH_append += " -mfix-cortex-a53-843419 -mfix-cortex-a53-835769”

Something in the following block seems to be the culprit.:

# for vcgencmd and vcdbg 32-bit executable support in the OS image (comment out for -c populate_sdk)
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "armv7a"
IMAGE_INSTALL_append += " vcgencmd lib32-glibc lib32-libgcc lib32-libstdc++ vcdbg rpi-setup \
“

I will post again when I have localized the build problem further.  Maybe there’s some 64-bit vs. 32-bit build confusion going on, and the armv7a default tune switch for 32-bits is colliding with the errata switches.

The errata switches are only valid for aarch64, not for armv7a.
There is likely some kind of "invalid option" earlier in your build.

To conitnue to be able to use the 32-bit app support, perhaps I must do this:

DEFAULTTUNE_virtclass-multilib-lib32 = “armv7a -mno-fix-cortex-a53-843419 -mno-fix-cortex-a53-835769”

This doesn’t work.

If I wish to keep the 32-bit app support in my build, I’ll need to devise a way to make sure those ARM errata flags are only applied to the aarch64 portion of the compile/link for the target, not to the multilib 32-bit app support portion.

Andrei and/or Khem,

Could you advise an approach that allows to use the ARM errata switches for the aarch64 portion of the build for the target, but which will NOT specify the ARM errata switches for our supplementary 32-bit portion of the build for the target?  (This supplementary 32-bit portion of the build is to support the 32-bit vcgencmd app, and contains multilib and some additional 32-bit libraires.  Please see earlier post for the syntax we use in our local.conf.)

Steve Pavao
Korg R&D
help with meta-java

Shockley, Timothy <timothy.shockley@...>
 

Helllo,

 

I am looking for some help with meta-java, specifically upgrading to zeus branch and also upgrading openjdk to a more recent release in order to address CVEs. Wondering if there is anyone else working / needing this?

 

Thanks,

Tim Shockley

 
Re: [meta-raspberrypi] poky linux build fails if ARM erratum mfix linker switch is specified

Steve Pavao
 


On Nov 4, 2019, at 11:16 AM, Steve Pavao <stevep@...> wrote:


On Nov 4, 2019, at 11:11 AM, Adrian Bunk <bunk@...> wrote:

On Mon, Nov 04, 2019 at 10:48:57AM -0500, Steve Pavao wrote:

On Nov 3, 2019, at 1:25 PM, Adrian Bunk <bunk@...> wrote:

On Sun, Nov 03, 2019 at 05:56:45PM +0000, Andrei Gherzan wrote:
On 3 November 2019 13:18:53 GMT, Khem Raj <raj.khem@...> wrote:
On Sun, Nov 3, 2019 at 2:46 AM Andrei Gherzan <andrei@...>
wrote:
I was thinking about this. The erratum seems to show that this
applies
to all revisions of a53. So it sounds like we should add it in
`tune-cortexa53.inc`.


Up to r0b4 only so maybe not all a53 implementations are impacted


As far as I know that is the latest revision. Do you mean that newer revision might come up with this fixed? 

It is fixed in some r0p4 implementations, indicated in REVIDR[8].

I am closer to understanding why I experience an error when building with the ARM errata switches.

I believe it is related to 32-bit app support in my poky Linux 64-bit build (I add this to support vcgencmd and vcdbg 32-bit apps.)

When I remove the 32-bit support, the build completes OK.  As of now, adding the following seems to work fine to acheive this:

TARGET_CC_ARCH_append += " -mfix-cortex-a53-843419 -mfix-cortex-a53-835769”

Something in the following block seems to be the culprit.:

# for vcgencmd and vcdbg 32-bit executable support in the OS image (comment out for -c populate_sdk)
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "armv7a"
IMAGE_INSTALL_append += " vcgencmd lib32-glibc lib32-libgcc lib32-libstdc++ vcdbg rpi-setup \
“

I will post again when I have localized the build problem further.  Maybe there’s some 64-bit vs. 32-bit build confusion going on, and the armv7a default tune switch for 32-bits is colliding with the errata switches.

The errata switches are only valid for aarch64, not for armv7a.
There is likely some kind of "invalid option" earlier in your build.

To conitnue to be able to use the 32-bit app support, perhaps I must do this:

DEFAULTTUNE_virtclass-multilib-lib32 = “armv7a -mno-fix-cortex-a53-843419 -mno-fix-cortex-a53-835769”

This doesn’t work.

If I wish to keep the 32-bit app support in my build, I’ll need to devise a way to make sure those ARM errata flags are only applied to the aarch64 portion of the compile/link for the target, not to the multilib 32-bit app support portion.

Thanks to all of you for your thoughts so far.

Steve Pavao
Korg R&D
Re: [meta-raspberrypi] poky linux build fails if ARM erratum mfix linker switch is specified

Steve Pavao
 


On Nov 4, 2019, at 11:11 AM, Adrian Bunk <bunk@...> wrote:

On Mon, Nov 04, 2019 at 10:48:57AM -0500, Steve Pavao wrote:

On Nov 3, 2019, at 1:25 PM, Adrian Bunk <bunk@...> wrote:

On Sun, Nov 03, 2019 at 05:56:45PM +0000, Andrei Gherzan wrote:
On 3 November 2019 13:18:53 GMT, Khem Raj <raj.khem@...> wrote:
On Sun, Nov 3, 2019 at 2:46 AM Andrei Gherzan <andrei@...>
wrote:
I was thinking about this. The erratum seems to show that this
applies
to all revisions of a53. So it sounds like we should add it in
`tune-cortexa53.inc`.


Up to r0b4 only so maybe not all a53 implementations are impacted


As far as I know that is the latest revision. Do you mean that newer revision might come up with this fixed? 

It is fixed in some r0p4 implementations, indicated in REVIDR[8].

I am closer to understanding why I experience an error when building with the ARM errata switches.

I believe it is related to 32-bit app support in my poky Linux 64-bit build (I add this to support vcgencmd and vcdbg 32-bit apps.)

When I remove the 32-bit support, the build completes OK.  As of now, adding the following seems to work fine to acheive this:

TARGET_CC_ARCH_append += " -mfix-cortex-a53-843419 -mfix-cortex-a53-835769”

Something in the following block seems to be the culprit.:

# for vcgencmd and vcdbg 32-bit executable support in the OS image (comment out for -c populate_sdk)
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "armv7a"
IMAGE_INSTALL_append += " vcgencmd lib32-glibc lib32-libgcc lib32-libstdc++ vcdbg rpi-setup \
“

I will post again when I have localized the build problem further.  Maybe there’s some 64-bit vs. 32-bit build confusion going on, and the armv7a default tune switch for 32-bits is colliding with the errata switches.

The errata switches are only valid for aarch64, not for armv7a.
There is likely some kind of "invalid option" earlier in your build.

To conitnue to be able to use the 32-bit app support, perhaps I must do this:

DEFAULTTUNE_virtclass-multilib-lib32 = “armv7a -mno-fix-cortex-a53-843419 -mno-fix-cortex-a53-835769”

I’ll give it a try.

- Steve Pavao
Korg R&D
Re: [meta-raspberrypi] poky linux build fails if ARM erratum mfix linker switch is specified

Adrian Bunk
 

On Mon, Nov 04, 2019 at 10:48:57AM -0500, Steve Pavao wrote:

On Nov 3, 2019, at 1:25 PM, Adrian Bunk <bunk@...> wrote:

On Sun, Nov 03, 2019 at 05:56:45PM +0000, Andrei Gherzan wrote:
On 3 November 2019 13:18:53 GMT, Khem Raj <raj.khem@...> wrote:
On Sun, Nov 3, 2019 at 2:46 AM Andrei Gherzan <andrei@...>
wrote:
I was thinking about this. The erratum seems to show that this
applies
to all revisions of a53. So it sounds like we should add it in
`tune-cortexa53.inc`.
Up to r0b4 only so maybe not all a53 implementations are impacted
As far as I know that is the latest revision. Do you mean that newer revision might come up with this fixed?
It is fixed in some r0p4 implementations, indicated in REVIDR[8].
I am closer to understanding why I experience an error when building with the ARM errata switches.

I believe it is related to 32-bit app support in my poky Linux 64-bit build (I add this to support vcgencmd and vcdbg 32-bit apps.)

When I remove the 32-bit support, the build completes OK. As of now, adding the following seems to work fine to acheive this:

TARGET_CC_ARCH_append += " -mfix-cortex-a53-843419 -mfix-cortex-a53-835769”

Something in the following block seems to be the culprit.:

# for vcgencmd and vcdbg 32-bit executable support in the OS image (comment out for -c populate_sdk)
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "armv7a"
IMAGE_INSTALL_append += " vcgencmd lib32-glibc lib32-libgcc lib32-libstdc++ vcdbg rpi-setup \
“

I will post again when I have localized the build problem further. Maybe there’s some 64-bit vs. 32-bit build confusion going on, and the armv7a default tune switch for 32-bits is colliding with the errata switches.
The errata switches are only valid for aarch64, not for armv7a.
There is likely some kind of "invalid option" earlier in your build.

- Steve Pavao
Korg R&D
cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Re: [meta-raspberrypi] poky linux build fails if ARM erratum mfix linker switch is specified

Steve Pavao
 

On Nov 3, 2019, at 1:25 PM, Adrian Bunk <bunk@...> wrote:

On Sun, Nov 03, 2019 at 05:56:45PM +0000, Andrei Gherzan wrote:
On 3 November 2019 13:18:53 GMT, Khem Raj <raj.khem@...> wrote:
On Sun, Nov 3, 2019 at 2:46 AM Andrei Gherzan <andrei@...>
wrote:
I was thinking about this. The erratum seems to show that this
applies
to all revisions of a53. So it sounds like we should add it in
`tune-cortexa53.inc`.
Up to r0b4 only so maybe not all a53 implementations are impacted
As far as I know that is the latest revision. Do you mean that newer revision might come up with this fixed?
It is fixed in some r0p4 implementations, indicated in REVIDR[8].
I am closer to understanding why I experience an error when building with the ARM errata switches.

I believe it is related to 32-bit app support in my poky Linux 64-bit build (I add this to support vcgencmd and vcdbg 32-bit apps.)

When I remove the 32-bit support, the build completes OK. As of now, adding the following seems to work fine to acheive this:

TARGET_CC_ARCH_append += " -mfix-cortex-a53-843419 -mfix-cortex-a53-835769”

Something in the following block seems to be the culprit.:

# for vcgencmd and vcdbg 32-bit executable support in the OS image (comment out for -c populate_sdk)
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "armv7a"
IMAGE_INSTALL_append += " vcgencmd lib32-glibc lib32-libgcc lib32-libstdc++ vcdbg rpi-setup \
“

I will post again when I have localized the build problem further. Maybe there’s some 64-bit vs. 32-bit build confusion going on, and the armv7a default tune switch for 32-bits is colliding with the errata switches.

- Steve Pavao
Korg R&D
bitbake SRC_URI fetch Azure DevOps repository Azure DevOps Services Basic

Samuel Jiang (江騏先) <Samuel.Jiang@...>
 

Dear yocto developer,
The below disscussed about azure devops clone issue including test result with Microsoft support team member.
We wonder know how Bitbake access repository through SSH. Does it different between git and Azue DevOps?

Thanks,

Samuel Jiang
---------- Forwarded message ----------
From: Alex Chong (Shanghai Wicresoft Co,.Ltd.) <v-chucho@...>
Date: 2019年10月31日 PM5:39 [+0800]
To: Samuel Jiang (江騏先) <Samuel.Jiang@...>
Cc: support <support@...>, Alex Chong (Shanghai Wicresoft Co,.Ltd.) <v-chucho@...>
Subject: RE: 119102923000220 use yocto bitbake SRC_URI fetch Azure DevOps repository Azure DevOps Services Basic

Hi Samuel,

 

Thank you for reply.

 

I test and read the BitBake doc, let me share with you my finding and analysis.

  1. I have verified that our Azure DevOps Organization Repo could be clone through SSH authentication successfully.
  1. I create a new SSH key and add it to Azure DevOps SSH public keys.

  1. Then I use git clone command and clone this repo successfully. The url is “v-chucho-microsoft@...:v3/v-chucho-microsoft/testCodeCoverage/testCodeCoverage”

My testing verify that SSH Authentication is available, and the url given by Azure DevOps is correct.

 

  1. Then I also test it in GitHub, and succeed. The only difference is the url of GitHub is “git@...:xxxxxxxxxxxxxxxxxx.git”

 

  1. So let’s come back to BitBake. I read more of the BitBake doc.( https://www.yoctoproject.org/docs/1.8/bitbake-user-manual/bitbake-user-manual.html#bb-fetchers) . Your command SRC_URI = "git://quanta01@...:v3/quanta01/OpenBMC/crashdump;protocol=ssh;nobranch=1". The BitBake example is below.

We can see that the BitBake syntax is like git SSH but not Azure DevOps SSH. Do you try to use this command clone a repo from GitHub?

 

  1. Then I read the doc you shared. The customer also met your issue when trying to clone Azure DevOps repo with SSH url. In my understanding, seems BitBake Git fetcher is good for Git SSH but not ready to access the Azure DevOps SSH.

 

Action Plan

Could you involve BitBake support team? We can deliver this testing result and consult them how BitBake access Azure DevOps through SSH.

 

If you have any conern or query, please feel free to let me know.

 

Best Regards,

 

Alex Chong

 

image001

Support Engineer

Microsoft APAC Developer Support Team

Customer Service & Support (CSS)

Email: v-chucho@...

Office: +86 (21) 52638610

Time zone: (UTC+08:00) Beijing, Chongqing, Hong Kong, Urumqi

Working time: 9:00am-6:00pm, Mon-Tue-Wed-Thu-Fri

 

From: Samuel Jiang (江騏先) <Samuel.Jiang@...>
Sent: Thursday, October 31, 2019 12:16 PM
To: Alex Chong (Shanghai Wicresoft Co,.Ltd.) <v-chucho@...>
Cc: support <support@...>
Subject: RE: 119102923000220 use yocto bitbake SRC_URI fetch Azure DevOps repository Azure DevOps Services Basic

 

Hi Alex,

I catch same problem on the yocto mail list
link: https://lists.yoctoproject.org/pipermail/yocto/2018-October/042736.html

when I use SRC_URI = "git://quanta01@...:v3/quanta01/OpenBMC/crashdump;protocol=ssh;nobranch=1"

the bitbake response below error message:
git -c core.fsyncobjectfiles=0 ls-remote ssh://quanta01@...:v3/quanta01/OpenBMC/crashdump  failed with exit code 128, output:

ssh: Could not resolve hostname vs-ssh.visualstudio.com:v3: Name or service not known

fatal: Could not read from remote repository.

I think the bitbake call “git ls-remote” command however it could not parser below host vs-ssh.visualstudio.com:v3

Could you help confirm the  “git ls-remote”command could work on ssh method clone with ssh:// prefix?

BTW, the protocol will define the uri prefix, I didn’t find any way removing this prefix.

Thanks,
Samuel Jiang

 

From: Alex Chong (Shanghai Wicresoft Co,.Ltd.) <v-chucho@...>
Sent: Thursday, October 31, 2019 10:32 AM
To: Samuel Jiang (江騏先) <Samuel.Jiang@...>
Cc: Alex Chong (Shanghai Wicresoft Co,.Ltd.) <v-chucho@...>; support <support@...>
Subject: RE: 119102923000220 use yocto bitbake SRC_URI fetch Azure DevOps repository Azure DevOps Services Basic

 

Hi Samuel,

 

How are you?

 

Do you try our Azure DevOps SSH authentication? Do you contact BitBake support for help? Is there any suggestion or new issue? Please feel free to contact me if there is something I can do for you.

 

Best Regards,

 

Alex Chong

 

image001

Support Engineer

Microsoft APAC Developer Support Team

Customer Service & Support (CSS)

Email: v-chucho@...

Office: +86 (21) 52638610

Time zone: (UTC+08:00) Beijing, Chongqing, Hong Kong, Urumqi

Working time: 9:00am-6:00pm, Mon-Tue-Wed-Thu-Fri

 

From: Alex Chong (Shanghai Wicresoft Co,.Ltd.) <v-chucho@...>
Sent: Tuesday, October 29, 2019 3:50 PM
To: Samuel.Jiang@...
Cc: Alex Chong (Shanghai Wicresoft Co,.Ltd.) <v-chucho@...>
Subject: 119102923000220 use yocto bitbake SRC_URI fetch Azure DevOps repository Azure DevOps Services Basic

 

 

 

Image removed by sender. 郵件模板標頭

 

Hi Samuel,

 

Thank you for contacting Microsoft.

 

My name is Alex and I am the Microsoft Support Engineer from APGC who will be working with you on this support request . You can reach me using the contact information in my signature.

 

I just called you at +886 3 327 2345 and had a quick discussion.

Issue Description

1.Customer is using a 3rd-party application BitBake to clone Azure DevOps repo. 

2.Customer could fetch file from https url successfully.

3.Customer wants to know whether Azure DevOps support SSH authentication method.

 

Analysis

  • Create your SSH keys

    Create your SSH keys with the ssh-keygen command from the bash prompt.

  • Add the public key to your Azure DevOps Organization

Open your security settings by browsing to the web portal and selecting your avatar in the upper right of the user interface. Select Security in the menu that appears.

Select SSH public keys , then select +New Key.

Copy the contents of the public key (for example, id_rsa.pub) that you generated into the Public Key Data field.

 

 

  • Clone the Git repository with SSH

Copy the SSH clone URL from the web portal. In this example the SSL clone URL is for a repo in an organization named fabrikam-fiber, as indicated by the first part of the URL after dev.azure.com.

Run git clone from the command prompt.

 

This is a 3rd-party application which is out of our Microsoft support. Our Azure DevOps has SSH authentication method. But I have no experience whether there is such option in BitBake. 

I did some research on this application and find Git fetcher and ssh:// fetcher functionalities. In my understanding, it should support git with SSH or SSH fecher directly. It's suggested to consult BitBake support for more details of these 2 fetchers. If there is something our Microsoft could help, please feel free to involve me directly.

 

If you have any concern or query, please feel free to contact me.

 

Best Regards,

 

Alex Chong

 

Support Engineer

Microsoft APAC Developer Support Team

Customer Service & Support (CSS)

Email: v-chucho@...

Office: +86 (21) 52638610

Time zone: (UTC+08:00) Beijing, Chongqing, Hong Kong, Urumqi

Working time: 9:00am-6:00pm, Mon-Tue-Wed-Thu-Fri

 

這則來自 Microsoft 的訊息是您或貴公司所購買或參與之計畫、服務或產品的重要部分。請檢閱我們的線上隱私權聲明

Microsoft Corporation
One Microsoft Way
Redmond, WA, USA 98052

Image removed by sender. Microsoft
Re: [meta-raspberrypi] poky linux build fails if ARM erratum mfix linker switch is specified

Adrian Bunk
 

On Sun, Nov 03, 2019 at 05:56:45PM +0000, Andrei Gherzan wrote:
On 3 November 2019 13:18:53 GMT, Khem Raj <raj.khem@...> wrote:
On Sun, Nov 3, 2019 at 2:46 AM Andrei Gherzan <andrei@...>
wrote:
I was thinking about this. The erratum seems to show that this
applies
to all revisions of a53. So it sounds like we should add it in
`tune-cortexa53.inc`.
Up to r0b4 only so maybe not all a53 implementations are impacted
As far as I know that is the latest revision. Do you mean that newer revision might come up with this fixed?
It is fixed in some r0p4 implementations, indicated in REVIDR[8].

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Re: [meta-raspberrypi] poky linux build fails if ARM erratum mfix linker switch is specified

Khem Raj
 



On Sun, Nov 3, 2019 at 9:56 AM Andrei Gherzan <andrei@...> wrote:


On 3 November 2019 13:18:53 GMT, Khem Raj <raj.khem@...> wrote:
>On Sun, Nov 3, 2019 at 2:46 AM Andrei Gherzan <andrei@...>
>wrote:
>
>> On 01/11/2019 17:18, Khem Raj wrote:
>> > On Fri, Nov 1, 2019 at 1:28 AM Andrei Gherzan <andrei@...>
>wrote:
>> >>
>> >> Hi Steve,
>> >>
>> >> On 01/11/2019 05:32, Steve Pavao wrote:
>> >>> poky linux build fails when ARM erratum mfix linker switch is
>specified
>> >>> in local.conf:
>> >>>
>> >>> TARGET_LD_ARCH_append += " -mfix-cortex-a53-843419”
>> >>>
>> >>> causes build failure.
>> >>>
>> >>> Please advise how to use this switch successfully.  I am synced
>current
>> >>> in master branch in all layers as of today.  The switch causes
>libtool
>> >>> link to fail due to missing libbz2.so.  If I don’t specify the
>switch,
>> >>> the build completes without errors.
>> >>>
>> >>> It is important to be able to build poky linux with this switch
>to
>> avoid
>> >>> certain crash conditions as described in the ARM errata document.
>> >>
>> >> I haven't tried this erratum fix. It is indeed implemented at the
>> >> linker's lever. It's curious though to see the bz2 dependency. Can
>you
>> >> share the specific error? I assume you are doing this on RPi3.
>> >>
>> >
>> > this will impact rpi3 in 64bit mode, don't think 32bit needs this.
>I
>> > think its best to
>> > add this option in raspberrypi3-64.conf perhaps via TUNE_CCARGS
>>
>> I was thinking about this. The erratum seems to show that this
>applies
>> to all revisions of a53. So it sounds like we should add it in
>> `tune-cortexa53.inc`.
>>
>
>Up to r0b4 only so maybe not all a53 implementations are impacted
>

As far as I know that is the latest revision. Do you mean that newer revision might come up with this fixed?

Rpi3 is one of many cortex a53 implementations 

--
Andrei Gherzan
gpg: rsa4096/D4D94F67AD0E9640 | t: @agherzan
Re: [meta-raspberrypi] poky linux build fails if ARM erratum mfix linker switch is specified

Andrei Gherzan
 

On 3 November 2019 13:18:53 GMT, Khem Raj <raj.khem@...> wrote:
On Sun, Nov 3, 2019 at 2:46 AM Andrei Gherzan <andrei@...>
wrote:

On 01/11/2019 17:18, Khem Raj wrote:
On Fri, Nov 1, 2019 at 1:28 AM Andrei Gherzan <andrei@...>
wrote:

Hi Steve,

On 01/11/2019 05:32, Steve Pavao wrote:
poky linux build fails when ARM erratum mfix linker switch is
specified
in local.conf:

TARGET_LD_ARCH_append += " -mfix-cortex-a53-843419”

causes build failure.

Please advise how to use this switch successfully. I am synced
current
in master branch in all layers as of today. The switch causes
libtool
link to fail due to missing libbz2.so. If I don’t specify the
switch,
the build completes without errors.

It is important to be able to build poky linux with this switch
to
avoid
certain crash conditions as described in the ARM errata document.
I haven't tried this erratum fix. It is indeed implemented at the
linker's lever. It's curious though to see the bz2 dependency. Can
you
share the specific error? I assume you are doing this on RPi3.
this will impact rpi3 in 64bit mode, don't think 32bit needs this.
I
think its best to
add this option in raspberrypi3-64.conf perhaps via TUNE_CCARGS
I was thinking about this. The erratum seems to show that this
applies
to all revisions of a53. So it sounds like we should add it in
`tune-cortexa53.inc`.
Up to r0b4 only so maybe not all a53 implementations are impacted
As far as I know that is the latest revision. Do you mean that newer revision might come up with this fixed?

--
Andrei Gherzan
gpg: rsa4096/D4D94F67AD0E9640 | t: @agherzan
Re: [meta-raspberrypi] poky linux build fails if ARM erratum mfix linker switch is specified

Khem Raj
 



On Sun, Nov 3, 2019 at 2:46 AM Andrei Gherzan <andrei@...> wrote:
On 01/11/2019 17:18, Khem Raj wrote:
> On Fri, Nov 1, 2019 at 1:28 AM Andrei Gherzan <andrei@...> wrote:
>>
>> Hi Steve,
>>
>> On 01/11/2019 05:32, Steve Pavao wrote:
>>> poky linux build fails when ARM erratum mfix linker switch is specified
>>> in local.conf:
>>>
>>> TARGET_LD_ARCH_append += " -mfix-cortex-a53-843419”
>>>
>>> causes build failure.
>>>
>>> Please advise how to use this switch successfully.  I am synced current
>>> in master branch in all layers as of today.  The switch causes libtool
>>> link to fail due to missing libbz2.so.  If I don’t specify the switch,
>>> the build completes without errors.
>>>
>>> It is important to be able to build poky linux with this switch to avoid
>>> certain crash conditions as described in the ARM errata document.
>>
>> I haven't tried this erratum fix. It is indeed implemented at the
>> linker's lever. It's curious though to see the bz2 dependency. Can you
>> share the specific error? I assume you are doing this on RPi3.
>>
>
> this will impact rpi3 in 64bit mode, don't think 32bit needs this. I
> think its best to
> add this option in raspberrypi3-64.conf perhaps via TUNE_CCARGS

I was thinking about this. The erratum seems to show that this applies
to all revisions of a53. So it sounds like we should add it in
`tune-cortexa53.inc`.

Up to r0b4 only so maybe not all a53 implementations are impacted 

--
Andrei Gherzan
Re: [meta-raspberrypi] poky linux build fails if ARM erratum mfix linker switch is specified

Andrei Gherzan
 

On 01/11/2019 17:18, Khem Raj wrote:
On Fri, Nov 1, 2019 at 1:28 AM Andrei Gherzan <andrei@...> wrote:

Hi Steve,

On 01/11/2019 05:32, Steve Pavao wrote:
poky linux build fails when ARM erratum mfix linker switch is specified
in local.conf:

TARGET_LD_ARCH_append += " -mfix-cortex-a53-843419”

causes build failure.

Please advise how to use this switch successfully. I am synced current
in master branch in all layers as of today. The switch causes libtool
link to fail due to missing libbz2.so. If I don’t specify the switch,
the build completes without errors.

It is important to be able to build poky linux with this switch to avoid
certain crash conditions as described in the ARM errata document.
I haven't tried this erratum fix. It is indeed implemented at the
linker's lever. It's curious though to see the bz2 dependency. Can you
share the specific error? I assume you are doing this on RPi3.
this will impact rpi3 in 64bit mode, don't think 32bit needs this. I
think its best to
add this option in raspberrypi3-64.conf perhaps via TUNE_CCARGS
I was thinking about this. The erratum seems to show that this applies to all revisions of a53. So it sounds like we should add it in `tune-cortexa53.inc`.

--
Andrei Gherzan
Kernel modules packaged but not installed

Dimitris Tassopoulos <dimtass@...>
 

Hi all. I have a weird issue with the kernel modules not being installed in the image and also not packaged.
I see the packages for individual "kernel-module-*.ipk" modules but the "kernel-modules_*.ipk" is always
empty.

I'm also able to see the "modules-${MACHINE}.tgz" in DEPLOYDIR which has all the modules in there, just fine.

In my image file I've also set this:
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules"

This is the kernel recipe:

And this is the conf folder

For some reason I can't figure out why modules are not ending up in the image.

If I do it manually in a do_install_append like this:
do_install_append() {
    # Install kernel-modules
install -d ${D}${nonarch_base_libdir}
    oe_runmake INSTALL_MOD_PATH=${D} modules_install
}

then it works, but I guess that shouldn't be the right way.

Any suggestions or ideas?

Thanks!
Re: [meta-qt5] How to contribute patches for qtwebengine in meta-qt5?

Tanu Kaskinen
 

On Fri, 2019-11-01 at 13:24 +0100, Martin Jansa wrote:
This patch is already included in 5.13.2 upgrade (ready in zeus-next
and master-next branches), so you don't need to do anything.
Okay, that's great!

Otherwise like Khem says, submit the change for meta-qt5 repository
like any other layer.

The meta-qt5/qt* repositories are used to maintain the patches, but
usually only me is updating them to keep in sync with meta-qt5 and
then syncing from them to meta-qt5 with git format-patch --no-
numbered --no-signature when doing bigger rebase like when upgrading
to newer Qt version.
Thanks for the information!

-- Tanu


On Fri, Nov 1, 2019 at 11:02 AM Tanu Kaskinen <tanuk@...> wrote:
Hi all!

The meta-qt5 readme says that contributions should be made by forking
the meta-qt5 repository on GitHub, but when I look at the qtwebengine
recipe, it looks like patches are pulled from
https://github.com/meta-qt5/qtwebengine-chromium, and that repository
looks like the patches are kept in a particular order so adding a patch
at the top is perhaps not what I should do.

It's not clear to me how I should submit a patch in this case. The
patch in question would be a simple backport of this upstream commit:
https://codereview.qt-project.org/gitweb?p=qt/qtwebengine-chromium.git;a=commitdiff;h=b84e8682b312fb16b16ffb9591415067ceae69f8

It's needed for not breaking qtwebengine when upgrading PulseAudio to
13.0.

--
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk
Re: Debugging custom python code in recipes

Ross Burton <ross.burton@...>
 

On 01/11/2019 21:30, Alan Martinović wrote:
Cool, thanks.
This one seems to be the most up to date from the python debugger wrappers:
https://github.com/ionelmc/python-remote-pdb
Entirely worth writing a proper class and pushing a layer somewhere.

The `shell_wait()` in your bbclass is related to the pdb() functionality?
No, it's just a way of making shell tasks pause for inspecting the state of the build tree during a task. I was debugging some nasty packaging failures...

Ross
Re: Debugging custom python code in recipes

Alan Martinović
 

Cool, thanks.

This one seems to be the most up to date from the python debugger wrappers:
https://github.com/ionelmc/python-remote-pdb

The `shell_wait()` in your bbclass is related to the pdb() functionality?

On Fri, Nov 1, 2019 at 10:14 PM Ross Burton <ross.burton@...> wrote:

On 01/11/2019 20:44, Alan Martinović wrote:
Hey,
there was a question today about options for debugging python scripts in yocto.
I've patched up this PoC for remote debugging.
FWIW, I've done something similar using bare pdb.

https://github.com/rossburton/meta-ross/blob/master/classes/pdb.bbclass

Just call pdb() from Python context. Not as neat as epdb though.

Ross
Re: Debugging custom python code in recipes

Ross Burton <ross.burton@...>
 

On 01/11/2019 20:44, Alan Martinović wrote:
Hey,
there was a question today about options for debugging python scripts in yocto.
I've patched up this PoC for remote debugging.
FWIW, I've done something similar using bare pdb.

https://github.com/rossburton/meta-ross/blob/master/classes/pdb.bbclass

Just call pdb() from Python context. Not as neat as epdb though.

Ross
Debugging custom python code in recipes

Alan Martinović
 

Hey,
there was a question today about options for debugging python scripts in yocto.
I've patched up this PoC for remote debugging.

If someone finds it useful (it should be copy-pastable), feel free to
ping me back.
Am opet to shaping it into a friendlier format and discover potential issues.


```
# epdb is a python debugger which has a capability of attaching to breakpoints
# on running daemons. Install it on the host.
pip3 install epdb

git clone -b zeus git://git.yoctoproject.org/poky.git
cd poky

# Create a example .inc file in a random location
cat > meta/recipes-core/images/python-debug-example.inc << "EOF"
python () {

# Import the epdb installed on the host
import epdb
random_action = 3

# Set the breakpoint.
# This will stop the program and open a channel to connect to the
interactive debugger
epdb.serve()
some_other_action = 5
another_action = 6
}
EOF


# Add the .inc file to an arbitrary image
# Triggering the image build, the python code will be executed
# and the breakpoint reached
cat >> meta/recipes-core/images/core-image-minimal.bb << EOF
require python-debug-example.inc
EOF

source oe-init-build-env
# This will block because of the breakpoint
bitbake core-image-minimal

# Open a new terminal and connect to the debugger
python3 -c "import epdb; epdb.connect()"

# You should see something like...
# (Epdb) l
# 5 random_action = 3
# 6
# 7 # Set the breakpoint.
# 8 # This will stop the program and open a channel to
connect to the interactive debugger
# 9 epdb.serve()
# 10 -> some_other_action = 5
# 11 another_action = 6
# 12 }
#[EOF]

# ... which is the interactive python debugger
```

Be Well,
Alan
10661 - 10680 of 57806