Re: [yocto] is there a rationale for YP using sysvinit as default init manager?

[Richard Purdie]

On Fri, 2019-11-22 at 10:08 +1300, Paul Eggleton wrote:
> On Friday, 22 November 2019 9:40:35 AM NZDT Richard Purdie wrote:
> > On Thu, 2019-11-21 at 14:02 -0500, Robert P. J. Day wrote:
> > >   don't get me wrong, i have no problem with that, but a
> > > colleague
> > > asked me what the reason was for using sysvinit as the *default*.
> > > i
> > > hemmed and hawed and suggested it was for simplicity and
> > > reliability,
> > > and that a lot of embedded systems didn't need the flashy
> > > features of
> > > systemd, and so on.
> > > 
> > >   is there any short answer to give to that question?
> > 
> > The project existed before systemd and we haven't changed the
> > default.
> > 
> > We can change the default, it just means someone going through and
> > fixing the build failures it generates and rewriting all the test
> > metadata to invert poky and poky-altcfg. Personally I've got other
> > things I'd prefer to do...
> 
> Kai was working on changing this in the last cycle but AFAICT not all
> issues were able to be resolved in time. Kai, do you have a status
> update?

We got so far and after looking at the position we ended up I decided
it was easier to switch poky-altcfg rather than change poky and/or OE
defaults. I resolved that bug as "complete" as we now had testing of
systemd on a near enough equal footing to sysvinit which was the
concern people had raised. There are problems in oe-selftest and some
other corner cases but nothing people seem to be running into day-to-
day.

There has been representation at OE meetings, in surveys and from YP
members for us not to switch the default FWIW.

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] is there a rationale for YP using sysvinit as default init manager?

[Richard Purdie]

On Thu, 2019-11-21 at 14:02 -0500, Robert P. J. Day wrote:
>   don't get me wrong, i have no problem with that, but a colleague
> asked me what the reason was for using sysvinit as the *default*. i
> hemmed and hawed and suggested it was for simplicity and reliability,
> and that a lot of embedded systems didn't need the flashy features of
> systemd, and so on.
> 
>   is there any short answer to give to that question?

The project existed before systemd and we haven't changed the default.

We can change the default, it just means someone going through and
fixing the build failures it generates and rewriting all the test
metadata to invert poky and poky-altcfg. Personally I've got other
things I'd prefer to do...

Cheers,

Richard



-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] Yocto Project Status WW46'19

[Richard Purdie]

On Thu, 2019-11-14 at 16:11 -0800, akuster808 wrote:
> 
> Hello Stephen,
> 
> On 11/12/19 7:47 AM, sjolley.yp...@gmail.com wrote:
> > Current Dev Position: YP 3.1 M1 
> > Next Deadline: YP 3.1 M1 build Dec. 2, 2019
> >  
> > SWAT Team Rotation:
> > SWAT lead is currently: Anuj 
> > SWAT team rotation: Anuj -> Chen on Nov. 15, 2019
> > SWAT team rotation: Chen > Paul on Nov. 22, 2019
> > https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team
>  
> I watch and triage stable branch builds I initiate week after week
> and I no longer want to take on the responsibilities for the other
> builds. I therefor am removing my name from the normal swat rotation
> and have updated the wiki accordingly.  This should set the
> appropriate expectations. This unfortunately puts the full burden
> back on Intel and WindRiver.  If things should change in the future,
> I will let you know.

Thanks for your work on that team, its been hugely appreciated. 

I think it may be time that we suspend the SWAT process and have the
build owners handle it themselves.

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] bitbake SRC_URI fetch Azure DevOps repository Azure DevOps Services Basic

[Richard Purdie]

On Wed, 2019-11-13 at 09:02 +, Samuel Jiang (江騏先) wrote:
> I got below error message:
> crashdump-git-r0 do_fetch: Fetcher failure: Fetch command export 
> PSEUDO_DISABLED=1; unset _PYTHON_SYSCONFIGDATA_NAME; export 
> DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus"; export 
> SSH_AGENT_PID="2255"; export SSH_AUTH_SOCK="/run/user/1000/keyring/ssh"; 
> export PATH="[private_data]"; export HOME="/home/samueljiang";
> git -c core.fsyncobjectfiles=0 ls-remote 
> git://quanta01.visualstudio.com/OpenBMC/_git/crashdump  failed with exit code 
> 128, output:
> fatal: unable to connect to quanta01.visualstudio.com:
> quanta01.visualstudio.com[0: 2620:1ec:21::18]: errno=Network is unreachable
> quanta01.visualstudio.com[1: 13.107.42.18]: errno=Connection timed out
> 
> Seems this url with git:// prefix could not connect in Azure DevOps 
> 
> Document[https://docs.microsoft.com/en-us/azure/devops/repos/git/use-ssh-keys-to-authenticate?view=azure-devops].

I now realise what the problem is. Whatever this git server you're
talking to is, it does not work the same as is documented for the "git
clone" manpage.

There is no option to force bitbake to use the syntax you're asking for
since the manpage says the synax its using is valid. You could patch
bitbake to force it to use that syntax with a patch like:

diff --git a/bitbake/lib/bb/fetch2/git.py b/bitbake/lib/bb/fetch2/git.py
index fa41b078f12..f20c1f36b82 100644
--- a/bitbake/lib/bb/fetch2/git.py
+++ b/bitbake/lib/bb/fetch2/git.py
@@ -588,6 +588,8 @@ class Git(FetchMethod):
 username = ud.user + '@'
 else:
 username = ""
+if ud.proto == "ssh":
+return "%s%s:%s" % (username, ud.host, ud.path[1:])
 return "%s://%s%s%s" % (ud.proto, username, ud.host, ud.path)
 
 def _revision_key(self, ud, d, name):


which in my local tests appeared to give the result you're asking for
but that shouldn't be required with a server that adheres to what the
git manual says is supported.

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] bitbake SRC_URI fetch Azure DevOps repository Azure DevOps Services Basic

[Richard Purdie]

On Wed, 2019-11-13 at 03:06 +, Samuel Jiang (江騏先) wrote:
> I try use 
> SRC_URI = "git://quanta01@vs-
> ssh.visualstudio.com/v3/quanta01/OpenBMC/crashdump;protocol=ssh;nobra
> nch=1"
> 
> the bitbake response below error message:
>  git -c core.fsyncobjectfiles=0 ls-remote 
> ssh://quant...@vs-ssh.visualstudio.com: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 discussed with Microsoft support team,
> the Azure DevOps support SSH url clone without [ ssh:// ] prefix,
> like below:
> git -c core.fsyncobjectfiles=0 ls-remote 
> quant...@vs-ssh.visualstudio.com:v3/quanta01/OpenBMC/crashdump
> 
> Does bitbake support git SRC_URI without any prefix or need extra
> with Azure SSH protocol support it?

Have you tried:

SRC_URI = 
"git://quant...@vs-ssh.visualstudio.com/v3/quanta01/OpenBMC/crashdump;protocol=git;nobranch=1"

(changing protocol to git)
?

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] bitbake SRC_URI fetch Azure DevOps repository Azure DevOps Services Basic

[Richard Purdie]

On Mon, 2019-11-04 at 02:52 +, Samuel Jiang (江騏先) wrote:
> 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?


Try:

SRC_URI = 
"git://quant...@vs-ssh.visualstudio.com/v3/quanta01/OpenBMC/crashdump;protocol=ssh;nobranch=1"

as I think you didn't convert the url to our syntax correctly.

Cheers,

Richard


> Thanks,
> 
> Samuel Jiang
> -- Forwarded message --
> From: Alex Chong (Shanghai Wicresoft Co,.Ltd.) <
> v-chu...@microsoft.com>
> Date: 2019年10月31日 PM5:39 [+0800]
> To: Samuel Jiang (江騏先) 
> Cc: support , Alex Chong
> (Shanghai Wicresoft Co,.Ltd.) 
> 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.
> > 
> > I have verified that our Azure DevOps Organization Repo could be
> > clone through SSH authentication successfully.
> > I create a new SSH key and add it to Azure DevOps SSH public keys.
> >  
> > 
> > Then I use git clone command and clone this repo successfully. The
> > url is “v-chucho-micros...@vs-ssh.visualstudio.com:v3/v-chucho-
> > microsoft/testCodeCoverage/testCodeCoverage”
> > 
> > 
> > My testing verify that SSH Authentication is available, and the url
> > given by Azure DevOps is correct.
> > 
> >  
> > 
> > Then I also test it in GitHub, and succeed. The only difference is
> > the url of GitHub is “g...@github.com:xx.git”
> >  
> > 
> > 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@vs-
> > ssh.visualstudio.com:v3/quanta01/OpenBMC/crashdump;protocol=ssh;nob
> > ranch=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?
> > 
> >  
> > 
> > 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
> > 
> >  
> > 
> > 
> > 
> > Support Engineer
> > 
> > Microsoft APAC Developer Support Team
> > 
> > Customer Service & Support (CSS)
> > 
> > Email: v-chu...@microsoft.com
> > 
> > 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 (江騏先) 
> > Sent: Thursday, October 31, 2019 12:16 PM
> > To: Alex Chong (Shanghai Wicresoft Co,.Ltd.) <
> > v-chu...@microsoft.com>
> > Cc: 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@vs-
> > ssh.visualstudio.com:v3/quanta01/OpenBMC/crashdump;protocol=ssh;nob
> > ranch=1"
> > 
> > the bitbake response below error message:
> > git -c core.fsyncobjectfiles=0 ls-remote 
> > ssh://quant...@vs-ssh.visualstudio.com: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-chu...@microsoft.com>
> > Sent: Thursday, October 31, 2019 10:32 AM
> > To: Samuel Jiang (江騏先) 
> > Cc: Alex Chong (Shanghai Wicresoft Co,.Ltd.) <
> > v-chu...@microsoft.com>; support <
> > supp...@mail.support.microsoft.com>
> > Subject: RE: 119102923000220 use yocto bitbake SRC_URI fetch Azure
> > DevOps repository Azure DevOps Services Basic
> > 
> >  
> > 
> > Hi Samuel,
> > 
> >  
> > 
> > 

Re: [yocto] [EXTERNAL] Re: Issues adding bare meta toolchain to yocto build

[richard . purdie]

On Thu, 2019-10-24 at 15:37 +, Westermann, Oliver wrote:
> > On Thu, 2019-10-24 at 04:01 +, Richard Purdie wrote:
> > If its a native recipe, there are no packages and therefore FILES
> > doesn't make sense.
> 
> Oh, I have to admit I'm pretty new to the concept of the native
> packages.
> Where can I find the list of files that are considered to be
> installed into a "native" packages sysroot?

http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/staging.bbclass

SYSROOT_DIRS_NATIVE vs. just SYSROOT_DIRS
(at the top of the file)

The code which uses these is below in that file and handles which files
get "staged". We stage a different set for native and target.

> An good option for me would be to eg. install the toolchain into the
> native sysroots /opt/ dir for usage by other recipes.

You can probably do that by extending SYSROOT_DIRS in the recipe.

> > Can you confirm that recipe does work?
> 
> For the TI recipe, no, I can't. I found it online and used it as a
> guide for my first steps on the topic.
>
> 
> > If you install the binaries into ${bindir} they will. If you place
> > them
> > somewhere else which the system doesn't know about, they probably
> > won't.
> > 
> > There are ways to make alternative locations work but I don't see
> > any
> > of that in the above recipe.
> 
> Can you point me to these ways? :)

See above, easiest is extending SYSROOT_DIRS.

> > There isn't anything that special about a baremetal compiler except
> > it sets some different default flags and is missing the library
> > support.
> 
> I agree, though using linaro has the benefit that we would use the
> same toolchain in yocto as in "regular development" of the m4
> functionality.

Agreed. If you want a newlib compiler (which is a bit more than
baremetal as I understand the term) you'd need a multiconfig build to
generate one too as discussed in the other part of the thread.

Cheers,

Richard





-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [EXTERNAL] Re: Issues adding bare meta toolchain to yocto build

[richard . purdie]

On Thu, 2019-10-24 at 10:30 -0400, William Mills wrote:
> On 10/24/19 10:02 AM, richard.pur...@linuxfoundation.org wrote:
> > On Thu, 2019-10-24 at 09:43 -0400, William Mills wrote:
> > > Then understand that you will need to supply your own gcc
> > > compiler
> > > helpers and all stdc functions even the ones that port well like
> > > strlen and memcpy.  (Because everyone should embedded their own
> > > unoptimized memcpy in their projects.)
> > 
> > Right, that is by definition baremetal.
> > 
> 
> Well not really.  All the "bare-metal" toolchains I have used come
> with a proper libgcc and some conig of newlib that at least gets you
> usable strlen and memcpy etc.  How much of the rest of it is usable
> on your platform is variable.
> 
> This is true of the toolchain Oliver is pointing at and has been true
> back to 2007 when I was using codesourcery releases.

The baremetal libgcc would be libgcc-initial in OE terms. As for
"baremetal", OE defines that as no library. You can see the options in
this listing:

http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/distro/include

tclibc-baremetal.inc
tclibc-glibc.inc
tclibc-musl.inc
tclibc-newlib.inc

So we support newlib builds but that is different to our definition of
baremetal. So we conflicting usage of terms.

> > You're probably right to have some concerns in that its not a well
> > travelled path. There are libc specifics encoded into libgcc but I
> > can't quite see where they change how gcc behaves other that the
> > default option selection.
> > 
> > Equally there may be something I'm missing.
> > 
> > For full disclosure, gcc is built against linux-libc-headers
> > wherease
> > with baremetal it would be built without headers. I believe that
> > changes the default options gcc uses for compiling but not the way
> > the
> > compiler itself works.
> 
> "baremetal" would be compiled against some config of newlib headers.
> newlib has its own issues and many config choices (you get to pick
> your threading model: none, bad, or hacky).  For TI-RTOS I think we
> rebuild it with a different thread model.

Our baremetal is compiled with no headers. Newlib is effectively like
choosing a different C library, and yes, gcc would be built against its
headers and use it to link against. You would need multiconfig to mix a
newlib and musl/glibc toolchain.

Sorry for the confusion over the terms.

Cheers,

Richard





-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [EXTERNAL] Re: Issues adding bare meta toolchain to yocto build

[richard . purdie]

Hi Bill,

On Thu, 2019-10-24 at 09:43 -0400, William Mills wrote:
> I started looking at this thread because I had the same
> questions.  Is it possible to make a recipe depend on another version
> of GCC and restart the whole GCC build process again with a different
> config.
> 
> Or does this need multi-config?

A different version of gcc would be most easily handled with
multiconfig, yes.

> This is the question I was trying to ask the other day.
> 
> > I'm saying I don't think you need a second toolchain. I think you
> > could
> > use your existing arm toolchain with the right compiler options.
> > 
> > See 
> > https://stackoverflow.com/questions/28514507/what-makes-bare-metal-tool-chains-special
> > 
> > So you'd just add the right flags to the compiler, something like:
> > 
> > XXX-gcc -mcpu=cortex-m4 -march=armv7e-m -ffreestanding -nostdlib
> > -nostdinc
> > 
> > i.e. tell it which processor to target and not to use standard
> > libraries/includes.
> > 
> > There isn't anything that special about a baremetal compiler except
> > it
> > sets some different default flags and is missing the library
> > support.
> > 
> 
> Really??

As I understand it. I'm by no means an expert but I do my best with the
OE toolchain recipes.

> Lets start with the fact that the ARM binary toolchain has been
> tested with M4 cores.

Sure, I'm not claiming this is a well travelled path. I don't see why
it shouldn't work though, or why it makes much difference with the
right compiler options.

> Then understand that you will need to supply your own gcc compiler
> helpers and all stdc functions even the ones that port well like
> strlen and memcpy.  (Because everyone should embedded their own
> unoptimized memcpy in their projects.)

Right, that is by definition baremetal.

> This works for the kernel and u-boot but they were designed for this
> and have many eyes on their version of memcpy etc.  They are also
> running on the same CPU core as the Linux user space.
> 
> Given this I can believe this would work for CLang/LLVM if M4 support
> was enabled at build time.  I am not convinced for GCC.
> 
> If the above really works then why does gcc insist on being compiled
> again after the c library has been compiled?  I have asked and never
> got an answer that I understood.  I have been told that it looks at
> the c library headers and changes what it builds into the compiler.

I've never understood that either and looked into it. Back in December
last year, we dropped gcc-cross-initial:

http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/recipes-devtools/gcc?id=0afd3ac3ada35dd986aaf3be41d7177dc6b71ade

After that, YP does no longer rebuild gcc after building the c library,
there is one cross toolchain. That one toolchain is used for all
different arm targets, its only architecture specific.

The only thing we do rebuild is libgcc, which is why there is still a
libgcc-initial and a libgcc, the latter being built after libc. That
much kind of makes sense.

>   Does all that magic go away with just -nostdinc and -nostdlib?

I believe so, yes.

> I know this works for the kernel but targeting an RTOS or bare-metal
> for a very different core would make me nervous.  Especially true if
> the M4 would need to link libraries that were built outside of OE.
> 
> I know I am pushing back hard but I am also hoping you will convince
> me I am wrong.

You're probably right to have some concerns in that its not a well
travelled path. There are libc specifics encoded into libgcc but I
can't quite see where they change how gcc behaves other that the
default option selection.

Equally there may be something I'm missing.

For full disclosure, gcc is built against linux-libc-headers wherease
with baremetal it would be built without headers. I believe that
changes the default options gcc uses for compiling but not the way the
compiler itself works.

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [EXTERNAL] Re: Issues adding bare meta toolchain to yocto build

[richard . purdie]

On Thu, 2019-10-24 at 10:03 +, Westermann, Oliver wrote:
> > On Wed, 2019-10-23 at 15:34 +, Richard Purdie wrote:
> > > On Wed, 2019-10-23 at 11:23 +, Westermann, Oliver wrote:
> > > Hey,
> > > [...]
> > > Any suggestions on what I'm doing wrong or how to debug this
> > > further?
> > Sounds like the sysroot filtering code doesn't know about this
> > directory and therefore doesn't pass it through to the recipe
> > sysroot?
> 
> Sorry to ask dumb questions, but what do you mean by "this
> directory"?
> The toolchain directory created by the TI recipe? Shouldn't that be
> handled by FILES_${PN}?

If its a target recipe, FILES makes sense.

If its a native recipe, there are no packages and therefore FILES
doesn't make sense.

> > The recipe you link to is for an on target compiler, not one in the
> > sysroot.
> 
> Again, might be a stupid missunderstanding on my side: The recipe I
> linked extracts a precompiled toolchain that is suitable only for
> x86_64 systems and  allows a "native" package. From my current
> understanding, a native package is to be used on the build host,
> which is what I'm intending to do here.

