**** BEGIN LOGGING AT Tue Jul 19 02:59:58 2016 Jul 19 07:21:07 hey all Jul 19 07:21:21 I have a new error that has started popping around when working around Jul 19 07:21:37 ERROR: openvivoe-image-testpattern-1.0-r0 do_image_rpi_sdimg: Taskhash mismatch 771883a2e269a20a7462ed438687162c verses a61480386f516334b46dccd1c8a8676c for /home/jrosen/openwide/yoctoproject/meta-openvivoe/recipes-openvivoe/images/openvivoe-image-testpattern.bb.do_image_rpi_sdimg Jul 19 07:21:50 what is a taskhash mismatch, and how do I solve it ? Jul 19 07:22:28 I had it too last week, are you working with the latest revision from meta-raspberry? Jul 19 07:22:45 I think there is some patch, at least updating fixed it for me Jul 19 07:26:57 mathieu_la: yes i am... I will upgrade meta-raspberry Jul 19 07:27:01 thx for the hint Jul 19 07:34:20 hello Jul 19 07:34:30 anybody knows if genivi repos have issue ahain? Jul 19 07:34:38 again Jul 19 07:38:58 they sem to have sporadic access issues Jul 19 07:39:17 boucman_work : http://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/commit/?id=6564e126aea0ac42a129595c79218ba69f8095eb Jul 19 07:43:29 mathieu_la: yes, it seems to be solved now, thx Jul 19 08:10:17 whi is cleanall depending on upstream being available? Jul 19 08:10:24 why is cleanall depending on upstream being available? Jul 19 08:13:22 that's weird... Jul 19 08:15:13 i have issues getting node-state-manager from genivi and when trying cleannall it complains that upstream is not accessible Jul 19 08:16:17 Error is: Could not read from remote repository Jul 19 09:01:20 c0rnel: does the recipe use autorev? Jul 19 09:01:41 rburton, let me check Jul 19 09:01:54 because that needs network access to parse before it even starts running tasks Jul 19 09:02:13 (another reason why autorev is bad) Jul 19 09:03:42 no autorev in node-state-manager recipe Jul 19 09:06:52 then the recipe is doing something stupid Jul 19 09:06:53 it's form meta-ivi, anyway Jul 19 09:06:58 it's from meta-ivi, anyway Jul 19 09:07:00 eek Jul 19 09:07:12 http://git.yoctoproject.org/cgit/cgit.cgi/meta-ivi/tree/meta-ivi/recipes-extended/node-state-manager/node-state-manager_2.0.0.bb?h=master? Jul 19 09:07:55 yes Jul 19 09:09:04 nothing in there that would force network access, unless your distro/local conf is setting autorev on it Jul 19 09:09:12 a full cooker log would be helpful Jul 19 09:10:44 trying to get one, but meanwhile cat local.conf | grep auto shows nothing Jul 19 09:12:46 tmp/log/cooker has the logs Jul 19 09:14:06 no autorev there Jul 19 09:14:44 i mean, share the log Jul 19 09:18:16 I never new about tmp/log Jul 19 09:18:28 * boucman_work1 always go to WORKDIR/temp to find the logs... Jul 19 09:22:01 rburton, it will take a little time, i'm also in the middle of a meeting and one colleague is asking for some other info Jul 19 09:37:03 I still haven't figured out how to compile Qt5 for qemu (or native for that matter)... Jul 19 10:13:55 how do I collect a new license? I've added LMSL, which is our license (LICENSE="LMSL") and its checksum, however I need to "collect" it when I build the package. How do I do that? Jul 19 11:45:32 the reference manual says that "presently, the output from Python tasks is sent directly to the console." is that still true? i can't reproduce it. Jul 19 12:37:35 Is it possible to use here documents in image recipe sh functions? Jul 19 12:51:26 sveinse: should be fine. do a search for "< If my image recipe "require something.bb" and it uses ROOTFS_POST_PROCESS_COMMAND_append = "...", I will need to use += for the same variable right? Jul 19 12:53:56 sveinse: _append is magic. you never need to use += with it. Jul 19 12:54:22 FOO_append = "boll" FOO_append = "hav" will append "bollhav" to FOO Jul 19 12:55:46 _append stuff is also applied at the end of parsing, meaning there's no way to override it. FOO_append = "foo" followed by FOO = "" will still set FOO to "foo". Jul 19 12:56:00 += on the other hand is applied "there and then" Jul 19 12:56:26 allright. good. the append logic is done while parsing. The other alternative would be that it parsed everything and at the end it set FOO="${FOO_prepend}${FOO}${FOO_append}" Jul 19 12:57:20 yeah, that'd be another option. i guess the more "magic" solution turned out to be handier. Jul 19 12:57:34 the docs is not crystal clear when using multiple _append statements (or I've missed it) Jul 19 12:57:57 either is equally probable :D Jul 19 12:58:03 it might not be. the documentation maintainer is very friendly, so you could always suggest a change. :) Jul 19 12:58:08 i've gotten lots of stuff in Jul 19 13:20:10 what task do I need to rerun to make an image task execute its ROOTFS_POSTPROCESS_COMMAND? Jul 19 13:23:45 -c rootfs Jul 19 13:23:48 well, -C Jul 19 13:25:42 Can I access files from other recipes sources (not recipe dir) from another (image) recipe? Jul 19 13:27:55 sveinse: the clean way is to put them in the staging sysroot (STAGING_DIR_HOST) and accessing them there. if they're packaged (and not in some unusual path), then do_populate_sysroot will put them there. Jul 19 13:29:05 sveinse: the staging sysroot is how build-time dependencies (libraries, headers, etc.) are made available to recipes Jul 19 13:29:30 DEPENDS is (usually) just a shorthand for waiting for those other recipes to put their stuff into the staging sysroot Jul 19 13:30:57 sveinse: you can't access source trees as they may not exist, so if a recipe wants to share something it needs to be staged. Jul 19 13:31:25 so i guess what i meant is you can obviously just access WORKDIR/[recipe]/[version]/ but that may or may not exist Jul 19 13:32:35 Ulfalizer: My objective is that when I build the image, I auto generate a copyright manifest file for display on the end product. This file consists of various bits of text, like our address, from our main application SCM repo. Together with the Yocto collected licenses from usr/share/common-licenses/ Jul 19 13:33:21 So my problem is the manifest-script in the image recipe, where I need access to some text files from our SCM (which "belongs" to another recipe) Jul 19 13:33:40 sveinse: licensing stuff bores me to death (even though it's important), so i'm a bit of a noob when it comes to it :) Jul 19 13:33:45 So... I suppose, I want to know how I can stage a file from the other recipe then Jul 19 13:34:32 Ulfalizer: Well, I don't really need to bother with them either. I just need to collect them to be able to display them to the end user. Yocto goes a great job at that Jul 19 13:35:51 I do not need or want the staged file present on target, only for generating the manifest Jul 19 13:37:00 sveinse: using the same repository in two different recipes is okay. yocto might even be able to cache it. Jul 19 13:37:49 otherwise, the "owning" recipe will need to put the files you need into either the staging sysroot or e.g. DEPLOY_DIR_IMAGE (tmp/deploy, which is used for final build output, like images), and the other recipe access them there Jul 19 13:38:27 you need to set up the right dependencies in that case though. probably easiest to just have the same repo SRC_URI in both recipes. Jul 19 13:38:33 or reorganizing things in some other way... Jul 19 13:40:14 Ulfalizer: Making a recipe that makes a package with the said files is simple enough. But how do I deploy it/depend on it such that I can fetch it from my image recipe, but not deploy to target? Jul 19 13:41:00 (I'm only a 1 week old Yoctoer, so please have patience with me) Jul 19 13:42:05 sveinse: if you have a DEPENDS on that other recipe, then you can access the file as ${STAGING_DIR_HOST}/path/to/file (as long as you do it at or after do_configure, because do_configure is what depends on do_populate_sysroot in the other recipe) Jul 19 13:42:27 see STAGING_BINDIR, etc., too. those are based on STAGING_DIR_HOST. Jul 19 13:43:11 So, in my image recipe, I have IMAGE_INSTALL for that which ends up in the target, while I can use DEPENDS for the things that ends up the staging area? Jul 19 13:43:30 yup, that should work Jul 19 13:43:37 perfect, thanks Jul 19 13:43:44 one thing some recipes do is to append the staging function Jul 19 13:43:47 unless image.bbclass does something funky with the tasks Jul 19 13:43:52 but hopefully ;) Jul 19 13:44:05 ie wayland does sysroot_stage_all_append_class-target to drop more files into the staging directory that shouldn't be packaged Jul 19 13:45:45 sveinse: btw... there's quite a lot of updates in the latest version (2.2) of the reference manual, so might be worthwhile looking at that one vs. earlier versions Jul 19 13:46:46 yeah, I am. The mega manual is on my tablet :P Jul 19 13:47:06 the mega manual is too mega for me :S Jul 19 13:50:38 How do I deploy a new license from my recipe? Jul 19 13:50:50 Plain file location, or is there some functions for doing it? Jul 19 13:54:23 do you mean your recipe has a license that isn't covered by the collection in oe-core? Jul 19 13:54:31 yes Jul 19 13:55:04 eg meta-fsl-ppc/conf/layer.conf:LICENSE_PATH += "${LAYERDIR}/custom-licenses" Jul 19 13:55:16 put the license texts in your layer, extend license_path in your layer.conf Jul 19 13:56:34 http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#var-LICENSE_PATH Jul 19 13:56:38 its documented! \o/ Jul 19 14:09:32 yes, it is. Yet, having it in "glossaries" does not assist in how to do it. You still need to find it. Perhaps a suggestion of having a "cookbook" section in the manuals. A "how do I" section that shows the various pattern that a Yocto developer might encounter Jul 19 14:11:56 We decided more than a year ago to move to Yocto with our product, and we also employed a sub-contractor to do it for us. Now that I'm (finally) getting to learn Yocto, I see that they haven't always done things according to defacto standards. So in my opinion, setting policy/standards is an important part of maintaining Yocto. Jul 19 14:12:13 absolutely Jul 19 14:12:41 in fact there's a little effort going on in my team to write some short "how to" guides for non-trivial tasks, and i just added new licenses to that list Jul 19 14:13:03 rburton: brilliant, thanks Jul 19 14:16:38 rburton : might I add "changing a configuration file at image-generation time" to the list ? I'm doing it right now and it's a bit tricky Jul 19 14:17:09 rootfs postfunc, do what you need to do Jul 19 14:17:11 in particular, do_fetch and do_unpack are not executed for images, so you need to reactivate them Jul 19 14:17:30 but there is no easy way to unset a variable flag so you have to use inline python Jul 19 14:17:37 rburton: that's the easy part :P Jul 19 14:17:54 let me pastebin what I do Jul 19 14:17:57 why not package the image-specific file in a recipe and pick between them? Jul 19 14:18:27 http://pastebin.com/YRVgrTie Jul 19 14:18:57 because they overlay files from other packages (CONFFILES) and that creates conflicts iirc Jul 19 14:19:24 remove them from the other packages? Jul 19 14:19:50 that creates a lot of .bbappend when you are configuring a whole system and make the other packages much less generic Jul 19 14:20:00 you don't use distro_features_check in that recipe :) Jul 19 14:20:02 i'm deep in the yocto-as-a-firmware use-case here... Jul 19 14:20:10 ?? Jul 19 14:20:12 ah, yes, one of my questions as well. Handling overrides/file conflicts during system build Jul 19 14:20:26 you inherit distro_features_check but its not used Jul 19 14:20:47 rburton: I do ? where ? Jul 19 14:22:15 boucman_work1: 12 inherit core-image distro_features_check Jul 19 14:22:19 oh right, Jul 19 14:22:23 * boucman_work1 <= blind Jul 19 14:22:35 thx Jul 19 14:23:35 but yeah, the firmware use-case requires to override quite a few file, and doing it at the image-level is where it makes most sense, I believe... but the deactivation of do_fetch and do_unpack makes it non-trivial Jul 19 14:24:06 (and instinctively, I would have used do_install to install the files, but that's also deactivated and not required by do_rootfs) Jul 19 14:24:17 I can see various fixes Jul 19 14:24:19 yeah would be good to have an easier way to undo disabling Jul 19 14:24:24 file a bug against bitbake Jul 19 14:24:46 * change bitbake to accept do_xxx[noexec] = 0 Jul 19 14:25:07 * reactivate do_fetch and do_unpack in yocto for images Jul 19 14:25:19 * both Jul 19 14:25:24 (1) is my vote Jul 19 14:25:48 basically make the noexec thing need a positive assignment, not just presence, might work Jul 19 14:25:53 I think both makes most sense. fetching files for overriding and benefiting from the whole fetch/cache infrastructure seems like something needed Jul 19 14:26:03 but yeah, the bitbake side is definitely needed Jul 19 14:26:17 but if the task isn't needed generally then it can be disabled for performance Jul 19 14:27:55 that sounds a bit like a micro-optimisation, but maybe I see it that way because all I do is yocto firmware, so I need it all the time Jul 19 14:28:36 (ideally i'd like to add a generic overlay mechanism for images which would check that overlayed files are CONFFILES for the original recipe, but i don't know if that's doable Jul 19 14:28:47 when do you use PACKAGE_ARCH="${MACHINE_ARCH}" in recipes? Because I see in my build that I have many more packages that is built against tune (it's tune, right?) than machine Jul 19 14:29:04 yeah that's usual Jul 19 14:29:19 because we cater for the situation where you may target two MACHINES which are actually very similar Jul 19 14:29:32 think two different ARM boards, the CPU is identical but the HW will be different Jul 19 14:29:48 so, libc upwards can all be tune-specific, but the kernel and maybe drivers are MACHINE-specific Jul 19 14:30:30 so if your recipe is specific to a single instance of your machine then it needs to be machine specific, if it will work on all x86 / armv7 / etc then its tune specific Jul 19 14:30:33 This is indeed the case here. Same CPU but different boards. Pure SW tools, like most linux tools, are HW agnostic, and can be build to tune then Jul 19 14:48:01 What methods for conditional code/blocks are there in recipes? Is doing ${@bb.utils.contains the only way? I have two image recipes that are very similar and can be merged if there is some MACHINE selector I can use Jul 19 14:50:21 you can do commands based on the target machine using overrides Jul 19 15:27:31 rburton: speaking of disabled tasks, I noticed that do_configure[noexec] also disables validation of LIC_FILES_CHKSUM; would you consider that to be a bug? Jul 19 15:27:45 i.e. would you accept patches that move the check into a separate task? Jul 19 15:28:41 didn't we already do that? Jul 19 15:29:00 from my testing on master, I thought it was link to do_fetch... Jul 19 15:29:24 oe-core b7811bbec1ba373d62ace5c4fc56918e53c69d50 Jul 19 15:29:38 oh different license bits? Jul 19 15:30:57 let me check, we might be on a rotting branch... Jul 19 15:32:00 yeah thats LIC_FILES_CHKSUM Jul 19 15:32:08 now a postfunc on do_populate_lic Jul 19 15:32:11 Yeah, that fixes the issue. Only a month old, so of course it's not in what we call stableā€¦ Jul 19 15:32:56 yeah, master only Jul 19 15:55:39 success! Jul 19 16:22:49 Hmm, I don't get this license setup: I have in my recipe: LICENSE="LMSL" and LICENSE_FLAGS="commercial" and a LIC_FILES_CHKSUM with reference to upstream license file. I've added LICENSE_PATH += "${LAYERDIR}/licenses" and added licenses/LMSL to the layer. But still I get "WARNING: The license listed LSML was not in the licenses collected for recipe". What am I missing? Jul 19 16:23:42 try forcing a rebuild of that recipe? Jul 19 16:24:03 rburton: How deep? I've redone do_install Jul 19 16:24:34 populate_lic Jul 19 16:28:25 btw, I'm running off a EXTERNALSRC setup here (as I havent really got hg to work well with the recipe). I notice that it rebuilds my recipe every time. Is this a feature of using EXTERNALSRC? Jul 19 16:29:26 rburton: great, populate_lic worked Jul 19 16:29:47 * sveinse need to study all the various task steps during builds :) Jul 19 16:34:11 sveinse: that should have worked automatically Jul 19 16:41:42 I get three warnings when I start bb: WARNING: xyz is tainted from forced run: uim_1.8.6.bb.do_compile, sp.bb.do_build, lm-sp-image.bb.do_rootfs. Probably the same chain of events Jul 19 16:43:10 yeah they can be ignored, its just telling you that you forced a build Jul 19 16:44:15 rburton: yeah, but why is the question. I ran bitbake lm-sp-image when this happens Jul 19 16:45:39 because you used -C foo or -f Jul 19 16:45:50 just ignore them Jul 19 16:45:54 no I did not Jul 19 18:03:57 When I add bluez to IMAGE_INSTALL_append I get "'bluez' is unbuildable", but I have meta-openembedded/meta-oe correctly in bblayers.conf I and I can build a different package from there like zeromq Jul 19 18:04:05 for krogoth qemuarm Jul 19 18:07:11 how do I debug this? What is bitbake reading to find if/where a package is available? Jul 19 18:11:08 ok bluez5 seems to be doing something Jul 19 18:14:29 ok that seemed to work Jul 19 18:19:55 pthomas: yeah bluez might be blacklisted somewhere, it may conflict with bluez5 or something Jul 19 18:41:50 pthomas: do you need bluez4 or 5 Jul 19 18:42:57 I have multiple FILESEXTRAPATHS_prepend declarations in different bbappends in different layers. How do I ensure that my layer takes precedence? Jul 19 18:48:01 Conditional Syntax (Overrides) looks promissing, but also complicated. Any suggestions? Jul 19 18:49:30 organise your BBLAYERS in bblayers.conf Jul 19 18:50:01 aha, yes, that makes sense. Thanks khem Jul 19 20:47:54 organizing bblayers didn't work. BBFILE_PRIORITY was the key Jul 19 22:27:20 for FILESEXTRAPATHS yes priority matters Jul 19 22:27:43 for config files and other search paths which are implicit the order matters Jul 19 23:26:04 I am seeing these errors Jul 19 23:26:06 http://hastebin.com/ipolaveduv.tex Jul 19 23:26:10 when enabling ptest Jul 19 23:26:15 any ideas ? **** ENDING LOGGING AT Wed Jul 20 02:59:58 2016