[yocto] bb-matrix.sh Script not working as expected
Hello, I'm trying to evaluate the performance of my builds and following the wiki link https://wiki.yoctoproject.org/wiki/Build_Performance to determine the accurate BB and PM values for my builds. I have set "INHERIT += "buildstats"" in my local.conf and disabled "BB_NUMBER_THREADS" & "PARALLEL_MAKE" during the execution of the build and the script. Executing the script bb-matrix.sh from the BUILDDIR with the command ". ../poky-sumo-19.0.0/scripts/contrib/bb-perf/bb-matrix.sh ." deletes the TMPDIR entirely and then complains 'cp: cannot stat ‘tmp/buildstats’: No such file or directory' for each iteration of BB and PM values. I don't understand where I am going wrong and how do I go about generating the dat file and in turn plotting the graph to determine the performance of the build? Thanks! Dhanush -- ___ 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?
On Thu, 25 Apr 2019, Richard Purdie wrote: ... big snip of warning me about what i'm trying to do ... > This is a bad idea and you're on a path to madness ;-) i already knew that ... i did admit i've been out of YP for a while and have a lot of catching up to do. i suspect my next few days will be full of reading. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ 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?
On Thu, 25 Apr 2019, Bach, Pascal wrote: > rday wrote: > > 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? > > Generally it's fine to use ASSUME_PROVIDED if you don't mind the > dependency between the build host and Yocto. as i mentioned, i'm already living life on the edge doing all this on fedora 30 branched (the unofficial next release), so i'm quite prepared to trip over versioning issues, and testing all this against F30 at least warns me about upcoming issues that i might be able to do bug reports or patches against ahead of time. and it's easy to see there's a *ton* of packages i can assume natively that should be fairly safe; in many cases, the version that would be built by YP is exactly the same version i already have natively. in other cases, the difference might be a micro-version off. anyway, i probably wouldn't have bothered with this if it weren't for that cmake issue. but let's see where this goes. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ 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?
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?
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] ASSUME_PROVIDED, cmake-native and why cmake is subsequently not found?
> 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/# > 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? > Generally it's find to use ASSUME_PROVIDED if you don't mind the dependency between the build host and Yocto. Pascal -- ___ 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?
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" 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? 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. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] ASSUME_PROVIDED, cmake-native and why cmake is subsequently not found?
(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 | - 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. 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? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] QA cycle report for 2.5.3 RC3
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
