Re: [yocto] How to share files between recipes?
On Thu, Sep 19, 2019 at 9:48 AM wrote: > One possibility is to provide these keys as host native tools and data to > build of target recipes. This makes the files available in the build > environment > but does not expose them to target. > > Create a -native recipe which has and installs the files and use via DEPENDS > to > the -native recipe. > > Hope this helps, > > -Mikko Thank you. That feels like the better answer all around. Ultimately, that's where I was going, but hadn't thought of the fact that I only really need this data on my native build environment. --wpd -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to share files between recipes?
On Thu, Sep 19, 2019 at 9:39 AM Patrick Doyle wrote:
> do_install() {
> install -d ${D}/${datadir}
> install -m 755 -d ${WORKDIR}/keys ${D}/${datadir}
> }
>
Oops... I just noticed the typo(s) in my recipe... I wasn't installing
the contents of my ${WORKDIR} in ${D}${datadir}/keys the way I thought
I was... all I was doing was creating empty directories.
That's why I ask questions like this... so that right after I ask
them, I can find the blatantly stupid mistake I made in my code.
Thanks for playing!
--wpd
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to share files between recipes?
I have a set of data files (cryptographic keys) that I would like to
share among several recipes in my build. They won't go into the
rootfs, but they will be used by multiple recipes that construct the
rootfs. So, to the best of my understanding, it seems like I should
put them in sysroot and somehow access them from there.
I constructed the following recipe:
SUMMARY = "Development keys used by my image"
DESCRIPTION = "Install the development keys in the sysroot so that they \
can be referenced by other recipes."
LICENSE = "Proprietary"
LIC_FILES_CHKSUM =
"file://${COMMON_LICENSE_DIR}/Proprietary;md5=0557f9d92cf58f2ccdd50f62f8ac0b28"
SRC_URI = "file://keys"
do_install() {
install -d ${D}/${datadir}
install -m 755 -d ${WORKDIR}/keys ${D}/${datadir}
}
FILES_${PN} += "${datadir}/keys/"
But when I attempt to bitbake this recipe, I get the following error:
ERROR: development-keys-1.0-r0 do_package: QA Issue: development-keys:
Files/directories were installed but not shipped in any package:
/usr
/usr/share
Ummm I don't put anything in /usr or /usr/share.
I don't inherit from anything (other than base.bbclass) that puts
anything in /usr or /usr/share.
Does base.bbclass put anything in /usr or /usr/share?
Why?
I suppose I could follow the advice given in the error message and
rm -rf ${D}/usr
in my do_install() task, but I'd like to understand why and how those
directories are being created in the first place?
--wpd
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to include the checksum of the (read-only) rootfs in an initramfs
Is this a solved problem? If so, what is the correct solution?
Here are some more details of the problem statement...
I want to verify that my read-only rootfs has not been modified when I
boot. So I bundle the checksum of the the rootfs in /etc/rootfs.hash
in my initramfs using something a lot like:
do_install() {
install -d -m 0755 ${D}/etc
sha256sum -b ${DEPLOY_DIR_IMAGE}/base-image-${MACHINE}.squashfs-xz
| cut -c-64 > ${D}/etc/rootfs.hash
install -d -m 0755 ${D}/init.d
install -m 0755 ${WORKDIR}/rootfs ${D}/init.d/90-rootfs
}
This is part of my "validate-rootfs.bb" recipe which is part of my
initramfs image.
The problem is, I need to ensure that
${DEPLOY_DIR_IMAGE}/base-image-${MACHINE}.squashfs-xz is up to date
prior to the execution of my do_install() task. So I added:
do_install[depends] += "base-image:do_image_complete"
to my recipe. That has worked great... until I noticed that if I do:
$ bitbake base-image -ccleansstate
$ bitbake base-image
I generate a new rootfs, with new timestamps, which means that it will
have a new checksum.
The problem is, since none of the inputs to base-image.bb have
changed, none of the checksums have changed, so bitbake doesn't think
it needs to run my validate-rootfs.bb recipe, so I don't get a new
checksum embedded in my initramfs.
So, I feel like I am doing something wrong here. I _could_ generate
rootfs.hash as part of generating
${DEPLOY_DIR_IMAGE}/base-image-${MACHINE}.squashfs-xz, but I think I
would still have the problem of making validate-rootfs.bb notice that
a file in ${DEPLOY_DIR_IMAGE} has changed and therefore it should run
again.
Digging through the output of
$ bitbake-dumpsig -t validate-rootfs do_install
I noticed a line that read:
This task depends on the checksums of files: []
which looked promising. Digging through the source code, I intuited
that I could add something like:
do_install[file-checksums] +=
"${DEPLOY_DIR_IMAGE}/base-image-${MACHINE}.squashfs-xz:False"
to my recipe. This appeared to work at first, but also appears to be
totally undocumented, and even as I write this, I am seeing situations
where the checksum doesn't get recalculated.
So I wonder if other folks have tried to solve this problem, and how
they have done so.
--wpd
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Reproducible u-boot
How do I use the reproducible_build class to create a reproducible u-boot? I tried adding inherit reproducible_build to my u-boot recipe, but when I do that, I generate errors of the form: ERROR: When reparsing /path/tot/u-boot_git.bb.do_deploy_source_date_epoch, the basehash value changed from e7c4a942e76dc4e630d9dc6e3b6d49db66adeb2c9a5e2d511fac3fc7dabd4e59 to 4735b8a3f887bf83059c5d56e529f1a5650fab8ac53ce4e2c222524e690092ae. The metadata is not deterministic and this needs to be fixed. Where should I look to learn more about the use of reproducible_build.bbclass? --wpd -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Why does enabling initramfs pull eudev into my build?
On Mon, Jul 29, 2019 at 10:52 AM Patrick Doyle wrote:
>
> Did that get your attention? :-)
>
> I am trying to understand why eudev gets pulled into my build, where
> it wasn't part of it before. I recently added an initramfs to my
> build...
What I neglected to say was that a colleague of mine had recently
added crda to our build as well, and that recipe has an explicit
RDEPENDS on "udev".
I did spend an interesting day learning about the difference between
recipes that RDEPEND on providers and individual packages that RDEPEND
on providers. I was confused by the fact that the
initramfs-framework_1.0.bb recipe contains:
SUMMARY_initramfs-module-udev = "initramfs support for udev"
RDEPENDS_initramfs-module-udev = "${PN}-base udev"
FILES_initramfs-module-udev = "/init.d/01-udev"
and, since I didn't depend/rdepend on initramfs-module-udev anywhere
in my build, why that resulted in udev being included in my build.
The answer is... it doesn't. crda caused it to be included in my build.
Thanks for listening.
--wpd
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Why does enabling initramfs pull eudev into my build?
Did that get your attention? :-)
I am trying to understand why eudev gets pulled into my build, where
it wasn't part of it before. I recently added an initramfs to my
build by setting:
INITRAMFS_IMAGE_BUNDLE="1"
in my machine.conf file. I have a custom, very minimal initramfs.bb
recipe that doesn't do much more than:
NO_RECOMMENDATIONS_pn-initramfs = "1"
PACKAGE_INSTALL = "${VIRTUAL-RUNTIME_base-utils} validate-rootfs"
IMAGE_FEATURES = ""
export IMAGE_BASENAME = "${MLPREFIX}initramfs"
IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}"
inherit core-image
When I run:
$ bitbake base-image -g -u taskexp
I see that eudev.do_build lists "base-image.du_build" as a dependent
task and, for some reason, eudev.do_packagedata lists
"initramfs.do_roofs" as a dependent task.
When I remove INITRAMFS_IMAGE_BUNDLE from my machine.conf file, eudev
is no longer included in my image. (Although, oddly,
initramfs.do_build is listed as a dependent task of eudev.do_build
when I run taskexp on my initramfs recipe, but not when I run it on
the base-image recipe.)
Can anybody point me at (more) tools that can help me understand what
I did to my initramfs.bb recipe that caused eudev to be included in my
build?
Thanks
--wpd
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to specify a different kernel for an image
On Mon, Jul 22, 2019 at 2:05 AM Gabriele Zampieri wrote: > > Hi Patrick, > > thank you for the clarification. > I have no idea on how to encapsulate the output of bitbake into another image > in a nice and clean way. I'm pretty sure that you must run two separate > bitbake, one per MACHINE. > What about a partitioned USB stick? You could have the base partition schema > plus an extra partition that contains the production image. The > implementation depends on which tool you are going to use to partition the > output image (if any). > > Gabriele Thanks again for your thoughts, ideas, and conversation. Based on this conversation and further research around the web, it seems like defining a new MACHINE is the best/only way to go. (This is where you say, "That's what I TOLD you at the beginning) --wpd -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to specify a different kernel for an image
On Fri, Jul 19, 2019 at 10:03 AM Gabriele Zampieri wrote: >> 2. My new image going to be used as an installation image for my >> production image. So I need to include the production image (for >> MACHINE="mymachine")) deploy products in the image for my installation >> image. How can I do that if I define a new MACHINE for the production >> image? > > > This is not clear to me. With 'installation image' do you mean a full image > (bootloader, kernel, rootfs etc)? > Can you give me some more details about this use case? > Hi Gabriele, Thank you again so much for your help! My use case is as follows: I need to create an image that will go on a USB stick that we use when we manufacture our boards. That image will be used to flash the production image that we ship. The manufacturing image will have a different kernel configuration, possibly a different device tree, and certainly a different rootfs than our production image. I would like to: $ bitbake manufacturing-image and have the build system set up so that it builds production-image and includes production-image-ubi.img as a file in the rootfs for my manufacturing-image. It seems to me that production-image-ubi.img must be built with MACHINE=mymachine manufacturing-image would have to be built with MACHINE=my-manufacturing-machine ...and that's where I get confused/concerned about using a different MACHINE for my manufacturing image vs my production image. --wpd -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to specify a different kernel for an image
On Fri, Jul 19, 2019 at 1:58 AM Gabriele Zampieri
wrote:
>
> Hi,
>
> you could define two machines, where the manufacturing one is just an overlay
> of the production one. If the two kernels differs only for their config, you
> can specify different defconfig based on machine. If you need a completely
> different kernel, just specify PREFERRED_PROVIDER_virtual/kernel in
> manufacturing overlay
Hi Gabriele,
I wondered about that, but I get confused about the MACHINE concept in
Yocto/OE/bitbake...
1. If I define a new machine, but I have a lot of recipes conditioned
on the old machine, how do I say "This is the same as machine A, but
with these differences"? I have defined a machine now ("mymachine")
and have recipes and .bbappend files with things like this in them:
SRC_URI_mymachine += "file:/blah/blah/blah"
do_install_append_mymachine() {
do_stuff()
}
Do I have to replicate (and maintain) all of the references to
mymachine to also refer to my newly defined "installationmachine"? Or
can I tell Bitbake that "installationmachine" is the same as
"mymachine", and just add/change new stuff for "installationmachine"?
I hope my confusion here makes sense, but since it's confusion, it's
tough to tell :-)
2. My new image going to be used as an installation image for my
production image. So I need to include the production image (for
MACHINE="mymachine")) deploy products in the image for my installation
image. How can I do that if I define a new MACHINE for the production
image?
Thank you so much for the suggestion... it confirms that I am looking
in the right places and thinking about the right things... I just
don't know how to solve this problem.
I'm also surprised that it's not a more general problem... which leads
me to believe that I must be thinking about this the wrong way.
Thanks again.
--wpd
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to specify a different kernel for an image
Hello All, I have a situation where I need to build an image for my machine with a different kernel than is specified by PREFERRED_PROVIDER_virtual/kernel. But I also need to build the default kernel. This is for a "manufacturing" image which will include the full production image, and then some (and, possibly, without some). The kernel configuration needs to be different for the manufacturing image. What is the recommended mechanism to override the value of PREFERRED_PROVIDE_virtual/kernel in my manufacturing-image.bb recipe? --wpd -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to maintain a global DL_DIR?
On Tue, Aug 16, 2016 at 4:24 PM, Peter Kjellerstedt wrote: > You seem to be using an old version of Poky. I am using the version of poky distributed with the board. In this case, the board is the Edison board, and the manufacturer is Intel. I guess I was assuming that the Edison would have been distributed with the latest version of Yocto/OE. Oh well. For other boards with other distributions, who knows what I will find? > If you do not have the option of using Krogoth or newer, you could > use this trick in your .bashrc: > > alias bitbake="BB_ENV_EXTRAWHITE=\"$BB_ENV_EXTRAWHITE DL_DIR\" bitbake" > > It may not be kosher, but it works. ;) I like that solution a whole lot more than the solution I proposed. Learning that the Yocto shipped with the Edison is old, and that there is a newer/better way to address this problem is.. priceless. Thanks for the tip. --wpd -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to maintain a global DL_DIR?
Oh this is ugly... I tried setting BB_ENV_EXTRAWHITE to DL_DIR in my .bashrc, but found that BB_ENV_EXTRAWHITE gets overwritten by oe-buildenv-internal as I mentioned previously. I tried setting BB_ENV_WHITELIST to DL_DIR in my .bashrc and found that bitbake just stopped working. After rereading the manual (https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html#var-BB_ENV_WHITELIST) I tried setting BB_ENV_WHITELIST to "BBPATH BB_RESERVE_ENV BB_ENV_WHITELIST BB_ENV_EXTRAWHITE DL_DIR", and bitbake still didn't work. So I looked in poky/bitbake/lib/bb/utils.py and found the following: def preserved_envvars_exported(): """Variables which are taken from the environment and placed in and exported from the metadata""" return [ 'BB_TASKHASH', 'HOME', 'LOGNAME', 'PATH', 'PWD', 'SHELL', 'TERM', 'USER', ] def preserved_envvars(): """Variables which are taken from the environment and placed in the metadata""" v = [ 'BBPATH', 'BB_PRESERVE_ENV', 'BB_ENV_WHITELIST', 'BB_ENV_EXTRAWHITE', ] return v + preserved_envvars_exported() ... if 'BB_ENV_WHITELIST' in os.environ: approved = os.environ['BB_ENV_WHITELIST'].split() approved.extend(['BB_ENV_WHITELIST']) else: approved = preserved_envvars() This looks like, if BB_ENV_WHITELIST is defined in the environment, bitbake will use it (arbitrarily appending BB_ENV_WHITELIST to the end of whatever was defined in the environment variable). If it is not defined, then BB_ENV_WHITELIST is initialized to be: ['BBPATH', 'BB_PRESERVE_ENV', 'BB_ENV_WHITELIST', 'BB_ENV_EXTRAWHITE', 'BB_TASKHASH', 'HOME', ...] So I finally tried setting BB_ENV_WHITELIST in .bashrc to be "BBPATH BB_PRESERVE_ENV BB_ENV_EXTRAWHITE BB_TASKHASH HOME LOGNAME PATH PWD SHELL TERM USER DL_DIR" But it is very sadly ugly... not terribly maintainable... and makes me think I'm missing something important. Please tell me I'm missing something important. --wpd -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to maintain a global DL_DIR?
As I am playing with several different Yocto/OE projects, I thought it would be nice to set up a global downloads directory. Also, being a somewhat forgetful sort, I thought it would be nice if I could set DL_DIR in my .bashrc and not have to remember to edit conf/local.conf each time I follow the directions from a third party site to set up their Yocto based distribution. Can I do this? If so, how? Do I add DL_DIR to BB_ENV_WHITELIST? Do I add it to BB_ENV_EXTRAWHITE? But I note that poky/scripts/oe-buildenv-internal arbitrarily blasts its own values into BB_ENV_EXTRAWHITE, so setting BB_ENV_EXTRAWHITE in my .bashrc won't work. Perhaps I am misunderstanding the concept of the whitelist. Perhaps I should just ask for some help. Help. Can I maintain a single global download directory specified solely through environment variables? If so, how? Thanks. --wpd -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] What is the simplest way to test a new kernel configuration in a Yocto Project?
Back story: I have an Intel Edison board running some form of a Yocto distibution (from ubilinux-edison-150309.tar.gz). I want to change the kernel configuration. Following Intel's documention, I have downloaded the Yocto build for this board and have seperately learned that I can run: $ bitbake virtual/kernel -c menuconfig # enable some other kernel modules $ bitbake virtual/kernel -c compile -f $ bitbake edison-image u-boot (Yes, this could probably be optimized a bit... but at the moment I just want to try out my tweaked kernel). So, how would I try out my tweaked kernel? I see in tmp/deploy/ipk/edison a set of .ipk files that were just assembled, including the suggestively usefully named kernel-image-3.10.98-poky-edison+_1.0-r2_edison.ipk file, but also the confusingly named kernel-dev_1.0-r2_edison.ipk and kernel-modules_1.0-r2_edison.ipk files along with 23 files of the form kernel-module-*.ipk. I just want to try the new kernel and the new modules compiled with that kernel. How might I do that? I feel like I am going down a path of copy the .ipk files over to the device (much as I would copy .deb files over) and run "sudo ipkg -i *.ipk". But I wonder if I might be sorry just doing that. So I figured I'd ask around first. Any thoughts? --wpd -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] QEMU support for SD/MMC card
On Tue, May 5, 2015 at 6:40 AM, Burton, Ross wrote: > On 3 May 2015 at 22:24, Patrick Doyle wrote: >> >> Can anybody point me in the direction of running an arm based QEMU >> with a (simulated) SD/MMC card? >> >> From the documentation for QEMU, I see that I can pass a -drive >> parameter to QEMU with an if=sd option, which sounds (reads?) an awful >> lot like I can simulate an SD/MMC card. >> >> But looking through the Yocto supplied runqemu script, (actually, >> runqemu-internal) it appears that only supports -hda or -virtio disks. > > > I've no experience using if=sd, but at the end of the day runqemu is just a > helper script, you can pass the right arguments to qemu directly or patch > the script locally. Thanks Ross. I've been fiddling with that a bit (a very little bit, being distracted by other, higher priority tasks), but haven't figured out the right incantation yet. I may have to (gasp) look at the source code :-) Or maybe the monkey in me will eventually press the right combination of keys to make it work. The lazy programmer in me was hoping somebody would say "Oh yeah, I do that all the time. I just blah blah blah". --wpd -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] QEMU support for SD/MMC card
Can anybody point me in the direction of running an arm based QEMU with a (simulated) SD/MMC card? >From the documentation for QEMU, I see that I can pass a -drive parameter to QEMU with an if=sd option, which sounds (reads?) an awful lot like I can simulate an SD/MMC card. But looking through the Yocto supplied runqemu script, (actually, runqemu-internal) it appears that only supports -hda or -virtio disks. --wpd -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto-ish upgrade-in-place strategy
On Sun, May 3, 2015 at 3:58 PM, Chris Morgan wrote: > We thought about the rescue/recovery approach as well. The issue was how the > system would recover in the field and how updates were handled. > > Consider that to update the full system image you'd have to download and > store that image to flash, unless you stored it somewhere, and if you were > going to store it you'd have to have extra space for that. For recovery > you'd have the similar approach of booting recovery but you could write > directly to the primary fs since you're booted to recovery. The trouble > there is download speed and connectivity. The system is down until you > download the update diff/full image and that could take some time. And the > system is down for that period. > > So we didn't see a path forward that would support slow connections plus no > down time. And we would still need some place to put the new image that was > guaranteed to be available which means it couldn't be used for application > or other data that had to be preserved across updates. With two rootfs > partitions we can download in place and take our time doing so. Plus no > special recovery image and no reserved area that is unused except during > update. We do have a full duplicate rootfs though. > > I see where you are going, for other use cases it may be better to have a > primary and a recovery. Our rootfs is around 200MB at this point. I don't expect my rootfs will be anywhere near 200MB. It's a deeply embedded, single function application. So the issues of memory size and bandwidth don't really apply for my particular application. As I have thought about this more (driving to and from baseball games for my kids), I think what I was really wishing for was a Yocto standard/recommended Poky core-image-bootstrap image with appropriate hooks and configuration items to allow me to tailor it to my particular application. So far, I'm not sure how core-image-bootstrap differs from core-image-minimal, except for the additional packages and a custom rc.local I mentioned previously. So perhaps there isn't a need for such a beast, and I'll go roll my own bootstrap/rescue upgrade strategy myself. I'll go start a different thread with a specific question along that line now... --wpd -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto-ish upgrade-in-place strategy
On Sun, May 3, 2015 at 5:51 AM, Chris Morgan wrote: > Is there a standard way? We've seen a few different approaches between > android systems (phones), Linux distributions, and things like chromebook. > > In our case we are using two uboot, two kernel, and two root file system > partitions with uboot environment controlling the active one. Squashfs for > the root fs. Raw images for uboot and kernel. Overlayfs in another rw > partition that we put on top of the rootfs where we keep system > configuration. Media and other stuff goes into yet another btrfs partition > that, like the overlayfs, isn't managed by the update system. > > Approach is to update the second rootfs while one rootfs is running. Swap > env in uboot environment to point at the other rootfs and then when > appropriate reboot. This lets us avoid downtime while downloading the > update, we download in the background. > > We build everything with yocto but afaik we don't have much specific stuff > for the update system because we don't have an upgrade partition but rather > two sets of partitions. > > Thoughts? Hi Chris, Thanks for the description. We do something very much similar to that on one of our systems (except for the part about downloading in the background). As I have been thinking about this, I have been thinking about something along the lines of creating a rescue/boot partition with the following: core-image-minimal squashfs ssh (for rescue operations) kexec-tools U-boot would boot that image. That image would contain an rc.local that would mount the active partition and kexec the kernel it found there. The active partition would contain our deployed application, which would likely also have a squashfs rootfs (because I don't want to trash the flash when the power goes out). It would also have whatever hooks we needed to upgrade images in place. My thinking is that the boot/rescue image would be a factory/expert image. It (of necessity) needs special tools and/or access to the board (JTAG header, USB rescue port, etc...) to be installed. But once it is installed, it is capable of booting whatever Linux I place in the active partition. I might make it smart enough to support an "active" partition and a "fallback" partition, but I kinda feel like I already have a "fallback" mechanism in place with the boot/rescue image. At some point, I begin to think that I am overthinking this. I also begin to think that everybody (in this space) has these same issues. Why do we keep reinventing the wheel? --wpd -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto-ish upgrade-in-place strategy
Rather than inventing this from scratch yet again, I would like to ask what the Yocto-ish best practice is for deploying an embedded system that has to support in-place upgrades. It seems to me that this should be a fairly common scenario: I have (or, rather am in the process of developing yet another) an embedded application that will be running on a device whose power supply is uncertain at best. Consequently, I want to run from a read-only squashfs rootfs, with some small amount of seldom changed configuration data (most likely stored in a JFFS partition). But I need a strategy to upgrade this system in place. Since I am running from a read-only squashfs, I can't apt-get or rpm upgrade individual packages. I must redeploy the entire image. I can divvy up the flash however I want, so I am thinking that I would like to use u-boot to boot a rescue image from one partition, that would kexec the deployed image from a different parition. Are there Yocto recipes, blogs, community experience with this sort of thing, or should I invent my own solution? Again, this feel like a common problem that others should have already solved, and I would rather solve uncommon problems than re-solve common ones. --wpd -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Make autotools use autogen.sh
On Mon, Jul 14, 2014 at 11:39 AM, Burton, Ross wrote: > On 14 July 2014 16:31, Patrick Doyle wrote: >> a) do_compile fails because make depends on INSTALL, because INSTALL >> is listed in the aravis_DATA list in Makefile.am. > > That's silly. Why would you ever need the install instructions to be > installed? Personally I'd patch that out and send it to them. > INSTALL is implicitly included in tarballs and there's no purpose in > installing a generic installation document. I like that answer best of all… I started with that approach this morning, but then misread the automake documentation and convinced myself that there had to be a better solution. Reading your response, and reading the automake documentation more carefully, I agree. INSTALL should not be listed in aravis_DATA. I'll submit that patch upstream. Thank you very much. This was extremely helpful. --wpd -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Make autotools use autogen.sh
Hi Ross,
Thank you for answering. As we've been digging into it here, we've found:
a) do_compile fails because make depends on INSTALL, because INSTALL
is listed in the aravis_DATA list in Makefile.am.
b) It appears (subject to further investigation) that autoreconf
--install doesn't create the INSTALL file because it is passed the
--foreign flag (whereas autogen.sh passes the --gnu flag to automake).
I'm going to continue poking around and see if there is some sort of
OE_USE_GNU_INSTEAD_OF_FOREIGN flag I can set in my recipe :-) In the
mean time, I have established that I can override do_configure (for
this specific case) with:
do_configure() {
NOCONFIGURE=true ./autogen.sh --enable-gst-plugin
oe_runconf
}
The NOCONFIGURE=true is required because that's what upstream
autogen.sh checks to see whether it should run configure or not.
If I wanted to learn more about autogen.sh dying out, where would I
look? I'd be happy to talk with the upstream maintainer about whether
he could eliminate this or not, but I'd like to know more myself
before starting that conversation. However, I think there might still
be the issue with --foreign vs --gnu (assuming that is truly the root
cause of the missing INSTALL file).
--wpd
On Mon, Jul 14, 2014 at 10:25 AM, Burton, Ross wrote:
> On 14 July 2014 14:32, Patrick Doyle wrote:
>> What is the best thing to do here…
>> Should I inherit autotools and override do_configure with my own
>> version that just runs the (package supplied) autogen.sh?
>>
>> Is there a way for autotools to run automake --add-missing?
>
> So autotools.bbclass invokes autoreconf --install, which should be
> passed down as automake --add-missing. If that isn't the case then
> that's arguably a bug in autoreconf.
>
> In general autogen.sh is dying now that autoconf has autoreconf, as
> your typical autogen.sh just runs the autoconf/automake/etc tools in
> the right order - and this is what autoreconf does.
>
>> Should I go figure out why the build fails in INSTALL doesn't exist?
>> (I'm going to start there, since my first two ideas haven't panned
>> out. (Well, I haven't actually tried the first one yet, it just seems
>> silly to me to inherit autotools and then not use them.))
>
> I've no idea why a missing INSTALL file would cause a build error, or
> why you don't get it when autoreconf is executed. Can you share some
> logs?
>
> Ross
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Make autotools use autogen.sh
First off, I have no expertise whatsoever autotools at all. I know they exist. I know they make life simpler (somehow) for (some?) people. I shutter to think of ever trying to learn enough about how they work to learn that they would make my life simpler. But, I _do_ know how to run a shell script called "autogen.sh", if it exists in a package I'm adding to my project. And I have a project that includes it; and I do see that it runs all sorts of tools like autoheader, automake, libtoolize, etc… One thing that it does run in the midst of all of that is "automake --add-missing", which creates the INSTALL file for the package. What is the best thing to do here… Should I inherit autotools and override do_configure with my own version that just runs the (package supplied) autogen.sh? Is there a way for autotools to run automake --add-missing? Should I go figure out why the build fails in INSTALL doesn't exist? (I'm going to start there, since my first two ideas haven't panned out. (Well, I haven't actually tried the first one yet, it just seems silly to me to inherit autotools and then not use them.)) Should I try something else? Thanks (as always) for any tips or pointers you might have. --wpd -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Is it possible to prevent a package from updating the shared state cache?
On Fri, Jul 11, 2014 at 3:19 PM, Burton, Ross wrote: > On 11 July 2014 17:00, Patrick Doyle wrote: >> (I >> wanted to build from a different bzr repository and didn't want to >> "contaminate" my sstate cache, or even worse, confuse it with a >> different version of revsion 1234 from the other repository) > > Ouch, I'd forgotten that bzr revisions were not unique. Is there a > way of making revisions globally unique, and should we switch the > packages to use those instead of local revisions? Ahhh… Bazaar does use globally unique identifiers internally (according to http://doc.bazaar.canonical.com/developers/overview.html). I didn't think about that when I asked my question. I just assumed that the sstate cache was based on revno rather than guid. I would expect that the guid should be available via bzrlib, if you use that for the sstate cache. It is also available (I have now learned) via "bzr version-info" for a given branch. --wpd -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Is it possible to prevent a package from updating the shared state cache?
For anybody (such as myself) who might stumble across this thread later… I just wanted to build a recipe without tainting my sstate cache. (I wanted to build from a different bzr repository and didn't want to "contaminate" my sstate cache, or even worse, confuse it with a different version of revsion 1234 from the other repository). So I went with: Run the cleansstate task Bitbake my one particular recipe Copy the generated output for the particular test I wanted to run to the particular test system on which I wanted to run it. Run the cleansstate task again to clean up after myself. I'm open to suggestions for better ways to accomplish this. --wpd On Thu, Jul 10, 2014 at 3:00 PM, Patrick Doyle wrote: > Suppose I always wanted Yocto to process a particular recipe local to > a project and never to consult the shared state for that recipe. Is > there some way to mark a recipe to do this? > > --wpd -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Is it possible to prevent a package from updating the shared state cache?
Suppose I always wanted Yocto to process a particular recipe local to a project and never to consult the shared state for that recipe. Is there some way to mark a recipe to do this? --wpd -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Environment Variables being unset by bitbake?
Oh! I think I know the answer to this one!
Check out BB_ENV_EXTRAWHITE at
http://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html#var-BB_ENV_EXTRAWHITE.
If you set that to something like JAVA_HOME, that might do what you
want.
--wpd
On Wed, Jul 9, 2014 at 4:58 PM, Allen Kennedy Jr.
wrote:
> I am trying to run java program from a recipe.
>
> I get an error that JAVA_HOME is not set.
> I can verify that JAVA_HOME is set by echo $JAVA_HOME.
>
> I can then run the program without issue, but from within a recipe it
> seems that $JAVA_HOME is unset.
>
> I have verified this with 'bbnote "java is here: ${JAVA_HOME}"' from within
> a recipe.
>
> Any ideas why or how this is getting unset, and how to fix?
> I couldn't find any documentation that talks about this.
>
> Thanks
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] What is the simplest, or better yet, canonical way to add a shell script to core-image-minimal?
Hello Gaurang, Ross, and Nicolas,
Thank you for your suggestions. I ended up implementing Ross's
suggestion (before I got even got his suggestion) because it was the
only answer I could come with on my own where all the pieces made
sense. I originally asked the question out of a (most likely
misguided) sense that creating a recipe simply to install a shell
script was too heavyweight. I thought there might be a simpler way to
do that than writing a recipe like:
DESCRIPTION = "My specific shell script[s] that get installed in the rootfs."
LICENSE = "CLOSED"
SRC_URI = "file://my_script.sh"
do_install () {
install -d ${D}${bindir}
install -m 755 ${WORKDIR}/my_script.sh ${D}${bindir}
}
… and then adding custom-scripts recipe to CORE_IMAGE_EXTRA_INSTALL.
Once I finished writing the recipe, I realized it was much simpler
than I thought it would be. Thanks for providing the infrastructure
that made that so easy.
--wpd
On Tue, Jun 24, 2014 at 5:50 AM, Burton, Ross wrote:
> On 23 June 2014 16:56, Patrick Doyle wrote:
>> Should I create a core-image-minimal.bbappend file with a SRC_URI
>> pointing to my script and a do_install rule to install it?
>
> Create a new recipe for the script and then add it to the image.
>
> The documentation is useful:
> http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#extendpoky
>
> Ross
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] What is the simplest, or better yet, canonical way to add a shell script to core-image-minimal?
Should I create a core-image-minimal.bbappend file with a SRC_URI pointing to my script and a do_install rule to install it? Is there a better way? --wpd -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [dora] x264: Update SRCREV to match commit in upstream git repo
On Tue, Jun 17, 2014 at 12:46 PM, Paul Eggleton wrote: > No problem - in this particular instance with x264 it was a bit of an > unfortunate trifecta where the upstream project does not provide release > tarballs so we build directly from their git repository; they recently decided > to rewrite their git history without telling anyone, and we didn't notice > immediately because we don't build it on our autobuilder regularly (since it > has LICENSE_FLAGS set). Even when we did know about it though, it's fair to > say we have been a little slow to correct for it; hopefully we can get this > patch in soon and then it'll be taken care of, at least for the x264 recipes > in master, daisy and dora. > In this particular instance, it was even more difficult as I just learned that we don't have a mechanism for keeping our local dora repository in sync with the Yocto repository. Fortunately, I know how to fix that :-) > Cheers, > Paul Thanks for your help, and for your commitment to Open Source Software. --wpd -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [dora] x264: Update SRCREV to match commit in upstream git repo
Thanks Paul, I hope I didn't step on any toes with this. I'm still confused about what parts of the project are "Yocto" and what parts are "OE". Do you have any guesses as to when this might show up in the official dora branch? I am asking because we have a development flow here (I'm still not sure I'm 100% happy with it, but it's what we've got), where we mirror the poky repository, check out from that mirror very occasionally, and generate a complete-from-scratch even more occasionally. Unfortunately, we have a situation right now where, if somebody were to do that (say, hypothetically speaking, a new person joins the team), we can't generate a complete build from scratch. I could apply my patch to our local mirror, and thus break the mirror. Or I could create a local clone of the mirror and reference our local clone. Or … If this will show up in dora in a matter of hours to a day or so, I'm going to stop thinking about this. If it is anticipated that it will take longer, then I'll come up with a solution. I'm not trying to complain nor advocate that this patch get applied faster than would be normal, I'm just trying to plan my day :-) --wpd On Tue, Jun 17, 2014 at 11:07 AM, Paul Eggleton wrote: > Hi Patrick, > > On Tuesday 17 June 2014 09:36:05 Patrick Doyle wrote: >> It seems that 585324fee380109acd9986388f857f413a60b896 is no >> longer there in git and it has been rewritten to >> ffc3ad4945da69f3caa2b40e4eed715a9a8d9526 > > FYI I sent a similar patch for dora to the OE-Core list a week ago; hopefully > it should be merged soon. > > (Robert: I think my CC of the patch to you at the time bounced, not sure what > happened.) > > Cheers, > Paul > > -- > > Paul Eggleton > Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [dora] x264: Update SRCREV to match commit in upstream git repo
It seems that 585324fee380109acd9986388f857f413a60b896 is no
longer there in git and it has been rewritten to
ffc3ad4945da69f3caa2b40e4eed715a9a8d9526
Change-Id: I9ffe8bd9bcef0d2dc5e6f6d3a6e4317bada8f4be
(From OE-Core rev: b193c7f251542aa76cb5a4d6dcb71d15b27005eb)
(From OE-Core rev: f2b20b169a462cf4c6e6f341b76add8a0f4d6e3f)
Signed-off-by: Khem Raj
Signed-off-by: Saul Wold
Signed-off-by: Richard Purdie
---
meta/recipes-multimedia/x264/x264_git.bb |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-multimedia/x264/x264_git.bb
b/meta/recipes-multimedia/x264/x264_git.bb
index 406df30..e40290f 100644
--- a/meta/recipes-multimedia/x264/x264_git.bb
+++ b/meta/recipes-multimedia/x264/x264_git.bb
@@ -11,7 +11,7 @@ SRC_URI = "git://git.videolan.org/x264.git \
file://don-t-default-to-cortex-a9-with-neon.patch \
"
-SRCREV = "585324fee380109acd9986388f857f413a60b896"
+SRCREV = "ffc3ad4945da69f3caa2b40e4eed715a9a8d9526"
PV = "r2265+git${SRCPV}"
--
1.7.9.5
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] What is the best process for applying patches to dora?
ok, thanks. I'll do that. --wpd On Mon, Jun 16, 2014 at 5:02 AM, Burton, Ross wrote: > On 14 June 2014 17:48, Patrick Doyle wrote: >> What is the best way to get this applied to dora? > > Cherry-pick the commit into a branch of Dora to verify that it applies > and builds, and then sent the patch to oe-core@ with '[dora]' added to > the message subject (--subject-prefix is the option you want for > git-send-email). > > Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] What is the best process for applying patches to dora?
…either locally (i.e. in my build environment), or globally so that others can benefit? My build from scratch no longer works. It fails the build the x264_git recipe. Tracking things down, I see that it fails because the revision in that recipe referenced by SRCREV (585324fee380109acd9986388f857f413a60b896) is no longer in the git repository. Tracking things down even more, I see that this has been fixed in daisy with commit a714cf870046d736d45aa1c3f891bdc877a3ca0e: Author: Khem Raj Date: Wed May 28 22:22:54 2014 -0700 x264: Update SRCREV to match commit in upstream git repo It seems that 585324fee380109acd9986388f857f413a60b896 is no longer there in git and it has been rewritten to ffc3ad4945da69f3caa2b40e4eed715a9a8d9526 Change-Id: I9ffe8bd9bcef0d2dc5e6f6d3a6e4317bada8f4be (From OE-Core rev: b193c7f251542aa76cb5a4d6dcb71d15b27005eb) (From OE-Core rev: f2b20b169a462cf4c6e6f341b76add8a0f4d6e3f) Signed-off-by: Khem Raj Signed-off-by: Saul Wold Signed-off-by: Richard Purdie What is the best way to get this applied to dora? --wpd -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to specify a default value for a variable in a recipe
On Fri, Jun 13, 2014 at 10:13 AM, Gary Thomas wrote:
> Any time you need to set the variable outside of the recipe itself (.bb* or
> .inc),
> then you need the _pn-${recipe} syntax.
Ahhh…. that's good to know.
I keep wanting to understand the scope rules of bitbake. This helps.
Thanks Gary.
--wpd
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to specify a default value for a variable in a recipe
On Fri, Jun 13, 2014 at 9:47 AM, Gary Thomas wrote:
> If this is in the gstxbac recipe itself, use the much simpler
> SRCREV ?= "${AUTOREV}"
Even better! While I like that solution best of all, that opens up a
whole new world of hurt for me.
How does
SRCREV_default_pn-gstxbac = "${AUTOREV}"
work? When would I use that over the much simpler solution you proposed?
I am thinking that if I used your solution, I might place
SRCREV_pn-gstxbac = "123" (or a git hash, or whatever)
in my local.conf? in my BSP layer.conf?
I guess I could put
SRCREV_default_pn-gstxbac = "123" in my BSP layer.conf, and then,
later on, on some other project that used the same board, I might put
SRCREV_pn-gstxbac = "${AUTOREV}" in my local.conf, or maybe in a
.bbappend file for my BSP?
How/where does the _pn suffix (middlex?) come into play?
At this point, I like your solution tremendously, as it makes sense to
me. But I sure would like to understand more about all the myriad
capabilities offered by bitbake.
--wpd
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to specify a default value for a variable in a recipe
OK, I've got to ask this, because it totally confuses me. I wrote a
recipe to build a custom application (gstreamer plugin, actually) that
I wanted to fetch from our SCM. Bitbake told me I needed to specify a
source revision and even gave me a clue of what to put in. Looking at
the development manual, I decided I wanted to use the latest revision
from our repository by default, so I added the following line to my
recipe:
SRCREV_default_pn-gstxbac = "${AUTOREV}"
But now I'm curious. Why couldn't I use (I haven't tried this yet)
SRCREV_pn-gstxbac ?= "${AUTOREV}"
and even more confusingly, why isn't the syntax something more like:
SRCREV_pn-gstxbac_default = "${AUTOREV}"
What's going on here?
Does one syntax (BLAH_default vs BLAH ?=) get evaluated early in the
bitbake process and the other get evaluated late?
Does the location of the letters "default" in a variable name matter?
At some point, I really need to wrap my head around Bitbake, it's
syntax, and how it operates and internalize all of that.
--wpd
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to determine which tasks bitbake just ran?
Thanks. bitbake foo | cat is most likely to be what I was looking for. I found the cooker log shortly after I asked my question. I'll go look through bitbake and see what it would take to create a symbolic link to the most recent logfile, as is done with the logfiles for the individual tasks. I'll also go see what I can learn about Toaster. --wpd On Thu, Jun 12, 2014 at 3:06 PM, Christopher Larson wrote: > > On Thu, Jun 12, 2014 at 12:00 PM, Burton, Ross > wrote: >> >> On 12 June 2014 19:53, Patrick Doyle wrote: >> > As you know, when we bitbake a recipe, we see lots of messages about >> > individual tasks that are run as they are being run (do_fetch, >> > do_configure, etc…), and then a final summary message that reads >> > something like: >> > >> > NOTE: Tasks Summary: Attempted 690 tasks of which 677 didn't need to >> > be rerun and all succeeded. >> > >> > I'm curious: >> > 1) What were the 13 tasks that ran? >> > 2) Why are there 690 tasks for my simple recipe anyway? >> >> You want to see the cooker log. >> >> If you want to see that as it happens, then for a one-off you can >> convince bitbake that it's not running on a vt (bitbake foo | cat -). >> >> After the event, the cooker logs are in >> tmp/logs/cooker/[machine]/[timestamp].log. For convenience, Chris >> Larson's excellent 'bb' command has a 'log' mode that if given no >> arguments will display the latest cooker log. > > > The new Toaster is pretty great at examining what your build did, if you ran > your build in toaster context, afaik. I haven't spent much time playing with > it, but it does seem like it's intended to answer just these sort of > questions. > -- > Christopher Larson > clarson at kergoth dot com > Founder - BitBake, OpenEmbedded, OpenZaurus > Maintainer - Tslib > Senior Software Engineer, Mentor Graphics -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to determine which tasks bitbake just ran?
I'm sure I'll get tired of looking at this eventually, and learn to love the normal ncurses style interface of bitbake. But things are still new enough to me that I want to know what's going on. As you know, when we bitbake a recipe, we see lots of messages about individual tasks that are run as they are being run (do_fetch, do_configure, etc…), and then a final summary message that reads something like: NOTE: Tasks Summary: Attempted 690 tasks of which 677 didn't need to be rerun and all succeeded. I'm curious: 1) What were the 13 tasks that ran? 2) Why are there 690 tasks for my simple recipe anyway? Is there some way to preserve the list of 13 tasks that were run? Are they listed in a logfile through which I could grep "running task " or "task skipped"? Also, as I've been playing with my simple recipe, I find myself frequently wanting to start from a totally clean slate, so I $ bitbake myrecipe -c cleanall But I notice that tmp/work/arm/myrecipe still exists, so, in my paranoia, I like to rm -rf tmp/work/arm/myrecipe just to make sure that my clean slate really is clean. I don't see a "cleanevenmorethanall" task listed with -c listtasks. 1) Is there any harm done in rm -rf tmp/work/arm/myrecipe? 2) Is there an eqivalent to a cleanevenmorethanall task that would do that for me? --wpd -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Conditional patches on kernel depending on board, how to maintain?
Can you compile the different device drivers as modules and load them at runtime? Can you compile the different device drivers statically and probe them based on a devicetree file? --wpd On Thu, Jun 12, 2014 at 7:54 AM, Daniel Hilst Selli wrote: > I have a SoM which will be used on several boards, this SoM has a base > kernel for it, with its board-*.c file. In each board I may have different > peripherals, so I have to patch the same board-*.c file depending on my > target board, and that patches may be conflicting one each other. For > example, I could have a RF on first SPI bus on one board, and on another > board a SD card on same first SPI bus. > > So basically I will have a different kernel(uImage) and rootfs (with kernel > modules) for each board. > > I think to create a layer for each target board, with the linux-SoM.bbappend > including the patches for that board..., so I enable the layer depending on > target board I'm creating, but is too much file editions, or have a build > directory for each target board, enabling the right layer on each > local.conf, but this means mantaining build directories, or at last > local.conf, which doesn't seem a good idea for me... > > Would be possible to do this relying only new layers and its configurations? > > Thanks in advance > Cheers! > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] QA Issue: non -dev/-dbg/-nativesdk package contains symlink .so
I found the "libtool related change" for which I was looking, fixed it, submitted a patch upstream, saw the patch approved and applied to master, and now my Yocto build works once again. Hooray for Open Source! (Boo for my lack of ability to keep an email stream on list.) Thanks everybody for the help. --wpd On Tue, Jun 10, 2014 at 12:05 PM, Burton, Ross wrote: > On 10 June 2014 16:29, Patrick Doyle wrote: >> Hmmm…. Thanks Ross, I think you're probably onto something there, >> since the Aravis package is generating a shared library plugin that >> can be loaded with gstreamer. >> >> The confusing thing is… this used to work (as of mumble revisions ago >> on the master branch), and I don't see any libtool related changes in >> the diffs. I'll go check again, and read the Building-modules.html >> page to which you directed me, and see if I can figure out what went >> wrong where/how. > > Right, that's exactly whats happening then. Yocto has had this QA > warning for a long time, so possibly your distro has done something > that enabled it? In this case it's trivial to either fix the Makefile > (and push the fix upstream) or short-term fix by disabling that QA > test with INSANE_SKIP. > > Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] QA Issue: non -dev/-dbg/-nativesdk package contains symlink .so
I started getting the warning mentioned above when I updated to a newer release of an open source package (Aravis). I asked the google how I should address that issue, and it was no help, so now I'll ask the list :-) Any suggestions as to what I should do about this? The (autotools generated) Makefiles do, in fact, generate symlinks. Do I care? --wpd -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Thank you
I just want to publicly say "Thank you" to all of the Yocto developers and community members, both in the general sense of "Thank you for your contributions to the Open Source community" and in the specific (and very self-centered) sense of "Thank you for answering my newbie questions over the last couple of weeks. We made it through this week's demo thanks to the framework you provided and the specific answers to the specific questions I asked. Thank you again. --wpd -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Confusion about autotools
ok, thanks.
I do get a "Hello World" message out of do_unpack(). Weird.
Thanks.
--wpd
On Thu, Apr 10, 2014 at 8:15 PM, Chris Larson wrote:
>
> On Thu, Apr 10, 2014 at 5:12 PM, Patrick Doyle wrote:
>>
>> ok, that makes sense. Trying to pattern match against too many
>> patterns, and not spending enough time understanding the underlying
>> technology. Thank you for the explanation.
>>
>> If you don't mind, I'll move on to my next question...
>>
>> I now have a "do_fetch()" task that looks like this:
>>
>> do_fetch () {
>> bberror "Hello World"
>> exit 1
>> }
>>
>> Where would I see "Hello World" pop out? I don't see it in the log file.
>
>
> It should show up in the do_fetch log (not the cooker log), which lives next
> to the run script. That said, it's possible you're hitting an issue due to
> the base.bbclass fetch implementation being python, not shell.
>
> --
> Christopher Larson
> clarson at kergoth dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Maintainer - Tslib
> Senior Software Engineer, Mentor Graphics
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Confusion about autotools
ok, that makes sense. Trying to pattern match against too many
patterns, and not spending enough time understanding the underlying
technology. Thank you for the explanation.
If you don't mind, I'll move on to my next question...
I now have a "do_fetch()" task that looks like this:
do_fetch () {
bberror "Hello World"
exit 1
}
Where would I see "Hello World" pop out? I don't see it in the log file.
I do see in run.do_fetch a shell script that looks like:
...
do_fetch() {
bberror "Hello World"
exit 1
}
bberror() {
echo "ERROR: $*"
}
cd '/home/wpd/yocto/downloads'
do_fetch
That's cool... things are starting to make sense now. Especially as I
see that "do_fetch()" is probably not the right task to overload.
But I do wonder what happened to my "Hello World" message.
--wpd
On Thu, Apr 10, 2014 at 7:50 PM, Chris Larson wrote:
>
> On Thu, Apr 10, 2014 at 4:43 PM, Patrick Doyle wrote:
>>
>> I am trying to write a recipe for a custom gstreamer plugin that
>> compiles fine (natively) with autotools.
>>
>> I thought it would be as simple as writing a recipe that said something
>> like:
>>
>> inherit autotools
>>
>> myplugin_do_fetch() {
>> commands_to_make_a_copy_of_my_source_code_in_build_tree;
>> }
>> EXPORT_FUNCTIONS do_fetch
>>
>> (I am leaving out the boilerplate DESCRIPTION, LICENSE, etc...
>>
>> But when I try to run my recipe, I get an error that ends like:
>>
>> 109: /home/wpd/.../run.do_fetch.1234 do_fetch: not found
>>
>> and when I look at run.do_fetch, I see on line 109
>>
>> do_fetch
>>
>> I thought that do_fetch would be inherited from base.bbclass. I look
>> in autotools.bbclass and I don't see a do_fetch function task defined
>> there.
>
>
> EXPORT_FUNCTIONS is an inheritance mechanism, to let you override a function
> in a class you inherit but still be able to explicitly call the function
> defined by that class. Unless you have a 'myplugin' class, nothing will
> translate myplugin_do_fetch to do_fetch. If you want to override a function
> like do_fetch in your recipe, just override that function, don't prefix it.
> --
> Christopher Larson
> clarson at kergoth dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Maintainer - Tslib
> Senior Software Engineer, Mentor Graphics
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Confusion about autotools
I am trying to write a recipe for a custom gstreamer plugin that
compiles fine (natively) with autotools.
I thought it would be as simple as writing a recipe that said something like:
inherit autotools
myplugin_do_fetch() {
commands_to_make_a_copy_of_my_source_code_in_build_tree;
}
EXPORT_FUNCTIONS do_fetch
(I am leaving out the boilerplate DESCRIPTION, LICENSE, etc...
But when I try to run my recipe, I get an error that ends like:
109: /home/wpd/.../run.do_fetch.1234 do_fetch: not found
and when I look at run.do_fetch, I see on line 109
do_fetch
I thought that do_fetch would be inherited from base.bbclass. I look
in autotools.bbclass and I don't see a do_fetch function task defined
there.
So now I'm confused. Since this isn't working the way I thought it
would, I figured it was time (once again -- and thanks for all of the
help so far!) to ask the list how I should do this.
For purely hysterical reasons, the gst plugin is in the same (bzr)
repository and my yocto build environment. I was expecting to write a
"do_fetch()" task that would copy the source files into the
appropriate location in build tree.
I guess I could create a subdirectory of the recipe that contains a
bunch of symbolic links to each of the source files required to build
the plugin, and list them all as file:whatever in SRC_URI. But that
feels hackish.
Once again, any tips to help over this hump (and help me make it to
the big important demo next week) would be welcome.
--wpd
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to include kernel module without including the kernel in the rootfs?
Hi Bruce, Thank you very much. That did the trick. --wpd On Thu, Apr 10, 2014 at 11:35 AM, Bruce Ashfield wrote: > On 14-04-10 11:32 AM, Patrick Doyle wrote: >> >> I just added a custom kernel module to my build, and now my rootfs >> includes a copy of my kernel (thus making it too large to fit in my >> pinhole sized root partition). >> >> Is there any way to prevent the kernel from being included in the >> rootfs? Do modutils require a kernel image in order to function >> properly? > > > Clear this in your kernel recipe: > > # Allow machines to override this dependency if kernel image files are > # not wanted in images as standard > RDEPENDS_kernel-base ?= "kernel-image" > > and you'll get no kernel image, and yes, modules will work. > > Bruce > > >> >> My recipe contains >> >> inherit module >> >> So I'm expecting that the module class does magic that results in the >> kernel getting installed. >> >> Is there a flag I can set to say "Don't do that?". >> >> Thanks. >> >> --wpd >> > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Why increment PRINC by 2?
The BSP guide gives the following helpful tip for installing a custom
/etc/network/interfaces file (see
https://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html#customizing-a-recipe-for-a-bsp
-- and thank you, BTW -- that addressed a specific problem I needed to
solve):
1. Edit the init-ifupdown_1.0.bbappend file so that it contains the following:
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
PRINC := "${@int(PRINC) + 2}"
The append file needs to be in the meta-xyz/recipes-core/init-ifupdown
directory.
2. Create and place the new interfaces configuration file in the BSP's
layer here:
meta-xyz/recipes-core/init-ifupdown/files/xyz/interfaces
In my continuing attempt to understand the mindset of Yocto
practitioners, I would appreciate any light folks can shed on this... it
opens up so many questions to me...
1) Why does FILESEXTRAPATHS exist? The documentation says, "You can
extend FILESPATH variable by using FILESEXTRAPATHS." Errr, can't one
extend FILESPATH with
FILESPATH = "blah:" + $FILESPATH
or
FILESPATH_prepend = "blah:"
I see that the documentation for FILESPATH specifically states:
"Do not hand-edit the FILESPATH variable. If you want the build system
to look in directories other than the defaults, extend the FILESPATH
variable by using the FILESEXTRAPATHS variable."
but that doesn't help me understand why this method is preferred for
extending FILESPATH.
2) Why does PRINC exist? The documentation says that PRINC "causes
the PR variable of .bbappend files to dynamically increment" and that
"This increment minimizes the impact of layer ordering." I guess that
means that the init-ifupdown_1.0.bb file has some revision (which I
think is "1.0") and that, when my .bbappend file is appended to it,
causes the recipe to effectively be "3.0". Why do I care? If there
is an "init-ifupdown_5.0.bb" file someplace in my search path, won't I
get that one anyway? How does this minimize the impact of layer
ordering?
Oh yeah, and why increment by 2? Why not 1, or pi?
I guess I only had 2 questions... but 1,000,000 subquestions :-)
Thanks for any tips you can give me.
--wpd
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to include kernel module without including the kernel in the rootfs?
I just added a custom kernel module to my build, and now my rootfs includes a copy of my kernel (thus making it too large to fit in my pinhole sized root partition). Is there any way to prevent the kernel from being included in the rootfs? Do modutils require a kernel image in order to function properly? My recipe contains inherit module So I'm expecting that the module class does magic that results in the kernel getting installed. Is there a flag I can set to say "Don't do that?". Thanks. --wpd -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Squeezing a gstreamer video pipeline into the smallest footprint possible
Thank you for the tips folks... please keep them coming. At the moment (for this pinhole sized project) I only need support for video. Is there any way to strip out all of the audio components from the gstreamer I generate? I tried adding --disable-vorbis to my recipe, only to find that config.status shows that both --disable-vorbis and --enable-vorbis options we set in ac_cs_config. In the mean time, I'm going to go build my own pipeline & link it statically as suggested by Sebastian. Thank you again. --wpd On Wed, Apr 9, 2014 at 4:53 AM, Burton, Ross wrote: > On 9 April 2014 00:03, Patrick Doyle wrote: >> I have a ridiculously pinhole sized memory footprint into which I >> would like to squeeze a gstreamer based video pipeline. I am looking >> for tips on what I can do to minimize the footprint as much as >> possible for my Yocto based system. > > The GStreamer plugins and libraries are all packaged independently in > Yocto, so you can do some heavy size reduction by just installing the > packages you need, and double-checking that nothing unexpected gets > pulled in via dependencies. > > Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Squeezing a gstreamer video pipeline into the smallest footprint possible
I have a ridiculously pinhole sized memory footprint into which I would like to squeeze a gstreamer based video pipeline. I am looking for tips on what I can do to minimize the footprint as much as possible for my Yocto based system. Looking at the rootfs, I see that libgstaudio is included. Can anybody give me any tips on how I might exclude that from my system? At worst, I suppose I could write a post install task that simply removes it from the rootfs, but that feels unduly hackish to me. Also, I tried adding a .bbappend file with --disable-theora, --disable-vorbis, etc... added, but when I looked at the resulting config.status file, I found my --disable-theora & --disable-vorbis options in ac_cs_config, followed by --enable-theora and --enable-vorbis. Adding insult to injury, the resulting compressed rootfs was 100 bytes longer than before :-) (The part of me that enjoys ironic humor, laughed heartily at that. The part of me that is just trying to squeeze this image into my 6MB partition wept.) Is there a way to configure gstreamer with just the set of 3 or 4 plugins I really need? Can I compile static libraries and link them into into my own static application? Any tips? Thanks. --wpd -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problems building documentation for bitbake 1.17.0
That's the ticket…. thanks.
Installing dblatex and/or xmlto made everything work (and work much
faster!). 1.17.0 installs fine (with python setup.py install --user) and
"make DOC=user-manual" works for master. setup still doesn't work on
master, probably because doc/manual/thml/* no longer exists:
data_files = [("share/bitbake", glob("conf/*") + glob("classes/*")),
("share/doc/bitbake-%s/manual" % __version__,
glob("doc/manual/html/*"))],
--wpd
On Tue, Mar 25, 2014 at 12:23 PM, Rifenbark, Scott M <
scott.m.rifenb...@intel.com> wrote:
> Hmm… I can the following on Ubuntu 12.04:
>
>
>
> $ git clone git://git.openembedded.org/bitbake
> $ cd bitbake
> $ make DOC=user-manual
>
> Builds both HTML and PDF fine. Assumes the “master” branch.
>
> I have the make, xsltproc, docbook-utils, fop, dblatex, and xmlto packages
> on my host build machine.
>
> Scott
>
>
>
>
>
>
>
>
>
> *From:* Patrick Doyle [mailto:wpds...@gmail.com]
> *Sent:* Tuesday, March 25, 2014 8:30 AM
> *To:* Rifenbark, Scott M
> *Cc:* yocto@yoctoproject.org
> *Subject:* Re: [yocto] Problems building documentation for bitbake 1.17.0
>
>
>
> I poked around some more after sending my email (instead of doing the work
> I was supposed to be doing) and found that, by ignoring the docbook
> messages and just letting the setup complete for 1.17.0, it worked (once I
> apt-got another package or two: xsltproc, libxml2-utils, fop, maybe
> others). So I now have a doc/manual/html directory for 1.17.0.
>
>
>
> I still can't build the docs (with "make DOC=user-manual") on master
> though. It fails to build user-manual.pdf:
>
>
>
> http://docbook.sourceforge.net/release/xsl/current/common/en.xml:188:
> parser error : Premature end of data in tag l10n line 2
>
> http://docbook.sourceforge.net/release/xsl/current/common/en.xml:207:
> parser error : Extra content at the end of the document
>
> ĞğĠġĢģƓɠǤǥǦǧǴǵḠḡHhĤĥĦħȞȟɦḢḣḤḥḦḧḨḩḪḫ
>
>
> ^
>
>
>
> I tried this on a Ubuntu 12.04 LTS 64 bit machine. Am I missing a
> particular dependency? Is this a known problem (with an obvious solution?)
> The Google doesn't tell me anything obvious about "docbook extra content
> at end of document" (I didn't try searching for the string of random
> characters that follows that. Perhaps I should try.)
>
>
>
> I get the same error when executing "make DOC=user-manual" on the master
> branch (note that setup.py doesn't work right now on master), so I'm
> inclined to believe the problem is at my end. I'm just not sure where to
> start looking for a solution. So I figured I'd ask.
>
>
>
> --wpd
>
>
>
>
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problems building documentation for bitbake 1.17.0
I poked around some more after sending my email (instead of doing the work I was supposed to be doing) and found that, by ignoring the docbook messages and just letting the setup complete for 1.17.0, it worked (once I apt-got another package or two: xsltproc, libxml2-utils, fop, maybe others). So I now have a doc/manual/html directory for 1.17.0. I still can't build the docs (with "make DOC=user-manual") on master though. It fails to build user-manual.pdf: http://docbook.sourceforge.net/release/xsl/current/common/en.xml:188: parser error : Premature end of data in tag l10n line 2 http://docbook.sourceforge.net/release/xsl/current/common/en.xml:207: > parser error : Extra content at the end of the document > > ĞğĠġĢģƓɠǤǥǦǧǴǵḠḡHhĤĥĦħȞȟɦḢḣḤḥḦḧḨḩḪḫ > > > ^ > > > > I tried this on a Ubuntu 12.04 LTS 64 bit machine. Am I missing a > particular dependency? Is this a known problem (with an obvious solution?) > The Google doesn't tell me anything obvious about "docbook extra content > at end of document" (I didn't try searching for the string of random > characters that follows that. Perhaps I should try.) > > > > I get the same error when executing "make DOC=user-manual" on the master > branch (note that setup.py doesn't work right now on master), so I'm > inclined to believe the problem is at my end. I'm just not sure where to > start looking for a solution. So I figured I'd ask. > > > > --wpd > > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Problems building documentation for bitbake 1.17.0
Hello all, I just tried $ git clone git://git.openembedded.org/bitbake $ cd bitbake $ git checkout 1.17.0 $ python setup.py install and that failed with an infinite (well, I hit ^C before I found out for real) stream of messages of the form: http://docbook.sourceforge.net/release/xsl/current/common/en.xml:207: parser error : Extra content at the end of the document ĞğĠġĢģƓɠǤǥǦǧǴǵḠḡHhĤĥĦħȞȟɦḢḣḤḥḦḧḨḩḪḫ ^ I tried this on a Ubuntu 12.04 LTS 64 bit machine. Am I missing a particular dependency? Is this a known problem (with an obvious solution?) The Google doesn't tell me anything obvious about "docbook extra content at end of document" (I didn't try searching for the string of random characters that follows that. Perhaps I should try.) I get the same error when executing "make DOC=user-manual" on the master branch (note that setup.py doesn't work right now on master), so I'm inclined to believe the problem is at my end. I'm just not sure where to start looking for a solution. So I figured I'd ask. --wpd -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
