**** BEGIN LOGGING AT Tue Mar 26 02:59:58 2013 Mar 26 03:49:00 hi Mar 26 03:49:48 QA Issue: pkgconfig rdepends on toolchain-dev Mar 26 03:50:21 i'm using my my own toolchain Mar 26 03:51:03 its not only giving for pkgconfig but many other modules Mar 26 03:51:19 and hence do_package_qa fails Mar 26 05:00:18 For a given set of prefix and postfix modifiers, make those packages RRECOMMENDS on the corresponding packages for its RDEPENDS. Mar 26 05:00:58 can anyone help on what the above sentence means? Mar 26 05:17:30 what is the difference b/w RDEPENDS and RRECOMMENDS? Mar 26 06:58:26 gm Mar 26 07:50:10 howdy! can anyone ahre a short overview of how all the recipes in root/meta/recipes-devtools/gcc are interrelated? Mar 26 08:32:17 hi Mar 26 08:51:06 HI Mar 26 08:51:14 When i am using externel toolchain Mar 26 08:51:20 i am getting ERROR: QA Issue: rsync rdepends on external-gf-toolchain-dev Mar 26 08:51:38 ERROR: QA run found fatal errors. Please consider fixing them. Mar 26 08:51:52 ERROR: Function failed: do_package_qa Mar 26 08:52:13 make[1]: *** [rsync] Error 1 Mar 26 08:52:26 Please can any one tell me why its failing Mar 26 08:52:35 this is happening only for some modules Mar 26 08:55:31 hm this again Mar 26 08:55:35 okay Mar 26 08:55:48 you can do bitbake -DDD -g bla Mar 26 08:56:05 and than check the debug output and dependency graph Mar 26 08:56:18 forgot this the firstime you aksed the question Mar 26 08:56:36 and maybee you will find the root of external-gf-toolchain-dev Mar 26 09:06:12 woglinde: mine is webos setup Mar 26 09:06:27 there i am not building with bitbake option its make option Mar 26 09:07:15 in make how to give -DDD option in oe core for openwebos make? Mar 26 09:08:08 sorry no idea Mar 26 09:08:52 is it available in log? that depends graph? Mar 26 09:13:22 DEBUG: rsync: Dependency libpopt.so.0 requires package popt DEBUG: rsync: Dependency libiconv.so.2 requires package external-gf-toolchain-dev DEBUG: rsync: Dependency libgcc_s.so.1 requires package libgcc DEBUG: rsync: Dependency libc.so.6 requires package external-gf-toolchain Mar 26 09:13:45 in log its giving this message and Mar 26 09:13:55 NOTE: DO PACKAGE QA NOTE: Checking Package: rsync-dbg NOTE: Checking Package: rsync-staticdev NOTE: Checking Package: rsync-dev NOTE: Checking Package: rsync-doc NOTE: Checking Package: rsync-locale NOTE: Checking Package: rsync ERROR: QA Issue: rsync rdepends on external-gf-toolchain-dev ERROR: QA run found fatal errors. Please consider fixing them. DEBUG: Python function do_package_qa finished DEBUG: Python function do_package finish Mar 26 09:16:10 can any one help??? Mar 26 09:18:08 bhaskar: I can't. but somehow external-gf-toolchain-dev contains libgcc_s.so.1 which normally should not be part of a -dev package. Mar 26 09:18:21 bhaskar: so is external-gf-toolchain playing with the shlibs? building packages? Mar 26 09:19:47 morning all Mar 26 09:21:01 FILES_${PN} if i add then its making package Mar 26 09:21:15 but its failing in rootfs Mar 26 09:22:14 hi bluelightning Mar 26 09:43:20 good morning Mar 26 09:45:28 good morning Mar 26 09:50:15 root Mar 26 09:50:19 meeh Mar 26 09:50:43 * erbo gets coffee Mar 26 11:17:56 hekko Mar 26 11:35:48 morning Mar 26 11:37:10 hi xora Mar 26 11:37:12 hi xor5 Mar 26 11:37:14 uos Mar 26 12:29:52 can I mask specific versions of a recipe? or force a recipe version? Mar 26 12:30:27 by default, directfb 1.6 is built, but the hardware acceleration drivers for my platform are built for directfb 1.4 Mar 26 12:30:41 so, some way to limit the directfb version in the machine config would be great Mar 26 12:31:05 PREFERRED_VERSION_directfb Mar 26 12:31:25 but that's not machine config Mar 26 12:33:25 cant I just stick this in the machine.conf? Mar 26 12:36:56 that will work, but break multimachine builds Mar 26 12:37:52 multimachine builds? you mean, one recipe that builds for multiple targets at the same time? Mar 26 12:37:58 s/targets/machines/ Mar 26 12:40:36 no, one distro which builds multiple machines in the same feed Mar 26 12:41:09 but that would mean that other things are disallowed as well? like PREFERRED_PROVIDER_virtual/xserver? Mar 26 12:42:07 why does the preferred version thing break multimachine builds but something like PREFERRED_PROVIDER_virtual/kernel = "customkernel" doesnt? Mar 26 12:43:17 because kernel is MACHINE_ARCH Mar 26 12:44:04 everything else should be distro decision (DISTRO select common denominator of all supported MACHINEs) Mar 26 12:48:17 hm. Mar 26 12:48:26 well sometimes it is machine dependent Mar 26 12:49:01 one example is virtual/libgles2 . some platforms have hardware accelerated OpenGL ES 2 support, and you must override the preferred version then Mar 26 12:49:07 err, the preferred provider Mar 26 12:49:14 otherwise it installs mesa Mar 26 12:49:31 so how could this be done in a proper way? Mar 26 12:50:02 there some packaging changes in mesa to allow to build both Mar 26 12:50:25 and then install machine specific binary vendor blob on target Mar 26 12:50:35 dv_: for your builds you can set PREF_VER in conf/site.conf Mar 26 12:50:48 also note that configs in OE core do it like that as well: https://github.com/openembedded/oe-core/blob/master/meta/conf/machine/qemux86.conf Mar 26 12:53:45 JaMa: but not in yocto 1.3 / poky danny, right? Mar 26 12:55:07 yes IIRC after danny was released, but check git log and ML Mar 26 13:02:57 speaking of it, i cannot find the name of the next poky version. the previous one was denzil, the current one is danny, the next one .. ? is there a page with the names? Mar 26 13:18:36 how do I remove a disk from the disk monitor? Mar 26 13:19:05 in the latest bitbake revision I get a few _thousand_ messages informing me that the inode check is unavailable when before I only go one Mar 26 13:20:15 ok no worries, I managed Mar 26 13:29:54 jackmitchell: what was the solution Mar 26 13:30:54 dv_: in local.conf there is a BB_DISKMON variable, I have my sstate and dl_dir on ext4 and my tmp on btrfs so I removed the lines which referred to ${TMP_DIR} Mar 26 13:31:10 as Inode check doesn't work on btrfs Mar 26 16:49:09 is there a way to clean the work directory easily ? Mar 26 16:49:58 that's what the clean task is for, among other things Mar 26 16:50:01 bitbake -c clean Mar 26 16:50:14 to do it for all the recipes ? Mar 26 16:50:20 bitbake -c clean world ? :) Mar 26 16:50:42 rm -rf tmp Mar 26 16:50:47 :P Mar 26 16:50:52 moin Mar 26 16:50:57 moin? Mar 26 16:52:01 it's a frisian greeting... Mar 26 16:52:18 moin mr_science Mar 26 16:52:40 plus it sounds kinda like morning and is easy to type... Mar 26 16:53:17 technically it's more common as "moin moin" but i think one is enough Mar 26 17:01:10 boy am i glad they got the nand rescue image working... Mar 26 17:01:24 +40GB (yay) Mar 26 17:02:10 doesn't take many builds to suck up your remaining disk space... Mar 26 17:02:34 afournier: two other options FYI - scripts/cleanup-workdir and INHERIT += "rm_work" Mar 26 17:02:56 INHERIT += "rm_work" looks good Mar 26 17:04:50 the reason we don't have it on by default is some people use the working directories to muck about with the source, and having work deleted can be kind of annoying :) Mar 26 17:05:50 historically we've also had many sstate/rm_work interaction bugs Mar 26 17:05:53 not sure if any still remain though Mar 26 17:06:10 indeed... JaMa are you regularly building with rm_work still? Mar 26 17:07:29 I believe a patch went in recently for rm_work to add an exclusion list as well so you can avoid deleting workdirs for recipes you know you're working on Mar 26 17:19:34 bluelightning: yes and now it works even better (removes more) Mar 26 17:20:07 I was using rm_work_old for some time, but now I'm back to rm_work Mar 26 17:20:10 ok, I guess we can assume rm_work can be relied upon in that case :) Mar 26 17:20:17 nice Mar 26 17:20:31 * bluelightning doe not use rm_work, and curses when disk space runs out instead Mar 26 17:21:11 yes some of the interaction bugs were caused by bad metadata (e.g. different do_package checksums for 2 MACHINEs with the same architecture) Mar 26 17:21:19 aha Mar 26 17:21:28 but those are now fixed (at least in recipes I'm building) Mar 26 17:21:29 i like rm_work as a default, since you can always -c clean -c compile anything you need... Mar 26 17:22:16 FWIW: I usually use -c build to temporary disable it (e.g. for only one recipe I want to check in WORKDIR) Mar 26 17:31:39 sstate consumes most diskspace and it would be nice when it could be disabled Mar 26 17:32:15 there are multiple ways to keep sstate cache size under control Mar 26 17:32:32 sstate is designed for people who do more then one build.. since it allows significant re-use in subsequent builds.. Mar 26 17:32:56 kergoth: how? except a manual rm -rf Mar 26 17:34:00 ensc|w: there's a tool in scripts for it, and you can also do what i do, which is periodically wipe sstate archives older than a week by modification time Mar 26 17:34:10 the problem (or advantage) is that everytime you make a change to a recipe or configuration, the checksum can change.. this leads to additional entries in the sstate-cache.. Mar 26 17:34:28 and of course takes additional space.. the advantage is then if you revert your change.. it will simply re-use the old version.. Mar 26 17:34:31 kergoth: yes, I saw it. But using a common sstate dir and wiping it manually with 'rm -rf' is much easier Mar 26 17:34:47 you must be really low on space to sacrifice that much build time Mar 26 17:34:52 i can't remember the last time i manually wiped mine Mar 26 17:35:06 kergoth, I only wipe mine when I move from say 1.2 to 1.3 to 1.4 Mar 26 17:35:13 otherwise I keep it and prune it.. Mar 26 17:35:37 kergoth: sstate costs build time only; I do not see where it would save it Mar 26 17:36:22 it costs virtually no time and it's a HUGE time saver.. Mar 26 17:36:31 do a build, load your sstate-cache.. Mar 26 17:36:39 start a -new- build.. use the same sstate-cache directory.. Mar 26 17:36:43 kergoth: after a 'git pull' which changes packagse.bbclass or so, the whole sstate space is wasted Mar 26 17:36:46 your build just went from > 1 hr to about 5 minutes Mar 26 17:37:14 ensc|w no.. actually a change to package.bbclass will only invalidate one step of the stsate-cache.. there are three steps.. Mar 26 17:37:24 so you don't have to re-unpack,patch,configure,compile and install.. Mar 26 17:37:34 but you do have to redo do_package and do_package*write Mar 26 17:38:44 ensc|w: i'd say it's been at least a few weeks since the last full from scartch build i had to do. 90% of the time the build times are less than half of from scratch Mar 26 17:38:48 for me, anyway Mar 26 17:39:01 it's viscerally *painful* for me to do a from scratch build now Mar 26 17:39:05 * kergoth shrugs Mar 26 17:40:11 ok; for package.bblcass that might be true. But when some more basic class or recipe is changed, the whole sstate gets invalided Mar 26 17:40:44 and such changes happen very often Mar 26 17:40:51 we don't exactly touch base.bbclass every day, and even when yo udo, it entirely depends on what function/task is changed Mar 26 17:41:00 it should be left to the user to decide whether he wants sstate or not Mar 26 17:48:50 if you really don't want sstate-cache.. you can create your own layer and disable it.. Mar 26 17:49:08 just replace tehs sstate class/functions with ones that fail.. Mar 26 17:49:17 the system will skip all of the sstate work and move right on to compilation Mar 26 17:49:47 (sstate.bbclass is what you will want to override) Mar 26 17:50:01 I do not see that I gain anything with sstates; only one of my last 12 qt4 builds seems to speed up by it: http://pastebin.com/raw.php?i=6T8FsiGT Mar 26 17:51:00 sstate doesn't speed up "one package" Mar 26 17:51:05 it speeds up the build of the whole system.. Mar 26 17:51:17 if you are making changes to one package, then you will see no loss of speed nor a performance gain.. Mar 26 17:51:26 if you do multiple distribution builds, you will see huge gains Mar 26 17:51:30 qt4 build is perhaps 60-70% of system build time Mar 26 17:51:45 not in a normal system build.. Mar 26 17:51:56 toolchain is generally the largest contributor Mar 26 17:52:03 (by individual package) Mar 26 17:52:24 toolchain = binutils-native, gcc-cross, eglibc and eglibc-locales) Mar 26 17:53:22 gcc-cross + binutils are perhaps 20 minutes Mar 26 17:53:45 eglibc is 10 minuets Mar 26 17:53:52 I have no complains my full system build with sstate is 19 mins that includes X and stuff Mar 26 17:53:56 image is ~1G Mar 26 17:53:58 if Qt wasn't completely monolithic then sstate could help; AIUI Qt5 moves to a more modular build so this will be possible Mar 26 17:54:16 * khem dont have to deal with QT Mar 26 17:54:43 The big issue with sstate is how brittle it can be, the way it rebuilds not just the modified tasks but everything that deps on those tasks -- in some cases that makes sense, but in a lot it doesn't. that said, it's better to have deterministic builds than to risk potentially not rebuilding something taht needs to be Mar 26 17:55:27 kergoth: any ideas on a practical way to ignore certain changes? Mar 26 17:55:29 one could make an argument in favor of a more 'loose' behavior for daily development while using the current behavior for more important builds, that's what oe-lite allows, iirc Mar 26 17:55:45 not off the top of my head, given how it's implemented.. would need further thought Mar 26 17:55:47 hmm Mar 26 17:56:32 last time we were talking about it I really liked the idea to compare binary output from changed tasks Mar 26 17:56:52 conclusion was that it's not possible/easy with current implementation Mar 26 17:57:10 JaMa: sure, the big question is how do you feed the result back in if the output is the same... Mar 26 17:57:19 but it would be great to stop propagating some change as soon as you find something which isn't really influenced by that Mar 26 17:57:22 It's not actually that hard to do.. but then again -- it'd take longer to do the diff most likely then rebuild the deps in most cases Mar 26 17:57:44 but it would be an interesting add-on to help find changes that don't affect certain recipes (or even all recipes) Mar 26 17:57:45 fray: I guess you're building smaller images then I do :) Mar 26 17:57:46 JaMa: ah, yes, i've wanted that too, checksum not just input but also output, that's a good point Mar 26 17:58:07 JaMa, ha.. I'm currently building 'world' Mar 26 17:58:12 300 GB project directory.. :P Mar 26 17:58:20 hah Mar 26 17:58:21 21958 tasks Mar 26 17:58:22 bluelightning: you have to build it stuff which depends on changed task, but then you can stop propagating it any further Mar 26 17:59:04 25439 tasks in my * 4 MACHINES Mar 26 17:59:07 for propegating changes it could.. Mar 26 17:59:31 for changes that affect every package (do_package for instance) it would still have to just run Mar 26 18:00:08 Like I said, interesting experiment.. but unless teh change is to a key package (like gcc/eglibc) I doubt the diff is quicker then the compile in a lot of cases.. Mar 26 18:00:11 JaMa: we'd likely need something like sstate's inputdirs/outputdirs for *every* task that touches disk, not just current sstate tasks Mar 26 18:00:17 could be fun to play with, indeed Mar 26 18:00:28 and stuff like added dependency to dbus (just for deterministic dependency) which will rebuild 3 webkit-* and qt* even when dbus was built the same before is just sad Mar 26 18:00:31 it seems like a worth R&D exercise Mar 26 18:00:36 * kergoth nods Mar 26 18:01:42 kergoth: and also some nice whitelist for changes not important in outputdirs :/ Mar 26 18:02:05 at one point i had a class that used git to track all changes to workdir and tagged the tasks, was just an experiment :) Mar 26 18:02:23 kergoth: e.g. when something keeps putting timestamp or creates tarball with timestamps in the process then such change is probably still not important for other tasks after it Mar 26 18:02:45 that's a good point Mar 26 18:02:46 how will you filter out stuff like timestamps? Mar 26 18:03:09 ensc|w: that's the complicated part :) Mar 26 18:03:39 not sure if we can come up with some generic way to whitelist at least 80% of such changes :/ Mar 26 18:04:18 I've summarized some ideas about that a while ago on oe-core ML, but don't remember now Mar 26 18:10:30 JaMa, bring it up again.. it is a source of pain Mar 26 18:14:43 might be good to collect thoughts on it on a wiki page or something Mar 26 18:32:33 mmh... providing an empty/trivial sstate.bbclass to avoid sstate does not work :( Mar 26 18:34:00 ensc|w I did it in the past, worked fine.. you just have to stub out the routines Mar 26 18:34:08 make sure they fail... Mar 26 18:34:28 fail? Mar 26 18:34:43 what is "fail"? when they throw an exception ugly backtrace are printed Mar 26 18:34:56 return != 0 Mar 26 18:35:52 sstate_create_package do nothing.. just return Mar 26 18:36:08 sstate_checkhashes -- return != 0 Mar 26 18:36:20 ensc|w: do you want to only disable sstate archive creation? Mar 26 18:36:33 sstate_unpack_packages return Mar 26 18:36:39 ensc|w: there is patch to do exactly that on ML (2y old maybe) Mar 26 18:36:44 that may be all that's needed Mar 26 18:36:57 might also need to stub out sstate_cleanall Mar 26 18:37:14 JaMa: yes; I saw this patch (but did not checked whether it still applies) Mar 26 18:38:04 fray: I defined only sstate_setscene() and sstate_state_fromvars(); there were no other backtraces due to other missing functions yet... Mar 26 18:38:23 ensc|w: you can find it up2date in my oe-core branch :) Mar 26 18:38:25 JaMa: why was this patch not added? Mar 26 18:39:07 creating just another code path which won't be well tested Mar 26 18:39:31 but I don't agree, missing sstate archives in sstate-cache is quite common scenario Mar 26 18:39:44 and not putting them there is not so big change Mar 26 18:40:59 but with OEBasicHash enabled by default, it's not so useful to not create them anymore Mar 26 18:41:02 I still think that sstate is for most people uninteresting; when I want a clean build (e.g. to see what the customer sees) I want a clean build and nothing which uses some random stuff Mar 26 18:41:37 when I got to reproduce a customer issue, I ask for their sstate-cache Mar 26 18:41:50 (for at least the items having issues) Mar 26 18:41:58 * ensc|w asks for the logfiles... Mar 26 18:42:18 logfiles, sstate cache & configuration then environment info Mar 26 18:43:57 sstate files are not very useful in foreign environments (different paths -> different hashes) Mar 26 18:44:01 it isn't random stuff, it's previous build output Mar 26 18:44:03 no, thats wrong Mar 26 18:44:07 paths aren't included in the checksums Mar 26 18:44:11 if you find one, taht's a bug Mar 26 18:44:35 yup Mar 26 18:44:42 same with embedded environment stuff.. Mar 26 18:46:30 yes, it's the opposite of random Mar 26 18:46:55 and the reason everything rebuilds is because it is sensitive to content changes, as you say, it's the opposite of random, if anything it's too specific, not the other way around Mar 26 18:49:25 in most cases it's too strict, in only very few strict it isn't strict enough (and that's bug), last time it was tracking variables in *contains* functions Mar 26 18:49:55 sorry for bold, * was used because we have at least 3 of them with different names Mar 26 18:50:37 s/strict/cases/ huh, /me goes for coffee Mar 26 19:03:08 ok; indeed, paths don't seem to affect sstate output. Nevertheless, the same project on Fedora 18 and Ubuntu 12.04 creates different sstate Mar 26 19:03:30 use the diff tool and figure out why.. it may be a bug Mar 26 19:03:50 (bitbake-diffsigs) Mar 26 19:05:14 ensc|w: for target or native? for native that's the case because binaries built on one distro wont necessarily run on another, due to e.g. glibc version, etc Mar 26 19:05:35 (nativesdk should be the same though) Mar 26 19:05:44 true Mar 26 19:05:56 my guess is that it's the host detection that is triggering the rebuild.. since the host has changed.. Mar 26 19:06:15 BTW one thing I'd like to see for '1.5'.. go away from 'native' packages and only use 'nativesdk' packages.. Mar 26 19:06:33 I see no reason for a difference between native and nativesdk.. other then to rebuild the package.. :P Mar 26 19:07:23 what really bugs me about native is the sysroot 'prefix'. if we deal with relocation issues, we can keep the normal prefixes but just install relative to the sysroot Mar 26 19:07:52 ys Mar 26 19:07:55 'er.. yes Mar 26 19:09:23 bluelightning, still around? Mar 26 19:09:27 Crofton|work: yep Mar 26 19:09:34 heading home soon Mar 26 19:09:46 I am looking at buildhisroy sdk output Mar 26 19:09:52 and not seeing -dev pakages Mar 26 19:09:58 even though I select Mar 26 19:10:10 SDKIMAGE_FEATURES = dev-pkgs dbg-pkgs Mar 26 19:10:46 Crofton|work: is this for meta-toolchain* or -c populate_sdk ? Mar 26 19:10:55 populate_sdk Mar 26 19:11:02 hmm, that should work Mar 26 19:11:13 files in sdk suggests they are there Mar 26 19:11:30 maybe that stuff is happening afterwards Mar 26 19:11:33 curses... Mar 26 19:11:50 ok, no crisis justwanted to ask Mar 26 19:12:06 well, it is a pretty serious bug Mar 26 19:12:16 I see a .debug directory when I search for curses Mar 26 19:12:18 well, serious if you care about the buildhistory output being correct Mar 26 19:12:20 agreed Mar 26 19:12:45 by curses I meant ;) Mar 26 19:12:50 :) Mar 26 19:12:52 I know Mar 26 19:13:28 sorry to point this out right before you go home Mar 26 19:13:45 Crofton|work: no worries, I'm guessing it won't take me long to fix Mar 26 19:13:52 kergoth: both; trace ends at 'Hash for dependent task libtool-native_2.4.2.bb.do_populate_sysroot changed from ee02e42a55c5ec5a53480c0848f38305 to 2fb9ead41e4bccff8990dfe218ab165a' and I do not have a sigdata file for this. Mar 26 19:13:57 Crofton|work: I'll have to take care of it after I get home though Mar 26 19:14:05 no problem Mar 26 19:14:23 it looks like the sdk is ok, jsut can't verify using buildhistory Mar 26 19:16:14 Crofton|work: try changing POPULATE_SDK_POST_TARGET_COMMAND += to POPULATE_SDK_POST_TARGET_COMMAND_append = in buildhistory.bbclass Mar 26 19:17:02 ok Mar 26 19:17:15 I think that should fix it Mar 26 19:17:17 bbl Mar 26 19:18:18 what about the HSOT one? Mar 26 19:54:57 At the company I work for, we all use Windows for development. I want to use linux as the OS in our project. My idea was to use Openembedded to create a sys-root, with all the necessary libraries and headers that our application needs, and the use Cygwin to build a cross-compiler, connected to the sys-root created by Openembedded. This way, we could still stay in windows for all the development. Does this sound like it could work ? Mar 26 19:56:58 yes it can work, but it may be easier and cheaper to buy a commercial solution for this Mar 26 19:57:29 there is no (as far as I know) existing to help you build an SDK with a cygwin based compiler.. Mar 26 19:57:46 if you want information on the commercial stuff I know about /msg me.. Mar 26 19:58:18 building a cross-toolchain in Cygwin is not a problem, I have done this Mar 26 19:58:33 the problem is building all the remaining libraries with dependencies Mar 26 19:59:10 openembedded would fit in perfectly if I could use the sys-root and link it with my cross-compiled gcc Mar 26 20:01:25 you want to export and SDK from oe Mar 26 20:01:44 if you are using the last release or master you can do bitbake -c populate_sdk Mar 26 20:01:57 then install the generated SDK onto your linux machine and simply copy the gneerated sysroot out Mar 26 20:03:41 bitbake -c populate_sdk will generate a development sysroot that matches the image you selected.. this way your application deveopers have access to everything installed into that image Mar 26 20:04:08 fray, cool thanks Mar 26 20:05:07 fray, is that the sysroot in for instance, build/tmp-eglibc/sysroots/qemuarm/ Mar 26 20:05:22 that one may have extra stuff in it.. Mar 26 20:05:31 you want the one from the SDK, it's been sanitized for application development Mar 26 20:06:18 ok Mar 26 21:18:51 fray, where does the sys-root endup ? Mar 26 21:20:27 tmp/edploy/sdk Mar 26 21:33:53 Crofton|work, thanks Mar 26 21:34:39 Crofton|work: any luck? Mar 26 21:34:47 yeah much better Mar 26 21:34:55 but Mar 26 21:35:06 I had to add libudev-dev to the recipe Mar 26 21:35:21 it did not get picked up vie dev-pkgs for some reason Mar 26 21:35:42 -POPULATE_SDK_POST_TARGET_COMMAND += "buildhistory_get_sdk_installed target ; " Mar 26 21:35:42 +POPULATE_SDK_POST_TARGET_COMMAND_append = "buildhistory_get_sdk_installed targe Mar 26 21:35:42 POPULATE_SDK_POST_HOST_COMMAND += "buildhistory_get_sdk_installed host ; " Mar 26 21:35:46 is the diff Mar 26 21:36:00 SDK... Mar 26 21:36:19 I wonder how much work would be to add BAD_RECOMMENDATIONS support into populate_sdk Mar 26 21:36:32 hrw: it should work already... Mar 26 21:36:43 since the same code is used... Mar 26 21:36:52 bluelightning: support for it is in rootfs_ipk only Mar 26 21:37:30 ah right Mar 26 21:37:36 implemented at the wrong level really Mar 26 21:37:50 and I have ugly package for which I need that Mar 26 21:38:29 probably unmergable at current state Mar 26 21:39:05 hrw: patches to implement it welcome ;) Mar 26 21:39:17 bluelightning: I know ;) Mar 26 21:39:51 bluelightning: first I would probably write something to break depchains Mar 26 21:48:55 hrw: in what way? Mar 26 21:49:38 bluelightning: look at my recent elfutils patch Mar 26 21:50:26 bluelightning: elfutils get split to libdw libasm libelf (+ -dev -dbg). then I have libdwarf which depends on elfutils and rdepends on libelf Mar 26 21:50:44 libdwarf-dev conflicts with libdw-dev due to /usr/include/dwarf.h present in both Mar 26 21:51:08 surely that's just plain invalid? Mar 26 21:51:16 but in OE land libdwarf-dev depends on libelf-dev which depends on elfutils-dev which depends on libdw-dev which conflicts with libdwarf-dev Mar 26 21:51:48 bluelightning: only from OE perspective Mar 26 21:52:05 why is it OK for two packages to install the same named header? Mar 26 21:52:16 bluelightning: perfectly valid in Debian based systems Mar 26 21:52:19 recipe for disaster surely if you ever include it... Mar 26 21:52:47 and there are 3rdparty packages which depend on that Mar 26 21:53:12 what, two versions of the same header? Mar 26 21:54:02 no Mar 26 21:54:10 on libdwarf-dev Mar 26 21:55:39 so reiterating the question, why would we not solve this by ensuring that only one dev package contains the header? Mar 26 21:56:12 the problem is that those are different headers Mar 26 21:57:00 I have other (than current) way to solve it (in OE friendly way) but issue was interesting Mar 26 21:57:16 hmm ok Mar 26 21:57:33 Id say throw bricks at people who don't use namespaces to stop this happening! Mar 26 21:57:51 I thought namespaces were a C++ only feature Mar 26 21:57:54 ? Mar 26 21:58:18 bluelightning: a directory is also a namespace dw/badheader.h would work just as well Mar 26 21:58:31 right, in that sense of the word, I agree Mar 26 21:58:54 not sure why linux guys like everything in a 1,000,000,000 entry directory Mar 26 21:59:11 XorA: probably because they can ;D Mar 26 21:59:37 XorA: your acorn electron came with any extras? Mar 26 21:59:54 nice, I have an electron too :) Mar 26 22:00:03 hrw: plus1, Slogger Pegasus 400, 5-1/4 inch drive, view word processor Mar 26 22:00:09 in the cupboard at my parents' house on the other side of the world though Mar 26 22:00:09 hrw: thats my second electron Mar 26 22:00:25 bluelightning: hehe, ever appeciating in value then ;-) Mar 26 22:00:29 has 3.5" floppy and cartridge extensions Mar 26 22:00:48 going to hook the HxC to it, no need for real floppies these days Mar 26 22:01:26 * XorA has 1 or 2 1980s retro machines Mar 26 22:01:27 I haven't plugged it in for probably over 15 years now Mar 26 22:02:00 what no repton playing? thats ciminal ;-) Mar 26 22:02:23 XorA: that slogger interface looks crazy Mar 26 22:02:34 XorA: I never got hooked on games on those machines tbh, we weren't allowed to play them at school :) Mar 26 22:02:54 hrw: its just two eproms, disk controller, some other chip and some 74LS decoding logic Mar 26 22:03:20 XorA: I mean bare pcb sticked in cart slot with cables on top etc Mar 26 22:03:33 hrw: look up the plus3 for crazy :-D Mar 26 22:03:47 XorA: but atari xl/xe karin maxi drive is similar (but with case) Mar 26 22:03:51 XorA: with extra psu? Mar 26 22:04:34 hrw: yeah, extra amps and because the normal psu hole is covered by the drive Mar 26 22:05:36 XorA: if you look at atari xl/xe at Polish atari parties you redefine "crazy" Mar 26 22:06:19 hrw: crazy is the atari 2600 demo scene :-D Mar 26 22:06:30 XorA: 65816 inside, at least 1MB ram, hard drives, extra graphic cards, 'bios' like setups, stereo mods Mar 26 22:06:49 XorA: 2600 is insanely crazy Mar 26 22:07:00 128 bytes of ram and no video ram ;) Mar 26 22:07:32 XorA: at Sillyventure there were demos for 2600 iirc. pure awesomeness (when you know hw limits) Mar 26 22:10:43 hrw: nothing is as cool as a zx81 though :-D Mar 26 22:11:21 XorA: without extensions of course? Mar 26 22:11:42 hrw: it has many fun extensions Mar 26 22:11:57 which makes it less cool Mar 26 22:13:02 I think the AY addons, the MMC drive are pretty cool Mar 26 22:13:27 and 64KB memory pack? Mar 26 22:14:14 anyway I prefer 6502 over z80 Mar 26 22:14:21 bluegh!!!! Mar 26 22:14:36 * XorA likes his registers! Mar 26 22:15:30 when I had z80 programming during studies it made me puke each time I had to write code Mar 26 22:15:45 s/puke/wanting to puke/ Mar 26 22:15:50 z80 even has task switching :-D Mar 26 22:16:12 and the XorA instruction, which is of course the coolest! Mar 26 22:16:21 and very ununiversal registers Mar 26 22:17:20 not sure what you mean by that Mar 26 22:17:50 at that time I was spoiled by m68k probably Mar 26 22:18:12 and having to remember what can be done only with A/B or C/D or H/L was pita Mar 26 22:18:30 AF, BC, DE, HL :-D Mar 26 22:18:55 whatever Mar 26 22:19:48 programming microcontroller with 20 keys, 8 entry 7segment display and some adc/dac card was fun anyway Mar 26 22:20:28 wrote bunch of simple programs: signal generators, calculators, base converters etc Mar 26 22:21:08 and got enough beers from guys at year which had to draw program block schemes without having idea about programming Mar 26 22:21:11 ;d Mar 26 22:22:35 my brother is the big 6502 collector, me more z80s Mar 26 22:22:52 XorA: Steven? Mar 26 22:22:56 although I also have a c64 somewhere Mar 26 22:22:59 hrw: yes Mar 26 22:23:08 and a plus/4 Mar 26 22:23:29 my oldest 'computer' is zaurus c760 ;D Mar 26 22:23:37 my oldest is zx80 Mar 26 22:24:12 XorA: does Steven has kim-1? Mar 26 22:24:20 hrw: no Mar 26 22:24:25 hrw: is that a clone? Mar 26 22:24:34 XorA: no, its first 6502 devkit Mar 26 22:24:50 http://en.wikipedia.org/wiki/KIM-1 Mar 26 22:25:00 hrw: found it, no he isnt much of a programmer Mar 26 22:27:15 Package Complete: /home/hrw/HDD/devel/android/cyanogenmod/out/target/product/mako/cm-10.1-20130326-UNOFFICIAL-mako.zip Mar 26 22:27:19 uf. Mar 27 01:23:35 OpenEmbedded Developer Lounge | Web: http://openembedded.org | Repositories: http://git.openembedded.org/ | Primary Repo Mirrors: https://github.com/openembedded | This is not a distro or machine support channel ‎‏#‏HADIDAH Mar 27 01:40:56 #HaDiDaH Mar 27 01:41:04 #HaDiDaH Mar 27 02:00:35 That renders very very poorly on my terminal **** ENDING LOGGING AT Wed Mar 27 02:59:58 2013