**** BEGIN LOGGING AT Fri Sep 11 02:59:58 2015 Sep 11 03:02:41 it'll build more than the kernel, to satisfy dependencies only Sep 11 03:03:10 e.g. just to fetch and unpack it, certain host tools are needed, of versions we know are good, not relying on them all on teh build machine Sep 11 03:09:08 kergoth, What is the correct way to 'clean' an entire recipe (I want it to delete the entire tmp/work/foo directory)? Sep 11 03:09:47 kergoth, I tried `bitbake -c clean foo` but when I then tried `bitbake -c build foo` it gave me errors that I didn't get the first time around. Sep 11 03:10:06 So I think somehow the -c clean screwed up the target. Sep 11 03:17:14 so now I have no build failures left with clang on x86_64 and aarch64 qemu Sep 11 03:17:19 yay Sep 11 03:18:02 not everything is yet compiled with clang there are some packages approx 30 which still use gcc but thats OK Sep 11 03:18:35 https://github.com/kraj/meta-clang/tree/master/recipes-excluded/nonclangable Sep 11 03:37:16 Lewoco_: clean is the correct task. Sep 11 07:15:40 good morning Sep 11 07:19:14 hi there, morning! i just learned about recipes http://recipes.yoctoproject.org/... does anyone know how it gets the 'uptsream' version? some are missing, and was wondering how to fix some of the missing ones. Sep 11 07:24:11 ndec: the upstream tracking include files in meta/conf/distro/include Sep 11 07:24:22 (if it can't infer it from the SRC_URI) Sep 11 07:26:43 rburton: hmm. which file in distro/include would give such hints? i am not seeing anything there? Sep 11 07:27:12 in fact i'd like to understand why 'mesa' is 'unknown' Sep 11 07:27:24 ndec: using master? in all releases its in meta-yocto Sep 11 07:27:41 oh, meta-yocto.. Sep 11 07:30:02 rburton: and is the tracking tool available anywhere? Sep 11 07:31:10 ndec: enable the distrodata class and use poky distro if you're not on master, then bitbake [recipe] -c checkpkg Sep 11 07:31:25 that's essentially the backend logic Sep 11 07:31:37 ok, thanks! Sep 11 07:31:41 in master its all in core now Sep 11 07:57:10 rburton: hehe.. somebody had some fun with regex there... Sep 11 08:02:43 ndec: hours of fun with regex! Sep 11 08:03:04 yeah.. i am not sure if i really want to fix the mesa one ;-) Sep 11 11:39:53 hi.. i built for qemuarm64 but when calling runqemu /path/to/Image.bin /path/to/rootfs.ext3 the last line i see is "VNC server running on.." -- kernel does not boot?? Sep 11 14:32:32 morning Sep 11 15:16:21 Hi, what can be the reason that a symlink to library is not copied to the image? Sep 11 15:27:06 first, files aren't copied directly to images at all, binary packages are installed there. second, symlinks *are* installed just fine Sep 11 15:27:20 if you want the symlink .so for a shared library, that isn't needed to run binaries, only to do development. Sep 11 15:27:25 hence they're in the -dev packages Sep 11 15:28:00 i.e. libfoo.so, libfoo.so.1, libfoo.so.1.2.3 -- the first of those is only used in development, not to run binaries that link against it. the binaries reference libfoo.so.1, which is the library's SONAME Sep 11 15:29:16 hmm, told wic to create this rootfs with a size of just under 4G, and the resulting .wic is 5.6G. the only other partition is 64M. Sep 11 15:29:26 that's not what i would expect wic to be doing Sep 11 15:29:37 abelloni: run into this before? Sep 11 15:30:58 * pidge is wondering why the rootfs manifests seem to randomly have the wrong umasks. Anyone have a build older then 0802 that can check to see if it has the wrong permissions? Sep 11 15:33:10 kergoth: did you use any alignment option ? Sep 11 15:34:39 pidge, conssitn perms or are they varying? Sep 11 15:34:51 fray: varying Sep 11 15:35:36 abelloni: looks like the one i copied was --align 4. that doesn't seem like it'd result in going from 4 gigs to 5.2, unless i'm missing something.. i expected to have to adjust for the partition alignment, but that doesn't seem like it'd result in a jump that large. hmm Sep 11 15:35:54 https://bugzilla.yoctoproject.org/show_bug.cgi?id=8282 Sep 11 15:35:55 Bug 8282: major, Undecided, 2.0, ross.burton, ACCEPTED , Manifest files inaccesible on autobuilder (403: Forbidden) Sep 11 15:35:58 * kergoth also noticed that changing IMAGE_CMD_wic, or the wks file, doesn't cause do_rootfs to rerun, not good Sep 11 15:36:28 kergoth: yeah, it is just that align is in k by default, I wanted to makee sure it is not too large Sep 11 15:36:42 * kergoth nods Sep 11 15:36:54 I'd say that you have to run with debug enabled Sep 11 15:37:06 https://gist.github.com/kergoth/ef9f745a2e602cc96b99 is the exact one i'm testing Sep 11 15:37:08 ah, good idea Sep 11 15:40:30 * kergoth does that Sep 11 16:01:58 Does anyone know the state of devtool in master, does it yet support updating the SDK? Sep 11 16:05:15 have you thought about actually looking? Sep 11 16:14:24 Well it's not documented anywhere so I am asking here if anyone knows if it works or not. Sep 11 16:15:02 yes, i know, you've been doing that on a regular basis. you're asking what's been committed, checking what's been committed is trivial Sep 11 16:15:55 pardon me? I've been doing what on a regular basis? Sep 11 16:17:29 asking about this on this channel Sep 11 16:17:40 regardless, yes, afaict it was merged 4 days ago, see http://cgit.openembedded.org/openembedded-core/commit/?id=32cbd4c57fc8ca097a18929fc404c07322ef36dd Sep 11 16:17:57 * kergoth double checks Sep 11 16:19:22 I asked about it once yesterday and once today, if this bothers you I don't know what to say. Sep 11 16:19:57 but thanks for the link to the commit. Sep 11 16:20:06 I guess I just don't see why you wouldn't just go look at the commits and see if it was merged Sep 11 16:20:14 * kergoth shrugs Sep 11 16:20:28 it's a web page, not hard to find Sep 11 16:21:41 because by asking people maybe someone has tried it and it doesn't work yet and it can save some time, why does anyone ask anything here? Sep 11 16:27:37 the point is, you're valuing everyone else's time more than your own, by not bothering to do due diligence on your own Sep 11 16:34:36 I didn't ask you to look it up I asked if anyone knew, anyways just ignore questions if they bother you so much. Sep 11 16:44:44 Debug: Requested partition size for /: 2031616 Sep 11 16:44:44 Debug: Requested blocks 2031616, current_blocks 165404 Sep 11 16:44:44 Debug: Added 1866212 extra blocks to / to get to 2641100 total blocks Sep 11 16:44:46 hmmm Sep 11 16:45:26 I'm not seeing the logic there, it takes a 2 gig partition with 165 megs used and bumps it to 2.6 gigs for no apparent reason i can see Sep 11 16:49:23 kergoth: that is the overhead_factor Sep 11 16:49:40 1.3 I think for ext2/3/4 Sep 11 16:50:18 you can try --overhead-factor=1 Sep 11 16:54:07 huh, i knew it had overhead, but that seems high. i guess in this case since i'm leaving a bunch of empty space anyway, there's no need to automatically add more Sep 11 16:54:10 thanks, that helps Sep 11 17:13:31 Anyone know what the best bet is for the partition alignment on sd? a few resources i've found indicate that 4M is best (allocation group size) for sdhc Sep 11 17:13:42 guess i could do some performance testing Sep 11 17:42:37 kergoth, I think you need to line up with erase blocks Sep 11 18:03:43 there is a way to get something like 'VIRTUAL-RUNTIME_foo == foo then CORE_IMAGE_EXTRA_INSTALL += "foo"' Sep 11 18:06:53 aj_c: CORE_IMAGE_EXTRA_INSTALL += "${VIRTUAL-RUNTIME_foo}" Sep 11 18:06:55 done Sep 11 18:07:14 VIRTUAL-RUNTIME isn't special, it's just a variable, a convention Sep 11 18:07:59 kergoth: 4k is probably fine Sep 11 18:08:48 kergoth: you are correct actually my statement was wrong Sep 11 18:08:54 'VIRTUAL-RUNTIME_foo == "x" then CORE_IMAGE_EXTRA_INSTALL += "a b c" ' Sep 11 18:09:19 it should be more like this Sep 11 18:10:58 kergoth: you probably want to use https://git.linaro.org/people/arnd.bergmann/flashbench.git Sep 11 18:12:29 aj_c: CORE_IMAGE_EXTRA_INSTALL += "${@'a b c' if '${VIRTUAL-RUNTIME_foo}' == 'x' else ''}" Sep 11 18:12:32 inline python Sep 11 19:49:24 hi, how do i get my intel edison to recognize usb devices? Sep 11 19:49:43 lsusb Sep 11 19:49:58 should show you what it sees Sep 11 19:50:45 when i plug in my hub an do lsusb i see "Linux Foundation 3.0 root hub" and ".. "2.0 root hub" Sep 11 19:50:53 but the devices connected dont show up Sep 11 19:51:16 make it 1 connected device. Not devices. Sep 11 19:51:36 baby steps. Sep 11 19:51:44 o ysi did hat too Sep 11 19:51:48 and reboot with only 1 device connected. Sep 11 19:52:47 what is your psu like? A good hefty external wall wart? Sep 11 19:53:14 using the console port ffor nw Sep 11 19:53:20 I wouldn't try to run extra usb devices with the only power available is from a usb port. Sep 11 19:53:32 *for now Sep 11 19:53:35 that could be it right there. Sep 11 19:53:51 no, but i had this working before Sep 11 19:54:18 then i somehow blew my edison Sep 11 19:54:19 and what changed? Sep 11 19:54:39 then i bough anothe eisonn Sep 11 19:56:18 brb Sep 11 19:57:55 sorry, network problems Sep 11 19:58:23 so I blew my edison and bought another one Sep 11 19:58:29 installed exactly the same image on it Sep 11 19:58:47 now usb devices are not recognized Sep 11 19:59:00 worked before on the old edison using console port as only power source Sep 11 19:59:50 whose base board? Sparkfun or intel? Sep 11 20:00:03 sparkfun baseboard Sep 11 20:00:18 "bas block" Sep 11 20:00:23 base* Sep 11 20:00:27 right. Sep 11 20:00:38 the one with 2 usb ports on it? Sep 11 20:00:42 yep Sep 11 20:00:44 ok Sep 11 20:01:13 I got a couple of those at home but I can't get to them right now to look and see what mine says. Sep 11 20:01:26 k Sep 11 20:01:46 is there some kernel module i'm missing or something? Sep 11 20:02:19 just a wild guess, but something is different. So maybe upgrade /update the boot image? Sep 11 20:02:33 whose linux u using...yocto? Sep 11 20:02:37 yep Sep 11 20:02:46 Poky (Yocto Project Reference Distro) 1.7.2 edison ttyMFD2 Sep 11 20:03:22 wish I knew yocto better. Sep 11 20:03:44 what u running on edison? Sep 11 20:04:49 I have 4 - and It's been awhile....if I put the edison on an intel board I keep yocto on it. Sep 11 20:05:21 k Sep 11 20:05:27 but if I use sparkfun boards I put debian ...can't remember the exact flavor off the top of my head. Sep 11 20:05:58 I certainly wouldn't hurt to reflash it. Sep 11 20:06:16 have you done opkg update/upgrade? Sep 11 20:06:51 yea i've reflashed a number of times already :P Sep 11 20:08:41 maybe a yocto expert here knows more...me too noob. Love my edisons though. Sep 11 20:17:14 hi folks, thanks a lot for fixing bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=6881 Sep 11 20:17:15 Bug 6881: normal, Medium+, 1.8 M2, richard.purdie, VERIFIED FIXED, git fetcher does not support lightweight tags Sep 11 22:28:44 LocutusOfBorg1: you're welcome :) Sep 12 01:24:02 Hi - So I'm trying to build Yocto with the 4.2 kernel, but trying to use the linux-yocto-dev and yocto-kernel-cache master repositories is giving me an error: WARNING: Failed to fetch URL git://git.yoctoproject.org/linux-yocto-dev.git;name=machine;branch=standard/base;, attempting MIRRORS if available Sep 12 01:24:19 gives that warning, then an error: Fetcher failure: Unable to find revision 59b8c4f5e8ddb9c33c62fff22204fe2b0d8c703e in branch standard/base even from upstream Sep 12 01:24:22 any ideas why? Sep 12 01:26:00 That commit is definitely there: https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-dev/commit/?h=standard/base&id=59b8c4f5e8ddb9c33c62fff22204fe2b0d8c703e Sep 12 01:26:40 also, I know that commit is for the 4.1.6 tag, I was just trying a different commit ID - the one I tried first was: e7c500d82e649173cb36504e93f8ba8061d989e0 **** ENDING LOGGING AT Sat Sep 12 02:59:58 2015