You are correct, that recipe disables the target version and appears to
provide a native binary. I can't actually see how it can work though.
Can you confirm that recipe does work?

> I managed to sucessfully add a native recipe for the NXP code signing
> tool (which is only provided as a precompiled binary as well) which
> works as expected.

If you install the binaries into ${bindir} they will. If you place them
somewhere else which the system doesn't know about, they probably
won't.

There are ways to make alternative locations work but I don't see any
of that in the above recipe.

> > I'm actually a little surprised you can't use our standard cross
> > compiler assuming this M4 core is on an ARM chip? It should be a
> > case
> > of passing the right options to the compiler to target the M4?
> 
> I'm totally up for any infos on how to do this! I did google around
> for recipes for examples that build a non-linux binary using yocto,
> but I couldn't really find anything or any documentation. But maybe
> my searchterms (along "build baremetal  arm binary using yocto") were
> off target. Can you point me at documentation, examples,
> searchterms..?

I'm saying I don't think you need a second toolchain. I think you could
use your existing arm toolchain with the right compiler options.

See 
https://stackoverflow.com/questions/28514507/what-makes-bare-metal-tool-chains-special

So you'd just add the right flags to the compiler, something like:

XXX-gcc -mcpu=cortex-m4 -march=armv7e-m -ffreestanding -nostdlib -nostdinc

i.e. tell it which processor to target and not to use standard
libraries/includes.

There isn't anything that special about a baremetal compiler except it
sets some different default flags and is missing the library support.

Cheers,

Richard




-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Issues adding bare meta toolchain to yocto build

[Richard Purdie]

On Wed, 2019-10-23 at 11:23 +, Westermann, Oliver wrote:
> Hey,
> 
> I'm having issues adding a build for a bare metal target to my yocto
> toolchain. I've a NXP SoC with a M4 core and I would like to
> integrate the M4 binary build into yocto.
> My M4 binary has a CMAKE file that depends on ARMGCC_DIR being set to
> locate the toolchain and everything works fine locally.
> 
> I've create a recipe for the toolchain that is heavily inspired by a
> TI recipe for the gcc-arm-none-eabi (available here: 
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-ti/devtools/gcc-arm-none-eabi_7-2018-q2-update.bb?h=master
> ).
> I've made sure that GCC_ARM_NONE_TOOLCHAIN_RECIPE is set.
> 
> After calling bitbake -cpopulate-sysroot gcc-arm-none-eabi-native the
> image/${GCC_ARM_NONE_TOOLCHAIN_RECIPE} path contains the complete
> toolchain.
> 
> My M4 recipe looks like this (plus SUMMARY, LICENSE, SRC_URI, ...):
> 
> inherit pkgconfig cmake
> DEPENDS = "gcc-arm-none-eabi-native"
> 
> S = "${WORKDIR}/git "
> 
> EXTRA_OECMAKE = '-DCMAKE_TOOLCHAIN_FILE="../armgcc.cmake" \
>  -G "Unix Makefiles" \
>  -DCMAKE_BUILD_TYPE=release'
> 
> From my understanding depending on gcc-arm-none-eabi-native should
> result in the native toolchain being installed into the m4's recipe-
> sysroot-native folder.
> The sysroot-providers in the recipe-sysroot-native folder does list
> gcc-arm-none-eabi-native, but I don't get the files and therefore
> have no toolchain.
> 
> Any suggestions on what I'm doing wrong or how to debug this further?

Sounds like the sysroot filtering code doesn't know about this
directory and therefore doesn't pass it through to the recipe sysroot?

The recipe you link to is for an on target compiler, not one in the
sysroot.

I'm actually a little surprised you can't use our standard cross
compiler assuming this M4 core is on an ARM chip? It should be a case
of passing the right options to the compiler to target the M4?

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] QA notification for completed autobuilder build (yocto-2.6.4.rc2)

[richard . purdie]

On Wed, 2019-10-23 at 08:00 +, Jain, Sangeeta wrote:
> Hello all,
> 
> This is the full report for 2.6.4 RC2:  
> https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults
> 
> === Summary 
> No high milestone defects.  
> No new defect found in this cycle.
> The stap test case failure on beaglebone still exists in this release
> (BUG id:13273). 
> 
> === Bugs 
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13273
> 
> Thanks & Regards,
> Sangeeta Jain

Thanks Sangeeta and team!

Rather than respin the release we're thinking we should perhaps release
and then add the fix for the stap issue to the branch. The TSC will
make a decision on that, hopefully tomorrow. We're hoping to get the
warrior point release sorted ASAP but the remaining issue is proving
tricky to resolve.

Cheers,

Richard



-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Reducing the size of the image by optimizing python

[richard . purdie]

On Sat, 2019-10-19 at 14:55 +, Abhi Arora wrote:
> Thanks your for the suggestion. 
> 
> From where I can find out what modules and packages python3-misc
> downloads and installs? I am new to yocto and Don't know where to
> look for. I tried grep but didn't help me.

python3-misc is a package. You can look at its dependencies to see what
it adds to the image.

> And how about optimization using pyc file? Is it doable?

Start simple. If you have python3-misc installed its using a lot of
space and is the sensible place to start with trimming things down.

Optimising to just pyc files is an optimisation further than most
people find they need and will be much harder to do.

Cheers,

Richard



-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Reducing the size of the image by optimizing python

[Richard Purdie]

On Sat, 2019-10-19 at 12:45 +, Abhi Arora wrote:
> Thanks for the reply. Can you help me which file to modify to prevent
> downloading certain packages and modules using BAD_RECOMMENDATION? 
> 
> And how to have only pyc files in the final image to improve speed
> and reduce footprint?
> 
> Following are the lines in my yocto project which install python
> packages.
> 
> IMAGE_INSTALL_append = " \
> python3 \
> python3-core \
> python3-misc \
> python3-async \
> python3-six \
> python3-websockets \
> python3-requests \
> python3-urllib3 \
> python3-chardet \
> python3-websocket-client \
> python3-pyopenssl \
> python3-simplejson \
> python3-cython \
> 
> Pardon for some stupid questions as I am new to yocto.

Take python3-misc out that list as its huge. See if anything breaks, if
so, try and install just what you need, not the large "catchall"
package.

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [opkg-devel] [OE-core][opkg-utils ] Bug 13528 : adding SPDX license identifier

[richard . purdie]

On Fri, 2019-10-11 at 15:54 +, Alejandro Del Castillo wrote:
> On 10/11/19 8:51 AM, Ycn aKaJoseph wrote:
> > Hi guys,
> > 
> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=13528 
> > <
> > https://urldefense.com/v3/__https://bugzilla.yoctoproject.org/show_bug.cgi?id=13528__;!fqWJcnlTkjM!8RtsWJXbDz_l063ZSVKrRMwvQ5KGdD0lk9aSjlUW9VHM2wufITJnBuIvovQxoT0yJXu-6Q$
> > >
> > 
> > I'm about to work on that bug however most of the script in opkg-
> > utils 
> > dir are un-licenced and there's no hint for me to decide what SPDX 
> > Identifier to add.
> 
> thanks for doing this!
> 
> > The doubt concerns those script :
> > makePackage
> > opkg-build
> > opkg-buildpackage
> > opkg-compare-indexes
> > opkg-diff
> > opkg-extract-file
> > opkg-graph-deps
> > opkg-list-fields
> > opkg-make-index
> > opkg-show-deps
> > opkg-unbuild
> > opkg-update-index
> > 
> > What license do you want them to carry ?
> 
> Looking at the commit history, opkg-graph-deps was authored by Haris 
> Okanovic, and the rest by Richard Purdie (included them on the
> thread).
> 
> My take on it:  since opkg is licensed as GPLv2+, and the files that 
> have a license in opkg-utils are GPLv2+, make sense to me to license
> the rest as GPLv2+ too.

I didn't author these, they were imported from ipkg-utils which was
part of handhelds.org. I did modify things quite a bit during the
import.

handhelds.org's CVS repos aren't there any more but I do have old
sources lying around locally. I have a snapshot of the CVS repo from
20050930 and it has GPLv2 COPYING file (not 2+, just 2).

I'd suggest we follow the original licensing of that and go with GPLv2.

Cheers,

Richard




-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] QA notification for completed autobuilder build (yocto-3.0.rc2)

[richard . purdie]

On Thu, 2019-10-10 at 07:37 +, Jain, Sangeeta wrote:
> Hello All,
> 
> Intel and WR YP QA is planning for QA execution for YP build yocto-
> 3.0.rc2.
> We are planning to execute following tests for this cycle:
> 
> OEQA-manual tests for following module:
> 1. OE-Core
> 2. BSP-hw
> 3. BSP-Qemu
> 
> Runtime auto test for following platforms:
> 1. MinnowTurbot 32-bit
> 2. Coffee Lake
> 3. NUC 7
> 4. NUC 6
> 5. Edgerouter
> 6. MPC8315e-rdb
> 7. Beaglebone
> 
> ETA for completion is next Tuesday, October 15.

Thanks Sangeeta!

There were some failures in the build, specifically the build
performance results didn't merge to the repo correct and an oe-selftest 
failed.

I fixed the performance results manually and pushed them. The oe-
selftest in the reproducibility test is a known issue with perl from
the host system.

I don't believe either issue should affect the release.

Cheers,

Richard



-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Task vardeps on a variable changed externally

[Richard Purdie]

On Wed, 2019-10-09 at 10:42 +0100, Andrei Gherzan wrote:
> I struggle to figure out an issue that I lately got into. I want to
> have a recipe which writes a manifest of all the layers part of the
> build. 
> These layers are all git repositories and I want their revision to
> be exposed at runtime. So I obviously have a a python function which 
> computes let's say, for the sake of example, a revision of one layer.
> 
> def get_rev(d):
>  # returns revision of a repository
> 
> LAYER_REVISION := "${get_rev(d)}"
> 
> The recipe also has a `do_compile` variable dependency:
> do_compile[vardeps] += "LAYER_REVISION"
> 
> Checking the task signature I see the inclusion of the expanded
> variable 
> LAYER_REVISION.
> 
> Now, if I externally change the revision of that respective layer
> the 
> task is not re-triggered even so the recipe environment reports the 
> updated variable (bitbake -e). What is even more confusing is that
> if 
> for whatever reason the do_compile task gets invalidated (or I force 
> it), the build system returns a "basehash value changed" error.
> 
> I would expect that the change of revision to trickle a task 
> invalidation and the task to be rerun but that doesn't seem to happen
> as described above.

The hashes are generated at parse time. The key question is how does
bitbake know when to reparse this recipe?

You'd need to make the recipe always reparse so it can rerun that
function.

I think BB_DONT_CACHE = "1" may do that.

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] global class that others will inherit

[Richard Purdie]

On Thu, 2019-10-03 at 11:36 +0200, Łukasz Tasz wrote:
> Hi, 
> this is my first post here, so big hello!
> 
> I have a problem which you might help me to solve. 
> I have quite complex configuration, and I would like to inject
> something into build system in a right way. 
> 
> I already did some POC work, and adjusted cmake.class but this is
> rather dirty hack, but also do not aplly to all of components, only
> to those who inherits from cmake.
> I would like to adjust local.conf, put there INHERITS+="mytuning" and
> I would expect that everybody will inherit. I'm prepending/appending 
> This is happening, but my class in shell like, and python recepies
> throw exception because of  syntax error... 
> 
> 
> question, how to provide global class, that will inject python/shell
> depending on context? mayby my way is simply wrong?

It would help to understand where you're trying to add the
shell/python.

I'm guessing you're adding it to functions using append/prepend?

Perhaps try it at the task level with the prefuncs and postfuncs flags
to add extra functions?

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] Yocto Project Status WW40’19

[richard . purdie]

On Tue, 2019-10-01 at 21:16 +0200, Alexander Kanavin wrote:
> On Tue, 1 Oct 2019 at 16:54, Stephen K Jolley <
> sjolley.yp...@gmail.com> wrote:
> > A significant performance problem has been found on the autobuilder
> > where some builds are scaling in time badly as the sstate cache
> > grows, taking 12 hours or more in some cases. Unfortunately nobody
> > seems motivated to help work on this kind of issue.
> > 
> 
> Wait a moment, I believe there is a patch for this issue?
> http://lists.openembedded.org/pipermail/openembedded-core/2019-September/287445.html

Sorry, that was copied form last week and should have been updated but
I became distracted in completing the blockers list.

There is a patch and the plan is to test that on the autobuilder to
compare performance, I appreciate the patch!

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

[richard . purdie]

On Mon, 2019-09-23 at 07:37 +, Jain, Sangeeta wrote:
> Hi Richard,
> 
> LSB support was expected to be removed from build 'yocto-2.8_M3.rc1'
> onwards, but link on AB still points to LSB images.
> The images present inside 
> https://autobuilder.yocto.io/pub/releases/yocto-2.8_M3.rc1/machines/genericx86-64-lsb/
>   are built with systemd as init manager.
> 
> Can you please confirm if these are altcfg images and the link name
> needs to updated?

Well spotted!

I can confirm these are altcfg images which have systemd as the init
manager.

For backwards compatibility the autobuilder target names didn't change
but the configuration they're built with did. I hadn't realised this
would be visible in the release so we may need to think about that for
M4 but they are altcfg images.

[Added Vineela to cc:]

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Pointless unlink-link in strip_execs?

[Richard Purdie]

On Fri, 2019-09-06 at 11:52 -0700, Kaz Kylheku wrote:
> Hi,
> 
> I'm looking at meta/lib/oe/package.py, function strip_execs, under
> Yocto 
> 2.5.
> 
> It has this tidbit:
> 
>  if s.st_ino in inodes:
>  os.unlink(file) # <---
> of 
> interest
>  os.link(inodes[s.st_ino], file) #
>  else:
>  # break hardlinks so that we do not strip
> the 
> original.
>  inodes[s.st_ino] = file
>  bb.utils.copyfile(file, file)
>  elffiles[file] = elf_file
> 
> If s.st_ino is in the inodes dictionary, doesn't that mean that the 
> paths
> inodes[s.st_ino] and file are already hard links to the same object?
> 
> In other words, those two link and unlink lines don't achieve
> anything?

I think its more subtle than this.

It will be in that inodes list if we already want to break hardlinks to
the copy having gone through the "else" section once before already. We
want one copy and all the hardlinks pointing to that copy.

The reason is so that we have one stripped copy and in our packaged
data, all copies hardlink to that copy.

Cheers,

Richard



-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto Project Status WW36’19

[Richard Purdie]

