**** BEGIN LOGGING AT Thu Nov 17 02:59:57 2011 Nov 17 09:02:17 good morning Nov 17 09:19:30 oh no dbus-native now depends on base-passwd Nov 17 09:20:27 good morning Nov 17 09:20:38 hi florian Nov 17 09:22:51 *sigh* Nov 17 09:23:19 we really should have a qa stuff for checking if a native package depends on a target package Nov 17 09:27:46 mornin Nov 17 09:28:40 hi jineld Nov 17 09:28:43 morning all Nov 17 09:28:57 hi bluelightning Nov 17 09:29:36 bluelightning was there a patchwork for oe-core? Nov 17 09:29:56 woglinde: it's the same one as for oe now Nov 17 09:30:00 oe-dev that is Nov 17 09:30:03 ah found it Nov 17 09:46:41 hi xora Nov 17 09:47:32 yo woglinde Nov 17 09:58:53 woglinde: we should have a QA check for that, yes :/ Nov 17 09:59:12 morning all Nov 17 09:59:20 hi pb Nov 17 09:59:21 woglinde: good find, I think we might need another tweak - replied on list Nov 17 09:59:26 hi pb_ Nov 17 09:59:32 hi rp Nov 17 10:02:56 rp hm what about the gcc-cross stuff? Nov 17 10:14:09 woglinde: what about it? Nov 17 10:14:22 the wrong include path Nov 17 10:14:39 woglinde: I'm not following? Nov 17 10:14:54 the thread I hijacked from ericben Nov 17 10:15:57 woglinde: oh. I think I'd like to understand what problem that patch solves Nov 17 10:16:06 compiling llvm Nov 17 10:16:09 with cmake Nov 17 10:16:32 it couldnt find the c++ headers Nov 17 10:16:43 so fired g++ up with verbose infos Nov 17 10:16:45 woglinde: ah, right. You totally confused me as I was trying to combine the two problems Nov 17 10:16:54 yeah my bad Nov 17 10:17:13 RP: maybe you have some ideas, we tried a couple of things already and I have no idea what else it could be; I have a u-boot recipe (built from a tarball no SRCREV/SRCPV involved), each time I bitbake myimage it compiles u-boot for no reason; using bitbake 1.14 Nov 17 10:17:16 woglinde: yes, I think we should fix that Nov 17 10:17:51 Jin^eLD: how are you depending on uboot from the image? Nov 17 10:18:23 I do not think I am depending on it in the image itself, at least the image does not list u-boot Nov 17 10:18:36 I could quickly to a -g to see who is depending on u-boot at all Nov 17 10:19:11 it worked fine in OE-classic with the older bitbake, when I migrated my stuff to OE-core I noticed this behaviour Nov 17 10:20:07 Jin^eLD: Can I look at this "stuff" anywhere? Nov 17 10:20:27 Jin^eLD: I'd suspect it something like depending on the do_rootfs task which is "nostamp" Nov 17 10:20:36 hmm I did not check it in yet, I could make a tarball? Nov 17 10:20:46 and if something depends on a "nostamp" task it will always rerun Nov 17 10:20:56 but I'm just guessing Nov 17 10:21:05 Jin^eLD: can you pastebin the machine.conf file? Nov 17 10:21:09 how would such a dependency look, i.e. what do I grep for? I'm surely not doing it in DEPENDS Nov 17 10:21:16 sure, sec Nov 17 10:21:40 Jin^eLD: I'd find where u-boot is being depended upon Nov 17 10:21:52 easier to grep for Nov 17 10:22:28 http://pastebin.mozilla.org/1385060 Nov 17 10:22:39 it is in EXTRA_IMAGEDEPENDS Nov 17 10:22:53 but at91bootstrap is there as well and that one is not being rebuilt Nov 17 10:23:02 I took the conf from my classic setup without changes Nov 17 10:25:53 based on -g u-boot is depending on these packages: http://pastebin.mozilla.org/1385061 Nov 17 10:27:52 Jin^eLD: that all looks correct and ok :/ Nov 17 10:28:10 Jin^eLD: I assume none of the dependencies listed there rebuild? Nov 17 10:28:24 nope, only u-boot Nov 17 10:28:32 Jin^eLD: are you using rm_work? Nov 17 10:28:36 yes Nov 17 10:28:52 ah. Is your u-boot recipe defining any custom tasks? Nov 17 10:28:57 let me check Nov 17 10:29:20 indeed it is :> Nov 17 10:29:24 I took the recipe from classic Nov 17 10:29:31 addtask deploy before do_build after do_compile Nov 17 10:29:50 Jin^eLD: rm_work is removing those tasks and rm_work is not "covering" them so the system finds it needs them and reruns it Nov 17 10:29:57 Jin^eLD: have a look at deploy.bbclass Nov 17 10:30:14 aah, finally an explanation and a hint where to dig :) thanks Nov 17 10:30:21 we were looking at stamps, sqlite database and other things Nov 17 10:30:39 Jin^eLD: I suspect an "inherit deploy" might help a lo Nov 17 10:30:40 lot Nov 17 10:31:30 let me try :) Nov 17 10:32:18 so I am inheriting deploy and can drop the addtask thing? Nov 17 10:32:37 if I read the deploy.bbclass correctly..? Nov 17 10:33:06 Jin^eLD: yes Nov 17 10:34:50 RP: thanks a lot! rebuilding and checking now... Nov 17 10:37:49 Jin^eLD: I just looked at the class and you still need your original addtask Nov 17 10:38:00 oh ok Nov 17 10:38:06 sorry, I thought you didn't Nov 17 10:38:22 * RP__ 's memory is evidently fuzzy Nov 17 10:38:29 :) Nov 17 10:45:18 addtask deploy before do_populate_sysroot after do_compile Nov 17 10:45:49 and deploy in ${DEPLOY_DIR_IMAGE} Nov 17 10:45:50 rather than the old line? ok.. thanks Nov 17 10:46:08 I'll compare with the newer u-boot recipes in core Nov 17 10:46:29 we use that in meta-handheld for installers Nov 17 10:48:54 Jin^eLD: this was for mimicking the package_stagefile_shell we had in oe-classic Nov 17 10:55:47 Hi, I have my own machine type pc7302 Nov 17 10:56:03 when I compile busybox with oe Nov 17 10:56:25 sometimes it unpack under tmp/work/armv6-oe-linux-gnueabi Nov 17 10:56:43 and sometimes under tmp/work/armv6-oe-linux-gnueabi Nov 17 10:56:59 sorry, tmp/work/pc7302-oe-linux-gnueabi Nov 17 10:58:00 I think the difference is compiling busybox directly and compiling by an image bb Nov 17 10:58:51 should not unpack sources to same directory in two cases? Nov 17 11:00:47 mgundes? there is no diffrence for compiling Nov 17 11:02:41 when I tell "bitbake busybox" it is unpacked under to tmp/work/armv6-oe-linux-gnueabi directory Nov 17 11:03:27 but when I creating rootfs image my bb file, this time busybox sources unpacked to tmp/work/pc7302-oe-linux-gnueabi Nov 17 11:03:58 I don't know why it is Nov 17 11:04:15 RP, ant_work: thanks guys - it works now :) no more u-boot rebuilding when I build the image Nov 17 11:04:44 mgundes_ hm and? Nov 17 11:07:43 there four directories under tmp/work Nov 17 11:07:47 all-oe-linux-gnueabi armv6-oe-linux-gnueabi i686-linux pc7302-oe-linux-gnueabi Nov 17 11:08:19 what is the difference between armv6-oe-linux-gnueabi and pc7302-oe-linux-gnueabi Nov 17 11:09:03 mgundes: these are build for different machines/architectures Nov 17 11:09:34 if I use, say for ARM9 and for my StorCenter (powerpc) I will share x86 stuff but get separate diectories for arm and ppc Nov 17 11:09:48 and I'll share "all" stuff Nov 17 11:11:32 hm this is for reusing compiled sources with next different type of arch/machine build Nov 17 11:11:34 right? Nov 17 11:12:14 depends on your overall configuration but yes, so you do not build stuff twice that does not need to be built (like noarch packages, etc) Nov 17 11:14:13 ok but I still could not understand why my busybox unpacked to different paths Nov 17 11:14:31 when I say "bitbake busybox" oe knows it is for arm and machine is pc7302 Nov 17 11:15:03 and when I say "bitbake myimage" oe knows it is crosscompiling for arm and machine is pc7302 Nov 17 11:15:49 do you have any idea why oe deicde to different paths for busybox in two cases? Nov 17 11:17:41 I don't :P Nov 17 11:18:44 thanks :) Nov 17 11:44:42 * pb_ stabs ubuntu Nov 17 11:44:56 grr, poxy networkmanager Nov 17 11:58:12 pb_: sounds familiar... nils upgraded his ubuntu and complains quite a lot. Nov 17 11:58:34 yeah, my colleague is just trying to install ubuntu on a new PC and he seems to be having some kind of nightmare. Nov 17 11:58:45 well, now he's trying debian and that is even worse: it doesn't recognise his keyboard Nov 17 12:01:05 hehe unity Nov 17 12:02:06 yeah, it's all bad Nov 17 12:02:19 rather depressing really Nov 17 12:03:02 and I guess I have all this to look forward to when I get a new laptop :-} Nov 17 12:09:42 * XorA is finding Mint 12 quite pleasant to use, certainly blows away Unity Nov 17 12:10:03 I am happy with awesome anyway Nov 17 12:11:43 is Mint using GNOME 3? Nov 17 12:12:02 one of my colleagues just installed xfce on his netbook and he seems happy with that, so I might try that next time. Nov 17 12:12:58 however, a more pressing issue for me is that my mitre saw is broken. seems I need to buy a new one. :-( Nov 17 12:16:05 Mint uses gnome 3 but with extensions to make it usable and its nothing like gnome shell, much more like gnome2 Nov 17 12:16:32 ah right, that sounds worth a look Nov 17 12:16:33 pb_: Laptop annoying you that badly you need to make art out of it? Nov 17 12:17:01 XorA: heh, no, old laptop still just about usable at the moment. Nov 17 12:17:20 I was planning to buy a new one this month but it looks like I need to spend that money on the saw instead so the laptop will have to wait. Nov 17 12:17:36 I had never used Mint before 5 days ago, but the whole gnome-shell/unity mess drove me to search solutions Nov 17 12:17:57 hmm.. gnome-session-fallback Nov 17 12:19:20 * pb_ going christmas shopping (!!) now Nov 17 12:19:20 bbiab Nov 17 12:19:39 help the economy..but a lot! Nov 17 12:23:00 xmas shopping this year is going to have to be squeezed into the few days I am actually at home :-( Nov 17 12:37:35 pb_, at least the mitre saw doesn't run gnome3 Nov 17 12:39:50 gm crofton Nov 17 12:42:00 yo mr Crofton Nov 17 13:55:06 argllllll Nov 17 13:55:13 uclibc dont has qsort_r Nov 17 13:55:24 who the hell patched it this wrong Nov 17 13:55:32 way Nov 17 13:57:35 probably me Nov 17 13:58:00 please fix it Nov 17 13:58:18 and there is newer glib too Nov 17 13:58:34 hm Nov 17 13:58:50 what was the intention of the patch? Nov 17 13:59:12 rather than useing the site-files Nov 17 13:59:56 yes please change it to use site-files and upgrade it when you're there Nov 17 14:00:43 hm Nov 17 14:00:48 hm Nov 17 14:01:26 but I need more information Nov 17 14:02:13 is the result wrong with eglibc? Nov 17 14:02:18 or under diffrent archs? Nov 17 14:02:29 it cannot execute arm binaries while building on x86 :) Nov 17 14:02:52 and because of that comment # BSD has a qsort_r with wrong argument order Nov 17 14:03:07 re Nov 17 14:03:12 jo pb Nov 17 14:03:25 I didn't expect it's something we need to care about in OE (not expecting that qsort_r is also not available in uclibc) Nov 17 14:06:28 hm Nov 17 14:06:30 WARNING: For recipe glib-2.0, the following files/directories were installed but not shipped in any package: Nov 17 14:06:33 WARNING: /usr/lib/gio Nov 17 14:06:35 WARNING: /usr/lib/gio/modules Nov 17 14:13:58 hm what replaces oenote these days? Nov 17 14:17:25 Say I have base-image-productA and base-image-productB, what technique would allow productA to use QT 4.7.1 while allowing productB to use QT 4.7.4 ? Nov 17 14:18:04 They run on the exact same hardware Nov 17 14:18:20 make two images? Nov 17 14:18:42 ah you already have Nov 17 14:18:43 hm Nov 17 14:19:08 hm okay one ugly solution would be to define the PREFFERED_VERSION in machine.def Nov 17 14:19:34 but thats the only one comming to my mind now Nov 17 14:19:37 What postfix would be correct if they both use the same machine.conf? Nov 17 14:20:01 could not be Nov 17 14:20:14 hm args Nov 17 14:20:16 for example, PREFERRED_VERSION_tar_produtA Nov 17 14:20:26 same hw Nov 17 14:20:53 There's no good/easy way to do that. You could hack the packaging for Qt to make the two of them be parallel-buildable and generate separate output packages, then you can just depend on the appropriate things from your image file. Nov 17 14:21:08 yes exactly same hardware, just want a stable productA while productB is being built Nov 17 14:21:15 Or you could teach bitbake how to do per-recipe sysroot construction and versioned dependencies. Which would be rather more work but a better outcome :-) Nov 17 14:21:35 Or you could make two distros, one with each qt version, and build them in separate trees. Nov 17 14:21:45 yes Nov 17 14:21:56 two distros is easiest way Nov 17 14:22:00 I have manually built 2 QT and packaged them, but I needed to change local.conf Nov 17 14:22:11 Hi, I try to build an image for the beaglebone using Angstrom, OE. I've got a MemoryError, which seems to be OE related, therefor I'm asking here. http://paste.ubuntu.com/741180/ Nov 17 14:22:16 which would not be easy for most of my users Nov 17 14:22:42 atl19711 did you listen? Nov 17 14:22:48 two distros Nov 17 14:22:52 yes, 2 distros easiest Nov 17 14:22:56 falstaff: seems that you need more memory Nov 17 14:23:08 I built it once again with "bitbake virtual/kernel", now python consumes 50% of my memory (2GB) and it doesnt continues Nov 17 14:23:20 thank you Nov 17 14:24:07 falstaff why you use a buildmachine with that low ram? Nov 17 14:24:10 pb_, it's in a loop somehow, I don't think it really needs more memory, something is broken Nov 17 14:24:23 woglinde, 4GiB ram total... Nov 17 14:25:01 mm, yeah, if it's using more than 4GB it does sound as though something is broken Nov 17 14:25:14 could try using strace to see what it's up to, I guess Nov 17 14:25:39 nothin in the log files? Nov 17 14:26:13 pb_, woglinde, that's the current state... http://paste.ubuntu.com/741209/ Nov 17 14:26:14 wipe out the cache directory, see if that helps? Nov 17 14:27:43 RP__, I'm new to OE, is there a easy way to delete related chaches only? I, eerm, OE built a packages while already :-) Nov 17 14:28:51 falstaff: rm tmp/cache/ -r Nov 17 14:32:24 JaMa: I'm trying to clean /linux in meta-handheld, after committing 3.1 i would remove 2.6.39, linux_git, linux-kexecboot_git at least. Suggestions? Nov 17 14:33:01 ant_work: upgrade to 3.1.1? Nov 17 14:33:13 Yes, I already have done it Nov 17 14:33:39 maybe keep _git with SRCREV for 3.2-rc2+ ? Nov 17 14:35:02 no strong opinions Nov 17 14:35:11 there is much more to do in userspace now ;) Nov 17 14:48:42 RP__, I tried that, but the same seems to happen afterwards Nov 17 14:49:06 falstaff: ok, it a was a bit of a long shot :( Nov 17 14:52:44 pb__, using strace on the process who uses all the memory (the last in chain btw) http://paste.ubuntu.com/741238/ Nov 17 14:57:23 moin Nov 17 14:58:30 Anyone knows how to require inc files in an oe layer without having them also in the same layer? Like require linux.inc from a kernel recipe but using the one from oe-core and not a out-of-sync copy in your own BSP layer Nov 17 14:58:34 hi stefan_schmidt Nov 17 14:58:42 hi florian Nov 17 14:58:57 * stefan_schmidt has finished his studies :) Nov 17 14:59:13 stefan_schmidt: cool - congratulations Nov 17 15:00:01 florian: thx, took long enough :) Nov 17 15:00:39 stefan_schmidt: need to manipulate FILESPATH/BBPATH, e.g. like one does with bbappend? Nov 17 15:01:36 zecke: That is what shoragan and myself are wondering about Nov 17 15:01:41 stefan_schmidt: 'require recipes/foo/bar.inc' Nov 17 15:01:46 instead of 'require bar.inc' Nov 17 15:01:54 then it'll search for that relative path anywhere in bbpath, adn find it Nov 17 15:02:08 whereas 'bar.inc' doesn't exist anywhere in bbpath but the path where the recipe lives Nov 17 15:02:46 kergoth: interesting, thanks Nov 17 15:02:51 will try it right away Nov 17 15:07:43 stefan_schmidt all finished? Nov 17 15:10:12 woglinde: yeah, got all my paperwork today. Exmatrikulation tomorrow :) Nov 17 15:10:34 cool Nov 17 15:11:52 woglinde: yeah, ages over ages and finally done :) Nov 17 15:14:40 zecke, require with full path should help for recipes-osmocom/meta/meta-toolchain-osmo.bb in meta-telephony Nov 17 15:15:07 hmm, the kernel stuff changed a lot in oe-core. But I need to rely on the meta-ti layer anyway. Will use the linux.inc from there. Nov 17 15:18:14 stefan_schmidt: look at this de-uglified version http://cgit.openembedded.org/meta-handheld/tree/recipes-kernel/linux/linux.inc Nov 17 15:20:10 ant_work: heh, de-uglified is a matter of taste it seems. root-over-nfs-over-usb-eth support... ;) Nov 17 15:20:18 ant_work: more serious. Will have a look Nov 17 15:20:31 heh, partly Nov 17 15:24:07 Hm, there seems to be a problem with git: http://paste.ubuntu.com/741261/ Nov 17 15:24:44 delete the git dir Nov 17 15:24:47 sorry Nov 17 15:24:55 you need to catch the 500 mb again Nov 17 15:30:50 woglinde, ok, now everything getting a bit clearer. I deleted that folder, and then I get this error: gzip: stdin: unexpected end of file Nov 17 15:32:00 What I think happend is that the gzip download was interrupted (I had connection problems yesterday) then I restarted the build, and because a part of the file was there it unpacked it (or part of it). I restarted the build once again, and then these git errors happend... Nov 17 15:32:42 * falstaff notes: read the logs before just restart the build Nov 17 15:35:00 shoragan: yes, it should Nov 17 15:35:14 shoragan: you still need to know if you are in yocto or clean oe-build. :( Nov 17 15:37:36 kergoth: worked fine, thanks a lot. FInally I can drop some inc files form the small BSP layer :) Nov 17 15:38:26 :) np Nov 17 15:39:17 hi zecke, kergoth Nov 17 15:51:37 woglinde, still problems: http://paste.ubuntu.com/741295/ Nov 17 15:51:58 ps shows that once this git.real thing is used and once it's just calling git Nov 17 15:52:02 might that be a problem? http://paste.ubuntu.com/741293/ Nov 17 15:52:42 hm Nov 17 15:52:48 watch your traffic Nov 17 15:52:55 maybee git is downloading Nov 17 15:52:59 its 500 mb the kernel Nov 17 15:53:05 woglinde, I watched the directory sources/downloads/git2/github.com.beagleboard.linux.git/ Nov 17 15:53:09 du -sh Nov 17 15:53:20 it growed to 690 MB... Nov 17 15:53:21 du dont working with git Nov 17 15:53:37 watch network traffic Nov 17 16:03:01 woglinde, ok its downloading now, 100mb already Nov 17 16:08:11 woglinde closed at 503913543 bytes Nov 17 16:08:23 *g* Nov 17 16:09:11 woglinde, iptraf is exact :-) now git does something, 100% cpu Nov 17 16:10:23 git stopped Nov 17 16:10:48 the errors from before :-( Nov 17 16:11:08 uhm Nov 17 16:11:14 whats your fs? Nov 17 16:11:26 ext4 Nov 17 16:11:41 what git version? Nov 17 16:12:00 maybee the remote repo is broken Nov 17 16:12:09 1.7.5.4 Nov 17 16:14:20 woglinde, I'm going to clone it manually and switch to the relevant branch... Nov 17 16:14:30 brb Nov 17 16:25:33 gm all Nov 17 16:45:28 woglinde, checkout succeeded, as well as checkout the branch Nov 17 16:52:01 how can I remove something from DEPENDS in a .bbappend file? Nov 17 16:52:29 what I do not understand is this multiple level of git commands: http://paste.ubuntu.com/741357/ Nov 17 16:55:07 gchiii: an anonymous python function, or := + oe_filter_out. grep around for examples Nov 17 16:57:55 kergoth: thanks, I have never done an anonymous python function, or used the oe_filter_out thing. i will do some more google-ing Nov 17 17:04:09 using kernel nfs server, which package should i add to get all those sysvinit scripts to manage the kernel nfs server? Nov 17 17:04:16 nfs-utils are for userland servers? Nov 17 17:57:54 hi, with oe-core : is that expected that when building the same image (qt4e-demo-image) for several machine (omap3, imx51, imx53) with the same architecture (cortex a8), the build last longer and longer at each new machine when I would expect it to reuse the previously built package (example : qt4 embedded) instead of rebuilding Nov 17 18:04:25 ericben: I'd have thought it would reuse it unless there was something machine specific Nov 17 18:06:17 RP__: I'd have thought that also but for example qt4 doesn't seems to have something machine specific .. and on the second run it's even longer to build than the first time (with pseudo running for hours) Nov 17 18:06:23 not if they are using different TUNE_CCARGS ie -mtune Nov 17 18:06:38 JaMa: same include file for CARGS Nov 17 18:06:51 ericben: its reusing the same WORKDIR? Nov 17 18:07:15 fray: we need to look at pseudo in this context :/ Nov 17 18:07:29 RP__: same tmp dir (Im' using angstrom setup script) Nov 17 18:07:46 omap3, imx51, imx53 have all same -mtune? Nov 17 18:07:50 RP__: I'll provide some numbers when rebuilding everything Nov 17 18:07:53 ericben: but they each use the same WORKDIR too? (an armv7 one I guess) Nov 17 18:08:12 JaMa: the 3 are cortex A8 Nov 17 18:08:18 RP__: yes armv7a-angstrom-linux-gnueabi/ Nov 17 18:08:34 RP__: only the few mahcine specifics are in different workdir Nov 17 18:08:49 ericben: bitbake shouldn't be rerunning that :/ Nov 17 18:09:33 RP__: in fact (this is not proved yet but that's my feeling when looking at ps & top) : it seems to extract the previously used packages and then to launch again make on them Nov 17 18:10:21 RP__: also Im using rm_work Nov 17 18:10:30 JaMa: the 3 machine have require conf/machine/include/tune-cortexa8.inc Nov 17 18:10:46 ericben: I have the same with nokia900 palmpre palmpre2 Nov 17 18:10:49 JaMa: and the toolchain is'nt rebuilt (at least I didn't notice that) Nov 17 18:10:49 ericben: does qt have any addtasks ? Nov 17 18:10:56 ericben: and they are always rebuilding Nov 17 18:10:58 ericben: it could be rm_work Nov 17 18:11:18 as reported in "[OE-core] sstate.bbclass: Ensure machine specific stamps are only wiped for the current task" Nov 17 18:11:52 ericben: because stamp files says that everything is built already for ie nokia900, but sstate checksums are already different so it decides to rebuild it for palmpre Nov 17 18:12:33 JaMa: ok what is strange is that it seems not to rebuild everything (I don't see as many gcc as the first time in top/ps) Nov 17 18:12:36 ericben: see http://lists.linuxtogo.org/pipermail/openembedded-core/2011-November/012053.html Nov 17 18:13:28 RP__: I didn't see addtask with a quick grep on class & qt recipes Nov 17 18:14:05 if you rebuild all 3 devices from scratch without any change to metadata, then it will reuse sstate Nov 17 18:14:28 JaMa: we should figure out why the sstate checksums are differing if that is the issue Nov 17 18:15:46 RP__: the problem is that when I finish ie shr-image build for nokia900 I would assume that all sstate checksums are uptodate for that build Nov 17 18:16:13 RP__: but problem is that checksums are changed only stamps are holding it from rebuilding everything again Nov 17 18:16:31 because I'm using basic BB_SIGNATURE_HANDLER again Nov 17 18:16:40 and when I switch machine to palmpre Nov 17 18:17:12 it doesn't look at nokia900 stamps (from basic BB_SIGNATURE_HANDLER) but is looking on sstate-cache for right checksums which are not available Nov 17 18:17:19 JaMa: this is the mtune issue? Nov 17 18:17:30 no .. those are 2 issues Nov 17 18:17:37 in fact starting from yesterday I have 5 different sstate-qt4-embedded-armv7a-angstrom-linux-gnueabi-4.7.4-r36.3-armv7a-2-*pop* Nov 17 18:18:04 mtune is about checksums too strict to keep shared feed in armv7a-vfp-neon Nov 17 18:18:08 ericben: and what does bitbake-diffsigs say changed? Nov 17 18:18:16 RP__: I'm on it Nov 17 18:18:48 and the 2nd issue is that with basic BB_SIGNATURE_HANDLER I don't see rebuilds unless PV-PR is changed Nov 17 18:19:05 JaMa: I think I see what you mean about the stamps Nov 17 18:19:09 so finished image build seems like everything should be uptodate (and uptodate in sstate-cache) Nov 17 18:19:23 JaMa: if you didn't use rm_work it wouldn't do that Nov 17 18:19:31 but it's uptodate wrt stamps files Nov 17 18:19:41 RP__: http://pastebin.com/4zRHU0RK Nov 17 18:19:46 but not uptodate wrt checksums used in sstate-cache Nov 17 18:20:53 ericben: hmm, a machine.conf file hardcoding TARGET_ARCH? Nov 17 18:21:36 RP__: ok the last one is doing that Nov 17 18:22:23 RP__: I thought we've fixed rm_work with 36386f3b8cadf283954f5c6db6ac6ee463c395de Nov 17 18:22:24 ericben: remove that line and it should help that problem at least Nov 17 18:22:35 RP__: but that's bug then isn't it? Nov 17 18:23:02 RP__: build launched again, that machine was just ported from classic and this line wasn't removed Nov 17 18:23:17 JaMa: This has nothing to do with that commit Nov 17 18:23:47 JaMa: If you don't have rm_work enabled, the stamps are all left intact and it won't use sstate checksums at all Nov 17 18:24:08 aha Nov 17 18:24:21 JaMa: So when you build the second one, bitbake will see the stamps and be happy. With rm_work all the stamps are removed and replaced with setscene ones Nov 17 18:24:36 so its forced to consider sstate checksums Nov 17 18:24:55 RP__: I'll launch a build from scratch with time logging on a more powerfull build host for the same 3 machine and if I see the problem I'll provide details on the list. Thanks for the analysis of the present problem. Nov 17 18:25:08 ericben: sounds good :) Nov 17 18:26:04 RP__: and cannot we remove only useless workdir data and keep stamps where possible? Nov 17 18:26:33 RP__: because something still needs to populate machine specific sysroot after machine switch, right? Nov 17 18:26:44 JaMa: It turns out to be extremely hard to do this and not break the builds Nov 17 18:26:58 JaMa: deal with the user doing random bitbake xxx -c compile -f and so on Nov 17 18:27:06 RP__: and even with rm_work I still have packages-split etc to populate it Nov 17 18:27:30 RP__: and how does palmpre populate sysroot if only nokia900 was built before? Nov 17 18:27:49 RP__: it still needs to use populate_sysroot from sstate-cache? Nov 17 18:28:06 JaMa: yes Nov 17 18:28:21 and how will it find "right" .tgz in sstate-cache? Nov 17 18:28:31 JaMa: The best solution would be to teach the sstate dependencies to equate the different mtune settings Nov 17 18:28:50 I thought that it computes own sstate checksum and looks for tgz with that checksum and use it if exists Nov 17 18:28:51 JaMa: since you clearly don't mind having inconsistent package feeds Nov 17 18:29:23 JaMa: right, so we need to encourage the checksum calculation to match the right values Nov 17 18:29:35 I do mind.. but with FEED_ARCH computed as it's now I think it's better to make them equal Nov 17 18:29:58 or just do machine specific FEED_ARCHs so files are not overwritten over and over again Nov 17 18:30:36 RP__: but then removing rm_work won't help, or I'm missing something Nov 17 18:33:11 JaMa: well, if you give each tune its own namespace the problem goes away Nov 17 18:33:30 JaMa: It will build them three times but in different namespaces with the different tune values Nov 17 18:36:37 well I think we should decide if it's better to build three times (and populate 3 different feeds so enduser will know if he is armv5t getting binary with -mtune=arm926ej-s or -mtune=xscale) Nov 17 18:37:04 or not pass -mtune at all Nov 17 18:37:35 or 3) make it opt in to pass -mtune if builder knows he is building only 1 mtune per arch Nov 17 18:38:05 mtune should be machine specific to be effective Nov 17 18:38:07 but right now when I do opkg upgrade on my spitz I cannot control if I get binaries built for qemuarm or spitz Nov 17 18:38:27 gm all Nov 17 18:39:11 and building those 2 twice is currently useless Nov 17 18:39:36 not sure how it is used in rpm/deb packaging though Nov 17 18:39:37 hi khem Nov 17 18:39:38 khem: gm Nov 17 18:40:15 JaMa: in the case you cited something tuned for xscale may not run on arm926ej-s Nov 17 18:40:30 since compiler will use PLD and LDRD/STRD Nov 17 18:40:50 and that's exactly the case when someone is building spitz and qemuarm machines.. Nov 17 18:41:31 I think xscale should be counted as separate arm sub family Nov 17 18:41:39 like armv5t and armv4t Nov 17 18:42:37 I would say least common denominator in this case is armv5te Nov 17 18:43:44 did I mention that having not to switch between job and studies anymore is great? :P Nov 17 18:43:54 yes Nov 17 18:44:12 stefan_schmidt: did you finish uni ? Nov 17 18:44:19 woglinde: sorry, was not targeted at you. Just happy. :) Nov 17 18:44:26 khem: juuuup :) Nov 17 18:44:34 congrats Nov 17 18:44:37 finally my cs diploma :) Nov 17 18:44:42 khem: thanks Nov 17 18:44:49 woglinde has to hurry up Nov 17 18:44:59 but there are certain advantages of being student Nov 17 18:45:25 like discounts on movie tickets and ski resport tickets Nov 17 18:45:28 did I mention that I would like to change dayjob? :) Nov 17 18:45:30 khem: there are indeed. But I'm happy to trade them now after so many years. Nov 17 18:45:41 I bet Nov 17 18:45:42 jama do it Nov 17 18:45:46 Especially freelance work and studies at the same time was stressing me a lot Nov 17 18:45:55 were you at TUM Nov 17 18:46:34 khem: hmm, ski resorts. Need to think about a snowboarding trip next year. Good that you remember me Nov 17 18:47:37 Any of you guys are using the systemd images from meta-angstrom? Nov 17 18:48:03 stefan_schmidt: yes I have been using it lately Nov 17 18:48:06 and it works well Nov 17 18:48:27 khem: does halt works for you? Nov 17 18:49:01 It seems somehow systemctl is broken and gets no dbus connection. Fails for halt which is a symlink to systemctl... Nov 17 18:49:12 stefan_schmidt: havent tried that Nov 17 18:49:20 stefan_schmidt: all I use is qemu Nov 17 18:49:29 khem: ok, everything else was fine so far Nov 17 18:49:38 I was not able to boot into gnome though Nov 17 18:49:40 khem: Not playing with the efika anymore? Nov 17 18:49:45 but that was before I went on vacation Nov 17 18:49:54 khem: even better :) Nov 17 18:49:54 I havent tried it after return Nov 17 18:50:02 stefan_schmidt: not much Nov 17 18:50:12 stefan_schmidt: I have beagle xM Nov 17 18:50:19 stefan_schmidt: are you sure you don't have /var/run -> volatile/run for dbus to run? Nov 17 18:51:25 JaMa: hmm, its the latest build form oe-core/meta-ansgtrom without any image changes from me. Let me check. Nov 17 18:56:16 JaMa: tmpfs on /var/run type tmpfs (rw,nosuid,nodev,relatime,mode=755) Nov 17 18:56:30 JaMa: tmpfs should be correct, no? Nov 17 18:56:44 Not much done with the run dir so far Nov 17 18:57:33 Ah, and this is the error message for halt. Just if someone has seen it before: http://pastebin.com/8aYfcVvs Nov 17 18:58:35 The first line is the bummer I think. halt is a symlink to systemctl and that fails on every invocation with the missing dbus connection. systemd and dbusd are happily running though Nov 17 18:58:46 khem: I have some fun with Qt/uclibc. Do you know if there were __attribute__((constructor)) fixes for uclibc in the last ~1 year? Nov 17 18:59:51 zecke: hmm I dont remember direct fixes what sort of errors do u get Nov 17 18:59:59 zecke do you use oe-core? Nov 17 19:02:32 woglinde: sysmocom is on an old poky snapshot Nov 17 19:02:51 * woglinde wonders why Nov 17 19:02:58 khem: okay. i think i see a propblem when I dlopen a plugin linking to directfb, that dlopens a plugin that uses __attribute__((constructor)) Nov 17 19:03:13 woglinde: overworked and underpaid. or why poky? Nov 17 19:07:03 yes why poky anymore Nov 17 19:07:07 zecke: does the shared library have proper .ctor and .dtor sections ? Nov 17 19:07:08 it gets no love Nov 17 19:07:57 zecke: I wouldnt deny if ld.so does not have a problem with running ctors of dlopened library Nov 17 19:08:01 its a bit rare Nov 17 19:09:14 woglinde: why do you say it does not get love? I thought the subset is more well tested... but after udev not being started, PCI modules not loaded by udev, rpm on jffs2, i think it is not as well tested as I think it was. On top of that getting fixes into poky is 'difficult'. Nov 17 19:09:43 khem: how would you define proper? and which library? the outermost? Nov 17 19:10:29 zecke: yes the one that has the function with constructor attr Nov 17 19:11:10 zecke: set a breakpoint on __do_global_ctors Nov 17 19:11:16 and see if it breaks there Nov 17 19:11:21 when it loads that library Nov 17 19:11:41 khem: i have a printf in the method.. it is called. Nov 17 19:13:51 ok that means its working isnt it Nov 17 19:15:02 make sure that the linking is totally dynamic and there is no other library being loaded which has this library linked in static Nov 17 19:15:02 khem: yes, but I think some pointers are wrongly... Nov 17 19:15:17 zecke: hmmm Nov 17 19:15:44 khem: anyway, thanks a lot. I just wondered if you are aware of some weird corner case fixes in uclibc Nov 17 19:16:30 zecke: not that I know Nov 17 19:16:46 zecke: if you see more details I can help Nov 17 19:17:31 khem: yeah, will try to write a testcase... sadly it is a stinky old vendor drop. :( Nov 17 19:19:45 JaMa: just reading your dbus bug report on oe-core. And something is not right for my UID/GID settings as well: http://pastebin.com/71zGffjb Nov 17 19:26:19 khem: ah funny, a function is not resolved... Nov 17 19:26:45 zecke: hmm Nov 17 19:26:57 is this function from the now loaded .so Nov 17 19:28:34 khem: http://paste.lisp.org/display/125922 Nov 17 19:29:12 khem: function is resolved to 0x0... let me see if the plugin links to libdirect.so Nov 17 19:30:37 khem: ah, the plugin violates the "link to what you use rule". so it does not link to libdirect.so Nov 17 20:12:58 zecke: there you go Nov 17 20:13:34 zecke: so either dlopen that file or add it to linker commandline for plugin so it get added to DT_NEEDED Nov 17 20:16:57 can some reminf me how IMAGE FEATURES work in classic Nov 17 20:17:11 specifically, adding all the debg packages Nov 17 20:22:25 Crofton|work: Add IMAGE_FEATURES += "dbg" to your local.conf Nov 17 20:23:47 can I do it in the image file? Nov 17 20:24:24 Crofton|work, thanks for the samba fix btw, it worked for me Nov 17 20:24:46 er Nov 17 20:24:49 what was it? Nov 17 20:25:25 the python path that were taken as cotaminated Nov 17 20:25:34 s/the/some/ Nov 17 20:25:55 ah Nov 17 20:26:04 I am going nuts, to many things going on Nov 17 20:26:09 ok Nov 17 20:26:18 Crofton|work: may be yes Nov 17 20:26:22 you can add override Nov 17 20:26:31 khem: yeah... -no-undefined should be default link behavior... Nov 17 20:26:56 ( + ac_cv_path_PYTHON=/not/exist \ in EXTRA_OECONF of samba) Nov 17 20:27:35 Crofton|work: yes, you can add it in the image recipe fine Nov 17 20:27:47 zecke: ok yes Nov 17 20:27:49 might have to after the inherit of image, don't recall Nov 17 20:30:32 khem: hehe Nov 17 20:42:15 Missing or unbuildable dependency chain was: ['sysvinit-pidof-dbg'] Nov 17 20:42:45 heh, bitbake really shouldn't die on a missing rrecommends Nov 17 20:48:29 yeah Nov 17 20:49:38 any thoughts on solving this Nov 17 20:49:44 this is in oe-classic Nov 17 20:50:19 Hmm. could modify image.bbclass to include -dbg by recipe name only, not recipe name and package name Nov 17 20:50:35 or could INHERIT += "package_dbg", which makes -dbg packaging per-binary-package rather than per-recipe Nov 17 20:50:43 * kergoth hasn't looked at that stuff in a long time Nov 17 20:55:25 image_featuers += "package_dbg" is building Nov 17 20:55:35 we'll see if the image is huge when it is done :) Nov 17 20:56:54 someday i'm going to remember that my ll shell alias exists Nov 17 21:12:41 hm whats the variable for $host/bin/$target_arch Nov 17 21:19:45 hm ${TOOLCHAINPATH} Nov 17 21:21:09 hm or STAGING_BINDIR_TOOLCHAIN Nov 17 22:34:04 denix: ping Nov 17 23:20:42 Crofton|work: hey phil, you around? Nov 17 23:20:57 yeah, but on a telecon Nov 17 23:21:12 with someone choking on a tootsie roll Nov 17 23:21:42 apparently he i cramming tootsie rolls into his muoth Nov 17 23:22:15 hehe Nov 17 23:22:54 * darknighte does a spit-take Nov 17 23:23:44 Crofton|work: too funny. anyway, look for an invite to a telecon tomorrow (shoeleather) Nov 17 23:23:58 we need to job like Crofton|work with so much spare time you have to commit suicide by tootsie Nov 17 23:24:15 ok Nov 17 23:24:25 these guys are nuts Nov 17 23:24:30 gnuradio telecon Nov 17 23:25:52 huh? seriously? Nov 17 23:40:16 For the records: I could solve my problem, the root cause was a not completly downloaded mirror file (git2_github.com.beagleboard.linux.git.tar.gz in my case). The installer didn't noticed that, uncompressed it and then git faild with those strange errors I had... Nov 18 02:42:02 hi. is there a way i can get output from a daemon started in angstrom /etc/init.d to go to the console, i can get the output to go to a file with no problem, but if i try > /dev/console 2>&1 or /dev/tty or dev/tty0 , can't get anything to show up on the console. is there something special about oe's syslog.busybox? **** ENDING LOGGING AT Fri Nov 18 02:59:57 2011