**** BEGIN LOGGING AT Fri Aug 16 02:59:58 2013 Aug 16 03:04:41 brm: not played with that... Aug 16 03:05:45 either it just doesn't support xz decompression or there's a setting somewhere for that... Aug 16 03:06:45 i assume it's supposed to make an image and extract the rootfs then boot it? Aug 16 03:36:38 back again: Anyone know how I use runqemu-extract-sdk with a rootfs.tar.xz file instead of what it expects .... tar.bz2 ? Aug 16 03:40:06 proxy must've hiccuped again... Aug 16 03:51:10 huh? Aug 16 03:51:47 didn't see a part message so i was answering you with useless crap Aug 16 03:51:56 didn't miss anything... Aug 16 03:52:23 so do you have an answer? Aug 16 03:53:32 not really, i was just asking what it was supposed to do Aug 16 03:53:51 as in "make an image and extract the rootfs then boot it?" Aug 16 03:54:02 well it is mean't to produce a rootfs that you can use with qemu Aug 16 03:54:50 then it would need to make an image file with the rootfs on it Aug 16 03:54:50 I have a roots.tar.xv that is decompressed onto an SD card to use on real hardware, that works fine Aug 16 03:55:02 now I want to use the rootfs with quemu Aug 16 03:56:06 the example given shows runquemu-extract-sdk only used with .bz2 images Aug 16 03:57:06 there's a bbclass in the rpi layer that adds sdimg as a build output Aug 16 03:57:27 i am not using a rpi ... beaglebone Aug 16 03:58:06 right, but it should be not-too-difficult to add it to the bb layer Aug 16 03:58:21 just a thought... Aug 16 03:58:43 I have allready run the rootfs.tar.xz image on the target board, so you are saying I need some other rootfs image? Aug 16 03:58:44 is runquemu-extract-sdk a shell script? Aug 16 03:59:00 the tarball is not an image Aug 16 03:59:14 it's a rootfs tarball Aug 16 03:59:31 sorry, did not bben image, Aug 16 04:00:18 I mean't that the tarball is decompresssed onto the SD card .. I couls just as well decomp that on my PC Aug 16 04:00:58 the rpi bbclass creates the image file and extracts the rootfs for you Aug 16 04:01:24 you just dd the image to card and expand it to whatever size you need Aug 16 04:02:37 anyway, if runquemu-extract-sdk is a script of some kind, did you look to see if you can pass it any options? Aug 16 04:02:50 *useful options Aug 16 04:03:43 will do .. cheers Aug 16 04:04:12 or edit it if there's no compression option... Aug 16 04:05:06 will do ... not on that machine at the moment ... will check it out .. thanks Aug 16 07:15:53 hello, is it bug? : mfw_isink requre libgstfsl-0.10 for work, but only gst-fsl-plugin-dev and gst-fsl-plugin-dbg contain it... Aug 16 07:24:33 alex_kag: maybe a lib packaging issue? Aug 16 07:24:49 does it work if you install the -dev package? Aug 16 07:27:52 im waiting building image Aug 16 07:32:06 this describes the packaging guidelines => http://www.embeddedlinux.org.cn/OEManual/recipes_packages.html Aug 16 07:32:27 hopefully it's not too out of date... Aug 16 08:21:52 \ Aug 16 08:22:33 morning zecke, all Aug 16 08:27:24 hi. :) Aug 16 10:05:01 Morning Aug 16 10:42:33 hi, what is the best of handling BB_NUMBER_THREADS to be the accurate number for each PC including CI? Aug 16 10:42:37 way* Aug 16 10:42:51 MAKEFLAGS can be used for PARALLEL_MAKE Aug 16 10:43:15 as the local.conf is pretty much the same otherwise, we just check that in. Aug 16 10:43:41 the only non-portable bit so far is BB_NUMBER_THREADS. Aug 16 10:55:56 bluelightning: hi, is "classes/terminal: fix pseudo exiting when launching devshell" also needed for master or already in Saul's queue? Aug 16 10:58:23 JaMa: 'classes/terminal' is a fix for a problem in dylan only. Aug 16 10:58:38 cf. devshell was broken 2 days ago. Aug 16 11:01:46 ok, I was just surprised that it does apply in master too Aug 16 11:18:37 lpapp, BB_NUMBER_THREADS is likely very dependent on exact machine setup, including disks etc Aug 16 11:18:59 Crofton|work: which is exactly the reason for my question how to solve it. Aug 16 11:19:07 parallel is a standard MAKEFLAGS stuff. Aug 16 11:19:21 I think most people use empircal methodas Aug 16 11:19:35 empirical methods :) Aug 16 11:19:50 like ? Aug 16 11:19:57 guessing :) Aug 16 11:20:19 ?? Aug 16 11:20:40 there is script to benchmark which value works best for your hardware Aug 16 11:20:49 google for bb-matrix Aug 16 11:21:45 you are probably misunderstanding the question. Aug 16 11:21:52 Crofton|work: probably you, too. Aug 16 11:22:01 Crofton|work: I know what to put in there, but I do not know _how_ Aug 16 11:22:33 101378268367730737515 Aug 16 11:22:37 urg Aug 16 11:22:46 https://plus.google.com/101378268367730737515/posts/KLURPQuGyJw ? Aug 16 11:23:22 http://wiki.webos-ports.org/wiki/OE_benchmark Aug 16 11:23:23 it is still irrelevant. Aug 16 11:23:49 what you probably do not understand is the fact, once you put a value in there (No matter what), it will be device specific. Aug 16 11:24:12 and that will not be working across multiple platforms and setups unlike MAKEFLAGS for the parallel stuff. Aug 16 11:24:23 so pretty much, what people will need is the equivalence of MAKEFLAGS for threads. Aug 16 11:26:13 you can run the benchmark on every machine you care about and put right value in variable in /etc/profile or whatever Aug 16 11:26:56 this is one of the reasons site.conf exists Aug 16 11:28:21 bluelightning: except that as I suggested many times, it will not help unless you have an out of the build (i.e. global setting) Aug 16 11:28:40 or even out of repository for that matter. Aug 16 11:29:49 most people have out of the build "setup" repos Aug 16 11:30:52 let me repeat: _out of the repository_ Aug 16 11:32:32 there are just more and more global stuff I would like to set up. Aug 16 11:32:53 it is not getting less, just more, and it is scary IMO yocto does not address this. Aug 16 11:36:30 hmm, why is oe-core building gtk-doc? Aug 16 11:36:36 gtk is not really like core, yeah? Aug 16 11:36:42 (especially the doc) Aug 16 11:37:50 is there an option to switch gtk off, or a "more minimal" image than core-image-minimal? Aug 16 11:47:03 hmm, so it is not possible to check out the meta-networking layer separately? :( Aug 16 11:55:35 meta-networking is the only exception where it is possible Aug 16 11:57:19 well, it is just a subdirectory, really. Aug 16 11:57:23 in openembedded Aug 16 11:57:31 it is not any different in there tha others. Aug 16 12:00:41 it is also separate repository on github Aug 16 12:01:18 you can find e-mail about it on oe-devel ML, in last 1-3 weeks Aug 16 12:02:06 can anyone help with this pod2man issue? http://paste.kde.org/~lpapp/p158554ad/ Aug 16 12:02:54 well, that repository is read only. Aug 16 12:03:00 so contribution would not be possible in there. Aug 16 12:09:11 http://lists.openembedded.org/pipermail/openembedded-core/2013-June/080341.html -> seems no one cherry picked it yet ... Aug 16 12:09:49 why not? Aug 16 12:14:25 lpapp: local configuration is not supposed to be put into a repository Aug 16 12:15:07 lpapp: yes, it has been cherry-picked Aug 16 12:15:58 http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=dylan&id=d3c465dc1e6b956e4636d016e06ffcb881c90030 Aug 16 12:16:13 bluelightning: then it is not the right fix. Aug 16 12:16:20 bluelightning: for my issue, that is. Aug 16 12:16:23 so any idea for my issue? Aug 16 12:16:23 that's a different question then Aug 16 12:17:08 which version are you actually using? the 1.4.1 release? Aug 16 12:18:44 master Aug 16 12:20:01 bluelightning: ^ Aug 16 12:21:40 right, I guess I was confused by "poky-dylan-9.0.1" in your paste Aug 16 12:22:07 if you're using master then not sure, sorry Aug 16 12:22:07 oops Aug 16 12:22:14 you might be right ... Aug 16 12:22:26 sorry, you are right. Aug 16 12:22:31 we are using 9.0.1 poky indeed. Aug 16 12:22:33 ok, that sucks. Aug 16 12:22:52 hope there will be a 9.0.2 soon... Aug 16 12:23:20 yep, it's imminent Aug 16 12:23:41 last patchset just got merged, final build should be over the weekend and QA testing will happen next week Aug 16 12:24:35 bluelightning: do you know why gtk stuff is needed for core stubb, even if stub? Aug 16 12:25:05 I suspect because some upstream gtk-doc-using stuff just breaks without gtk-doc, so we have to stub it rather than disabling it Aug 16 12:25:11 but I actually don't know for usre Aug 16 12:25:18 sure Aug 16 12:26:15 bluelightning: http://paste.kde.org/~lpapp/p345c2aca/ Aug 16 12:29:11 bluelightning: https://bugzilla.yoctoproject.org/show_bug.cgi?id=4988 Aug 16 12:29:12 Bug 4988: normal, Medium, Future, kergoth, NEW , QA fatal errors for the external Code Sourcery toolchain. Aug 16 12:29:28 kergoth: any progress on fixing that simple one? ^ Aug 16 12:30:58 bluelightning: is that simple to fix? Aug 16 12:31:51 I don't know if the /lib/libssl.so.1.0.0 is actually needed Aug 16 12:32:04 bluelightning: means? Aug 16 12:32:20 meaning I don't know if it's needed... not sure how to put it any other way Aug 16 12:32:33 if it is, add a spec that picks it up to FILES_ Aug 16 12:33:32 if not, in do_install(_append?) just rm ${D}/lib/libssl.so.* and rmdir /usr/libexec Aug 16 12:33:47 if I create xf86-video-nouveau and xf86-video-ati recipes, should it go into oe-core or meta-oe? Aug 16 12:34:09 bluelightning: which recipe? Aug 16 12:34:29 lpapp: the one it's reporting the issue with, external-sourcery-toolchain.bb Aug 16 12:34:38 bluelightning: so meta-sourcery, right? Aug 16 12:35:02 lpapp: from the path, it looks like that's the one you're building, yes Aug 16 12:35:58 Net147: good question Aug 16 12:36:31 bluelightning: why haven't you used ${libdir} Aug 16 12:37:20 lpapp: ${libdir} could be used sure, depends on whether the installation is using ${libdir} already or just hardcoding /lib Aug 16 12:37:47 bluelightning: I am looking to add it for use with NVIDIA ION and AMD E-350 platforms. as a sideeffect it would also support desktop/laptop ATI/NVIDIA graphics too. Aug 16 12:37:49 bluelightning: rm -r ${D}${libdir}/libssl.so.* ${D}/usr/libexec Aug 16 12:37:52 normally we use ${libdir} because we're fully controlling the build process, here I'm not so sure since this is dealing with precompiled binaries Aug 16 12:37:55 that one? Aug 16 12:38:17 lpapp: looks like it should work yes Aug 16 12:38:44 bluelightning: but how can it work for others? Aug 16 12:38:52 lpapp: others? Aug 16 12:39:23 bluelightning: other people Aug 16 12:39:26 ah you meant this: rm -r ${D}${libdir}/libssl.so* ${D}/usr/libexec Aug 16 12:39:31 note the so*, not so.* Aug 16 12:40:02 since it is just libssl.so Aug 16 12:40:18 lpapp: well yes but arguably if you have deleted the real library then you probably don't want any symlinks to it to be present either if they exist... Aug 16 12:40:28 Net147: searching through recipes it looks like we've added additional drivers in other layers rather than in the core ; there are two in meta-oe (geode and glamo) for example Aug 16 12:40:56 bluelightning: ? Aug 16 12:41:08 ERROR: QA Issue: external-sourcery-toolchain: Files/directories were installed but not shipped /lib/libssl.so.1.0.0 Aug 16 12:41:11 still getting it. Aug 16 12:41:15 libdir might not be working then ... Aug 16 12:41:36 ah right, of course. ${libdir} is /usr/lib not /lib Aug 16 12:41:47 ./tmp/sysroots/beagleboard/usr/include/eglibc-locale-internal-armv7a-vfp-neon-poky-linux-gnueabi/lib/libssl.so.1.0.0 Aug 16 12:41:47 ${base_libdir} is what you'd need there Aug 16 12:41:50 ./tmp/sysroots/beagleboard/lib/libssl.so.1.0.0 Aug 16 12:41:51 yes Aug 16 12:42:10 so with dot or without? Aug 16 12:42:39 I'd say without because of what I've said above Aug 16 12:42:52 if there aren't any other files matching of course then the issue is moot Aug 16 12:43:02 WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/lpapp/Projects/poky/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/external-sourcery-toolchain/2009q1-203-r22/packages-split/nscd/usr/sbin/nscd' Aug 16 12:43:59 bluelightning: http://paste.kde.org/~lpapp/p9e792937/ Aug 16 12:46:27 bluelightning: so I should target meta-oe then? Aug 16 12:47:27 Net147: going by the current placement of recipes, it would seem so yes; I don't know if much in the way of deliberate organisation has gone into that though Aug 16 12:48:05 lpapp: I guess add INSANE_SKIP_nscd += "ldflags" Aug 16 12:48:35 bluelightning: I would like to solve it, not work around. Aug 16 12:48:36 bluelightning: well if oe-core is to only have graphics driver recipes for only the hardware platforms that it is actively tested with, then that makes sense Aug 16 12:49:12 lpapp: I don't think there is any way to properly solve it since that issue has been precompiled into the binaries that that recipe is just packaging Aug 16 12:49:42 bluelightning: gosh Aug 16 12:49:58 bluelightning: you understand it is a suboptimal step for people involved? Aug 16 12:50:48 I want to debug do_populate_sdk function in poky/meta/classes/populate_sdk_base.bbclass, is there any echo/print function I can use there? Aug 16 12:50:49 lpapp: is that issue present in the modern version of the toolchain? Aug 16 12:51:03 bluelightning: same with that line, too Aug 16 12:51:32 lpapp: I'm not in charge of maintaining meta-sourcery... Aug 16 12:51:37 bluelightning: http://paste.kde.org/~lpapp/p93009aa6/ Aug 16 12:52:04 Krz: depends if it's a shell function or a python function you want to debug within Aug 16 12:52:42 Krz: for python functions, bb.warn() can be useful for quick debug messages; long term you'd add bb.debug() and then just look at the task log or increase verbosity Aug 16 12:52:56 bluelightning: fakeroot python do_populate_sdk() { - looks like python for me:) Aug 16 12:53:13 Krz: for shell tasks you can just echo or use bbwarn/bbdebug/etc. but those messages won't come out to the build terminal, only the logs Aug 16 12:53:35 Krz: right, ok Aug 16 12:55:45 lpapp: odd error, never seen that one before... you might want to have a look at the spec file it has generated Aug 16 12:56:14 bluelightning: which file ? Aug 16 12:57:46 lpapp: there should be a single .spec file in the workdir for the recipe Aug 16 13:00:19 bluelightning: which recipe Aug 16 13:00:54 the one that the error is about... Aug 16 13:01:03 I have no idea what that is ... Aug 16 13:01:36 which recipe is indicated in the error at the end of your paste? Aug 16 13:02:14 no clue. Aug 16 13:03:09 maybe cs Aug 16 13:03:37 cat ./tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/external-sourcery-toolchain/2009q1-203-r22/external-sourcery-toolchain.spec | wgetpaste Aug 16 13:03:41 Your paste can be seen here: http://bpaste.net/show/123550/ Aug 16 13:06:29 lpapp: eww.. look at the lines after %package -n gdbserver Aug 16 13:06:36 I think that's where the problem lies... Aug 16 13:06:51 bluelightning: if you say so ... Aug 16 13:07:35 bluelightning: not sure what to do with it ... Aug 16 13:08:40 which task in linux-yocto is responsible for integrating the bsp kernel config fragments into .config? Aug 16 13:09:38 so I can force it to generate the .config again with new changes in bsp kernel config Aug 16 13:12:20 Net147: not sure, perhaps do_kernel_configme ? I'm not an expert in that area at all Aug 16 13:13:26 bluelightning: that's what I tried first, it didn't work Aug 16 13:13:35 ah ok, not sure then Aug 16 13:14:02 any changes ought to be picked up automatically I would have thought... Aug 16 13:14:13 bluelightning: only if recipe changes Aug 16 13:14:19 zeddii is probably the best person to help debug any issues Aug 16 13:14:32 (with linux-yocto) Aug 16 13:16:04 it seems like it is done in do_patch Aug 16 13:16:49 do_unpack -> kernel_checkout -> do_patch -> .. Aug 16 13:17:28 do_patch builds the meta-series, which is where the fragments are detected. do_configme processes the meta-series and finalizes the config. Aug 16 13:18:05 zeddii: so bitbake -C patch virtual/kernel? Aug 16 13:18:18 that won't config the kernel, no. Aug 16 13:18:22 it's the configme Aug 16 13:18:53 -C configme? Aug 16 13:19:10 bitbake -c kernel_configme linux-yocto Aug 16 13:19:43 zeddii: testing... Aug 16 13:20:13 bluelightning: got a clue? Aug 16 13:20:31 lpapp: not on this issue, no Aug 16 13:20:54 bluelightning: too bad ... Aug 16 13:21:06 zeddii: the .config file still not correct Aug 16 13:21:48 you really aren't giving me anything to go on Aug 16 13:22:01 I assure you that it works, so there's something you are doing that I don't know about. Aug 16 13:22:39 lpapp: looks like it tries to auto-determine the correct version and fails because the gdb binary can't be run (missing ncurses?) Aug 16 13:23:04 zeddii: okay, I just need to wait for build to complete I think Aug 16 13:23:20 zeddii: looks correct now Aug 16 13:23:29 configme runs before do_configure Aug 16 13:23:33 lpapp: maybe a DEPENDS on ncurses-native would help? Aug 16 13:23:41 so depending on what you were looking for, that might have been the problem. Aug 16 13:23:43 lpapp: (a complete guess) Aug 16 13:23:50 bluelightning: for a toolchain? :O Aug 16 13:24:35 lpapp: clearly the gdb binary has a shared library dependency on it... Aug 16 13:24:40 DEPENDS += "${@base_conditional('PREFERRED_PROVIDER_linux-libc-headers', PN, '', 'linux-libc-headers', d)}" Aug 16 13:24:49 how to extend this line ? Aug 16 13:25:23 just add stuff before the closing quote, or put another line underneath it doing DEPENDS += "whatever-value-you-want" Aug 16 13:27:01 bluelightning: do I need to clean up before retry Aug 16 13:27:45 (same error) Aug 16 13:27:49 even with -c cleanall Aug 16 13:28:20 well, I don't know Aug 16 13:28:37 clearly it needs ncurses and can't find it Aug 16 13:28:57 well, adding to DEPENDS does not help. Aug 16 13:29:02 and rerunning bitbake stunnel Aug 16 13:29:23 zeddii: what I am doing is I have a kernel already built. then I enable a new kernel option in meta-custom-bsp/recipes-kernel/linux/files/custom.cfg and do bitbake -C kernel_configme virtual/kernel Aug 16 13:29:26 I did say that was a guess Aug 16 13:29:57 In my Yocto build I have the directory with whole bunch of broken symlinks: /dev/shm/kmsywula/tmp/work/i586-poky-linux-uclibc/meta-toolchain/1.0-r7/sdk/image/opt/my-tiny/1.4.1/sysroots/i586-poky-linux-uclibc/usr/src/debug/uclibc/0.9.33+gitAUTOINC+946799cd0ce0c6c803c9cb173a84f4d607bde350-r8.4/git/include/bits Aug 16 13:30:09 do you know who is responsible for building this ? Aug 16 13:30:13 Net147, right, so in that case, you need to prop them back to WORKDIR and that's the patch phase, it collects up the bits and pieces. Aug 16 13:30:44 zeddii: so I was right I need to do -C patch instead Aug 16 13:30:50 yup. Aug 16 13:33:12 perhaps the build system can be improved to detect changes in the .cfg even if there are no changes in the recipes? Aug 16 13:33:35 I have something open for that in 1.5, so looking into it! Aug 16 13:33:42 Net147, are you on master ? Aug 16 13:33:45 yes Aug 16 13:33:49 you got the bug report number? Aug 16 13:34:06 I'll track it down. I'm 3 minutes late for a meeting :) Aug 16 13:34:10 4 Aug 16 13:34:11 heh Aug 16 13:34:55 Net147, one other quick question, you had that .cfg file listed in the SRC_URI, right ? Aug 16 13:35:30 if so, that should hit the checksum when you modified it, just a matter of re-running the right phases after that. Aug 16 13:35:59 zeddii: custom.scc has "kconfig hardware custom.cfg" Aug 16 13:36:04 zeddii: and I changed custom.cfg Aug 16 13:36:35 bluelightning: thanks anyway ... Aug 16 13:36:36 :) Aug 16 13:36:48 Net147, ok, that's good too. that's right what I'm looking into. will let you know that bug number. Aug 16 13:37:05 you can drop me an email at bruce.ashfield@windriver.com .. so I don't forget. Aug 16 13:37:11 zeddi: thanks Aug 16 13:38:53 lpapp: if you want to hack around it for the time being you could just hardcode CSL_VER_GDB to some value instead of letting it try to obtain it from the non-working binary Aug 16 13:40:49 bluelightning: plenty of issues around the toolchain. Aug 16 13:41:06 perhaps it will be better to switch to the internal within a few years. Aug 16 13:41:51 the internal toolchain is certainly what we use to test the system and how many people use it Aug 16 13:42:19 the only problem is that it does not make any sense to rebuilt it all the time ... Aug 16 13:42:24 rebuild* Aug 16 13:42:35 it would slow the CI down significantly. Aug 16 13:43:27 that;s what sstate is for :) Aug 16 13:46:41 indeed Aug 16 14:03:04 bluelightning: ? Aug 16 14:03:14 bluelightning: you do not wanna check in sstates into the repository, I guess. Aug 16 14:03:29 you don't, no Aug 16 14:03:41 bluelightning: then how would that solve the CI's issue? Aug 16 14:04:34 have a shared sstate cache mirror that each builder points to using SSTATE_MIRRORS Aug 16 14:08:09 bluelightning: are you saying a sstate cache does not ever change? Aug 16 14:08:22 what if I add new packages, remove existing, modify dependencies, etc. Aug 16 14:08:27 lpapp: if the inputs don't change Aug 16 14:08:29 the states are changing, and hence the jobs ... Aug 16 14:09:01 yes, and therefore the signature will change and the task will be re-run instead of having its output extracted from sstate Aug 16 14:23:20 bluelightning: but that would mean we need to be careful to keep sync with the server. Aug 16 14:23:24 and that is an additional hassle. Aug 16 14:23:29 and a potential places for errors. Aug 16 14:45:10 lpapp: not sure how you get potential places for errors Aug 16 14:46:08 bluelightning: forget sync? Aug 16 14:46:27 then it would just rebuild instead of restoring from sstate and give you the same result... Aug 16 14:46:35 it's a build time saving mechanism, nothing more Aug 16 14:47:02 it is critical on CI ... Aug 16 14:47:07 whether it is one hour or two ... Aug 16 14:48:03 it is not a "subtle feature" Aug 16 14:48:09 IOW, it is a blocker. Aug 16 14:48:14 using shared state you can reduce the build time significantly for the items that haven't changed since the last build Aug 16 14:48:28 what is a blocker? Aug 16 14:48:48 building slowly. Aug 16 14:49:02 since that slows down the merges etc etc etc... Aug 16 14:50:20 yes, so try using shared state to resolve that... Aug 16 14:50:31 but it can get error prone easily ... Aug 16 14:50:40 unlike an external toolchain installed once... Aug 16 14:56:32 no, I don't think it can Aug 16 15:01:57 bluelightning: what if you forget to sync up? Aug 16 15:02:16 I just answered that question Aug 16 15:02:33 can you use sstate when changing from eglibc to uclibc? Aug 16 15:02:58 bluelightning: you need to update. Aug 16 15:03:04 bluelightning: which means you can forget it Aug 16 15:03:14 bluelightning: which means the slow might get an uncool regression. Aug 16 15:03:20 slow = build* Aug 16 15:03:26 lpapp: no, it won't Aug 16 15:04:01 Krz: in theory yes but I don't know if anyone has tested that Aug 16 15:04:06 bluelightning: sure, it will. Aug 16 15:04:17 or I do not understand the magic. Aug 16 15:04:58 lpapp: all of the inputs go into a checksum, which is used to fetch the shared state package (tarball). If one of the inputs have changed, the checksum will be different -> the old output will not be re-used Aug 16 15:05:23 bluelightning: so there will be no speed up ... Aug 16 15:05:26 so it will slow down ... Aug 16 15:05:30 no Aug 16 15:05:49 it's unlikely you will always be changing everything at once Aug 16 15:06:04 thus, there will be large numbers of tasks whose inputs are unchanged Aug 16 15:06:06 bluelightning: sure, we will. Aug 16 15:06:11 i.e. yocto update Aug 16 15:06:27 all of those that do not change can be extracted from sstate instead of being built Aug 16 15:06:53 pretty much everything changes with a yocto update ... Aug 16 15:27:50 bluelightning: why are bitbake recipes so complicated many times? Aug 16 15:28:08 I mean, some packages on other distributions are simpler in the sense that config, make, install, etc are the default. Aug 16 15:28:11 epic way around autorev at parse time :) Aug 16 15:28:12 https://github.com/Xilinx/meta-xilinx/blob/master/recipes-kernel/linux/linux-xlnx-dev.bb Aug 16 15:28:22 here, it seems the environment and those steps require quite a bit of customization. Aug 16 15:28:35 Crofton|work: you work for Xilinx ? Aug 16 15:28:41 me? no Aug 16 15:28:47 just a consumer Aug 16 15:28:56 ok Aug 16 15:29:07 lpapp: I guess one reason would be that many of those other distros don't cross-compile Aug 16 15:29:39 bluelightning: cannot that be avoided by putting the boilerplate into a central place ? Aug 16 15:29:54 lpapp: we do that, see meta/classes/* Aug 16 15:30:01 Crofton|work, same trick we play with linux-yocto-dev :P So I approve Aug 16 15:30:34 heh Aug 16 15:30:40 bluelightning: then why still so much customization in most of the recipes ? Aug 16 15:30:55 I'm not certain I'd encourage that in a customer facing bsp :) Aug 16 15:31:23 gah, they are using PR in a kernel recipe Aug 16 15:31:25 Finding whole bunch of broken symlinks on poky-dylan9.0.1: /build/kmsywula/yocto_build/tmp/work/i586-poky-linux-uclibc/uclibc find -L -type l Aug 16 15:31:25 lpapp: we'd have to get more specific Aug 16 15:31:41 it does not look valid at all, and that's 100% upstreamed code Aug 16 15:31:45 lpapp: in order to answer the question Aug 16 15:32:03 I need to send them a patch to add machineoverrides to each SRC_URI line Aug 16 15:32:03 bluelightning: ok, I will become specific at home during the weekend if you wish. Aug 16 15:32:16 khem: can you help Krz with uclib stuff ^? Aug 16 15:32:47 and it is a bitch addding a driver in your custom hardware linux-yocto recipe Aug 16 15:36:56 would SRC_URI_${MACHINE} += "foo" work? Aug 16 15:37:14 or is this crossing the streams :) Aug 16 15:37:53 broken symlinks were not found yet is because populate_sdk/tar_sdk tars whole package without --hard-dereference; I believe that should be default flag Aug 16 15:51:01 bluelightning: i'll take a closer look at that tslib patch sometime today, sorry for the delay Aug 16 15:54:33 ups, i meant tar -h (the other is for hardlinks) Aug 16 15:55:22 kergoth: no worries... I think we may be safe without it, but of course you would be able to tell for sure Aug 16 15:56:21 that's not necessarily true, i'm admittedly pretty rusty at this, i need to think about handing off tslib maintainance to someone with hardware that has an actual touchscreen :) Aug 16 15:59:02 ah, didn't see your latest reply, if it's working on mips, i'm in favor of just pushing the update and dealing with any potential problems if and when they appear Aug 16 15:59:07 heh Aug 16 16:01:59 zeddii, have you dealt with builds that contain multiple bsp's each using a .bbappend to modify the kernel? Aug 16 16:02:31 yup. plenty. lots of stacked layers around here. Aug 16 16:04:20 so I would be correct in assuming that you need to use a machien override in your SRC_URI's that you append? Aug 16 16:04:35 since all the linux-yocto bbappnds will stack in some order Aug 16 16:05:38 yah, if they are changing things that are really board specific. we control the order, and of course drive most changes into a git tree (versus patches), but they should be tagged machine specific. Aug 16 16:06:11 yeah, there are loads of patches against 3.8 Aug 16 16:06:15 and there is the epic line Aug 16 16:06:29 https://github.com/Xilinx/meta-xilinx/blob/master/recipes-kernel/linux/linux-yocto_3.8.bbappend#L10 Aug 16 16:06:55 Hi All: I'm trying to bitbake my recipe and it keeps puking. I get "Recipe file does not have license file information (LIC_FILES_CHKSUM)", I have "LIC_FILES_CHKSUM = 'file://COPYING;md5=bb3ca60759f3202f1ae42e3519cd06bc"' in my recipe Aug 16 16:06:57 which mandates everyone have the ${KMACHINE}-standard.scc file Aug 16 16:07:51 its a GPLv3 license and i generated the md5 on my machine from the COPYING file in the source tarball, which is local to my machine. Aug 16 16:07:56 cfo215_: can you paste both your recipe and the full error text to pastebin or the like Aug 16 16:08:11 sgw_: will do. w1 Aug 16 16:08:14 cfo215_: or recipe snipet Aug 16 16:09:38 Crofton|work, yah, they can have those patches, they just need to make that ${KMACHINE}-standard.scc be something you can override, or they should put their machine name in there and you inherit it .. then add, how ever you like. Aug 16 16:09:57 yeah Aug 16 16:10:20 I added my own bbappend, and it blew up because I do not use that name Aug 16 16:10:57 the only way I can see making that line work is add a SRC_URI line for each machine they have in the layer Aug 16 16:13:42 sgw_:http://pastebin.com/jFBrLvND Aug 16 16:17:39 cfo215_: and if you cut and paste the "invalid file" the COPYING file is really there at that path? Aug 16 16:24:02 sgw_: no the file isn't there... I don't quite understand how it all works (yet). I thought the bb system would extract the tarball to inspect the COPYING file. Aug 16 16:24:36 COPYING is just the standard GPLv3 boilerplate text. Aug 16 16:25:55 cfo215_: it will, it's just a matter of ensuring S points to the right directory and then LIC_FILES_CHKSUM should match up with that (since that will be the current working dir when that is checked) Aug 16 16:26:26 cfo215_: looking at what you're doing in do_install I wonder if S should be set to "${WORKDIR}/phidget21" Aug 16 16:28:12 bluelightning: i'll comment it out and see what happens. Aug 16 16:30:27 cfo215_: I'd suggest naming your recipe as libphidget_2.1.8.20130723.bb and then you shouldn't need to set S, and your package version will be correct as well Aug 16 16:30:38 cfo215_: when you are in ${S}, are there files there at all? if you cd .. from ${S} what directories exist? or what does the tarball contain for it's root Aug 16 16:30:42 cfo215_: (since it defaults to being derived from the filename) Aug 16 16:32:33 we should really change it so ${S} doesn't get autocreated if it doesn't exist, but thats the default behavior of 'dirs'.. Aug 16 16:32:37 heh Aug 16 16:34:53 bluelightning: same results. I do suspect something though... testing again. Aug 16 16:35:19 kergoth: yes, I agree Aug 16 16:39:14 kergoth: If I wanted to submit some patches to meta-sourcery, would I use the yocto contrib tree, or some other tree, or just send you patches? Aug 16 16:39:29 bluelightning: I tried remvoving the PR variable, but got some error, just with r0 instead of r1 in the file path. Aug 16 16:40:01 cfo215_: right, changing PR won't help here Aug 16 16:41:46 cfo215_: could the files be in phigets/phidget21/COPYING? It would be helpful to know the top directory of your tarball. Aug 16 16:42:01 seebs: its easiest to open pull requests against the github repository, thats where we're doing our main development, and mirroring to the yocto repository. https://github.com/MentorEmbedded/meta-sourcery Aug 16 16:42:33 Okay. Aug 16 16:43:13 What toolchains would you normally test that against? I know my patches work with ours, but they're not quite the standard/default. Aug 16 16:43:59 sgw_:bluelightning: /media/toshiba-usb3/work/test/setup-scripts/sources/meta-epic/recipes-epic/phidgets/files/libphidget_2.1.8.20130723.tar.gz ALSO: ./configure depends on libusb if that matters. Aug 16 16:45:03