Current Dev Position: YP 2.8 M4 Feature FreezeNext Deadline: YP 3.0
Final Release 25th Oct
SWAT Team Rotation:SWAT lead is currently: ArminSWAT team rotation:
Armin -> Paul on Sept. 6, 2019SWAT team rotation: Paul -> Ross on Sept.
13, 2019
https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team
Next Team Meetings:Bug Triage meeting Thursday Sept 5th at 7:30am PDT (
https://zoom.us/j/454367603)Monthly Project Meeting Tuesday Sept. 3rd
at 8am PDT (https://zoom.us/j/990892712) Twitch - Next event is Tuesday
Sept. 10th at 8am PDT (https://www.twitch.tv/yocto_project)
Key Status/Updates:We’re now in feature freeze for 3.0 and working on
bug fixing for final releaseSeveral key 3.0 changes have now merged:5.2
linux-libc-kernel-headers5.2 kernel recipesRemoval of LSB and poky-lsb
and replacement with alt config testingPatches have significantly
reduced the dependency on python2Reproducible builds are now being
tested for core-image-minimalThere are the following changes still
under discussion/testing:Systemd vs. sysvinit defaults (maybe for the
poky alternative configuration tests)Making 5.2 the default kernel for
qemu (has regressions, see below)Hashserv performance issue
resolutionFinal configuration of hash equivalencytoolchain testsuite
patch seriesThe sstate hash equivalency continues to have challenges:we
need to rework the client/server communication to scale to the
autobuilderthere are some bugs in the code the autobuilder continues to
exposewe have cases where its not 100% clear what the correct behaviour
should betest cases are proving to be problematic to write in a
maintainable wayPatch merging is roughly up to date againWe have
several significant problematic bugs that are being worked on:5.2 stap
build issue on qemuarm5.2 kprobes error message (qemuarm64,
qemumips64)qemumips machine hangIf anyone has any status items for the
project they’d like to add to the weekly reports, please email
Richard+Stephen.
Planned Releases for YP 3.0 {2.8}:M3 Release 6th SeptM4 Cutoff 30th
Sept - this will be YP 3.0.YP 3.0 {2.8 (M4)} Final Release 25th Oct
Planned upcoming dot releases:YP 2.7.2 (Warrior) is planned for after
YP 3.0 release.YP 2.6.4 (Thud) is planned for after YP 2.7.2  release.
Tracking Metrics:WDD 2413 (last week 2485) (
https://wiki.yoctoproject.org/charts/combo.html)Poky Patch
Metrics  Total patches found: 1470 (last week 1474)Patches in the
Pending State: 611 (42%) [last week 613 (41%)]
Key Status Links for YP:
https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.8_Statushttps://wiki.yoctoproject.org/wiki/Yocto_2.8_Schedulehttps://wiki.yoctoproject.org/wiki/Yocto_2.8_Features
The Yocto Project’s technical governance is through its Technical
Steering Committee, more information is available at:
https://wiki.yoctoproject.org/wiki/TSC
The Status reports are now stored on the wiki at: 
https://wiki.yoctoproject.org/wiki/Weekly_Status
[If anyone has suggestions for other information you’d like to see on
this weekly status update, let us know!]


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Recipe svn-fetcher and scmdata

[Richard Purdie]

On Mon, 2019-08-19 at 10:18 +0300, Teemu K wrote:
> Hi,
> 
> I have some recipes that fetch sources directly from svn. I'd like to
> keep the .svn to make it easier to commit changes. I checked that
> those are by default removed and that there is scmdata - option if
> those wanted to be kept.
> 
> I set the following src_uri:
> 
> SRC_URI =
> "svn://my.svn.server/svn/sw_components/program/;module=trunk;protocol
> =http;scmdata=keep"
> 
> Yet the .svn - data is removed from the sources under build -
> directory. It is in under download directory though so I'm wondering
> if I got this right in the first place?
> 
> I tried with devtool modify and it seems I ended up having .git -
> directory there although sources are in svn. Maybe it's systems
> 'subtle' way of telling me to switch to git? ;)
> 
> But should the scmdata=keep option work like I'm thinking it should
> and/or what I'm doing wrong?

I have a suspicion the build directory (${B}) may be getting cleaned by
one of the tasks and wiping out the scm data but its just a guess...

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [yocto-autobuilder2][PATCH 2/3] Added remote distribution of config JSON files

[Richard Purdie]

On Tue, 2019-07-30 at 14:36 -0400, Thomas Goodwin wrote:
> This feature/fix allows the worker to download the
> autobuilder helper JSON files from the controller
> rather than having to store them in the
> yocto-autobuilder-helper repository.  The process
> installs the file into the worker's
> builddir/yocto-autobuilder-helper path.
> 
> Signed-off-by: Thomas Goodwin 
> ---
>  builders.py | 22 ++
>  1 file changed, 22 insertions(+)

I like the idea however this is going to break the autobuilders as they
already use full paths in the variable.

I've merged some of the other patches but this one will need a little
further thought so we don't break the existing install.

The existing code also allows for different path locations on
individual workers (e.g. different username) which this would break.

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

[richard . purdie]

On Thu, 2019-08-08 at 03:00 +, Jain, Sangeeta wrote:
> Hello All,
> 
> This is the full report for 2.6.3 RC1:  
> https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/log/?h=intel-yocto-testresults
> 
> === Summary 
> No high milestone defects.  
> No new defects are found in this build.
> 
> ===QA notes=
> One minor issue is observed, after installed core-image-sato-sdk
> image to NUC7 internal harddisk, during boot up, it hangs at the
> Yocto splash screen. Need to manual press keyboard "enter" button
> multiple times for it to continue the boot and bring the screen to
> sato GUI. No bug is filed for this issue as this seems to be a minor
> issue and QA team investigating more onto it. This bug is
> consistently reproducible.

Thanks for running the tests.

FWIW the issue above sounds very like a lack of entropy problem, you
may want to look at the kernel configuration and see how its generating
entropy. If you can see the kernel boot messages and disable the splash
screen that would help debug it.

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] -staticdev packages not in sdk

[Richard Purdie]

On Tue, 2019-08-06 at 14:04 +, Koeller, Thomas wrote:
> browsing the list archives I came across an older thread that exactly
> describes the problem I am currently struggling with:
> 
> https://lists.yoctoproject.org/pipermail/yocto/2018-February/039950.html
> 
> In short, I have a recipe that produces only a couple of header files
> and a single static library, nothing to be installed on the target.
> So the base package is empty, which is why I have 'ALLOW_EMPTY_${PN}
> = "1"' in its recipe. In my image definition I have
> 'SDKIMAGE_FEATURES_append = " staticdev-pkgs"', so I expect the
> -staticdev package to be included when generating the SDK. This is,
> however, not the case. While a large number of -staticdev packages
> from different recipes is now included in the SDK, only the -dev
> package is included for my recipe, not the -staticdev (though the
> corresponding rpm is actually built and contains the library as
> expected, it just is not installed).
> 
> The archived mail thread referenced above suggests adding the base
> package ${PN} to IMAGE_INSTALL, which indeed does work for me.
> However, I do not understand why this is necessary at all, as my
> package is already referenced from another recipe by being listed in
> that recipe's DEPENDS variable, shouldn't that be enough?

DEPENDS means its a *build* time dependency. Since nothing links to it
there is no runtime dependency generated and this empty package you've
created is never installed into the image.

If its not installed into the image, the SDK for that image won't have
the corresponding -dev package.

If you add an RDEPENDS on the empty package to something in the image,
you'll probably find the -dev package then is installed.

>  Also, the -dev package gets installed into the SDK even without such
> cruft. As far as I can see, identical logic is applied to both -dev
> and -staticdev packages, so what is the difference?
> 
> I also found a different workaround for the problem: listing the
> -staticdev package in TOOLCHAIN_TARGET_TASK. Needless to say, this
> workaround is just as undesirable as the former one.

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] QA cycle report for 2.8 M2 RC1

[richard . purdie]

On Thu, 2019-08-01 at 07:30 +, Yeoh, Ee Peng wrote:
> This is the full report for 2.8 M2 RC1:  
> https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=zeus=d550d40646e1ca78a4b5d106e1b20831208b4c37
> 
> === Summary 
> No high milestone defects.  
> Two new defects are found in this cycle, both beaglebone and
> genericx86-64 facing shutdown hanging (BUG id:13461) and ptest failed
> (BUG id:13465). 
> One timeout issues observed in ptests was mdadm (BUG id: 13368).
> 
> === Bugs 
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13461
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13465
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13368

Thanks Ee Peng, Yi and everyone else in QA!

I think we do need to fix these regressions but they're not serious
enough to block release of M2, or require a rebuild. As such I think we
should release this.

Any other feedback from anyone?

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] RFC: dropping official support for Debian 8 / Opensuse 42.3

[Richard Purdie]

On Thu, 2019-07-18 at 12:31 +0100, Burton, Ross wrote:
> > CentOS 7 is based on Fedora 19 from 2013.
> > 
> > This is the oldest currently supported distribution, and when to
> > remove
> > support for it (replacing it with the not yet existing CentOS 8)
> > should
> > IMHO be part of this discussion.
> 
> Centos 7 support is, I believe, already patchy - I think we mandate
> the buildtools for that?  Any idea what the support plan for Centos 7
> will be once 8 is released, whenever that is?

There is some kind of official feed to add python 3.6 to it which we
use.

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [ptest-runner][PATCH v2 4/4] utils: ensure child can be session leader

[richard . purdie]

On Tue, 2019-06-25 at 20:51 -0500, Anibal Limon wrote:
> I plan to take the Richard patches, He added in the recipe to have
> real testing and looks like
> there aren't problems related to, Richard can you confirm it?,

We've been running the patches for a while in the recipe (since we last
discussed them) and we haven't seen any problems with them.

Thanks for looking at this, its a good one to get sorted out.

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH V3] update-rc.d: support enable/disable options

[richard . purdie]

On Thu, 2019-06-20 at 10:07 +0800, Changqing Li wrote:
> Please also help to review this patch, Thanks.

This patch needs to go to OE-Core for the bbclass part. The
documentation piece needs to be separated out as its a different 
repository. Also doesn't it depend on the change I just made to the
update-rc.d repo so there will be a SRCREV that needs to be updated
that this depends on?

Thanks,

Richard


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [ptest-runner][PATCH v2 4/4] utils: ensure child can be session leader

[richard . purdie]

On Wed, 2019-06-19 at 13:49 -0400, Randy MacLeod wrote:
> On 6/14/19 10:48 AM, Randy MacLeod wrote:
> > When running the run-execscript bash ptest as a user rather than
> > root, a warning:
> >bash: cannot set terminal process group (16036): Inappropriate
> > ioctl for device
> >bash: no job control in this shell
> > contaminates the bash log files causing the test to fail. This
> > happens only
> > when run under ptest-runner and not when interactively testing!
> > 
> > The changes made to fix this include:
> > 1. Get the process group id (pgid) before forking,
> > 2. Set the pgid in both the parent and child to avoid a race,
> > 3. Find, open and set permission on the child tty, and
> > 4. Allow the child to attach to controlling tty.
> > 
> > Also add '-lutil' to Makefile. This lib is from libc and provides
> > openpty.
> 
> Hmmm, I was making the code compile cleanly under clang using
>-Weverything
> when I noticed:
> 
> 1. the 'make check' tests. They still work fine.
> 2. The './ptest-runner -d tests/data -t 1' tests
> which now generate loads of error like:
>  ERROR: Unable to detach from controlling tty, Inappropriate
> ioctl 
> for device

Aha.

Does this mean you get to own:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13409

:)

> 
> so while this change fixed the bash-ptest, the ptest-runner self-test
> it did something wrong Ah, I'm calling:
> ioctl(0, TIOCNOTTY) == -1)
> repeatedly in the parent so that's what's generating the extra logs.
> Fixed locally and I'll send a patch but it's not urgent. Phew! :)
> 
> Anibal,
> 
> If you could reply to explain your plans for Richard's patches
> that would help me figure out when to send the clang warning clean-
> ups commits and what commit to base my work on.

I think he believed some of them unnecessary, they were a bit belt and
brances but I'm not sure that is a bad thing.

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [update-rc.d][PATCH V3] update-rc.d: support enable/disable options

[Richard Purdie]

On Tue, 2019-04-30 at 14:56 +0800, changqing...@windriver.com wrote:
> From: Changqing Li 
> 
> Add support of enable/disable options, refer
> https://manpages.debian.org/wheezy/sysv-rc/update-rc.d.8.en.html
> 
> With support of these options, the usr can never change an existing
> configuration even after upgrading a package. The program will only
> install links if none are present, otherwise, it will keep
> the previous configuration.
> 
> preinst in update-rc.d.bbclass will delete all the links under
> rcrunlevel.d, this behavior now conflicts with enable/disable
> options. so remove preinst from the update-rc.d.bbclass
> 
> [Yocto 12955]
> 
> Signed-off-by: Changqing Li 

Merged, thanks, sorry about the delay.

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Download git source not the latest

[Richard Purdie]

On Tue, 2019-06-11 at 20:38 +1000, JH wrote:
> Hi,
> 
> I set up SRCREV = "${AUTOREV}" in the recipe of my application, but
> too often it downloaded the old revision. How can I force the bitbake
> to download the latest git source?

What did you set PV to?

You need to have SRCPV in PV for autorev to work properly.

Regards,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] QA notification for completed autobuilder build (yocto-2.8_M1.rc2)

[richard . purdie]

On Wed, 2019-06-12 at 00:51 +, Jain, Sangeeta wrote:
> On Tue, 2019-06-11 at 03:32 +, pokybu...@debian9-ty-1.yocto.io
> > wrote:
> > > A build flagged for QA (yocto-2.8_M1.rc2) was completed on the
> > > autobuilder and is available at:
> > > 
> > > 
> > > https://autobuilder.yocto.io/pub/releases/yocto-2.8_M1.rc2
> > > 
> > 
> > Some notes for QA:
> Thanks Richard for sharing this.
> > There was a failure in this build in qemux86 oe-selftest. It looks
> > to be a race issue where qemu was shutting down. This needs a bug
> > and looking into but is a minor issue which wouldn't block the
> > milestone release or further QA.
> 
> We are analysing the failures and will file the bugs as suggested.

Just for reference I did file some of the bugs.

> > There are three timeouts in ptest, acl, bluez5 (#13366) and mdadm
> > (#13368).
> > These are also not going to block the milestone release. The
> > bluez5 issue is gcc9 related, mdadm was exposed by wider testing in
> > master. The
> > acl issue needs a bug opening and investigation as that is a
> > regression.
> 
> Looks like some disconnect here. In test result report, no timeout
> issue reported for acl ptest.

https://autobuilder.yocto.io/pub/releases/yocto-2.8_M1.rc2/testresults/testresult-report.txt

acl  | 184 | 9| 0 | 302 T

I hadn't spotted that dbus-test also has a timeout :(.

This timeout is also in the testresults file:

ERROR: Exit status is 9\nDURATION: 302\nTIMEOUT: /usr/lib/acl/ptest\n

in:

https://autobuilder.yocto.io/pub/releases/yocto-2.8_M1.rc2/testresults/qemux86-64-ptest/testresults.json

> We are referring to test results at yocto-testresults under tag "
> master/54573-g9910a3631ce953b8dd8f3d57d6e122c7fd8cb462/1"

You are right, there is no mention of this in the log at:

http://git.yoctoproject.org/cgit.cgi/yocto-testresults/tree/runtime/poky/qemux86-64/core-image-sato-sdk-ptest/ptest-acl.log?id=56b1caa6044ce30e92a1895eae48d3935562b627
or
http://git.yoctoproject.org/cgit.cgi/yocto-testresults/commit/runtime/poky/qemux86-64/core-image-sato-sdk-ptest/ptest-acl.log?id=ac623e13e3bc3a348b60fe3b884e6ae567b8230a

I suspect this is due to the information being filtered out as part of
the log processing. We probably shouldn't do that.

Looking at the individual logs in 
https://autobuilder.yocto.io/pub/releases/yocto-2.8_M1.rc2/testresults/qemux86-64-ptest/testresults.json,
 the timeout information looks to be truncated off there too.

I do however note that:

"ptestresult.sections": {
"acl": {
"duration": "302",
"exitcode": "9",
"timeout": true
},

is in 
http://git.yoctoproject.org/cgit.cgi/yocto-testresults/tree/runtime/poky/qemux86-64/core-image-sato-sdk-ptest/testresults.json?id=56b1caa6044ce30e92a1895eae48d3935562b627
so the timeout is recorded in the results.

Regards,

Richard


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto Project Status WW24'19

[Richard Purdie]

Current Dev Position: YP 2.8 M2Next Deadline: YP 2.8 Milestone 2 Cutoff
July 14th, 2019
SWAT Team Rotation: * SWAT lead is currently: Anuj
 * SWAT team rotation: Anuj -> Paul on June 14, 2019
 * SWAT team rotation: Paul -> Ross on June 21, 2019
 * https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team

Next Team Meetings: * Bug Triage meeting Thursday June 13th at 7:30am
PDT (https://zoom.us/j/454367603)
 * Monthly Project Meeting Tuesday July 2nd at 8am PDT (
https://zoom.us/j/990892712) 
 * Twitch - Next event is Tuesday 11th June at 8am PDT (
https://www.twitch.tv/yocto_project)

Key Status/Updates: * 2.8 M1 has been built and rc2 is now undergoing
QA (rc1 ran into an issue with a broken autobuilder worker).
 * Stephen continues to be unavailable, please refer any queries to
Richard
 * Mailing lists are moving to groups.io instead of our current mailman
setup. This shouldn’t impact users directly, more details will be sent
to the mailing lists before the transfer. THe Yocto Project lists will
move first, followed by OE, likely a week later.
 * We have a new “newcomer” bug category which are bugs suited to
someone new to the project. These can be seen here: 
https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs
 * We’re seeing an increasing number of intermittent failures which
affect the autobuilder builds, causing problems for merging patches and
for release builds. One cause, a long standing problem with gpg signing
testing has finally been root caused and fixed. Several others keep
appearing. There is a backlog of them in the bugzilla and we’re opening
bugs for the new ones.
 * M1 isn’t of ideal quality, there are three ptest timeouts (2.7 had
none). The ptest failure rate is however much improved. There is nobody
actively working on some of the ptest timeout issues so holding the
milestone build wouldn’t have made much difference but its a worrying
sign for the project quality.
 * M1 also has a couple of MIPS issues with the gcc9 upgrade. There
doesn’t appear to be much interest in investigating and fixing these
which raises questions about supporting the architecture within the
project.
 * There was a Yocto Project related article in LWN: 
https://lwn.net/Articles/788626/

Planned Releases for YP 2.8: * M1 Cutoff June 9th
 * M1 Release June 21st
 * M2 Cutoff 14th July
 * M2 Release 26th July
 * M3 Cutoff (Feature Freeze) 25th Aug
 * M3 Release 6th Sept
 * M4 Cutoff 30th Sept
 * 2.8 (M4) Final Release 25th Oct

Planned upcoming dot releases: * YP 2.6.3 (Thud) is in planning
 * YP 2.7.1 (Warrior) is in planning

Tracking Metrics: * WDD 2478 (last week 2507) (
https://wiki.yoctoproject.org/charts/combo.html)
 * Poky Patch Metrics  
* Total patches found: 1507 (last week 1513)
* Patches in the Pending State: 641 (43%) [last week 646 (43%)]

Key Status Links for YP:
https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.8_Statushttps://wiki.yoctoproject.org/wiki/Yocto_2.8_Schedulehttps://wiki.yoctoproject.org/wiki/Yocto_2.8_Features
The Status reports are now stored on the wiki at: 
https://wiki.yoctoproject.org/wiki/Weekly_Status
[If anyone has suggestions for other information you’d like to see on
this weekly status update, let us know!]





-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] QA notification for completed autobuilder build (yocto-2.8_M1.rc2)

[richard . purdie]

On Tue, 2019-06-11 at 03:32 +, pokybu...@debian9-ty-1.yocto.io
wrote:
> A build flagged for QA (yocto-2.8_M1.rc2) was completed on the
> autobuilder and is available at:
> 
> 
> https://autobuilder.yocto.io/pub/releases/yocto-2.8_M1.rc2
>

Some notes for QA:

There was a failure in this build in qemux86 oe-selftest. It looks to
be a race issue where qemu was shutting down. This needs a bug and
looking into but is a minor issue which wouldn't block the milestone
release or further QA.

There are three timeouts in ptest, acl, bluez5 (#13366) and mdadm
(#13368). These are also not going to block the milestone release. The
bluez5 issue is gcc9 related, mdadm was exposed by wider testing in
master. The acl issue needs a bug opening and investigation as that is
a regression.

There is a lot more testing happening under automation than in previous
builds, particularly on arm hosts/targets.

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

[richard . purdie]

On Mon, 2019-06-10 at 21:38 +, Poky Build User wrote:
> A build flagged for QA (yocto-2.8_M1.rc1) was completed on the
> autobuilder and is available at:
> 
> 
> https://autobuilder.yocto.io/pub/releases/yocto-2.8_M1.rc1
> 

I've triggered an rc2 since one of the autobuilder workers messed up
the mips builds.

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Multiple MACHINEs and DISTROs: When to use own build dir, SSTATE_DIR, DL_DIR ?

[Richard Purdie]

On Mon, 2019-06-10 at 00:11 +0200, Ulf Samuelsson wrote:
> Den 2019-05-09 kl. 11:56, skrev Burton, Ross:
> > On Thu, 9 May 2019 at 10:47, Fabian Knapp  > > wrote:
> > 
> > we have multiple MACHINEs and DISTROs and Im wondering for
> > which
> > combinations I have to setup a dedicated build dir, SSTATE_DIR
> > and
> > DL_DIR.
> > 
> > Information in the form of:
> > 
> > Each (change of) MACHINE needs its dedicated SSTATE_DIR and
> > build
> > dir but can share DL_DIR.
> > 
> > 
> > You can always share DL_DIR and SSTATE_DIR.
> > 
> > Ross
> > 
> When you have the same machine, and the recipes have variants
> which are DISTRO dependent the SSTATE_DIR can be messed up
> 
> We never digged deep enough to find the cause,
> but when we separated the SSTATE to only have one DISTRO
> in the same SSTATE, the problem disappeared.

The system is designed to work sharing DISTROs within sstate. If there
is a problem I would very much like to see the issue investigated and
fixed and can help with that.

Any such problems that have been filed in the bugzilla have been
addressed and there haven't really need any for quite a while.

Cheers,

Richard


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [patchtest-oe][PATCH] test_metadata_src_uri: new unittest detecting added patch files without modifying SRC_URI

[Richard Purdie]

On Wed, 2019-05-29 at 10:28 +0800, Changqing Li wrote:
> On 5/28/19 10:53 PM, akuster wrote:
> > On 5/27/19 6:00 PM, Changqing Li wrote:
> > > ping
> > > 
> > > On 4/29/19 2:10 PM, Changqing Li wrote:
> > > > ping
> > > > 
> > Does this mean you have a working knowledge of patchtest?
> > 
> > The one used by the project appears to be off line.  Can you help?
> > 
> > kind regards,
> > Armin
> 
> I have do some work on this,  and can try to help,  but I don't have
> 
> access right of the server,  and I also don't have the admin account
> of the patchwork.  if  someone can  provide these info,  I am glad to
> help.

Help would be much appreciated, lets take this offlist and work with
Michael and Paul and see if we can figure out how to move forward.

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto Project Status WW23'19

[Richard Purdie]

Current Dev Position: YP 2.8 M1Next Deadline: YP 2.8 Milestone 1 Cutoff
June 9th, 2019
SWAT Team Rotation: * SWAT lead is currently: Armin
 * SWAT team rotation: Armin -> Anuj on June 7, 2019
 * SWAT team rotation: Anuj -> Paul on June 14, 2019
 * https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team

Next Team Meetings: * Bug Triage meeting Thursday June 6th at 7:30am
PDT (https://zoom.us/j/454367603)
 * Monthly Project Meeting Tuesday June 4th at 8am PDT (
https://zoom.us/j/990892712) 
 * Twitch - Next event is Tuesday 11th June at 8am PDT (
https://www.twitch.tv/yocto_project)

Key Status/Updates: * 2.8 M1 is nearly upon us with just under a week
left for the remaining features/patches.
 * Stephen continues to be unavailable, please refer any queries to
Richard
 * Mailing lists are moving to groups.io instead of our current mailman
setup. This shouldn’t impact users directly, more details will be sent
to the mailing lists before the transfer. THe Yocto Project lists will
move first, followed by OE, likely a week later.
 * We have a new “newcomer” bug category which are bugs suited to
someone new to the project. These can be seen here: 
https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs
 * Uninative 2.5 was released which supports gcc 9. This should fix
issues for fedora 30 builds and allow the bringup of fedora 30 workers
in the autobuilder too.
 * ARM native builds are now working on the autobuilder as well as KVM
accelerated ARM ptest and ltp testing.
 * There are ongoing concerns about perl module dependencies. Tim and
Richard have applied bandaids to solve some ptest issues but we really
need work in this area if there are any perl experts interested.
 * Many further ptests fixes have merged, thanks to all for the
contributions.

Planned Releases for YP 2.8: * M1 Cutoff June 9th
 * M1 Release June 21st
 * M2 Cutoff 14th July
 * M2 Release 26th July
 * M3 Cutoff (Feature Freeze) 25th Aug
 * M3 Release 6th Sept
 * M4 Cutoff 30th Sept
 * 2.8 (M4) Final Release 25th Oct

Planned upcoming dot releases: * YP 2.6.3 (Thud) is in planning
 * YP 2.7.1 (Warrior) is in planning

Tracking Metrics: * WDD 2507 (last week 2524) (
https://wiki.yoctoproject.org/charts/combo.html)
 * Poky Patch Metrics  
* Total patches found: 1513 (last week 1525)
* Patches in the Pending State: 646 (43%) [last week 649 (43%)]

Key Status Links for YP:
https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.8_Statushttps://wiki.yoctoproject.org/wiki/Yocto_2.8_Schedulehttps://wiki.yoctoproject.org/wiki/Yocto_2.8_Features
The Status reports are now stored on the wiki at: 
https://wiki.yoctoproject.org/wiki/Weekly_Status
[If anyone has suggestions for other information you’d like to see on
this weekly status update, let us know!]




-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [ptest-runner][PATCH] Add SPDX-License-Identifier: GPL-2.0-or-later to source files

[richard . purdie]

On Mon, 2019-06-03 at 13:39 -0500, Aníbal Limón wrote:
> Signed-off-by: Aníbal Limón 
> ---
>  main.c | 2 ++
>  ptest_list.c   | 2 ++
>  ptest_list.h   | 2 ++
>  tests/main.c   | 2 ++
>  tests/ptest_list.c | 2 ++
>  tests/utils.c  | 2 ++
>  utils.c| 2 ++
>  utils.h| 2 ++
>  8 files changed, 16 insertions(+)
> 
> diff --git a/main.c b/main.c
> index e963efe..83cd8f2 100644
> --- a/main.c
> +++ b/main.c
> @@ -15,6 +15,8 @@
>   * along with this program; if not, write to the Free Software
>   * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
> MA  02110-1301, USA.
>   *
> + * SPDX-License-Identifier: GPL-2.0-or-later
> + *
>   * AUTHORS
>   *   Aníbal Limón 
>   */

Looks good to me, thanks!

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto 2.7: SSTATEPOSTUNPACKFUNCS_remove not working

[richard . purdie]

On Wed, 2019-05-29 at 22:37 +, Wolfgang Tolkien wrote:
> Thanks,
> 
> not sure I follow: 'SSTATEPOSTUNPACKFUNCS_remove' is not valid any
> more and previously only worked because there was a bug?

Previously the value of the expression wasn't accounted for in the
hashes which represent the state of the tasks.

The remove values need to be accounted for so we fixed that.

The reason you now see the hash mismatch is because its correctly
accounting for "remove" expressions.

> Also, what about running bitbake-dumpsig on the task sigdata and
> finding a line containing
> 
> "_remove of" (and nothing else)

Its showing its accounting for the remove.

Its empty due to the code in uninative.bbclass which sets a
vardepvalueexclude for SSTATEPOSTUNPACKFUNCS.

You're seeing the hash change because uninative is a little odd due to
the point in parsing where it gets added. Its not meant to change the
hash but the way you're altering things means it now does.

What may work is doing something like:

python uninative_changeinterp () {
return
}

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto 2.7: SSTATEPOSTUNPACKFUNCS_remove not working

[Richard Purdie]

On Wed, 2019-05-29 at 21:17 +, Wolfgang Tolkien wrote:
> Hi there,
> 
> I'm upgrading from Yocto 2.5  to 2.7. I have a recipe that (for
> legacy reasons) builds a 32bit "-native" executable. I am disabling
> uninative by setting
> 
> SSTATEPOSTUNPACKFUNCS_remove = "uninative_changeinterp"
> 
> This worked well with Yocto 2.5, but with Yocto 2.7 I'm getting 
> 
> ERROR: When reparsing virtual:native:my-32bit-
> recipe_1.0.bb.do_populate_sysroot, the basehash value changed from
>  to 
> ERROR: When reparsing virtual:native:my-32bit-
> recipe_1.0.bb.do_populate_lic, the basehash value changed from
>  to 
> ERROR: my-32bit-recipe-native-1.0-r0 do_populate_sysroot: Taskhash
> mismatch  versus  for virtual:native:my-32bit-
> recipe_1.0.bb.do_populate_sysroot
> [... lots of these...]

I suspect the reason this appeared is a bugfix in bitbake:

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

which means this removal is now correctly being accounted for in the
checksum. In your particularly case you were relying on the bug :(

Cheers,

Richard



-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto Project Status WW22'19

[Richard Purdie]

Current Dev Position: YP 2.8 M1Next Deadline: YP 2.8 Milestone 1 Cutoff
June 9th, 2019
SWAT Team Rotation: * SWAT lead is currently: Chen
 * SWAT team rotation: Chen -> Armin on May. 31, 2019
 * SWAT team rotation: Armin -> Anuj on June 7, 2019
 * https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team

Next Team Meetings: * Bug Triage meeting Thursday May 30th at 7:30am
PDT (https://zoom.us/j/454367603)
 * Monthly Project Meeting Tuesday June 4th at 8am PDT (
https://zoom.us/j/990892712) 

Key Status/Updates: * Stephen is going to be unavailable for several
weeks, please refer any queries to Richard
 * Mailing lists are moving to groups.io instead of our current mailman
setup. For various reasons the move was delayed and will take place on
3rd June. This shouldn’t impact users directly, more details will be
sent to the mailing lists in due course.
 * We have a new “newcomer” bug category which are bugs suited to
someone new to the project. These can be seen here: 
https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs
 * Adrian Bunk has done some much appreciated work in removing patches
which are no longer needed or appropriate.
 * Various upgrades and ptest dependency fixes merged. Work is still
needed on ptest dependencies, particularly on perl modules.
 * Gcc 9 is now the default, thanks to Khem for working around the
remaining bug in OE-Core.


Planned Releases for YP 2.8: * M1 Cutoff June 9th
 * M1 Release June 21st
 * M2 Cutoff 14th July
 * M2 Release 26th July
 * M3 Cutoff (Feature Freeze) 25th Aug
 * M3 Release 6th Sept
 * M4 Cutoff 30th Sept
 * 2.8 (M4) Final Release 25th Oct

Planned upcoming dot releases: * YP 2.6.3 (Thud) is in planning
 * YP 2.7.1 (Warrior) is in planning

Tracking Metrics: * WDD 2524 (last week 2559) (
https://wiki.yoctoproject.org/charts/combo.html)
 * Poky Patch Metrics  
* Total patches found: 1525 (last week 1531)
* Patches in the Pending State: 649 (43%) [last week 655 (43%)]

Key Status Links for YP:
https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.8_Statushttps://wiki.yoctoproject.org/wiki/Yocto_2.8_Schedulehttps://wiki.yoctoproject.org/wiki/Yocto_2.8_Features
The Status reports are now stored on the wiki at: 
https://wiki.yoctoproject.org/wiki/Weekly_Status
[If anyone has suggestions for other information you’d like to see on
this weekly status update, let us know!]




-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto Project Status WW21'19

[Richard Purdie]

Current Dev Position: YP 2.8 M1Next Deadline: YP 2.8 Milestone 1 Cutoff
June 9th, 2019
SWAT Team Rotation: * SWAT lead is currently: Ross
 * SWAT team rotation: Ross -> Chen on May. 24, 2019
 * SWAT team rotation: Chen -> Armin on May. 31, 2019
 * https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team

Next Team Meetings: * Bug Triage meeting Thursday May 23rd at 7:30am
PDT (https://zoom.us/j/454367603)
 * Monthly Project Meeting Tuesday June 4th at 8am PDT (
https://zoom.us/j/990892712) 

Key Status/Updates: * Stephen is going to be unavailable for several
weeks, please refer any queries to Richard
 * Mailing lists are moving to groups.io instead of our current mailman
setup on 27th May. This shouldn’t impact users directly, more details
will be sent to the mailing lists in due course.
 * We have a new “newcomer” bug category which are bugs suited to
someone new to the project. These can be seen here: 
https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs
 * Work is continuing to improve the ptest reliability with a focus now
on ensuring the dependencies are correct.


Planned Releases for YP 2.8: * M1 Cutoff June 9th
 * M1 Release June 21st
 * M2 Cutoff 14th July
 * M2 Release 26th July
 * M3 Cutoff (Feature Freeze) 25th Aug
 * M3 Release 6th Sept
 * M4 Cutoff 30th Sept
 * 2.8 (M4) Final Release 25th Oct

Planned upcoming dot releases: * YP 2.6.3 (Thud) is in planning
 * YP 2.7.1 (Warrior) is in planning

Tracking Metrics: * WDD 2559 (last week 2596) (
https://wiki.yoctoproject.org/charts/combo.html)
 * Poky Patch Metrics  
* Total patches found: 1531 (last week 1560)
* Patches in the Pending State: 654 (43%) [last week 665 (43%)]

Key Status Links for YP:
https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.8_Statushttps://wiki.yoctoproject.org/wiki/Yocto_2.8_Schedulehttps://wiki.yoctoproject.org/wiki/Yocto_2.8_Features
The Status reports are now stored on the wiki at: 
https://wiki.yoctoproject.org/wiki/Weekly_Status
[If anyone has suggestions for other information you’d like to see on
this weekly status update, let us know!]


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto Project Status WW20'19

[Richard Purdie]

Current Dev Position: YP 2.8 M1Next Deadline: YP 2.8 Milestone 1 Cutoff
June 9th, 2019
SWAT Team Rotation: * SWAT lead is currently: Amanda
 * SWAT team rotation: Amanda -> Ross on May. 17, 2019
 * SWAT team rotation: Ross -> Chen on May. 24, 2019
 * https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team

Next Team Meetings: * Bug Triage meeting Thursday May 16th at 7:30am
PDT (https://zoom.us/j/454367603)
 * Monthly Project Meeting Tuesday June 4th at 8am PDT (
https://zoom.us/j/990892712) 

Key Status/Updates: * Stephen is going to be unavailable for several
weeks, please refer any queries to Richard
 * The final 2.8 planning meeting was held. The google doc summarising
the discussions so far: 
https://docs.google.com/document/d/1CNEKA4d0eT6-e0hnS2pwi7xdZ5_t6smpZO2HbaJGXbU/
If people are planning to work on specific things in 2.8 please let us
know so we can incorporate this into our plans. If you’re interested in
working on anything in the document, please also let us know or talk
with us in one of the planning meetings.Most items planned to be worked
upon should now be in the bugzilla with appropriately detailed entries
there.A summary of the 2.8 planning risk items was included in an email
to the yocto-ab list:
https://lists.yoctoproject.org/pipermail/yocto-ab/2019-May/002334.html
* The project is planning to adopt SPDX license headers in its source code 
where practical, OE-Core now has the markup on its scripts too.
 * Mailing lists are moving to groups.io instead of our current mailman
setup on 27th May. This shouldn’t impact users directly, more details
will be sent to the mailing lists in due course.
 * We have a new “newcomer” bug category which are bugs suited to
someone new to the project. These can be seen here: 
https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs
 * We’re about ready to switch over to gcc 9 by default with one more
issue needing to be resolved on mips.
 * We’re likely going to change the tuning of qemux86 to something more
modern
 * We’re likely to drop openssl 1.0 and irda from OE-Core imminently


Planned Releases for YP 2.8: * M1 Cutoff June 9th
 * M1 Release June 21st
 * M2 Cutoff 14th July
 * M2 Release 26th July
 * M3 Cutoff (Feature Freeze) 25th Aug
 * M3 Release 6th Sept
 * M4 Cutoff 30th Sept
 * 2.8 (M4) Final Release 25th Oct

Planned upcoming dot releases: * YP 2.6.3 (Thud) is in planning
 * YP 2.7.1 (Warrior) is in planning

Tracking Metrics: * WDD 2596 (last week 2602) (
https://wiki.yoctoproject.org/charts/combo.html)
 * Poky Patch Metrics  
* Total patches found: 1560 (last week 1558)
* Patches in the Pending State: 665 (43%) [last week 655 (42%)]

Key Status Links for YP:
https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.8_Statushttps://wiki.yoctoproject.org/wiki/Yocto_2.8_Schedulehttps://wiki.yoctoproject.org/wiki/Yocto_2.8_Features
The Status reports are now stored on the wiki at: 
https://wiki.yoctoproject.org/wiki/Weekly_Status
[If anyone has suggestions for other information you’d like to see on
this weekly status update, let us know!]


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [Yocto-bsp] Error of " fs.inotify.max_user_watches " while using bitbake [ Yocto-2.6.1 + Qemux86]

[Richard Purdie]

On Mon, 2019-05-13 at 15:38 +0530, AshishKumar Mishra wrote:
> Can team members please let me know the solution & what is causing
> the below mentioned error ?
> ( I am having around 128GB of disk space still left , hence don't
> think that space is the issue here )
> 
> ~/Documents/linux-foundation-projects/yocto/poky/build (slef-bsp) : bitbake 
> -vn virtual/kernel
> ERROR: No space left on device or exceeds fs.inotify.max_user_watches?
> ERROR: To check max_user_watches: sysctl -n fs.inotify.max_user_watches.
> ERROR: To modify max_user_watches: sysctl -n -w 
> fs.inotify.max_user_watches=.
> ERROR: Root privilege is required to modify max_user_watches.
> ERROR: Command execution failed: Traceback (most recent call last):

Did you try what it says above and check the max_user_watches value?

Also, did you check you had enough free inodes on the filesystem?

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [Yocto-bsp] Error of " fs.inotify.max_user_watches " while using bitbake [ Yocto-2.6.1 + Qemux86]

[Richard Purdie]

On Mon, 2019-05-13 at 15:38 +0530, AshishKumar Mishra wrote:
> Can team members please let me know the solution & what is causing
> the below mentioned error ?
> ( I am having around 128GB of disk space still left , hence don't
> think that space is the issue here )
> 
> ~/Documents/linux-foundation-projects/yocto/poky/build (slef-bsp) : bitbake 
> -vn virtual/kernel
> ERROR: No space left on device or exceeds fs.inotify.max_user_watches?
> ERROR: To check max_user_watches: sysctl -n fs.inotify.max_user_watches.
> ERROR: To modify max_user_watches: sysctl -n -w 
> fs.inotify.max_user_watches=.
> ERROR: Root privilege is required to modify max_user_watches.
> ERROR: Command execution failed: Traceback (most recent call last):

Did you try what it says above and check the max_user_watches value?

Also, did you check you had enough free inodes on the filesystem?

Cheers,

Richard

-- 
___
yocto-bsp mailing list
yocto-bsp@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto-bsp

Re: [yocto] [OE-core] Yocto Project Status WW19'19

[richard . purdie]

On Tue, 2019-05-07 at 08:00 -0700, akuster wrote:
> > Key Status Links for YP:
> > https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.7_Status
> > https://wiki.yoctoproject.org/wiki/Yocto_2.7_Schedule
> > https://wiki.yoctoproject.org/wiki/Yocto_2.7_Features
>  
> Don't we need 2.8 now ? 

We do, this was on the agenda for the 2.8 planning meeting. We need
dates for the milestones, I'm proposing we use:

M1 Apr. 29, 2019 to June 21, 2019
M1 RC1 June 9th
M2 June 10, 2019 to July 26, 2019 
M2 RC1 14th July
M3 July 15, 2019 to Sept. 6, 2019 
M3 RC1 25th Aug
M4 Aug. 26, 2019 to Oct. 25, 2019
M4 RC1: 30th Sept
M4 RC2: 7th Oct
M4 RC3: 14th Oct 

I updated this into:

https://wiki.yoctoproject.org/wiki/Yocto_2.8_Schedule

If anyone foresees any problems with this or has any other feedback on
the dates please let us know!

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [OE-core] Yocto Project Status WW19'19

[Richard Purdie]

Current Dev Position: YP 2.8 M1
Next Deadline: YP 2.8 Milestone 1 Target May ??, 2019

SWAT Team Rotation:
 * SWAT lead is currently: Anuj
 * SWAT team rotation: Anuj -> Ross on May. 10, 2019
 * SWAT team rotation: Ross -> Amanda on May. 17, 2019
 * https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team

Next Team Meetings:
 * YP 2.8 Planning meeting Tuesday May 7th at 8am PDT (
https://zoom.us/j/990892712) 
 * Bug Triage meeting Thursday May 9th at 7:30am PDT (
https://zoom.us/j/454367603)

Key Status/Updates:
 * Stephen is going to be unavailable for several weeks, please refer
any queries to Richard
 * YP 2.7 was released
 * The 2.8 planning discussions are starting and there is a google doc
summarising the discussions so far: 
https://docs.google.com/document/d/1CNEKA4d0eT6-e0hnS2pwi7xdZ5_t6smpZO2HbaJGXbU/
If people are planning to work on specific things in 2.8 please let us
know so we can incorporate this into our plans. If you’re interested in
working on anything in the document, please also let us know or talk
with us in one of the planning meetings.
 * At this point we believe we’ve made our final release for the sumo
(2.5) series
 * The project is planning to adopt SPDX license headers in its source
code where practical, bitbake has had these merged as a first step.
 * We have a new “newcomer” bug category which are bugs suited to
someone new to the project. These can be seen here: 
https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs

Planned Releases for YP 2.8:
 * TBA

Planned upcoming dot releases:
 * YP 2.6.3 (Thud) is in planning
 * YP 2.7.1 (Warrior) is in planning

Tracking Metrics:
 * WDD 2602 (last week 2593) (
https://wiki.yoctoproject.org/charts/combo.html)
 * Poky Patch Metrics  
* Total patches found: 1558 (last week 1565)
* Patches in the Pending State: 655 (42%) [last week 655 (42%)]

Key Status Links for YP:
https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.7_Status
https://wiki.yoctoproject.org/wiki/Yocto_2.7_Schedule
https://wiki.yoctoproject.org/wiki/Yocto_2.7_Features

The Status reports are now stored on the wiki at: 
https://wiki.yoctoproject.org/wiki/Weekly_Status

[If anyone has suggestions for other information you’d like to see on
this weekly status update, let us know!]
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Newcomer bugs

[Richard Purdie]

Apologies for cross posting but I wanted a wider audience to see this.

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, if there are people interested in helping mentor newcomers and
help develop newcomer suited bugs, please talk to me about it as we
could definitely do with help there. 

Other roles where we could do with particular help are toaster
development, website improvements/maintenance, QA framework
documentation/development + testcases and our CI testing along with the
usual other things but these are not really suited to newcomers.

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Could not find glib.h

[Richard Purdie]

On Wed, 2019-05-01 at 10:43 +1000, JH wrote:
> Hi,
> 
> I added glib-2.0 to DEPENDS but it still could find the glib.h, what
> I
> could be missing here?
> 
> fatal error: glib.h: No such file or directory
> >  #include 
> >   ^~~~
> > compilation terminated.

You probably need to use pkg-config to find out which CFLAGS to use for
glib-2.0...

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [OE-core] Yocto Project Status WW18'19

[Richard Purdie]

Current Dev Position: YP 2.7 M4 (2.7 rc2 release being discussed)
Next Deadline: YP 2.7 Release Target April 26, 2019

SWAT Team Rotation:
SWAT lead is currently: PaulSWAT team rotation: Paul -> Anuj on May. 3,
2019SWAT team rotation: Anuj -> Ross on May. 10, 2019
https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team
Next Team Meetings:
Bug Triage meeting Thursday May 2nd at 7:30am PDT (
https://zoom.us/j/454367603)YP 2.8 Planning meeting Tuesday May 7th at
8am PDT (https://zoom.us/j/990892712) 
Key Status/Updates:
Stephen is going to be unavailable for several weeks, please refer any
queries to RichardYP 2.5.3 was released.YP 2.7 is out of QA but pending
answers to some questions on the QA report and the final pieces of
release process.Huge kudos this week go to Armin for work on test
automation of some of the manual testsWe’ve merged ltp test automation
which is now being run automatically on the autobuilder on a-full
builds.Master continues to take patches, somewhat slowed by host
specific build issues with vte-nativeWDD, our bug tracking metric is
high and there are few people helping with bugs.The 2.8 planning
discussions are starting and there is a google doc summarising the
discussions so far: 
https://docs.google.com/document/d/1CNEKA4d0eT6-e0hnS2pwi7xdZ5_t6smpZO2HbaJGXbU/If
people are planning to work on specific things in 2.8 please let us
know so we can incorporate this into our plans. If you’re interested in
working on anything in the document, please also let us know or talk
with us in one of the planning meetings.
We have a new “newcomer” bug category which are bugs suited to someone
new to the project. These can be seen here: 
https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs
Planned Releases for YP 2.7:
YP 2.7 M4 Cutoff was Apr. 1, 2019YP 2.7 M4 Release Target is Apr. 26,
2019
Planned upcoming dot releases:
YP 2.6.3 (Thud) is in planning
Tracking Metrics:
WDD 2593 (last week 2598) (
https://wiki.yoctoproject.org/charts/combo.html)Poky Patch Metrics
 Total patches found: 1565 (last week 1553)Patches in the Pending
State: 655 (42%) [last week 654 (42%)]
Key Status Links for YP:
https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.7_Status
https://wiki.yoctoproject.org/wiki/Yocto_2.7_Schedule
https://wiki.yoctoproject.org/wiki/Yocto_2.7_Features

The Status reports are now stored on the wiki at: 
https://wiki.yoctoproject.org/wiki/Weekly_Status

[If anyone has suggestions for other information you’d like to see on
this weekly status update, let us know!]

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] QA cycle report for 2.7 RC2

[richard . purdie]

On Fri, 2019-04-26 at 06:27 +, Jain, Sangeeta wrote:
>  
> QA cycle report for 2.7 RC2:
>  
> No high milestone defects. 
> 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]
> No new defects are found in this cycle.
> No existing issues observed in this release
> No ptests are failing in this release which were passing in previous
> release. No timeout issues.
>  
> QA Hint: One failure was observed on public AB:
>  
> testseries | result_id : qemuppc | oeselftest_centos-
> 7_qemuppc_20190414221329
> runqemu.QemuTest.test_qemu_can_shutdown
>  
> No bug filed for this issue, as it appears to be an intermittent
> failure and worked on rc1 test run.

Thanks for the testing!

FWIW it should have and does have a bug:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13309
also, 
https://bugzilla.yoctoproject.org/show_bug.cgi?id=12991
is still present in the release according to that bug.

I've asked the TSC for a go/nogo decision on the release.

Cheers,

Richard




-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] ASSUME_PROVIDED, cmake-native and why cmake is subsequently not found?

[Richard Purdie]

On Thu, 2019-04-25 at 08:32 -0400, Robert P. J. Day wrote:
> On Thu, 25 Apr 2019, Bach, Pascal wrote:
> 
> > >   currently trying to build a "core-image-minimal" for a zedboard
> > > on my
> > > wholly unsupported fedora 30 (branched) system, so i'm well aware
> > > there
> > > will almost certainly be breakage as i try to resolve version
> > > numbers and so
> > > on, but working off the "thud" branch, the first issue i had was
> > > trying to
> > > configure cmake-native -- the error message is exactly what you
> > > can read
> > > someone asking about here:
> > > 
> > > https://stackoverflow.com/questions/52663287/glibcxx-3-4-26-not-found
> > > 
> > > /home/rpjday/oe/builds/zedboard/tmp/work/x86_64-linux/cmake-
> > > native/3.12.2-r0/build/Bootstrap.cmk/cmake:
> > > /home/rpjday/oe/builds/zedboard/tmp/sysroots-uninative/x86_64-
> > > linux/usr/lib/libstdc++.so.6:
> > > version `GLIBCXX_3.4.26' not found (required by
> > > /home/rpjday/oe/builds/zedboard/tmp/work/x86_64-linux/cmake-
> > > native/3.12.2-r0/build/Bootstrap.cmk/cmake)
> > > > -
> > > > Error when bootstrapping CMake:
> > > > Problem while running initial CMake
> > > > -
> > > 
> > >   i'm unsure how to resolve that easily, but my first reaction
> > > was, "if i already have cmake installed on the host, why not just
> > > take advantage of ASSUME_PROVIDED"? i recall from some time back
> > > asking why more host utils were not, by default, included in
> > > ASSUME_PROVIDED, and the answer (quite reasonably) was that one
> > > wants to have as few variables as possible for reliably
> > > replicated
> > > builds.
> > > 
> > >   fair enough, but in my case, until i figure out how to fix
> > > that,
> > > i thought, why not just:
> > > 
> > >   ASSUME_PROVIDED += "cmake-native"
> > > 
> > > so i did, and that got me past the cmake-native build issue,
> > > until
> > > i hit this trying to build libsolv-native:
> > > 
> > > DEBUG: Executing shell function do_configure
> > > /home/rpjday/oe/builds/zedboard/tmp/work/x86_64-linux/libsolv-
> > > native/0.6.35-r0/temp/run.do_configure.16705:
> > > line 130: cmake: command not found
> > > 
> > >   hang on ... why would a subsequent recipe not be able to locate
> > > /usr/bin/cmake on my host after i explicitly identified
> > > cmake-native as assumed to be provided? is there something about
> > > the libsolv-native recipe that does not take that possibility
> > > into
> > > account? i'm just about to check, but if someone has an
> > > explanation for that, i'm all ears.
> > 
> > There is an issue that CMake is not able to find binaries in
> > hosttools. It might be the case that this is the issue you are
> > seeing.
> > 
> > I submitted a patch for that but I'm not sure it Ever made it into
> > master or a release. I need to follow up on this, the patch is
> > here:
> > https://patchwork.openembedded.org/series/14429/#
> 
>   that *sort of* sounds like what is happening, but to be pedantic,
> it's not that cmake can't find binaries in hosttools, it's that
> *other* packages can't locate cmake on the host even after setting
> 
>   ASSUME_PROVIDED += "cmake-native"

Setting that "fixes" dependencies but it doesn't make cmake visible in
our HOSTTOOLS.

> i am assuming that whatever search path is used for "native" tools is
> extended by the use of ASSUME_PROVIDED -- is that what your patch is
> addressing?

How would it know in general terms which binaries a given X would
provide?

>  in any event, i've now run into a couple other packages
> with the same issue -- "cmake: command not found" -- libcomps-native
> and librepo-native, so i'll just ASSUME_PROVIDED them too for the
> moment, as they're both installed on my host.

This is a bad idea and you're on a path to madness ;-)

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] ASSUME_PROVIDED, cmake-native and why cmake is subsequently not found?

[Richard Purdie]

On Thu, 2019-04-25 at 08:05 -0400, Robert P. J. Day wrote:
>   (warning: i've been away from YP for well over a year and am now
> studiously trying to catch up, so i have some work to do.)
> 
>   currently trying to build a "core-image-minimal" for a zedboard on
> my wholly unsupported fedora 30 (branched) system, so i'm well aware
> there will almost certainly be breakage as i try to resolve version
> numbers and so on, but working off the "thud" branch, the first issue
> i had was trying to configure cmake-native -- the error message is
> exactly what you can read someone asking about here:
> 
> https://stackoverflow.com/questions/52663287/glibcxx-3-4-26-not-found
> 
> /home/rpjday/oe/builds/zedboard/tmp/work/x86_64-linux/cmake-
> native/3.12.2-r0/build/Bootstrap.cmk/cmake:
> /home/rpjday/oe/builds/zedboard/tmp/sysroots-uninative/x86_64-
> linux/usr/lib/libstdc++.so.6:
> version `GLIBCXX_3.4.26' not found (required by
> /home/rpjday/oe/builds/zedboard/tmp/work/x86_64-linux/cmake-
> native/3.12.2-r0/build/Bootstrap.cmk/cmake)
> > -
> > Error when bootstrapping CMake:
> > Problem while running initial CMake
> > -

This probably means that your system c library is newer than the one in
uninative and things aren't working because of that. Either try:

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

or turning off uninative.

>   i'm unsure how to resolve that easily, but my first reaction was,
> "if i already have cmake installed on the host, why not just take
> advantage of ASSUME_PROVIDED"? i recall from some time back asking
> why
> more host utils were not, by default, included in ASSUME_PROVIDED,
> and
> the answer (quite reasonably) was that one wants to have as few
> variables as possible for reliably replicated builds.

That is one reason, there is a second. We patch some of the utilities
to do what we need. We rely on our patches being present.

>   fair enough, but in my case, until i figure out how to fix that, i
> thought, why not just:
> 
>   ASSUME_PROVIDED += "cmake-native"

This is a bad idea as we patch cmake iirc.

> 
> so i did, and that got me past the cmake-native build issue, until i
> hit this trying to build libsolv-native:
> 
> DEBUG: Executing shell function do_configure
> /home/rpjday/oe/builds/zedboard/tmp/work/x86_64-linux/libsolv-
> native/0.6.35-r0/temp/run.do_configure.16705:
> line 130: cmake: command not found
> 
>   hang on ... why would a subsequent recipe not be able to locate
> /usr/bin/cmake on my host after i explicitly identified cmake-native
> as assumed to be provided? is there something about the libsolv-
> native
> recipe that does not take that possibility into account? i'm just
> about to check, but if someone has an explanation for that, i'm
> all ears.

You would also have to do:

HOSTTOOLS += "cmake"

to allow cmake to be visible from the host system. Its a host
contamination protection mechanisn that has been there since pyro.

>   finally, regarding ASSUME_PROVIDED, given that i'm already living
> life dangerously with an unsupported distro, is there any harm in
> just loading up on ASSUME_PROVIDED packages, as long as they work? in
> many cases, i can see that the version that would be built by YP is
> close to, if not identical to, my host version. so other than risking
> breakage down the line as versions change, as long as the host
> packages work, is there any harm in just taking advantage of them?

I think it will be a world of pain ;-)

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] QA cycle report for 2.5.3 RC3

[richard . purdie]

On Wed, 2019-04-24 at 06:28 +, Jain, Sangeeta wrote:
> That looks great to me. 
> As a further improvement for sharing of test results, I am working to
> create a wiki page for consolidated 
> test results. For 2.5.3, it can be viewed at:
> https://wiki.yoctoproject.org/wiki/WW16_-_2019-04-18_-_Full_Test_Cycle_2.5.3_RC3

The reasons for a wiki page are historical, mainly from the testopia
plugin to the wiki. I think going forward we should focus on having a
test report included in the release artefacts and that we shouldn't
need the wiki page.

> After you have added more results on AB, I will change some existing
> links on this web page with the new ones.
> 
> Another thought I have is that since for any release, all data will
> be removed from public AB after few days of release,
> Should I include here a  link to "yocto-testresults" git repo? It
> will make this wiki page more useful for reference in future as well.

Release data is moved from the autobuilder to the main public release
location, e.g.:

http://downloads.yoctoproject.org/releases/yocto/yocto-2.6.2/testresults/

So if we put a test report as a release artefact, it moves with the
rest of the release artefacts and we're all good!

This avoids the need for any links as all the data is in one place.

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [OE-core] Yocto Project Status WW17'19

[Richard Purdie]

Current Dev Position: YP 2.7 M4 (2.7 rc2 is in QA)
Next Deadline: YP 2.7 Release Target April 26, 2019

SWAT Team Rotation:
SWAT lead is currently: ArminSWAT team rotation: Armin -> Anuj on Apr.
26, 2019SWAT team rotation: Armin -> Paul on May. 3, 2019
https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team
Next Team Meetings:
Bug Triage meeting Thursday April 25th at 7:30am PDT (
https://zoom.us/j/454367603)YP 2.8 Planning meeting Tuesday May 7th at
8am PDT (https://zoom.us/j/990892712) 
Key Status/Updates:
Stephen is going to be unavailable for several weeks, please refer any
queries to RichardYP 2.6.2 was released!YP 2.5.3 is likely to be
released imminentlyYP 2.7 rc2 (warrior) is currently going through
QA.The final two members of the new YP TSC were elected, Denys and
Armin. The TSC will therefore now start to discuss how its going to
establish itself and operate.Huge thanks to Joshua Watt for diving in
and helping file some ptest bugs and helping sort some missing tweaks
with resulttool, it was just appreciatedPatches are continuing to flow
into master, slightly impeded by holidays/vacation in some parts of the
world.WDD, our bug tracking metric is sharply rising as there are few
people helping with bugs.The 2.8 planning discussions are starting and
there is a google doc summarising the discussions so far: 
https://docs.google.com/document/d/1CNEKA4d0eT6-e0hnS2pwi7xdZ5_t6smpZO2HbaJGXbU/If
people are planning to work on specific things in 2.8 please let us
know so we can incorporate this into our plans. If you’re interested in
working on anything in the document, please also let us know or talk
with us in one of the planning meetings.

Planned Releases for YP 2.7:
YP 2.7 M4 Cutoff was Apr. 1, 2019YP 2.7 M4 Release Target is Apr. 26,
2019
Planned upcoming dot releases:
YP 2.5.3 (Sumo) is due for release.
Tracking Metrics:
WDD 2598 (last week 2523) (
https://wiki.yoctoproject.org/charts/combo.html)Poky Patch Metrics
 Total patches found: 1553 (last week 1553)Patches in the Pending
State: 654 (42%) [last week 654 (42%)]
Key Status Links for YP:
https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.7_Status
https://wiki.yoctoproject.org/wiki/Yocto_2.7_Schedule
https://wiki.yoctoproject.org/wiki/Yocto_2.7_Features

The Status reports are now stored on the wiki at: 
https://wiki.yoctoproject.org/wiki/Weekly_Status

[If anyone has suggestions for other information you’d like to see on
this weekly status update, let us know!]
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] QA cycle report for 2.5.3 RC3

[richard . purdie]

On Thu, 2019-04-18 at 04:58 +, Jain, Sangeeta wrote:
>  
> QA cycle report for 2.5.3 RC3:
>  
> No high milestone defects. 
> Test results are available at following location:
> ·For results of all automated tests, 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]
> ·For ptest results, please refer to results at public AB [5]
> ·For ptest report, refer to attachment [6]
> No new defects are found in this cycle.
> Number of existing issues observed in this release is 2- toaster [7]
> and Build-appliance [8]
> For ptest, regression data is not available for this release. No
> timeout issues.
> Test result report on Public AB shows no failures.

I've been discussing with Tracy and Vineela how to best handle the test
results for the release for 2.5.3. In the end I:

a) Copied in the ptest results to the right place. This will happen
automagically in all future builds:

https://autobuilder.yocto.io/pub/releases/yocto-2.5.3/testresults/qemux86-64-ptest/

b) Copied in the intel test results to their own directory:

https://autobuilder.yocto.io/pub/releases/yocto-2.5.3/testresults-intel/

c) Manually generated an updated test report for the combined results
with the commands:

$ cd /srv/autobuilder/autobuilder.yoctoproject.org/pub/releases/yocto-
2.5.3
$resulttool report . > testreport.txt

d) Added a header to the report which consisted of the report from QA
with details of the bugs etc.

This means we have a top level testreport file which contains all the
test information about the release.

I'd like to make this the standard procedure for release. The release
notes and announcement can refer to the test report included with the
release and the test results as its there all together.

Ultimately I'd like to improve the formatting of the report (separate
out ptest regressions from the other regressions, maybe html, maybe
graphs, better regression information) but that is something for the
future.

Does that work for everyone?

Cheers,

Richard


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] QA cycle report for 2.5.3 RC3

[richard . purdie]

On Thu, 2019-04-18 at 04:58 +, Jain, Sangeeta wrote:
>  
> QA cycle report for 2.5.3 RC3:
>  
> No high milestone defects. 
> Test results are available at following location:
> ·For results of all automated tests, 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]
> ·For ptest results, please refer to results at public AB [5]
> ·For ptest report, refer to attachment [6]
> No new defects are found in this cycle.
> Number of existing issues observed in this release is 2- toaster [7]
> and Build-appliance [8]
> For ptest, regression data is not available for this release. No
> timeout issues.
> Test result report on Public AB shows no failures.

I've been discussing with Tracy and Vineela how to best handle the test
results for the release for 2.5.3. In the end I:

a) Copied in the ptest results to the right place. This will happen
automagically in all future builds:

https://autobuilder.yocto.io/pub/releases/yocto-2.5.3/testresults/qemux86-64-ptest/

b) Copied in the intel test results to their own directory:

https://autobuilder.yocto.io/pub/releases/yocto-2.5.3/testresults-intel/

c) Manually generated an updated test report for the combined results
with the commands:

$ cd /srv/autobuilder/autobuilder.yoctoproject.org/pub/releases/yocto-2.5.3
$resulttool report . > testreport.txt

d) Added a header to the report which consisted of the report from QA
with details of the bugs etc.

This means we have a top level testreport file which contains all the
test information about the release.

I'd like to make this the standard procedure for release. The release
notes and announcement can refer to the test report included with the
release and the test results as its there all together.

Ultimately I'd like to improve the formatting of the report (separate
out ptest regressions from the other regressions, maybe html, maybe
graphs, better regression information) but that is something for the
future.

Does that work for everyone?

Cheers,

Richard


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [OE-core] Yocto Project Status WW15'19

[Richard Purdie]

Current Dev Position: YP 2.7 M4 (2.7 rc2 is in QA)
Next Deadline: YP 2.7 Release Target April 26, 2019

SWAT Team Rotation:
SWAT lead is currently: Chen SWAT team rotation: Chen -> Armin on Apr.
19, 2019SWAT team rotation: Armin -> Anuj on Apr. 26, 2019
https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team
Next Team Meetings:
YP 2.8 Planning meeting Tuesday April 16nd at 8am PDT (
https://zoom.us/j/990892712) Bug Triage meeting Thursday April 18th at
7:30am PDT (https://zoom.us/j/454367603)
Key Status/Updates:
Stephen is unavailable at the moment, please refer any queries to
RichardYP 2.6.2 was rebuilt as rc4 to include the boost upgrade revert
and is due to be released today. The YP 2.6.2 rc3/4 report is
summarized at 
https://lists.yoctoproject.org/pipermail/yocto/2019-April/044827.html
and the results are at https://autobuilder.yocto.io/pub/releases/yocto
-2.6.2.rc4/testresults/.YP 2.5.3 is currently going through the QA
process.We’re sad to announce that we will be removing eclipse plugin
builds from the autobuilder and will not be including the plugin in any
future project releases. This is due to a lack of anyone able to help
work on the plugin development, bug fixing or release.The key fixes
mentioned in last week’s status have been merged into 2.7.A key bug in
pseudo was identified which may be the root cause of the long standing
glibc-locale uid “host contamination” issue. Many thanks to Peter and
Otavio for the help in debugging that. A separate fix should also
ensure pseudo works with newer distro coreutils and glibc versions.YP
2.7 rc2 (warrior) was built successfully and is currently going through
the QA process after 2.5.3 is done.The ptest results in 2.7 are much
more stable than ever before with results being consistent from build
to build. At the start of 2.8 we can make some further improvements so
we take advantage of this and build upon it to reduce regressions in
the system.In an effort to keep the patch queue under control, patches
are merging to master.The list of issues from last week of worrying
things we lack resources to improve upon remains:Intermittent
autobuilder failures (fork running out of resources - which resources?,
oe-selftest intermittent issues, gpg signing resource problems,
occasional PR server failure and more)Build-appliance testing issues
(show up on each QA report across multiple releases)40% valgrind ptest
failuresKnown bitbake memory resident bugsOther ptest failuresThe 2.8
planning discussions are starting and there is a google doc summarising
the discussions so far: 
https://docs.google.com/document/d/1CNEKA4d0eT6-e0hnS2pwi7xdZ5_t6smpZO2HbaJGXbU/If
people are planning to work on specific things in 2.8 please let us
know so we can incorporate this into our plans. If you’re interested in
working on anything in the document, please also let us know or talk
with us in one of the planning meetings.

Planned Releases for YP 2.7:
YP 2.7 M4 Cutoff was Apr. 1, 2019YP 2.7 M4 Release Target is Apr. 26,
2019
Planned upcoming dot releases:
YP 2.5.3 (Sumo) is in QA.
Tracking Metrics:
WDD 2523 (last week 2471) (
https://wiki.yoctoproject.org/charts/combo.html)Poky Patch Metrics
 Total patches found: 1553 (last week 1553)Patches in the Pending
State: 654 (42%) [last week 655 (42%)]
Key Status Links for YP:
https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.7_Status
https://wiki.yoctoproject.org/wiki/Yocto_2.7_Schedule
https://wiki.yoctoproject.org/wiki/Yocto_2.7_Features

The Status reports are now stored on the wiki at: 
https://wiki.yoctoproject.org/wiki/Weekly_Status

[If anyone has suggestions for other information you’d like to see on
this weekly status update, let us know!]


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Dependencies on other file system types for custom file system type

[Richard Purdie]

On Mon, 2019-04-15 at 21:43 +0700, Eric Grunt wrote:
> > Notice how the function names for squashfs are:
> > 
> > do_image_squashfs_xz
> > 
> > not
> > 
> > do_image_squashfs-xz
> > 
> > This is because shell functions/variables can't have "-" in their
> > name.
> > You need to change to us IMAGE_CMD_squashfs_xz_ubi.
> 
> I tried to basically change all "-" in the fs and variable names into
> "_",
> but this didn't change the behaviour.
> What I do not understand:
> The filesystem type squashfs-xz (included in poky) uses "-",
> among others also for the IMAGE_CMD name ("IMAGE_CMD_squashfs-xz").
> Only the dependencies to squashfs tools are using "_":
> do_image_squashfs_xz[depends] += "squashfs-tools-
> native:do_populate_sysroot"
> 
> In the case of squashfs_xz_ubi the IMAGE_TYPEDEP_ dependency
> to sqashfs-xz is ignored.
> (experimentally trying to change that dependency to squashfs
> (a name without "-")  does not help)

I think there is some translation code somewhere which probably
confuses things more as some bits have - and some have _. Does the
squashfs_xz image type actually work? 

Cheers,

Richard


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] QA notification for completed autobuilder build (yocto-2.7.rc2)

[richard . purdie]

On Sun, 2019-04-14 at 23:48 +, pokybuild@centos7-ty-1.localdomain
wrote:
> A build flagged for QA (yocto-2.7.rc2) was completed on the
> autobuilder and is available at:
> 
> 
> https://autobuilder.yocto.io/pub/releases/yocto-2.7.rc2
> 
> 
> Build hash information: 
> 
> bitbake: cb185efe9e88cfb12b7a3fd08f3086ca0b69c8e2
> meta-gplv2: 106ba6d2a4d08a276205c305f8485d701fe8a8f3
> meta-intel: cd2c3bfca97655999cbde645b73be712675dba92
> meta-mingw: 10695afe8cd406844e0d0dd868c11677e07557d4
> oecore: f571b188177788d8ed0a7f3efe3569f153b1b0d3
> poky: 0e392026ffefee098a890c39bc3ca1f697bacb52

Note for QA:

I was able to add the automated oe-selftests for the different qemu
machines in this run as we discussed. This should reduce the amount of
tests QA need to run. There was one failure:

testseries | result_id : qemuppc | oeselftest_centos-7_qemuppc_20190414221329
runqemu.QemuTest.test_qemu_can_shutdown

I believe this worked on the rc1 test run so it appears to be an
intermittent failure which I'd not block release on.

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] QA notification for completed autobuilder build (yocto-2.6.2.rc4)

[richard . purdie]

On Mon, 2019-04-15 at 08:27 +, pokybu...@fedora29-ty-1.yocto.io
wrote:
> A build flagged for QA (yocto-2.6.2.rc4) was completed on the
> autobuilder and is available at:
> 
> 
> https://autobuilder.yocto.io/pub/releases/yocto-2.6.2.rc4
> 
> 
> Build hash information: 
> 
> bitbake: 7c1eb51d1e8a4c5f39bf9dddf05fb0b3598da72b
> meta-gplv2: aabc30f3bd03f97326fb8596910b94639fea7575
> meta-intel: 27dadcfc7bc0de70328b02fecb841608389d22fc
> meta-mingw: 6556cde16fbdf42c7edae89bb186e5ae4982eff5
> oecore: fddd3ca8490adaceab6491632cf249c2320e4fda
> poky: e7f0177ef3b6e06b8bc1722fca0241fef08a1530

As discussed in the QA report thread, this is a respin of 2.6.2, one
commit different to avoid the boost upgrade. The intent is to release
this as 2.6.2 rather than rc3 if there is general agreement.

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Dependencies on other file system types for custom file system type

[richard . purdie]

On Fri, 2019-04-12 at 20:50 +0700, Eric Grunt wrote:
> > The dependency code is only triggered if the image type is in
> > IMAGE_FSTYPES. Did you add it there?
> 
> Yes, in the distro conf file.
> Guess, otherwise it wouldn't be built at all (since it isn't
> dependency of another fs)

Notice how the function names for squashfs are:

do_image_squashfs_xz

not

do_image_squashfs-xz

This is because shell functions/variables can't have "-" in their name.
You need to change to us IMAGE_CMD_squashfs_xz_ubi.

Cheers,

Richard



-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Dependencies on other file system types for custom file system type

[Richard Purdie]

On Fri, 2019-04-12 at 20:19 +0700, Eric Grunt wrote:
> Dependencies on other file system types for custom file system type
> 
> I'd like to add a custom fs type - a squashfs-xz on an ubi (instead
> of ubifs).
> For this purpose I created a new class, inherited image_types and
> added
> a dependency on squashfs-xz and also on squashfs-tools-native and
> mtd-utils-native:
> 
> inherit image_types
> 
> IMAGE_TYPEDEP_squashfs-xz-ubi = "squashfs-xz"
> 
> do_image_squashfs-xz-ubi[depends] += "mtd-utils-
> native:do_populate_sysroot"
> do_image_squashfs-xz-ubi[depends] += "squashfs-tools-
> native:do_populate_sysroot"
> 
> (full class file is attached to this mail)
> 
> But the dependency handling is not working corrently in my solution:

The dependency code is only triggered if the image type is in
IMAGE_FSTYPES. Did you add it there?

Cheers,

Richard



-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] QA cycle report for 2.6.2 RC3

[richard . purdie]

On Wed, 2019-04-10 at 02:38 +, Jain, Sangeeta wrote:
>  
> QA cycle report for 2.6.2 RC3:
>  
> No high milestone defects. 
> Test results are available at following location:
> ·For results of all automated tests, 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]
> ·For ptest results, please refer to results at public AB [5]
> ·For ptest report, refer to attachment [6]
> 1 new defects are found in this cycle, Beaglebone [7].
> QA hint:  Similar issue for sysemtap failure (bug 13153) was found in
> 2.7 M2 RC1 which is now resolved for master.
> Number of existing issues observed in this release is 3- toaster [8],
> Build-appliance [9] and qemu-shutdown [10]
> For ptest, regression data is not available for this release. 3
> packages are facing timeout issues: lttng-tools [11], openssh [12]
> and strace [13].
> Test result report on Public AB shows following failures:
> buildgalculator.GalculatorTest.test_galculator
> QA Comment: Expected failure for hw limitation
> python.PythonTest.test_python3
> QA Comment: Failure due to “python3” test case not backported to
> Thud. No bug filed as not real Yocto failure.

Thanks for running QA on this. Firstly, I can comment on the bugs:
 
> [7] Bug 13273 - [2.6.2 RC3] Systemtap doesn't work on beaglebone
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13273

We've root caused this on master and believe we know how to fix this,
its a kernel makefile configuration issue. We can likely document this
as a known issue and fix in 2.6.3.
 
> Previous Bugs observed in this release:
>  
> [8] 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
>  
> [9] 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

This is a long running issue we've been "ignoring", its likely resource
issues on the machine/VM running the test.

> [10] Bug 13234 - [2.7 M3 RC1] qemumips & qemumips64: failed to
> shutdown
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13234

This is an issue root caused to be from 4.19 and 5.0 kernels. I thought
2.6.2 had a 4.18 kernel so shouldn't have this issue? The bug wasn't
reopened?
 
> ptest Bugs:
>  
> [11] Bug 13255 - [2.7 M3 rc1] lttng-tools ptest facing timeout issue
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13255
>  
> [12] Bug 13256 - [2.7 M3 rc1] openssh ptest facing timeout issue
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13256
>  
> [13] Bug 13274 - [2.6.2 RC3] strace ptest facing timeout issue
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13274

ptest has been a bit tricky and we've been actively working these bugs
on master. Once we have them resolved there we can backport to older
releases.

There is one other critical issue we have with 2.6.2 which is the
revert of the boost upgrade. I'm very reluctant to release without that
revert as it caused problems for a lot of people.

I'm wondering whether we should rebuild 2.6.2 one commit later and then
release that assuming it passes a rerun of the automated QA (but not
the manual QA). Opinions on that?

I'd propose fixing the systemtap and ptest issues for 2.6.3.

Cheers,

Richard



-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] QA cycle report for 2.6.2 RC3

[richard . purdie]

On Wed, 2019-04-10 at 02:38 +, Jain, Sangeeta wrote:
>  
> QA cycle report for 2.6.2 RC3:
>  
> No high milestone defects. 
> Test results are available at following location:
> ·For results of all automated tests, 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]
> ·For ptest results, please refer to results at public AB [5]
> ·For ptest report, refer to attachment [6]
> 1 new defects are found in this cycle, Beaglebone [7].
> QA hint:  Similar issue for sysemtap failure (bug 13153) was found in
> 2.7 M2 RC1 which is now resolved for master.
> Number of existing issues observed in this release is 3- toaster [8],
> Build-appliance [9] and qemu-shutdown [10]
> For ptest, regression data is not available for this release. 3
> packages are facing timeout issues: lttng-tools [11], openssh [12]
> and strace [13].
> Test result report on Public AB shows following failures:
> buildgalculator.GalculatorTest.test_galculator
> QA Comment: Expected failure for hw limitation
> python.PythonTest.test_python3
> QA Comment: Failure due to “python3” test case not backported to
> Thud. No bug filed as not real Yocto failure.

Thanks for running QA on this. Firstly, I can comment on the bugs:
 
> [7] Bug 13273 - [2.6.2 RC3] Systemtap doesn't work on beaglebone
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13273

We've root caused this on master and believe we know how to fix this,
its a kernel makefile configuration issue. We can likely document this
as a known issue and fix in 2.6.3.
 
> Previous Bugs observed in this release:
>  
> [8] 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
>  
> [9] 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

This is a long running issue we've been "ignoring", its likely resource
issues on the machine/VM running the test.

> [10] Bug 13234 - [2.7 M3 RC1] qemumips & qemumips64: failed to
> shutdown
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13234

This is an issue root caused to be from 4.19 and 5.0 kernels. I thought
2.6.2 had a 4.18 kernel so shouldn't have this issue? The bug wasn't
reopened?
 
> ptest Bugs:
>  
> [11] Bug 13255 - [2.7 M3 rc1] lttng-tools ptest facing timeout issue
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13255
>  
> [12] Bug 13256 - [2.7 M3 rc1] openssh ptest facing timeout issue
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13256
>  
> [13] Bug 13274 - [2.6.2 RC3] strace ptest facing timeout issue
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13274

ptest has been a bit tricky and we've been actively working these bugs
on master. Once we have them resolved there we can backport to older
releases.

There is one other critical issue we have with 2.6.2 which is the
revert of the boost upgrade. I'm very reluctant to release without that
revert as it caused problems for a lot of people.

I'm wondering whether we should rebuild 2.6.2 one commit later and then
release that assuming it passes a rerun of the automated QA (but not
the manual QA). Opinions on that?

I'd propose fixing the systemtap and ptest issues for 2.6.3.

Cheers,

Richard



-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] Eclipse support dropped with immediate effect

[richard . purdie]

On Thu, 2019-04-11 at 08:42 +0530, akuster808 wrote:
> 
> On 4/10/19 3:11 PM, richard.pur...@linuxfoundation.org wrote:
> > On Wed, 2019-04-10 at 05:56 +0530, akuster808 wrote:
> > > On 4/9/19 8:52 PM, Richard Purdie wrote:
> > > > I'm sorry to have to say this but the project is terminating
> > > > its
> > > > official eclipse plugin support with immediate effect.
> > > Does this affect the stable branches as well?
> > Yes, I think we'll just be removing the target from the autobuilder
> > entirely.
> 
> Have we every removed a feature from a release? Do we need to doc
> this ?

Its not so much remove as not release. No, we haven't and yes, we do
need to document it in the release notes.

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] Eclipse support dropped with immediate effect

[richard . purdie]

On Wed, 2019-04-10 at 05:56 +0530, akuster808 wrote:
> 
> On 4/9/19 8:52 PM, Richard Purdie wrote:
> > I'm sorry to have to say this but the project is terminating its
> > official eclipse plugin support with immediate effect.
> 
> Does this affect the stable branches as well?

Yes, I think we'll just be removing the target from the autobuilder
entirely.

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Eclipse support dropped with immediate effect

[Richard Purdie]

I'm sorry to have to say this but the project is terminating its
official eclipse plugin support with immediate effect.

There is nobody willing to keep the builds going, fix bugs, port to new
eclipse releases or release the current plugin. This has been raised in
many forums, multiple times and nobody stepped up to help. With nobody
to do the work, we can't keep it going, it is that simple.

We'll be removing the automated testing of the eclipse plugin from the
autobuilder with immediate effect for all project releases.

Richard



-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [ptest-runner] Run ptests via stdbuf configured to line-buffering

[richard . purdie]

On Fri, 2019-04-05 at 06:54 +, mikko.rap...@bmw.de wrote:
> On Fri, Apr 05, 2019 at 07:46:00AM +0100, 
> richard.pur...@linuxfoundation.org wrote:
> > On Fri, 2019-04-05 at 06:16 +, mikko.rap...@bmw.de wrote:
> > > On Thu, Apr 04, 2019 at 10:48:17PM +0100, Richard Purdie wrote:
> > > > On Thu, 2019-04-04 at 18:00 +0200, Alexander Kanavin wrote:
> > > > > As ptest-runner communicates with child processes via
> > > > > pipe2(),
> > > > > the corresponding channels are not attached to a pty. In that
> > > > > situation stdio facilities like printf() or fwrite() are
> > > > > fully
> > > > > buffered. If a ptest would use them, without bothering
> > > > > to fflush() the output, ptest-runner will only receive what
> > > > > was written by the child ptest process after a buffer gets
> > > > > filled.
> > > > > If the unit tests are proceeding slowly, this may mean that
> > > > > ptest-runner will erroneously timeout due to an apparent lack
> > > > > of
> > > > > 'signs of life' from the child process.
> > > > > 
> > > > > stdbuf utility from coreutils adjusts the buffering to a
> > > > > line-
> > > > > buffered
> > > > > one, and so ptest-runner will get the lines as soon as they
> > > > > are
> > > > > written.
> > > > > 
> > > > > Signed-off-by: Alexander Kanavin 
> > > > > ---
> > > > >  utils.c | 7 ++-
> > > > >  1 file changed, 2 insertions(+), 5 deletions(-)
> > > > 
> > > > I'm a little torn on this. I noticed some of the run-ptest
> > > > scripts
> > > > use
> > > > "| sed -u" whilst the one you were seeing problems with uses "|
> > > > sed"
> > > > without -u.
> > > > 
> > > > We may want to consider strongly recommending -u. I'm testing a
> > > > patch
> > > > with some tweaks like that in it...
> > > 
> > > Please no. I'm running images without sed and using busybox sed
> > > instead, and that
> > > doesn't support -u. I'd rather be compatible with sed from
> > > busybox to
> > > keep changes
> > > to images minimal (e.g. install of additional packages) before
> > > executing ptests.
> > 
> > The other alternative option being proposed is for ptest-runner to
> > depend on coreutils which is worse?
> 
> GNU sed does not come from coreutils but from sed recipe.
> 
> Your call in the end. I just provided my point of view.

The original patch in this thread from Alex needs stdbuf which would
add a coreutils depends to ptest-runner for everything as I understand
it.

> > I did test the -u option to sed in the openssh ptest runner and it
> > did
> > fix the problems we've been seeing.
> > 
> > I'm open to other alternatives but the -u option to sed is looking
> > like
> > the best one we have right now. These bugs are making our testing
> > of
> > ptests effectively useless and unpredictable so this is a serious
> > issue...
> 
> Understood. I hope you could also add 'set -eux' to all ptest shell
> scripts. Many of them seem to be missing shell script error handling
> and failures like providing -u to busybox sed may go unnoticed.

Patches would be welcome to help clean up some of these scripts. I feel
like I'm fighting a lonely battle trying to get any of this to work at
times :(

The good news is the automated monitoring of the ptest results should
catch problems like that as if a chunk of ptests "disappear", the new
testing should quickly highlight that.

(We should improve the scripts, we just also have another way to spot
problems)

Cheers,

Richard



-- 
___
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)

[richard . purdie]

On Thu, 2019-04-04 at 17:58 -0700, Tim Orling wrote:
> Just curious: all Perl modules in oe-core have ptest enabled, but
> only libxml-parser-perl is included in these test reports. Is it
> simply the only module in that image or is something else afoot?

Its probably the only one in the image.

I have been meaning to go and round up all the ptest enabled things
which aren't making it in and add them but until the basic image works,
its not been a priority.

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [ptest-runner] Run ptests via stdbuf configured to line-buffering

[richard . purdie]

On Fri, 2019-04-05 at 06:16 +, mikko.rap...@bmw.de wrote:
> On Thu, Apr 04, 2019 at 10:48:17PM +0100, Richard Purdie wrote:
> > On Thu, 2019-04-04 at 18:00 +0200, Alexander Kanavin wrote:
> > > As ptest-runner communicates with child processes via pipe2(),
> > > the corresponding channels are not attached to a pty. In that
> > > situation stdio facilities like printf() or fwrite() are fully
> > > buffered. If a ptest would use them, without bothering
> > > to fflush() the output, ptest-runner will only receive what
> > > was written by the child ptest process after a buffer gets
> > > filled.
> > > If the unit tests are proceeding slowly, this may mean that
> > > ptest-runner will erroneously timeout due to an apparent lack of
> > > 'signs of life' from the child process.
> > > 
> > > stdbuf utility from coreutils adjusts the buffering to a line-
> > > buffered
> > > one, and so ptest-runner will get the lines as soon as they are
> > > written.
> > > 
> > > Signed-off-by: Alexander Kanavin 
> > > ---
> > >  utils.c | 7 ++-
> > >  1 file changed, 2 insertions(+), 5 deletions(-)
> > 
> > I'm a little torn on this. I noticed some of the run-ptest scripts
> > use
> > "| sed -u" whilst the one you were seeing problems with uses "|
> > sed"
> > without -u.
> > 
> > We may want to consider strongly recommending -u. I'm testing a
> > patch
> > with some tweaks like that in it...
> 
> Please no. I'm running images without sed and using busybox sed
> instead, and that
> doesn't support -u. I'd rather be compatible with sed from busybox to
> keep changes
> to images minimal (e.g. install of additional packages) before
> executing ptests.

The other alternative option being proposed is for ptest-runner to
depend on coreutils which is worse?

I did test the -u option to sed in the openssh ptest runner and it did
fix the problems we've been seeing.

I'm open to other alternatives but the -u option to sed is looking like
the best one we have right now. These bugs are making our testing of
ptests effectively useless and unpredictable so this is a serious
issue...

Cheers,

Richard





-- 
___
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)

[richard . purdie]

On Fri, 2019-04-05 at 03:46 +0530, akuster808 wrote:
> 
> On 4/5/19 3:25 AM, richard.pur...@linuxfoundation.org wrote:
> > On Thu, 2019-04-04 at 02:19 +, Jain, Sangeeta wrote:
> > > 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?
> > These were run separately but will run as part of any new stable
> > release builds. The results are here:
> > 
> > https://autobuilder.yocto.io/pub/non-release/20190328-8/testresults/qemux86-64-ptest/
> > https://autobuilder.yocto.io/pub/non-release/20190328-7/testresults/qemux86-64-ptest/
> > 
> > (for 2.6.2 and 2.5.4)
> > 
> > I'll merge these into the main release output in due course.
> Did I miss something in order to create:
> https://autobuilder.yocto.io/pub/non-release/20190326-8/testresults/testresult-report.txt

Right now only a-quick or a-full builds get those.

You can get one with:

$ wget 
https://autobuilder.yocto.io/pub/non-release/20190328-8/testresults/qemux86-64-ptest/testresults.json
$ resulttool report .

which gives:

==
PTest Result Summary
==
--
Recipe | Passed  | Failed   | Skipped  | Time(s)   
--
acl| 221 | 0| 0| -
attr   | 109 | 0| 0| -
bash   | 75  | 4| 0| -
bluez5 | 25  | 0| 0| -
busybox| 528 | 15   | 45   | -
bzip2  | 6   | 0| 0| -
dbus-test  | 18  | 3| 2| -
diffstat   | 439 | 0| 0| -
diffutils  | 20  | 0| 0| -
e2fsprogs  | 315 | 6| 27   | -
flex   | 114 | 0| 0| -
gawk   | 342 | 0| 0| -
gdbm   | 24  | 0| 0| -
gdk-pixbuf | 20  | 0| 0| -
glib-2.0   | 259 | 3| 0| -
gstreamer1.0   | 101 | 3| 0| -
gzip   | 21  | 0| 0| -
libpcre| 3   | 0| 0| -
libusb1| 4   | 0| 0| -
libxml-parser-perl | 15  | 0| 0| -
libxml2| 134 | 0| 0| -
lttng-tools| 1087| 0| 0| - T
lzo| 39  | 6| 0| -
nettle | 158 | 0| 2| -
openssh| 832 | 72   | 367  | - T
openssl| 0   | 0| 0| -
pango  | 12  | 0| 0| -
perl   | 2298| 1| 120  | -
python | 5444| 15   | 53   | -
python3| 7466| 0| 198  | -
quilt  | 57  | 0| 0| -
sed| 86  | 0| 0| -
slang  | 97  | 0| 0| -
strace | 213 | 272  | 97   | - T
tcl| 148 | 0| 0| -
util-linux | 0   | 395  | 55   | -
--

and

$ wget 
https://autobuilder.yocto.io/pub/non-release/20190328-7/testresults/qemux86-64-ptest/testresults.json
$ resulttool report .

which gives:

==
PTest Result Summary
==
--
Recipe | Passed  | Failed   | Skipped  | Time(s)   
--
acl| 221 | 0| 0| -
attr   | 109 | 0| 0| -
bash   | 75  | 4| 0| -
bluez5 | 7   | 0| 0| -
busybox| 509 | 14   | 36   | -
bzip2  | 6   | 0| 0| -
dbus-test  | 18  | 3| 2| -
diffstat   | 

Re: [yocto] QA notification for completed autobuilder build (yocto-2.6.2.rc3)

[richard . purdie]

On Thu, 2019-04-04 at 02:19 +, Jain, Sangeeta wrote:
> 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?

These were run separately but will run as part of any new stable
release builds. The results are here:

https://autobuilder.yocto.io/pub/non-release/20190328-8/testresults/qemux86-64-ptest/
https://autobuilder.yocto.io/pub/non-release/20190328-7/testresults/qemux86-64-ptest/

(for 2.6.2 and 2.5.4)

I'll merge these into the main release output in due course.

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [ptest-runner] Run ptests via stdbuf configured to line-buffering

[Richard Purdie]

On Thu, 2019-04-04 at 18:00 +0200, Alexander Kanavin wrote:
> As ptest-runner communicates with child processes via pipe2(),
> the corresponding channels are not attached to a pty. In that
> situation stdio facilities like printf() or fwrite() are fully
> buffered. If a ptest would use them, without bothering
> to fflush() the output, ptest-runner will only receive what
> was written by the child ptest process after a buffer gets filled.
> If the unit tests are proceeding slowly, this may mean that
> ptest-runner will erroneously timeout due to an apparent lack of
> 'signs of life' from the child process.
> 
> stdbuf utility from coreutils adjusts the buffering to a line-
> buffered
> one, and so ptest-runner will get the lines as soon as they are
> written.
> 
> Signed-off-by: Alexander Kanavin 
> ---
>  utils.c | 7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)

I'm a little torn on this. I noticed some of the run-ptest scripts use
"| sed -u" whilst the one you were seeing problems with uses "| sed"
without -u.

We may want to consider strongly recommending -u. I'm testing a patch
with some tweaks like that in it...

Cheers,

Richard

-- 
___
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)

