**** BEGIN LOGGING AT Wed Jul 27 02:59:58 2016 Jul 27 05:06:36 hmmm, linux-libc-headers-4.4 is missing one tiny #define Jul 27 05:07:10 and it's needed by python-evdev Jul 27 05:08:10 i'm a teensy bit behind on krogoth, so unless that was recently fixed? Jul 27 05:31:01 Hi, I have seen if I do a package as well native via BBCLASSEXTEND there is no native package generated ... is there a way to do it anyway? Jul 27 06:13:21 anyone built a NOMMU yocto image? Jul 27 07:55:27 MDNNeo: bitbake -native should do it Jul 27 07:56:21 redengin: there is some work on baremetal, I encourage you to look at zephyr project which is using Yocto project infra for baremetal rtos Jul 27 07:57:03 nerdboy: header missing a define is almost like an API change if kernel intended users to use it Jul 27 07:57:18 nerdboy: its not clear what you are referring to though Jul 27 07:57:56 khem, my google-foo is lacking can you provide a link? Jul 27 07:59:01 https://www.zephyrproject.org/ Jul 27 07:59:26 khem, do you participate on NOMMU builds? I'd like to know what the modern standard is for placement independence Jul 27 07:59:40 redengin: FDPIC Jul 27 08:00:28 atleast some arches like SH and blackfin has support for it Jul 27 08:01:49 khem, has OE adopted FDPIC? Jul 27 08:02:09 redengin: I dont think so. Jul 27 08:02:24 in the past OE supported uclinux target Jul 27 08:02:36 for avr IIRC but it has bitrotted Jul 27 08:03:15 now you can build SDKs from OE which can then help you compile your nommu application Jul 27 08:03:19 yeah, I'm willing to raise those bodies, just want to make sure FDPIC has future momentum Jul 27 08:03:35 redengin: it should be. Jul 27 08:04:27 khem: isn't it exactly not doing it .. so for target we do ipk packages and i can find the not native one but not if I bitbake pkg-native? also checked the native.bbclass it explicit inherit nopackage Jul 27 08:04:43 I'd still like to see an MPU emulation of an MMU evolve, but I can save that for another time Jul 27 08:06:18 MDNNeo: thats right, we do not build packages for native tools, they are just used during build anyway Jul 27 08:06:21 khem, would you have a link to the fdpic maintainers? Jul 27 08:06:52 redengin: for OE ? Jul 27 08:07:04 there isnt any but I can help Jul 27 08:07:11 khem, no for evolution of fdpic Jul 27 08:07:49 redengin: docs hmmm, there are lot of discussions atleast in musl forums on implmenting nommu and fdpic is clear winner Jul 27 08:07:57 e.g. see http://lists.nommu.org/pipermail/0pf/2015-September/000033.html Jul 27 08:08:02 khem, i.e. if I want to evolve an MPU into an emulated MMU, I'll need some fdpic support Jul 27 08:08:28 khem: if there is a way to do it still ... so maybe some background its just a pretty simple pckg with xml schemas and I want to share them some how easily to validate on target or on some host (not necessarly have the full yocto envirionment) Jul 27 08:09:25 MDNNeo: you can make such pakages as *all* type Jul 27 08:10:10 khem, sounds like my best bet is musl to find some brethren Jul 27 08:10:15 MDNNeo: just add inherit allarch and remove BBCLASSEXTEND = "native" Jul 27 08:10:29 k, thx ... will give it a try Jul 27 08:10:40 redengin: yes, other option is uclibc but thats more or less stagnant project Jul 27 08:11:04 redengin: whats your motivation for nommu and what arch are you looking at Jul 27 08:12:10 khem, cortex-r/m Jul 27 08:12:33 redengin: yeah, we would be happy if you can contribute the port to musl Jul 27 08:12:48 since sh2 is in now Jul 27 08:12:56 khem: perfect ... works ... should have tought of this on my own it sounds even more clean anyways Jul 27 08:12:59 you do have a template Jul 27 08:13:45 there are tweaks needed in binutils and gcc at times. Since mmuless systems didnt have uniform ABI Jul 27 08:14:21 redengin: see this http://git.musl-libc.org/cgit/musl/commit/?id=7a9669e977e5f750cf72ccbd2614f8b72ce02c4c Jul 27 08:14:34 khem, perhaps you can also settle an argument I've had with a coworker. Does the linux kernel have any dependency on the *libc? Jul 27 08:14:50 redengin: no Jul 27 08:15:20 khem, I agree, but I wasn't 100% sure Jul 27 08:15:23 redengin: but when it comes to nommu then it does Jul 27 08:15:41 khem: hi, sorry to jump in. I'm back testing musl and I'd need a bit of help with old qte (OPIE). There is a list of obsolete toolchains in the qt sources and musl is not there. Which one should I take as example? Jul 27 08:15:44 khem, only in the sense of which ldd.so it pulls Jul 27 08:16:49 khem, if the ldd.so places things in memory nicely, the kernel has no care Jul 27 08:17:29 ant_work: dont get it. but I think it will require some work for OPIE to work with musl Jul 27 08:18:09 I have doubts about the right triplet to use like oe-musl-gnueabi Jul 27 08:18:35 redengin: not sure about the dependency to kernel isn't it that the glibc headers are used during kernel compilation Jul 27 08:19:29 MDNNeo, but only portions of the headers that are considered portable Jul 27 08:19:29 redengin: yes, if its relocatable etc. are artifacts of no MMU abi Jul 27 08:19:53 MDNNeo: no its other way around Jul 27 08:20:25 ... ah yes ... both is right Jul 27 08:21:37 ant_work: oe-linux-musleabi for ARM EABI Jul 27 08:21:52 hm, I see Jul 27 08:21:54 ant_work: and oe-linux-musl for rest of the arches Jul 27 08:21:54 I got Jul 27 08:22:08 khem, whats the vision of musl libc? is NOMMU a necessary objective? Jul 27 08:22:10 ERROR: qte-mt-2.3.10-r32 do_configure: Function failed: do_configure No shared library support for platform/compiler linux-musleabi-arm-g++-shared Jul 27 08:22:32 it seems to be in qmake_base_legacy.bbclass Jul 27 08:22:39 case ${QMAKESPEC} in ... Jul 27 08:22:57 redengin: yes nommu is game. The real aim is to have POSIXly C library for linux Jul 27 08:23:29 ant_work: yeah you have to fix the specs for qmake Jul 27 08:23:58 ah, ok, adding it under qt-2.3.10/configs Jul 27 08:24:00 khem, well its easy to drop NOMMU for POSIX, hence the reason I asked Jul 27 08:24:41 redengin: I think nommu is of interest as sh2 has got it now. Especially FDPIC Jul 27 08:24:54 sounds like I should get to work on MMU emulation via MPU Jul 27 08:25:24 redengin: hmm, thats interesting although, I am not sure about performance Jul 27 08:26:58 khem, what performance are you worried about? (e.g. number of context switches, cycle cost of remapping mpu)? Jul 27 08:27:14 khem: besides, my last build showed pretty similar sizes for core-image-base musl/glibc...unexpected Jul 27 08:27:45 that was default distro / arm Jul 27 08:28:30 maybe the stripping is not properly done? I'll check Jul 27 08:33:02 redengin: yeah Jul 27 08:33:19 redengin: in general the MPU latency and access to external storage Jul 27 08:34:16 ant_work: hmm, must is about 600K which include libm+libc+librt and other utils Jul 27 08:34:26 ant_work: glibc is around 2M Jul 27 08:34:37 so you should atleast see that difference Jul 27 08:35:10 well, I've kept both images iirc, I'll give you details Jul 27 08:35:42 note that my images does include the 2Mb kernel so one big part is that Jul 27 08:36:11 thus I wasn't expecting an enormous saving Jul 27 08:40:05 khem: fwiw it was core-image-base + modules = 17119K, musl was 17108K Jul 27 08:41:37 tht was June 19th, I'll give you fresh figures Jul 27 08:41:39 thanks Jul 27 08:46:04 khem, I need to test, but I believe the MPU latency is minimal on these TI platforms, if that assumption holds, paging of external storage will be only bound by the drivers/external-bandwidth Jul 27 08:46:51 redengin: sounds good Jul 27 08:47:06 ant_work: ok Jul 27 08:47:18 * khem -> sleep() Jul 27 08:47:45 gn Jul 27 11:57:41 yocto default parallel build options don't work at all anymore in our project. Has anyone set memory usage limits to every do_compile calls? ulimit or cgroups? Jul 27 11:58:41 if there are no limits, developers consume it all, and more. Single c++ compile process taking 20 gigs of RES == physical ram. grazy. Jul 27 12:09:33 RP: did you have time to dicuss my bitbake patch ? Jul 27 12:13:49 boucman_work: I've wanted to talk to kergoth about it. I think its ok, I just want to talk with Chris before we add syntax since its hard to change later Jul 27 12:25:16 mcfrisk: i wonder if it would be possible to write a class to fiddle cgroup stuff in do_compile tasks Jul 27 12:31:50 RP: ok, cool, take your time. I have the python workaround so I don't need it right away... it's just on my list of "patch on projects I can't commit myself and need to bug the maintainers" :P Jul 27 12:46:53 don't know what it's about, but please also submit documentation patches if you introduce new syntax Jul 27 12:56:47 I am working on a larger recipe with a lot of depends, and a week ago I got a lot of complaints from QA about missing RDEPENDS, but now I don't get any. Why might that be? Jul 27 12:57:05 Is this because DEPENDS are automatically promoted to RDEPENDS? Jul 27 12:57:57 Because I see the debs (and ipks) have a rather long list in there Depends section, which I have not explicitly specified Jul 27 13:01:24 rburton: ok, similar to current PARALLEL_MAKE handling I guess. Jul 27 13:02:08 hi guys Jul 27 13:02:29 having 20 cores (40 with hyberthreading) and only 64 gigs of ram is bad with current yocto parallel defaults, and 'modern' c++ programmers and their template crap Jul 27 13:02:50 Everytime I bitbake my image it starts to compile the whole linux-yocto, no matter if there is no modification Jul 27 13:03:11 someone know if its a known mistake or something predictable? Jul 27 13:05:38 igor2: sounds like there is a bug somewhere but OE-Core doesn't do that as far as I know Jul 27 13:06:20 humm... I thought I was doing something wrong Jul 27 13:06:44 thank you RP Jul 27 13:31:32 sveinse: probably what's happening is that your app is detecting dependencies and enabling/disabling features, so if it eg finds bzip2 it may enable bzip2 usage and therefore link to libbz2. as you don't DEPEND on bzip you'll get a warning that this is happening. Jul 27 13:32:02 sveinse: however now your sysroot doesn't contain those extra dependencies, so when it rebuilds it disables bzip2 and doesn't link to libbz anyore Jul 27 13:33:52 rburton: My objective with this is to make sure I have the proper list in RDEPENDS, and it concerns me that QA no longer complains about it :( Jul 27 13:34:11 mcfrisk: i have been wondering about changing the auto-detect logic to be slightly more advanced, basically threads=ncores for <4 and after that ncores/2 or something Jul 27 13:34:55 sveinse: as you know you have a recipe which is doing this you could just read the configure script or whatever it uses and see what DEPENDS you are missing and/or what options you need to explicitly disable Jul 27 13:35:22 rburton: Well, my app has no option not to link against a feature, so when I put bzip2 in its DEPENDS to allow it to build, it does not complain about missing libzip2 in RDEPENDS evidently Jul 27 13:35:51 the QA message is when you RDEPEND on something that isn't provided by anything in DEPENDS Jul 27 13:36:09 generally when you link to a library (which turns into a RDEPENDS automatically) which you don't DEPEND on Jul 27 13:36:13 rburton: Ah, there you go. So there /is/ an implicit RDEPENDS feature. Thanks Jul 27 13:36:37 yeah, as with every other packaging system, library linkage -> runtime dependencies Jul 27 13:36:56 Other systems, such as debian dependencies, don't do this. You have to explicitly put libs in both DEPENDS and RDEPENDS Jul 27 13:37:00 they do Jul 27 13:37:36 (https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-dpkg-shlibdeps) Jul 27 13:38:00 and we use bits of rpm to do the dependency generation Jul 27 13:40:05 No, but you need to use some specific directives to do that, afaik. Before I explain why, one question about yocto's depend system: DEPENDS is that referring to a source package, what is called a recipe here, or a package? And RDEPENDS is refering to packages, right? Jul 27 13:41:31 DEPENDS is build time so recipes, RDEPENDS is runtime to packages Jul 27 13:41:32 Because a recipe might generate multiple packages. That implies that you don't necessarily want to RDEPENDS to depend on all packages a recipe generates, right? Jul 27 13:41:43 you rdepend on the package that you need Jul 27 13:42:00 So with implicit put-in-DEPENDS-then-its-automatically-RDEPENDED, can you control it then? Jul 27 13:42:19 not sure you understand what's happening magically Jul 27 13:42:29 I guess I don't Jul 27 13:42:55 Say boost. this is one recipe, but generates a lot of packages Jul 27 13:42:56 you have a binary that links to libz. libz is provided by zlib. packaging generates a RDEPENDS=zlib for you Jul 27 13:43:28 sure so you have a binary that links to libboost-clock.so, so adds a RDEPENDS=libboost-clock. Jul 27 13:43:35 if you don't also DEPEND on boost then you get a QA warning Jul 27 13:43:48 I need DEPENDS=boost, but I only want RDEPEDS=boost-filesystem, not the other things boost generates Jul 27 13:43:53 yes Jul 27 13:43:58 thats what happens Jul 27 13:44:21 (have a look at the dependencies) Jul 27 13:44:45 Yes, I see from my debs, that is indeed does only depend on the libboost-filesystem as you say. So yes, there is some magic there. good Jul 27 13:45:26 fwiw you can opt out of the shared library depends in debian, but the upload would be rejected on review Jul 27 13:46:23 It's equivalent to ${shlibs:Depends} then I belive Jul 27 13:46:31 yes, precisely Jul 27 13:46:46 yeah exactly the same Jul 27 13:47:15 ok, good to know. And this was indeed my quesiton, so thanks Jul 27 13:49:18 Then the scheme for a new package is make sure that DEPENDS contains what it needs to build and you are mostly OK with RDEPENDS in terms of libs at least Jul 27 13:49:30 yeah Jul 27 13:49:42 perfect Jul 27 13:49:52 one trick is to build world then your recipe and see if you get any warnings Jul 27 13:50:33 (JaMa does that for a number of layers automatically and mails the lists with the warnings) Jul 27 13:51:28 I think it was you who told me to start off a wiped sysroot and stop building at do_compile to ensure as little polluted sysroot from other recipes going on in parallel. Jul 27 13:51:40 That has worked out well Jul 27 13:52:01 yeah that also helps weed out hard failures where the recipe will fail to build with missing deps Jul 27 13:52:51 ...and possible races, as sometimes sysroot contains a missing, but required package, and sometimes not Jul 27 13:54:43 scripts/test-dependencies.sh is the script which does this automatically Jul 27 13:55:24 builds world, rebuilds tested recipes separately, then wipes sysroot and builds them again and compares RDEPENDS in those 2 builds Jul 27 13:56:09 this way it catches more issues than those QA warnings along (e.g. packages not created at all often in things like gstreamer plugins) Jul 27 13:56:47 JaMa: Cool, I'll take a look at it Jul 27 13:57:07 its "a bit" time intensive but very complete Jul 27 13:57:30 Does it work with sstate caching? Jul 27 13:58:14 it does, but in the end it needs to rebuild each tested recipe without sstate Jul 27 13:58:42 and twice (with maximal and minimal sysroot) Jul 27 14:03:39 i did say its time intensive :) Jul 27 14:06:39 JaMa, you're maintaining Qt5 right? Jul 27 14:09:18 running yocto on sabrelite board, why is my sdcard readonly? Jul 27 14:09:22 mmcblk0: mmc0:aaaa SL08G 7.40 GiB (ro) Jul 27 14:09:40 nothing indicates why... Jul 27 14:13:00 you didn't flip the lock switch on the sd did you? Jul 27 14:13:01 :) Jul 27 14:14:14 rburton: I did check. and I'm writing new images from my dev machine all the time Jul 27 14:14:33 sveinse: yes, but recently I don't have much time for it Jul 27 14:14:59 sveinse: I've seen your question, but don't know the answere without digging the history why it is as it is now Jul 27 14:15:04 cat /sys/block/mmcblk0/ro: 1 /sys/block/mmcblk0/force_ro: 0 Jul 27 14:18:20 JaMa: All right, thanks thou. I also saw you discussion with the Qt devs and you, and it seems there are some, lets say some controversy on how Qt thinks cross builds should be and how Yocto does it. Nevertheless we've worked around the issue by using conditional qmake and ExternalHostBinaries. Jul 27 14:20:10 E.g. Qt insists on generating versioned libraries, but when using plugins, they load the unversioned .so. Yocto places the symlink into -dev by default... Jul 27 14:21:03 a more accurate way to describe that would be that qt is building versioned libraries instead of modules Jul 27 14:21:10 when it actually wants a module Jul 27 14:22:12 rburton: yup. But trying to explain the fact to Qt devs seems to be talking to a wall, unfortunately. I have to setup my own LDFLAGS to circumvent it Jul 27 14:32:04 sveinse: yes, but these discussions were before even 5.0, since then they added something similar as ExternalHostBinaries but unfortunately I haven't had enough time to adapt our changes to use that instead our own ExternalHostBinaries Jul 27 14:32:32 sveinse: or even to verify that their new atempt (IIRC meant mostly for android) can be used for our purposes Jul 27 14:48:10 Hi there! I'm trying to bitbake a minimal image for an aarch64/armv8 machine Jul 27 14:49:12 When I run "bitbake linaro-image-minimal" or "bitbake core-image-minimal" I get the following error: Jul 27 14:49:29 ERROR: Nothing PROVIDES 'virtual/kernel' Jul 27 14:49:30 ERROR: linux-linaro-aarch64 PROVIDES virtual/kernel but was skipped: PREFERRED_PROVIDER_virtual/kernel set to linux-linaro, not linux-linaro-aarch64 Jul 27 14:50:17 I did "echo 'MACHINE= "genericarmv8"' >> conf/local.conf" Jul 27 14:50:45 and added all the dependency layers to conf/bblayers.conf Jul 27 14:52:08 Does anyone know where to start looking for the problem? Thanks Jul 27 15:01:49 'linux-linaro' doesn't have a 'virtual/kernel' provide in it -- but the system is tryingt o be helpful and saying 'linux-linaro-aarch64' does.. Jul 27 15:02:23 so something in your system has 'PREFERRED_PROVIDER_virtual/kernel = "..." set wrong Jul 27 15:36:54 ernstp: may be you have readonly-rootfs in image_features Jul 27 15:38:26 rburton: only way to ensure predictable builds with autotools being more intelligent then humans, is to have recipe specific build time sysroot Jul 27 15:39:25 or cache all the configure variables so that a rerun of configure would not run the probes Jul 27 15:39:39 freebsd this that, and it was valuable Jul 27 15:39:47 s/this/did/ Jul 27 15:48:02 baah, it's not the fact that test-dependencies.sh takes a lot of time, but the fact it eats disk space. I'm full once more. Is there a way to resume when it stops because of STOPTASKS? Jul 27 15:59:41 fray: thanks! it's compiling now Jul 27 16:12:53 sveinse: have you inherited rm_work? Jul 27 16:19:43 regarding BB_SRCREV_POLICY="cache", was there a bug fix for removing the 'cache' dir not causing a re-cache (and subsequenty potential re-build) of packages? I'm currently on a fairly old fork of poky (from what I can tell), and I'm not able to force a re-cache just by deleting the cache dir. Jul 27 16:21:03 specifically, I'm on ~daisy-11.0.3 Jul 27 17:18:09 (I lost my link for minute there, so I don't know if my question got answered while away) Jul 27 17:19:08 I found on the web I can override with an empty do_rm_work() function for those recipes I want not to run rm_work on. But that will require me to modify the receipes. I can't do that from local.conf, where I define the rm_work in the first place? Jul 27 17:26:19 sveinse: rm_work is added via a bbclass Jul 27 17:27:20 jmesmon: deleting cache dir should enforce recaching Jul 27 17:27:23 even on daisy Jul 27 17:28:01 khem: Sorry, but what does that mean? Jul 27 17:29:31 sveinse: I was trying to hint you to read through :) however RM_WORK_EXCLUDE can be set in local.conf to blacklist recipes from rm_work Jul 27 17:30:01 sveinse: however, rm_work might kill your HDD faster than usual Jul 27 17:31:26 khem: heh, yes, I'm on SSD :P -- but it does not help much when it's full :P Jul 27 17:35:15 khem: And sorry for being slow and not taking the hint. Now I've read it. Thanks Jul 27 17:41:16 Hello :) Jul 27 17:42:15 I am building something cool with the Intel Edison, and I need to have a kernel driver loaded `modprobe snd-virmidi`, but it is not there "FATAL: Module snd_virmidi not found." How can I install it? Jul 27 17:47:45 khem: i mean include/uapi/linux/input.h is missing one #define that is not missing from build host header Jul 27 17:48:21 and python-evdev does not compile without it Jul 27 17:48:31 +#define BUS_RMI <= missing Jul 27 17:53:30 Technicus: you need to add the module to your image. you can add just this one module or you can add all by doing MACHINE_EXTRA_RRECOMMENDS = " kernel-modules" in your machine configuration file Jul 27 17:53:57 nerdboy: what kernel version do you have on build host ? Jul 27 17:55:04 khem, will you please explain the machine configuration file to me? Jul 27 17:56:07 4.3.5-hardened-r2 right now Jul 27 17:56:19 should be another one ready... Jul 27 17:57:28 but it has linux-headers-4.6 Jul 27 18:00:08 khem: Do I need to completely reinstall the OS? Jul 27 18:01:14 khem: and it's true for versions of python-evdev back to 0.4.7 Jul 27 18:02:46 beaglebone kernel is up to 4.4-ti/4.7-bone Jul 27 18:03:24 i have it as _append_beaglebone right now Jul 27 18:25:06 looks like 4.6 headers got the update, and python-evdev-0.4.5 compiles against the older ones Jul 27 18:26:20 so i have no idea how 0.6.0 ever compiled without 4.6 Jul 27 18:26:51 * nerdboy looks funny at moto-timo Jul 27 18:38:19 khem: Is this: < http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#closer-look > where I will find my answer? Jul 27 21:07:09 hi guys, is udev part of systemd package these days? Jul 27 21:19:04 yup Jul 27 21:19:13 eudev is the fork Jul 27 21:31:03 Xz: if systemd is in your distro features then you get the udev that is built by systemd, otherwise you get eudev. Jul 27 21:36:08 How do I add add modules to the kernel? Specifically I need to add snd-virmidi . Jul 27 21:36:18 rburton: the parallel job logic needs to take into account CPU's and RAM (not swap, swapping is bad), and it should monitor builds and allow to start processes only if memory and CPU is available. Hitting kernel oom killer during builds is bad. Sometimes the failures bitbake build logs don't even show that gcc/g++ or similar got killed due to oom. And in our case I really wan't to punish developers who requ Jul 27 21:36:24 ire up to 20 gigabytes of RSS/RAM for a single g++ compiler process. Thus setting cgroup/ulimit limits for tasks makes sence, offender gets killed instead of random other build due to oom. Jul 27 21:39:23 rburton: nerdboy thanks Jul 27 21:42:14 cgroups++ Jul 27 21:42:49 Xz: you didn't say which branch Jul 27 21:42:52 a beer for the first person to write a class that puts each compile task in its own cgroup Jul 27 21:43:06 eudev isn't everywhere... Jul 27 21:43:27 nerdboy: well, on the image I have udev installed, that's a fact Jul 27 21:43:42 nerdboy: I'm just trying to figure out how to make a recipe that will add 1 rule Jul 27 21:43:50 that change was fairly recent, on master i think Jul 27 21:44:10 (hopefully) that shouldn't matter Jul 27 21:44:19 are you saying it does? Jul 27 21:44:53 er, how the rule works/wher it gets installed Jul 27 21:45:00 it was in krogoth iirc Jul 27 21:45:03 (eudev) Jul 27 21:45:55 Xz: look at meta/recipes-core/udev/udev-extraconf* Jul 27 21:46:07 that's the daemon that runs on the board: /lib/systemd/systemd-udevd Jul 27 21:47:36 looks like udev-extraconf should not care which Jul 27 22:12:20 In case people missed it, I am in fact still planning to do some work on pseudo, and I have a notion of how to fix the xattr-fix-related performance regression. And joshuagl independantly invented roughly the same fix, and it appears to work, so I am encouraged. Jul 27 22:12:58 Also I have spotted a more fundamental design flaw introduced some revisions back which is why some failure modes have produced corrupted permissions without clear error diagnostics, and I have a plan for fixing it. Jul 27 22:30:53 seebs++ for having a plan Jul 28 00:32:46 seebs: that sounds like it's all fucked up. Jul 28 00:54:56 morning all Jul 28 00:56:58 Can anyone advise whether it's possible to get more debug out of devtool? Specifically, I am trying to find out why the devtool modify, build, deploy-target process always deploys the same binary Jul 28 00:57:33 (in my setup) Jul 28 01:35:37 pwebster: possibly not, but the issue would be in the recipe or the build process it calls - since devtool deploy-target is only installing what gets installed by do_install Jul 28 01:35:53 * bluelightning is the primary author of devtool Jul 28 01:37:24 first thing to check would be to look under image/ in the work directory for the recipe, just to check if that's the unmodified version... then work back from there - you could look at temp/log.do_install in the workdir as well Jul 28 01:47:15 @bluelightning: Thank-you for the response. Jul 28 01:48:40 no worries Jul 28 01:50:15 As far as I can tell, there are 2 different targets where my binary is being installed based on whether I'm using devtool or bitbake to build the recipe Jul 28 01:51:04 I'm building for the raspberrypi using the meta-raspberrypi layer. Jul 28 01:53:01 The one under tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/ seems to be the result of devtool build Jul 28 01:53:40 and the other? Jul 28 01:53:51 there shouldn't be any separation Jul 28 01:54:54 I've just discovered that the one deployed in the rootfs for my image target is updated after I did the devtool modify and edited code, then did bitbake image Jul 28 01:55:46 That might get me by for now, but I expected the process was to use devtool to make changes and test until I was ready to create a source patch Jul 28 01:56:08 the latter is expected to work, so something unusual is going on Jul 28 01:58:37 The devtool deploy seems to use a different work location than the bitbake image Jul 28 01:58:59 the bb outputs to tmp/work/raspberrypi-poky-linux-gnueabi Jul 28 01:59:34 not the arm1176jzfshf-vfp-poky-linux-gnueabi one. Is that significant? Jul 28 02:00:55 it could be yes Jul 28 02:01:14 what do you get if you run: bitbake -e recipe | grep ^WORKDIR= Jul 28 02:03:58 WORKDIR="/home/pwebster/Work/Yocto/builds/pi1/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi//" Jul 28 02:06:47 I'll check how my image is doing its builds... Jul 28 02:07:11 ok, so at least if you built the image now I can't imagine how it would be pulling from any other location Jul 28 02:24:32 @bluelightning: thanks for the help. The "different" binaries in the rootfs vs the "recipe/image" was a red herring. The rootfs one was significantly smaller, I think it's probably being stripped as part of its install. I need to investigate some more, but at least I have a better idea now where to look. Jul 28 02:25:17 pwebster: ok, please do let me know if you figure it out and/or need any help Jul 28 02:28:42 Thanks. I'm very new to Yocto and it's processes, so it's probably an understanding/expectation issue. Having said that, if I can provide even just some feedback for documentation improvements to help new users, I will. Jul 28 02:28:54 that would be much appreciated :) **** ENDING LOGGING AT Thu Jul 28 02:59:58 2016