Re: [OE-core] [PATCH] mtd-utils: Upgrade to 2.0.0
On Thu, 2017-03-02 at 10:59 +0100, Alexandre Belloni wrote: > Hi, > > On 04/01/2017 at 19:28:46 +, Mike Crowe wrote: > > Upstream has started using automake which means that the recipe must now > > inherit from autotools and pkgconfig. > > > > The source tree has been reorganised too which requires the paths in the > > patches to be modified. None of the patches appear to have been applied > > upstream. > > > > They haven't been applied because they have never been submitted > upstream (despite being tagged with "Upstream-Status: Pending") That's the problem with "Pending" - it doesn't really mean that the original author has specific plans in place to get the patches upstream, and because there's no systematic tracking of "Pending" patches there's also no pressure to do so once the patch has been accepted into OE-core. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/3] rm_work.bbclass: clean up sooner
quilt-native_0.65.bb:do_unpack 3. ID /work/iot-ref-kit/openembedded-core/meta/recipes-devtools/quilt/quilt-native_0.65.bb:do_patch 4. ID /work/iot-ref-kit/openembedded-core/meta/recipes-devtools/quilt/quilt-native_0.65.bb:do_prepare_recipe_sysroot 5. ID /work/iot-ref-kit/openembedded-core/meta/recipes-devtools/quilt/quilt-native_0.65.bb:do_configure 6. ID /work/iot-ref-kit/openembedded-core/meta/recipes-devtools/quilt/quilt-native_0.65.bb:do_compile 7. ID /work/iot-ref-kit/openembedded-core/meta/recipes-devtools/quilt/quilt-native_0.65.bb:do_install 8. ID /work/iot-ref-kit/openembedded-core/meta/recipes-devtools/quilt/quilt-native_0.65.bb:do_populate_sysroot 9. ID /work/iot-ref-kit/openembedded-core/meta/recipes-extended/texinfo-dummy-native/texinfo-dummy-native.bb:do_fetch ... 597. ID virtual:native:/work/iot-ref-kit/openembedded-core/meta/recipes-core/gettext/gettext_0.19.8.1.bb:do_populate_lic 598. ID virtual:native:/work/iot-ref-kit/openembedded-core/meta/recipes-devtools/flex/flex_2.6.2.bb:do_rm_work 599. ID virtual:native:/work/iot-ref-kit/openembedded-core/meta/recipes-core/ncurses/ncurses_6.0+20161126.bb:do_rm_work 600. ID virtual:native:/work/iot-ref-kit/openembedded-core/meta/recipes-graphics/xorg-proto/xproto_7.0.31.bb:do_rm_work 601. ID /work/iot-ref-kit/openembedded-core/meta/recipes-core/glibc/glibc_2.25.bb:do_rm_work 602. ID virtual:native:/work/iot-ref-kit/openembedded-core/meta/recipes-support/popt/popt_1.16.bb:do_rm_work 603. ID /work/iot-ref-kit/openembedded-core/meta/recipes-core/systemd/systemd-systemctl-native.bb:do_rm_work 604. ID virtual:native:/work/iot-ref-kit/openembedded-core/meta/recipes-extended/gperf/gperf_3.0.4.bb:do_rm_work 605. ID /work/iot-ref-kit/openembedded-core/meta/recipes-devtools/gcc/gcc-cross-initial_6.3.bb:do_rm_work 606. ID /work/iot-ref-kit/openembedded-core/meta/recipes-devtools/libtool/libtool-native_2.4.6.bb:do_rm_work 607. ID virtual:native:/work/iot-ref-kit/openembedded-core/meta/recipes-devtools/ossp-uuid/ossp-uuid_1.6.2.bb:do_rm_work 608. ID virtual:native:/work/iot-ref-kit/openembedded-core/meta/recipes-graphics/xorg-util/util-macros_1.19.1.bb:do_rm_work 609. ID virtual:native:/work/iot-ref-kit/openembedded-core/meta/recipes-support/attr/acl_2.2.52.bb:do_rm_work 610. ID virtual:native:/work/iot-ref-kit/openembedded-core/meta/recipes-core/zlib/zlib_1.2.8.bb:do_rm_work 611. ID /work/iot-ref-kit/openembedded-core/meta/recipes-devtools/quilt/quilt-native_0.65.bb:do_rm_work ... DEBUG: completion priorities (most important first): 1. ID /work/iot-ref-kit/openembedded-core/meta/recipes-core/zlib/zlib_1.2.8.bb:do_build 2. ID /work/iot-ref-kit/openembedded-core/meta/recipes-core/zlib/zlib_1.2.8.bb:do_rm_work_all 3. ID /work/iot-ref-kit/openembedded-core/meta/recipes-core/zlib/zlib_1.2.8.bb:do_rm_work 4. ID virtual:native:/work/iot-ref-kit/openembedded-core/meta/recipes-devtools/flex/flex_2.6.2.bb:do_rm_work 5. ID virtual:native:/work/iot-ref-kit/openembedded-core/meta/recipes-core/ncurses/ncurses_6.0+20161126.bb:do_rm_work 6. ID virtual:native:/work/iot-ref-kit/openembedded-core/meta/recipes-graphics/xorg-proto/xproto_7.0.31.bb:do_rm_work 7. ID /work/iot-ref-kit/openembedded-core/meta/recipes-core/glibc/glibc_2.25.bb:do_rm_work 8. ID virtual:native:/work/iot-ref-kit/openembedded-core/meta/recipes-support/popt/popt_1.16.bb:do_rm_work 9. ID /work/iot-ref-kit/openembedded-core/meta/recipes-core/systemd/systemd-systemctl-native.bb:do_rm_work 10. ID virtual:native:/work/iot-ref-kit/openembedded-core/meta/recipes-extended/gperf/gperf_3.0.4.bb:do_rm_work 11. ID /work/iot-ref-kit/openembedded-core/meta/recipes-devtools/gcc/gcc-cross-initial_6.3.bb:do_rm_work 12. ID /work/iot-ref-kit/openembedded-core/meta/recipes-devtools/libtool/libtool-native_2.4.6.bb:do_rm_work 13. ID virtual:native:/work/iot-ref-kit/openembedded-core/meta/recipes-devtools/ossp-uuid/ossp-uuid_1.6.2.bb:do_rm_work 14. ID virtual:native:/work/iot-ref-kit/openembedded-core/meta/recipes-graphics/xorg-util/util-macros_1.19.1.bb:do_rm_work 15. ID virtual:native:/work/iot-ref-kit/openembedded-core/meta/recipes-support/attr/acl_2.2.52.bb:do_rm_work 16. ID virtual:native:/work/iot-ref-kit/openembedded-core/meta/recipes-core/zlib/zlib_1.2.8.bb:do_rm_work 17. ID /work/iot-ref-kit/openembedded-core/meta/recipes-devtools/quilt/quilt-native_0.65.bb:do_rm_work 18. ID virtual:native:/work/iot-ref-kit/openembedded-core/meta/recipes-devtools/opkg-utils/opkg-utils_git.bb:do_rm_work ... That the speed scheduler (aka "original priorities" above) only adds quilt-native_0.65.bb:do_rm_work at the end is a bit unexpected, I thought it added all tasks of a recipe in sequence. As a result of that, the reordered completion priorities do not have quilt-native_0.65.bb:do_rm_work quite as high as it would be otherwise. I don't think it matters in practice, though. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an emp
Re: [OE-core] [PATCH 3/3] rm_work.bbclass: clean up sooner
On Wed, 2017-03-01 at 16:52 +0100, Martin Jansa wrote: > On Thu, Feb 16, 2017 at 11:26:54AM +0100, Patrick Ohly wrote: > > On Wed, 2017-02-15 at 19:32 +0100, Martin Jansa wrote: > > > Are all changes necessary for this to work already in master? > > > > Yes. > > > > > Yesterday I've noticed that rm_work for some components which are > > > early in the dependency (like qtbase) are executed relatively late > > > (together with do_package_qa). > > > > Could do_rm_work run before do_package_qa? rm_work.bbclass doesn't know > > that, and therefore schedules do_rm_work after do_package_qa. > > > > If yes, then adding a list of tasks that can be ignored would be > > trivial. This can be a variable, so a recipe can even add their own > > ones, if necessary. > > That's now what I've meant. > > I believe that rm_work needs to be executed after do_package_qa, but I > don't understand the scheduler code enough (at least not yet) to say > that higher priority of rm_work task also makes all the tasks rm_work > depends on e.g. do_package_qa to be executed sooner. > > From my observation it looked like do_package_qa is still executed > "late", but immediately followed by rm_work thanks to its high priority > (so it's executed as soon as it can, but it's still late in progress of > the whole build). > > Another interesting test from today was to run: > # rm -rf tmp-glibc/* > # bitbake -n zlib | tee log.zlib.rm_work > # cd oe-core; git revert -1 936179754c8d0f98e1196ddc6796fdfd72c0c3b4; cd .. > # rm -rf tmp-glibc/* > # bitbake -n zlib | tee log.zlib.rm_work.revert > > and it shows interesting difference that many rm_work tasks aren't > executed at all: > > # grep rm_work log.zlib.rm_work* | grep zlib_ > log.zlib.rm_work:NOTE: Running task 526 of 527 > (/OE/build/oe-core/openembedded-core/meta/recipes-core/zlib/zlib_1.2.8.bb:do_rm_work) > log.zlib.rm_work.revert:NOTE: Running task 128 of 721 > (virtual:native:/OE/build/oe-core/openembedded-core/meta/recipes-core/zlib/zlib_1.2.8.bb:do_rm_work) > log.zlib.rm_work.revert:NOTE: Running task 717 of 721 > (/OE/build/oe-core/openembedded-core/meta/recipes-core/zlib/zlib_1.2.8.bb:do_rm_work) > log.zlib.rm_work.revert:NOTE: Running task 721 of 721 > (/OE/build/oe-core/openembedded-core/meta/recipes-core/zlib/zlib_1.2.8.bb:do_rm_work_all) > > # grep rm_work log.zlib.rm_work* | grep gcc > log.zlib.rm_work.revert:NOTE: Running task 2 of 721 > (/OE/build/oe-core/openembedded-core/meta/recipes-devtools/gcc/gcc-source_6.3.bb:do_rm_work) > log.zlib.rm_work.revert:NOTE: Running task 240 of 721 > (/OE/build/oe-core/openembedded-core/meta/recipes-devtools/gcc/gcc-cross-initial_6.3.bb:do_rm_work) > log.zlib.rm_work.revert:NOTE: Running task 250 of 721 > (/OE/build/oe-core/openembedded-core/meta/recipes-devtools/gcc/libgcc-initial_6.3.bb:do_rm_work) > log.zlib.rm_work.revert:NOTE: Running task 634 of 721 > (/OE/build/oe-core/openembedded-core/meta/recipes-devtools/gcc/gcc-cross_6.3.bb:do_rm_work) > log.zlib.rm_work.revert:NOTE: Running task 674 of 721 > (/OE/build/oe-core/openembedded-core/meta/recipes-devtools/gcc/libgcc_6.3.bb:do_rm_work) > log.zlib.rm_work.revert:NOTE: Running task 678 of 721 > (/OE/build/oe-core/openembedded-core/meta/recipes-devtools/gcc/gcc-runtime_6.3.bb:do_rm_work) I can reproduce that. The root cause for the current behavior is that zlib:do_build does not depend on zlib-native:do_build and thus does not enable zlib-native:do_rm_work: # bitbake -g zlib # grep -e '->.*zlib-native' task-depends.dot | grep -v '^.zlib-native' "binutils-cross-x86_64.do_prepare_recipe_sysroot" -> "zlib-native.do_populate_sysroot" "rpm-native.do_prepare_recipe_sysroot" -> "zlib-native.do_populate_sysroot" "gcc-cross-initial-x86_64.do_prepare_recipe_sysroot" -> "zlib-native.do_populate_sysroot" "binutils-native.do_prepare_recipe_sysroot" -> "zlib-native.do_populate_sysroot" "gcc-cross-x86_64.do_prepare_recipe_sysroot" -> "zlib-native.do_populate_sysroot" "file-native.do_prepare_recipe_sysroot" -> "zlib-native.do_populate_sysroot" "pigz-native.do_prepare_recipe_sysroot" -> "zlib-native.do_populate_sysroot" "elfutils-native.do_prepare_recipe_sysroot" -> "zlib-native.do_populate_sysroot" "python-native.do_prepare_recipe_sysroot" -> "zlib-native.do_populate_sysroot" "libpcre-native.do_prepare_recipe_sysroot" -> "zlib-native.do_populate_sysroot" Only tasks that are required by the current build target(s) are executed. From that perspective, the current behavior makes se
Re: [OE-core] [PATCHv2] yocto-compat-layer.py: Add script to YP Compatible Layer validation
On Wed, 2017-03-01 at 16:01 +, Richard Purdie wrote: > On Wed, 2017-03-01 at 16:51 +0100, Patrick Ohly wrote: > > On Wed, 2017-03-01 at 15:12 +, Richard Purdie wrote: > > > > > > On Wed, 2017-03-01 at 08:10 +0100, Patrick Ohly wrote: > > > > > > > > Is the "build single distro for different machines" scenario that > > > > I > > > > described part of the Yocto Compliance 2.0? Should there be tests > > > > for > > > > it? > > > Right now its not > > Okay, so the goal is a bit less ambitious than I had thought. I > > wonder > > whether that's useful, because at least the problems Ostro and AGL > > (at > > least as far as I understood it from lurking on their mailing list) > > had > > only happened when trying to combine multiple BSP layers *and* > > actually > > using the different machines in the same distro. > > > > > > > > but I'd consider it. > > At least I'd find that useful - not sure about others ;-} > > I do like the idea, I'm also mindful of walking before running... But bumping the requirements in the Yocto Compliance often will irritate people, because they will have to redo the compliance testing more often. > > > The question is can we write an > > > easy generic test for it, > > It's a bit more complicated than the existing tests, but I think it > > is > > doable. > > > > > > > > and also clearly phrase the criteria in the > > > list of compliance questions with a binary yes/no answer? > > Does the BSP layer only modify machine-specific packages and only > > when > > the MACHINE(s) defined by the BSP layer are selected? [yes/no] > > > > The "only when" part is covered by the existing tests (because they > > keep > > MACHINE constant). The missing part is comparing different MACHINE > > sstamps. > > That seems reasonable, unless the layer in question applying for > compatibility is not a BSP layer but thats a minor detail. > > I'm open to more details on what the test would look like. I guess I now have the AR to write such a test? ;-} -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/3] rm_work.bbclass: clean up sooner
On Wed, 2017-03-01 at 16:52 +0100, Martin Jansa wrote: > On Thu, Feb 16, 2017 at 11:26:54AM +0100, Patrick Ohly wrote: > > On Wed, 2017-02-15 at 19:32 +0100, Martin Jansa wrote: > > > Are all changes necessary for this to work already in master? > > > > Yes. > > > > > Yesterday I've noticed that rm_work for some components which are > > > early in the dependency (like qtbase) are executed relatively late > > > (together with do_package_qa). > > > > Could do_rm_work run before do_package_qa? rm_work.bbclass doesn't know > > that, and therefore schedules do_rm_work after do_package_qa. > > > > If yes, then adding a list of tasks that can be ignored would be > > trivial. This can be a variable, so a recipe can even add their own > > ones, if necessary. > > That's now what I've meant. > > I believe that rm_work needs to be executed after do_package_qa, but I > don't understand the scheduler code enough (at least not yet) to say > that higher priority of rm_work task also makes all the tasks rm_work > depends on e.g. do_package_qa to be executed sooner. I see. do_package_qa should have a high priority, but it's still blocked by its dependencies. Building those dependencies only gets an indirect boost from scheduling recipes that many other recipes depend on first (a feature of the normal scheduler). I suspect the problem with do_package_qa is similar to the problem with do_build before: it depends on do_package_qa of everything a recipe depends on, and thus finishing the build of those other recipes also blocks finishing the current recipe. That creates very deep dependency chains and thus increases the number of recipes which are "in progress" at the same time. > Another interesting test from today was to run: > # rm -rf tmp-glibc/* > # bitbake -n zlib | tee log.zlib.rm_work > # cd oe-core; git revert -1 936179754c8d0f98e1196ddc6796fdfd72c0c3b4; cd .. > # rm -rf tmp-glibc/* > # bitbake -n zlib | tee log.zlib.rm_work.revert > > and it shows interesting difference that many rm_work tasks aren't > executed at all: > > # grep rm_work log.zlib.rm_work* | grep zlib_ > log.zlib.rm_work:NOTE: Running task 526 of 527 > (/OE/build/oe-core/openembedded-core/meta/recipes-core/zlib/zlib_1.2.8.bb:do_rm_work) > log.zlib.rm_work.revert:NOTE: Running task 128 of 721 > (virtual:native:/OE/build/oe-core/openembedded-core/meta/recipes-core/zlib/zlib_1.2.8.bb:do_rm_work) > log.zlib.rm_work.revert:NOTE: Running task 717 of 721 > (/OE/build/oe-core/openembedded-core/meta/recipes-core/zlib/zlib_1.2.8.bb:do_rm_work) > log.zlib.rm_work.revert:NOTE: Running task 721 of 721 > (/OE/build/oe-core/openembedded-core/meta/recipes-core/zlib/zlib_1.2.8.bb:do_rm_work_all) > > # grep rm_work log.zlib.rm_work* | grep gcc > log.zlib.rm_work.revert:NOTE: Running task 2 of 721 > (/OE/build/oe-core/openembedded-core/meta/recipes-devtools/gcc/gcc-source_6.3.bb:do_rm_work) > log.zlib.rm_work.revert:NOTE: Running task 240 of 721 > (/OE/build/oe-core/openembedded-core/meta/recipes-devtools/gcc/gcc-cross-initial_6.3.bb:do_rm_work) > log.zlib.rm_work.revert:NOTE: Running task 250 of 721 > (/OE/build/oe-core/openembedded-core/meta/recipes-devtools/gcc/libgcc-initial_6.3.bb:do_rm_work) > log.zlib.rm_work.revert:NOTE: Running task 634 of 721 > (/OE/build/oe-core/openembedded-core/meta/recipes-devtools/gcc/gcc-cross_6.3.bb:do_rm_work) > log.zlib.rm_work.revert:NOTE: Running task 674 of 721 > (/OE/build/oe-core/openembedded-core/meta/recipes-devtools/gcc/libgcc_6.3.bb:do_rm_work) > log.zlib.rm_work.revert:NOTE: Running task 678 of 721 > (/OE/build/oe-core/openembedded-core/meta/recipes-devtools/gcc/gcc-runtime_6.3.bb:do_rm_work) > > # grep -c rm_work log.zlib.rm_work* > log.zlib.rm_work:1 > log.zlib.rm_work.revert:63 > > I'll check if it's something in my setup or if this happens everywhere now. I'll try to double-check this myself, too. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCHv2] yocto-compat-layer.py: Add script to YP Compatible Layer validation
On Wed, 2017-03-01 at 15:12 +, Richard Purdie wrote: > On Wed, 2017-03-01 at 08:10 +0100, Patrick Ohly wrote: > > Is the "build single distro for different machines" scenario that I > > described part of the Yocto Compliance 2.0? Should there be tests for > > it? > > Right now its not Okay, so the goal is a bit less ambitious than I had thought. I wonder whether that's useful, because at least the problems Ostro and AGL (at least as far as I understood it from lurking on their mailing list) had only happened when trying to combine multiple BSP layers *and* actually using the different machines in the same distro. > but I'd consider it. At least I'd find that useful - not sure about others ;-} > The question is can we write an > easy generic test for it, It's a bit more complicated than the existing tests, but I think it is doable. > and also clearly phrase the criteria in the > list of compliance questions with a binary yes/no answer? Does the BSP layer only modify machine-specific packages and only when the MACHINE(s) defined by the BSP layer are selected? [yes/no] The "only when" part is covered by the existing tests (because they keep MACHINE constant). The missing part is comparing different MACHINE sstamps. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCHv2] yocto-compat-layer.py: Add script to YP Compatible Layer validation
On Wed, 2017-03-01 at 04:00 +, Richard Purdie wrote: > On Tue, 2017-02-28 at 21:09 +0100, Patrick Ohly wrote: > > On Mon, 2017-02-20 at 15:12 -0600, Aníbal Limón wrote: > > > > > > common.test_signatures: Test executed in BSP and DISTRO layers to > > > review > > > doesn't comes with recipes that changes the signatures. > > I have a question about the goal for this test: is it meant to detect > > layers which incorrectly change the signatures of allarch recipes or > > recipes which share the same tune flags with other machines? > > > > Let's take MACHINE=edison as an example. > > The test is not for these things. Its using the sstate signatures for > something different compared to those other tests. > > The idea is that if you have a set of layers and generate the > signatures for world, then you add say a BSP layer but do not select > that MACHINE, the signatures should remain unchanged. That's useful too, of course. Is the "build single distro for different machines" scenario that I described part of the Yocto Compliance 2.0? Should there be tests for it? -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCHv2] yocto-compat-layer.py: Add script to YP Compatible Layer validation
On Tue, 2017-02-28 at 14:33 -0600, Aníbal Limón wrote:
>
> On 02/28/2017 02:09 PM, Patrick Ohly wrote:
> > On Mon, 2017-02-20 at 15:12 -0600, Aníbal Limón wrote:
> >> common.test_signatures: Test executed in BSP and DISTRO layers to review
> >> doesn't comes with recipes that changes the signatures.
> >
> > I have a question about the goal for this test: is it meant to detect
> > layers which incorrectly change the signatures of allarch recipes or
> > recipes which share the same tune flags with other machines?
>
> The requirement is DISTRO and BSP layers aren't allowed to automatically
> change the MACHINE or DISTRO variable that causes the signatures to change.
I do not fully understand this explanation. Can you give an example for
the kind of misbehavior what the test is meant to catch?
> > Let's take MACHINE=edison as an example.
> >
> > Modifying allarch creates a conflict with basically all other machines
> > in a distro. Example for something not allowed:
> > VOLATILE_BINDS_append_pn-volatile-binds_edison = " /var/volatile/foo
> > /var/foo \n"
> >
> > This can be detected by comparing against OE-core, but only when testing
> > with MACHINE=edison.
> >
> > More difficult to detect is modifying recipes with the same tune flags,
> > which is the majority of the recipes. MACHINE=edison and
> > MACHINE=intel-core2-32 both compile for the same target architecture, so
> > something like this is incorrect:
> > do_install_append_pn-base-files_edison () {
> > echo "Built for Edison" >>${D}${sysconfdir}/motd
> > }
> >
> > This can only be detected when testing with both MACHINE=edison and
> > MACHINE=intel-core2-32 - at least I think MACHINE=qemux86 uses different
> > tune flags (haven't checked).
> >
> > My point is, the test probably needs to be extended to run with a set of
> > machines, and that set of machines must be broad enough to cover a
> > variety of common tune flags.
>
> It is expected to change recipe signatures when the machine change, this
> leaves me other question. what signatures are expected to change when
> set a different MACHINE?
Everything that is machine-specific may change, for example image
recipes and kernel (although even that is a slight simplification, as
meta-intel intentionally shares kernels between different MACHINE
configs).
The real-world test is: can two BSP layers be combined in a single
distro so that one can build first for one MACHINE, then the other (or,
when using multiconfig, even in a single build)? If any shared package
changes as result of changing the MACHINE, then that won't work.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCHv2] yocto-compat-layer.py: Add script to YP Compatible Layer validation
On Mon, 2017-02-20 at 15:12 -0600, Aníbal Limón wrote:
> common.test_signatures: Test executed in BSP and DISTRO layers to review
> doesn't comes with recipes that changes the signatures.
I have a question about the goal for this test: is it meant to detect
layers which incorrectly change the signatures of allarch recipes or
recipes which share the same tune flags with other machines?
Let's take MACHINE=edison as an example.
Modifying allarch creates a conflict with basically all other machines
in a distro. Example for something not allowed:
VOLATILE_BINDS_append_pn-volatile-binds_edison = " /var/volatile/foo /var/foo
\n"
This can be detected by comparing against OE-core, but only when testing
with MACHINE=edison.
More difficult to detect is modifying recipes with the same tune flags,
which is the majority of the recipes. MACHINE=edison and
MACHINE=intel-core2-32 both compile for the same target architecture, so
something like this is incorrect:
do_install_append_pn-base-files_edison () {
echo "Built for Edison" >>${D}${sysconfdir}/motd
}
This can only be detected when testing with both MACHINE=edison and
MACHINE=intel-core2-32 - at least I think MACHINE=qemux86 uses different
tune flags (haven't checked).
My point is, the test probably needs to be extended to run with a set of
machines, and that set of machines must be broad enough to cover a
variety of common tune flags.
The corresponding selftest, test_sstate_sametune_samesigs in
sstatetests.py, has the same limitation of its scope, i.e. doesn't
actually test with real machine definitions.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/4] Add dummy tools to help identify needed dependencies
On Tue, 2017-02-28 at 14:35 +0100, Peter Kjellerstedt wrote: > After the introduction of RSS, I still found it hard to get > dependencies on some common tools that are typically installed on the > build host correct. Using the wrong version of tools like pkg-config, > gdbus-codegen and dbus-binding-tool can cause build failures. This is indeed still a problem. I had also discussed this briefly with Richard. We both had the same idea: manipulate the PATH so that instead of the initial paths it only contains a directory with symlinks to tools which are okay to inherit from the build host. In other words, the basic approach would be to whitelist acceptable tools. > To circumvent this, I created dummy versions of the tools that always > fail and placed them in the scripts directory. Thus, if the real tool > has not been installed in the RSS, the dummy version is used and the > build fails. For good measures I even output a message that says what > needs to be corrected in the recipe. This is the other approach: blacklisting tools which are known to be problematic. I suspect the blacklisting approach is going a long way towards solving the problem, but it'll remain uncertain how complete it is. As it is fairly simple, it's probably worth merging until someone has the time to investigate the whitelisting approach further. Richard had some code for it in some of his experimental branches. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] how to *securely* do a remote install of an OE image?
On Tue, 2017-02-28 at 13:32 +0100, Gary Thomas wrote:
> > For ssh keys, there's rootfsdebugfiles.bbclass. In local.conf:
> >
> > INHERIT += "rootfsdebugfiles"
> > ROOTFS_DEBUG_FILES += "/home/pohly/.ssh/id_rsa.pub
> ${IMAGE_ROOTFS}/home/root/.ssh/authorized_keys ;"
> >
> > This copies my id_rsa.pub into authorized_keys and thus let's me log
> > into images that I create via ssh.
> >
>
> Does this work for dropbear or only openssh?
Should also work with dropbear. From
https://matt.ucc.asn.au/dropbear/dropbear.html:
"Compatible with OpenSSH ~/.ssh/authorized_keys public key
authentication"
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] how to *securely* do a remote install of an OE image?
On Tue, 2017-02-28 at 05:28 -0500, Robert P. J. Day wrote:
> my immediate reaction was to use SSH keys, where the
> newly-installed system would require SSH logins, and would have to
> match the corresponding private key.
That would also be my preferred approach.
> as an alternative, perhaps don't worry about such a situation, but
> when the authorized user logs in for what is *supposed* to be the
> first time, it will be flagged that someone else has already logged in
> earlier, and a warning will be printed, "Previous login to root
> detected, you have been compromised, please re-install!"
Or, along the same lines, set an empty root password and force the user
to set a password on the first login. There are ways to do that with
PAM, but I don't have anything at hand.
> i'm sure there are plenty of ways of doing this, anyone have any
> pointers?
For ssh keys, there's rootfsdebugfiles.bbclass. In local.conf:
INHERIT += "rootfsdebugfiles"
ROOTFS_DEBUG_FILES += "/home/pohly/.ssh/id_rsa.pub
${IMAGE_ROOTFS}/home/root/.ssh/authorized_keys ;"
This copies my id_rsa.pub into authorized_keys and thus let's me log
into images that I create via ssh.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] runqemu: avoid overridden user input for bootparams
On Tue, 2017-02-21 at 17:18 +0200, Dmitry Rozhkov wrote: > Currently runqemu hardcodes the "ip=" kernel boot parameter > when configuring QEMU to use tap or slirp networking. This makes > the guest system to have a network interface pre-configured > by kernel and causes systemd to fail renaming the interface > to whatever pleases it: > > Feb 21 10:10:20 intel-corei7-64 systemd-udevd[201]: Error changing > net interface name 'eth0' to 'enp0s3': Device or resource busy, > > Always append user input for kernel boot params after the ones > added by the script. This way user input has priority over runqemu's > default params. Presumably the user's bootparams then would include "ip="? Either way, the change looks good to me. I did something similar for the qemu parameters in "runqemu: let command line parameters override defaults". -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] style suggestions for that whole "_append" and leading space thing
On Mon, 2017-02-27 at 06:07 -0500, Robert P. J. Day wrote:
> getting pedantic (as i am wont to do), occasionally i run across
> things like this, from meta/conf/distro/include/no-static-libs.inc:
>
> EXTRA_OECONF_append = "${DISABLE_STATIC}"
>
> which, at first glance, simply seems wrong given the lack of a leading
> space, until one looks higher up in that same file to read:
>
> DISABLE_STATIC = " --disable-static"
>
> where one finds the leading space as part of the variable itself. i
> find this potentially *really* confusing; consistent style suggests
> variables should be assigned their values without regard as to how
> they might be used later. subsequent references or usages of those
> variables should be responsible for making sure they're included
> properly, no?
In principle you are right, but probably it was done this way here to
avoid adding a space to EXTRA_OECONF in those cases where DISABLE_STATIC
is overridden to be empty. Consider DISABLE_STATIC an implementation
detail and then it becomes okay to set it as needed by the
implementation.
> and the last line in that same file also suggests potential misuse:
>
> EXTRA_OECMAKE_append_pn-libical = "-DSHARED_ONLY=True"
Yes, that's just plain wrong and just happens to work by accident.
> p.s. would the same logic hold with lines like this?
>
> meta/conf/machine/include/tune-ppce6500.inc:
>
> MACHINE_FEATURES_BACKFILL_CONSIDERED_append =
> "${@bb.utils.contains('TUNE_FEATURES', 'e6500', ' qemu-usermode', '',
> d)}"
>
> would it not be clearer if one were to write:
>
> MACHINE_FEATURES_BACKFILL_CONSIDERED_append =
> " ${@bb.utils.contains('TUNE_FEATURES', 'e6500', 'qemu-usermode', '',
> d)}"
The existing line is better because it avoids adding a space when
nothing needs to be added.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Patchwork not picking changes from the ML
On Fri, 2017-02-24 at 15:33 +0100, Gary Thomas wrote: > On 2017-02-24 15:21, Patrick Ohly wrote: > > On Wed, 2017-02-22 at 15:56 -0600, Jose Lamego wrote: > >> > >> On 02/22/2017 02:55 PM, Michael Halstead wrote: > >>> I've seen several issues with hooks. I was working on them yesterday and > >>> will continue today. > >>> > >>> These are currently managed by hand but we are moving them into > >>> configuration management which should help keep them working consistently. > >> > >> Michael: one syntax error in patchwork code was pulled into production > >> yesterday. This is the cause for missing patches. The error is fixed in > >> the Yocto repo now, please perform a server code update ASAP. > >> > >> Martin: I will look at the UI issue you are describing and file a bug if > >> needed. > > > > Would it perhaps make sense to reply to the original author with an > > email confirming that his patch is now in Patchwork? It should include a > > link to the patch series, too. > > > > This could have several advantages: > > * submitters not aware of Patchwork or whether their target > > currently uses it learn about it and then can follow the > > progress of their patch > > * everyone gets a confirmation that the submission made it through > > the various mail servers and Patchwork itself > > > > It still relies on the original submitter to watch out for breakages in > > the processes, but I guess that can't be avoided with an asynchronous, > > mail-based process. > > > > I would love to see this added to the process - +1 :-) Let me clarify that my original proposal was to reply only to the original author. That was meant to keep noise down on the list. However, perhaps it should also go to the list? Then others can help check that Patchwork works, as the original author might not be aware that a response is missing. It also tells everyone the relevant link in Patchwork. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Patchwork not picking changes from the ML
On Wed, 2017-02-22 at 15:56 -0600, Jose Lamego wrote: > > On 02/22/2017 02:55 PM, Michael Halstead wrote: > > I've seen several issues with hooks. I was working on them yesterday and > > will continue today. > > > > These are currently managed by hand but we are moving them into > > configuration management which should help keep them working consistently. > > Michael: one syntax error in patchwork code was pulled into production > yesterday. This is the cause for missing patches. The error is fixed in > the Yocto repo now, please perform a server code update ASAP. > > Martin: I will look at the UI issue you are describing and file a bug if > needed. Would it perhaps make sense to reply to the original author with an email confirming that his patch is now in Patchwork? It should include a link to the patch series, too. This could have several advantages: * submitters not aware of Patchwork or whether their target currently uses it learn about it and then can follow the progress of their patch * everyone gets a confirmation that the submission made it through the various mail servers and Patchwork itself It still relies on the original submitter to watch out for breakages in the processes, but I guess that can't be avoided with an asynchronous, mail-based process. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] ovmf: increase path length limit
The VfrCompile tool has a hard-coded maximum length for path names which turned out to be too small by around 20 characters in the Yocto autobuilder setup. Increasing the maximum by a factor of 4 is relatively easy and makes the problem less likely. Signed-off-by: Patrick Ohly <patrick.o...@intel.com> --- .../VfrCompile-increase-path-length-limit.patch| 33 ++ meta/recipes-core/ovmf/ovmf_git.bb | 1 + 2 files changed, 34 insertions(+) create mode 100644 meta/recipes-core/ovmf/ovmf/VfrCompile-increase-path-length-limit.patch diff --git a/meta/recipes-core/ovmf/ovmf/VfrCompile-increase-path-length-limit.patch b/meta/recipes-core/ovmf/ovmf/VfrCompile-increase-path-length-limit.patch new file mode 100644 index 000..bb12d8b --- /dev/null +++ b/meta/recipes-core/ovmf/ovmf/VfrCompile-increase-path-length-limit.patch @@ -0,0 +1,33 @@ +From c7722d10c7bcf6be0adcf54abb1d406599dd7914 Mon Sep 17 00:00:00 2001 +From: Patrick Ohly <patrick.o...@intel.com> +Date: Fri, 24 Feb 2017 01:40:02 +0100 +Subject: [PATCH] VfrCompile: increase path length limit + +The VfrCompile tool has a hard-coded maximum length for path names +which turned out to be too small by around 20 characters in the Yocto +autobuilder setup. Increasing the maximum by a factor of 4 is +relatively easy and makes the problem less likely. + +Upstream-Status: Inappropriate [configuration] + +Signed-off-by: Patrick Ohly <patrick.o...@intel.com> +--- + BaseTools/Source/C/VfrCompile/EfiVfr.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/BaseTools/Source/C/VfrCompile/EfiVfr.h b/BaseTools/Source/C/VfrCompile/EfiVfr.h +index d187902..9ad4a7b 100644 +--- a/BaseTools/Source/C/VfrCompile/EfiVfr.h b/BaseTools/Source/C/VfrCompile/EfiVfr.h +@@ -19,7 +19,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. + #include "Common/UefiInternalFormRepresentation.h" + #include "Common/MdeModuleHii.h" + +-#define MAX_PATH 255 ++#define MAX_PATH 1023 + #define MAX_VFR_LINE_LEN 4096 + + #define EFI_IFR_MAX_LENGTH 0xFF +-- +2.1.4 + diff --git a/meta/recipes-core/ovmf/ovmf_git.bb b/meta/recipes-core/ovmf/ovmf_git.bb index 6b3a597..a658c9d 100644 --- a/meta/recipes-core/ovmf/ovmf_git.bb +++ b/meta/recipes-core/ovmf/ovmf_git.bb @@ -14,6 +14,7 @@ SRC_URI = "git://github.com/tianocore/edk2.git;branch=master \ file://0001-BaseTools-Force-tools-variables-to-host-toolchain.patch \ file://0002-ovmf-update-path-to-native-BaseTools.patch \ file://0003-BaseTools-makefile-adjust-to-build-in-under-bitbake.patch \ + file://VfrCompile-increase-path-length-limit.patch \ " SRC_URI_append_class-target = " \ -- 2.1.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] ovmf: increase path length limit
On Thu, 2017-02-23 at 18:48 +0100, Patrick Ohly wrote:
> The VfrCompile tool has a hard-coded maximum length for path names
> which turned out to be too small by around 20 characters in the
> Yocto autobuilder setup. Increasing the maximum by a factor of 4
> is relatively easy and makes the problem less likely.
>
> Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
> ---
> meta/recipes-core/ovmf/ovmf_git.bb | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/meta/recipes-core/ovmf/ovmf_git.bb
> b/meta/recipes-core/ovmf/ovmf_git.bb
> index 6b3a597..76e836a 100644
> --- a/meta/recipes-core/ovmf/ovmf_git.bb
> +++ b/meta/recipes-core/ovmf/ovmf_git.bb
> @@ -50,6 +50,11 @@ COMPATIBLE_HOST='(i.86|x86_64).*'
> OVMF_SECURE_BOOT_EXTRA_FLAGS ??= ""
> OVMF_SECURE_BOOT_FLAGS = "-DSECURE_BOOT_ENABLE=TRUE
> ${OVMF_SECURE_BOOT_EXTRA_FLAGS}"
>
> +do_patch[postfuncs] += "fix_path_len"
> +fix_path_len () {
> +sed -i -e 's/^#define MAX_PATH.*255/#define MAX_PATH 1023/'
> ${S}/BaseTools/Source/C/VfrCompile/EfiVfr.h
> +}
I've used sed here because it was easy. I'll also send a version which
uses a proper patch. Just beware of the line encoding issues. The patch
really must have CR line ends, otherwise it won't apply to the source.
It might be safer to pull V2 of the ovmf patch from:
https://github.com/pohly/openembedded-core/commits/ovmf
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] acpica: fix compilation with musl
Manipulating stderr after freopen() fails as done by upstream
does not work with musl. The replacement is Unix specific
and uses open()/dup2().
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/recipes-extended/acpica/acpica_20150515.bb| 1 +
.../files/manipulate-fds-instead-of-FILE.patch | 71 ++
2 files changed, 72 insertions(+)
create mode 100644
meta/recipes-extended/acpica/files/manipulate-fds-instead-of-FILE.patch
diff --git a/meta/recipes-extended/acpica/acpica_20150515.bb
b/meta/recipes-extended/acpica/acpica_20150515.bb
index c23b491..b55f353 100644
--- a/meta/recipes-extended/acpica/acpica_20150515.bb
+++ b/meta/recipes-extended/acpica/acpica_20150515.bb
@@ -19,6 +19,7 @@ DEPENDS = "bison flex"
SRC_URI = "https://acpica.org/sites/acpica/files/acpica-unix2-${PV}.tar.gz \
file://no-werror.patch \
file://rename-yy_scan_string-manually.patch \
+file://manipulate-fds-instead-of-FILE.patch \
"
SRC_URI[md5sum] = "2bc4a7ccc82de9df9fa964f784ecb29c"
SRC_URI[sha256sum] =
"61204ec56d71bc9bfa2ee2ade4c66f7e8541772ac72ef8ccc20b3f339cc96374"
diff --git
a/meta/recipes-extended/acpica/files/manipulate-fds-instead-of-FILE.patch
b/meta/recipes-extended/acpica/files/manipulate-fds-instead-of-FILE.patch
new file mode 100644
index 000..6944bb7
--- /dev/null
+++ b/meta/recipes-extended/acpica/files/manipulate-fds-instead-of-FILE.patch
@@ -0,0 +1,71 @@
+From 33a57979738e5ab13950ec1c0e7298e41ef50929 Mon Sep 17 00:00:00 2001
+From: Patrick Ohly <patrick.o...@intel.com>
+Date: Thu, 23 Feb 2017 18:10:47 +0100
+Subject: [PATCH] aslfiles.c: manipulate fds instead of FILE
+
+Copying what stdout/stderr point to is not portable and fails with
+musl because FILE is an undefined struct.
+
+Instead, use lower-level Unix functions to modify the file that stderr
+writes into. This works on the platforms that Yocto targets.
+
+Upstream-Status: Inappropriate [embedded specific]
+
+Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
+---
+ source/compiler/aslfiles.c | 20 +++-
+ 1 file changed, 11 insertions(+), 9 deletions(-)
+
+diff --git a/source/compiler/aslfiles.c b/source/compiler/aslfiles.c
+index 947e465..7a352b4 100644
+--- a/source/compiler/aslfiles.c
b/source/compiler/aslfiles.c
+@@ -44,6 +44,11 @@
+ #include "aslcompiler.h"
+ #include "acapps.h"
+
++#include
++#include
++#include
++#include
++
+ #define _COMPONENT ACPI_COMPILER
+ ACPI_MODULE_NAME("aslfiles")
+
+@@ -569,6 +574,8 @@ FlOpenMiscOutputFiles (
+
+ if (Gbl_DebugFlag)
+ {
++int fd;
++
+ Filename = FlGenerateFilename (FilenamePrefix, FILE_SUFFIX_DEBUG);
+ if (!Filename)
+ {
+@@ -582,20 +589,15 @@ FlOpenMiscOutputFiles (
+ /* TBD: hide this behind a FlReopenFile function */
+
+ Gbl_Files[ASL_FILE_DEBUG_OUTPUT].Filename = Filename;
+-Gbl_Files[ASL_FILE_DEBUG_OUTPUT].Handle =
+-freopen (Filename, "w+t", stderr);
+-
+-if (!Gbl_Files[ASL_FILE_DEBUG_OUTPUT].Handle)
++fd = open(Filename, O_CREAT|O_TRUNC,
S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH);
++if (fd < 0 ||
++dup2(fd, fileno(stderr)))
+ {
+-/*
+- * A problem with freopen is that on error,
+- * we no longer have stderr.
+- */
+ Gbl_DebugFlag = FALSE;
+-memcpy (stderr, stdout, sizeof (FILE));
+ FlFileError (ASL_FILE_DEBUG_OUTPUT, ASL_MSG_DEBUG_FILENAME);
+ AslAbort ();
+ }
++Gbl_Files[ASL_FILE_DEBUG_OUTPUT].Handle = stderr;
+
+ AslCompilerSignon (ASL_FILE_DEBUG_OUTPUT);
+ AslCompilerFileHeader (ASL_FILE_DEBUG_OUTPUT);
+--
+2.1.4
+
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] ovmf: increase path length limit
The VfrCompile tool has a hard-coded maximum length for path names
which turned out to be too small by around 20 characters in the
Yocto autobuilder setup. Increasing the maximum by a factor of 4
is relatively easy and makes the problem less likely.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/recipes-core/ovmf/ovmf_git.bb | 5 +
1 file changed, 5 insertions(+)
diff --git a/meta/recipes-core/ovmf/ovmf_git.bb
b/meta/recipes-core/ovmf/ovmf_git.bb
index 6b3a597..76e836a 100644
--- a/meta/recipes-core/ovmf/ovmf_git.bb
+++ b/meta/recipes-core/ovmf/ovmf_git.bb
@@ -50,6 +50,11 @@ COMPATIBLE_HOST='(i.86|x86_64).*'
OVMF_SECURE_BOOT_EXTRA_FLAGS ??= ""
OVMF_SECURE_BOOT_FLAGS = "-DSECURE_BOOT_ENABLE=TRUE
${OVMF_SECURE_BOOT_EXTRA_FLAGS}"
+do_patch[postfuncs] += "fix_path_len"
+fix_path_len () {
+sed -i -e 's/^#define MAX_PATH.*255/#define MAX_PATH 1023/'
${S}/BaseTools/Source/C/VfrCompile/EfiVfr.h
+}
+
do_patch_append_class-native() {
bb.build.exec_func('do_fix_iasl', d)
bb.build.exec_func('do_fix_toolchain', d)
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v5 03/12] ovmf: move from meta-luv to OE-core
On Fri, 2017-02-17 at 18:04 -0800, Khem Raj wrote: > On 17-02-17 13:10:56, Richard Purdie wrote: > > On Fri, 2017-01-27 at 16:30 +0100, Patrick Ohly wrote: > > > From: meta-luv <l...@lists.01.org> > > > > > > This is an unmodified copy of > > > github.com/01org/luv-yocto/meta-luv/recipes-core/ovmf revision > > > 4be4329. > > > > https://autobuilder.yocto.io/builders/nightly-world/builds/156 > > > > which boils down to: > > > > | "gcc-ar" cr > > /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-world/build/build/tmp/work/x86-pokymllib32-linux/lib32-ovmf/git-r0/git/Build/OvmfIa32/RELEASE_GCC5/IA32/MdeModulePkg/Library/BootLogoLib/BootLogoLib/OUTPUT/BootLogoLib.lib > > > > @/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-world/build/build/tmp/work/x86-pokymllib32-linux/lib32-ovmf/git-r0/git/Build/OvmfIa32/RELEASE_GCC5/IA32/MdeModulePkg/Library/BootLogoLib/BootLogoLib/OUTPUT/object_files.lst > > | make: *** > > [/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-world/build/build/tmp/work/x86-pokymllib32-linux/lib32-ovmf/git-r0/git/Build/OvmfIa32/RELEASE_GCC5/IA32/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerUiLib/DEBUG/BootMaintenanceManager.c] > > Error 2 > > | VfrCompile: ERROR 1003: Invalid option value > > | VFR file name > > /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-world/build/build/tmp/work/x86-pokymllib32-linux/lib32-ovmf/git-r0/git/Build/OvmfIa32/RELEASE_GCC5/IA32/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerUiLib/OUTPUT/BootMaintenanceManager.i > > is too long. > > | "gcc-ar" cr > > /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-world/build/build/tmp/work/x86-pokymllib32-linux/lib32-ovmf/git-r0/git/Build/OvmfIa32/RELEASE_GCC5/IA32/OvmfPkg/Library/NvVarsFileLib/NvVarsFileLib/OUTPUT/NvVarsFileLib.lib > > > > @/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-world/build/build/tmp/work/x86-pokymllib32-linux/lib32-ovmf/git-r0/git/Build/OvmfIa32/RELEASE_GCC5/IA32/OvmfPkg/Library/NvVarsFileLib/NvVarsFileLib/OUTPUT/object_files.lst > > > > i.e. path length issues. > > > > We saw this on multiple builds :(. > > I wonder why its using gcc-ar that should actually be -gcc-ar > so probably we need to set AR to point to -gcc-ar, but I would > like to see if we can use normal ar since gcc-ar would fail with clang The actual error wasn't in the gcc-ar invocation but rather the VfrCompile tool, so for now I haven't done anything about gcc-ar vs. ar. I have patches for the VfrCompile path length and the acpica+musl issue which I will send momentarily. Richard, Ross, they apply on top of the patches that I had sent earlier. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/6] wic: fix for #11017
On Tue, 2017-02-21 at 17:23 +0200, Ed Bartosh wrote: > This patchset improves handling of wic native tool dependencies and > fixes minor bugs in the wic code. I haven't tested it, but the patches themselves look good to me. Thanks! -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Recipe specific sysroot: handling recipes creating same files
On Mon, 2017-02-20 at 17:08 +, Burton, Ross wrote: > > On 19 February 2017 at 22:04, Andreas Müller > <schnitzelt...@googlemail.com> wrote: > This needs love: One can guess that libldb is trying to > install stuff > already there - nothing mentions samba and the error pops up > for gvfs > which does nothing really wrong. I consider this as bug > introduced by > RSS. > > Yes: without RSS this would result in a fatal error when the second > recipe wrote to the sysroot. Can you file a bug? So it is still considered an error when two recipes produce the same file? One (IMHO valid) use-case for allowing this are configuration packages. You could have a /etc/motd packaged in foo-motd and another in bar-motd with different content, and then build different images where a suitable motd config package is added. With a single sysroot, one had to introduce alternatives, which is more complicated and introduces unnecessary symlinks in read-only images. With RSS, it is possible more easily. Having said that, the error report generated when files overlap in the same real sysroot definitely needs to be improved. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Does recipe specific sysrooot (or whatelse in current oe) break native dependencies?
On Sun, 2017-02-19 at 14:26 -0800, Richard Purdie wrote: > On Tue, 2017-02-14 at 11:26 +0100, Patrick Ohly wrote: > > My testing was flawed: in addition to the RDEPENDS there also was a > > DEPENDS with the same entry, and despite what was said earlier about > > build dependencies, that entry did have an effect. So it is a bit > > more > > complicated. > > > > The way I'd expect this to work for native tools is this: > > 1. DEPENDS should be ignored (build dependencies like compiler > > which are not needed when using the resulting tool) > > Firstly. this is not true at all. Native recipes have build > dependencies just the same as target recipes. Yes, of course. But here I was talking about installing an already built tool in the RSS, and in that case the build dependencies are not always necessary anymore. What I hadn't considered is that there's no packaging and thus also no analysis of ELF files to detect library dependencies. Without that, one has no choice and must install all DEPENDS, even those that only provide build tools that aren't needed anymore. I'm not suggesting to add such packaging. It's another big change and it is not clear whether the reduced size of the resulting sysroots really would outweigh the extra costs and complexity (for example, boot-strapping the ELF analysis). > By comparison RDEPENDS of a native recipe are only needed after its > been compiled and we're about to run it (at least by definition). Let's focus on RDEPENDS. > With a little more digging, I realised that base.bbclass does: > > do_prepare_recipe_sysroot[deptask] = "do_populate_sysroot" > > Note that this is "deptask", not "rdeptask". > > The lack of the "r" means it will work off DEPENDS, not RDEPENDS. So just to be clear, all RDEPENDS* variables are currently ignored when populating the RSS. I think that's what surprised me. Some sort of support for it also in the native case would make sense, because it is cleaner and avoids rebuilding tools when only they runtime dependencies change. We just need to agree on something and then make it work. I propose we use RDEPENDS_$i for i in PACKAGES, because unsetting PACKAGES in native.bbclass when used via BBCLASSEXTEND is a hack that already fails in some cases (like the PACKAGES_prepend that I mentioned earlier) and because it is more consistent with target recipes. To handle that case that a RDEPENDS_foobar pulls in a dependency that is irrelevant because the foobar package would have been empty and skipped if packaging was done, PACKAGES_class-native can be used to set a smaller list. What about RDEPENDS for native-sdk? Does it matter there? Can do_prepare_recipe_sysroot be extended to consider both DEPENDS and RDEPENDS_$i? -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] native.bbclass: populate native recipe with it's files
On Sun, 2017-02-19 at 10:47 -0800, Richard Purdie wrote:
> On Fri, 2017-02-17 at 08:25 +0100, Patrick Ohly wrote:
> > On Thu, 2017-02-16 at 15:46 -0800, Saul Wold wrote:
> > >
> > > This allows a native package's recipe-sysroot-native to be
> > > populated with
> > > that packages native image files. This in turns allows it to be
> > > used by
> > > scripts or other tools without creating un-necessary DEPENDS.
> > >
> > > An example of this is systemtap-native and the crosstap script.
> > The intended usage wasn't clear to me at first. I think it is
> > something
> > like "bitbake foobar-native" and then calling foobar's tools directly
> > from tmp/work/*/foobar-native/*/recipe-sysroot-native (?).
> >
> > If true, then any recipe intending to be used like that also needs to
> > exclude itself from do_rm_work:
> > RM_WORK_EXCLUDE += "${PN}"
> >
> > Or perhaps more selectively exclude the RSS:
> > RM_WORK_EXCLUDE_ITEMS += "recipe-sysroot-native" (is there a variable
> > for this name?)
>
> I've been idly wondering whether just excluding recipe-sysroot* from
> rm_work might be useful since its mostly hardlinked files anyway and
> likely doesn't cause too much of a space issue...
It might still be useful to remove even the hardlinks, to spread out the
IO required to clean up after a build - "rm -rf tmp" can take a long
time. But I haven't measured how much of a difference rm_work makes in
this case.
Regarding Saul's patch: I've used it together with devtool to build and
debug a native tool. After "devtool build foo-native" one cannot
actually run foo because it is not installed in a sysroot. "bitbake
foo-native:do_addto_recipe_sysroot" fixes that. I also enabled debug
information and prevented native sysroot stripping for this particular
use-case. I'll probably file an enhancement request for devtool about
this...
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v5 03/12] ovmf: move from meta-luv to OE-core
Hello Ricardo, another issue with the UEFI recipes. See also Khem's comment (attached). Bye, Patrick On Fri, 2017-02-17 at 13:10 -0800, Richard Purdie wrote: > On Fri, 2017-01-27 at 16:30 +0100, Patrick Ohly wrote: > > From: meta-luv <l...@lists.01.org> > > > > This is an unmodified copy of > > github.com/01org/luv-yocto/meta-luv/recipes-core/ovmf revision > > 4be4329. > > https://autobuilder.yocto.io/builders/nightly-world/builds/156 > > which boils down to: > > | "gcc-ar" cr > /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-world/build/build/tmp/work/x86-pokymllib32-linux/lib32-ovmf/git-r0/git/Build/OvmfIa32/RELEASE_GCC5/IA32/MdeModulePkg/Library/BootLogoLib/BootLogoLib/OUTPUT/BootLogoLib.lib > > @/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-world/build/build/tmp/work/x86-pokymllib32-linux/lib32-ovmf/git-r0/git/Build/OvmfIa32/RELEASE_GCC5/IA32/MdeModulePkg/Library/BootLogoLib/BootLogoLib/OUTPUT/object_files.lst > | make: *** > [/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-world/build/build/tmp/work/x86-pokymllib32-linux/lib32-ovmf/git-r0/git/Build/OvmfIa32/RELEASE_GCC5/IA32/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerUiLib/DEBUG/BootMaintenanceManager.c] > Error 2 > | VfrCompile: ERROR 1003: Invalid option value > | VFR file name > /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-world/build/build/tmp/work/x86-pokymllib32-linux/lib32-ovmf/git-r0/git/Build/OvmfIa32/RELEASE_GCC5/IA32/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerUiLib/OUTPUT/BootMaintenanceManager.i > is too long. > | "gcc-ar" cr > /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-world/build/build/tmp/work/x86-pokymllib32-linux/lib32-ovmf/git-r0/git/Build/OvmfIa32/RELEASE_GCC5/IA32/OvmfPkg/Library/NvVarsFileLib/NvVarsFileLib/OUTPUT/NvVarsFileLib.lib > > @/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-world/build/build/tmp/work/x86-pokymllib32-linux/lib32-ovmf/git-r0/git/Build/OvmfIa32/RELEASE_GCC5/IA32/OvmfPkg/Library/NvVarsFileLib/NvVarsFileLib/OUTPUT/object_files.lst > > i.e. path length issues. > > We saw this on multiple builds :(. > > Cheers, > > Richard --- Begin Message --- On 17-02-17 13:10:56, Richard Purdie wrote: > On Fri, 2017-01-27 at 16:30 +0100, Patrick Ohly wrote: > > From: meta-luv <l...@lists.01.org> > > > > This is an unmodified copy of > > github.com/01org/luv-yocto/meta-luv/recipes-core/ovmf revision > > 4be4329. > > https://autobuilder.yocto.io/builders/nightly-world/builds/156 > > which boils down to: > > | "gcc-ar" cr > /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-world/build/build/tmp/work/x86-pokymllib32-linux/lib32-ovmf/git-r0/git/Build/OvmfIa32/RELEASE_GCC5/IA32/MdeModulePkg/Library/BootLogoLib/BootLogoLib/OUTPUT/BootLogoLib.lib > > @/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-world/build/build/tmp/work/x86-pokymllib32-linux/lib32-ovmf/git-r0/git/Build/OvmfIa32/RELEASE_GCC5/IA32/MdeModulePkg/Library/BootLogoLib/BootLogoLib/OUTPUT/object_files.lst > | make: *** > [/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-world/build/build/tmp/work/x86-pokymllib32-linux/lib32-ovmf/git-r0/git/Build/OvmfIa32/RELEASE_GCC5/IA32/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerUiLib/DEBUG/BootMaintenanceManager.c] > Error 2 > | VfrCompile: ERROR 1003: Invalid option value > | VFR file name > /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-world/build/build/tmp/work/x86-pokymllib32-linux/lib32-ovmf/git-r0/git/Build/OvmfIa32/RELEASE_GCC5/IA32/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerUiLib/OUTPUT/BootMaintenanceManager.i > is too long. > | "gcc-ar" cr > /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-world/build/build/tmp/work/x86-pokymllib32-linux/lib32-ovmf/git-r0/git/Build/OvmfIa32/RELEASE_GCC5/IA32/OvmfPkg/Library/NvVarsFileLib/NvVarsFileLib/OUTPUT/NvVarsFileLib.lib > > @/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-world/build/build/tmp/work/x86-pokymllib32-linux/lib32-ovmf/git-r0/git/Build/OvmfIa32/RELEASE_GCC5/IA32/OvmfPkg/Library/NvVarsFileLib/NvVarsFileLib/OUTPUT/object_files.lst > > i.e. path length issues. > > We saw this on multiple builds :(. I wonder why its using gcc-ar that should actually be -gcc-ar so probably we need to set AR to point to -gcc-ar, but I would like to see if we can use normal ar since gcc-ar would fail with clang --- End Message --- -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v5 01/12] acpica: move from meta-oe to OE-core
Hello Ricardo,
can you perhaps help?
I'm traveling next week and don't have much time.
Thanks, Patrick
On Fri, 2017-02-17 at 13:13 -0800, Richard Purdie wrote:
> On Fri, 2017-01-27 at 16:30 +0100, Patrick Ohly wrote:
> > From: Fathi Boudra <fathi.bou...@linaro.org>
> >
> > qemu support for UEFI in OE-core depends on OVMF, which needs the
> > iasl
> > tools provided by this recipe. There's also an iasl recipe in
> > meta-luv, but than can and will be replaced by this one, thus
> > reducing
> > overall maintenance work.
> >
> > Copied from meta-openembedded rev fa65be9ba (current master).
> >
> > Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
>
> This fails on musl:
>
> https://autobuilder.yocto.io/builders/nightly-musl/builds/160/steps/BuildImages/logs/stdio
>
> | ^~
> | i586-poky-linux-musl-gcc -m32 -march=i586
> --sysroot=/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-musl/build/build/tmp/work/i586-poky-linux-musl/acpica/20150515-r0/recipe-sysroot
> -c -O2 -pipe -g -feliminate-unused-debug-types
> -fdebug-prefix-map=/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-musl/build/build/tmp/work/i586-poky-linux-musl/acpica/20150515-r0=/usr/src/debug/acpica/20150515-r0
>
> -fdebug-prefix-map=/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-musl/build/build/tmp/work/i586-poky-linux-musl/acpica/20150515-r0/recipe-sysroot-native=
>
> -fdebug-prefix-map=/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-musl/build/build/tmp/work/i586-poky-linux-musl/acpica/20150515-r0/recipe-sysroot=
> -D_CYGWIN -D_GNU_SOURCE -I../../../source/include -D_CYGWIN -D_GNU_SOURCE
> -I../../../source/include -DACPI_ASL_COMPILER -I../../../source/compiler
> -Iobj -Wall -o obj/asllistsup.o ../../../source/compiler/asllistsup.c
> | ../../../source/compiler/aslfiles.c: In function 'FlOpenMiscOutputFiles':
> | ../../../source/compiler/aslfiles.c:595:45: error: invalid application of
> 'sizeof' to incomplete type 'FILE {aka struct _IO_FILE}'
> | memcpy (stderr, stdout, sizeof (FILE));
> | ^~~~
> | Copied obj/acpiexamples to ../bin/acpiexamples
>
> Cheers,
>
> Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libarchive: fix bzip2 dependency for native build
When DEPENDS=bzip2 becomes bzip2-native in libarchive-native,
the dependency ends up getting ignored because bzip2-native
is in ASSUME_PROVIDED.
But we need the library and thus have to depend on
bzip2-replacement-native, otherwise the build proceeds
without it despite the explicit --with-bz2lib.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/recipes-extended/libarchive/libarchive_3.2.2.bb | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-extended/libarchive/libarchive_3.2.2.bb
b/meta/recipes-extended/libarchive/libarchive_3.2.2.bb
index 8ad62ad..a7c1204 100644
--- a/meta/recipes-extended/libarchive/libarchive_3.2.2.bb
+++ b/meta/recipes-extended/libarchive/libarchive_3.2.2.bb
@@ -18,11 +18,14 @@ PACKAGECONFIG_append_class-target = "\
PACKAGECONFIG_append_class-nativesdk = " largefile"
+DEPENDS_BZIP2 = "bzip2-replacement-native"
+DEPENDS_BZIP2_class-target = "bzip2"
+
PACKAGECONFIG[acl] = "--enable-acl,--disable-acl,acl,"
PACKAGECONFIG[xattr] = "--enable-xattr,--disable-xattr,attr,"
PACKAGECONFIG[largefile] = "--enable-largefile,--disable-largefile,,"
PACKAGECONFIG[zlib] = "--with-zlib,--without-zlib,zlib,"
-PACKAGECONFIG[bz2] = "--with-bz2lib,--without-bz2lib,bzip2,"
+PACKAGECONFIG[bz2] = "--with-bz2lib,--without-bz2lib,${DEPENDS_BZIP2},"
PACKAGECONFIG[xz] = "--with-lzmadec --with-lzma,--without-lzmadec
--without-lzma,xz,"
PACKAGECONFIG[openssl] = "--with-openssl,--without-openssl,openssl,"
PACKAGECONFIG[libxml2] = "--with-xml2,--without-xml2,libxml2,"
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Running task for all recipes required by an image (was Re: [PATCH v2 3/3] rm_work.bbclass: clean up sooner)
On Fri, 2017-02-17 at 15:21 +, Mike Crowe wrote: > On Monday 13 February 2017 at 11:54:32 +0100, Patrick Ohly wrote: > > On Fri, 2017-02-10 at 18:32 +, Mike Crowe wrote: > > > On Thursday 09 February 2017 at 17:24:39 +0100, Patrick Ohly wrote: > > > > On Wed, 2017-02-08 at 13:48 +, Mike Crowe wrote: > > > > > On Wednesday 08 February 2017 at 14:04:42 +0100, Patrick Ohly wrote: > > > The part I'd missed is the all-important line in source-release-world.bb: > > > > > > do_source_release[depends] += "core-image-sato:do_build" > > > > Okay, that explains it. > > > > IMHO this do_build dependency should trigger do_rm_work. Your "bitbake > > -c all_source_releases source-release-world" intentionally includes a > > real world build, not just executing the source release tasks. Cleaning > > up while building is the goal of rm_work.bbclass. It's arguably a > > deficiency in the previous rm_work.bbclass that it wasn't active in your > > case. > > > > Now we just need to find a way to combine these without breaking the > > extra tasks. > > Now I think about this further, we're only depending on do_build in order > to ensure that we get all the dependencies included in the source release > via the recrdeps task. If there were a better way to do that then perhaps > rm_work wouldn't cause any problems, and we also wouldn't waste time > building stuff that we aren't going to use. Isn't that exactly what do_fetchall does? I thought you wanted to build things as part of your source-release-world. If that isn't needed, then this in release-source.bbclass might work: do_all_source_releases[recrdeptask] = "do_all_source_releases do_source_release" do_all_source_releases[recideptask] = "do_build" And used like this: bitbake -c all_source_releases core-image-sato -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] native.bbclass: populate native recipe with it's files
On Thu, 2017-02-16 at 15:46 -0800, Saul Wold wrote:
> This allows a native package's recipe-sysroot-native to be populated with
> that packages native image files. This in turns allows it to be used by
> scripts or other tools without creating un-necessary DEPENDS.
>
> An example of this is systemtap-native and the crosstap script.
The intended usage wasn't clear to me at first. I think it is something
like "bitbake foobar-native" and then calling foobar's tools directly
from tmp/work/*/foobar-native/*/recipe-sysroot-native (?).
If true, then any recipe intending to be used like that also needs to
exclude itself from do_rm_work:
RM_WORK_EXCLUDE += "${PN}"
Or perhaps more selectively exclude the RSS:
RM_WORK_EXCLUDE_ITEMS += "recipe-sysroot-native" (is there a variable
for this name?)
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/3] rm_work.bbclass: clean up sooner
On Wed, 2017-02-15 at 19:32 +0100, Martin Jansa wrote:
> Are all changes necessary for this to work already in master?
Yes.
> Yesterday I've noticed that rm_work for some components which are
> early in the dependency (like qtbase) are executed relatively late
> (together with do_package_qa).
Could do_rm_work run before do_package_qa? rm_work.bbclass doesn't know
that, and therefore schedules do_rm_work after do_package_qa.
If yes, then adding a list of tasks that can be ignored would be
trivial. This can be a variable, so a recipe can even add their own
ones, if necessary.
> So I've tried very naive way to find out if the rm_work tasks are
> executed sooner or not just by comparing Task IDs in build of the same
> image built from scratch (without sstate) with Dizzy, Morty and
> current master.
Interesting, I hadn't thought of testing it like that.
> If we dismiss the strange case in rm_work.tasks.master.qemux86 then it
> seems to perform at least as good as old completion BB_SCHEDULER.
>
>
> But I wanted to ask if there is something else we can do or you were
> planing to do, because IIRC you shared some longer analysis of what
> could be improved here and I'm not sure if you managed to implement it
> all.
The other ideas that I mentioned at some point didn't pan out as
intended. In particular allowing do_rm_work tasks to run when the normal
task limit was reached didn't have a big effect and the implementation
was a hack, so I dropped that.
> It feels to me that rm_work has high priority, but still it's
> "blocked" by e.g. do_package_qa which gets executed late and then
> immediately followed by rm_work.
That should be easy to change, perhaps like this (untested):
RM_WORK_TASKS_WHITELIST = "do_build do_package_qa"
deps = set(bb.build.preceedtask('do_build', True, d))
whitelist = d.getVar('RM_WORK_TASKS_WHITELIST').split()
deps.difference_update(whitelist)
# In practice, addtask() here merely updates the dependencies.
bb.build.addtask('do_rm_work', 'do_build', ' '.join(deps), d)
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] how to select for non-volatile /var/log?
On Tue, 2017-02-14 at 10:12 -0500, Robert P. J. Day wrote: > On Tue, 14 Feb 2017, Patrick Ohly wrote: > > > On Tue, 2017-02-14 at 09:31 -0500, Robert P. J. Day wrote: > > > i recall, once upon a time, a discussion of how to best support a > > > non-volatile /var/log directory: > > > > > > https://patchwork.openembedded.org/patch/90151/ > > > > A more recent, but also still unmerged patch for this functionality > > is here: https://patchwork.openembedded.org/patch/90839/ > > "more recent" would appear to be a relative term, since the date on > that is may of 2015. It was reposted late last year, I just didn't pick the more recent entry in patchwork. Here's the current one: https://patchwork.openembedded.org/series/4028/ > it seems that this topic comes up every so often, > then just dies. so is there any *current* discussion to add this > feature? be nice if this issue was just resolved, one way or the > other. Fully agreed. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] multipath-tools on arm (was: Re: State of bitbake world, Failed tasks 2017-02-08)
On Fri, 2017-02-10 at 09:28 +0100, Martin Jansa wrote:
> *
> meta-openembedded/meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb:do_compile
This is http://errors.yoctoproject.org/Errors/Details/130529/ and now
blacklisted with the comment "Fails to build with RSS
http://errors.yoctoproject.org/Errors/Details/130529/;
However, the error isn't about RSS. It looks like an inline-assembler or
compiler bug:
{standard input}: Assembler messages:
{standard input}:80: Error: shifts in CMP/MOV instructions are only supported
in unified syntax -- `mov r12,r12,ror#3'
{standard input}:80: Error: shifts in CMP/MOV instructions are only supported
in unified syntax -- `mov r12,r12,ror#13'
...
../Makefile.inc:66: recipe for target 'debug.o' failed
make[1]: *** [debug.o] Error 1
Does anyone know what this could be? I'll also fire up a build in the
meantime.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] how to select for non-volatile /var/log?
On Tue, 2017-02-14 at 09:31 -0500, Robert P. J. Day wrote: > i recall, once upon a time, a discussion of how to best support a > non-volatile /var/log directory: > > https://patchwork.openembedded.org/patch/90151/ A more recent, but also still unmerged patch for this functionality is here: https://patchwork.openembedded.org/patch/90839/ -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Does recipe specific sysrooot (or whatelse in current oe) break native dependencies?
On Mon, 2017-02-13 at 18:03 +0100, Patrick Ohly wrote:
> On Mon, 2017-02-13 at 16:24 +0100, Patrick Ohly wrote:
> > On Mon, 2017-02-13 at 15:36 +0100, Martin Jansa wrote:
> > > Hi Andreas,
> > >
> > >
> > > I think it's feature which was already there, but almost never
> > > triggered (even in test-dependencies.sh tests), but with RSS it fails
> > > reliably.
> > >
> > >
> > > See:
> > > http://lists.openembedded.org/pipermail/openembedded-core/2016-July/124435.html
> >
> > That's not quite the same, if I understand it correctly. In that email,
> > Richard was talking about "dependencies of that target are not needed
> > and not installed" and used "quilt-native" and "compiler/toolchain" as
> > example. In other words, if recipe foo DEPENDS on bar for getting foo
> > compiled, that dependency on bar gets ignored when installing "foo" into
> > the recipe specific sysroot because it shouldn't be needed anymore.
> >
> > But the example here is a recipe foo which has a runtime dependency on
> > bar, so bar must be installed in addition to foo, otherwise foo will not
> > work.
> >
> > This is where it gets tricky: do native recipes have RDEPENDS? They are
> > not getting packaged, so I suppose not. One could collect all RDEPENDS_*
> > values (regardless of the actual package), but that might be too broad
> > (for example, when "packaging" the native recipe wouldn't even produce
> > that package).
>
> Apparently RDEPENDS do work, also for native recipes. Based on some
> testing, it seems that all RDEPENDS are considered, even those that
> refer to packages that would normally be empty, i.e. the sysroot
> potentially contains more than strictly needed, but that shouldn't be a
> problem.
My testing was flawed: in addition to the RDEPENDS there also was a
DEPENDS with the same entry, and despite what was said earlier about
build dependencies, that entry did have an effect. So it is a bit more
complicated.
The way I'd expect this to work for native tools is this:
1. DEPENDS should be ignored (build dependencies like compiler
which are not needed when using the resulting tool)
2. RDEPENDS_${PN} needs to be used (essential runtime dependencies,
set the same way as for the target recipes, because then
BBCLASSEXTEND native mostly works automatically)
3. RDEPENDS_foo for foo != ${PN} is *not* used - that's basically a
convention, and addresses the issue I mentioned where it is
unclear for a native recipe whether it really has such a package
But the actual implementation isn't quite doing this. Instead,
extend_recipe_sysroot() in staging.bbclass and setscene_depvalid() in
sstate.bbclass look at the task dependencies.
Here's an example, using Poky e758547db = current master:
$ bitbake wic-tools
...
$ grep gettext
tmp/work/i586-poky-linux/wic-tools/1.0-r0/temp/log.do_prepare_recipe_sysroot
Considering setscene task: ['gettext-native', 'do_populate_sysroot']
considering dependency: ['gettext-native', 'do_populate_sysroot']
Skipping setscene dependency
virtual:native:/work/poky/meta/recipes-core/gettext/gettext_0.19.8.1.bb:do_populate_sysroot
for installation into the sysroot
...
$ find tmp/work/i586-poky-linux/wic-tools/1.0-r0/recipe-sysroot-native/
-name gettext
tmp/work/i586-poky-linux/wic-tools/1.0-r0/recipe-sysroot-native/usr/share/gettext
tmp/work/i586-poky-linux/wic-tools/1.0-r0/recipe-sysroot-native/installeddeps/gettext
"gettext" is not installed.
Let's add it to RDEPENDS_${PN} of dosfstools-native, one of the
dependencies of wic-tools:
$ echo 'RDEPENDS_dosfstools-native_append_pn-dosfstools-native = "
gettext-native"' >conf/auto.conf
$ bitbake -e dosfstools-native | grep ^RDEPENDS
RDEPENDS_dosfstools-native="gettext-native"
RDEPENDS=""
RDEPENDS_kernel-base=""
RDEPENDS_dosfstools-native-staticdev="dosfstools-native-dev (= 4.1-r0)"
RDEPENDS_dosfstools-native-dev="dosfstools-native (= 4.1-r0)"
First observation: "bitbake wic-tools:do_prepare_recipe_sysroot" does
not run again. But even forcing it to run again doesn't change anything,
i.e. either "gettext-native" in RDEPENDS_dosfstools-native or
RDEPENDS_dosfstools-native are ignored.
Let's compare adding something new to RDEPENDS vs. DEPENDS:
$ echo 'DEPENDS_append_pn-dosfstools-native = " socat-native"' >conf/auto.conf
$ bitbake -g wic-tools
$ grep -e '->.*socat-native.do_populate_sysroot' task-depends.dot
"dosfstools-native.do_prepare_recipe_sysroot" ->
"socat-native.do_populate_sysroot"
$ echo 'RDEPENDS_dosfstools-native_append_pn-dosfstools-native = "
gettext-native"' >c
Re: [OE-core] Does recipe specific sysrooot (or whatelse in current oe) break native dependencies?
On Mon, 2017-02-13 at 18:03 +0100, Patrick Ohly wrote:
> On Mon, 2017-02-13 at 16:24 +0100, Patrick Ohly wrote:
> > On Mon, 2017-02-13 at 15:36 +0100, Martin Jansa wrote:
> > > Hi Andreas,
> > >
> > >
> > > I think it's feature which was already there, but almost never
> > > triggered (even in test-dependencies.sh tests), but with RSS it fails
> > > reliably.
> > >
> > >
> > > See:
> > > http://lists.openembedded.org/pipermail/openembedded-core/2016-July/124435.html
> >
> > That's not quite the same, if I understand it correctly. In that email,
> > Richard was talking about "dependencies of that target are not needed
> > and not installed" and used "quilt-native" and "compiler/toolchain" as
> > example. In other words, if recipe foo DEPENDS on bar for getting foo
> > compiled, that dependency on bar gets ignored when installing "foo" into
> > the recipe specific sysroot because it shouldn't be needed anymore.
> >
> > But the example here is a recipe foo which has a runtime dependency on
> > bar, so bar must be installed in addition to foo, otherwise foo will not
> > work.
> >
> > This is where it gets tricky: do native recipes have RDEPENDS? They are
> > not getting packaged, so I suppose not. One could collect all RDEPENDS_*
> > values (regardless of the actual package), but that might be too broad
> > (for example, when "packaging" the native recipe wouldn't even produce
> > that package).
>
> Apparently RDEPENDS do work, also for native recipes. Based on some
> testing, it seems that all RDEPENDS are considered, even those that
> refer to packages that would normally be empty, i.e. the sysroot
> potentially contains more than strictly needed, but that shouldn't be a
> problem.
>
> Andreas, does adding RDEPENDS instead of (or, where needed, in addition
> to) DEPENDS fix you problem?
... and to avoid confusion: I meant adding gettext to RDEPEND_${PN} in
kdoctools, not adding it to every recipe which uses kdoctools.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Does recipe specific sysrooot (or whatelse in current oe) break native dependencies?
On Mon, 2017-02-13 at 16:24 +0100, Patrick Ohly wrote: > On Mon, 2017-02-13 at 15:36 +0100, Martin Jansa wrote: > > Hi Andreas, > > > > > > I think it's feature which was already there, but almost never > > triggered (even in test-dependencies.sh tests), but with RSS it fails > > reliably. > > > > > > See: > > http://lists.openembedded.org/pipermail/openembedded-core/2016-July/124435.html > > That's not quite the same, if I understand it correctly. In that email, > Richard was talking about "dependencies of that target are not needed > and not installed" and used "quilt-native" and "compiler/toolchain" as > example. In other words, if recipe foo DEPENDS on bar for getting foo > compiled, that dependency on bar gets ignored when installing "foo" into > the recipe specific sysroot because it shouldn't be needed anymore. > > But the example here is a recipe foo which has a runtime dependency on > bar, so bar must be installed in addition to foo, otherwise foo will not > work. > > This is where it gets tricky: do native recipes have RDEPENDS? They are > not getting packaged, so I suppose not. One could collect all RDEPENDS_* > values (regardless of the actual package), but that might be too broad > (for example, when "packaging" the native recipe wouldn't even produce > that package). Apparently RDEPENDS do work, also for native recipes. Based on some testing, it seems that all RDEPENDS are considered, even those that refer to packages that would normally be empty, i.e. the sysroot potentially contains more than strictly needed, but that shouldn't be a problem. Andreas, does adding RDEPENDS instead of (or, where needed, in addition to) DEPENDS fix you problem? -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Does recipe specific sysrooot (or whatelse in current oe) break native dependencies?
On Mon, 2017-02-13 at 16:32 +0100, Martin Jansa wrote: > On Mon, Feb 13, 2017 at 04:24:15PM +0100, Patrick Ohly wrote: > > On Mon, 2017-02-13 at 15:36 +0100, Martin Jansa wrote: > > > Hi Andreas, > > > > > > > > > I think it's feature which was already there, but almost never > > > triggered (even in test-dependencies.sh tests), but with RSS it fails > > > reliably. > > > > > > > > > See: > > > http://lists.openembedded.org/pipermail/openembedded-core/2016-July/124435.html > > > > That's not quite the same, if I understand it correctly. In that email, > > Richard was talking about "dependencies of that target are not needed > > and not installed" and used "quilt-native" and "compiler/toolchain" as > > example. In other words, if recipe foo DEPENDS on bar for getting foo > > compiled, that dependency on bar gets ignored when installing "foo" into > > the recipe specific sysroot because it shouldn't be needed anymore. > > I'm not sure if it's the same or not, but back then I got very rarely > missing dependency on wayland-native or qtwayland-native, now with RSS I > got 20-30 recipes failing because of missing dependency on > wayland-native, qtwayland-native or qtbase-native to stage the scanner, > moc and other native tools in recipe-sysroot-native. > > And Andreas issues look similar to that. I'm sure Andreas can clarify, but "kdoctools which depends on gettext-native" sounds like a runtime-dependency to me (but I'm just guessing that kdoctools wraps gettext, I don't really know). -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Does recipe specific sysrooot (or whatelse in current oe) break native dependencies?
On Mon, 2017-02-13 at 15:36 +0100, Martin Jansa wrote: > Hi Andreas, > > > I think it's feature which was already there, but almost never > triggered (even in test-dependencies.sh tests), but with RSS it fails > reliably. > > > See: > http://lists.openembedded.org/pipermail/openembedded-core/2016-July/124435.html That's not quite the same, if I understand it correctly. In that email, Richard was talking about "dependencies of that target are not needed and not installed" and used "quilt-native" and "compiler/toolchain" as example. In other words, if recipe foo DEPENDS on bar for getting foo compiled, that dependency on bar gets ignored when installing "foo" into the recipe specific sysroot because it shouldn't be needed anymore. But the example here is a recipe foo which has a runtime dependency on bar, so bar must be installed in addition to foo, otherwise foo will not work. This is where it gets tricky: do native recipes have RDEPENDS? They are not getting packaged, so I suppose not. One could collect all RDEPENDS_* values (regardless of the actual package), but that might be too broad (for example, when "packaging" the native recipe wouldn't even produce that package). -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 3/3] rm_work.bbclass: clean up sooner
On Mon, 2017-02-13 at 12:19 +, Mike Crowe wrote: > On Monday 13 February 2017 at 11:54:32 +0100, Patrick Ohly wrote: > > To me it seems like the right solution. Inheriting > > release-source.bbclass could be limited to builds which produce > > releases, for example in your CI setup, then normal developers will not > > be affected. > > At the moment it is straightforward to build the source release with a > simple bitbake invocation. > > Your solution would work, but it would be necessary to meddle with > local.conf or similar in order to generate the source release. There is conf/auto.conf for that. local.conf can stay unmodified. Alternatively, you could also introduce an environment variable which controls whether release-source.bbclass gets inherited. Add that variable to the BB_ENV_EXTRAWHITE in your local.conf.sample and builds with or without the class could be as simple as: RELEASE_SOURCE=1 bitbake ... > Is there any way we can get our tasks in as predecessors of rm_work only if > they would have run anyway? Rather like the way make(1) supports order-only > prerequisites[1]? No, I don't think there is such a dependency in bitbake, and I'm not convinced that the usecase justifies the extra complexity. It might "feel" natural to use the "addtask before" as such a weaker ordering relationship and the "addtask after" as the stronger "must run dependency" relationship, but that's just not the current semantic and changing it probably would break too much. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 3/3] rm_work.bbclass: clean up sooner
On Fri, 2017-02-10 at 18:32 +, Mike Crowe wrote: > On Thursday 09 February 2017 at 17:24:39 +0100, Patrick Ohly wrote: > > On Wed, 2017-02-08 at 13:48 +, Mike Crowe wrote: > > > On Wednesday 08 February 2017 at 14:04:42 +0100, Patrick Ohly wrote: > The part I'd missed is the all-important line in source-release-world.bb: > > do_source_release[depends] += "core-image-sato:do_build" Okay, that explains it. IMHO this do_build dependency should trigger do_rm_work. Your "bitbake -c all_source_releases source-release-world" intentionally includes a real world build, not just executing the source release tasks. Cleaning up while building is the goal of rm_work.bbclass. It's arguably a deficiency in the previous rm_work.bbclass that it wasn't active in your case. Now we just need to find a way to combine these without breaking the extra tasks. > > It seems unsafe to have tasks that are not properly ordered and just > > rely on not activating them in the same build, but without understanding > > the problem better it is too early to look for a solution. > > Thanks for investigating. If you're still having trouble then I have a > single patch on top of current oe-core master that reproduces it for me > that I can send. I can reproduce it. As you said earlier, adding "before do_rm_work" solves the problem: addtask source_release before do_rm_work That's okay, even when rm_work.bbclass does not get inherited. However, when rm_work.bbclass, a "normal" build like "bitbake menu-cache" ends up triggering the source_release task: $ bitbake -g menu-cache ... $ grep do_rm_work task-depends.dot | grep do_source_release | grep menu-cache "menu-cache.do_rm_work" -> "menu-cache.do_source_release" Is that acceptable for you? To me it seems like the right solution. Inheriting release-source.bbclass could be limited to builds which produce releases, for example in your CI setup, then normal developers will not be affected. With that in mind, you could also just do: addtask source_release before do_build And then build with: bitbake world (or your image) That seems simpler than the construct with do_all_source_releases and the special source-release-world.bb. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] rootfspostcommands: remove shadow backup files instead of trying to sort
Backup are files sometimes are inconsistent and then cannot be
sorted (YOCTO #11043), and more importantly, are not needed in
the initial rootfs, so they get deleted.
Fixes: [YOCTO #11007]
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/lib/rootfspostcommands.py | 28
1 file changed, 20 insertions(+), 8 deletions(-)
diff --git a/meta/lib/rootfspostcommands.py b/meta/lib/rootfspostcommands.py
index 6a9b8b4..4742e06 100644
--- a/meta/lib/rootfspostcommands.py
+++ b/meta/lib/rootfspostcommands.py
@@ -29,16 +29,28 @@ def sort_file(filename, mapping):
f.write(b''.join(lines))
return new_mapping
+def remove_backup(filename):
+"""
+Removes the backup file for files like /etc/passwd.
+"""
+backup_filename = filename + '-'
+if os.path.exists(backup_filename):
+os.unlink(backup_filename)
+
def sort_passwd(sysconfdir):
"""
Sorts passwd and group files in a rootfs /etc directory by ID.
+Backup files are sometimes are inconsistent and then cannot be
+sorted (YOCTO #11043), and more importantly, are not needed in
+the initial rootfs, so they get deleted.
"""
-for suffix in '', '-':
-for main, shadow in (('passwd', 'shadow'),
- ('group', 'gshadow')):
-filename = os.path.join(sysconfdir, main + suffix)
+for main, shadow in (('passwd', 'shadow'),
+ ('group', 'gshadow')):
+filename = os.path.join(sysconfdir, main)
+remove_backup(filename)
+if os.path.exists(filename):
+mapping = sort_file(filename, None)
+filename = os.path.join(sysconfdir, shadow)
+remove_backup(filename)
if os.path.exists(filename):
-mapping = sort_file(filename, None)
-filename = os.path.join(sysconfdir, shadow + suffix)
-if os.path.exists(filename):
-sort_file(filename, mapping)
+ sort_file(filename, mapping)
base-commit: 652f7245ac95fd11c72f4ad62e0b99234a7e59c5
--
git-series 0.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 3/3] rm_work.bbclass: clean up sooner
On Wed, 2017-02-08 at 13:48 +, Mike Crowe wrote:
> On Wednesday 08 February 2017 at 14:04:42 +0100, Patrick Ohly wrote:
> > On Wed, 2017-02-08 at 11:50 +, Mike Crowe wrote:
> > > On Friday 13 January 2017 at 15:52:33 +0100, Patrick Ohly wrote:
> > > > The right solution is to inject do_rm_work before do_build and after
> > > > all tasks of the recipe. Achieving that depends on the new bitbake
> > > > bb.event.RecipeTaskPreProcess and bb.build.preceedtask().
> > >
> > > We've run into trouble with this change. We have a number of custom
> > > ancillary tasks that are used to generate source release files and run
> > > package tests. No other tasks (including do_build) depend on these tasks
> > > since they are run explicitly when required using bitbake -c; either
> > > directly or via a recrdeptask.
> > >
> > > Running a single task continues to work correctly - presumably this is
> > > because the do_build task is not being run, so its dependencies (including
> > > rm_work) aren't run either.
> > >
> > > Running via the recrdeptask fails. This is because for any particular
> > > recipe we end up depending on both do_build and the source release tasks.
> > > There's nothing to stop do_rm_work running before (or even during!) one of
> > > the source release tasks.
> >
> > Can you show how you use recrdeptask and how you call bitbake to trigger
> > those extra tasks, just for my understanding?
>
> Certainly, we have a bbclass globally in INHERIT that contains:
>
> addtask source_release # potential fix here
> do_source_release() {
> :
> }
>
> addtask all_source_releases
> xx_do_all_source_releases() {
> :
> }
>
> do_all_source_releases[nostamp] = "1"
> do_all_source_releases[recrdeptask] += "do_all_source_releases
> do_source_release"
>
> addtask husk_recipe before do_source_release
> python xx_do_husk_recipe() {
> ...
> }
>
> (there's also another task similar to do_husk_recipe)
>
> and in the particular recipe that has trouble with racing against rm_work:
>
> do_husk_recipe() {
> # do stuff in ${WORKDIR}
> }
> addtask husk_recipe after do_populate_sysroot before do_source_release
>
> there's also a source-release-world recipe that contains:
>
> DEPENDS = "our-image"
>
> and we run:
>
> bitbake -c all_source_releases source-release-world
I tried to replicate that with Poky master (= 226a508da), but without
luck:
/work/poky$ cat meta/classes/release-source.bbclass
addtask source_release # potential fix here
do_source_release() {
:
}
addtask all_source_releases
do_all_source_releases() {
:
}
do_all_source_releases[nostamp] = "1"
do_all_source_releases[recrdeptask] += "do_all_source_releases
do_source_release"
addtask husk_recipe before do_source_release
python do_husk_recipe() {
pass
}
/work/poky$ cat meta/recipes-core/husk/husk.bb
LICENSE = "custom"
do_husk_recipe() {
# do stuff in ${WORKDIR}
:
}
addtask husk_recipe after do_populate_sysroot before do_source_release
/work/poky$ cat meta/recipes-core/husk/source-release-world.bb
LICENSE = "custom"
DEPENDS = "core-image-sato"
/work/poky/build$ tail -1 conf/local.conf
INHERIT += "rm_work release-source"
/work/poky/build$ bitbake --dry-run -c all_source_releases source-release-world
...
That last command does not trigger the do_rm_work task and thus there is
also no race.
I had a hunch that it is related to populating the sysroot and how it
might depend on do_build in the dependencies, but that's not it. I added
DEPENDS="m4" to the husk.bb above and it has an effect:
/work/poky/build$ bitbake -g -c all_source_releases husk
Loading cache: 100% |
#|
Time: 0:00:00
Loaded 1324 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies
NOTE: PN build list saved to 'pn-buildlist'
NOTE: PN dependencies saved to 'pn-depends.dot'
NOTE: Package dependencies saved to 'package-depends.dot'
NOTE: Task dependencies saved to 'task-depends.dot'
/work/poky/build$ grep -e 'husk.*->.*m4' task-depends.dot
"husk.do_all_source_releases" -> "m4.do_source_release"
"husk.do_all_source_releases" -> "m4-native.do_source_release"
"husk.do_prepare_recipe_sysroot" -> "m4.do_populate_sysroot"
But it does not cause m4.do_build and thus m4.do_rm_work to run.
> > > It seems that we need to ensure that do_rm_work also needs to depend on
> > > our
> > > ancillary tasks too, but only i
Re: [OE-core] [PATCH v2 3/3] rm_work.bbclass: clean up sooner
On Wed, 2017-02-08 at 11:50 +, Mike Crowe wrote: > On Friday 13 January 2017 at 15:52:33 +0100, Patrick Ohly wrote: > > Having do_rm_work depend on do_build had one major disadvantage: > > do_build depends on the do_build of other recipes, to ensure that > > runtime dependencies also get built. The effect is that when work on a > > recipe is complete and it could get cleaned up, do_rm_work still > > doesn't run because it waits for those other recipes, thus leading to > > more temporary disk space usage than really needed. > > > > The right solution is to inject do_rm_work before do_build and after > > all tasks of the recipe. Achieving that depends on the new bitbake > > bb.event.RecipeTaskPreProcess and bb.build.preceedtask(). > > We've run into trouble with this change. We have a number of custom > ancillary tasks that are used to generate source release files and run > package tests. No other tasks (including do_build) depend on these tasks > since they are run explicitly when required using bitbake -c; either > directly or via a recrdeptask. > > Running a single task continues to work correctly - presumably this is > because the do_build task is not being run, so its dependencies (including > rm_work) aren't run either. > > Running via the recrdeptask fails. This is because for any particular > recipe we end up depending on both do_build and the source release tasks. > There's nothing to stop do_rm_work running before (or even during!) one of > the source release tasks. Can you show how you use recrdeptask and how you call bitbake to trigger those extra tasks, just for my understanding? I suppose it worked before because your tasks could depend on do_build without triggering do_rm_work, while now that is included. > It seems that we need to ensure that do_rm_work also needs to depend on our > ancillary tasks too, but only if they are being built. I'm unsure how this > can be done though. :( How do you determine whether the tasks need to run? Does it depend on how bitbake is invoked or does it depend on specific properties of the recipe? -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] (morty) Python exception during rootfs
On Tue, 2017-02-07 at 17:08 +0100, Mike Looijmans wrote: > Found it. A rootfs post-process function was misspelled, and that caused it. > > I'll make a patch to improve the error message here, to make it just say that > it cannot find "func". I already fixed that in bitbake master, see commit 25df3db5 "build.py: avoid exception when function is not defined". Sorry, only now saw your original email. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] whatever happened to a proposal for "read-only" sstate?
On Fri, 2017-02-03 at 16:24 -0500, Robert P. J. Day wrote: > On Fri, 3 Feb 2017, Patrick Ohly wrote: > > > On Fri, 2017-02-03 at 14:14 -0500, Robert P. J. Day wrote: > > > is there a command that will tell you how much shared state info a > > > given build would be able to take advantage of? > > > > INHERIT += "buildstats-summary" in local.conf will print that > > information after a build is done. > > but not before? ok, that will do for now. It might do that also for a "bitbake --dry-run", but I am not sure, and my build directory is currently busy, so I can't test it. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] whatever happened to a proposal for "read-only" sstate?
On Fri, 2017-02-03 at 14:14 -0500, Robert P. J. Day wrote: > is there a command that will tell you how much shared state info a > given build would be able to take advantage of? INHERIT += "buildstats-summary" in local.conf will print that information after a build is done. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] host-user-contaminated QA check
On Thu, 2017-02-02 at 13:11 -0600, Seebs wrote:
> On Thu, 02 Feb 2017 18:17:29 +0100
> Patrick Ohly <patrick.o...@intel.com> wrote:
>
> > On Thu, 2017-02-02 at 11:12 -0600, Seebs wrote:
> > > > But I find mapping to root:root more attractive because it makes
> > > > packaging simpler (less worries about accidentally copying the
> > > > original uid) and the builds faster (no need to run the QA check).
>
> > > Hmm. I think I would rather have the QA check, because if a file's
> > > supposed to be non-root, and ends up root instead, that could cause
> > > subtle problems, but we'd no longer have a way to *detect* those
> > > problems.
>
> > But that's not the kind of the problem detected by the QA check, is
> > it?
> >
> > It warns when the owner of the file is the same as the user who did
> > the build, but because root isn't (normally) used for building, files
> > accidentally owned by root on the target won't trigger the warning.
>
> Right. But the purpose of that is to detect files which didn't get
> their ownership correctly set. If we change to a default which we can't
> detect, then we can't detect "files which were supposed to have an
> ownership but didn't get it".
Got it - that's the same concern I had with 'it hides
such sloppy use of "cp"'.
> ("Created under pseudo" is enough to count as "ownership determined by
> recipe", it doesn't have to be an explicit chown.)
One could argue that an implicit "created during build -> owned by root"
follows the same logic. But as the check as it is now did find a real
issue and also others in the past (the pseudo bugs that Chris
mentioned), let's keep it.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] host-user-contaminated QA check
On Thu, 2017-02-02 at 18:49 +0100, Enrico Scholz wrote: > Patrick Ohly <patrick.ohly-ral2jqcrhueavxtiumw...@public.gmane.org> > writes: > > > Recently the host-user-contaminated QA check triggered for the trousers > > recipe in meta-security: > > > > WARNING: trousers-0.3.14+gitAUTOINC+4b9a70d578-r0 do_package_qa: QA Issue: > > trousers: /trousers/etc/tcsd.conf is owned by uid 1000, which is the same > > as the user running bitbake. This may be due to host contamination > > [host-user-contaminated] > > > > However, that's a false positive in this case. UID 1000 got assigned to > > the "tss" user in the target sysroot during the build, and tcsd.conf is > > correctly and intentionally owned by that user because tcsd checks > > ownership and refuses to start when owned by someone else (including > > root). It just happened that the UID was the same. > > > > This is likely to affect all recipes with files owned by dynamically > > created users, in particular when the host system assigns UIDs from the > > same range as the target system (quick poll: who else has 1000 as his > > UID on his main Linux box? ;-) > > Usually, this can not happen. There is reserved a range for dynamically > created users (standard says 100-499, some distributions use 100-999). > > In this case, there is probably some '--system' flag missing when the > 'tss' user is created (--> packaging bug). That's a good point. I hadn't considered that. In that case the QA check has found a real problem, albeit reported it in a way that it wasn't obvious what was going on - probably the message should get extended. I therefore retract my earlier proposal. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] host-user-contaminated QA check
On Thu, 2017-02-02 at 11:12 -0600, Seebs wrote: > > But I find mapping to root:root more attractive because it makes > > packaging simpler (less worries about accidentally copying the > > original uid) and the builds faster (no need to run the QA check). > > Hmm. I think I would rather have the QA check, because if a file's > supposed to be non-root, and ends up root instead, that could cause > subtle problems, but we'd no longer have a way to *detect* those > problems. But that's not the kind of the problem detected by the QA check, is it? It warns when the owner of the file is the same as the user who did the build, but because root isn't (normally) used for building, files accidentally owned by root on the target won't trigger the warning. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] host-user-contaminated QA check
On Thu, 2017-02-02 at 10:21 -0600, Seebs wrote: > On Thu, 02 Feb 2017 11:38:00 +0100 > Patrick Ohly <patrick.o...@intel.com> wrote: > > > Why do we make the real user ID on the build system visible at all > > when running under pseudo? The uid and user name have no meaning > > there, as the user won't exist on the target system. Instead we could > > map the owner of all files to root:root by default, i.e. in those > > cases where no other ownership is recorded in the pseudo database. > > We could. Honestly, the underlying reason we don't is at least in part > that that makes the behavior differ more from the behavior of "sudo"; > with sudo, you see actual ownerships. But that's less applicable here. > > I would be more inclined to report a Definitely Absolutely Not Okay > user ID, like 65533. (65534 and 65535 have both been used as Magic > Cookies in the past, I think.) I had considered that approach myself, too. It would make the QA check reliable and in that sense solve the problem. But I find mapping to root:root more attractive because it makes packaging simpler (less worries about accidentally copying the original uid) and the builds faster (no need to run the QA check). -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libtasn1: depends on yacc
On Wed, 2017-02-01 at 08:56 -0800, Khem Raj wrote:
>
> On 1/31/17 1:05 AM, Patrick Ohly wrote:
> > This fixes a potential pollution by the build host and build error
> > when yacc isn't installed on the build host:
> >
> > | ../../libtasn1-4.9/build-aux/ylwrap: line 175: yacc: command not found
> > | Makefile:1116: recipe for target 'ASN1.c' failed
> > | make[3]: *** [ASN1.c] Error 127
> >
> > Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
> > ---
> > meta/recipes-support/gnutls/libtasn1_4.9.bb | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/meta/recipes-support/gnutls/libtasn1_4.9.bb
> > b/meta/recipes-support/gnutls/libtasn1_4.9.bb
> > index b8ff9eaf7a9..3da5d4bcc56 100644
> > --- a/meta/recipes-support/gnutls/libtasn1_4.9.bb
> > +++ b/meta/recipes-support/gnutls/libtasn1_4.9.bb
> > @@ -16,6 +16,8 @@ SRC_URI = "${GNU_MIRROR}/libtasn1/libtasn1-${PV}.tar.gz \
> > file://0004-tools-eliminated-compiler-warnings.patch \
> > "
> >
> > +DEPENDS = "bison-native"
> > +
>
> nit on style, you generally put checksum assignments immediately after
> SRC_URI containing the origninal src location. Secondly, if we use +=
> then we dont run the risk of it overwriting prior assignments if any
Makes sense, will change that as suggested.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] potential bashism in guile_2.0.13.bb
On Wed, 2017-02-01 at 09:03 -0800, Khem Raj wrote:
>
> On 1/31/17 4:29 AM, Patrick Ohly wrote:
> > Hello!
> >
> > verify-bashisms (after some fixing of the script) reports:
> >
> > /work/iot-ref-kit/openembedded-core/meta/recipes-devtools/guile/guile_2.0.13.bb
> > possible bashism in guile_cross_config line 94 ($'...' should be "$(printf
> > '...')"):
> > echo '#!'`which ${BUILD_SYS}-guile`$' \\\n--no-auto-compile -e
> > main -s\n!#\n(define %guile-build-info '\'\( \
> > > ${B}/guile-config.cross
> >
> >
> > This is for:
> >
> > guile_cross_config() {
> > # this is only for target recipe
> > if [ "${PN}" = "guile" ]
> > then
> > # Create guile-config returning target values instead of native
> > values
> > install -d ${SYSROOT_DESTDIR}${STAGING_BINDIR_CROSS}
> > echo '#!'`which ${BUILD_SYS}-guile`$' \\\n--no-auto-compile -e
> > main -s\n!#\n(define %guile-build-info '\'\( \
> > > ${B}/guile-config.cross
> >
> > And the resulting guile-config.cross has (when /bin/sh -> /bin/dash):
> >
> > #!/fast/build/refkit/intel-corei7-64/tmp-glibc/work/corei7-64-refkit-linux/guile/2.0.13-r0/recipe-sysroot-native/usr/bin/x86_64-linux-guile$
> > \
> > --no-auto-compile -e main -s
> > !#
> > (define %guile-build-info '(
> > ...
> >
> > This looks rather strange to me and I've no idea how the Linux kernel
> > will interpret that first shebang line, which literally ends in
> > ...guile$ \
> >
> > Is the content as intended?
>
> it should have come out as path to native guile with options, I think if
> this is not happening it might just be installing wrong wrapper when
> used it should complain.
Here's a test script:
#!/bin/echo \
hello world
That prints:
\ /tmp/test2
It doesn't look like line continuation in the shebang line works, so the
above guile-config.cross is just wrong. However, both dash and bash do
the same thing, so I guess the file is not used at all?
> In any case its better to make it shell
> independent.
So the correct content of guile-config.cross would be this?
#!/.../guile/2.0.13-r0/recipe-sysroot-native/usr/bin/x86_64-linux-guile
--no-auto-compile -e main -s
!#
(define %guile-build-info '(
...
I have no idea what the script is supposed to do, so I'm a bit reluctant
to change anything.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] host-user-contaminated QA check
Hello! Recently the host-user-contaminated QA check triggered for the trousers recipe in meta-security: WARNING: trousers-0.3.14+gitAUTOINC+4b9a70d578-r0 do_package_qa: QA Issue: trousers: /trousers/etc/tcsd.conf is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated] However, that's a false positive in this case. UID 1000 got assigned to the "tss" user in the target sysroot during the build, and tcsd.conf is correctly and intentionally owned by that user because tcsd checks ownership and refuses to start when owned by someone else (including root). It just happened that the UID was the same. This is likely to affect all recipes with files owned by dynamically created users, in particular when the host system assigns UIDs from the same range as the target system (quick poll: who else has 1000 as his UID on his main Linux box? ;-) The current solution is to suppress the QA check for affected recipes. But I wonder whether we can do better. Why do we make the real user ID on the build system visible at all when running under pseudo? The uid and user name have no meaning there, as the user won't exist on the target system. Instead we could map the owner of all files to root:root by default, i.e. in those cases where no other ownership is recorded in the pseudo database. The usual reason for host-user-contaminated is when do_install does a "cp -a". When mapping the real owner to root, that command will end up doing the right thing: create a file owned by root on the target. Because the host user cannot leak into the target anymore, the entire QA check can be disabled. The only downsides of this approach that I can think of is that it hides such sloppy use of "cp" where "install" would be better, and it might be slightly confusing at first when working under devshell. Any thoughts? Seebs, I suppose this wouldn't be hard to implement in pseudo, would it? -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/4] selftest/buildoptions: use a thinner image to test 'read-only-rootfs' feature
On Wed, 2017-02-01 at 09:02 -0600, Leonardo Sandoval wrote:
>
> On 01/31/2017 05:16 PM, Richard Purdie wrote:
> > On Tue, 2017-01-31 at 16:50 -0600,
> > leonardo.sandoval.gonza...@linux.intel.com wrote:
> >> From: Leonardo Sandoval <leonardo.sandoval.gonza...@linux.intel.com>
> >> -bitbake("core-image-sato")
> >> +bitbake("core-image-minimal")
> >> # do_image will fail if there are any pending postinsts
> > Whilst this is certainly going to be a touch faster, I believe we do
> > want to test read only rootfs with a larger image like sato to make
> > sure the postinsts really do work with a read only system?
>
> I don't get it. What would make the test different using a larger image?
The postinst of each component installed into the image must work
properly in a read-only rootfs configuration. So the test is partly for
image creation, partly for the components, and thus more comprehensive
when using a larger image.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] verify-bashisms + shellcheck (was: Re: [PATCH 0/8] verify-bashisms: fix script and one issue found by it)
On Tue, 2017-01-31 at 13:50 +0100, Patrick Ohly wrote:
> The script broke when introducing tinfoil2. The patches also include
> several usability enhancements, like making the output less redundant
> and including information about the actual file and line where the
> offending script can be found.
I've further modified verify-bashisms so that it can optionally run the
scripts through shellcheck (https://www.shellcheck.net/).
I'm quite impressed with how much real issues shellcheck finds and I
also found the recommendations useful. However, it is too verbose to be
applied to all scripts in OE. For example, it warns about missing
quotation marks around variables a lot.
There is no simple "check for bashisms" command line flag or "enable
just these checks" mode. One can disable warnings, so perhaps excluding
a long list of know "harmless" checks would be a way how shellcheck
could replace checkbashisms.pl?
My current solution always calls checkbashisms.pl, and shellcheck only
when a function is annotated:
foobar () {
echo hello world
}
foobar[shellcheck] = "sh"
This sets "sh" as expected shell flavor. I did it this way because I can
imagine that someone might want to have some functions with bash
features and then ensure that bash is used to execute the code.
I can also imagine that this varflag could be used to exclude certain
checks with "sh SC2001 SC2002 ...", although the same can also be done
with inline comments for specific lines:
foobar () {
# shellcheck disable=SC2003
i=$( expr $i + 1 )
}
Using expr triggers a warning because usually $(( )) is a better
alternative. However, that currently can't be used in bitbake functions
because the shell parser chokes on it:
NotImplementedError: $((
So I've disabled that check by default.
Any suggestions how to proceed with this?
Note that shellcheck is written in Haskell. Getting it installed
automatically via a recipe would imply adding Haskell support to
OE-core. OTOH it seems to be packaged quite widely, so assuming it to be
installed on the host seems okay.
The "verify-bashisms" name of the script no longer quite matches the
actual functionality when using shellcheck, but that's minor (?).
FWIW, current additional patch is here:
diff --git a/scripts/verify-bashisms b/scripts/verify-bashisms
index dab64ef5019..000ed3f1764 100755
--- a/scripts/verify-bashisms
+++ b/scripts/verify-bashisms
@@ -24,8 +24,9 @@ def is_whitelisted(s):
SCRIPT_LINENO_RE = re.compile(r' line (\d+) ')
BASHISM_WARNING = re.compile(r'^(possible bashism in.*)$', re.MULTILINE)
+SHELLCHECK_LINENO_RE = re.compile(r'^(In .* line )(\d+):$', re.MULTILINE)
-def process(filename, function, lineno, script):
+def process(filename, function, lineno, script, shellcheck):
import tempfile
if not script.startswith("#!"):
@@ -35,10 +36,10 @@ def process(filename, function, lineno, script):
fn.write(script)
fn.flush()
+results = []
try:
subprocess.check_output(("checkbashisms.pl", fn.name),
universal_newlines=True, stderr=subprocess.STDOUT)
-# No bashisms, so just return
-return
+# No bashisms, so just continue
except subprocess.CalledProcessError as e:
# TODO check exit code is 1
@@ -48,33 +49,53 @@ def process(filename, function, lineno, script):
# Probably starts with or contains only warnings. Dump verbatim
# with one space indention. Can't do the splitting and whitelist
# checking below.
-return '\n'.join([filename,
- ' Unexpected output from checkbashisms.pl'] +
- [' ' + x for x in output.splitlines()])
-
-# We know that the first line matches and that therefore the first
-# list entry will be empty - skip it.
-output = BASHISM_WARNING.split(output)[1:]
-# Turn the output into a single string like this:
-# /.../foobar.bb
-# possible bashism in updatercd_postrm line 2 (type):
-# if ${@use_updatercd(d)} && type update-rc.d >/dev/null
2>/dev/null; then
-# ...
-# ...
-result = []
-# Check the results against the whitelist
-for message, source in zip(output[0::2], output[1::2]):
-if not is_whitelisted(source):
-if lineno is not None:
-message = SCRIPT_LINENO_RE.sub(lambda m: ' line %d ' %
(int(m.group(1)) + int(lineno) - 1),
- message)
-result.append(' ' + message.strip())
-result.extend([' %s' % x for x in source.splitlines()])
-if result:
-result.insert(0, filename)
-return '\n'.join(result)
+results.extend([' Unexpected output from checkbashisms.pl'] +
+ [' ' +
[OE-core] [PATCH 7/8] populate_sdk_ext: fix == bashism
Found via verify-bashisms.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/classes/populate_sdk_ext.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/populate_sdk_ext.bbclass
b/meta/classes/populate_sdk_ext.bbclass
index 39e0c83..9517111 100644
--- a/meta/classes/populate_sdk_ext.bbclass
+++ b/meta/classes/populate_sdk_ext.bbclass
@@ -512,7 +512,7 @@ install_tools() {
# We can't use the same method as above because files in the sysroot
won't exist at this point
# (they get populated from sstate on installation)
unfsd_path="${SDK_OUTPUT}/${SDKPATHNATIVE}${bindir_nativesdk}/unfsd"
- if [ "${SDK_INCLUDE_TOOLCHAIN}" == "1" -a ! -e $unfsd_path ] ; then
+ if [ "${SDK_INCLUDE_TOOLCHAIN}" = "1" -a ! -e $unfsd_path ] ; then
binrelpath=${@os.path.relpath(d.getVar('STAGING_BINDIR_NATIVE'),
d.getVar('TMPDIR'))}
lnr ${SDK_OUTPUT}/${SDKPATH}/tmp/$binrelpath/unfsd $unfsd_path
fi
--
git-series 0.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 8/8] verify-bashisms: support warnings with more than one line of source code
All warnings start with "possible bashism in", followed by one or more
(in the case of line continuation) lines of source code. To support
more than one line, we now split by matching against the known intro
text.
Example:
$ verify-bashisms guile
...
/.../openembedded-core/meta/recipes-devtools/guile/guile_2.0.13.bb
possible bashism in guile_cross_config line 94 ($'...' should be "$(printf
'...')"):
echo '#!'`which ${BUILD_SYS}-guile`$' \\\n--no-auto-compile -e
main -s\n!#\n(define %guile-build-info '\'\( \
> ${B}/guile-config.cross
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
scripts/verify-bashisms | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/scripts/verify-bashisms b/scripts/verify-bashisms
index 7283980..dab64ef 100755
--- a/scripts/verify-bashisms
+++ b/scripts/verify-bashisms
@@ -23,6 +23,7 @@ def is_whitelisted(s):
return False
SCRIPT_LINENO_RE = re.compile(r' line (\d+) ')
+BASHISM_WARNING = re.compile(r'^(possible bashism in.*)$', re.MULTILINE)
def process(filename, function, lineno, script):
import tempfile
@@ -42,11 +43,18 @@ def process(filename, function, lineno, script):
# TODO check exit code is 1
# Replace the temporary filename with the function and split it
-output = e.output.replace(fn.name, function).splitlines()
-if len(output) % 2 != 0:
-print("Unexpected output from checkbashism: %s" % str(output))
-return
-
+output = e.output.replace(fn.name, function)
+if not output or not output.startswith('possible bashism'):
+# Probably starts with or contains only warnings. Dump verbatim
+# with one space indention. Can't do the splitting and whitelist
+# checking below.
+return '\n'.join([filename,
+ ' Unexpected output from checkbashisms.pl'] +
+ [' ' + x for x in output.splitlines()])
+
+# We know that the first line matches and that therefore the first
+# list entry will be empty - skip it.
+output = BASHISM_WARNING.split(output)[1:]
# Turn the output into a single string like this:
# /.../foobar.bb
# possible bashism in updatercd_postrm line 2 (type):
@@ -60,7 +68,8 @@ def process(filename, function, lineno, script):
if lineno is not None:
message = SCRIPT_LINENO_RE.sub(lambda m: ' line %d ' %
(int(m.group(1)) + int(lineno) - 1),
message)
-result.extend([' ' + message, ' ' + source])
+result.append(' ' + message.strip())
+result.extend([' %s' % x for x in source.splitlines()])
if result:
result.insert(0, filename)
return '\n'.join(result)
--
git-series 0.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 6/8] verify-bashisms: check scripts only once, include original file and line
Several scripts that are defined in .bbclass files end up in multiple
different recipes. It's better (faster, less repetitive error reports)
to check them only once.
In addition, the real information for the developer is where he can
find the script, not which recipe file uses it. verify-bashisms now
prints the original file instead of the recipe whenever possible
(i.e. 'filename' is set) and also bumps the line number so that it is
relative to the file and not the script.
Example with one real error and one added just for testing:
$ verify-bashisms core-image-minimal core-image-sato
Loading cache: 100%
|#|
Time: 0:00:00
Loaded 2935 entries from dependency cache.
Parsing recipes: 100%
|###|
Time: 0:00:01
Parsing of 2137 .bb files complete (2101 cached, 36 parsed). 2935 targets,
412 skipped, 0 masked, 0 errors.
Generating scripts...
Scanning scripts...
/.../openembedded-core/meta/classes/populate_sdk_ext.bbclass
possible bashism in install_tools line 515 (should be 'b = a'):
if [ "${SDK_INCLUDE_TOOLCHAIN}" == "1" -a ! -e $unfsd_path ] ; then
possible bashism in install_tools line 521 (type):
type fixme
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
scripts/verify-bashisms | 56 +++---
1 file changed, 36 insertions(+), 20 deletions(-)
diff --git a/scripts/verify-bashisms b/scripts/verify-bashisms
index df071e3..7283980 100755
--- a/scripts/verify-bashisms
+++ b/scripts/verify-bashisms
@@ -22,7 +22,9 @@ def is_whitelisted(s):
return True
return False
-def process(recipe, function, script):
+SCRIPT_LINENO_RE = re.compile(r' line (\d+) ')
+
+def process(filename, function, lineno, script):
import tempfile
if not script.startswith("#!"):
@@ -45,13 +47,25 @@ def process(recipe, function, script):
print("Unexpected output from checkbashism: %s" % str(output))
return
-# Turn the output into a list of (message, source) values
+# Turn the output into a single string like this:
+# /.../foobar.bb
+# possible bashism in updatercd_postrm line 2 (type):
+# if ${@use_updatercd(d)} && type update-rc.d >/dev/null
2>/dev/null; then
+# ...
+# ...
result = []
# Check the results against the whitelist
for message, source in zip(output[0::2], output[1::2]):
if not is_whitelisted(source):
-result.append((message, source))
-return result
+if lineno is not None:
+message = SCRIPT_LINENO_RE.sub(lambda m: ' line %d ' %
(int(m.group(1)) + int(lineno) - 1),
+ message)
+result.extend([' ' + message, ' ' + source])
+if result:
+result.insert(0, filename)
+return '\n'.join(result)
+else:
+return None
def get_tinfoil():
scripts_path = os.path.dirname(os.path.realpath(__file__))
@@ -75,12 +89,8 @@ if __name__=='__main__':
# initializing the pool and connecting to the
# bitbake server is crucial, don't change it.
def func(item):
-fn, scripts = item
-result = []
-for key, script in scripts:
-r = process(fn, key, script)
-if r: result.extend(r)
-return fn, result
+(filename, key, lineno), script = item
+return process(filename, key, lineno, script)
import multiprocessing
pool = multiprocessing.Pool()
@@ -97,27 +107,33 @@ if __name__=='__main__':
else:
initial_pns = sorted(pkg_pn)
-pns = {}
+pns = set()
+scripts = {}
print("Generating scripts...")
for pn in initial_pns:
for fn in pkg_pn[pn]:
# There's no point checking multiple BBCLASSEXTENDed variants of
the same recipe
+# (at least in general - there is some risk that the variants
contain different scripts)
realfn, _, _ = bb.cache.virtualfn2realfn(fn)
if realfn not in pns:
+pns.add(realfn)
data = tinfoil.parse_recipe_file(realfn)
-scripts = []
for key in data.keys():
if data.getVarFlag(key, "func") and not
data.getVarFlag(key, "python"):
script = data.getVar(key, False)
if script:
-scripts.append((key, script))
-pns[realfn] = scripts
+filename = data.getVarFlag(key, "filename")
+lineno = data.getVarFlag(key, "lineno")
+# There'
[OE-core] [PATCH 4/8] verify-bashisms: fix problems with tinfoil2
tinfoil2 is based on a client/server architecture, which broke the
verify-bashisms script:
- The tinfoil instance and its data proxies can't be pickled, so
all interaction with the bitbake server has to run in the main
script process and only processing of the plain scripts can
be done with multiprocessing:
_pickle.PicklingError: Can't pickle : attribute lookup
TinfoilRecipeCacheAdapter on bb.tinfoil failed
- The multiprocessing pool has to be created before initializing
tinfoil, otherwise the pool workers end up trying to communicate
with the bitbake server during shutdown:
ERROR: UI received SIGTERM
Process ForkPoolWorker-2:
Traceback (most recent call last):
File "/usr/lib/python3.4/multiprocessing/process.py", line 257, in
_bootstrap
util._exit_function()
File "/usr/lib/python3.4/multiprocessing/util.py", line 286, in
_exit_function
_run_finalizers(0)
...
File "/usr/lib/python3.4/multiprocessing/process.py", line 131, in is_alive
assert self._parent_pid == os.getpid(), 'can only test a child process'
AssertionError: can only test a child process
- func() needs to defined before creating the pool to avoid:
AttributeError: Can't get attribute 'func' on
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
scripts/verify-bashisms | 44 +++---
1 file changed, 25 insertions(+), 19 deletions(-)
diff --git a/scripts/verify-bashisms b/scripts/verify-bashisms
index ed0a563..613f174 100755
--- a/scripts/verify-bashisms
+++ b/scripts/verify-bashisms
@@ -71,6 +71,20 @@ if __name__=='__main__':
print("Cannot find checkbashisms.pl on $PATH, get it from
https://anonscm.debian.org/cgit/collab-maint/devscripts.git/plain/scripts/checkbashisms.pl;)
sys.exit(1)
+# The order of defining the worker function,
+# initializing the pool and connecting to the
+# bitbake server is crucial, don't change it.
+def func(item):
+fn, scripts = item
+result = []
+for key, script in scripts:
+r = process(fn, key, script)
+if r: result.extend(r)
+return fn, result
+
+import multiprocessing
+pool = multiprocessing.Pool()
+
tinfoil = get_tinfoil()
# This is only the default configuration and should iterate over
@@ -83,32 +97,24 @@ if __name__=='__main__':
else:
initial_pns = sorted(pkg_pn)
-pns = []
-print("Generating file list...")
+pns = {}
+print("Generating scripts...")
for pn in initial_pns:
for fn in pkg_pn[pn]:
# There's no point checking multiple BBCLASSEXTENDed variants of
the same recipe
realfn, _, _ = bb.cache.virtualfn2realfn(fn)
if realfn not in pns:
-pns.append(realfn)
-
-
-def func(fn):
-result = []
-data = tinfoil.parse_recipe_file(fn)
-for key in data.keys():
-if data.getVarFlag(key, "func") and not data.getVarFlag(key,
"python"):
-script = data.getVar(key, False)
-if not script: continue
-#print ("%s:%s" % (fn, key))
-r = process(fn, key, script)
-if r: result.extend(r)
-return fn, result
+data = tinfoil.parse_recipe_file(realfn)
+scripts = []
+for key in data.keys():
+if data.getVarFlag(key, "func") and not
data.getVarFlag(key, "python"):
+script = data.getVar(key, False)
+if script:
+scripts.append((key, script))
+pns[realfn] = scripts
print("Scanning scripts...\n")
-import multiprocessing
-pool = multiprocessing.Pool()
-for pn,results in pool.imap(func, pns):
+for pn, results in pool.imap(func, pns.items()):
if results:
print(pn)
for message,source in results:
--
git-series 0.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 5/8] verify-bashisms: revise update-rc.d whitelist entry
The actual code recently changed to:
if ${@use_updatercd(d)} && type update-rc.d >/dev/null 2>/dev/null; then
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
scripts/verify-bashisms | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/verify-bashisms b/scripts/verify-bashisms
index 613f174..df071e3 100755
--- a/scripts/verify-bashisms
+++ b/scripts/verify-bashisms
@@ -6,7 +6,7 @@ whitelist = (
# type is supported by dash
'if type systemctl >/dev/null 2>/dev/null; then',
'if type systemd-tmpfiles >/dev/null 2>/dev/null; then',
-'if type update-rc.d >/dev/null 2>/dev/null; then',
+'type update-rc.d >/dev/null 2>/dev/null; then',
'command -v',
# HOSTNAME is set locally
'buildhistory_single_commit "$CMDLINE" "$HOSTNAME"',
--
git-series 0.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/8] verify-bashisms: point out where to get checkbashisms.pl
The current SourceForge project seems to be unmaintained (last release
2.0.0.2 from 2015) while the copy used by Debian is quite active (last
commit 2016-09-30).
Ideally, checkbashisms.pl should get installed automatically via a
recipe, but for now at least provide the link for manual installation.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
scripts/verify-bashisms | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/verify-bashisms b/scripts/verify-bashisms
index 1bda60c..28795f4 100755
--- a/scripts/verify-bashisms
+++ b/scripts/verify-bashisms
@@ -68,7 +68,7 @@ def get_tinfoil():
if __name__=='__main__':
import shutil
if shutil.which("checkbashisms.pl") is None:
-print("Cannot find checkbashisms.pl on $PATH")
+print("Cannot find checkbashisms.pl on $PATH, get it from
https://anonscm.debian.org/cgit/collab-maint/devscripts.git/plain/scripts/checkbashisms.pl;)
sys.exit(1)
tinfoil = get_tinfoil()
--
git-series 0.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/8] verify-bashisms: explicitly shut down server
Current tinfoil2 requires manually shutting down the server.
Without that, the script hangs during exit. This might change
in the future.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
scripts/verify-bashisms | 1 +
1 file changed, 1 insertion(+)
diff --git a/scripts/verify-bashisms b/scripts/verify-bashisms
index 28795f4..ed0a563 100755
--- a/scripts/verify-bashisms
+++ b/scripts/verify-bashisms
@@ -114,3 +114,4 @@ if __name__=='__main__':
for message,source in results:
print(" %s\n %s" % (message, source))
print()
+tinfoil.shutdown()
--
git-series 0.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/8] verify-bashisms: fix typo
Variable was renamed, it's now called "output".
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
scripts/verify-bashisms | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/verify-bashisms b/scripts/verify-bashisms
index a8f761d..1bda60c 100755
--- a/scripts/verify-bashisms
+++ b/scripts/verify-bashisms
@@ -41,7 +41,7 @@ def process(recipe, function, script):
# Replace the temporary filename with the function and split it
output = e.output.replace(fn.name, function).splitlines()
-if len(results) % 2 != 0:
+if len(output) % 2 != 0:
print("Unexpected output from checkbashism: %s" % str(output))
return
--
git-series 0.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/8] verify-bashisms: fix script and one issue found by it
The script broke when introducing tinfoil2. The patches also include several usability enhancements, like making the output less redundant and including information about the actual file and line where the offending script can be found. Patrick Ohly (8): verify-bashisms: fix typo verify-bashisms: point out where to get checkbashisms.pl verify-bashisms: explicitly shut down server verify-bashisms: fix problems with tinfoil2 verify-bashisms: revise update-rc.d whitelist entry verify-bashisms: check scripts only once, include original file and line populate_sdk_ext: fix == bashism verify-bashisms: support warnings with more than one line of source code meta/classes/populate_sdk_ext.bbclass | 2 +- scripts/verify-bashisms | 100 +-- 2 files changed, 67 insertions(+), 35 deletions(-) base-commit: 8d955d3486beca27fa23448f930d2c4df94b187a -- git-series 0.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] potential bashism in guile_2.0.13.bb
Hello!
verify-bashisms (after some fixing of the script) reports:
/work/iot-ref-kit/openembedded-core/meta/recipes-devtools/guile/guile_2.0.13.bb
possible bashism in guile_cross_config line 94 ($'...' should be "$(printf
'...')"):
echo '#!'`which ${BUILD_SYS}-guile`$' \\\n--no-auto-compile -e
main -s\n!#\n(define %guile-build-info '\'\( \
> ${B}/guile-config.cross
This is for:
guile_cross_config() {
# this is only for target recipe
if [ "${PN}" = "guile" ]
then
# Create guile-config returning target values instead of native
values
install -d ${SYSROOT_DESTDIR}${STAGING_BINDIR_CROSS}
echo '#!'`which ${BUILD_SYS}-guile`$' \\\n--no-auto-compile -e
main -s\n!#\n(define %guile-build-info '\'\( \
> ${B}/guile-config.cross
And the resulting guile-config.cross has (when /bin/sh -> /bin/dash):
#!/fast/build/refkit/intel-corei7-64/tmp-glibc/work/corei7-64-refkit-linux/guile/2.0.13-r0/recipe-sysroot-native/usr/bin/x86_64-linux-guile$
\
--no-auto-compile -e main -s
!#
(define %guile-build-info '(
...
This looks rather strange to me and I've no idea how the Linux kernel
will interpret that first shebang line, which literally ends in
...guile$ \
Is the content as intended?
It builds, whatever that means.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libtasn1: depends on yacc
This fixes a potential pollution by the build host and build error
when yacc isn't installed on the build host:
| ../../libtasn1-4.9/build-aux/ylwrap: line 175: yacc: command not found
| Makefile:1116: recipe for target 'ASN1.c' failed
| make[3]: *** [ASN1.c] Error 127
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/recipes-support/gnutls/libtasn1_4.9.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-support/gnutls/libtasn1_4.9.bb
b/meta/recipes-support/gnutls/libtasn1_4.9.bb
index b8ff9eaf7a9..3da5d4bcc56 100644
--- a/meta/recipes-support/gnutls/libtasn1_4.9.bb
+++ b/meta/recipes-support/gnutls/libtasn1_4.9.bb
@@ -16,6 +16,8 @@ SRC_URI = "${GNU_MIRROR}/libtasn1/libtasn1-${PV}.tar.gz \
file://0004-tools-eliminated-compiler-warnings.patch \
"
+DEPENDS = "bison-native"
+
SRC_URI[md5sum] = "3018d0f466a32b66dde41bb122e6cab6"
SRC_URI[sha256sum] =
"4f6f7a8fd691ac2b8307c8ca365bad711db607d4ad5966f6938a9d2ecd65c920"
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v5 09/12] runqemu: also accept -image suffix for rootfs parameter
On Mon, 2017-01-30 at 17:12 +, Bystricky, Juro wrote:
>
> > -Original Message-
> > From: Patrick Ohly [mailto:patrick.o...@intel.com]
> > Sent: Friday, January 27, 2017 11:22 AM
> > To: Bystricky, Juro <juro.bystri...@intel.com>
> > Cc: openembedded-core@lists.openembedded.org
> > Subject: Re: [OE-core] [PATCH v5 09/12] runqemu: also accept -image suffix
> > for rootfs parameter
> >
> > On Fri, 2017-01-27 at 16:54 +, Bystricky, Juro wrote:
> > > Just curious: is this test for "image" in file name really necessary?
> > > With qemuboot.conf the relevant files are already spelled out.
> > > I don't see a need to force "compulsory" names for images.
> > > If I comment out this test, everything works just fine. Am I missing
> > something?
> >
> > Some of the usages when checking for paths might have become obsolete,
> > but at least for distinguishing between machine and image base name
> > parameters it is still relevant:
> >
> > def check_args(self):
> > ...
> > elif re.search(r'-image-|-image$', arg):
> > # Lazy rootfs
> > self.rootfs = arg
> > elif arg.startswith('ovmf'):
> > self.ovmf_bios.append(arg)
> > else:
> > # At last, assume is it the MACHINE
> > if (not unknown_arg) or unknown_arg == arg:
> > unknown_arg = arg
> > else:
> > raise Exception("Can't handle two unknown args: %s %
> > s" % (unknown_arg, arg))
> >
> > When removing the "if re.search(r'-image-|-image$', arg)" clause one
> > gets an error for:
> >
> > $ runqemu core-image-minimal ext4 qemux86
> > runqemu - ERROR - Can't handle two unknown args: core-image-minimal qemux86
> > runqemu - ERROR - Try 'runqemu help' on how to use it
> >
>
> I see, the purpose of this test is determine which argument is which,
> as they can be in any order. IMHO to differentiate between MACHINE and image
> it would
> make more sense to search for "qemu" instead of "-image-" or "-image" .
The machine is not guaranteed to contain "qemu". I sent a patch to
meta-intel which enables "runqemu core-image-minimal ext4
intel-corei7-64", and other BSPs might want to do the same.
> (BTW do we need both -image- and -image$?)
Yes, for "core-image-minimal" and "foobar-installer-image" (something
that I am currently working on).
> There is also ANOTHER test for '-image-', in "is_deploy_dir_image".
> This is the one I considered redundant (or not needed in case we have
> qemuboot.conf).
That might be true. I was trying to be conservative with this patch and
thus extended all existing checks instead of trying to to figure out
which one had become redundant.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v5 09/12] runqemu: also accept -image suffix for rootfs parameter
On Fri, 2017-01-27 at 16:54 +, Bystricky, Juro wrote:
> Just curious: is this test for "image" in file name really necessary?
> With qemuboot.conf the relevant files are already spelled out.
> I don't see a need to force "compulsory" names for images.
> If I comment out this test, everything works just fine. Am I missing
> something?
Some of the usages when checking for paths might have become obsolete,
but at least for distinguishing between machine and image base name
parameters it is still relevant:
def check_args(self):
...
elif re.search(r'-image-|-image$', arg):
# Lazy rootfs
self.rootfs = arg
elif arg.startswith('ovmf'):
self.ovmf_bios.append(arg)
else:
# At last, assume is it the MACHINE
if (not unknown_arg) or unknown_arg == arg:
unknown_arg = arg
else:
raise Exception("Can't handle two unknown args: %s %
s" % (unknown_arg, arg))
When removing the "if re.search(r'-image-|-image$', arg)" clause one
gets an error for:
$ runqemu core-image-minimal ext4 qemux86
runqemu - ERROR - Can't handle two unknown args: core-image-minimal qemux86
runqemu - ERROR - Try 'runqemu help' on how to use it
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v4 05/12] ovmf: deploy firmware in image directory
On Thu, 2017-01-26 at 19:25 -0800, Ricardo Neri wrote: > On Mon, 2017-01-23 at 08:45 +0100, Patrick Ohly wrote: > > > On the other hand, this is a new recipe and this may not be super > > > critical. Especially if you meant that only OVMF will not support > > > installing bios.bin in sysroot. Maybe all is needed is some > > > clarification in the commit message. > > > > Care to suggest something? ;-) To me, "traditional usage of ovmf ... > > is > > no longer supported" already says that this is a statement about ovmf, > > not the bios parameter, so I'm not sure how to reword this. > > Perhaps specifying what "traditional usage" means, both when using > runqemu or qemu directly. I think this is useful as you devoted a fair > amount of effort to enable your work in qemu. Mentioning the qemu > features could be useful to people using qemu directly. I've tried to make the commit message more useful in V5. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v5 12/12] ovmf: remove BGRT patch
This patch was added to meta-luv for kernel testing purposes and probably is not relevant for OE-core. Signed-off-by: Patrick Ohly <patrick.o...@intel.com> --- meta/recipes-core/ovmf/ovmf/0001-OvmfPkg-Enable-BGRT-in-OVMF.patch | 110 + meta/recipes-core/ovmf/ovmf_git.bb | 1 +- 2 files changed, 111 deletions(-) delete mode 100644 meta/recipes-core/ovmf/ovmf/0001-OvmfPkg-Enable-BGRT-in-OVMF.patch diff --git a/meta/recipes-core/ovmf/ovmf/0001-OvmfPkg-Enable-BGRT-in-OVMF.patch b/meta/recipes-core/ovmf/ovmf/0001-OvmfPkg-Enable-BGRT-in-OVMF.patch deleted file mode 100644 index 4531a6d..000 --- a/meta/recipes-core/ovmf/ovmf/0001-OvmfPkg-Enable-BGRT-in-OVMF.patch +++ /dev/null @@ -1,110 +0,0 @@ -From 66a4020c3c2163aeffc9757851f33c346ecfd870 Mon Sep 17 00:00:00 2001 -From: Sai Praneeth Prakhya <sai.praneeth.prak...@intel.com> -Date: Mon, 4 Apr 2016 12:15:12 -0700 -Subject: [PATCH] OvmfPkg: Enable BGRT in OVMF - -By default, firmware (OVMF - Open source Virtual Machine Firmware) -never publishes BGRT (Boot Graphics Resource Table) and in the boot -process Linux kernel checks for this table and if it fails to find BGRT -table then corresponding code in Linux kernel is not executed. EDK II -(EFI Development Kit, thus OVMF) already has BGRT source code packaged -into it but it is excluded from the build process of OVMF. These changes -to build system of OVMF enables BGRT in 32-bit and 64-bit OVMF. - -There are only two files that need to be modified in order to do this. -The first one being OvmfPkg*.dsc (this file describes the platform) and -the second one being OvmfPkg*.fdf (this file describes firmware descriptor -volume). A *.inf file (here "BootGraphicsResourceTableDxe.inf") -describes a module (here BGRT). So, include -"BootGraphicsResourceTableDxe.inf" file in "OvmfPkg*.dsc" so that BGRT -source code will be compiled and "BootGraphicsResourceTableDxe.efi" file -is generated and we should also include -"BootGraphicsResourceTableDxe.inf" file in "OvmfPkg*.fdf" file so that -"BootGraphicsResourceTableDxe.efi" will be placed in a firmware volume -and thus gets published. - -Signed-off-by: Sai Praneeth Prakhya <sai.praneeth.prak...@intel.com> - OvmfPkg/OvmfPkgIa32.dsc| 1 + - OvmfPkg/OvmfPkgIa32.fdf| 1 + - OvmfPkg/OvmfPkgIa32X64.dsc | 1 + - OvmfPkg/OvmfPkgIa32X64.fdf | 1 + - OvmfPkg/OvmfPkgX64.dsc | 1 + - OvmfPkg/OvmfPkgX64.fdf | 1 + - 6 files changed, 6 insertions(+) - -diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc -index 9e5b477..0582219 100644 a/OvmfPkg/OvmfPkgIa32.dsc -+++ b/OvmfPkg/OvmfPkgIa32.dsc -@@ -647,6 +647,7 @@ - OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf - MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf - MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf -+ MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf - - # - # Network Support -diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf -index fc203f2..f968cb7 100644 a/OvmfPkg/OvmfPkgIa32.fdf -+++ b/OvmfPkg/OvmfPkgIa32.fdf -@@ -274,6 +274,7 @@ INF RuleOverride=ACPITABLE OvmfPkg/AcpiTables/AcpiTables.inf - INF OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf - INF MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf - INF MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf -+INF MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf - - INF RuleOverride = BINARY FatBinPkg/EnhancedFatDxe/Fat.inf - -diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc -index 6e4da4f..8289385 100644 a/OvmfPkg/OvmfPkgIa32X64.dsc -+++ b/OvmfPkg/OvmfPkgIa32X64.dsc -@@ -656,6 +656,7 @@ - OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf - MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf - MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf -+ MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf - - # - # Network Support -diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf -index d3f46f3..282d40b 100644 a/OvmfPkg/OvmfPkgIa32X64.fdf -+++ b/OvmfPkg/OvmfPkgIa32X64.fdf -@@ -274,6 +274,7 @@ INF RuleOverride=ACPITABLE OvmfPkg/AcpiTables/AcpiTables.inf - INF OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf - INF MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf - INF MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf -+INF MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf - - INF RuleOverride = BINARY USE = X64 FatBinPkg/EnhancedFatDxe/Fat.inf - -diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc -index 3d6d43e..0f956a7 100644 a/OvmfPkg/OvmfPkgX64.dsc -+++ b
[OE-core] [PATCH v5 11/12] ovmf: build image which enrolls standard keys
When booting a qemu virtual machine with ovmf.secboot, it comes up
with no keys installed and thus Secure Boot disabled. To lock down
the machine like a typical PC, one has to enroll the same keys
that PC vendors normally install, i.e. the ones from Microsoft.
This can be done manually (see
https://wiki.ubuntu.com/SecurityTeam/SecureBoot and
https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_into_UEFI_Secure_Boot_White_Paper.pdf)
or automatically with the EnrollDefaultKeys.efi helper
from the Fedora ovmf rpm.
To use this with qemu:
$ bitbake ovmf-shell-image
...
$ runqemu serial nographic qemux86 ovmf-shell-image wic ovmf.secboot
...
UEFI Interactive Shell v2.1
EDK II
UEFI v2.60 (EDK II, 0x0001)
Mapping table
FS0: Alias(s):HD2b:;BLK4:
PciRoot(0x0)/Pci(0x5,0x0)/HD(1,GPT,06AEF759-3982-4AF6-B517-70BA6304FC1C,0x800,0x566C)
BLK0: Alias(s):
PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x0)
BLK1: Alias(s):
PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x1)
BLK2: Alias(s):
PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)
BLK3: Alias(s):
PciRoot(0x0)/Pci(0x5,0x0)
Press ESC in 1 seconds to skip startup.nsh or any other key to continue.
Shell> fs0:EnrollDefaultKeys.efi
info: SetupMode=1 SecureBoot=0 SecureBootEnable=0 CustomMode=0 VendorKeys=1
info: SetupMode=0 SecureBoot=1 SecureBootEnable=1 CustomMode=0 VendorKeys=0
info: success
Shell> reset
Remember that this will modify
deploy/images/qemux86/ovmf.secboot.qcow2, so make a copy and use the
full path of that copy instead of the "ovmf" argument if needed.
The ovmf-shell-image contains an EFI shell, which is what got started
here directly. After enrolling the keys, Secure Boot is active and the
same image cannot be booted anymore, so the BIOS goes through the
normal boot targets (including network boot, which can take a while to
time out), and ends up in the internal EFI shell. Trying to invoke
bootia32.efi (the shell from the image) or EnrollDefaultKeys.efi then
fails:
Shell> bootia32.efi
Command Error Status: Security Violation
The main purpose at the moment is to test that Secure Boot enforcement
really works. If we had a way to sign generated images, that part could
also be tested by booting in a locked down qemu instance.
0007-OvmfPkg-EnrollDefaultKeys-application-for-enrolling-.patch is
from
https://src.fedoraproject.org/cgit/rpms/edk2.git/tree/0007-OvmfPkg-EnrollDefaultKeys-application-for-enrolling-.patch?id=b1781931894bf2057464e634beed68b1e3218c9e
with one line changed to fix
https://bugzilla.redhat.com/show_bug.cgi?id=132502:
"EFI_STATUS Status = EFI_SUCCESS;" in EnrollListOfX509Certs() lacked
the initializer.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/recipes-core/ovmf/ovmf-shell-image.bb
| 17 +-
meta/recipes-core/ovmf/ovmf/0007-OvmfPkg-EnrollDefaultKeys-application-for-enrolling-.patch
| 1124
-
meta/recipes-core/ovmf/ovmf/ovmf-shell-image.wks
|4 +-
meta/recipes-core/ovmf/ovmf_git.bb
| 22 +-
4 files changed, 1167 insertions(+)
create mode 100644 meta/recipes-core/ovmf/ovmf-shell-image.bb
create mode 100644
meta/recipes-core/ovmf/ovmf/0007-OvmfPkg-EnrollDefaultKeys-application-for-enrolling-.patch
create mode 100644 meta/recipes-core/ovmf/ovmf/ovmf-shell-image.wks
diff --git a/meta/recipes-core/ovmf/ovmf-shell-image.bb
b/meta/recipes-core/ovmf/ovmf-shell-image.bb
new file mode 100644
index 000..029547b
--- /dev/null
+++ b/meta/recipes-core/ovmf/ovmf-shell-image.bb
@@ -0,0 +1,17 @@
+DESCRIPTION = "boot image with UEFI shell and tools"
+
+# For this image recipe, only the wic format with a
+# single vfat partition makes sense.
+IMAGE_FSTYPES_forcevariable = 'wic'
+
+WKS_FILE = "ovmf/ovmf-shell-image.wks"
+inherit image
+
+# We want a minimal image with just ovmf-shell-efi unpacked in it. We
+# avoid installing unnecessary stuff as much as possible, but some
+# things still get through and need to be removed.
+PACKAGE_INSTALL = "ovmf-shell-efi"
+LINGUAS_INSTALL = ""
+do_image () {
+rm -rf `ls -d ${IMAGE_ROOTFS}/* | grep -v efi`
+}
diff --git
a/meta/recipes-core/ovmf/ovmf/0007-OvmfPkg-EnrollDefaultKeys-application-for-enrolling-.patch
b/meta/recipes-core/ovmf/ovmf/0007-OvmfPkg-EnrollDefaultKeys-application-for-enrolling-.patch
new file mode 100644
index 000..3aa6cc4
--- /dev/null
+++
b/meta/recipes-core/ovmf/ovmf/0007-OvmfPkg-EnrollDefaultKeys-application-for-enrolling-.patch
@@ -0,0 +1,1124 @@
+From: Laszlo Ersek <ler...@redhat.com>
+Date: Mon, 6 Jul 2015 20:22:02 +0200
+Subject: [PATCH] OvmfPkg: EnrollDefaultKeys: application for enrolling default
+ keys
+
+(A port of the <https://bugzilla.redhat.com/show_bug.cgi?i
[OE-core] [PATCH v5 10/12] runqemu: support UEFI with OVMF firmware
In the simplest case, "runqemu qemux86 qcow2 ovmf" for an
EFI-enabled image in the qcow2 format will locate the ovmf.qcow2
firmware file deployed by the ovmf recipe in the image deploy
directory, override the graphics hardware with "-vga std" because that
is all that OVMF supports, and boot with UEFI enabled.
ovmf is not built by default. Either do it explicitly ("bitbake ovmf")
or make it a part of the normal build
("MACHINE_ESSENTIAL_EXTRA_RDEPENDS_append = ' ovmf'").
The firmware file is activated as a flash drive instead of using the
qemu BIOS parameters, because that is the recommended method
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764918#47) as it
allows storing UEFI variables in the file.
Instead of just "ovmf", a full path to an existing file can also be
used, just as with the rootfs. That may be useful when making a
permanent copy of the virtual machine data files.
It is possible to specify "ovmf*" parameters more than once, then
each parameter creates a separate flash drive. This way it is possible
to use separate flash drives for firmware code and variables:
$ runqemu qemux86 qcow2 ovmf.code ovmf.vars"
Note that rebuilding ovmf will overwrite the ovmf.vars.qcow2 file in
the image deploy directory. So when the goal is to update the firmware
while keeping variables, make a copy of the variable file and use
that:
$ mkdir my-machine
$ cp tmp/deploy/images/qemux86/ovmf.vars.qcow2 my-machine/
$ runqemu qemux86 qcow2 ovmf.code my-machine/ovmf.vars.qcow2
When Secure Boot was enabled in ovmf, one can pick that instead of
the non-Secure-Boot enabled ovmf.code:
$ runqemu qemux86 qcow2 ovmf.secboot.code
my-machine/ovmf.vars.qcow2
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
scripts/runqemu | 42 +-
1 file changed, 41 insertions(+), 1 deletion(-)
diff --git a/scripts/runqemu b/scripts/runqemu
index 4d7168c..10947bb 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -74,6 +74,7 @@ of the following environment variables (in any order):
kvm-vhost - enable KVM with vhost when running x86/x86_64 (VT-capable CPU
required)
publicvnc - enable a VNC server open to all hosts
audio - enable audio
+[*/]ovmf* - OVMF firmware file or base name for booting with UEFI
tcpserial= - specify tcp serial port number
biosdir= - specify custom bios dir
biosfilename= - specify bios filename
@@ -162,6 +163,13 @@ class BaseConfig(object):
self.clean_nfs_dir = False
self.nfs_server = ''
self.rootfs = ''
+# File name(s) of a OVMF firmware file or variable store,
+# to be added with -drive if=pflash.
+# Found in the same places as the rootfs, with or without one of
+# these suffices: qcow2, bin.
+# Setting one also adds "-vga std" because that is all that
+# OVMF supports.
+self.ovmf_bios = []
self.qemuboot = ''
self.qbconfload = False
self.kernel = ''
@@ -259,6 +267,7 @@ class BaseConfig(object):
- Check whether is a kernel file
- Check whether is a image file
- Check whether it is a nfs dir
+- Check whether it is a OVMF flash file
"""
if p.endswith('.qemuboot.conf'):
self.qemuboot = p
@@ -299,6 +308,8 @@ class BaseConfig(object):
else:
logger.info("Assuming %s is an nfs rootfs" % p)
self.check_arg_nfs(p)
+elif os.path.basename(p).startswith('ovmf'):
+self.ovmf_bios.append(p)
else:
raise Exception("Unknown path arg %s" % p)
@@ -384,6 +395,8 @@ class BaseConfig(object):
elif re.search(r'-image-|-image$', arg):
# Lazy rootfs
self.rootfs = arg
+elif arg.startswith('ovmf'):
+self.ovmf_bios.append(arg)
else:
# At last, assume is it the MACHINE
if (not unknown_arg) or unknown_arg == arg:
@@ -482,6 +495,20 @@ class BaseConfig(object):
if not os.path.exists(self.rootfs):
raise Exception("Can't find rootfs: %s" % self.rootfs)
+def check_ovmf(self):
+"""Check and set full path for OVMF firmware and variable file(s)."""
+
+for index, ovmf in enumerate(self.ovmf_bios):
+if os.path.exists(ovmf):
+continue
+for suffix in ('qcow2', 'bin'):
+path = '%s/%s.%s' % (self.get('DEPLOY_DIR_IMAGE'), ovmf,
suffix)
+if os.path.exists(path):
+self.ovmf_bios[index] = path
+break
+else:
+raise Exception("Can't find OVMF firmware: %s" % ovmf)
+
def check_kernel(self):
"""Check and set kernel,
[OE-core] [PATCH v5 09/12] runqemu: also accept -image suffix for rootfs parameter
The magic detection of the rootfs parameter only worked for image
recipes which embedd the "image" string in the middle, as in
"core-image-minimal".
Sometimes it is more natural to call an image "something-image". To
get such an image detected by runqemu, "-image" at the end of a
parameter must also cause that parameter to be treated as the rootfs
parameter.
Inside the image directory, "something-image" has an - suffix
and thus no change is needed for those usages of
re.search('-image-'). However, while at it also enhance those string
searches a bit (no need for re; any()+map() a bit closer to the
intended logic).
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
scripts/runqemu | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/scripts/runqemu b/scripts/runqemu
index 17d79e9..4d7168c 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -218,7 +218,7 @@ class BaseConfig(object):
if not re.search('.qemuboot.conf$', '\n'.join(os.listdir(p)),
re.M):
logger.info("Can't find required *.qemuboot.conf in %s" % p)
return False
-if not re.search('-image-', '\n'.join(os.listdir(p))):
+if not any(map(lambda name: '-image-' in name, os.listdir(p))):
logger.info("Can't find *-image-* in %s" % p)
return False
return True
@@ -267,7 +267,7 @@ class BaseConfig(object):
re.search('zImage', p) or re.search('vmlinux', p) or \
re.search('fitImage', p) or re.search('uImage', p):
self.kernel = p
-elif os.path.exists(p) and (not os.path.isdir(p)) and
re.search('-image-', os.path.basename(p)):
+elif os.path.exists(p) and (not os.path.isdir(p)) and '-image-' in
os.path.basename(p):
self.rootfs = p
# Check filename against self.fstypes can hanlde .cpio.gz,
# otherwise, its type would be "gz", which is incorrect.
@@ -381,7 +381,7 @@ class BaseConfig(object):
self.kernel_cmdline_script += ' %s' % arg[len('bootparams='):]
elif os.path.exists(arg) or (re.search(':', arg) and
re.search('/', arg)):
self.check_arg_path(os.path.abspath(arg))
-elif re.search('-image-', arg):
+elif re.search(r'-image-|-image$', arg):
# Lazy rootfs
self.rootfs = arg
else:
--
git-series 0.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v5 07/12] ovmf_git.bb: enable Secure Boot
When enabled via PACCKAGECONFIG = "secureboot" (off by default because
of the extra work and license change), the recipe compiles OVMF twice,
once without Secure Boot, once with. This is the same approach as in
https://src.fedoraproject.org/cgit/rpms/edk2.git/tree/edk2.spec
The results are "ovmf.qcow2" and "ovmf.secboot.qcow2" in the
image deploy directory, so
runqemu ovmf.secboot
will boot with Secure Boot enabled.
ovmf.secboot.code.qcow2 is provided for those who want separate code
and variable flash drives. The normal ovmf.vars.qcow2 can be used with
it.
In contrast to Fedora, no attempt is made to strip potentially patent
encumbered algorithms out of the OpenSSL archive. OVMF does not use
the ones considered problematic for Fedora, so this shouldn't be a
problem.
Fixes: luv-yocto/#38
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/recipes-core/ovmf/ovmf_git.bb | 36 +++-
1 file changed, 36 insertions(+)
diff --git a/meta/recipes-core/ovmf/ovmf_git.bb
b/meta/recipes-core/ovmf/ovmf_git.bb
index 9989025..bdec6aa 100644
--- a/meta/recipes-core/ovmf/ovmf_git.bb
+++ b/meta/recipes-core/ovmf/ovmf_git.bb
@@ -1,8 +1,15 @@
DESCRIPTION = "OVMF - UEFI firmware for Qemu and KVM"
HOMEPAGE =
"http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF;
LICENSE = "BSD"
+LICENSE_class-target = "${@bb.utils.contains('PACKAGECONFIG', 'secureboot',
'BSD & OpenSSL', 'BSD', d)}"
LIC_FILES_CHKSUM =
"file://OvmfPkg/License.txt;md5=343dc88e82ff33d042074f62050c3496"
+# Enabling Secure Boot adds a dependency on OpenSSL and implies
+# compiling OVMF twice, so it is disabled by default. Distros
+# may change that default.
+PACKAGECONFIG ??= ""
+PACKAGECONFIG[secureboot] = ",,,"
+
SRC_URI = "git://github.com/tianocore/edk2.git;branch=master \
file://0001-BaseTools-Force-tools-variables-to-host-toolchain.patch \
file://0001-OvmfPkg-Enable-BGRT-in-OVMF.patch \
@@ -10,7 +17,13 @@ SRC_URI = "git://github.com/tianocore/edk2.git;branch=master
\
file://0003-BaseTools-makefile-adjust-to-build-in-under-bitbake.patch \
"
+SRC_URI_append_class-target = " \
+ ${@bb.utils.contains('PACKAGECONFIG', 'secureboot',
'http://www.openssl.org/source/openssl-1.0.2j.tar.gz;name=openssl;subdir=${S}/CryptoPkg/Library/OpensslLib',
'', d)} \
+"
+
SRCREV="4575a602ca6072ee9d04150b38bfb143cbff8588"
+SRC_URI[openssl.md5sum] = "96322138f0b69e61b7212bc53d5e912b"
+SRC_URI[openssl.sha256sum] =
"e7aff292be21c259c6af26469c7a9b3ba26e9abaaffd325e3dccc9785256c431"
inherit deploy
@@ -32,6 +45,11 @@ BUILD_OPTIMIZATION="-pipe"
# OVMF supports IA only, although it could conceivably support ARM someday.
COMPATIBLE_HOST='(i.86|x86_64).*'
+# Additional build flags for OVMF with Secure Boot.
+# Fedora also uses "-D SMM_REQUIRE -D EXCLUDE_SHELL_FROM_FD".
+OVMF_SECURE_BOOT_EXTRA_FLAGS ??= ""
+OVMF_SECURE_BOOT_FLAGS = "-DSECURE_BOOT_ENABLE=TRUE
${OVMF_SECURE_BOOT_EXTRA_FLAGS}"
+
do_patch_append_class-native() {
bb.build.exec_func('do_fix_iasl', d)
bb.build.exec_func('do_fix_toolchain', d)
@@ -112,10 +130,27 @@ do_compile_class-target() {
bbnote FIXED_GCCVER is ${FIXED_GCCVER}
build_dir="${S}/Build/Ovmf$OVMF_DIR_SUFFIX/RELEASE_${FIXED_GCCVER}"
+bbnote "Building without Secure Boot."
+rm -rf ${S}/Build/Ovmf$OVMF_DIR_SUFFIX
${S}/OvmfPkg/build.sh $PARALLEL_JOBS -a $OVMF_ARCH -b RELEASE -t
${FIXED_GCCVER}
ln ${build_dir}/FV/OVMF.fd ${WORKDIR}/ovmf/ovmf.fd
ln ${build_dir}/FV/OVMF_CODE.fd ${WORKDIR}/ovmf/ovmf.code.fd
ln ${build_dir}/FV/OVMF_VARS.fd ${WORKDIR}/ovmf/ovmf.vars.fd
+
+if ${@bb.utils.contains('PACKAGECONFIG', 'secureboot', 'true', 'false',
d)}; then
+# See CryptoPkg/Library/OpensslLib/Patch-HOWTO.txt and
+# https://src.fedoraproject.org/cgit/rpms/edk2.git/tree/ for
+# building with Secure Boot enabled.
+bbnote "Building with Secure Boot."
+rm -rf ${S}/Build/Ovmf$OVMF_DIR_SUFFIX
+if ! [ -f
${S}/CryptoPkg/Library/OpensslLib/openssl-*/edk2-patch-applied ]; then
+( cd ${S}/CryptoPkg/Library/OpensslLib/openssl-* && patch -p1
<$(echo ../EDKII_openssl-*.patch) && touch edk2-patch-applied )
+fi
+( cd ${S}/CryptoPkg/Library/OpensslLib/ && ./Install.sh )
+${S}/OvmfPkg/build.sh $PARALLEL_JOBS -a $OVMF_ARCH -b RELEASE -t
${FIXED_GCCVER} ${OVMF_SECURE_BOOT_FLAGS}
+ln ${build_dir}/FV/OVMF.fd ${WORKDIR}/ovmf/ovmf.secboot.fd
+ln ${build_dir}/FV/OVMF_CODE.fd ${WORKDIR}/ovmf/ovmf.secboot.code.fd
+fi
}
do_install_class-native() {
@@ -135,6 +170,7 @@ do_deploy_class-target() {
ovmf \
ovmf.code \
[OE-core] [PATCH v5 05/12] ovmf: deploy firmware in image directory
When used with '-drive if=pflash', qemu will store UEFI variables
inside the firmware image file. That is unexpected for a file located in
the sysroot, which should be read-only, while it is normal for image
files in the deploy/images directory. Therefore that directory is a
better place for use with runqemu.
The name was chose so that "runqemu ovmf" can be used as shorthand for
"runqemu /ovmf.qcow2" by treating "ovmf" as the base name
of the firmware file. "ovmf.secboot.qcow2" is meant to be used for the
Secure Boot enabled firmware.
qcow2 is used because it is needed for "savevm" snapshots of a virtual
machine.
With code and variables stored in the same ovmf.qcow2 it is not
possible to update the firmware code without also overwriting the
variables. For users who care about persistent variables, the code and
variables are also provided as separate files, in ovmf.code.qcow2 and
ovmf.vars.qcow2.
The traditional usage of OVMF via the qemu bios parameter ("biosdir"
and/or "biosfilename" in runqemu) is no longer recommended, and
therefore this recipe no longer provides the bios.bin file. Instead,
OVMF is meant to be used as flash drive in qemu. See the "runqemu:
support UEFI with OVMF firmware" patch for details on how to use OVMF
that way.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/recipes-core/ovmf/ovmf_git.bb | 42 ++-
1 file changed, 31 insertions(+), 11 deletions(-)
diff --git a/meta/recipes-core/ovmf/ovmf_git.bb
b/meta/recipes-core/ovmf/ovmf_git.bb
index 13b583b..895ed6c 100644
--- a/meta/recipes-core/ovmf/ovmf_git.bb
+++ b/meta/recipes-core/ovmf/ovmf_git.bb
@@ -12,11 +12,13 @@ SRC_URI =
"git://github.com/tianocore/edk2.git;branch=master \
SRCREV="4575a602ca6072ee9d04150b38bfb143cbff8588"
+inherit deploy
+
PARALLEL_MAKE = ""
S = "${WORKDIR}/git"
-DEPENDS_class-native="util-linux-native iasl-native ossp-uuid-native"
+DEPENDS_class-native="util-linux-native iasl-native ossp-uuid-native
qemu-native"
DEPENDS_class-target="ovmf-native"
@@ -97,9 +99,22 @@ do_compile_class-target() {
OVMF_ARCH="IA32"
fi
+# ${WORKDIR}/ovmf is a well-known location where do_install and
+# do_deploy will be able to find the files.
+rm -rf ${WORKDIR}/ovmf
+mkdir ${WORKDIR}/ovmf
+OVMF_DIR_SUFFIX="X64"
+if [ "${TARGET_ARCH}" != "x86_64" ] ; then
+OVMF_DIR_SUFFIX="Ia32" # Note the different capitalization
+fi
FIXED_GCCVER=$(fixup_target_tools ${GCC_VER})
-echo FIXED_GCCVER is ${FIXED_GCCVER}
+bbnote FIXED_GCCVER is ${FIXED_GCCVER}
+build_dir="${S}/Build/Ovmf$OVMF_DIR_SUFFIX/RELEASE_${FIXED_GCCVER}"
+
${S}/OvmfPkg/build.sh -a $OVMF_ARCH -b RELEASE -t ${FIXED_GCCVER}
+ln ${build_dir}/FV/OVMF.fd ${WORKDIR}/ovmf/ovmf.fd
+ln ${build_dir}/FV/OVMF_CODE.fd ${WORKDIR}/ovmf/ovmf.code.fd
+ln ${build_dir}/FV/OVMF_VARS.fd ${WORKDIR}/ovmf/ovmf.vars.fd
}
do_install_class-native() {
@@ -108,16 +123,21 @@ do_install_class-native() {
}
do_install_class-target() {
-OVMF_DIR_SUFFIX="X64"
-if [ "${TARGET_ARCH}" != "x86_64" ] ; then
-OVMF_DIR_SUFFIX="Ia32" # Note the different capitalization
-fi
-install -d ${D}${datadir}/ovmf
+}
-FIXED_GCCVER=$(fixup_target_tools ${GCC_VER})
-build_dir="${S}/Build/Ovmf$OVMF_DIR_SUFFIX/RELEASE_${FIXED_GCCVER}"
-install -m 0755 ${build_dir}/FV/OVMF.fd \
- ${D}${datadir}/ovmf/bios.bin
+do_deploy() {
+}
+do_deploy[cleandirs] = "${DEPLOYDIR}"
+do_deploy_class-target() {
+# For use with "runqemu ovmf".
+for i in \
+ovmf \
+ovmf.code \
+ovmf.vars \
+; do
+qemu-img convert -f raw -O qcow2 ${WORKDIR}/ovmf/$i.fd
${DEPLOYDIR}/$i.qcow2
+done
}
+addtask do_deploy after do_compile before do_build
BBCLASSEXTEND = "native"
--
git-series 0.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v5 08/12] runqemu: fix undefined variable reference in check_arg_path()
'arg' isn't defined, the right name there is 'p'.
This fixes a rather obscure error message when that code path
ends up being taken:
$ runqemu some/existing-file-name
runqemu - ERROR - name 'arg' is not defined
runqemu - ERROR - Try 'runqemu help' on how to use it
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
scripts/runqemu | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/runqemu b/scripts/runqemu
index 434b1c2..17d79e9 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -292,7 +292,7 @@ class BaseConfig(object):
else:
raise Exception("Can't find FSTYPE from: %s" % p)
-elif os.path.isdir(p) or re.search(':', arg) and re.search('/', arg):
+elif os.path.isdir(p) or re.search(':', p) and re.search('/', p):
if self.is_deploy_dir_image(p):
logger.info('DEPLOY_DIR_IMAGE: %s' % p)
self.set("DEPLOY_DIR_IMAGE", p)
--
git-series 0.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v5 06/12] ovmf_git.bb: enable parallel compilation
The Fedora srpm [1] seems to have no problems with parallel
compilation, so let's also use that for the target. The native
tools however indeed have dependency problems:
| test_Ecc_CParser (CheckPythonSyntax.Tests) ... gcc -o ../bin/EfiRom
-L/fast/build/ostro/x86/tmp-glibc/sysroots/x86_64-linux/usr/lib
-L/fast/build/ostro/x86/tmp-glibc/sysroots/x86_64-linux/lib
-Wl,-rpath-link,/fast/build/ostro/x86/tmp-glibc/sysroots/x86_64-linux/usr/lib
-Wl,-rpath-link,/fast/build/ostro/x86/tmp-glibc/sysroots/x86_64-linux/lib
-Wl,-rpath,/fast/build/ostro/x86/tmp-glibc/sysroots/x86_64-linux/usr/lib
-Wl,-rpath,/fast/build/ostro/x86/tmp-glibc/sysroots/x86_64-linux/lib -Wl,-O1
EfiRom.o -L../libs -lCommon
| /usr/bin/ld: cannot find -lCommon
| collect2: error: ld returned 1 exit status
ERROR: Task (virtual:native:.../meta/recipes-core/ovmf/ovmf_git.bb:do_compile)
failed with exit code '1'
[1] https://src.fedoraproject.org/cgit/rpms/edk2.git/tree/edk2.spec
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/recipes-core/ovmf/ovmf_git.bb | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/ovmf/ovmf_git.bb
b/meta/recipes-core/ovmf/ovmf_git.bb
index 895ed6c..9989025 100644
--- a/meta/recipes-core/ovmf/ovmf_git.bb
+++ b/meta/recipes-core/ovmf/ovmf_git.bb
@@ -14,7 +14,7 @@ SRCREV="4575a602ca6072ee9d04150b38bfb143cbff8588"
inherit deploy
-PARALLEL_MAKE = ""
+PARALLEL_MAKE_class-native = ""
S = "${WORKDIR}/git"
@@ -94,6 +94,7 @@ do_compile_class-native() {
do_compile_class-target() {
export LFLAGS="${LDFLAGS}"
+PARALLEL_JOBS="${@ '${PARALLEL_MAKE}'.replace('-j', '-n')}"
OVMF_ARCH="X64"
if [ "${TARGET_ARCH}" != "x86_64" ] ; then
OVMF_ARCH="IA32"
@@ -111,7 +112,7 @@ do_compile_class-target() {
bbnote FIXED_GCCVER is ${FIXED_GCCVER}
build_dir="${S}/Build/Ovmf$OVMF_DIR_SUFFIX/RELEASE_${FIXED_GCCVER}"
-${S}/OvmfPkg/build.sh -a $OVMF_ARCH -b RELEASE -t ${FIXED_GCCVER}
+${S}/OvmfPkg/build.sh $PARALLEL_JOBS -a $OVMF_ARCH -b RELEASE -t
${FIXED_GCCVER}
ln ${build_dir}/FV/OVMF.fd ${WORKDIR}/ovmf/ovmf.fd
ln ${build_dir}/FV/OVMF_CODE.fd ${WORKDIR}/ovmf/ovmf.code.fd
ln ${build_dir}/FV/OVMF_VARS.fd ${WORKDIR}/ovmf/ovmf.vars.fd
--
git-series 0.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v5 03/12] ovmf: move from meta-luv to OE-core
From: meta-luv <l...@lists.01.org> This is an unmodified copy of github.com/01org/luv-yocto/meta-luv/recipes-core/ovmf revision 4be4329. Signed-off-by: Patrick Ohly <patrick.o...@intel.com> --- meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.patch | 48 +- meta/recipes-core/ovmf/ovmf/0001-OvmfPkg-Enable-BGRT-in-OVMF.patch | 110 +- meta/recipes-core/ovmf/ovmf/0002-ovmf-update-path-to-native-BaseTools.patch | 32 +++- meta/recipes-core/ovmf/ovmf/0003-BaseTools-makefile-adjust-to-build-in-under-bitbake.patch | 39 +++- meta/recipes-core/ovmf/ovmf_git.bb | 121 - 5 files changed, 350 insertions(+) create mode 100644 meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.patch create mode 100644 meta/recipes-core/ovmf/ovmf/0001-OvmfPkg-Enable-BGRT-in-OVMF.patch create mode 100644 meta/recipes-core/ovmf/ovmf/0002-ovmf-update-path-to-native-BaseTools.patch create mode 100644 meta/recipes-core/ovmf/ovmf/0003-BaseTools-makefile-adjust-to-build-in-under-bitbake.patch create mode 100644 meta/recipes-core/ovmf/ovmf_git.bb diff --git a/meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.patch b/meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.patch new file mode 100644 index 000..644b99d --- /dev/null +++ b/meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.patch @@ -0,0 +1,48 @@ +From 6e24bde1979c2d7149b37d142fb882dfde0e9770 Mon Sep 17 00:00:00 2001 +From: Matt Fleming <matt.flem...@intel.com> +Date: Fri, 27 Jun 2014 11:12:18 +0100 +Subject: [PATCH] BaseTools: Force tools variables to host toolchain + +Signed-off-by: Matt Fleming <matt.flem...@intel.com> +--- + BaseTools/Source/C/Makefiles/app.makefile | 7 +++ + BaseTools/Source/C/VfrCompile/GNUmakefile | 5 + + 2 files changed, 12 insertions(+) + +diff --git a/BaseTools/Source/C/Makefiles/app.makefile b/BaseTools/Source/C/Makefiles/app.makefile +index 19269a1..62aad0f 100644 +--- a/BaseTools/Source/C/Makefiles/app.makefile b/BaseTools/Source/C/Makefiles/app.makefile +@@ -16,6 +16,13 @@ include $(MAKEROOT)/Makefiles/header.makefile + + APPLICATION = $(MAKEROOT)/bin/$(APPNAME) + ++CC = gcc ++CXX = g++ ++AS = gcc ++AR = ar ++LD = ld ++LINKER = $(CC) ++ + .PHONY:all + all: $(MAKEROOT)/bin $(APPLICATION) + +diff --git a/BaseTools/Source/C/VfrCompile/GNUmakefile b/BaseTools/Source/C/VfrCompile/GNUmakefile +index 82005e1..5ac5f7e 100644 +--- a/BaseTools/Source/C/VfrCompile/GNUmakefile b/BaseTools/Source/C/VfrCompile/GNUmakefile +@@ -26,6 +26,11 @@ OBJECTS = AParser.o DLexerBase.o ATokenBuffer.o EfiVfrParser.o VfrLexer.o VfrSyn + + VFR_CPPFLAGS = -DPCCTS_USE_NAMESPACE_STD $(CPPFLAGS) + ++CC = gcc ++CXX = g++ ++AS = gcc ++AR = ar ++LD = ld + LINKER = $(BUILD_CXX) + + EXTRA_CLEAN_OBJECTS = EfiVfrParser.cpp EfiVfrParser.h VfrParser.dlg VfrTokens.h VfrLexer.cpp VfrLexer.h VfrSyntax.cpp tokens.h +-- +1.9.0 + diff --git a/meta/recipes-core/ovmf/ovmf/0001-OvmfPkg-Enable-BGRT-in-OVMF.patch b/meta/recipes-core/ovmf/ovmf/0001-OvmfPkg-Enable-BGRT-in-OVMF.patch new file mode 100644 index 000..4531a6d --- /dev/null +++ b/meta/recipes-core/ovmf/ovmf/0001-OvmfPkg-Enable-BGRT-in-OVMF.patch @@ -0,0 +1,110 @@ +From 66a4020c3c2163aeffc9757851f33c346ecfd870 Mon Sep 17 00:00:00 2001 +From: Sai Praneeth Prakhya <sai.praneeth.prak...@intel.com> +Date: Mon, 4 Apr 2016 12:15:12 -0700 +Subject: [PATCH] OvmfPkg: Enable BGRT in OVMF + +By default, firmware (OVMF - Open source Virtual Machine Firmware) +never publishes BGRT (Boot Graphics Resource Table) and in the boot +process Linux kernel checks for this table and if it fails to find BGRT +table then corresponding code in Linux kernel is not executed. EDK II +(EFI Development Kit, thus OVMF) already has BGRT source code packaged +into it but it is excluded from the build process of OVMF. These changes +to build system of OVMF enables BGRT in 32-bit and 64-bit OVMF. + +There are only two files that need to be modified in order to do this. +The first one being OvmfPkg*.dsc (this file describes the platform) and +the second one being OvmfPkg*.fdf (this file describes firmware descriptor +volume). A *.inf file (here "BootGraphicsResourceTableDxe.inf") +describes a module (here BGRT). So, include +"BootGraphicsResourceTableDxe.inf" file in "OvmfPkg*.dsc" so that BGRT +source code will be compiled and "BootGraphicsResourceTableDxe.efi" file +is generated and we should also include +"BootGraphicsResourceTableDxe.inf" file in "OvmfPkg*.fdf" file so t
[OE-core] [PATCH v5 04/12] ovmf: explicitly depend on nasm-native
Fixes a build issue when nasm was not build already because of something else. Signed-off-by: Patrick Ohly <patrick.o...@intel.com> --- meta/recipes-core/ovmf/ovmf_git.bb | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta/recipes-core/ovmf/ovmf_git.bb b/meta/recipes-core/ovmf/ovmf_git.bb index e722db5..13b583b 100644 --- a/meta/recipes-core/ovmf/ovmf_git.bb +++ b/meta/recipes-core/ovmf/ovmf_git.bb @@ -20,6 +20,8 @@ DEPENDS_class-native="util-linux-native iasl-native ossp-uuid-native" DEPENDS_class-target="ovmf-native" +DEPENDS_append = " nasm-native" + EDK_TOOLS_DIR="edk2_basetools" # OVMF has trouble building with the default optimization of -O2. -- git-series 0.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v5 02/12] acpica: work around flex 2.6.2 code generation issue
Without this patch, linking fails with a missing implementation of
yy_scan_string. This looks like a regression in flex, because 2.6.0 generated
different code that called PrParser_scan_string
resp. DtParser_scan_string.
Working around that in acpica until this is better understood or fixed
in flex is the easiest solution for now.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/recipes-extended/acpica/acpica_20150515.bb | 1 +
meta/recipes-extended/acpica/files/rename-yy_scan_string-manually.patch | 64
2 files changed, 65 insertions(+)
create mode 100644
meta/recipes-extended/acpica/files/rename-yy_scan_string-manually.patch
diff --git a/meta/recipes-extended/acpica/acpica_20150515.bb
b/meta/recipes-extended/acpica/acpica_20150515.bb
index de897e1..c23b491 100644
--- a/meta/recipes-extended/acpica/acpica_20150515.bb
+++ b/meta/recipes-extended/acpica/acpica_20150515.bb
@@ -18,6 +18,7 @@ DEPENDS = "bison flex"
SRC_URI = "https://acpica.org/sites/acpica/files/acpica-unix2-${PV}.tar.gz \
file://no-werror.patch \
+file://rename-yy_scan_string-manually.patch \
"
SRC_URI[md5sum] = "2bc4a7ccc82de9df9fa964f784ecb29c"
SRC_URI[sha256sum] =
"61204ec56d71bc9bfa2ee2ade4c66f7e8541772ac72ef8ccc20b3f339cc96374"
diff --git
a/meta/recipes-extended/acpica/files/rename-yy_scan_string-manually.patch
b/meta/recipes-extended/acpica/files/rename-yy_scan_string-manually.patch
new file mode 100644
index 000..b62ca25
--- /dev/null
+++ b/meta/recipes-extended/acpica/files/rename-yy_scan_string-manually.patch
@@ -0,0 +1,64 @@
+From 2ab61e6ad5a9cfcde838379bc36babfaaa61afb8 Mon Sep 17 00:00:00 2001
+From: Patrick Ohly <patrick.o...@intel.com>
+Date: Fri, 20 Jan 2017 13:50:17 +0100
+Subject: [PATCH] rename yy_scan_string manually
+
+flex 2.6.0 used to generate code where yy_scan_string was mapped
+to _scan_string directly in the generated .c code.
+
+For example, generate/unix/iasl/obj/prparserlex.c:
+
+int
+PrInitLexer (
+char*String)
+{
+
+LexBuffer = PrParser_scan_string (String);
+return (LexBuffer == NULL);
+}
+
+flex 2.6.3 no longer does that, leading to a compiler warning
+and link error about yy_scan_string().
+
+Both versions generate a preamble in the beginning of prparserlex.c
+that maps several yy_* names, but yy_scan_string is not among those:
+
+...
+...
+
+Upstream-Status: Inappropriate [workaround for
https://github.com/westes/flex/issues/164]
+Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
+---
+ source/compiler/dtparser.l | 2 +-
+ source/compiler/prparser.l | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/source/compiler/dtparser.l b/source/compiler/dtparser.l
+index 3f4c2f3..eaa43ff 100644
+--- a/source/compiler/dtparser.l
b/source/compiler/dtparser.l
+@@ -120,7 +120,7 @@ DtInitLexer (
+ char*String)
+ {
+
+-LexBuffer = yy_scan_string (String);
++LexBuffer = DtParser_scan_string (String);
+ return (LexBuffer == NULL);
+ }
+
+diff --git a/source/compiler/prparser.l b/source/compiler/prparser.l
+index 10bd130..9cb3573 100644
+--- a/source/compiler/prparser.l
b/source/compiler/prparser.l
+@@ -127,7 +127,7 @@ PrInitLexer (
+ char*String)
+ {
+
+-LexBuffer = yy_scan_string (String);
++LexBuffer = PrParser_scan_string (String);
+ return (LexBuffer == NULL);
+ }
+
+--
+2.11.0
+
--
git-series 0.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v5 00/12] UEFI + Secure Boot + qemu
There seems to be a consensus that supporting UEFI in OE-core for qemu
would be valuable, and there have been some (stalled) attempts to add
it. For reference, see:
[OE-core] [PATCH V3 0/3] Add UEFI firmware for qemux86*
[OE-core] Add ovmf-native to make qemu-native/runqemu support boot UEFI
image?
https://bugzilla.yoctoproject.org/show_bug.cgi?id=5654
https://github.com/01org/luv-yocto/issues/38
This patch set includes the necessary recipes (ovmf from meta-luv, acpica from
meta-oe), some improvements to them (in particular, enabling Secure
Boot), and changes to runqemu to make it easier to boot with UEFI. A
special image recipes builds an image which can be used to lock down a
virtual machine by enrolling the "normal" pre-installed certificates.
In contrast to the first version of this patch series, one can now use
both a single OVMF firmware file as well as set up persistent
variables for a virtual machine by using two files.
Eduardo promised to add automated testing for this once it is in OE-core.
As it stands now, ovmf-shell-image and ovmf without Secure Boot enabled
should at least be part of a world build.
As discussed on this list, Ricardo and Fathi volunteered to help with
maintaining the ovmf and acpica recipes in OE-core.
Beware that "git am --keep-cr" must be used to import the ovmf patches
correctly.
Changes since V1:
- support both combined code+vars ("ovmf") and separate code
and vars flash drives ("ovmf.code ovmf.vars")
- OVMF firmware no longer installed in the target sysroot
- slightly simpler renaming from OVMF (uppercase, underscore)
to OE naming convention (lowercase, dots): now the different
ln invocation directly create files with the final name
- DEPLOYDIR needs to be cleaned explicitly (done via cleandirs varflag)
- Secure Boot support in ovmf is controlled by a PACKAGECONFIG option,
off by default
- distros and developers can add additional Secure Boot compile flags
with OVMF_SECURE_BOOT_EXTRA_FLAGS
- explain how to get ovmf built for use with runqemu via
MACHINE_ESSENTIAL_EXTRA_RDEPENDS
- IMAGE_FSTYPES_forcevariable = "wic" used in ovmf-shell-image
- remove OVMF BGRT patch
- location of "inherit deploy"
Changes since V2:
- rebased onto current master
- workaround for acpica compile issue with flex 2.6.2
Changes since V3:
- rebased onto current master (for real, this time!)
- reordered patches a bit
Changes since V4:
- revised the commit message of "ovmf: deploy firmware in image directory"
to clarify expected usage
Fathi Boudra (1):
acpica: move from meta-oe to OE-core
Patrick Ohly (10):
acpica: work around flex 2.6.2 code generation issue
ovmf: explicitly depend on nasm-native
ovmf: deploy firmware in image directory
ovmf_git.bb: enable parallel compilation
ovmf_git.bb: enable Secure Boot
runqemu: fix undefined variable reference in check_arg_path()
runqemu: also accept -image suffix for rootfs parameter
runqemu: support UEFI with OVMF firmware
ovmf: build image which enrolls standard keys
ovmf: remove BGRT patch
meta-luv (1):
ovmf: move from meta-luv to OE-core
meta/recipes-core/ovmf/ovmf-shell-image.bb
| 17 +-
meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.patch
| 48 +++-
meta/recipes-core/ovmf/ovmf/0002-ovmf-update-path-to-native-BaseTools.patch
| 32 ++-
meta/recipes-core/ovmf/ovmf/0003-BaseTools-makefile-adjust-to-build-in-under-bitbake.patch
| 39 ++-
meta/recipes-core/ovmf/ovmf/0007-OvmfPkg-EnrollDefaultKeys-application-for-enrolling-.patch
| 1124
-
meta/recipes-core/ovmf/ovmf/ovmf-shell-image.wks
|4 +-
meta/recipes-core/ovmf/ovmf_git.bb
| 201 +-
meta/recipes-extended/acpica/acpica_20150515.bb
| 47 +++-
meta/recipes-extended/acpica/acpitests/aapits-linux.patch
| 336 ++-
meta/recipes-extended/acpica/acpitests/aapits-makefile.patch
| 34 ++-
meta/recipes-extended/acpica/acpitests_20140828.bb
| 35 ++-
meta/recipes-extended/acpica/files/no-werror.patch
| 32 ++-
meta/recipes-extended/acpica/files/rename-yy_scan_string-manually.patch
| 64 -
scripts/runqemu
| 50 ++-
14 files changed, 2058 insertions(+), 5 deletions(-)
create mode 100644 meta/recipes-core/ovmf/ovmf-shell-image.bb
create mode 100644
meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.patch
create mo
[OE-core] [PATCH v5 01/12] acpica: move from meta-oe to OE-core
From: Fathi Boudra <fathi.bou...@linaro.org>
qemu support for UEFI in OE-core depends on OVMF, which needs the iasl
tools provided by this recipe. There's also an iasl recipe in
meta-luv, but than can and will be replaced by this one, thus reducing
overall maintenance work.
Copied from meta-openembedded rev fa65be9ba (current master).
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/recipes-extended/acpica/acpica_20150515.bb | 46 +-
meta/recipes-extended/acpica/acpitests/aapits-linux.patch| 336 +++-
meta/recipes-extended/acpica/acpitests/aapits-makefile.patch | 34 +-
meta/recipes-extended/acpica/acpitests_20140828.bb | 35 +-
meta/recipes-extended/acpica/files/no-werror.patch | 32 +-
5 files changed, 483 insertions(+)
create mode 100644 meta/recipes-extended/acpica/acpica_20150515.bb
create mode 100644 meta/recipes-extended/acpica/acpitests/aapits-linux.patch
create mode 100644 meta/recipes-extended/acpica/acpitests/aapits-makefile.patch
create mode 100644 meta/recipes-extended/acpica/acpitests_20140828.bb
create mode 100644 meta/recipes-extended/acpica/files/no-werror.patch
diff --git a/meta/recipes-extended/acpica/acpica_20150515.bb
b/meta/recipes-extended/acpica/acpica_20150515.bb
new file mode 100644
index 000..de897e1
--- /dev/null
+++ b/meta/recipes-extended/acpica/acpica_20150515.bb
@@ -0,0 +1,46 @@
+SUMMARY = "ACPICA tools for the development and debug of ACPI tables"
+DESCRIPTION = "The ACPI Component Architecture (ACPICA) project provides an \
+OS-independent reference implementation of the Advanced Configuration and \
+Power Interface Specification (ACPI). ACPICA code contains those portions of \
+ACPI meant to be directly integrated into the host OS as a kernel-resident \
+subsystem, and a small set of tools to assist in developing and debugging \
+ACPI tables."
+
+HOMEPAGE = "http://www.acpica.org/;
+SECTION = "console/tools"
+
+LICENSE = "BSD | GPLv2"
+LIC_FILES_CHKSUM =
"file://generate/unix/readme.txt;md5=204407e197c1a01154a48f6c6280c3aa"
+
+COMPATIBLE_HOST = "(i.86|x86_64|arm|aarch64).*-linux"
+
+DEPENDS = "bison flex"
+
+SRC_URI = "https://acpica.org/sites/acpica/files/acpica-unix2-${PV}.tar.gz \
+file://no-werror.patch \
+"
+SRC_URI[md5sum] = "2bc4a7ccc82de9df9fa964f784ecb29c"
+SRC_URI[sha256sum] =
"61204ec56d71bc9bfa2ee2ade4c66f7e8541772ac72ef8ccc20b3f339cc96374"
+
+S = "${WORKDIR}/acpica-unix2-${PV}"
+
+EXTRA_OEMAKE = "CC='${CC}' 'OPT_CFLAGS=-Wall'"
+
+do_install() {
+install -D -p -m0755 generate/unix/bin*/iasl ${D}${bindir}/iasl
+install -D -p -m0755 generate/unix/bin*/acpibin ${D}${bindir}/acpibin
+install -D -p -m0755 generate/unix/bin*/acpiexec ${D}${bindir}/acpiexec
+install -D -p -m0755 generate/unix/bin*/acpihelp ${D}${bindir}/acpihelp
+install -D -p -m0755 generate/unix/bin*/acpinames ${D}${bindir}/acpinames
+install -D -p -m0755 generate/unix/bin*/acpisrc ${D}${bindir}/acpisrc
+install -D -p -m0755 generate/unix/bin*/acpixtract ${D}${bindir}/acpixtract
+}
+
+# iasl*.bb is a subset of this recipe, so RREPLACE it
+PROVIDES = "iasl"
+RPROVIDES_${PN} += "iasl"
+RREPLACES_${PN} += "iasl"
+RCONFLIGHTS_${PN} += "iasl"
+
+NATIVE_INSTALL_WORKS = "1"
+BBCLASSEXTEND = "native"
diff --git a/meta/recipes-extended/acpica/acpitests/aapits-linux.patch
b/meta/recipes-extended/acpica/acpitests/aapits-linux.patch
new file mode 100644
index 000..7c5d6b0
--- /dev/null
+++ b/meta/recipes-extended/acpica/acpitests/aapits-linux.patch
@@ -0,0 +1,336 @@
+From: Al Stone <a...@ahs3.net>
+Date: Mon, 7 Apr 2014 19:09:37 +
+Subject: [PATCH 1/2] Fixup aapits build
+
+From http://git.linaro.org/people/al.stone/acpica-tools.git
+Upstream-status: Unknown
+
+diff -urN acpica-unix2-20130626/tests/aapits/atexec.c
acpica-unix2-20130626-aapits/tests/aapits/atexec.c
+--- acpica-unix2-20130626/tests/aapits/atexec.c2013-01-17
12:48:28.0 -0700
acpica-unix2-20130626-aapits/tests/aapits/atexec.c 2013-07-25
13:44:23.023894441 -0600
+@@ -639,6 +639,7 @@
+ }
+
+
++#if ACPI_MACHINE_WIDTH == 32
+
/***
+ *
+ * FUNCTION:AtBuildLocalRSDT
+@@ -757,8 +758,9 @@
+ LocalRSDT->Header.Checksum = (UINT8)~LocalRSDT->Header.Checksum;
+ }
+ }
++#endif
+
+
+
/***
+ *
+ * FUNCTION:AtBuildLocalXSDT
+@@ -1424,7 +1426,7 @@
+ ACPI_WARNING ((AE_INFO,
+ "Request on [%4.4s] is beyond region limit Req-%X+%X, Base=%X,
Len-%X\n",
+ (RegionObject->Region.Node)->Name.Ascii, (UINT32) Address,
+-ByteWidth, (UINT32) BufferAddress, Length));
++ByteWidth
Re: [OE-core] sysroots, wic-tools and rm_work
On Thu, 2017-01-26 at 16:39 +0100, Kristian Amlie wrote:
> It seems like wic doesn't work together with rm_work, because of its
> dependency on wic-tools. The reason is that building wic-tools will
> result in rm_work removing the very sysroot that wic needs.
>
> It's easy to fix locally by adding
>
> RM_WORK_EXCLUDE = "wic-tools"
>
> however, I think this deserves a more permanent fix, and I'm not sure
> which approach is best.
wic-tools.bb can have:
RM_WORK_EXCLUDE += "${PN}"
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] image_types.bbclass: rebuild .wks file when .wks.in changes
WKS_FILE(S) can refer to .wks.in files which get expanded during the
build by do_write_wks_template. The actual content of the .wks.in file
gets added to the recipe meta data during parsing, and thus we need to
ensure that the recipe gets re-parsed when the file changes.
This fixes two related problems:
- editing the .wks.in file and rebuilding an image did not recreate
the image unless something else changed or "bitbake -c clean" was
used explicitly
- when forcing a rebuild, the cached meta data and the actual one
do not match, leading to "ERROR: Taskhash mismatch ... for
bb.do_write_wks_template"
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/classes/image_types.bbclass | 4
1 file changed, 4 insertions(+)
diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 5b1746a68ce..50545d9fdf0 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -265,6 +265,10 @@ python () {
d.setVar('WKS_TEMPLATE_PATH', wks_file_u)
d.setVar('WKS_FILE_CHECKSUM', '${WKS_TEMPLATE_PATH}:True')
+# We need to re-parse each time the file changes, and bitbake
+# needs to be told about that explicitly.
+bb.parse.mark_dependency(d, wks_file)
+
try:
with open(wks_file, 'r') as f:
body = f.read()
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] image_types.bbclass: rebuild .wks file when .wks.in changes
WKS_FILE(S) can refer to .wks.in files which get expanded during the
build by do_write_wks_template. The actual content of the .wks.in file
gets added to the recipe meta data during parsing, and thus we need to
ensure that the recipe gets re-parsed when the file changes.
This fixes two related problems:
- editing the .wks.in file and rebuilding an image did not recreate
the image unless something else changed or "bitbake -c clean" was
used explicitly
- when forcing a rebuild, the cached meta data and the actual one
do not match, leading to "ERROR: Taskhash mismatch ... for
bb.do_write_wks_template"
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/classes/image_types.bbclass | 4
1 file changed, 4 insertions(+)
diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 5b1746a68ce..9bc1996cdb0 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -265,6 +265,10 @@ python () {
d.setVar('WKS_TEMPLATE_PATH', wks_file_u)
d.setVar('WKS_FILE_CHECKSUM', '${WKS_TEMPLATE_PATH}:True')
+# We need to re-parse each time the file changes, and bitbake
+# needs to be told about that explicitly.
+# bb.parse.mark_dependency(d, wks_file)
+
try:
with open(wks_file, 'r') as f:
body = f.read()
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCHv2] qemu: Upgrade to 2.7.1
On Mon, 2017-01-23 at 16:01 +0200, Alexander Kanavin wrote:
> On 01/20/2017 09:44 PM, Patrick Ohly wrote:
>
> > In contrast to Alexander, I would also keep
> > http://wiki.qemu-project.org/download/${BP}.tar.bz2 in qemu_2.7.1.bb
> > with SRC_URI =+ because then there can be a qemu_git.bb with a different
> > URL than the one above.
>
> I would discourage creation of such separate _git recipes, unless there
> is a clear benefit to the whole of oe-core. They are almost always
> untested and neglected, and eventually removed because they're outdated
> and broken and no one cares.
I wasn't suggesting to add one, just using the possibility that one
might want to add one as the rationale for keeping the download URL for
the tarball out of the .inc file.
It's all rather subjective and hinges on the likelihood of adding a
_git.bb (don't include it in the .inc) vs. adding more than one
versioned .bb (then including the common download in the .inc reduces
duplication).
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] socat: support native compilation
This is needed for building the swtpm TPM simulator (recipe
in meta-security).
Native compilation disables tcp-wrappers by default to simplify
the build.
"nativesdk" is added just in case that someone also wants this
in an SDK.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/recipes-connectivity/socat/socat_1.7.3.1.bb | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-connectivity/socat/socat_1.7.3.1.bb
b/meta/recipes-connectivity/socat/socat_1.7.3.1.bb
index 4da6d39..a579f1e 100644
--- a/meta/recipes-connectivity/socat/socat_1.7.3.1.bb
+++ b/meta/recipes-connectivity/socat/socat_1.7.3.1.bb
@@ -29,10 +29,13 @@ EXTRA_OECONF += "ac_cv_have_z_modifier=yes \
ac_cv_header_bsd_libutil_h=no \
"
-PACKAGECONFIG ??= "tcp-wrappers"
+PACKAGECONFIG_class-target ??= "tcp-wrappers"
+PACKAGECONFIG ??= ""
PACKAGECONFIG[tcp-wrappers] = "--enable-libwrap,--disable-libwrap,tcp-wrappers"
do_install_prepend () {
mkdir -p ${D}${bindir}
install -d ${D}${bindir} ${D}${mandir}/man1
}
+
+BBCLASSEXTEND = "native nativesdk"
--
git-series 0.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] expect: support native compilation
This is needed for building the swtpm TPM simulator (recipe
in meta-security).
"nativesdk" is added just in case that someone also wants this
in an SDK.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/recipes-devtools/expect/expect_5.45.bb | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/expect/expect_5.45.bb
b/meta/recipes-devtools/expect/expect_5.45.bb
index b4dfe15..ab22a61 100644
--- a/meta/recipes-devtools/expect/expect_5.45.bb
+++ b/meta/recipes-devtools/expect/expect_5.45.bb
@@ -43,11 +43,16 @@ do_install_append() {
sed -e 's|$dir|${libdir}|' -i ${D}${libdir}/expect${PV}/pkgIndex.tcl
}
+# Apparently the public Tcl headers are only in /usr/include/tcl8.6
+# when building for the target.
+TCL_INCLUDE_PATH = ""
+TCL_INCLUDE_PATH_class-target = "--with-tclinclude=${STAGING_INCDIR}/tcl8.6"
+
EXTRA_OECONF += "--with-tcl=${STAGING_LIBDIR} \
- --with-tclinclude=${STAGING_INCDIR}/tcl8.6 \
--enable-shared \
--enable-threads \
--disable-rpath \
+ ${TCL_INCLUDE_PATH} \
"
EXTRA_OEMAKE_install = " 'SCRIPTS=' "
@@ -62,3 +67,5 @@ FILES_${PN}-dev = "${libdir_native}/expect${PV}/libexpect*.so
\
FILES_${PN} += "${libdir}/libexpect${PV}.so \
${libdir}/expect${PV}/* \
"
+
+BBCLASSEXTEND = "native nativesdk"
--
git-series 0.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/2] enable swtpm-native
swtpm (from meta-security) can be compiled for the host and then be used to provide a virtual TPM device in qemu. However, it depends on the native flavor of some recipes in OE-core. Patrick Ohly (2): expect: support native compilation socat: support native compilation meta/recipes-connectivity/socat/socat_1.7.3.1.bb | 5 - meta/recipes-devtools/expect/expect_5.45.bb | 9 - 2 files changed, 12 insertions(+), 2 deletions(-) base-commit: 5ecdab6c2589a83bbbc522074052ff4438782102 -- git-series 0.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] runqemu: more verbose error message about missing qemuboot.conf
When invoking "runqemu" with a mistyped image or architecture name,
the resulting error message is about the missing qemuboot.conf,
without any indication about the root cause:
$ runqemu core-image-mimimal ext4 intel-corei7-64
runqemu - INFO - Assuming MACHINE = intel-corei7-64
runqemu - INFO - Running MACHINE=intel-corei7-64 bitbake -e...
runqemu - INFO - MACHINE: intel-corei7-64
runqemu - INFO - DEPLOY_DIR_IMAGE:
/fast/build/refkit/intel-corei7-64/tmp-glibc/deploy/images/intel-corei7-64
Traceback (most recent call last):
File "/work/openembedded-core/scripts/runqemu", line 1095, in
ret = main()
File "/work/openembedded-core/scripts/runqemu", line 1082, in main
config.read_qemuboot()
File "/work/openembedded-core/scripts/runqemu", line 643, in read_qemuboot
raise Exception("Failed to find .qemuboot.conf!")
Exception: Failed to find .qemuboot.conf!
Including the name of the actual file the scripts expects to find plus
adding some hints what to check for might help. The error now is:
$ runqemu core-image-mimimal ext4 intel-corei7-64
...
Exception: Failed to find .qemuboot.conf =
.../tmp-glibc/deploy/images/intel-corei7-64/core-image-mimimal-intel-corei7-64.qemuboot.conf
(wrong image name or BSP does not support running under qemu?).
The comment about the BSP is included because that would be the real
reason why the file might be missing.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
scripts/runqemu | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/runqemu b/scripts/runqemu
index 10947bb3edc..eaf38384a5b 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -640,7 +640,7 @@ class BaseConfig(object):
return
if not os.path.exists(self.qemuboot):
-raise Exception("Failed to find .qemuboot.conf!")
+raise Exception("Failed to find .qemuboot.conf = %s (wrong
image name or BSP does not support running under qemu?)." % self.qemuboot)
logger.info('CONFFILE: %s' % self.qemuboot)
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v4 05/12] ovmf: deploy firmware in image directory
On Sun, 2017-01-22 at 23:23 -0800, Ricardo Neri wrote: > On Fri, 2017-01-20 at 15:12 +0100, Patrick Ohly wrote: > > The traditional usage of ovmf via the qemu bios parameter is no longer > > supported > > I don't see dropping support for this option in this series. > > Is part of > another series? I just checked the poky repo and I still the the option > supported. Or do you mean that only the ovmf recipe will not support > exporting bios.bin? Yes, the latter. > > and therefore it is not necessary to create a "bios.bin" > > file in the target sysroot. > > Wouldn't this particular part of the patch break the existing runqemu. > If this is the case, perhaps the last patch (or a patch towards the end > of the series) can remove this functionality in both places. Could be done, but personally I prefer to add something new before taking away the old approach. This might not be applicable here (because there is no other bios), but it still "feels" safer. > On the other hand, this is a new recipe and this may not be super > critical. Especially if you meant that only OVMF will not support > installing bios.bin in sysroot. Maybe all is needed is some > clarification in the commit message. Care to suggest something? ;-) To me, "traditional usage of ovmf ... is no longer supported" already says that this is a statement about ovmf, not the bios parameter, so I'm not sure how to reword this. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCHv3] qemu: Upgrade to 2.7.1
On Fri, 2017-01-20 at 16:15 -0600, Aníbal Limón wrote:
> Minor upgrade contains fixes from 2.7.0.
>
> Removed patches (already in upstream):
[...]
> diff --git a/meta/recipes-devtools/qemu/qemu_2.7.0.bb
> b/meta/recipes-devtools/qemu/qemu_2.7.1.bb
> similarity index 66%
> rename from meta/recipes-devtools/qemu/qemu_2.7.0.bb
> rename to meta/recipes-devtools/qemu/qemu_2.7.1.bb
> index 0d680a7..8180c5f 100644
> --- a/meta/recipes-devtools/qemu/qemu_2.7.0.bb
> +++ b/meta/recipes-devtools/qemu/qemu_2.7.1.bb
> @@ -9,16 +9,14 @@ SRC_URI +=
> "file://configure-fix-Darwin-target-detection.patch \
> file://no-valgrind.patch \
> file://pathlimit.patch \
> file://qemu-2.5.0-cflags.patch \
> -file://0001-virtio-zero-vq-inuse-in-virtio_reset.patch \
> -file://0002-fix-CVE-2016-7423.patch \
> file://0003-fix-CVE-2016-7908.patch \
> file://0004-fix-CVE-2016-7909.patch \
> -
> file://0001-pci-assign-sync-MSI-MSI-X-cap-and-table-with-PCIDevi.patch \
> "
>
> -SRC_URI_prepend = "http://wiki.qemu-project.org/download/${BP}.tar.bz2;
> -SRC_URI[md5sum] = "08d4d06d1cb598efecd796137f4844ab"
> -SRC_URI[sha256sum] =
> "326e739506ba690daf69fc17bd3913a6c313d9928d743bd8eddb82f403f81e53"
> +SRC_URI =+ "http://wiki.qemu-project.org/download/${BP}.tar.bz2;
> +
> +SRC_URI[md5sum] = "a315bc51ed443a08d2cf1416d76b9ab4"
> +SRC_URI[sha256sum] =
> "68636788eb69bcb0b44ba220b32b50495d6bd5712a934c282217831c4822958f"
Looks good to me, thanks.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCHv2] qemu: Upgrade to 2.7.1
On Fri, 2017-01-20 at 12:12 -0600, Aníbal Limón wrote:
> --- a/meta/recipes-devtools/qemu/qemu.inc
> +++ b/meta/recipes-devtools/qemu/qemu.inc
> @@ -9,12 +9,11 @@ require qemu-targets.inc
> inherit autotools ptest
> BBCLASSEXTEND = "native nativesdk"
>
> -PR = "r1"
> -
> # QEMU_TARGETS is overridable variable
> QEMU_TARGETS ?= "arm aarch64 i386 mips mipsel mips64 mips64el ppc sh4
> x86_64"
>
> SRC_URI = "\
> +http://wiki.qemu-project.org/download/${BP}.tar.bz2 \
> file://powerpc_rom.bin \
> file://disable-grabs.patch \
> file://exclude-some-arm-EABI-obsolete-syscalls.patch \
> @@ -24,6 +23,9 @@ SRC_URI = "\
> file://0001-target-mips-add-24KEc-CPU-definition.patch \
> "
>
> +SRC_URI[md5sum] = "a315bc51ed443a08d2cf1416d76b9ab4"
> +SRC_URI[sha256sum] =
> "68636788eb69bcb0b44ba220b32b50495d6bd5712a934c282217831c4822958f"
Slight misunderstanding, I suppose. The *URL* is independent of the
version and could be added in qemu.inc, but the hashes are version
dependent and are better suited for qemu_2.7.1.bb. At least that's how I
would do it.
In contrast to Alexander, I would also keep
http://wiki.qemu-project.org/download/${BP}.tar.bz2 in qemu_2.7.1.bb
with SRC_URI =+ because then there can be a qemu_git.bb with a different
URL than the one above.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v4 02/12] acpica: work around flex 2.6.2 code generation issue
On Fri, 2017-01-20 at 15:12 +0100, Patrick Ohly wrote: > Without this patch, linking fails with a missing implementation of > yy_scan_string. This looks like a regression in flex, because 2.6.0 generated > different code that called PrParser_scan_string > resp. DtParser_scan_string. > > Working around that in acpica until this is better understood or fixed > in flex is the easiest solution for now. It turned out that flex 2.6.3 has a fix for the problem. But the github issue tracker for flex has several people who reported issues with 2.6.3 (affecting gdb, binutils, grub) that we probably should wait a bit before trying to update to that release. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v4 03/12] ovmf: move from meta-luv to OE-core
From: meta-luv <l...@lists.01.org> This is an unmodified copy of github.com/01org/luv-yocto/meta-luv/recipes-core/ovmf revision 4be4329. Signed-off-by: Patrick Ohly <patrick.o...@intel.com> --- meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.patch | 48 +- meta/recipes-core/ovmf/ovmf/0001-OvmfPkg-Enable-BGRT-in-OVMF.patch | 110 +- meta/recipes-core/ovmf/ovmf/0002-ovmf-update-path-to-native-BaseTools.patch | 32 +++- meta/recipes-core/ovmf/ovmf/0003-BaseTools-makefile-adjust-to-build-in-under-bitbake.patch | 39 +++- meta/recipes-core/ovmf/ovmf_git.bb | 121 - 5 files changed, 350 insertions(+) create mode 100644 meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.patch create mode 100644 meta/recipes-core/ovmf/ovmf/0001-OvmfPkg-Enable-BGRT-in-OVMF.patch create mode 100644 meta/recipes-core/ovmf/ovmf/0002-ovmf-update-path-to-native-BaseTools.patch create mode 100644 meta/recipes-core/ovmf/ovmf/0003-BaseTools-makefile-adjust-to-build-in-under-bitbake.patch create mode 100644 meta/recipes-core/ovmf/ovmf_git.bb diff --git a/meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.patch b/meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.patch new file mode 100644 index 000..644b99d --- /dev/null +++ b/meta/recipes-core/ovmf/ovmf/0001-BaseTools-Force-tools-variables-to-host-toolchain.patch @@ -0,0 +1,48 @@ +From 6e24bde1979c2d7149b37d142fb882dfde0e9770 Mon Sep 17 00:00:00 2001 +From: Matt Fleming <matt.flem...@intel.com> +Date: Fri, 27 Jun 2014 11:12:18 +0100 +Subject: [PATCH] BaseTools: Force tools variables to host toolchain + +Signed-off-by: Matt Fleming <matt.flem...@intel.com> +--- + BaseTools/Source/C/Makefiles/app.makefile | 7 +++ + BaseTools/Source/C/VfrCompile/GNUmakefile | 5 + + 2 files changed, 12 insertions(+) + +diff --git a/BaseTools/Source/C/Makefiles/app.makefile b/BaseTools/Source/C/Makefiles/app.makefile +index 19269a1..62aad0f 100644 +--- a/BaseTools/Source/C/Makefiles/app.makefile b/BaseTools/Source/C/Makefiles/app.makefile +@@ -16,6 +16,13 @@ include $(MAKEROOT)/Makefiles/header.makefile + + APPLICATION = $(MAKEROOT)/bin/$(APPNAME) + ++CC = gcc ++CXX = g++ ++AS = gcc ++AR = ar ++LD = ld ++LINKER = $(CC) ++ + .PHONY:all + all: $(MAKEROOT)/bin $(APPLICATION) + +diff --git a/BaseTools/Source/C/VfrCompile/GNUmakefile b/BaseTools/Source/C/VfrCompile/GNUmakefile +index 82005e1..5ac5f7e 100644 +--- a/BaseTools/Source/C/VfrCompile/GNUmakefile b/BaseTools/Source/C/VfrCompile/GNUmakefile +@@ -26,6 +26,11 @@ OBJECTS = AParser.o DLexerBase.o ATokenBuffer.o EfiVfrParser.o VfrLexer.o VfrSyn + + VFR_CPPFLAGS = -DPCCTS_USE_NAMESPACE_STD $(CPPFLAGS) + ++CC = gcc ++CXX = g++ ++AS = gcc ++AR = ar ++LD = ld + LINKER = $(BUILD_CXX) + + EXTRA_CLEAN_OBJECTS = EfiVfrParser.cpp EfiVfrParser.h VfrParser.dlg VfrTokens.h VfrLexer.cpp VfrLexer.h VfrSyntax.cpp tokens.h +-- +1.9.0 + diff --git a/meta/recipes-core/ovmf/ovmf/0001-OvmfPkg-Enable-BGRT-in-OVMF.patch b/meta/recipes-core/ovmf/ovmf/0001-OvmfPkg-Enable-BGRT-in-OVMF.patch new file mode 100644 index 000..4531a6d --- /dev/null +++ b/meta/recipes-core/ovmf/ovmf/0001-OvmfPkg-Enable-BGRT-in-OVMF.patch @@ -0,0 +1,110 @@ +From 66a4020c3c2163aeffc9757851f33c346ecfd870 Mon Sep 17 00:00:00 2001 +From: Sai Praneeth Prakhya <sai.praneeth.prak...@intel.com> +Date: Mon, 4 Apr 2016 12:15:12 -0700 +Subject: [PATCH] OvmfPkg: Enable BGRT in OVMF + +By default, firmware (OVMF - Open source Virtual Machine Firmware) +never publishes BGRT (Boot Graphics Resource Table) and in the boot +process Linux kernel checks for this table and if it fails to find BGRT +table then corresponding code in Linux kernel is not executed. EDK II +(EFI Development Kit, thus OVMF) already has BGRT source code packaged +into it but it is excluded from the build process of OVMF. These changes +to build system of OVMF enables BGRT in 32-bit and 64-bit OVMF. + +There are only two files that need to be modified in order to do this. +The first one being OvmfPkg*.dsc (this file describes the platform) and +the second one being OvmfPkg*.fdf (this file describes firmware descriptor +volume). A *.inf file (here "BootGraphicsResourceTableDxe.inf") +describes a module (here BGRT). So, include +"BootGraphicsResourceTableDxe.inf" file in "OvmfPkg*.dsc" so that BGRT +source code will be compiled and "BootGraphicsResourceTableDxe.efi" file +is generated and we should also include +"BootGraphicsResourceTableDxe.inf" file in "OvmfPkg*.fdf" file so t
[OE-core] [PATCH v4 09/12] runqemu: also accept -image suffix for rootfs parameter
The magic detection of the rootfs parameter only worked for image
recipes which embedd the "image" string in the middle, as in
"core-image-minimal".
Sometimes it is more natural to call an image "something-image". To
get such an image detected by runqemu, "-image" at the end of a
parameter must also cause that parameter to be treated as the rootfs
parameter.
Inside the image directory, "something-image" has an - suffix
and thus no change is needed for those usages of
re.search('-image-'). However, while at it also enhance those string
searches a bit (no need for re; any()+map() a bit closer to the
intended logic).
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
scripts/runqemu | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/scripts/runqemu b/scripts/runqemu
index 17d79e9..4d7168c 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -218,7 +218,7 @@ class BaseConfig(object):
if not re.search('.qemuboot.conf$', '\n'.join(os.listdir(p)),
re.M):
logger.info("Can't find required *.qemuboot.conf in %s" % p)
return False
-if not re.search('-image-', '\n'.join(os.listdir(p))):
+if not any(map(lambda name: '-image-' in name, os.listdir(p))):
logger.info("Can't find *-image-* in %s" % p)
return False
return True
@@ -267,7 +267,7 @@ class BaseConfig(object):
re.search('zImage', p) or re.search('vmlinux', p) or \
re.search('fitImage', p) or re.search('uImage', p):
self.kernel = p
-elif os.path.exists(p) and (not os.path.isdir(p)) and
re.search('-image-', os.path.basename(p)):
+elif os.path.exists(p) and (not os.path.isdir(p)) and '-image-' in
os.path.basename(p):
self.rootfs = p
# Check filename against self.fstypes can hanlde .cpio.gz,
# otherwise, its type would be "gz", which is incorrect.
@@ -381,7 +381,7 @@ class BaseConfig(object):
self.kernel_cmdline_script += ' %s' % arg[len('bootparams='):]
elif os.path.exists(arg) or (re.search(':', arg) and
re.search('/', arg)):
self.check_arg_path(os.path.abspath(arg))
-elif re.search('-image-', arg):
+elif re.search(r'-image-|-image$', arg):
# Lazy rootfs
self.rootfs = arg
else:
--
git-series 0.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v4 11/12] ovmf: build image which enrolls standard keys
When booting a qemu virtual machine with ovmf.secboot, it comes up
with no keys installed and thus Secure Boot disabled. To lock down
the machine like a typical PC, one has to enroll the same keys
that PC vendors normally install, i.e. the ones from Microsoft.
This can be done manually (see
https://wiki.ubuntu.com/SecurityTeam/SecureBoot and
https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_into_UEFI_Secure_Boot_White_Paper.pdf)
or automatically with the EnrollDefaultKeys.efi helper
from the Fedora ovmf rpm.
To use this with qemu:
$ bitbake ovmf-shell-image
...
$ runqemu serial nographic qemux86 ovmf-shell-image wic ovmf.secboot
...
UEFI Interactive Shell v2.1
EDK II
UEFI v2.60 (EDK II, 0x0001)
Mapping table
FS0: Alias(s):HD2b:;BLK4:
PciRoot(0x0)/Pci(0x5,0x0)/HD(1,GPT,06AEF759-3982-4AF6-B517-70BA6304FC1C,0x800,0x566C)
BLK0: Alias(s):
PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x0)
BLK1: Alias(s):
PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x1)
BLK2: Alias(s):
PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)
BLK3: Alias(s):
PciRoot(0x0)/Pci(0x5,0x0)
Press ESC in 1 seconds to skip startup.nsh or any other key to continue.
Shell> fs0:EnrollDefaultKeys.efi
info: SetupMode=1 SecureBoot=0 SecureBootEnable=0 CustomMode=0 VendorKeys=1
info: SetupMode=0 SecureBoot=1 SecureBootEnable=1 CustomMode=0 VendorKeys=0
info: success
Shell> reset
Remember that this will modify
deploy/images/qemux86/ovmf.secboot.qcow2, so make a copy and use the
full path of that copy instead of the "ovmf" argument if needed.
The ovmf-shell-image contains an EFI shell, which is what got started
here directly. After enrolling the keys, Secure Boot is active and the
same image cannot be booted anymore, so the BIOS goes through the
normal boot targets (including network boot, which can take a while to
time out), and ends up in the internal EFI shell. Trying to invoke
bootia32.efi (the shell from the image) or EnrollDefaultKeys.efi then
fails:
Shell> bootia32.efi
Command Error Status: Security Violation
The main purpose at the moment is to test that Secure Boot enforcement
really works. If we had a way to sign generated images, that part could
also be tested by booting in a locked down qemu instance.
0007-OvmfPkg-EnrollDefaultKeys-application-for-enrolling-.patch is
from
https://src.fedoraproject.org/cgit/rpms/edk2.git/tree/0007-OvmfPkg-EnrollDefaultKeys-application-for-enrolling-.patch?id=b1781931894bf2057464e634beed68b1e3218c9e
with one line changed to fix
https://bugzilla.redhat.com/show_bug.cgi?id=132502:
"EFI_STATUS Status = EFI_SUCCESS;" in EnrollListOfX509Certs() lacked
the initializer.
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
meta/recipes-core/ovmf/ovmf-shell-image.bb
| 17 +-
meta/recipes-core/ovmf/ovmf/0007-OvmfPkg-EnrollDefaultKeys-application-for-enrolling-.patch
| 1124
-
meta/recipes-core/ovmf/ovmf/ovmf-shell-image.wks
|4 +-
meta/recipes-core/ovmf/ovmf_git.bb
| 22 +-
4 files changed, 1167 insertions(+)
create mode 100644 meta/recipes-core/ovmf/ovmf-shell-image.bb
create mode 100644
meta/recipes-core/ovmf/ovmf/0007-OvmfPkg-EnrollDefaultKeys-application-for-enrolling-.patch
create mode 100644 meta/recipes-core/ovmf/ovmf/ovmf-shell-image.wks
diff --git a/meta/recipes-core/ovmf/ovmf-shell-image.bb
b/meta/recipes-core/ovmf/ovmf-shell-image.bb
new file mode 100644
index 000..029547b
--- /dev/null
+++ b/meta/recipes-core/ovmf/ovmf-shell-image.bb
@@ -0,0 +1,17 @@
+DESCRIPTION = "boot image with UEFI shell and tools"
+
+# For this image recipe, only the wic format with a
+# single vfat partition makes sense.
+IMAGE_FSTYPES_forcevariable = 'wic'
+
+WKS_FILE = "ovmf/ovmf-shell-image.wks"
+inherit image
+
+# We want a minimal image with just ovmf-shell-efi unpacked in it. We
+# avoid installing unnecessary stuff as much as possible, but some
+# things still get through and need to be removed.
+PACKAGE_INSTALL = "ovmf-shell-efi"
+LINGUAS_INSTALL = ""
+do_image () {
+rm -rf `ls -d ${IMAGE_ROOTFS}/* | grep -v efi`
+}
diff --git
a/meta/recipes-core/ovmf/ovmf/0007-OvmfPkg-EnrollDefaultKeys-application-for-enrolling-.patch
b/meta/recipes-core/ovmf/ovmf/0007-OvmfPkg-EnrollDefaultKeys-application-for-enrolling-.patch
new file mode 100644
index 000..3aa6cc4
--- /dev/null
+++
b/meta/recipes-core/ovmf/ovmf/0007-OvmfPkg-EnrollDefaultKeys-application-for-enrolling-.patch
@@ -0,0 +1,1124 @@
+From: Laszlo Ersek <ler...@redhat.com>
+Date: Mon, 6 Jul 2015 20:22:02 +0200
+Subject: [PATCH] OvmfPkg: EnrollDefaultKeys: application for enrolling default
+ keys
+
+(A port of the <https://bugzilla.redhat.com/show_bug.cgi?i
[OE-core] [PATCH v4 12/12] ovmf: remove BGRT patch
This patch was added to meta-luv for kernel testing purposes and probably is not relevant for OE-core. Signed-off-by: Patrick Ohly <patrick.o...@intel.com> --- meta/recipes-core/ovmf/ovmf/0001-OvmfPkg-Enable-BGRT-in-OVMF.patch | 110 + meta/recipes-core/ovmf/ovmf_git.bb | 1 +- 2 files changed, 111 deletions(-) delete mode 100644 meta/recipes-core/ovmf/ovmf/0001-OvmfPkg-Enable-BGRT-in-OVMF.patch diff --git a/meta/recipes-core/ovmf/ovmf/0001-OvmfPkg-Enable-BGRT-in-OVMF.patch b/meta/recipes-core/ovmf/ovmf/0001-OvmfPkg-Enable-BGRT-in-OVMF.patch deleted file mode 100644 index 4531a6d..000 --- a/meta/recipes-core/ovmf/ovmf/0001-OvmfPkg-Enable-BGRT-in-OVMF.patch +++ /dev/null @@ -1,110 +0,0 @@ -From 66a4020c3c2163aeffc9757851f33c346ecfd870 Mon Sep 17 00:00:00 2001 -From: Sai Praneeth Prakhya <sai.praneeth.prak...@intel.com> -Date: Mon, 4 Apr 2016 12:15:12 -0700 -Subject: [PATCH] OvmfPkg: Enable BGRT in OVMF - -By default, firmware (OVMF - Open source Virtual Machine Firmware) -never publishes BGRT (Boot Graphics Resource Table) and in the boot -process Linux kernel checks for this table and if it fails to find BGRT -table then corresponding code in Linux kernel is not executed. EDK II -(EFI Development Kit, thus OVMF) already has BGRT source code packaged -into it but it is excluded from the build process of OVMF. These changes -to build system of OVMF enables BGRT in 32-bit and 64-bit OVMF. - -There are only two files that need to be modified in order to do this. -The first one being OvmfPkg*.dsc (this file describes the platform) and -the second one being OvmfPkg*.fdf (this file describes firmware descriptor -volume). A *.inf file (here "BootGraphicsResourceTableDxe.inf") -describes a module (here BGRT). So, include -"BootGraphicsResourceTableDxe.inf" file in "OvmfPkg*.dsc" so that BGRT -source code will be compiled and "BootGraphicsResourceTableDxe.efi" file -is generated and we should also include -"BootGraphicsResourceTableDxe.inf" file in "OvmfPkg*.fdf" file so that -"BootGraphicsResourceTableDxe.efi" will be placed in a firmware volume -and thus gets published. - -Signed-off-by: Sai Praneeth Prakhya <sai.praneeth.prak...@intel.com> - OvmfPkg/OvmfPkgIa32.dsc| 1 + - OvmfPkg/OvmfPkgIa32.fdf| 1 + - OvmfPkg/OvmfPkgIa32X64.dsc | 1 + - OvmfPkg/OvmfPkgIa32X64.fdf | 1 + - OvmfPkg/OvmfPkgX64.dsc | 1 + - OvmfPkg/OvmfPkgX64.fdf | 1 + - 6 files changed, 6 insertions(+) - -diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc -index 9e5b477..0582219 100644 a/OvmfPkg/OvmfPkgIa32.dsc -+++ b/OvmfPkg/OvmfPkgIa32.dsc -@@ -647,6 +647,7 @@ - OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf - MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf - MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf -+ MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf - - # - # Network Support -diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf -index fc203f2..f968cb7 100644 a/OvmfPkg/OvmfPkgIa32.fdf -+++ b/OvmfPkg/OvmfPkgIa32.fdf -@@ -274,6 +274,7 @@ INF RuleOverride=ACPITABLE OvmfPkg/AcpiTables/AcpiTables.inf - INF OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf - INF MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf - INF MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf -+INF MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf - - INF RuleOverride = BINARY FatBinPkg/EnhancedFatDxe/Fat.inf - -diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc -index 6e4da4f..8289385 100644 a/OvmfPkg/OvmfPkgIa32X64.dsc -+++ b/OvmfPkg/OvmfPkgIa32X64.dsc -@@ -656,6 +656,7 @@ - OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf - MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf - MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf -+ MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf - - # - # Network Support -diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf -index d3f46f3..282d40b 100644 a/OvmfPkg/OvmfPkgIa32X64.fdf -+++ b/OvmfPkg/OvmfPkgIa32X64.fdf -@@ -274,6 +274,7 @@ INF RuleOverride=ACPITABLE OvmfPkg/AcpiTables/AcpiTables.inf - INF OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf - INF MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf - INF MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf -+INF MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf - - INF RuleOverride = BINARY USE = X64 FatBinPkg/EnhancedFatDxe/Fat.inf - -diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc -index 3d6d43e..0f956a7 100644 a/OvmfPkg/OvmfPkgX64.dsc -+++ b
[OE-core] [PATCH v4 10/12] runqemu: support UEFI with OVMF firmware
In the simplest case, "runqemu qemux86 qcow2 ovmf" for an
EFI-enabled image in the qcow2 format will locate the ovmf.qcow2
firmware file deployed by the ovmf recipe in the image deploy
directory, override the graphics hardware with "-vga std" because that
is all that OVMF supports, and boot with UEFI enabled.
ovmf is not built by default. Either do it explicitly ("bitbake ovmf")
or make it a part of the normal build
("MACHINE_ESSENTIAL_EXTRA_RDEPENDS_append = ' ovmf'").
The firmware file is activated as a flash drive instead of using the
qemu BIOS parameters, because that is the recommended method
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764918#47) as it
allows storing UEFI variables in the file.
Instead of just "ovmf", a full path to an existing file can also be
used, just as with the rootfs. That may be useful when making a
permanent copy of the virtual machine data files.
It is possible to specify "ovmf*" parameters more than once, then
each parameter creates a separate flash drive. This way it is possible
to use separate flash drives for firmware code and variables:
$ runqemu qemux86 qcow2 ovmf.code ovmf.vars"
Note that rebuilding ovmf will overwrite the ovmf.vars.qcow2 file in
the image deploy directory. So when the goal is to update the firmware
while keeping variables, make a copy of the variable file and use
that:
$ mkdir my-machine
$ cp tmp/deploy/images/qemux86/ovmf.vars.qcow2 my-machine/
$ runqemu qemux86 qcow2 ovmf.code my-machine/ovmf.vars.qcow2
When Secure Boot was enabled in ovmf, one can pick that instead of
the non-Secure-Boot enabled ovmf.code:
$ runqemu qemux86 qcow2 ovmf.secboot.code
my-machine/ovmf.vars.qcow2
Signed-off-by: Patrick Ohly <patrick.o...@intel.com>
---
scripts/runqemu | 42 +-
1 file changed, 41 insertions(+), 1 deletion(-)
diff --git a/scripts/runqemu b/scripts/runqemu
index 4d7168c..10947bb 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -74,6 +74,7 @@ of the following environment variables (in any order):
kvm-vhost - enable KVM with vhost when running x86/x86_64 (VT-capable CPU
required)
publicvnc - enable a VNC server open to all hosts
audio - enable audio
+[*/]ovmf* - OVMF firmware file or base name for booting with UEFI
tcpserial= - specify tcp serial port number
biosdir= - specify custom bios dir
biosfilename= - specify bios filename
@@ -162,6 +163,13 @@ class BaseConfig(object):
self.clean_nfs_dir = False
self.nfs_server = ''
self.rootfs = ''
+# File name(s) of a OVMF firmware file or variable store,
+# to be added with -drive if=pflash.
+# Found in the same places as the rootfs, with or without one of
+# these suffices: qcow2, bin.
+# Setting one also adds "-vga std" because that is all that
+# OVMF supports.
+self.ovmf_bios = []
self.qemuboot = ''
self.qbconfload = False
self.kernel = ''
@@ -259,6 +267,7 @@ class BaseConfig(object):
- Check whether is a kernel file
- Check whether is a image file
- Check whether it is a nfs dir
+- Check whether it is a OVMF flash file
"""
if p.endswith('.qemuboot.conf'):
self.qemuboot = p
@@ -299,6 +308,8 @@ class BaseConfig(object):
else:
logger.info("Assuming %s is an nfs rootfs" % p)
self.check_arg_nfs(p)
+elif os.path.basename(p).startswith('ovmf'):
+self.ovmf_bios.append(p)
else:
raise Exception("Unknown path arg %s" % p)
@@ -384,6 +395,8 @@ class BaseConfig(object):
elif re.search(r'-image-|-image$', arg):
# Lazy rootfs
self.rootfs = arg
+elif arg.startswith('ovmf'):
+self.ovmf_bios.append(arg)
else:
# At last, assume is it the MACHINE
if (not unknown_arg) or unknown_arg == arg:
@@ -482,6 +495,20 @@ class BaseConfig(object):
if not os.path.exists(self.rootfs):
raise Exception("Can't find rootfs: %s" % self.rootfs)
+def check_ovmf(self):
+"""Check and set full path for OVMF firmware and variable file(s)."""
+
+for index, ovmf in enumerate(self.ovmf_bios):
+if os.path.exists(ovmf):
+continue
+for suffix in ('qcow2', 'bin'):
+path = '%s/%s.%s' % (self.get('DEPLOY_DIR_IMAGE'), ovmf,
suffix)
+if os.path.exists(path):
+self.ovmf_bios[index] = path
+break
+else:
+raise Exception("Can't find OVMF firmware: %s" % ovmf)
+
def check_kernel(self):
"""Check and set kernel,