[richard . purdie]

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

Re: [yocto] Proposed new QA process

[richard . purdie]

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


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] QA cycle report for 2.7 M3 RC1

[richard . purdie]

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?

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?

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] openssh ptest facing timeout issue
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13256

No ideas on this one yet.

> [15] Bug 13257 - [2.7 M3 rc1] python3 ptest facing timeout issue
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13257

I'm hoping a patch from Ross in master fixes this, need to retest ptest
with this applied.

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] Git commit process question.

[Richard Purdie]

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?

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] New: "extrapatches" bbclass.

[Richard Purdie]

On Thu, 2019-03-07 at 19:26 -0800, Kaz Kylheku (poky) wrote:
> #
> # extrapatches bbclass
> #
> # This bbclass allows for a recipe to apply additional patches.
> #
> # "Additional patches" refers to patches that are not individually
> # fetched by the SRC_URI mechanism, but are already present
> # inside the source trees that are fetched and unpacked.
> # Referring directly to recipe-side patches
> # without fetching them via SRC_URI is also possible.
> #
> # How to use this class:
> #
> #   1. Add   inherit extrapatches   to your recipe.
> #   2. Optionally set the EXTRAPATCHES_WORKDIR,
> #   3. List the patches in EXTRAPATCHES in order of application.
> #  - Relative paths are interpreted relative to 
> EXTRAPATCHES_WORKDIR.
> #  - Absolute paths are allowed

Can't you already do this if you put a file:// url in SRC_URI for the
patch as its unpacked in the workdir?

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Incremental rebuild doesn't pick up FILES changes.

[Richard Purdie]

On Tue, 2019-03-05 at 18:28 -0800, Kaz Kylheku (poky) wrote:
> Hi,
> 
> I'm working in a Yocto 2.5 environment.
> 
> In my own layer, I added a bbappend targeting python which does this:
> 
>FILES_${PN}_remove = "${libdir}/python2.7/encodings"
> 
> Now this didn't take effect as I expected. I had to do a "bitbake -c 
> cleanall python" to rebuild the package.
> 
> In any case, all I have in the image now, as I expected, is these
> four 
> files, vastly reduced from dozens:
> 
>/usr/lib/python2.7/encodings/{aliases,utf-8}.{py,pyc}
> 
> Now, if I comment out this FILES_${PN}_remove variable assignment, I 
> cannot get the previously removed encoding modules to re-appear in
> my 
> image! I tried "bitbake -c cleanall" on python, and blowing away its 
> build directory. It didn't work; still there are just those four
> files.
> 
> How do we get Yocto to react to FILES changes, short of blowing away
> the entire build tree?

Maybe related to this change:

http://git.yoctoproject.org/cgit.cgi/poky/commit/bitbake/lib/bb/data_smart.py?id=f7f5e30667e1ad8e1ca76ee331be2843f2976bfa

