**** BEGIN LOGGING AT Wed Jan 25 03:00:02 2017 Jan 25 07:42:24 if i fetch all sources with fetchall, and then upload all the tarballs to a webserver somewhere, is it sufficient to point PREMIRRORS at this somewhere to act as a mirror? Jan 25 07:42:39 do i need the .done files? or the git2 repos? Jan 25 07:51:38 miceopede: it should be sufficient, the .done files are not required. You will want to have "BB_GENERATE_MIRROR_TARBALLS = "1"" set so that the git2 repos are turned into tarballs in the downloads/ directory Jan 25 07:53:15 nrossi: thanks. the bitbaking process is smart enough to know (somehow), that a git srcrev or autorev has changed and pull new source if needed? Jan 25 07:54:03 miceopede: Yes it does, and it will use the mirror tarball to fetch first. Then update the git repo locally Jan 25 07:55:14 miceopede: This is the command i use to populate my http mirror from a local downloads/ Jan 25 07:55:15 rsync -d --progress --exclude=*.done --include=*.zip --include=*.tar --include=*.tgz --include=*.tar.gz --include=*.tar.bz2 --include=*.tar.lzma --include=*.tar.xz --include=*.rpm --include=*.sh --include=*.diff.gz --include=*.patch.gz --include=bash*-* --include=readline*-* --exclude=* Jan 25 07:55:48 nrossi: perfect. i was about to start writing a script. thanks Jan 25 08:29:47 Hi. I can do this: bitbake -c clean somerecipe ; bitbake somerecipe Jan 25 08:30:06 how do I do this in one commend: bitbake -c clean -c XXXX somerecipe Jan 25 08:30:16 what's equivalent XXXX for just not giving any -c Jan 25 08:30:25 ? Jan 25 08:30:47 ...or how to achive that effect with running bitbake just once (because running it twice is annoyingly slower of course) Jan 25 08:32:52 default is "-c build" but you may be interested in "bitbake -C task": it invalidates the given stamp and then runs the default task Jan 25 08:33:52 I'll try them out Jan 25 08:33:54 hyde: so if you know you need to force a compile and want to then run default task: "bitbake -C compile recipe" Jan 25 08:45:47 yeah, I think I'll be doing bitbake -C fetch for a while now Jan 25 08:46:39 there's no "standard" way to define, "fetch sources from that directory tree" (not version control, not tar.gz, just plain source directory tree), is there? Jan 25 08:46:49 (now I have custom do_fetch) Jan 25 08:48:21 morning Jan 25 08:48:45 khem: khem: mips32r2 kernel did not compile with gcc 6.3.0 Jan 25 08:49:06 I'll give you more details later this evening Jan 25 08:49:36 (MACHINE is gcw0 in meta-handheld) Jan 25 08:49:39 hyde: http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#ref-classes-externalsrc Jan 25 08:49:44 i'm wondering if anyone can explain subtle differnces between BBCLASSEXTEND = "cross" and inherit cross, I seem to be getting slightly different behavior for each Jan 25 08:51:49 specifically forcing PN_class-cross = "go-cross-${TARGET_ARCH}" with BBCLASSEXTEND = "cross" is not the same as PN = "go-cross-${TARGET_ARCH}" with inherit cross Jan 25 08:53:03 with the former, recipes that DEPENDS = "go-cross-${TARGET_ARCH}" fail due to unresolvable dependency go-cross-arm, with the latter resolution works just fine Jan 25 08:58:16 mborzecki: the class extension code is a bit magic. I don't think cross is designed to work with BBCLASSEXTEND Jan 25 09:00:30 that would explain why it's different, so the convention is to inherit cross for toolchain like packages? Jan 25 09:02:28 (i'm implementing khem's suggestion in oe-meta-go and they have a single recipe with BBCLASSEXTEND = "cross" magic) Jan 25 09:07:59 mborzecki: yes, there are such a small number of users that making cross work with BBCLASSEXTEND didn't seem worthwhile Jan 25 09:08:31 RP: makes sense, thanks a lot Jan 25 09:08:35 mborzecki: hmm, there is a user in oe-core doing that :/ Jan 25 09:08:49 (u-boot-fw-utils) Jan 25 09:09:19 u-boot-fw-utils is *special* :) Jan 25 09:09:52 mborzecki: so it seems :) Jan 25 09:10:15 guess, i'll just fix oe-meta-go Jan 25 09:10:30 mborzecki: that seems like the best thing to do Jan 25 09:10:44 it'd be nice to revive khem's thread about including go in oe-core, i'm not sure what the conclusion was the last time Jan 25 09:10:57 or at least meta-oe if oe-core is not a suitable place Jan 25 09:11:06 mborzecki: its not that BBCLASSEXTEND doesn't work, it just will behave a bit oddly and probably not buy you much Jan 25 09:11:37 mborzecki: I can't remember the conclusion either, but yes, good timing Jan 25 09:12:13 thanks a lot Jan 25 09:34:16 good morning Jan 25 09:53:12 regarding the new sysroots: how is it decided what goes into the fixmepath, and what doesn't? Jan 25 10:10:50 Hi, I have a task to run after do_rootfs and before do_image, but when I add the "before do_image" dependency it cause do_image to reexecute after a first build (causing do_image to fail because it does not have the files of do_rootfs, they add been deleted by do_rmwork and do_rootfs doesn't reexecute). I don't have any clue of why this is happening, anybody know ? Jan 25 10:11:18 they had* Jan 25 10:33:04 geoffrey_l: add a "before do_image after do_rootfs Jan 25 10:33:32 geoffrey_l: so that the task is executed after the do_rootfs (aka depending on it) Jan 25 10:38:57 nrossi : I already have "addtask install_overlay after do_unpack do_rootfs before do_image" but it cause do_image to rerun, and i don't know why (while do_rootfs does not and that cause the error). It work fine on first build, it's when I re-do "bitbake [myrecipe]" the problem appears. Jan 25 11:13:12 is it me or does runqemu and oe-run-native no longer work? Jan 25 11:14:19 nvm, it is me :/ Jan 25 11:19:48 kanavin_home: thanks Jan 25 11:35:44 RP: I can't use $MACHINE as a part of env file name. wic would have to know value of MACHINE variable to find it. Again chicken&egg problem. I'll use directory instead. Directory is passed to wic in the command line and wic is looking at .env in it. Jan 25 12:08:30 Building universe -c fetch ( 50 secs ) Jan 25 12:08:31 yay :) Jan 25 12:09:01 ed2: ok, that sounds reasonable Jan 25 12:46:19 Hi! I'm doing some tests to eSDK and in particular to a workflow that allow developers to easily update their development hosts: hence I try to update through devtool. I built an eSDK install script against my image that installs (and works) fine on devel's host, then I setup a place for updates and published the eSDK (the same version that is in the installer for now). Running 'devtool sdk-update' from and eSDK-aware s Jan 25 12:46:21 hell completes with no error at first run but abort with failure if I run it again. I understand this is not exactly a typical use-case, since it's not supposed to update anything (same eSD content) but, in my understanding, if it doesn't fail the first time, it shouldn't the second time either. The error that devtool spits upon the second run is the folloving: Jan 25 12:46:25 ERROR: Failed to update metadata as there have been changes made to it. Aborting. Jan 25 12:46:27 ERROR: Changed files: Jan 25 12:46:29 b' M poky/bitbake/lib/bb/pysh/pyshtables.py\n' Jan 25 12:46:33 Seems like some uncommitted changes are left in layers/.git. Jan 25 12:46:35 Since I'm a newbie with eSDK just wanted to ping here before, if that's the case, filing on bugzilla... In the meanwhile, I'm trying to reproduce on a core-image-minimal from poky master (hope to have luck building with recent per-recipe sysroot related stuff), to bisect any eventual relationship with my custom image/project setup... Any clue from any eSDK expert there? Jan 25 12:54:51 gizero76: that file is generated and probably should be in gitignore Jan 25 12:56:34 RP: should I just try to add to .gitignore and run again? Jan 25 12:56:47 gizero76: I think its worth a try Jan 25 12:57:19 gizero76: that file is in the top level .gitignore in poky so perhaps the generated eSDK one isn't right? Jan 25 12:57:22 or missing? Jan 25 12:57:57 gizero@gizero-desktop ~/poky_sdk/layers (master●)$ cat .gitignore Jan 25 12:57:59 *.pyc Jan 25 12:58:01 *.pyo Jan 25 12:58:25 .gitignore is there but no reference to that file Jan 25 12:58:32 gizero76: sounds like a bug Jan 25 13:03:49 RP: adding to .gitignore won't be enough, of course, since the file is already tracked by git, but committing removal and running devtool sdk-update makes it go further... Jan 25 13:04:49 gizero76: ultimately the fix is to change whatever genereates that file Jan 25 13:05:12 RP: ...and it finishes with no complaints ;-) Jan 25 13:07:00 RP: going to file it on bugzilla and report back if it happens with poky master also Jan 25 13:09:28 gizero76: pretty sure it will, patch would be great! :) Jan 25 13:09:33 RP: BTW 'bitbake core-image-minimal -c populate_sdk_ext' is almost completing, but giving warnings like: Jan 25 13:09:37 WARNING: core-image-minimal-1.0-r0 do_sdk_depends: Manifest /scratch/gizero/poky-master-build/tmp/sstate-control/manifest-allarch-packagegroup-core-boot.populate_sysroot not found? Jan 25 13:09:39 WARNING: core-image-minimal-1.0-r0 do_sdk_depends: Manifest /scratch/gizero/poky-master-build/tmp/sstate-control/manifest-allarch-core-image-minimal.populate_sysroot not found? Jan 25 13:09:41 WARNING: core-image-minimal-1.0-r0 do_sdk_depends: Manifest /scratch/gizero/poky-master-build/tmp/sstate-control/manifest-allarch-meta-environment-extsdk-qemux86.populate_sysroot not found? Jan 25 13:09:43 WARNING: buildtools-tarball-1.0-r0 do_populate_sdk: Manifest /scratch/gizero/poky-master-build/tmp/sstate-control/manifest-x86_64_linux-nativesdk-buildtools-perl-dummy.populate_sysroot not found? Jan 25 13:09:45 WARNING: core-image-minimal-1.0-r0 do_populate_sdk_ext: Manifest /scratch/gizero/poky-master-build/tmp/sstate-control/manifest-allarch-meta-environment-extsdk-qemux86.populate_sysroot not found? Jan 25 13:09:47 WARNING: core-image-minimal-1.0-r0 do_populate_sdk_ext: Manifest /scratch/gizero/poky-master-build/tmp/sstate-control/manifest-allarch-core-image-minimal.populate_sysroot not found? Jan 25 13:09:49 WARNING: core-image-minimal-1.0-r0 do_populate_sdk_ext: Manifest /scratch/gizero/poky-master-build/tmp/sstate-control/manifest-allarch-packagegroup-core-boot.populate_sysroot not found? Jan 25 13:09:51 WARNING: core-image-minimal-1.0-r0 do_populate_sdk_ext: Manifest /scratch/gizero/poky-master-build/tmp/sstate-control/manifest-x86_64_linux-nativesdk-buildtools-perl-dummy.populate_sysroot not found? Jan 25 13:10:07 gizero76: rss is a bit chatty at the moment. None of those are anything to worry about Jan 25 13:10:26 gizero76: there have been some of these which were though which was why it was left in Jan 25 13:11:29 OK! ;-) Out of curiosity, is all this eSDK workflow being QA tested by CI/autobuilders? Jan 25 13:12:02 gizero76: some but not as well as we'd like Jan 25 13:12:44 gizero76: probably why it works the first time but not the second (we don't test second try) Jan 25 13:13:38 RP: fair enough ;-) Jan 25 13:28:20 * RP remembers why he hates touching the gcc recipes Jan 25 14:52:43 RP: Thx for helping! filed https://bugzilla.yoctoproject.org/show_bug.cgi?id=10963 Jan 25 14:52:45 Bug 10963: normal, Undecided, ---, eduard.bartosh, NEW , devtool sdk-update fails at subsequent runs Jan 25 14:55:53 gizero76: fancy sending a patch to scripts/oe-publish-sdk ? Jan 25 14:57:41 RP: Surely I'll look at it as soon as I find a time-slot and see if I can figure it out... Jan 25 14:58:13 gizero76: its trivially easy Jan 25 15:15:13 hi all. How can i add a sanity check as the first task of my build ? Jan 25 15:15:29 i want to check if my meta-s are up to date with git origin Jan 25 15:19:46 binarym: it does not look to me like a check to be done with metadata, perhaps a script to check this before running bitbake? Jan 25 15:20:28 lsandov: i would like it to be part of bitbake Jan 25 15:20:43 because my developers are a bit crazy i don't like following process Jan 25 15:20:43 so Jan 25 15:21:04 ensuring my checks are run as part of bitbake is better for me Jan 25 15:21:29 binarym: all the existing sanity checksa re in the metadata. hacking bitbake is pointless. bitbake fires an event specifically for sanity testing Jan 25 15:21:30 (but i can understand that it isn't completly yocto-compliant) Jan 25 15:21:32 see sanity.bbclass Jan 25 15:21:49 yeah, i saw this Jan 25 15:22:30 kergoth: can i define a new bbclass (let's say mysanity.bbclass) that would inherit from sanity.bbclass and use it instead of sanity.bbclass ? Jan 25 15:22:48 you can have any class parsed up front by adding to the INHERIT variable, i.e. in your distro Jan 25 15:23:49 ok thx kergoth , i'll dig into this Jan 25 15:24:07 ideally, sanity.bbclass would provide hooks to inject custom sanity tests, but it doesnt have that feature as of yet Jan 25 15:24:15 it is possible to respond to SanityCheck yourself, though Jan 25 15:24:28 see https://github.com/MentorEmbedded/meta-sourcery/blob/master/classes/sanity-external-toolchain.bbclass for an example of how i hooked into it to run up front sanity tests on an external toolchain Jan 25 15:25:47 that particular example doesn't run every time, though, only when stuff it cares about changes. all the sanity_file and config bits are related to that, so you can just run whatever logic you want in a SanityCheck event handler, with something like https://github.com/MentorEmbedded/meta-sourcery/blob/master/classes/sanity-external-toolchain.bbclass#L70-L78 for when it fails Jan 25 15:26:02 you can read sanity.bbclass as well, but that's a rather large file due to all the sanity checks run Jan 25 15:26:30 i intend to propose making it easier to add custom sanity tests for upstream at some point Jan 25 15:27:26 thx a lot for this explanation Jan 25 15:27:42 no problem Jan 25 15:27:50 and yeah, i read the sanity.bbclass ... and got afraid. Jan 25 15:29:18 it's basically just events. bitbake fires SanityCheck, and if e.generateevents is true, you're expected to fire events for sanity check failure. of course, sanity.bbclass also fires an event for success.. this all ties into the particulars of the bitbake UI in use, i.e. toaster uses them to give the user info about the sanity checking, afaik Jan 25 15:29:30 bitbake fires all sorts of events at various points, and the metadata can fire them as well, so handlers can respond Jan 25 15:29:42 the yocto project docs probably have more info, at least the bitbake manual *should* :) Jan 25 15:36:27 binarym: it's worth noting that you *could* also do checking at ConfigParsed or BuildStarted time, it's up to you when you want the check to run in the process. SanityCheck is of course specifically intended for this purpose, however :) Jan 25 15:36:56 https://github.com/MentorEmbedded/meta-mentor/blob/master/meta-mel/classes/mentor-updates-check.bbclass just warns the user if update layers exist but haven't been added to their configuration, via a ConfigParsed event handler, for example Jan 25 15:48:37 kergoth: ok. Now, i just have to code it :) thx Jan 25 15:48:42 np Jan 25 15:49:40 downside to checks at ConfigParsed time is if they're fatal, it means you can't run bitbake -e. best to use SanityCheck. I might have to convert a few of my other checks to that Jan 25 16:10:24 bavery_fn: dreyna_: https://wiki.yoctoproject.org/wiki/Working_Behind_a_Network_Proxy Jan 25 16:12:48 anyone else using openembedded-commits ML to notice new changes? Jan 25 16:13:01 it stopped working in December, I've filled https://bugzilla.yoctoproject.org/show_bug.cgi?id=10967 Jan 25 16:13:02 Bug 10967: normal, Undecided, ---, leonardo.sandoval.gonzalez, NEW , Merged commits are no longer sent to openembedded-commits ML Jan 25 16:16:51 jama: reassign it to halstead? Jan 25 16:17:41 bavery_fn: dreyna_: https://bugzilla.yoctoproject.org/show_bug.cgi?id=10524 Jan 25 16:17:43 Bug 10524: major, Medium, 2.3 M3, david.reyna, NEW , Command line build monitoring broken when using custom builddir and config file Jan 25 16:21:00 I've added michael to CC Jan 25 16:21:05 but will reassign as well Jan 25 16:34:39 there's a way to run the opkg tool to keep the toolchain packages updated in the development host? Jan 25 16:35:12 I install the toolchain and I would like to keep my libraries updated just run the opkg Jan 25 16:39:44 hi all, does the order still matter in the bblayers.conf? Or is precedency decided only by BBFILE_PRIORITY? Jan 25 16:40:17 i read in an older forum that precedency can depend on the order in which you specify the layers Jan 25 16:54:27 hello Jan 25 16:55:04 I have a failure with meta intel io security do_patch quilt Jan 25 16:55:43 i am trying to get a devshell to debug why, but it fails to get a devshell via $ bitbake -c devshell audit Jan 25 16:56:07 Using this example, would the "inherit" lines be added to local.conf? or should I add to a layer.conf? https://wiki.yoctoproject.org/wiki/FAQ:How_do_I_set_or_change_the_root_password Jan 25 16:57:34 hello guys Jan 25 16:58:14 mcudev: local Jan 25 16:58:20 mcudev: hopefully the up to date documentation in http://www.yoctoproject.org/docs/2.2/mega-manual/mega-manual.html#ref-classes-extrausers will help more Jan 25 17:00:21 not really more helpful Jan 25 17:00:48 where is the correct location to define these items? local.conf a layer.conf? Jan 25 17:01:23 CTtpollard: ok Jan 25 17:01:24 thanks Jan 25 17:01:46 I have several layers A and B with bbappend files for the same psplash package. I need to set priority of the layer B higher then layer A, but in the bblayers.conf file A has the highest priority then B. Is it possible at all? Jan 25 17:01:55 or add to the image file you are building Jan 25 17:01:58 ERROR: ParseError at /conf/local.conf:35: unparsed line: 'inherit extrausers' Jan 25 17:02:27 mcudev: you can't inherit in a config file Jan 25 17:02:41 recipes and .inc and .bbclass support a variety of things config files do not Jan 25 17:02:43 only a class? Jan 25 17:02:46 ok Jan 25 17:02:57 if you want something inherited globally, up front, add to INHERIT Jan 25 17:03:02 see alos the yocto project documentation Jan 25 17:07:10 ok, added to INHERIT var. I'm still getting the yocto concepts Jan 25 17:21:17 ed2: your latest wic patch conflicts with one you sent earlier. i presume the obvious merge is right? Jan 25 17:22:46 ed2: ah its not. can you rebase onto master-next please. Jan 25 17:23:04 ed2: sure. Jan 25 17:23:51 cheers Jan 25 17:30:07 Hi, so I've managed to get an image with qt5 from meta-qt5 up and running Jan 25 17:30:31 rburton: sent v2 Jan 25 17:30:32 Now I'm trying to build the SDK with bitbake my_image_recipe -c populate_sdk Jan 25 17:31:17 It appears that to use this SDK to build Qt5 based apps I need host (x86_64) versions of qmake, lrelease etc... basically the qtbase build tools Jan 25 17:31:30 But I can't figure out a way of adding that to the SDK Jan 25 17:31:37 Could anyone help me out here? Jan 25 17:31:51 The targer is a Raspberry Pi 3 Jan 25 17:31:54 *target Jan 25 17:38:36 So far as I know, populate_sdk should build all the tools it needs for the target image. Are there qt5 apps in the target image already? Jan 25 17:39:14 seebs: No. The idea is that we build an OS image with yocto that includes all the libs we need including Qt5 Jan 25 17:39:29 But we distribute the app itself as a custom squashfs package Jan 25 17:39:56 Well, the trivial solution is to make an image that includes a qt5 app, and then just remove that one app. :P Jan 25 17:40:00 Which means I need to compile the Qt5 app with a cross-compiler toolchain that poky builds for me Jan 25 17:40:32 So I added nativesdk-qtbase to my IMAGE_INSTALL_append Jan 25 17:40:39 And it seems to be building something Jan 25 17:41:23 populate_sdk has all the Qt5 libs in the cortexm7 sysroot Jan 25 17:41:38 But I need qmake and other qt build tools in the x86_64 sysroot Jan 25 17:45:23 rburton: v2 has a typo. please, don't merge it. Jan 25 17:46:18 Okay - it doesn't actually build a nativesdk package Jan 25 17:46:29 E: Unable to locate package nativesdk-qtbase Jan 25 17:58:22 anyone having a problem during patch of corei7-64-oe-linux/audit/2.3.2-r8 in the intel iot security layer? Jan 25 18:02:44 rburton: sent v3. I'm going to run wic tests on master-next as soon as build is done. Jan 25 18:54:33 anybody getting a failure with do_assemble_fitimage in linux-yocto-rt-4.4.36? Jan 25 20:04:51 im familiar with make bzimage, vmlinux, intrd, etc. Jan 25 20:05:10 im unfamiliar with assemble fs fit image Jan 25 20:05:41 yet it fails when doing the linux rt kernel. Is this something part of yocto or something in the kernel? Jan 25 20:39:02 khem: hi Jan 25 20:39:16 mipsel kernel failing: http://pastebin.com/Z5QWtjys Jan 25 20:39:42 fatal error: linux/compiler-gcc6.h: No such file or directory Jan 25 20:40:50 googlin' for it, sems a known issue Jan 25 21:11:55 jeez, it's because it is an older 4.0 kernel Jan 25 21:13:16 khem, do you think smthg like that could aid? http://tinyurl.com/he4cwpf Jan 25 21:33:41 khem: I'm lazy so I moved to a kernel v. 4.7 which compiles fine with gcc 6.3.0 Jan 25 22:57:12 How do I tell bitbake that certain files generated by a recipe should not be part of sstate? Jan 25 22:59:54 hbruce: don't install them into the dir that sstate tracks. Jan 25 23:00:10 hbruce: can you explain the issue you're attempting to solve? Jan 25 23:05:20 anyone seeing errors like this: Jan 25 23:05:22 ERROR: gcc-source-6.3.0-6.3.0-r0 do_patch: Command Error: 'quilt --quiltrc /home/jenkins/oe/world/shr-core/tmp-glibc/work-shared/gcc-6.3.0-r0/recipe-sysroot-native/etc/quiltrc push' exited with 0 Output: Jan 25 23:05:26 /bin/sh: 1: quilt: not found Jan 25 23:05:48 makes my first bitbake world build with recipe sysroots a bit useless Jan 25 23:05:49 Summary: There were 1675 ERROR messages shown, returning a non-zero exit code. Jan 25 23:07:02 and quilt seems to be default, so I'm not sure why I'm first one to report it (here) Jan 25 23:07:05 meta/conf/bitbake.conf:PATCHTOOL = "quilt" Jan 25 23:10:54 whaaaaa Jan 25 23:11:14 JaMa, I think use of quilt has been banned. Jan 25 23:12:17 eta/classes/patch.bbclass:PATCHDEPENDENCY = "${PATCHTOOL}-native:do_populate_sysroot" Jan 25 23:12:17 meta/classes/patch.bbclass:do_patch[depends] = "${PATCHDEPENDENCY}" Jan 25 23:12:28 so, why isn't that working Jan 25 23:13:31 paulg: banned? by who? Jan 25 23:13:49 The White House. :) Jan 25 23:14:02 ah that explains it Jan 25 23:14:17 JaMa: the depends work here - building m4 results in quilt appearing in m4's recipe-sysroot-native Jan 25 23:16:11 bluelightning/kergoth: I'm working with with meta-ros (see http://www.ros.org) which builds with cmake. Part of the build generates cmake files with hard coded paths (nasty) which end up in sysroot. If then you build in a different folder but use sstate, bitbake pulls in cmake files from sstate with paths from original folder and build fails. I want to prevent those generated cmake files from ever getting into stsate. Jan 25 23:17:10 hbruce: are the paths to the target sysroot, or the work directories? Jan 25 23:18:21 rburton. Paths are to target sysroot. Jan 25 23:19:21 rburton: does it require newer bitbake (and was the required version bumped in metadata to make sure it's new enough?) unfortunately in that jenkins job where it all failed I don't see bitbake revision used just BB_VERSION = "1.32.0" Jan 25 23:20:18 rburton: I take that back. Some paths are to work dirs, others are to target sysroot. Jan 25 23:21:11 hbruce: the target sysroot ones probably get replaced, the workdir ones should be causing a warning and is a bug in the software. figure out where they come from, and delete them. likely upstreamable. Jan 25 23:23:11 JaMa: i didn't think oe-core master needed master bitbake but i may be mistaken Jan 25 23:26:55 rburton: Thanks for guidance. I'll re-build and look for warnings. ros code maintainers reluctant to take build-related patches, which is why i wanted to solve the problem in meta-ros. Jan 25 23:27:00 btw I see in the cooker log that quilt-native was actually built: Jan 25 23:27:04 NOTE: Running task 25 of 33033 (/home/jenkins/oe/world/shr-core/openembedded-core/meta/recipes-devtools/quilt/quilt-native_0.65.bb:do_populate_sysroot) Jan 25 23:36:08 bluelightning: call? Jan 25 23:36:26 bavery_fn: check your email ;) Jan 25 23:37:28 rburton: maybe the PATH isn't correctly set to include recipe-sysroot-native? and it works for most people because they also have quilt on host in /usr/bin/quilt? Jan 25 23:41:45 JaMa: i don't have quilt on host Jan 25 23:41:47 * rburton bed Jan 26 00:28:14 anselmolsm: Jan 26 00:28:27 ah I was looking for ant_home Jan 26 00:28:39 :) **** ENDING LOGGING AT Thu Jan 26 03:00:01 2017