Re: [yocto] QA notification for completed autobuilder build (yocto-2.6.2.rc3)
Hi Richard, Sorry for the confusion. Yes, public autobuilder had already covered all automated runtime qemu tests. We do not plan to run any automated runtime qemu tests. For automated selftest, we plan to run a subset of selftest tests for a list of qemu architecture (qemu-shutdown & meta-ide). For these subset of selftest, could we enabled them to be run by pulic autobuilder as it only required changing MACHINE configuration to cover all qemu architectures? Hope this help to clarify the confusion. Please let us know if you have any more questions. Best regards, Yeoh Ee Peng -Original Message- From: Jain, Sangeeta Sent: Thursday, April 4, 2019 10:19 AM To: richard.pur...@linuxfoundation.org; Poky Build User ; yocto@yoctoproject.org; sjolley.yp...@gmail.com; Yi Zhao Cc: ota...@ossystems.com.br; Chan, Aaron Chun Yew ; akuster...@gmail.com; Yeoh, Ee Peng ; Sangal, Apoorv Subject: RE: [yocto] QA notification for completed autobuilder build (yocto-2.6.2.rc3) Hi Richard, >-Original Message- >From: richard.pur...@linuxfoundation.org > >Sent: Wednesday, 3 April, 2019 5:20 PM >To: Jain, Sangeeta ; Poky Build User >; yocto@yoctoproject.org; >sjolley.yp...@gmail.com; Yi Zhao >Cc: ota...@ossystems.com.br; Chan, Aaron Chun Yew >; akuster...@gmail.com; Yeoh, Ee Peng >; Sangal, Apoorv >Subject: Re: [yocto] QA notification for completed autobuilder build >(yocto- >2.6.2.rc3) > >Hi, > >This is good information and helps a lot, thanks! I had a question below. > >On Wed, 2019-04-03 at 08:06 +, Jain, Sangeeta wrote: >> Intel and WR YP QA is now working on QA execution for YP build 2.6.2 >> RC3. We are planning to execute following tests for this cycle: >> >> OEQA-Manual tests for following modules: >> 1. SDK >> 2. Eclipse-plugin >> 3. Kernel >> 4. Toaster >> 5. Bitbake (oe-core) >> 6. Build-appliance >> 7. Crops >> 8. Compliance-test >> 9. Bsp-hw >> 10. Bsp-qemu >> >> Runtime auto test for following platforms: >> >> 1. MinnowTurbo 32bit >> 2. MinnowTurbot 64 bit >> 3. NUC 7 >> 4. NUC 6 >> 5. Edgerouter >> 6. MPC8315e-rdb >> 7. Beaglebone >> 8. Qemuarm >> 9. Qemuarm-64 >> 10. Qemuppc >> 11. Qemumips >> 12. Qemumips64 > >I'm wondering if there is any difference between items 8-12 here and >the runtime testing we run on the public autobuilder? Is there some >testing we're missing on the public autobuilder? We will be running oe-selftest for machines 8-12, which is missing in autobuilder results. Also, I don't see any ptest results for 2.6.2.rc3 on public autobuilder. Do you have any plans to run them and share the results on autobuilder? > >Cheers, > >Richard > Thanks & Regards, Sangeeta Jain -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] wic / wks partition
Hello, we need to add a raw partition Type=0xda . How can I do that, because "part -fstype " has no raw or other value. Mit freundlichen Grüßen / Best regards Johann Obermayr -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Proposed new QA process
Hi Richard, Agreed to you inputs! I had created a new QA process wiki page to compile all inputs. https://wiki.yoctoproject.org/wiki/New_QA_process > Do we need to add something to the results to indicate which results are from > "who"? (i.e. from > the public autobuilder, Intel QA, WR QA, any other > sources?). We may want to add something >such as a parameter to the > resulttool store command so we can add this info to results? I had enhanced the resulttool following your suggestion. Patches submitted to openembedded-core mailing list. Best regards, Yeoh Ee Peng -Original Message- From: richard.pur...@linuxfoundation.org [mailto:richard.pur...@linuxfoundation.org] Sent: Wednesday, April 3, 2019 4:18 AM To: Yeoh, Ee Peng ; 'yocto@yoctoproject.org' Subject: Re: Proposed new QA process This is a good start. I've filled out some details below and had some questions. On Tue, 2019-04-02 at 03:28 +, Yeoh, Ee Peng wrote: > Given the new QA tooling (resulttool) available to manage QA test > results and reporting, here was the proposed new QA process. > > The new QA process consists below: > · Test Trigger > · Test Planning > · Test Execution > · Test Result Store > · Test Monitoring & Reporting > · Release Decision > > Test Trigger: Each QA team will subscribe to QA notification email > (request through Richard Purdie). The list of notifications is maintained on config.json in the yocto- autobuilder-helper which has a branch per release. > Test Planning: The lead QA team no longer need to setup Testopia and > wiki page. Each QA team (eg. intel, windriver, etc) will perform > planning on what extra tests they plan to run and when they'll send > the results back, then send these planning information as acknowledge > email to QA stakeholders (eg. Richard Purdie, Stephen Jolley) and the > lead QA team. Each QA team can refer to OEQA for automated and manual > test cases for their planning. What form will these notifications take? Is there a time limit for when they'll be received after a QA notification email? Can we agree to include an estimate of execution time in this notification? > Test Execution: Each QA team will execute the planned extra tests. To > make sure test result from the test execution could fully integrated > to the new QA tooling (resulttool for test result management and > reporting/regression), execute OEQA automated tests and OEQA manual > tests through resulttool (refer > https://wiki.yoctoproject.org/wiki/Resulttool#manualexecution). > > Test Result Store: Each QA team will store test result to the remote > yocto-testresults git repository using resulttool (refer > https://wiki.yoctoproject.org/wiki/Resulttool#store), then send the QA > completion email (include new defects information) to both QA > stakeholder and the lead QA team. Each QA team will request write > access to remote yocto-testresults git repository (request through > Richard Purdie). Ultimately, yes but I want to have things working before we have multiple people pushing things there. Need to document the commands used here to add the results too. Do we need to add something to the results to indicate which results are from "who"? (i.e. from the public autobuilder, Intel QA, WR QA, any other sources?). We may want to add something such as a parameter to the resulttool store command so we can add this info to results? > Test Monitoring & Reporting: QA stakeholder will monitor testing > progress from remote yocto-testresults git repository using resulttool > (refer https://wiki.yoctoproject.org/wiki/Resulttool#report). Once > every QA team completed the test execution, the lead QA team will > create QA test report and regression using resulttool. Send email > report to QA stakeholder and public yocto mailing list. We should document the command to do this. I'm also wondering where the list of stakeholders would be maintained? Is Intel volunteering to help with this role for the time being or does someone else need to start doing this. A key thing we need to document here is that someone, somewhere in this process needs to: a) Open a bug for each unique QA test failure b) List the bugs found in the QA report c) Notice any ptest timeouts and file bugs for those too > Release Decision: QA stakeholder will make the final decision for > release. The release decision will ultimately be made by the Yocto Project TSC who will review the responses to the QA report (including suggestions from QA) and make a go/nogo decision on that information (exact process to be agreed by the TSC). Cheers, Richard --- Begin Message --- v01: Enable merging results where both base and target are directory. v02: Follow suggestion from RP to reused the existing resultutils code base where it will merge results to flat file. Refactor resultutils code base to enable merging results where both base and target are directory.
Re: [yocto] QA notification for completed autobuilder build (yocto-2.6.2.rc3)
Hi Richard, >-Original Message- >From: richard.pur...@linuxfoundation.org >Sent: Wednesday, 3 April, 2019 5:20 PM >To: Jain, Sangeeta ; Poky Build User >; yocto@yoctoproject.org; >sjolley.yp...@gmail.com; Yi Zhao >Cc: ota...@ossystems.com.br; Chan, Aaron Chun Yew >; akuster...@gmail.com; Yeoh, Ee Peng >; Sangal, Apoorv >Subject: Re: [yocto] QA notification for completed autobuilder build (yocto- >2.6.2.rc3) > >Hi, > >This is good information and helps a lot, thanks! I had a question below. > >On Wed, 2019-04-03 at 08:06 +, Jain, Sangeeta wrote: >> Intel and WR YP QA is now working on QA execution for YP build 2.6.2 >> RC3. We are planning to execute following tests for this cycle: >> >> OEQA-Manual tests for following modules: >> 1. SDK >> 2. Eclipse-plugin >> 3. Kernel >> 4. Toaster >> 5. Bitbake (oe-core) >> 6. Build-appliance >> 7. Crops >> 8. Compliance-test >> 9. Bsp-hw >> 10. Bsp-qemu >> >> Runtime auto test for following platforms: >> >> 1. MinnowTurbo 32bit >> 2. MinnowTurbot 64 bit >> 3. NUC 7 >> 4. NUC 6 >> 5. Edgerouter >> 6. MPC8315e-rdb >> 7. Beaglebone >> 8. Qemuarm >> 9. Qemuarm-64 >> 10. Qemuppc >> 11. Qemumips >> 12. Qemumips64 > >I'm wondering if there is any difference between items 8-12 here and the >runtime >testing we run on the public autobuilder? Is there some testing we're missing >on >the public autobuilder? We will be running oe-selftest for machines 8-12, which is missing in autobuilder results. Also, I don't see any ptest results for 2.6.2.rc3 on public autobuilder. Do you have any plans to run them and share the results on autobuilder? > >Cheers, > >Richard > Thanks & Regards, Sangeeta Jain -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] grub-efi
Hello, now i build a wic image. This has bootia32.efi included. How can I add bootx64.efi & legacy bios boot ? Because the image must boot on different x64 machines. One machine has only efi 64 bit boot support. Another (older) has only legacy boot support. After create a image I have copy grubx64.efi from a ubuntu installation to my disk into /EFI/BOOT/bootx64.efi And now it will booting. We will have a 32 bit system, but only the kernel must be a 64bit. Xenomai only support 64bit x86. But our user space application must be 32bit. Mit freundlichen Grüßen / Best regards Johann Obermayr -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [oe] [OE-core] Git commit process question.
On Wed, Apr 3, 2019 at 4:07 PM Paul Eggleton wrote: > > On Thursday, 4 April 2019 5:46:04 AM NZDT Khem Raj wrote: > > On Wed, Apr 3, 2019 at 7:41 AM Tom Rini wrote: > > > > > > On Wed, Apr 03, 2019 at 11:30:39AM +0100, Burton, Ross wrote: > > > > On Tue, 2 Apr 2019 at 20:46, Tom Rini wrote: > > > > > > The kernel does not have "upgrade foo to the latest upstream > > > > > > version" commits. > > > > > > > > > > > > With the Automatic Upgrade Helper this is a semi-automatic task, and > > > > > > most of the time there is no specific motivation other than > > > > > > upgrading > > > > > > to the latest upstream version. > > > > > > > > > > But since that's just filling in a template the body can also be a > > > > > template perhaps with useful AUH data (run at ... by ... ?) ? > > > > > > > > Apart from making the commit message longer what does this achieve? > > > > The commit already has a timestamp and author. > > > > > > It's an etiquette thing. Subject+Sign-off+Empty body is bad form. AUH > > > updates are a form of "trivial update" that every project has. "Update > > > $X from version $Y to $Z" is what a human would normally put. It's > > > weird looking at git log of nothing but subject+signed-off-by. I'm not > > > going to object further on this point, but I don't get it. > > > > if the content of subject is being repeated in body then I would > > prefer an empty body > > redundant information in commits should be avoided since it can create > > impression that body does not have > > useful information and skip reading it. We should strive to make commits > > concise and useful. > > There is often (I won't say always, but often) something useful you can put in > the commit message. If it's a recipe upgrade, you could put a pointer to the > upstream changelog in it, for example. As the person doing the upgrade if your > prior review of that changelog or other upstream release documentation > indicated any backwards-compatibility issues or CVEs fixed then those really > ought to be mentioned as well; if you're feeling especially generous you might > mention highlights of any new functionality. (I have a proposal that might > help us automate part of that which I've not yet fully fleshed out, hopefully > one day soon I will get around to it.) > > The issue of empty commit messages is something I've complained about in the > past, and not just about recipe upgrades. If I - as someone who is relatively > familiar with OE - have to actually read beyond the shortlog / commit message > to understand the basics of why a change has been made, then it's likely that > the commit message wasn't good enough. Unlike other issues, once a commit goes > in the message is set in stone within the git history, so if you are working > on a change, *please* take a minute or two to document it adequately in the > commit message so that others looking back can understand it. > Definitely, and I agree that we should put relevant information in commits, usually the information about side effects if any, links to changelog etc. are useful too however, we should not enforce a behavior which could result in redundancy as explained > Thanks, > Paul > > -- > > Paul Eggleton > Intel Open Source Technology Centre > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [oe] [OE-core] Git commit process question.
On Thursday, 4 April 2019 5:46:04 AM NZDT Khem Raj wrote: > On Wed, Apr 3, 2019 at 7:41 AM Tom Rini wrote: > > > > On Wed, Apr 03, 2019 at 11:30:39AM +0100, Burton, Ross wrote: > > > On Tue, 2 Apr 2019 at 20:46, Tom Rini wrote: > > > > > The kernel does not have "upgrade foo to the latest upstream > > > > > version" commits. > > > > > > > > > > With the Automatic Upgrade Helper this is a semi-automatic task, and > > > > > most of the time there is no specific motivation other than > > > > > upgrading > > > > > to the latest upstream version. > > > > > > > > But since that's just filling in a template the body can also be a > > > > template perhaps with useful AUH data (run at ... by ... ?) ? > > > > > > Apart from making the commit message longer what does this achieve? > > > The commit already has a timestamp and author. > > > > It's an etiquette thing. Subject+Sign-off+Empty body is bad form. AUH > > updates are a form of "trivial update" that every project has. "Update > > $X from version $Y to $Z" is what a human would normally put. It's > > weird looking at git log of nothing but subject+signed-off-by. I'm not > > going to object further on this point, but I don't get it. > > if the content of subject is being repeated in body then I would > prefer an empty body > redundant information in commits should be avoided since it can create > impression that body does not have > useful information and skip reading it. We should strive to make commits > concise and useful. There is often (I won't say always, but often) something useful you can put in the commit message. If it's a recipe upgrade, you could put a pointer to the upstream changelog in it, for example. As the person doing the upgrade if your prior review of that changelog or other upstream release documentation indicated any backwards-compatibility issues or CVEs fixed then those really ought to be mentioned as well; if you're feeling especially generous you might mention highlights of any new functionality. (I have a proposal that might help us automate part of that which I've not yet fully fleshed out, hopefully one day soon I will get around to it.) The issue of empty commit messages is something I've complained about in the past, and not just about recipe upgrades. If I - as someone who is relatively familiar with OE - have to actually read beyond the shortlog / commit message to understand the basics of why a change has been made, then it's likely that the commit message wasn't good enough. Unlike other issues, once a commit goes in the message is set in stone within the git history, so if you are working on a change, *please* take a minute or two to document it adequately in the commit message so that others looking back can understand it. Thanks, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] gdb built with musl libc segfault
On Wed, Apr 3, 2019 at 9:59 AM Khem Raj wrote:
>
> On Tue, Apr 2, 2019 at 4:51 AM Lluis Campos
> wrote:
> >
> > Hi all,
> >
> > This is my very first question in the Yocto mailing list. Very exited!
> > Please let me know if I should use other list for this.
> >
> >
> > I am building an image using musl libc instead of gnu libc. I am not
> > using yocto-tiny distro, instead I achieve this by setting on my local.conf:
> >
> > TCLIBC = "musl"
> >
> >
> > My app (mender) got a segfault just starting. See output from strace:
> >
> > root@raspberrypi3:~# strace mender
> > execve("/usr/bin/mender", ["mender"], 0x7ee65e10 /* 13 vars */) = 0
> > set_tls(0x76f1bffc) = 0
> > set_tid_address(0x76f1bfa0) = 3020
> > --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0x530bc8} ---
> > +++ killed by SIGSEGV +++
> > Segmentation fault
> >
> >
> > To be able to debug the process, I added gdb to my image adding to my
> > local.conf:
> >
> > CORE_IMAGE_EXTRA_INSTALL += "packagegroup-core-buildessential
> > packagegroup-core-tools-debug"
> >
> >
> > Then, ironically, gdb itself also segfaults:
> >
> > root@raspberrypi3:~# strace gdb 2>&1 | tail
> > fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
> > getdents64(3, /* 6 entries */, 2048)= 144
> > getdents64(3, /* 0 entries */, 2048)= 0
> > close(3)= 0
> > ioctl(0, TIOCGWINSZ, {ws_row=25, ws_col=74, ws_xpixel=0, ws_ypixel=0}) = 0
> > getcwd("/home/root", 4096) = 11
> > access("/usr/local/bin/gdb", X_OK) = -1 ENOENT (No such file or
> > directory)
> > access("/usr/bin/gdb", X_OK)= 0
> > --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x7e35aff0} ---
> > +++ killed by SIGSEGV +++
> >
> >
> > So, what is going on here? My guess is that some recipes are being
> > wrongly linked with gnu libc instead of musl, and then cannot run in my
> > device.
> >
> > Any ideas on how to debug the issue?
> >
>
> We have switched to using PIE by default in last few releases, can you
> try master but comment out
> require conf/distro/include/security_flags.inc
> in your distro conf file.
>
I built a fresh image using yoe distro master today and gdb seems to
work fine on rpi3/musl
https://github.com/YoeDistro/yoe-distro
> > Thanks!
> >
> >
> > Lluís Campos
> > mender.io
> > Northen Tech
> >
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] gdb built with musl libc segfault
On Tue, Apr 2, 2019 at 4:51 AM Lluis Campos wrote:
>
> Hi all,
>
> This is my very first question in the Yocto mailing list. Very exited!
> Please let me know if I should use other list for this.
>
>
> I am building an image using musl libc instead of gnu libc. I am not
> using yocto-tiny distro, instead I achieve this by setting on my local.conf:
>
> TCLIBC = "musl"
>
>
> My app (mender) got a segfault just starting. See output from strace:
>
> root@raspberrypi3:~# strace mender
> execve("/usr/bin/mender", ["mender"], 0x7ee65e10 /* 13 vars */) = 0
> set_tls(0x76f1bffc) = 0
> set_tid_address(0x76f1bfa0) = 3020
> --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0x530bc8} ---
> +++ killed by SIGSEGV +++
> Segmentation fault
>
>
> To be able to debug the process, I added gdb to my image adding to my
> local.conf:
>
> CORE_IMAGE_EXTRA_INSTALL += "packagegroup-core-buildessential
> packagegroup-core-tools-debug"
>
>
> Then, ironically, gdb itself also segfaults:
>
> root@raspberrypi3:~# strace gdb 2>&1 | tail
> fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
> getdents64(3, /* 6 entries */, 2048)= 144
> getdents64(3, /* 0 entries */, 2048)= 0
> close(3)= 0
> ioctl(0, TIOCGWINSZ, {ws_row=25, ws_col=74, ws_xpixel=0, ws_ypixel=0}) = 0
> getcwd("/home/root", 4096) = 11
> access("/usr/local/bin/gdb", X_OK) = -1 ENOENT (No such file or
> directory)
> access("/usr/bin/gdb", X_OK)= 0
> --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x7e35aff0} ---
> +++ killed by SIGSEGV +++
>
>
> So, what is going on here? My guess is that some recipes are being
> wrongly linked with gnu libc instead of musl, and then cannot run in my
> device.
>
> Any ideas on how to debug the issue?
>
We have switched to using PIE by default in last few releases, can you
try master but comment out
require conf/distro/include/security_flags.inc
in your distro conf file.
> Thanks!
>
>
> Lluís Campos
> mender.io
> Northen Tech
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [oe] [OE-core] Git commit process question.
On Wed, Apr 3, 2019 at 7:41 AM Tom Rini wrote: > > On Wed, Apr 03, 2019 at 11:30:39AM +0100, Burton, Ross wrote: > > On Tue, 2 Apr 2019 at 20:46, Tom Rini wrote: > > > > The kernel does not have "upgrade foo to the latest upstream version" > > > > commits. > > > > > > > > With the Automatic Upgrade Helper this is a semi-automatic task, and > > > > most of the time there is no specific motivation other than upgrading > > > > to the latest upstream version. > > > > > > But since that's just filling in a template the body can also be a > > > template perhaps with useful AUH data (run at ... by ... ?) ? > > > > Apart from making the commit message longer what does this achieve? > > The commit already has a timestamp and author. > > It's an etiquette thing. Subject+Sign-off+Empty body is bad form. AUH > updates are a form of "trivial update" that every project has. "Update > $X from version $Y to $Z" is what a human would normally put. It's > weird looking at git log of nothing but subject+signed-off-by. I'm not > going to object further on this point, but I don't get it. if the content of subject is being repeated in body then I would prefer an empty body redundant information in commits should be avoided since it can create impression that body does not have useful information and skip reading it. We should strive to make commits concise and useful. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [oe] [OE-core] Git commit process question.
On Wed, Apr 03, 2019 at 11:30:39AM +0100, Burton, Ross wrote: > On Tue, 2 Apr 2019 at 20:46, Tom Rini wrote: > > > The kernel does not have "upgrade foo to the latest upstream version" > > > commits. > > > > > > With the Automatic Upgrade Helper this is a semi-automatic task, and > > > most of the time there is no specific motivation other than upgrading > > > to the latest upstream version. > > > > But since that's just filling in a template the body can also be a > > template perhaps with useful AUH data (run at ... by ... ?) ? > > Apart from making the commit message longer what does this achieve? > The commit already has a timestamp and author. It's an etiquette thing. Subject+Sign-off+Empty body is bad form. AUH updates are a form of "trivial update" that every project has. "Update $X from version $Y to $Z" is what a human would normally put. It's weird looking at git log of nothing but subject+signed-off-by. I'm not going to object further on this point, but I don't get it. -- Tom signature.asc Description: PGP signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] gdb built with musl libc segfault
On 02/04/2019 14:51, Lluis Campos wrote:
Hi Paul,
On 02.04.2019 14:49, Paul Barker wrote:
On 02/04/2019 12:45, Lluis Campos wrote:
Hi all,
This is my very first question in the Yocto mailing list. Very
exited! Please let me know if I should use other list for this.
I am building an image using musl libc instead of gnu libc. I am not
using yocto-tiny distro, instead I achieve this by setting on my
local.conf:
TCLIBC = "musl"
My app (mender) got a segfault just starting. See output from strace:
root@raspberrypi3:~# strace mender
execve("/usr/bin/mender", ["mender"], 0x7ee65e10 /* 13 vars */) = 0
set_tls(0x76f1bffc) = 0
set_tid_address(0x76f1bfa0) = 3020
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0x530bc8}
---
+++ killed by SIGSEGV +++
Segmentation fault
To be able to debug the process, I added gdb to my image adding to my
local.conf:
CORE_IMAGE_EXTRA_INSTALL += "packagegroup-core-buildessential
packagegroup-core-tools-debug"
Then, ironically, gdb itself also segfaults:
root@raspberrypi3:~# strace gdb 2>&1 | tail
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
getdents64(3, /* 6 entries */, 2048) = 144
getdents64(3, /* 0 entries */, 2048) = 0
close(3) = 0
ioctl(0, TIOCGWINSZ, {ws_row=25, ws_col=74, ws_xpixel=0,
ws_ypixel=0}) = 0
getcwd("/home/root", 4096) = 11
access("/usr/local/bin/gdb", X_OK) = -1 ENOENT (No such file or
directory)
access("/usr/bin/gdb", X_OK) = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR,
si_addr=0x7e35aff0} ---
+++ killed by SIGSEGV +++
So, what is going on here? My guess is that some recipes are being
wrongly linked with gnu libc instead of musl, and then cannot run in
my device.
Any ideas on how to debug the issue?
Hi Lluis,
This is an issue I've seen before with runc and gdb.
In runc we saw SIGILL which I tracked down to some hideous
setjmp/longjmp magic written in C. cgo is used to include this C code
in with the Go code that comprises the rest of the application.
Our application is written in Go and we use CGO as well. So it sounds
quite similar.
Does your application use setjmp/longjmp or C++ exceptions in the
sections built with CGO?
I've dug into the runc disassembly as well as adding extra prints and
can see that it's at calls to those functions that the program counter
jumps off into the weeds resulting in SIGILL. For gdb there's usage of
C++ exception handling around gdb_main() and strace shows that the crash
is very very early in execution so I suspect it's setjmp/longjmp again,
used by C++ exception handling.
In gdb we saw SIGSEGV which is what you've got above.
I think things are being correctly linked against musl but then
there's some runtime issue in recent musl versions, possibly in
conjunction with recent kernel headers.
Are you using the thud or master branch?
I am using thud branch. I haven't actually tried with master but I will
do it later today
I've reproduced the issue on master. I've also ruled out the issue in
sumo branch even if we uprev musl to the same version used on master.
It's likely a gcc/musl incompatibility of some kind introduced in a
recent gcc version.
I'm passing this one to a colleague for now but I'll try to have another
look myself next week. It's captured in our issue tracker for Oryx here:
https://gitlab.com/oryx/oryx/issues/14.
Thanks,
--
Paul Barker
Managing Director & Principal Engineer
Beta Five Ltd
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[linux-yocto] [kernel-meta v4.19 PATCH] mips: Enable the poweroff driver for the qemumips/qemumips64
As Indicated by Richard Purdie, in order to shutdown the machine we have
to explicitly enable the PIIX4 poweroff driver for the
qemumips/qemumips64 after the kernel commit dd129c6374e9 ("MIPS: Malta:
Use PIIX4 poweroff driver to power down") is merged.
Signed-off-by: Kevin Hao
---
bsp/mti-malta32/mti-malta32-common.cfg | 3 +++
bsp/mti-malta64/mti-malta64-common.cfg | 3 +++
2 files changed, 6 insertions(+)
diff --git a/bsp/mti-malta32/mti-malta32-common.cfg
b/bsp/mti-malta32/mti-malta32-common.cfg
index d30a38d0f89f..51b9bdc46586 100644
--- a/bsp/mti-malta32/mti-malta32-common.cfg
+++ b/bsp/mti-malta32/mti-malta32-common.cfg
@@ -73,3 +73,6 @@ CONFIG_SERIO=y
CONFIG_USB_MON=y
CONFIG_USB_OHCI_HCD=y
+# Board reset
+CONFIG_POWER_RESET=y
+CONFIG_POWER_RESET_PIIX4_POWEROFF=y
diff --git a/bsp/mti-malta64/mti-malta64-common.cfg
b/bsp/mti-malta64/mti-malta64-common.cfg
index a6c1202c5b13..c178fd07a127 100644
--- a/bsp/mti-malta64/mti-malta64-common.cfg
+++ b/bsp/mti-malta64/mti-malta64-common.cfg
@@ -79,3 +79,6 @@ CONFIG_USB_OHCI_HCD=y
# CONFIG_VGA_CONSOLE is not set
+# Board reset
+CONFIG_POWER_RESET=y
+CONFIG_POWER_RESET_PIIX4_POWEROFF=y
--
2.14.4
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [yocto] [OE-core] [oe] Git commit process question.
On 4/3/19 3:38 AM, Alexander Kanavin wrote: > Just to make clear, the AUH workflow does require the maintainer to > sign off and edit a commit message via 'git commit -s --reset-author > --amend' for every commit, Not sure if this a requirement anymore. Most of my packages got updated by other folks this time around. Hard to say if the AUH played a part or are folks now using the devtool check. > so AUH does not get in the way of useful > commit messages. There was talk of using the AUH to fast track updates that pass the process so in that case the message would be whatever the AUH provides - armin > > Alex > > On Wed, 3 Apr 2019 at 12:31, Burton, Ross wrote: >> On Tue, 2 Apr 2019 at 20:46, Tom Rini wrote: >> pr The kernel does not have "upgrade foo to the latest upstream version" commits. With the Automatic Upgrade Helper this is a semi-automatic task, and most of the time there is no specific motivation other than upgrading to the latest upstream version. >>> But since that's just filling in a template the body can also be a >>> template perhaps with useful AUH data (run at ... by ... ?) ? >> Apart from making the commit message longer what does this achieve? >> The commit already has a timestamp and author. >> >> Ross >> -- >> ___ >> Openembedded-core mailing list >> openembedded-c...@lists.openembedded.org >> http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [oe] Git commit process question.
Just to make clear, the AUH workflow does require the maintainer to sign off and edit a commit message via 'git commit -s --reset-author --amend' for every commit, so AUH does not get in the way of useful commit messages. Alex On Wed, 3 Apr 2019 at 12:31, Burton, Ross wrote: > > On Tue, 2 Apr 2019 at 20:46, Tom Rini wrote: > > > The kernel does not have "upgrade foo to the latest upstream version" > > > commits. > > > > > > With the Automatic Upgrade Helper this is a semi-automatic task, and > > > most of the time there is no specific motivation other than upgrading > > > to the latest upstream version. > > > > But since that's just filling in a template the body can also be a > > template perhaps with useful AUH data (run at ... by ... ?) ? > > Apart from making the commit message longer what does this achieve? > The commit already has a timestamp and author. > > Ross > -- > ___ > Openembedded-core mailing list > openembedded-c...@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [oe] [OE-core] Git commit process question.
On Tue, 2 Apr 2019 at 20:46, Tom Rini wrote: > > The kernel does not have "upgrade foo to the latest upstream version" > > commits. > > > > With the Automatic Upgrade Helper this is a semi-automatic task, and > > most of the time there is no specific motivation other than upgrading > > to the latest upstream version. > > But since that's just filling in a template the body can also be a > template perhaps with useful AUH data (run at ... by ... ?) ? Apart from making the commit message longer what does this achieve? The commit already has a timestamp and author. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-security][PATCH] samhain: hash fix for aarch64 and mips64
On Wed, Apr 03, 2019 at 04:55:14PM +0800, mingli...@windriver.com wrote: > From: Mingli Yu > > samhain fails on both aarch64 and mips64 targets with: > | samhain[3013]: FATAL: x_dnmalloc.c: 2790: hashval < AMOUNTHASH > > Though there is already a patch samhain-mips64-aarch64-dnmalloc-hash-fix.patch > to fix this issue, the logic is incomplete and > pass -DCONFIG_ARCH_MIPS64=1 and -DCONFIG_ARCH_AARCH64=1 > during do_configure phase respectively to fix the > issue. >... In master this has already been workarounded with --disable-dnmalloc. 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 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] QA notification for completed autobuilder build (yocto-2.6.2.rc3)
Hi Armin, For 2.6.2.rc3, QA team shall try to run the execution by referring to the manual testcases from master. Thanks, Yeoh Ee Peng -Original Message- From: akuster808 [mailto:akuster...@gmail.com] Sent: Wednesday, April 3, 2019 5:50 PM To: Jain, Sangeeta ; Poky Build User ; yocto@yoctoproject.org; richard.pur...@linuxfoundation.org; sjolley.yp...@gmail.com; Yi Zhao Cc: ota...@ossystems.com.br; Chan, Aaron Chun Yew ; Yeoh, Ee Peng ; Sangal, Apoorv Subject: Re: [yocto] QA notification for completed autobuilder build (yocto-2.6.2.rc3) Hello, On 4/3/19 1:06 AM, Jain, Sangeeta wrote: > Intel and WR YP QA is now working on QA execution for YP build 2.6.2 RC3. We > are planning to execute following tests for this cycle: > > OEQA-Manual tests for following modules: > 1.SDK > 2.Eclipse-plugin > 3.Kernel > 4.Toaster > 5.Bitbake (oe-core) > 6.Build-appliance > 7.Crops > 8.Compliance-test > 9.Bsp-hw > 10. Bsp-qemu I did not backport the manual test from master or thud. Are these the original set? regards, Armin > Runtime auto test for following platforms: > > 1.MinnowTurbo 32bit > 2.MinnowTurbot 64 bit > 3.NUC 7 > 4.NUC 6 > 5.Edgerouter > 6.MPC8315e-rdb > 7.Beaglebone > 8.Qemuarm > 9.Qemuarm-64 > 10. Qemuppc > 11. Qemumips > 12. Qemumips64 > > Other auto tests: > > 1.Qemu-selftest > 2.Qemu-meta-ide > > ETA for completion is Wednesday, 10 April. > > Thanks & Regards, > Sangeeta Jain > >> -Original Message- >> From: yocto-boun...@yoctoproject.org >> On Behalf Of Poky Build User >> Sent: Thursday, 28 March, 2019 11:30 AM >> To: yocto@yoctoproject.org >> Cc: ota...@ossystems.com.br; Chan, Aaron Chun Yew >> ; akuster...@gmail.com >> Subject: [yocto] QA notification for completed autobuilder build >> (yocto-2.6.2.rc3) >> >> >> A build flagged for QA (yocto-2.6.2.rc3) was completed on the >> autobuilder and is available at: >> >> >>https://autobuilder.yocto.io/pub/releases/yocto-2.6.2.rc3 >> >> >> Build hash information: >> >> bitbake: 7c1eb51d1e8a4c5f39bf9dddf05fb0b3598da72b >> eclipse-poky-neon: cd86f167be58a11b289af4ef236b4adec57ec316 >> eclipse-poky-oxygen: 210c58c5a7147127f9c840718c6cd2a56e871718 >> meta-gplv2: aabc30f3bd03f97326fb8596910b94639fea7575 >> meta-intel: 27dadcfc7bc0de70328b02fecb841608389d22fc >> meta-mingw: 6556cde16fbdf42c7edae89bb186e5ae4982eff5 >> meta-qt3: 23d7543ebd7e82ba95cbe19043ae4229bdb3b6b1 >> meta-qt4: b37d8b93924b314df3591b4a61e194ff3feb5517 >> oecore: 45032e30be70503faeee468159b216031b729309 >> poky: faeb366bc3eb322f5f203cfe08dc4cf529a822e9 >> >> >> >> This is an automated message from the Yocto Project Autobuilder >> Git: git://git.yoctoproject.org/yocto-autobuilder2 >> Email: richard.pur...@linuxfoundation.org >> >> >> >> -- >> ___ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] shared cmake modules
Hi all,
I'm setting up a layer that will compile our applications and libraries.
All the applications are based on cmake and they share modules. Before
using yocto I kept the modules in /cmake (under version control)
alongside applications and libraries. With yocto I wrote a recipe that
checkout the module repo and install them in
"${STAGING_DATADIR}/cmake/Modules/". I took this path from
"meta/classes/cmake.bbclass". If i build the module target, I get the files
installed in the target recipe datadir. If I want to build a library (that
depends also on my modules recipe) the task do_configure fails because
cmake cannot find none of my include. Digging around I found that the
toolchain.cmake file points to a module location that doesn't exist in the
library workdir, but in module recipe (${STAGING_DATADIR}/cmake/Modules/).
The module recipe looks like as follow:
MODULES_DEST_PATH = "${STAGING_DATADIR}/cmake/Modules"
FILES_${PN}-dev = "${MODULES_DEST_PATH}/*"
do_install() {
DEST_DIR=${MODULES_DEST_PATH}
# Create the destination folder
install -d $DEST_DIR
install -m 0444 ${S}/my/module.cmake $DEST_DIR
..
}
So my question is: where should I install the shared modules
(MODULE_DEST_PATH int the above snippet)? and how to update the
CMAKE_MODULE_PATH properly to append that location?
Thanks,
Gabriele
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-security][PATCH] samhain: hash fix for aarch64 and mips64
On 4/3/19 1:55 AM, mingli...@windriver.com wrote:
> From: Mingli Yu
>
> samhain fails on both aarch64 and mips64 targets with:
> | samhain[3013]: FATAL: x_dnmalloc.c: 2790: hashval < AMOUNTHASH
>
> Though there is already a patch samhain-mips64-aarch64-dnmalloc-hash-fix.patch
> to fix this issue, the logic is incomplete and
> pass -DCONFIG_ARCH_MIPS64=1 and -DCONFIG_ARCH_AARCH64=1
> during do_configure phase respectively to fix the
> issue.
This does not apply. Can you rebase with master.
thanks,
Armin
>
> Signed-off-by: Mingli Yu
> ---
> recipes-security/samhain/samhain.inc | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/recipes-security/samhain/samhain.inc
> b/recipes-security/samhain/samhain.inc
> index dcd72b9..90da813 100644
> --- a/recipes-security/samhain/samhain.inc
> +++ b/recipes-security/samhain/samhain.inc
> @@ -97,6 +97,11 @@ EOF
>
> do_configure () {
> autoconf -f
> + if [ "${TARGET_ARCH}" = "mips64" ]; then
> + export CFLAGS="${CFLAGS} -DCONFIG_ARCH_MIPS64=1"
> + elif [ "${TARGET_ARCH}" = "aarch64" ]; then
> + export CFLAGS="${CFLAGS} -DCONFIG_ARCH_AARCH64=1"
> + fi
> ./configure \
> --build=${BUILD_SYS} \
> --host=${HOST_SYS} \
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] QA notification for completed autobuilder build (yocto-2.6.2.rc3)
Hello, On 4/3/19 1:06 AM, Jain, Sangeeta wrote: > Intel and WR YP QA is now working on QA execution for YP build 2.6.2 RC3. We > are planning to execute following tests for this cycle: > > OEQA-Manual tests for following modules: > 1.SDK > 2.Eclipse-plugin > 3.Kernel > 4.Toaster > 5.Bitbake (oe-core) > 6.Build-appliance > 7.Crops > 8.Compliance-test > 9.Bsp-hw > 10. Bsp-qemu I did not backport the manual test from master or thud. Are these the original set? regards, Armin > Runtime auto test for following platforms: > > 1.MinnowTurbo 32bit > 2.MinnowTurbot 64 bit > 3.NUC 7 > 4.NUC 6 > 5.Edgerouter > 6.MPC8315e-rdb > 7.Beaglebone > 8.Qemuarm > 9.Qemuarm-64 > 10. Qemuppc > 11. Qemumips > 12. Qemumips64 > > Other auto tests: > > 1.Qemu-selftest > 2.Qemu-meta-ide > > ETA for completion is Wednesday, 10 April. > > Thanks & Regards, > Sangeeta Jain > >> -Original Message- >> From: yocto-boun...@yoctoproject.org On >> Behalf Of Poky Build User >> Sent: Thursday, 28 March, 2019 11:30 AM >> To: yocto@yoctoproject.org >> Cc: ota...@ossystems.com.br; Chan, Aaron Chun Yew >> ; akuster...@gmail.com >> Subject: [yocto] QA notification for completed autobuilder build >> (yocto-2.6.2.rc3) >> >> >> A build flagged for QA (yocto-2.6.2.rc3) was completed on the autobuilder >> and is >> available at: >> >> >>https://autobuilder.yocto.io/pub/releases/yocto-2.6.2.rc3 >> >> >> Build hash information: >> >> bitbake: 7c1eb51d1e8a4c5f39bf9dddf05fb0b3598da72b >> eclipse-poky-neon: cd86f167be58a11b289af4ef236b4adec57ec316 >> eclipse-poky-oxygen: 210c58c5a7147127f9c840718c6cd2a56e871718 >> meta-gplv2: aabc30f3bd03f97326fb8596910b94639fea7575 >> meta-intel: 27dadcfc7bc0de70328b02fecb841608389d22fc >> meta-mingw: 6556cde16fbdf42c7edae89bb186e5ae4982eff5 >> meta-qt3: 23d7543ebd7e82ba95cbe19043ae4229bdb3b6b1 >> meta-qt4: b37d8b93924b314df3591b4a61e194ff3feb5517 >> oecore: 45032e30be70503faeee468159b216031b729309 >> poky: faeb366bc3eb322f5f203cfe08dc4cf529a822e9 >> >> >> >> This is an automated message from the Yocto Project Autobuilder >> Git: git://git.yoctoproject.org/yocto-autobuilder2 >> Email: richard.pur...@linuxfoundation.org >> >> >> >> -- >> ___ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] Git commit process question.
On Tue, Apr 02, 2019 at 03:46:14PM -0400, Tom Rini wrote: > On Tue, Apr 02, 2019 at 09:51:21AM +0300, Adrian Bunk wrote: > > On Mon, Apr 01, 2019 at 04:20:41PM -0700, akuster808 wrote: > > > > > > > > > On 4/1/19 4:02 PM, Richard Purdie wrote: > > > > On Mon, 2019-04-01 at 15:33 -0700, akuster808 wrote: > > > >> Hello, > > > >> > > > >> I have noticed a large number of git commits with no header > > > >> information being accepted. > > > > Can you be more specific about what "no header information" means? You > > > > mean a shortlog and no full log message? > > > Commits with just a "subject" and signoff. No additional information > > > > > > We tend to reference back to how the kernel does things. > > > > > > https://www.kernel.org/doc/html/latest/process/submitting-patches.html > > > These two sections in particular. > > > > > > > > > 2) Describe your changes > > > > > > Describe your problem. Whether your patch is a one-line bug fix or 5000 > > > lines of a new feature, there must be an underlying problem that > > > motivated you to do this work. Convince the reviewer that there is a > > > problem worth fixing and that it makes sense for them to read past the > > > first paragraph. > > >... > > > > The kernel does not have "upgrade foo to the latest upstream version" > > commits. > > > > With the Automatic Upgrade Helper this is a semi-automatic task, and > > most of the time there is no specific motivation other than upgrading > > to the latest upstream version. > > But since that's just filling in a template the body can also be a > template perhaps with useful AUH data (run at ... by ... ?) ? That would be more trivial than useful. And so far noone has stated any actual problem that would be solved by adding such a new requirement. > Tom 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 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] QA notification for completed autobuilder build (yocto-2.6.2.rc3)
Hi, This is good information and helps a lot, thanks! I had a question below. On Wed, 2019-04-03 at 08:06 +, Jain, Sangeeta wrote: > Intel and WR YP QA is now working on QA execution for YP build 2.6.2 > RC3. We are planning to execute following tests for this cycle: > > OEQA-Manual tests for following modules: > 1.SDK > 2.Eclipse-plugin > 3.Kernel > 4.Toaster > 5.Bitbake (oe-core) > 6.Build-appliance > 7.Crops > 8.Compliance-test > 9.Bsp-hw > 10. Bsp-qemu > > Runtime auto test for following platforms: > > 1.MinnowTurbo 32bit > 2.MinnowTurbot 64 bit > 3.NUC 7 > 4.NUC 6 > 5.Edgerouter > 6.MPC8315e-rdb > 7.Beaglebone > 8.Qemuarm > 9.Qemuarm-64 > 10. Qemuppc > 11. Qemumips > 12. Qemumips64 I'm wondering if there is any difference between items 8-12 here and the runtime testing we run on the public autobuilder? Is there some testing we're missing on the public autobuilder? Cheers, Richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-security][PATCH] samhain: hash fix for aarch64 and mips64
From: Mingli Yu
samhain fails on both aarch64 and mips64 targets with:
| samhain[3013]: FATAL: x_dnmalloc.c: 2790: hashval < AMOUNTHASH
Though there is already a patch samhain-mips64-aarch64-dnmalloc-hash-fix.patch
to fix this issue, the logic is incomplete and
pass -DCONFIG_ARCH_MIPS64=1 and -DCONFIG_ARCH_AARCH64=1
during do_configure phase respectively to fix the
issue.
Signed-off-by: Mingli Yu
---
recipes-security/samhain/samhain.inc | 5 +
1 file changed, 5 insertions(+)
diff --git a/recipes-security/samhain/samhain.inc
b/recipes-security/samhain/samhain.inc
index dcd72b9..90da813 100644
--- a/recipes-security/samhain/samhain.inc
+++ b/recipes-security/samhain/samhain.inc
@@ -97,6 +97,11 @@ EOF
do_configure () {
autoconf -f
+ if [ "${TARGET_ARCH}" = "mips64" ]; then
+ export CFLAGS="${CFLAGS} -DCONFIG_ARCH_MIPS64=1"
+ elif [ "${TARGET_ARCH}" = "aarch64" ]; then
+ export CFLAGS="${CFLAGS} -DCONFIG_ARCH_AARCH64=1"
+ fi
./configure \
--build=${BUILD_SYS} \
--host=${HOST_SYS} \
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] QA notification for completed autobuilder build (yocto-2.6.2.rc3)
Intel and WR YP QA is now working on QA execution for YP build 2.6.2 RC3. We are planning to execute following tests for this cycle: OEQA-Manual tests for following modules: 1. SDK 2. Eclipse-plugin 3. Kernel 4. Toaster 5. Bitbake (oe-core) 6. Build-appliance 7. Crops 8. Compliance-test 9. Bsp-hw 10. Bsp-qemu Runtime auto test for following platforms: 1. MinnowTurbo 32bit 2. MinnowTurbot 64 bit 3. NUC 7 4. NUC 6 5. Edgerouter 6. MPC8315e-rdb 7. Beaglebone 8. Qemuarm 9. Qemuarm-64 10. Qemuppc 11. Qemumips 12. Qemumips64 Other auto tests: 1. Qemu-selftest 2. Qemu-meta-ide ETA for completion is Wednesday, 10 April. Thanks & Regards, Sangeeta Jain >-Original Message- >From: yocto-boun...@yoctoproject.org On >Behalf Of Poky Build User >Sent: Thursday, 28 March, 2019 11:30 AM >To: yocto@yoctoproject.org >Cc: ota...@ossystems.com.br; Chan, Aaron Chun Yew >; akuster...@gmail.com >Subject: [yocto] QA notification for completed autobuilder build >(yocto-2.6.2.rc3) > > >A build flagged for QA (yocto-2.6.2.rc3) was completed on the autobuilder and >is >available at: > > >https://autobuilder.yocto.io/pub/releases/yocto-2.6.2.rc3 > > >Build hash information: > >bitbake: 7c1eb51d1e8a4c5f39bf9dddf05fb0b3598da72b >eclipse-poky-neon: cd86f167be58a11b289af4ef236b4adec57ec316 >eclipse-poky-oxygen: 210c58c5a7147127f9c840718c6cd2a56e871718 >meta-gplv2: aabc30f3bd03f97326fb8596910b94639fea7575 >meta-intel: 27dadcfc7bc0de70328b02fecb841608389d22fc >meta-mingw: 6556cde16fbdf42c7edae89bb186e5ae4982eff5 >meta-qt3: 23d7543ebd7e82ba95cbe19043ae4229bdb3b6b1 >meta-qt4: b37d8b93924b314df3591b4a61e194ff3feb5517 >oecore: 45032e30be70503faeee468159b216031b729309 >poky: faeb366bc3eb322f5f203cfe08dc4cf529a822e9 > > > >This is an automated message from the Yocto Project Autobuilder >Git: git://git.yoctoproject.org/yocto-autobuilder2 >Email: richard.pur...@linuxfoundation.org > > > >-- >___ >yocto mailing list >yocto@yoctoproject.org >https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] QA cycle report for 2.7 M3 RC1
Hi Richard, For oe-selftest -r runqemu,meta_ide, configuration we are using is only changing the machine type. For adding "who" identifier in resulttool command, we can take it up as an enhancement. Thanks & Regards, Sangeeta Jain >-Original Message- >From: richard.pur...@linuxfoundation.org >Sent: Wednesday, 3 April, 2019 2:32 AM >To: Jain, Sangeeta ; 'yocto@yoctoproject.org' >; Eggleton, Paul ; 'Michael >Halstead' ; Erway, Tracey M >; sjolley.yp...@gmail.com; Burton, Ross > >Cc: OTC Embedded Malaysia >Subject: Re: QA cycle report for 2.7 M3 RC1 > >Hi Sangeeta/Ee Peng, > >On Tue, 2019-04-02 at 05:02 +, Jain, Sangeeta wrote: >> QA cycle report for 2.7 M3 RC1: >> >> No high milestone defects. >> This is completion of first QA cycle after adoption of new QA process. >> Test results are available at following location: >> ·For results of all automated tests, please refer to results >> at public AB [1]. >> ·For other test results, refer to attachment [2]. >> ·For test report for test cases run by Intel and WR team, >> refer attachment [3] >> ·For full test report, refer attachment [4] >> 2 new defects are found in this cycle, oe-selftest [5] and qemu- >> shutdown[6]. >> Number of existing issues observed in this release is 3- toaster [7], >> Build-appliance [8] and Beaglebone [9] For ptest, 3 package tests are >> failing in this release which were passing in previous release: python >> [10], python3[11] and strace[12]. >> 3 packages are facing timeout issues: lttng-tools [13], openssh [14] >> and python3 [15]. > >Thanks for this. I have some questions/observations. > >Looking at the Intel/WR report, I see tests which start oeselftest_XXX for sdk- >extras and qemu-shutdown. I think this means you have some QA test >infrastructure running "oe-selftest -r runqemu,meta_ide", iterating over >MACHINE=qemuppc, qemumips, qemuarm, qemux86? > >Is this some automation we're missing in the autobuilder configuration? >We all other tests covered and this is the only remaining automated piece we >haven't covered? What configuration are we missing exactly for the missing >tests? Just run for MACHINE=qemuppc /qemumips / qemuarm / qemux86 > >I'm partly wondering how you found the shutdown issue but this would explain >that. > >I think going forward we need to add some kind of "who" identifier to the test >results so we can say where/who they came from (main autobuilder, Intel, WR, >anywhere else). We could add a resulttool command to "stamp" a set of test >results with this, maybe as a parameter to the store command? Will work on resulttool to add this enhancement. Though not sure about timeline as of now. > >Of the bugs, I didn't see any which I think should block M3, I think we >probably >should release that and move forward to M4. I do want to see some of these >fixed before we build M4 though. I've made comments on them below. > >> New Bugs : >> >> [5] Bug 13237 - [2.7 M3 RC1][OE-selftest][Opensuseleap 15.0][Public >> AB]:"test_wic_cp_ext" failing for Opensuseleap 15.0. >> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13237 > >Ross: Are you looking into that one? > >> [6] Bug 13234 - [2.7 M3 RC1] qemumips & qemumips64: failed to shutdown >> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13234 > >This needs looking into and fixing, as well as figuring out why the autobuilder >doesn't see this (see above for my hypothesis). > >> Previous Bugs observed in this release: >> >> [7] Bug 13191 – [Test Case 1439] Build Failure after adding or >> removing packages with and without dependencies >> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13191 >> >> [8] Bug 12991 - [Bug] [2.6 M4 RC1][Build-Appliance] Bitbake build- >> appliance-image getting failed during building image due to webkitgtk >> package. >> https://bugzilla.yoctoproject.org/show_bug.cgi?id=12991 > >We need to do something about this. I believe its related to resource >starvation in >the VM. > >> [9] Bug 13153 – [2.7 M2 RC1] Systemtap doesn't work on beaglebone >> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13153 > >I'm hoping a SRCREV bump for beaglebone-yocto fixes this. > >> ptest Bugs: >> >> [10] Bug 13249 - [2.7 M3 RC1] python ptest failure >> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13249 > >I'm hoping a patch from Ross in master fixes this, need to retest ptest with >this >applied. > >> [11] Bug 13253 - [2.7 M3 RC1] python3 ptest failure >> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13253 > >I'm hoping a patch from Ross in master fixes this, need to retest ptest with >this >applied. > >> [12] Bug 13254 - [2.7 M3 RC1] strace ptest failure >> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13254 > >No ideas on this one yet. > >> [13] Bug 13255 - [2.7 M3 rc1] lttng-tools ptest facing timeout issue >> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13255 > >There are patches which are due to arrive soon which should address this. > >> [14] Bug 13256 - [2.7 M3 rc1]