?

Cheers,

Richard


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [opkg-devel] [opkg-utils] Question: why update-alternatives from opkg-utils chooses /usr/lib to hold database?

[Richard Purdie]

On Tue, 2019-03-05 at 16:05 +, Alejandro Del Castillo wrote:
> 
> On 3/5/19 12:11 AM, ChenQi wrote:
> > Hi All,
> > 
> > Recently I'm dealing with issue from which some discussion raises.
> > I'd like to ask why update-alternatives from opkg-utils chooses
> > /usr/lib 
> > to hold its alternatives database?
> > I looked into debian, its update-alternatives chooses /var/lib by
> > default.
> > Is there some design consideration? Or some historical reason?
> 
> Update-alternatives used to be on the opkg repo. I did a search
> there 
> all the way to the first commit on 2008-12-15 [1], but even then 
> /usr/lib was used. I can't think of a design consideration that
> would 
> make /usr/lib more palatable than the Debian default.
> 
> Maybe someone with more knowledge of the previous history can chime
> in?
> 
> [1] 
> http://git.yoctoproject.org/clean/cgit.cgi/opkg/commit/?id=8bf49d16a637cca0cd116450dfcabc4c941baf6c

I think the history is that the whole of /var was considered volatile
and we wanted the alternatives data to stick around so it was put under
/usr.

That decision doesn't really make sense now since only parts of /var
are volatile..

Cheers,

Richard


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Removing busybox

[Richard Purdie]

On Thu, 2019-02-28 at 09:37 -0500, Tom Rini wrote:
> On Thu, Feb 28, 2019 at 02:27:37PM +0000, Richard Purdie wrote:
> > On Thu, 2019-02-28 at 12:05 +, Burton, Ross wrote:
> > > I thought we had some other editor in core, but can't see
> > > one.  Worse
> > > case we still use busybox for its vi... :)
> > 
> > This could be an argument for pulling a small number of things into
> > OE-
> > Core too...
> 
> Moving the vim recipe (which doesn't have further depends) over and
> then
> putting VIRTUAL-RUNTIME_vim and ?= "vim-tiny" in this packagegroup
> should be flexible enough, yes?

Yes.

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Removing busybox

[Richard Purdie]

On Thu, 2019-02-28 at 12:05 +, Burton, Ross wrote:
> On Thu, 28 Feb 2019 at 05:20, Adrian Bunk  wrote:
> > > That's a good start.  For a oe-core packagegroup
> > 
> > I do not think a core-only packagegroup makes sense when the goal
> > is to
> > completely replace busybox (and not just most apps while keeping a
> > few
> > busybox apps installed).
> 
> But a "close enough" packagegroup in core would be a good starting
> point.
> 
> > > I'd suggest dropping
> > > dnsmasq bridgeutils bindutils to keep it lean.
> > 
> > The stated usecases are not "lean" but "replace all busybox
> > commands
> > with the full versions".
> > 
> > For that you need bind-utils (in oe-core) for DNS lookup.
> 
> Good point well made.
> > > Also swap vim for something in core obviously.
> > 
> > It is not obvious how to do that.
> > 
> > What other vi implementation is in core?
> > Is there even any good non-busybox non-GUI editor in core?
> > Replacing busybox vi with ed would be a bad fit for the
> > stated usecases.
> > 
> > There has to be some vi implementation installed,
> > and the "desktop command" implementation is vim.
> 
> I thought we had some other editor in core, but can't see one.  Worse
> case we still use busybox for its vi... :)

This could be an argument for pulling a small number of things into OE-
Core too...

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Review request 0/13: Contribute meta-tensorflow to Yocto

[Richard Purdie]

On Fri, 2019-02-22 at 20:49 +, Manjukumar Harthikote Matha wrote:
> > 
> > You might be interested in the yocto layers for tensorflow,
> > tensorflow-lite and
> > caffe2 on github here [1]. I'm not part of the team that developed
> > that work but I
> > forwarded your announcement to them. Perhaps there is the
> > opportunity for some
> > collaboration on the platform independent parts. The maintainer
> > details are in the
> > readme.
> > 
> 
> Thanks for the layer Hongxu. I agree with Steve, it would be good if
> you could collaborate with meta-renesas-ai and introduce the layer as
> meta-ai under meta-openembedded. 

