Re: [yocto] bbappend on top of bbappend
Hi Paul, On Thursday 22 August 2013 10:58:48 Paul D. DeRocco wrote: Paul Eggleton wrote: FWIW, when xinput-calibrator was moved over to OE-Core it was determined that this shouldn't even be started as a service by systemd, but instead launched using Xsession.d. You may have better results if you bring in the recipe from OE-Core master and use that instead. Since I'm not running I GUI, but needed an X session, I created a systemd unit to start a dummy X session, using sleep as the dummy client. Then, I can scribble on the screen from my python scripts run from the root command line. So I solved it by having the xinput-calibrator service run after my X session starts. I'll look at putting it in Xsession.d instead, and see if that is cleaner. I would think it would be cleaner, but probably whatever works in your situation here is fine. I read somewhere that stacked bbappends are handled in the order of layer priority. Mine is 5, the meta-systemd layer is 7. I don't know which is higher, or if one wants a higher or lower priority in order to be the last one to prepend to the path. They will be applied in ascending order, so anything in the bbappend from a layer with a higher layer priority number takes precedence. After I did a clean and a clean_sstate, the dual bbappends worked as expected. I'm learning from experience to clean things manually, to avoid problems, but sometimes I'm just waving a dead chicken over it. I don't really know what these things do, or in what situations they should or shouldn't be necessary. For instance, I've never found an explanation of what shared state really is, with sufficient specificity that I can predict, Oh, for that I need to clean the sstate, not just the build tree. Second, it seems like clean_sstate does a clean, but I'm not sure clean doesn't do something else that clean_sstate doesn't do. FWIW, we do have this section of the reference manual: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#shared-state-cache I guess you already saw since you were part of the thread, but this post and the ones that followed it may be of interest in terms of describing the known situations where the system can't automatically know that something has changed: https://lists.yoctoproject.org/pipermail/yocto/2013-August/018022.html One more thing puzzles me. The original bbappend, which creates a service unit, contained these six lines: FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}: PRINC := ${@int(PRINC) + 2} inherit systemd SRC_URI += file://xinput-calibrator.service SYSTEMD_PACKAGES = ${PN}-systemd SYSTEMD_SERVICE = ${PN}.service Since I only wanted to replace the file, I thought it should be sufficient to put the following in my bbappend: FILESEXTRAPATHS_prepend := ${THISDIR}/files: PRINC := ${@int(PRINC) + 1} It didn't work, though. I blindly copied all six lines into my bbappend, and it worked. I suspect the systemd lines were necessary, though. I'm wondering why adding another copy of the string file://xinput-calibrator.service to SRC_URI is necessary. If xinput-calibrator.service genuinely is in the recipe's original SRC_URI value, It isn't. However there is a difference between the FILESEXTRAPATHS lines in the two instances - one points to a subdirectory called files and the other to a directory called ${PN} (substituting the recipe name in there, of course). That might account for it going from not working to working depending on where you put the service file next to your bbappend. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] bbappend on top of bbappend
Hi Paul, On Friday 16 August 2013 16:22:00 Paul D. DeRocco wrote: In meta-oe/recipes-graphics/xinput-calibrator (Danny branch, currently used by Gumstix), there's a recipe called xinput-calibrator-git.bb, which installs a script for running a touchscreen calibration app if not already calibrated. In meta-openembedded/meta-systemd/meta-oe/recipes-graphics/xinput-calibrator, there's a bbappend for this recipe, which declares a local file called xinput-calibrator.service, which is supposed to run the above script on startup. It inherits the systemd bbclass, which I assume knows how to install this service file automagically, since there's no explicit do_install copying the file anywhere. The systemd.bbclass we now have in OE-Core (as of dylan) does not handle this automatically. The old one in meta-systemd does appear to though. The trouble is, on my Gumstix, the service fails because it needs a DISPLAY environment variable to tell it what display to calibrate. I figured the simplest thing to do would be to add an Environment=DISPLAY=:0 line to the service unit file. FWIW, when xinput-calibrator was moved over to OE-Core it was determined that this shouldn't even be started as a service by systemd, but instead launched using Xsession.d. You may have better results if you bring in the recipe from OE-Core master and use that instead. My shameless hack was to add a ROOTFS_POSTPROCESS_COMMAND that runs sed on the final copy of this service file in the rootfs, to insert the Environment= line, and that works. But I'd rather just provide my own version of the file, and use another .bbappend to prepend its file location to FILESEXTRAPATHS, overriding the one in the systemd .bbappend file. So I tried that, just putting the following two lines into my own .bbappend: FILESEXTRAPATHS_prepend := ${THISDIR}/files: PRINC := ${@int(PRINC) + 1} and of course putting the tweaked service file into my files subdirectory. On starting the build, it almost immediately spat this out: NOTE: ['/home/pauld/yocto/meta-foo/recipes/xinput-calibrator_git.bbappend', '/home/pauld/yocto/poky/meta-openembedded/meta-systemd/meta-oe/recipes-gra phics/xinput-calibrator/xinput-calibrator_git.bbappend'] to ['/home/pauld/yocto/poky/meta-openembedded/meta-systemd/meta-oe/recipes-gr aphics/xinput-calibrator/xinput-calibrator_git.bbappend'] (That was all on one line, of course.) BitBake will report new appends this way so this is expected. It is ugly though. The do_rootfs failed, and its log says that xinput-calibrator is an unknown package, and that it can't satisfy the dependency from packagegroup-core-x11-base. I don't know why this would happen. It's unlikely to be related to changes you've made that are discussed here. Does the package appear under tmp/deploy/(ipk|rpm|deb)/ ? I read somewhere that stacked bbappends are handled in the order of layer priority. Mine is 5, the meta-systemd layer is 7. I don't know which is higher, or if one wants a higher or lower priority in order to be the last one to prepend to the path. They will be applied in ascending order, so anything in the bbappend from a layer with a higher layer priority number takes precedence. FYI you can see the appends in effect in your configuration using: bitbake-layers show-appends Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] bbappend on top of bbappend
From: Paul Eggleton On Friday 16 August 2013 16:22:00 Paul D. DeRocco wrote: In meta-oe/recipes-graphics/xinput-calibrator (Danny branch, currently used by Gumstix), there's a recipe called xinput-calibrator-git.bb, which installs a script for running a touchscreen calibration app if not already calibrated. In meta-openembedded/meta-systemd/meta-oe/recipes-graphics/xinput -calibrator, there's a bbappend for this recipe, which declares a local file called xinput-calibrator.service, which is supposed to run the above script on startup. It inherits the systemd bbclass, which I assume knows how to install this service file automagically, since there's no explicit do_install copying the file anywhere. The systemd.bbclass we now have in OE-Core (as of dylan) does not handle this automatically. The old one in meta-systemd does appear to though. The trouble is, on my Gumstix, the service fails because it needs a DISPLAY environment variable to tell it what display to calibrate. I figured the simplest thing to do would be to add an Environment=DISPLAY=:0 line to the service unit file. FWIW, when xinput-calibrator was moved over to OE-Core it was determined that this shouldn't even be started as a service by systemd, but instead launched using Xsession.d. You may have better results if you bring in the recipe from OE-Core master and use that instead. Since I'm not running I GUI, but needed an X session, I created a systemd unit to start a dummy X session, using sleep as the dummy client. Then, I can scribble on the screen from my python scripts run from the root command line. So I solved it by having the xinput-calibrator service run after my X session starts. I'll look at putting it in Xsession.d instead, and see if that is cleaner. But I'd rather just provide my own version of the file, and use another .bbappend to prepend its file location to FILESEXTRAPATHS, overriding the one in the systemd .bbappend file. So I tried that, just putting the following two lines into my own .bbappend: FILESEXTRAPATHS_prepend := ${THISDIR}/files: PRINC := ${@int(PRINC) + 1} and of course putting the tweaked service file into my files subdirectory. snip I read somewhere that stacked bbappends are handled in the order of layer priority. Mine is 5, the meta-systemd layer is 7. I don't know which is higher, or if one wants a higher or lower priority in order to be the last one to prepend to the path. They will be applied in ascending order, so anything in the bbappend from a layer with a higher layer priority number takes precedence. After I did a clean and a clean_sstate, the dual bbappends worked as expected. I'm learning from experience to clean things manually, to avoid problems, but sometimes I'm just waving a dead chicken over it. I don't really know what these things do, or in what situations they should or shouldn't be necessary. For instance, I've never found an explanation of what shared state really is, with sufficient specificity that I can predict, Oh, for that I need to clean the sstate, not just the build tree. Second, it seems like clean_sstate does a clean, but I'm not sure clean doesn't do something else that clean_sstate doesn't do. One more thing puzzles me. The original bbappend, which creates a service unit, contained these six lines: FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}: PRINC := ${@int(PRINC) + 2} inherit systemd SRC_URI += file://xinput-calibrator.service SYSTEMD_PACKAGES = ${PN}-systemd SYSTEMD_SERVICE = ${PN}.service Since I only wanted to replace the file, I thought it should be sufficient to put the following in my bbappend: FILESEXTRAPATHS_prepend := ${THISDIR}/files: PRINC := ${@int(PRINC) + 1} It didn't work, though. I blindly copied all six lines into my bbappend, and it worked. I suspect the systemd lines were necessary, though. I'm wondering why adding another copy of the string file://xinput-calibrator.service to SRC_URI is necessary. Or am I imagining things? I do that sometimes. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] bbappend on top of bbappend
In meta-oe/recipes-graphics/xinput-calibrator (Danny branch, currently used by Gumstix), there's a recipe called xinput-calibrator-git.bb, which installs a script for running a touchscreen calibration app if not already calibrated. In meta-openembedded/meta-systemd/meta-oe/recipes-graphics/xinput-calibrator, there's a bbappend for this recipe, which declares a local file called xinput-calibrator.service, which is supposed to run the above script on startup. It inherits the systemd bbclass, which I assume knows how to install this service file automagically, since there's no explicit do_install copying the file anywhere. The trouble is, on my Gumstix, the service fails because it needs a DISPLAY environment variable to tell it what display to calibrate. I figured the simplest thing to do would be to add an Environment=DISPLAY=:0 line to the service unit file. My shameless hack was to add a ROOTFS_POSTPROCESS_COMMAND that runs sed on the final copy of this service file in the rootfs, to insert the Environment= line, and that works. But I'd rather just provide my own version of the file, and use another .bbappend to prepend its file location to FILESEXTRAPATHS, overriding the one in the systemd .bbappend file. So I tried that, just putting the following two lines into my own .bbappend: FILESEXTRAPATHS_prepend := ${THISDIR}/files: PRINC := ${@int(PRINC) + 1} and of course putting the tweaked service file into my files subdirectory. On starting the build, it almost immediately spat this out: NOTE: ['/home/pauld/yocto/meta-foo/recipes/xinput-calibrator_git.bbappend', '/home/pauld/yocto/poky/meta-openembedded/meta-systemd/meta-oe/recipes-gra phics/xinput-calibrator/xinput-calibrator_git.bbappend'] to ['/home/pauld/yocto/poky/meta-openembedded/meta-systemd/meta-oe/recipes-gr aphics/xinput-calibrator/xinput-calibrator_git.bbappend'] (That was all on one line, of course.) The do_rootfs failed, and its log says that xinput-calibrator is an unknown package, and that it can't satisfy the dependency from packagegroup-core-x11-base. I read somewhere that stacked bbappends are handled in the order of layer priority. Mine is 5, the meta-systemd layer is 7. I don't know which is higher, or if one wants a higher or lower priority in order to be the last one to prepend to the path. But somehow, I think my problem is a little more fundamental. Can anyone give me a little guidance here? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto