**** BEGIN LOGGING AT Wed Jul 09 02:59:58 2014 Jul 09 03:50:43 Hi Jul 09 03:51:00 I am trying to buildoe-core first time Jul 09 03:51:11 getting error "chown: changing ownership of `/home/test/oe/oe-core/build/tmp-eglibc/work/i686-linux/db-native/5.3.21-r0/image/home/test/oe/oe-core/build/tmp-eglibc/sysroots/i686-linux/usr/include/db_cxx.h': Operation not permitted Jul 09 03:51:22 and afterwards so man chown errors Jul 09 03:51:31 any suggestions what might have gone wrong Jul 09 03:51:32 ? Jul 09 07:52:17 what is the purpose of DEPENDS_class-native? Jul 09 07:52:26 is there a package called "class-native"? Jul 09 07:54:28 mago_: it's to specify a DEPENDS when the recipe is built for 'native' Jul 09 07:54:52 e.g. some recipes are used on the target, some are used on the host too. Jul 09 07:55:57 ndec, so if I've added BBCLASSEXTEND = "native" (enabling my recipe to be built as both myrecipe and myrecipe-native), will it ignore RDEPENDS when building for -native, and instead use RDEPENDS_class-native ? Jul 09 07:56:39 trying to build libav9.13 for arm (colibri-t20) im getting ERROR: ERROR: objcopy failed with exit code 1 (cmd was 'arm-angstrom-linux-gnueabi-objcopy' --only-keep-debug '/home/rick/oe-core/build/out-eglibc/work/armv7ahf-vfp-angstrom-linux-gnueabi/libavdep/9.13-r0/package/usr/lib/libavformat.so.54.20.4' '/home/rick/oe-core/build/out-eglibc/work/armv7ahf-vfp-angstrom-linux-gnueabi/libavdep/9.13-r0/package/usr/lib/.debug/libavformat.so. Jul 09 07:56:50 can someone help me fix this pls? Jul 09 07:57:06 mago_: probably. though this is a good question... not sure how DEPENDS and DEPENDS-class_native are combined together. Jul 09 07:57:31 mago_: i would recommend doing a quick test to try out..and confirm. Jul 09 08:02:01 https://lists.yoctoproject.org/pipermail/yocto/2013-September/016302.html Jul 09 08:02:06 mago_: ^ Jul 09 08:02:47 the overrides are processed later so th emain variable is reset Jul 09 08:03:32 RDEPENDS_class* is not a good idea Jul 09 08:05:26 RDEPENDS -> RDEPENDS_${PN} Jul 09 08:13:23 ant_work, i see. so this _class-native-thing is just a way to add additional (or override) the dependencies, IF building for native instead of target? Jul 09 08:13:56 you need that in case of BBCLASSEXTEND typically Jul 09 08:14:32 i thought that if I do BBCLASSEXTEND, it will automatically change the dependencies so that it depends on -native version of all dependencies? Jul 09 08:15:36 hm, no, it's not so easy Jul 09 08:15:45 check code in native.bbclass Jul 09 08:16:00 python native_virtclass_handler () { Jul 09 08:19:50 hm. map_dependencies() seems to do what I meant? Jul 09 08:20:05 it does in most cases, yes Jul 09 08:20:24 just grep the metadata to find the exceptions Jul 09 08:21:13 but th eprinciple is valid for other extensins, i.e. your custom class Jul 09 08:22:52 (sorry the typos, this wireless kb is ugly) Jul 09 08:24:14 my problem is with a python module recipe called pyserial (http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-devtools/python/python-pyserial_2.4.bb). It RDEPENDS python-fcntl. If I customize the pyserial recipe with BBCLASSEXTEND = "native" (using a python-pyserial_%.bbappend-file), it complains that python-fcntl-native is not available. What would be the appropriate way to build python-pyserial natively? python-fcntl is provided Jul 09 08:24:14 by python (as a package split), so would the appropriate solution here be to also add RDEPENDS_${PN}_class-native = "python-native" ? Jul 09 08:25:11 (what im trying to do is to build a recipe that needs pyserial-native, in case that was not clear from above) Jul 09 08:27:58 I think this is a similar example http://lists.openembedded.org/pipermail/openembedded-core/2013-May/078668.html Jul 09 08:30:20 should not all python modules have a RDEPENDS on python? Jul 09 08:30:30 (not just the appropriate modules) Jul 09 08:30:51 i think that would solve my problem, since the python RDEP would then be translated to python-native by map_dependencies() Jul 09 08:32:05 I'd say, check the python recipes in oe-core Jul 09 08:35:50 thanks Jul 09 08:38:05 anyone knows why "split and trip files" could fail? **** BEGIN LOGGING AT Wed Jul 09 08:42:18 2014 Jul 09 08:44:17 Guest83683: you should really check the logs carefully Jul 09 08:44:36 quick google gave some matches about the possible reasons Jul 09 08:44:43 anyway, to silence it, try include INHIBIT_PACKAGE_STRIP = "1" Jul 09 08:45:04 s/include/add/ Jul 09 08:45:23 ant_work: already tried INHIBIT_PACKAGE_STRIP Jul 09 08:45:41 then you have to inspect the workdir Jul 09 08:45:43 gives me QA issues architecture did not match Jul 09 08:45:48 and the .run files Jul 09 08:46:28 I'm sorry I don't build for armv7ahf Jul 09 08:47:12 still, arch mismatch should be really easy to spot Jul 09 08:47:26 (very strange I'd say) Jul 09 08:49:54 ant_work, doesn't the map_dependencies() kind of break if a recipe depends on package splits? lets say A provides packages A-a, A-b and A-c. My package B depends on A-a and A-b. map_dependencies() translates that into A-a-native and A-b-native, but does not know that the dependency it really needs to add is A-native ? Jul 09 08:50:44 because A will not PROVIDES A-a-native unless you try to build A-native, I guess? Jul 09 08:53:11 sorry, phone call Jul 09 08:53:32 the DEPENDS are on the recipe, not on the providede package Jul 09 08:53:50 you RDEPEND on package Jul 09 08:54:05 so B DEPENDS on A Jul 09 08:54:17 at buildtime Jul 09 08:54:47 different is at runtime Jul 09 08:54:56 what is the difference between a package and a recipe? Jul 09 08:56:32 the recipe A PACKAGES foo, bar, baz Jul 09 08:59:23 so if RDEPEND refers to the packages, why will not python-fcntl-native be available in my native build, when it is available for a target (non-native) build? Jul 09 08:59:43 found the thread.. Jul 09 08:59:45 https://www.mail-archive.com/yocto@yoctoproject.org/msg15184.html Jul 09 09:01:26 ant_work: dont be sorry, im really new to this so im trying stuff Jul 09 09:03:30 Guest83683: you are using Angstrom and armv7ahf, I really can't help here Jul 09 09:04:23 have you tried to clean and rebuild? Jul 09 09:09:39 Guest83683: in oe-core libav was updated 2 months ago Jul 09 09:10:39 maybe Angstrom is needing the old version? Wild guess Jul 09 09:11:45 ant_work, thanks for the link, really useful. However, I still don't understand why I cannot RDEPEND on python-fcntl-native without also doing RDEPEND_${PN}_class-native = "python-native" ? how come Bitbake cannot figure out that there is a package called python-fcntl-native? Jul 09 09:14:37 i assume bitbake parses every recipe and know which packages are available, and which ones are also available as native variants Jul 09 09:14:42 ant_work: I tried to do some cheating by using the 0.8 version recipe and just modifying the license, URI etc.. and it didnt fail, ill see if it actually works Jul 09 09:31:51 mago_: with python and perl there is sort of chicke-egg problem Jul 09 09:32:12 mago_: check out the python-native_2.7.3.bb recipe Jul 09 09:33:49 i see, so they do two completely different recipes for python and python-native? Jul 09 09:34:39 yes Jul 09 09:34:56 check i.e. PROVIDES vs. RPROVIDES Jul 09 09:39:23 btw, ant_work, the link you have me indicates that a RDEPENDS adds a dependency on otherpackage.do_write_package() for do_build(). When I do RDEPENDS on my python modules and then build the -native variant, the modules are not processed (although it seems to verify that they exist). The result is that my recipe is built, but none of the required python modules are available in the site-packages of my python-native. There is no error. If I manually Jul 09 09:39:23 build the required modules, e.g. bitbake python-mymodule-native, it becomes available in site-packages. I also checked, the python module recipes do not have a do_write_package task, could this be related? Is it not correct to assume that a RDEPENDS is suppose to be installed? Jul 09 09:39:27 (into the sysroot) Jul 09 09:41:33 hm, no, RDEPENDS just means it will be BUILT Jul 09 09:43:35 in that case, how am I suppose to get a working system with any python module? every python module in meta-openembedded only RDEPENDS on other modules. Do I have to go through them all and manually calculate the dependency tree and add it to my DEPENDS? Jul 09 09:46:28 ant_work, im not even getting a work-dir for the python modules in my RDEPENDS. It's like it's not even bothering with unpacking them? Jul 09 09:47:12 are you talking about target or buildhost now? Jul 09 09:47:46 native. but is the behavior of RDEPENDS different depending on if building for target or native? Jul 09 09:49:28 the mechanism is the same Jul 09 09:51:10 i'm pretty sure the modules are automatically installed onto the target rootfs if I do a target build, even if the recipes only use RDEPENDS Jul 09 09:53:53 sure, if you add package A to your image and it RDEPENDS on B, B will be added to target image. Or afterwards if you install i.e. A.opkg then B.opkg will be installed Jul 09 09:54:34 so adding stuff to your image adds special treatment to your RDEPENDS? Jul 09 09:54:53 depends, shlibs are automatically detected Jul 09 09:54:54 i guess this is handled by the image recipe, ie going through the RDEPENDS list and install it? Jul 09 09:55:39 bitbake does that Jul 09 09:56:19 you should really read the manual about these vars Jul 09 09:56:29 and remember that python is a special case ;) Jul 09 09:56:42 yeah, i feel confused :) i'll do that! thanks, now it's lunchtime! Jul 09 09:57:29 you can inspect the dependency tree. obviously it is possible that there is some bug Jul 09 09:58:01 one last question though: if you wanted a package to be built for native, and end up in the deployment directory, where would you put the dependency? i'd like this to happen for a specific image Jul 09 09:58:24 i.e if you build core-image-minimal for machine X, it builds package Y for host aswell Jul 09 09:58:38 mago_: the packages are for the target Jul 09 09:59:01 remember natives are only used to build the toolchain Jul 09 10:00:03 http://www.yoctoproject.org/docs/1.6.1/ref-manual/ref-manual.html#ref-classes-native Jul 09 10:41:35 ant_work, okay, so you're saying that if i want to create a tool that is available inside the buildtree, i should not create a package for it? Jul 09 10:52:32 sorry, when i said i want to package something for native, i just meant to provide a bitbake package.. it does not need to package into a file (such as a ipk) or anything Jul 09 10:59:46 mago right Jul 09 11:00:07 perhaps you need to provide it for native-sdk Jul 09 11:02:18 woglinde, the script im trying to integrate is a deployment script. Ideally, i'd like the user to be able to run it without installing any python modules in his or hers system, instead the OE tree should provide the python modules (and also python itself). The user can then run the script from the deployment directory to deploy the generated binaries to a device. Is this something I can achieve with OE? is it a "supported" use-case? The script itse Jul 09 11:02:18 lf is only there as a convenience, there is nothing else depending on it. Jul 09 11:03:46 ? Jul 09 11:04:24 hm Jul 09 11:04:31 thats not a normal usecase Jul 09 11:04:47 i'm starting to realize this :) is it a bad use-case? Jul 09 11:04:54 and if inherit rm_work is set there bill not binaries in the end Jul 09 11:05:04 ups there will be no Jul 09 11:05:32 so maybe i should keep this script outside the OE build tree? Jul 09 11:05:36 provide an image with all included or set up a package feed Jul 09 11:05:52 where uses can easily do opkg update install Jul 09 11:06:03 mago yes Jul 09 11:07:08 perhaps it is better to provide a .deb-file for the users to install on their system, rather than messing around with OE Jul 09 11:07:41 can opkg also be used for native packages? Jul 09 11:10:53 mago again what is your usecase? Jul 09 11:11:04 I can not see a clear one Jul 09 11:13:05 i want to provide a convenient script for the users that allows deploying OE generated binaries (uImage, rootfs etc) to a device. This (python) script depends on a few other python modules, which are not installed by default on an Ubuntu system. So I thought I could instead provide this script through my build tree, so when a user has built his binaries, there will also be a copy of the deployment script, and all the required modules are installed Jul 09 11:13:05 and ready to use using the OE provided python version Jul 09 11:13:46 so once the build has finished for a user, one can just run a command such as: cd tmp-eglibc/deploy/images/asdf/ && ./deploy_stuff.py -i 192.168.1.5 Jul 09 11:14:50 the only reason to why i want to keep my script inside the OE buildtree is because I was hoping it would allow the user to run it without having to install anything Jul 09 11:14:57 so it basically becomes linux agnostic Jul 09 11:22:33 mago_: sry, ws away Jul 09 11:22:45 mago_: normally it is the other way Jul 09 11:23:11 your script is pushing (ssh or ftp ?) 'files' on target Jul 09 11:23:32 normal case is, the package manager on target ยง(opkg i.e.) pulls the packages from a feed Jul 09 11:25:13 the packages and the eventual dependencies Jul 09 11:27:36 any native Jul 09 11:28:25 native are typically of different ARCH Jul 09 11:28:51 ant_work, this script deploys boot loader on empty devices so running the package manager on target is not an option Jul 09 11:29:06 it deploys boot loader and the inital system (linux+rootfs+dtb) Jul 09 11:30:05 so this script transfers the SPL bootloader using x-modem, then sends the full u-boot over Y-modem and finally launches a TFTP server and transfers the rest over network, which is finally written to NAND Jul 09 11:30:36 ok, I see Jul 09 11:31:53 but the more I think of it, keeping this outside the OE tree makes sense. I'm basically asking for a way to make the buildsystem generate a script which is not needed by the build process itself, and it is not included in the target filesystem, and it shall be built for the host. It doesn't make sense from the buildsystem perspective, I guess Jul 09 11:32:32 we are all in similar circumstances: the built kernel/rootfs must be somehow flashed Jul 09 11:33:40 it all depends on your bootloader Jul 09 11:33:53 i just vaguely recall that some part of Yocto is capable of generating virtual machine images "build appliances". If i understand these correctly, it is just a virtual machine that users can boot to run OpenEmbedded. They should fall under the same category of tasks, its something being built for the users as a convenience, not so much because the build system needs it Jul 09 11:34:06 some devices can be switched in 'usb' mode and get flashed with custom tools Jul 09 11:34:18 other devices expect a pre-formatted SD card Jul 09 11:34:29 routers have/had just tftp Jul 09 11:34:33 ant_work, yes, but regardless of how your boot loader works, you will need tools available on the machine to do it. I'm just looking for a way to get those tools into place Jul 09 11:34:38 so there is a vaste panorama Jul 09 11:34:54 hi, I've asked on #yocto but no reply so sorry for double asking: is it possible to use update-rc class to remove package specific S*files and keep only script in /etc/init.d? Jul 09 11:35:11 if its a usb bootloader, you need dfu, if your device runs a tftp client, you need a tftp server etc Jul 09 11:36:34 often you can use mtd-utils and flash from shell Jul 09 11:36:49 it all depends on device/bootloader Jul 09 11:37:16 you might think about an autoinstaller Jul 09 11:37:29 ant_work, sure, but you still need mtd-utils on your host? would you add that as a ASSUME_PROVIDED, or would you have OE build it for you? Jul 09 11:37:41 i,.e. a kernel embedding an initramfs wjth flasher+images Jul 09 11:38:31 mago_: some natives are installed jut choosing the jffs2/ubifs imagetypes Jul 09 11:39:24 you can add i.e. flashcp or ubiformat in your cpio Jul 09 11:39:29 ant_work, still talking about completely empty devices. we only have the bootrom level bootloaders to talk to; i agree that once you have u-boot in place, you have a lot more options in how to transfer the rest. That's not the problem, it's how to get the initial bootloader onto the device Jul 09 11:40:03 our only option is to send programs over x-modem, and in order to do that we need a x-modem tool on the host Jul 09 11:40:09 I don't work in a factory but suppose they have some jtag multi-flashers Jul 09 11:40:16 how many devices? Jul 09 11:40:57 ant_work, well, our production uses serial. we're talking thousands of units Jul 09 11:41:04 argh Jul 09 11:41:09 I see Jul 09 11:42:06 it all remembers my old Zyxel router Jul 09 11:42:13 and we are quite happy with serial/x-modem, my problem is still that i need to make a x-modem tool available on the host,, and it'd be really nice if OpenEmbedded could do that for me Jul 09 11:43:00 well your zyxel router probably also had only very few boot options when the flash was empty. Once U-boot is up, you can flash it using any method you want, tftp, usb, serial, even HTTP Jul 09 11:43:56 another use-case is if the device is bricked, this deployment script is capable of unbricking any device since it does not rely on _any_ software in the device. It only relies on the bootrom code which is hardcoded into the ASIC Jul 09 11:44:10 mago_: that code can boot a linux kernel? Jul 09 11:44:45 or can only chainload to a bootloader? Jul 09 11:45:13 ant_work, it can run a 64kb program, with 32 kb of RAM. What you do is boot the u-boot SPL (a tiny version of uboot). It will setup the DDR and everything. You then transfer the full U-boot, which is capable of writing to NAND, tftp and everything else. From there you can boot Linux Jul 09 11:45:30 the bootrom code will never use the DDR, so you are limited to on-chip memory Jul 09 11:46:39 is it a mips32? Jul 09 11:46:51 no :) Jul 09 11:47:04 this is how 99% of all SoCs work Jul 09 11:47:14 I have recently seen smthg similar but specific Jul 09 11:47:33 to jz4770 Jul 09 11:47:56 they developed a small 2nd stage bootloader Jul 09 11:48:07 mininit Jul 09 11:48:20 anyway Jul 09 11:48:33 who wil lupdate the device? the users? Jul 09 11:49:39 yeah, mostly the developers who get brand new hardware. the production facility will run the same script, but will of course not use OE. So the use-case is looking to solve is for developers Jul 09 11:50:01 flashing bootloader to virgin devices, or unbricking devices Jul 09 12:04:57 anybody? Jul 09 12:17:15 mago_ provide a native-sdk which has the stuff inside Jul 09 12:17:34 thats the closest I can think of Jul 09 12:17:41 to achieve it Jul 09 12:18:06 but there are some corner cases getting the image out of the deployment dir and so on Jul 09 12:18:13 so i will get a installer shellscript in deploy/sdk? or how does a native-sdk work? Jul 09 12:18:36 read the yocto documentation Jul 09 12:57:16 koen, ping Jul 09 12:57:23 pong Jul 09 12:57:43 hey, I'm fixing a commit messgae for the postgress autfoo to usse pkgconfig Jul 09 12:57:56 and you wanted to know more about the pg* stuff Jul 09 12:58:09 right Jul 09 12:58:19 about all I can figure is they are filtering for some things from the output of xml-config Jul 09 12:58:36 right again Jul 09 12:58:41 or do you know somethign clever they are doing? Jul 09 12:58:47 I still say the filtering is stupid and misguided Jul 09 12:58:56 it will drop -isystem Jul 09 12:58:57 the pg processing? Jul 09 12:59:04 yes Jul 09 12:59:14 I just dropped it and used output of pkgconfig Jul 09 12:59:52 so pretty much say the filtering was overly complicated and stop worrying about it :) Jul 09 13:01:13 as long as you mention it in the commit message :) Jul 09 13:48:20 how do I use ASSUMED_PROVIDED to add native depends to a recipe? Jul 09 13:58:38 where and how do i specify the path to local dependencies? Jul 09 13:58:55 normaly you dont Jul 09 13:59:18 when bitbake is running the PATH will be altered to use the sysroot Jul 09 13:59:24 before host Jul 09 15:10:11 woglinde, hey, just fyi, it seems at least on daisy, "perf" still has a rdependency on perl. looks like cpan-base.bbclass adds it to RDEPENDS_${PN} Jul 09 15:10:57 kroon uhm Jul 09 15:11:41 kroon I was sure I could install perf with perl Jul 09 15:11:45 but I will test it again Jul 09 15:11:52 till later Jul 09 15:16:24 I started looking into it, maybe something like s/+=/= in the RDEPENDS of the perf recipe Jul 09 15:53:23 are there any tools to integrate software coming from .deb files (with proprietary software) into a OE build? Jul 09 17:26:21 Can anyone help me with an openembedded recipe build? I am getting a "QA Issue: Architecture did not match (3 to 62)", not sure if this is the right place to go for this... Jul 09 17:32:12 it's telling you the problem Jul 09 17:32:19 the binaries you built weren't for what you're targeting Jul 09 17:32:25 e.g. it built x86 binaries which wont run on your arm target Jul 09 17:32:33 so the build didn't obey our variables (CC, CFLAGS, etc) Jul 09 17:34:52 Sorry, I'm failry inexperienced, I'm an intern learning this on my own, is there any way you can help me decide how to correct it so that it will build it for the right machine architecture? Jul 09 17:36:50 My recipe is located at https://github.com/wolfSSL/meta-wolfssl/tree/master/recipes-wolfssl/benchmark Jul 09 17:37:12 lct_: there's nowhere near sufficient information. how we make a buildsystem obey our variables is completely dependent on the type of buildsystem and the particular implementation. its a case by case thing, it varies from one piece of software to the next. Jul 09 17:37:39 oh, that's obvious then. you're manually using a compiler command instead of using our variables Jul 09 17:37:50 don't call clang, call ${CC}, and pass ${CFLAGS} and ${LDFLAGS} Jul 09 17:38:20 also, you don't have cyassl in your DEPENDS, so it wont be available to link against for hte target anyway Jul 09 17:39:02 the best bet is to just call out to the buildsystem of the softwar ein question rather than writing your compile commands in do_compile Jul 09 17:39:12 e.g. if it uses a makefile, bitbake will automatically call out to make Jul 09 17:39:33 oh, i see, the source is just the .c file Jul 09 17:39:48 yeah, in that case just run ${CC} directly with the correct arguments Jul 09 17:51:49 Thanks , I have changed my compile line but sadly, to no effect. Jul 09 17:52:02 then you didn't do so correctly, i'd say Jul 09 17:53:37 I tried: ${CC} ${CFLAGS} -DNO_RABBIT -Wall -o benchmark /home/leah/wolfSSL/meta-wolfssl/recipes-wolfssl/benchmark/files/benchmark.c -lcyassl ${LDFLAGS} Jul 09 17:55:48 Perhaps I should not be using the location on my own machine for my .c file? Jul 09 17:56:56 Is there a faster way to test image_type classes? Also, it seems like bitbake is caching my class and not seeing changes. Jul 09 17:57:19 lct_: that would be a start, using the correct path. ${WORKDIR}/benchmark.c Jul 09 17:57:25 but i doubt thats cuasing your failure Jul 09 17:58:17 sr105: what are you changing, and what bitbake command are you running to vierfy the change? and did you examine the contents of the metadata as bitbake sees it to make sure it sees your change? (e.g. make sure no higher piroirty layer is overriding your class) Jul 09 17:58:21 sr105: see bitbake -e Jul 09 17:58:44 whenever something seems inexplicable, first step is to check our assumptions, and the first step with that when using bitbake is to make sure vars are set the way we think they are Jul 09 17:58:49 this is invaluable when debugging Jul 09 18:00:22 kergoth: I added my own image_types_mine.bbclass which is based on one from meta-fsl-arm. Their's builds an "sdcard" image file. I made one that generates a script in DEPLOY_IMAGE_DIR that will do the same to a card Jul 09 18:01:17 I created the class, so there shouldn't be any other IMAGE_CMD_sdcard-script vars to overrride mine. And I can tell from the generated output that it's running that it's not picking up changes Jul 09 18:01:25 I'll try -e Jul 09 18:01:27 okay, step one, make sure its set the way you think it is, and that its being inherited Jul 09 18:02:02 step two, make sure the do_rootfs task is being re-run, that is, make sure bitbake recognizes that a change to that variable means it needs to re-run do_rootfs task Jul 09 18:02:08 the inherit is in the MACHINE conf and it gives me a warning about running my image function Jul 09 18:02:22 okay, thats a good sign Jul 09 18:02:23 I tried -C rootfs to force that Jul 09 18:02:56 then tried -c cleansstate in case the image creation function is being cached Jul 09 18:02:57 if forcing a re-run of the task doesn't help, then you have something bigger going on Jul 09 18:03:03 k Jul 09 18:03:07 cleansstate doesn't matter for images, images aren't archived as sstate Jul 09 18:03:23 I didn't think so, but I thought it couldn't hurt. :) Jul 09 18:03:25 * kergoth nods Jul 09 18:03:28 that's fair enough Jul 09 18:04:00 i was going to suggest that you could examine the run. script in ${WORKDIR}/temp/ for do_rootfs, but most of the do_rootfs work is in python in the python module now, so not sure how useful it is Jul 09 18:04:01 I'll dig a bit more. Having you tell me about sstate helps me cull that branch of investigation Jul 09 18:04:10 but in general its useful, since thats equivalent to what bitbake runs for the task Jul 09 18:04:13 * kergoth nods Jul 09 18:04:47 I have the python libs and classes open in emacs right now. I used them to see what environment the functions run in and what vars would be available to me Jul 09 18:04:51 you could also add echo commands and examine the do_rootfs log Jul 09 18:05:01 to see if those lines are being run at all, to make sure it is indeed using the currnet version of your function Jul 09 18:05:11 * kergoth nods Jul 09 18:05:31 Well, for now, bitbake generates a standalone script based on my function and is giving me a path to it in the warning Jul 09 18:05:56 ah, right, it's using exec_func for it. good Jul 09 18:06:22 * kergoth is still somewhat used to how the image creation used to work, before the rework to the python module :) Jul 09 18:06:23 That's how I can tell it's not updating because I removed 90% of the function to try and narrow down on the error and 100% is in the output Jul 09 18:06:41 yeah. It's much cleaner now it seems Jul 09 18:07:33 bitbake only caches metadata in the up front full parse used for dependency analysis for runqueue generation Jul 09 18:07:41 when it runs the tasks, it re-parses the recipe anyway Jul 09 18:07:47 for config files, it goes by the timestamp on the file Jul 09 18:08:02 (by config, that also includes classes listed in INHERIT, as they end up in the config metadata to act globally) Jul 09 18:08:47 it's unlikely that its failing to reparse the class when it should, so bitbake -e should show the correct content Jul 09 18:09:00 i'm guessing something is going wrong farther down the line, past the parsing and parse cache Jul 09 18:09:11 hey nitink Jul 09 18:18:17 I think bitbake -e was the trick. I forget about using that. It was a layer problem. There was a backup copy of the class. Ugh. Thank you. Jul 09 18:19:37 Hi kergoth Jul 09 18:20:06 sr105: :) np Jul 09 18:20:15 sr105: bitbake-layers can be useful for diagnosing those sort of problems too Jul 09 18:40:12 Note to self: create an empty image recipe for testing image classes. Jul 09 19:17:45 Is there any way to put ${VAR} inside a function and not have bitbake expand it *before* running the script (including in script comments)? Jul 09 20:16:08 sr105: nope. there's no escaping for bitbake variables Jul 09 20:16:19 sr105: if you're wanting to expand the shell variable, you can use $VAR, but otherwise your options are limited Jul 09 20:32:22 I ended up swicthing all my vars to $VAR unless it was one I knew was from bitbake. Jul 09 20:32:53 that's for the best, yeah Jul 09 20:32:54 hindsight is 20/20. I wish bitbake had used $(VAR) like make for it's own substitutions Jul 09 20:33:07 agreed, or % like rpm specfiles, or anything else really Jul 09 20:33:21 we wanted it to be something people were used to, and just caused confusion about what happens when instead Jul 09 20:33:25 :) Jul 09 20:33:28 :) Jul 09 20:34:01 its one of the most common sources of confusion, knowing the order of operations becomes important, even though ideally it shouldn't be something people have to be aware of Jul 09 20:34:38 course, you have to be aware of it even in makefiles, hence the need for := Jul 09 20:35:19 much of bitbake's format is make inspired. := and lazy expansion especially Jul 09 20:35:21 It made my here-docs easier to code. I didn't have to use backslash escapes since bitbake substitutes everywhere. Jul 09 20:36:35 I used a here-doc to generate my make_sdcard.sh script. I've been trying to figure out how to do it in such a way that it is easy for others to grok and mess with. Jul 10 02:25:08 * nerdboy having fun playing "student" **** ENDING LOGGING AT Thu Jul 10 02:59:58 2014