Please don't do the meta-openembedded part!

I believe that meta-oe is too large to be maintainable and that we need
a larger number of smaller layers.

Having tensorflow in its own layer which as a specific purpose and its
specific maintainers who understand it is in my view much more
desirable and sustainable.

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Review request 0/13: Contribute meta-tensorflow to Yocto

[Richard Purdie]

Hi Hongxu,

On Thu, 2019-02-21 at 06:37 -0500, Hongxu Jia wrote:
> Currently AI on IoT edge becomes more and more popular, but there is
> no
> machine learning framework in Yocto/OE. With the support of Eric
> , Robert 
> and Randy , after two months effort,
> I've
> integrated TensorFlow to Yocto.
> 
> Now, I contribute the patches to Yocto for review, and apply for
> creating
> a layer named `meta-tensorflow' on Yocto.
> 
> For test convenient, there is a fork on github:
> https://github.com/hongxu-jia/meta-tensorflow
> 
> BTW, I have contributed other 11 fundamental recipes to meta-
> openembedded
> and all of them have been merged to master branch.
> 
> Please no hesitate to share your suggestion.

I like this a lot, thanks for working on and sharing it!

I had a quick glance through the patches and I didn't see anything that
concerned me. I don't have much knowledge about tensor flow. I think
this would make a great addition to git.yoctoproject.org and would love
to see it there.

Thanks again, I'm pleased to see something like this!

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] QA notification for completed autobuilder build (yocto-2.7_M2.rc2)

[Richard Purdie]

On Tue, 2019-02-12 at 17:57 +, pokybuild@centos7-ty-1.localdomain
wrote:
> A build flagged for QA (yocto-2.7_M2.rc2) was completed on the
> autobuilder and is available at:
> 
> 
> https://autobuilder.yocto.io/pub/releases/yocto-2.7_M2.rc2
> 
> 
> Build hash information: 
> 
> bitbake: d73dbc3580faa1225d95ae4cefac4879ca3c1b2f
> eclipse-poky-neon: cd86f167be58a11b289af4ef236b4adec57ec316
> eclipse-poky-oxygen: 210c58c5a7147127f9c840718c6cd2a56e871718
> meta-gplv2: aabc30f3bd03f97326fb8596910b94639fea7575
> meta-intel: 29e4db5bf484f18e41bc9123161b1c069e60a128
> meta-mingw: 423433e3d31a32dbb80203c628e808442d440ad1
> meta-qt3: 23d7543ebd7e82ba95cbe19043ae4229bdb3b6b1
> meta-qt4: b37d8b93924b314df3591b4a61e194ff3feb5517
> oecore: 2dbbf598192ae2b3aa488df042f56aa6c6634a00
> poky: be52da152a4d9f9e798844f592ec9ae7e051c658
> 
> 
> 
> This is an automated message from the Yocto Project Autobuilder
> Git: git://git.yoctoproject.org/yocto-autobuilder2
> Email: richard.pur...@linuxfoundation.org

Just to mention there was a failure in oecore-qemuarm but it was due to
autobuilder configuration problems (now fixed[1]) so doesn't influence
this QA run.

[1] https://autobuilder.yoctoproject.org/typhoon/#/builders/47/builds/274

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] QA cycle report for 2.7 M2 RC1

[Richard Purdie]

On Fri, 2019-02-08 at 04:38 +, Jain, Sangeeta wrote:
> This is the full report for 2.7 M2 RC1:
>  
> https://wiki.yoctoproject.org/wiki/WW01_-_2019-01-28_-_Full_Test_Cycle_2.7_M2_RC1
>  
> === Summary 
>  
> All planned tests were executed.
> Total Test Executed - 3629
> Passed Test - 3613
> Failed Test - 16
>  
>  
> There were zero high milestone defect.  Team had found 3 new defects
> in BSP[1], Compliance [2] and  OE-Core[3].
> 5 existing issues were observed in this release.
>  
> For ptest, there is a drop in percentage of pass rate for 3 modules:
> nettle, perl and valgrind. Bugs are reported for Nettle [4] and Perl
> [5]. For Valgrind, no bug is filed, since there is a decrease in
> percentage but no failures as compared to previous results.

Thanks!

The perl regressions are fairly serious, but understandable given the
large changes we made to perl in M2. I'm therefore torn on whether we
let rc1 release, or we respin an rc2 based on current master. Any
opinions?

Current master does fix perl (bugs 13160, 13161, 13154), it also has a
key toaster fix for thud.

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] bb.build.addtask: add simple check for circular dependency

[Richard Purdie]

On Fri, 2019-01-18 at 15:16 +0100, Ulf Samuelsson wrote:
> > 18 jan. 2019 kl. 12:29 skrev Richard Purdie <
> > richard.pur...@linuxfoundation.org>:
> > 
> > > On Fri, 2019-01-18 at 05:30 +0100, Ulf Samuelsson wrote:
> > > So if KNOWN_TASKS is defined in a configuration file in oe-core,
> > > it
> > > would be OK?
> > > It needs to be extended to check for KNOWN_TASKS == None of
> > > course.
> > 
> > No, this is too fragile. We then have to maintain two different
> > lists
> > of tasks. If we did that we may as well just remove the generic
> > tasks
> > mechanism and hardcode the tasks list in the metadata.
> > 
> Why do we need two lists?

If we change one of these "generic" tasks, we then need to remember to
also update KNOWN_TASKS. The same information is being encoded in two
places.

Maintaining the same information in two different places means one of
those places inevitably ends up out of date.

> We need to know in what order the generic tasks are executed, that is
> all.
> 
> Then we need to see if an addtask is violating that order.
> If the ”after” or ”before” is not a generic task, the check cannot
> catch that.
> 
> If the user decides to not use the generic tasks, and create new ones
> with the same name, as the generic tasks, but rearranges the order,
> there will be a problem, but I do not see any other problems.
> 
> Please enlighten me!

This has the problem that the code will find some subset of the bugs
but not all of them. We'll then get users reporting that the tests
failed and asking for the checks to be improved.

So no, we are not doing this, sorry.

Cheers,

Richard


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] bb.build.addtask: add simple check for circular dependency

[Richard Purdie]

On Fri, 2019-01-18 at 05:30 +0100, Ulf Samuelsson wrote:
> So if KNOWN_TASKS is defined in a configuration file in oe-core, it
> would be OK?
> It needs to be extended to check for KNOWN_TASKS == None of course.

No, this is too fragile. We then have to maintain two different lists
of tasks. If we did that we may as well just remove the generic tasks
mechanism and hardcode the tasks list in the metadata.

As I mentioned, we need to come up with something which detects the
task loops generically.

Cheers,

Richard



-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] bb.build.addtask: add simple check for circular dependency

[Richard Purdie]

On Thu, 2019-01-17 at 19:15 +0100, Ulf Samuelsson wrote:
>  From 864e49bedbdab480c5ada9588ce8f980f23919dd Mon Sep 17 00:00:00
> 2001
> From: Ulf Samuelsson 
> Date: Thu, 17 Jan 2019 19:07:17 +0100
> Subject: [PATCH] bb.build.addtask: add simple check for circular
> dependency

We really can't hardcode a list of tasks like this in bitbake :(

The list is also incorrect (at a quick look its packagedata and
populate_sysroot is missing).

We'll need to come up with a better algorithm than this. From
experience with circular task dependencies within bitbake's runqueue,
this is a hard problem though.

Cheers,

Richard

> Signed-off-by: Ulf Samuelsson 
> ---
>   bitbake/lib/bb/build.py | 48 
> 
>   1 file changed, 48 insertions(+)
> 
> diff --git a/bitbake/lib/bb/build.py b/bitbake/lib/bb/build.py
> index 3e2a94e..887ced1 100644
> --- a/bitbake/lib/bb/build.py
> +++ b/bitbake/lib/bb/build.py
> @@ -43,6 +43,25 @@ logger = logging.getLogger('BitBake.Build')
> 
>   __mtime_cache = {}
> 
> +KNOWN_TASKS = {
> +'do_fetch' :   1 ,
> +'do_unpack' :  2 ,
> +'do_patch' :   3 ,
> +'do_configure' :   4 ,
> +'do_compile' : 5 ,
> +'do_install' : 6 ,
> +'do_package' : 7 ,
> +'do_package_data' :8 ,
> +'do_rootfs' :  9 ,
> +'do_image_qa' :   10 ,
> +'do_image' :  11 ,
> +'do_image_tar' :  12 ,
> +'do_image_ubifs' :12 ,
> +'do_image_jffs2' :12 ,
> +'do_image_complete' : 13 ,
> +'do_build' :  14
> +}
> +
>   def cached_mtime_noerror(f):
>   if f not in __mtime_cache:
>   try:
> @@ -820,7 +839,34 @@ def add_tasks(tasklist, d):
>   # don't assume holding a reference
>   d.setVar('_task_deps', task_deps)
> 
> +def circular(after, before):
> +if after == None:
> +return False
> +if before == None:
> +return False
> +for a in after.split():
> +if a in KNOWN_TASKS:
> +for b in before.split():
> +if a == b:
> +return True
> +if b in KNOWN_TASKS:
> +if KNOWN_TASKS[b] < KNOWN_TASKS[a]:
> +return True
> +else:
> +# tasks OK
> +pass
> +else:
> +# b is unknown
> +pass
> +else:
> +# a is unknown
> +pass
> +
>   def addtask(task, before, after, d):
> +if circular(after, before):
> +logger.error("addtask: %s cannot be after %s and before %s"
> % 
> (task, after, before))
> +raise
> +
>   if task[:3] != "do_":
>   task = "do_" + task
> 
> @@ -909,3 +955,5 @@ def tasksbetween(task_start, task_end, d):
>   chain.pop()
>   follow_chain(task_start, task_end)
>   return outtasks
> +
> +

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] bitbake: DataSmart.expandWithRefs causing exception when handed "${@...}"

[Richard Purdie]

On Sun, 2019-01-13 at 22:53 +0100, Ulf Samuelsson wrote:
> I am trying to add a new image class "SWU" in "sumo" for a "software
> update image".
> As a result:
> do_sdk_depends[depends] = '${@get_ext_sdk_depends(d)} meta-extsdk-
> toolchain:do_populate_sysroot'
> 
> When data_smart.py works on this, it will call 
> 
> DataSmart.expandWithRefs(self, s, varname)
> s= '${@get_ext_sdk_depends(d)} meta-extsdk-
> toolchain:do_populate_sysroot'
> varname  = 'do_sdk_depends[depends]'
> 
> I will get an exception in this statement:
> 
> while s.find('${') != -1:
> olds = s
> try:
> s = __expand_var_regexp__.sub(varparse.var_sub, s)
> 
> The definition of __expand_var_regexp__ is:
>   __expand_var_regexp__ = re.compile(r"\${[^{}@\n\t :]+}")
> 
> That is, it is looking for the string "${}"
> but  may not contains anything in [{}@\n\t :]
> 
> since the "variable" in "s" is actually a call to
> get_ext_sdk_depends,
> and thus contains a '@' character it is not matched.
> 
> The build aborts with an exception.
> 
> I am not sure, if '${@get_ext_sdk_depends(d)}' should be expanded
> before
> DataSmart,expandWithRefs, or if expandWithRefs needs to be extended
> to handle the case where the variable is a "call".
> 
> This is blocking us from upgrading from pyro to sumo.
> 
> Any ideas on a solution?

Can you firstly say what the error is you're seeing. Your attempt to
understand it is good but I'm not sure which error you see?

Secondly, is there a way someone else could reproduce this bug?

The fragment you quote looks correct. If you have variable and function
names conflicting that would be a problem though as they're all in the
same namespace. I'm unclear whether that is a problem here or not
though based on the available information.

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCHv2][ptest-runner] ptest-runner: Add support to report duration of each ptest

[Richard Purdie]

On Wed, 2019-01-09 at 12:00 -0600, Anibal Limon wrote:
> 
> 
> On Tue, 8 Jan 2019 at 14:00, 
> wrote:
> > On Mon, 2019-01-07 at 15:18 -0600, Aníbal Limón wrote:
> > > In stdout reported as,
> > > 
> > > ...
> > > BEGIN: ptest-dir
> > > ...
> > > DURATION: N
> > > END: ptest-dir
> > > ...
> > > 
> > > In XML reported as,
> > > 
> > > ...
> > > 
> > >   N
> > > 
> > > ...
> > > 
> > > Signed-off-by: Aníbal Limón 
> > > ---
> > >  tests/data/reference.xml |  2 ++
> > >  tests/utils.c| 20 
> > >  utils.c  | 19 ---
> > >  utils.h  |  2 +-
> > >  4 files changed, 27 insertions(+), 16 deletions(-)
> > 
> > I've not looked at the code detail but the above looks good to me
> > and
> > will significantly help ptest usage! :)
> > 
> > Once this is in are you able to help update the recipe and pass
> > this
> > data through to the the oe-selftest json report?
> 
> I will send the recipe upgrade, What is the selftest json report?,
> I'm not aware.

Sorry, its not from selftest, its from testimage running against an
image where ptests are present. It generates something like:

https://autobuilder.yocto.io/pub/releases/yocto-2.7_M1.rc1/testresults/qemux86-64-ptest/testresults.json

Cheers,

Richard



-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCHv2][ptest-runner] ptest-runner: Add support to report duration of each ptest

[richard . purdie]

On Mon, 2019-01-07 at 15:18 -0600, Aníbal Limón wrote:
> In stdout reported as,
> 
> ...
> BEGIN: ptest-dir
> ...
> DURATION: N
> END: ptest-dir
> ...
> 
> In XML reported as,
> 
> ...
> 
>   N
> 
> ...
> 
> Signed-off-by: Aníbal Limón 
> ---
>  tests/data/reference.xml |  2 ++
>  tests/utils.c| 20 
>  utils.c  | 19 ---
>  utils.h  |  2 +-
>  4 files changed, 27 insertions(+), 16 deletions(-)

I've not looked at the code detail but the above looks good to me and
will significantly help ptest usage! :)

Once this is in are you able to help update the recipe and pass this
data through to the the oe-selftest json report?

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH][ptest-runner] ptest-runner: Add support to report duration of each ptest

[richard . purdie]

On Sun, 2019-01-06 at 11:43 -0600, Aníbal Limón wrote:
> In stdout reported as,
> 
> ...
> BEGIN: ptest-dir
> ...
> DURATION: Ns
> END: ptest-dir
> ...
> 
> In XML reported as,
> 
> ...
> 
>   Ns
> 
> ...

Looks good, thanks!

One minor detail - should this be:

N

?

I'm wondering if we should just mandate duration is in seconds and not
put units into the field as it would complicate parsing?

Cheers,

Richard


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH][ptest-runner] ptest-runner: Add support timeout failure type to XML result file

[richard . purdie]

On Sat, 2019-01-05 at 11:30 -0600, Anibal Limon wrote:
> 
> 
> On Thu, 3 Jan 2019 at 15:45, 
> wrote:
> > On Thu, 2019-01-03 at 12:02 -0600, Aníbal Limón wrote:
> > > The ptest-runner support logging results to stdout and to a XML
> > file
> > > in stdout the ptest is mark as:
> > > 
> > > ...
> > > ERROR: Exit status is 1
> > > TIMEOUT: ptest-directory
> > > ...
> > > 
> > > Add the same support in XML file for example,
> > > 
> > > ...
> > > 
> > >   
> > >   
> > > 
> > > ...
> > > 
> > > [YOCTO #13088]
> > > 
> > > Signed-off-by: Aníbal Limón 
> > 
> > Sounds good, thanks!
> > 
> > I have a feeling this will show up a few bugs but we should find
> > and
> > fix the ones which are timing out...
> > 
> > I'd still be interested in the time each directory takes too if we
> > can
> > get that as it would help us decide which tests to run.
> 
> The timeout is set to 5 minutes (300 secs) by default and currently
> there is no way to set a timeout per ptest, 
> I will create other patch to add the timeout value to stdout and XML
> file.

That is handy but what I mean is the execution time each one takes. If
we have test which take 5s its easier to run them regularly than tests
which take 500s. Having an idea of their relative execution time would
therefore be helpful.

I assume the timeout takes effect after no output for that period?

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH][ptest-runner] ptest-runner: Add support timeout failure type to XML result file

[richard . purdie]

On Thu, 2019-01-03 at 12:02 -0600, Aníbal Limón wrote:
> The ptest-runner support logging results to stdout and to a XML file
> in stdout the ptest is mark as:
> 
> ...
> ERROR: Exit status is 1
> TIMEOUT: ptest-directory
> ...
> 
> Add the same support in XML file for example,
> 
> ...
> 
>   
>   
> 
> ...
> 
> [YOCTO #13088]
> 
> Signed-off-by: Aníbal Limón 

Sounds good, thanks!

I have a feeling this will show up a few bugs but we should find and
fix the ones which are timing out...

I'd still be interested in the time each directory takes too if we can
get that as it would help us decide which tests to run.

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Accelerate kernel module built in eSDK?

[richard . purdie]

On Fri, 2018-12-28 at 22:35 +0800, Zhaolong Zhang wrote:
> On 2018/12/28 19:40, richard.pur...@linuxfoundation.org wrote:
> > On Fri, 2018-12-28 at 18:19 +0800, Zhaolong Zhang wrote:
> > > Hi Experts,
> > > 
> > > Building out-of-tree kernel modules in eSDK will trigger a new
> > > rebuilding of kernel, which consumes lots of time.
> > > Is it possible to cache the do_shared_workdir() task in sstate-
> > > cache
> > > and ship it within eSDK? And how?
> > > 
> > > Or is there other method to accelerate?
> > > 
> > > Thanks in advance.
> > 
> > It is possible but it means creating a tarball of all the kernel
> > source
> > and build artefacts. Usually its just as quick to extract new
> > kernel
> > source and build it than it is to store this and extract it. The
> > sstate
> > object would be huge.
> > 
> 
> Hi Richard,
> 
> Thanks for responding!
> 
> Isn't sstate object also a tarball for them? Creating another
> tarball 
> would be a hacking and how can I let module.bbclass know that the
> kernel 
> source and build artifact are ready, without sstate hashes?

My point is that using sstate for this will be slow and mean there is a
very large sstate object. The performance benefits aren't very clear.
We used to create an sstate object but it got a lot of complaints about
speed/performance.

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto