**** BEGIN LOGGING AT Tue Aug 02 02:59:57 2011 **** BEGIN LOGGING AT Tue Aug 02 03:41:18 2011 Aug 02 08:36:31 morning all Aug 02 09:10:47 morning all Aug 02 09:23:05 good morning Aug 02 09:23:57 hi florian Aug 02 11:33:31 RP__: ping Aug 02 11:33:39 dongxiao: pong Aug 02 11:34:43 RP__: For the variable MULTILIB_PACKAGE_ARCHS, do we still need it? since multilib and normal recipe shares the same architecture currently... Aug 02 11:35:08 dongxiao: Isn't that used in the package backends? Aug 02 11:35:23 dongxiao: Its possible we don't, I know some of the ipk and rpm work overlapped Aug 02 11:35:51 RP__: Yes, however the value is actually same as PACKAGE_ARCHS Aug 02 11:36:09 dongxiao: Ah, its not a list of all the values combined? Aug 02 11:36:15 In that case we can remove it Aug 02 11:36:44 RP__: we need the value before since we have architecture like lib32-i586, etc Aug 02 11:37:25 RP__: However we have removed that kind of architecture and both normal package and multilib package are put in the same tmp/deploy/rpm/ARCH directory Aug 02 11:37:42 dongxiao: did you check the ipk backend for this? Aug 02 11:38:03 * RP__ suspects the ipk backend may still need this Aug 02 11:38:29 RP__: hmm, I checked with Lianhao this afternoon and he also considered to remove that variable... Aug 02 11:41:39 RP__: I greped the "MULTILIB_PACKAGE_ARCHS", and only three records (all in rpm side): Aug 02 11:41:39 meta/classes/package_rpm.bbclass: ml_package_archs="${MULTILIB_PACKAGE_ARCHS}" Aug 02 11:41:39 meta/classes/rootfs_rpm.bbclass: for each_arch in ${MULTILIB_PACKAGE_ARCHS} ${PACKAGE_ARCHS}; do Aug 02 11:41:39 meta/classes/rootfs_rpm.bbclass: bb.data.setVar('MULTILIB_PACKAGE_ARCHS', ml_package_archs, d) Aug 02 11:42:30 dongxiao: sounds like we might not need it then Aug 02 11:43:29 RP__: ok, I will make a patch for that. Also there will be several fix patches for sato rpm Aug 02 11:47:40 RP__: Another question about the DEFALTTUNE. Giving that a user is building a qemux86-64 image, and then he wants to build a lib32-zlib, so he need to manually set DEFAULTTUNE in local.conf? Aug 02 11:48:18 dongxiao: the user would need to define which tune to use for the multilib Aug 02 11:48:53 heh, and the local.conf.sample file is wrong :/ Aug 02 11:48:54 TUNENAME_virtclass-multilib-lib32 = "x86" Aug 02 11:49:10 should be DEFAULTTUNE_virtclass-multilib-lib32 = "x86" Aug 02 11:51:10 RP__: Thanks for the explanation Aug 02 12:46:28 RP__: do you have comments on one multilib patch for eglibc-locale? I saw that patch is still out of tree. Aug 02 12:50:36 RP__: _http://git.pokylinux.org/cgit.cgi/poky-contrib/commit/?h=dxu4/multilib&id=f7f91dfb4051dc1fbfd536612d59f3e4a31a27f9 Aug 02 12:58:59 dongxiao: hmm, I have concerns about that one :/ Aug 02 13:01:29 dongxiao: Basically, that addition is currently controlled by package_do_split_gconv() and the PACKAGE_NO_GCONV variable Aug 02 13:01:47 dongxiao: this change bypasses that a bit and makes a line in that funciton pointless Aug 02 13:10:04 RP__: hmm, sounds reasonable. But if not putting eglibc-gconv in PACKAGES, the eglibc-gconv will not be extended to lib32-eglibc-gconv... Aug 02 13:19:25 dongxiao: How about we add the MLPREFIX in the appropriate place? Aug 02 13:21:41 RP__: do you mean add a line in eglibc-locale.inc like: FILES_${MLPREFIX}eglibc-gconv = "${libdir}/gconv/*"? Aug 02 13:23:02 dongxiao: yes, should work... Aug 02 13:23:25 RP__: yes, we can treat it as an special case. Aug 02 13:25:29 dongxiao: you can always add a comment about it being dynamically added to PACKAGES Aug 02 13:28:00 RP__: OK, I will add it:) Aug 02 14:06:04 Morning All Aug 02 14:06:46 gm Aug 02 15:04:02 ReaperOfSouls: are you around? Aug 02 15:38:05 RP__: arm core-image-minimal completed Aug 02 16:25:51 pidge: morning Aug 02 16:28:16 sgw: hey, are my connman test and siteinfo bits in your queue yet? :) Aug 02 16:29:05 I am about to send an email, we are wrapping up M3 and I am going over requests now. There will be a 24-48 hour delay while I catch up. Aug 02 16:29:47 k Aug 02 16:34:54 sgw: ping Aug 02 16:35:09 tomz1: pong Aug 02 16:36:16 sgw: the other day you mentioned a problem you had seen regarding do_rootfs and busybox - do you remember what the problem was? Aug 02 16:38:21 Yeah, it was related to bug 1295 I think, which is fixed now Aug 02 16:39:15 sgw: great, thx! Aug 02 17:44:55 fray: ping Aug 02 17:45:44 hello Aug 02 17:46:46 fray: I'm debugging an issue with hob that run 2nd build using bitbake now I'm getting this /home/jzhang/yocto-latest/scripts/bitbake: line 86: 21266 Segmentation fault PSEUDO_BINDIR=$PSEUDOBINDIR PSEUDO_LIBDIR=$PSEUDOBINDIR/../lib/pseudo/lib PSEUDO_PREFIX=$PSEUDOBINDIR/../../ PSEUDO_DISABLED=1 $PSEUDOBINDIR/pseudo $BITBAKE $@ Aug 02 17:46:46 do u know what can trigger this from pseudo? Aug 02 17:47:16 since it's a segfault.. it's likely a problem in pseudo or the libc.. Aug 02 17:47:33 are you using the latest head-of-tree yocto? there was a bug that could cause a segfault about 2 weeks ago Aug 02 17:48:00 fray: yes it's very up-to-date, which I pulled down yesterday... Aug 02 17:48:46 fray: do u have an updated tree that you can do a quick test against hob usage? Aug 02 17:49:23 I don't.. can you set your ulimit -c unlimited take a core and see where it's blowing up? Aug 02 17:49:50 it'll be in pseudo, libpseudo or python Aug 02 17:50:13 hmmm x86_64/qemu does not boot now anyone seing it with oe-core Aug 02 17:50:50 since it dies before init. I suspect something simple might be wrong Aug 02 17:50:51 fray: I'll give it a try... Aug 02 17:50:54 like wrong ld.so name Aug 02 17:51:04 in INTERP section Aug 02 17:51:25 there are pending patches for the ld.so names and such.. I don't know if they've gone in yet Aug 02 17:52:10 I am more interested in knowing what broke it Aug 02 17:53:14 because oe-core (and yocto by extension) requires non-standard /lib paths (i.e. arbitrary base lib directory names) to exist.. so everything has to be dynamically generated.. Aug 02 17:53:29 if we'd just use the standard /lib for 32-bit and lib64 for 64-bit.. then no special patching would be required Aug 02 17:53:56 the patch that was created looks through the multilibs and should be able to generate a table based on the current system configuration Aug 02 17:54:46 dont we follow LSB ? Aug 02 17:54:58 does LSB dictate the multilib ? Aug 02 17:55:04 it should as I think Aug 02 17:55:34 we have a configuration that follows the LSB, but oe-core by default does not and requires arbitrary directories Aug 02 17:56:02 that probably is not what we should do then Aug 02 17:56:10 we should try to follow LSB Aug 02 17:56:15 that could simplify things Aug 02 17:56:29 since gcc and friends kind of converge to LSB Aug 02 17:57:43 there is only x86-64 which we should worry in oe-core as of now Aug 02 17:57:55 others are still okay with the defaults Aug 02 17:58:20 so I dont see any issue following LSB norms when we do multilib Aug 02 17:59:11 jzhang: what version of the tree are you using? Aug 02 17:59:20 jzhang: there was a fix for this issue I believe Aug 02 18:01:19 http://git.pokylinux.org/cgit/cgit.cgi/poky/commit/?id=5fdc8ab37e11781112e74f93f6c420ecb303fa88 Aug 02 18:01:39 msm: I just pull down the latest poky master yesterday which I believe if there's a fix should contains it... Aug 02 18:03:20 as I expected this is the problem Aug 02 18:03:30 init.sysvinit has this Aug 02 18:03:41 [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2] Aug 02 18:03:51 but ld.so is in /lib Aug 02 18:03:58 Khem: ping Aug 02 18:04:05 sgw: yes Aug 02 18:04:28 so some patch changed the defaults in gcc Aug 02 18:05:01 khem, when we do multilibs the default will be to use the lsb style naming.. Aug 02 18:05:03 but defaults in root file systems are still same Aug 02 18:05:10 khem, I am rolling through the back log and need a sanity check on Dmitry's patch, was that in reaction to the arm/thumb failures and is it still needed? oe thead subject: eglibc: fix build for armv4 machines Aug 02 18:05:28 but a lot of folks seem to want "/lib32" and "/lib64" instead of simply "/lib" and "/lib64" Aug 02 18:05:34 sgw: do u have patchwork url handy Aug 02 18:05:46 another group has requested "/lib" and "/lib32" (lib32 being hte i586 libraries) Aug 02 18:05:49 it's a real bloody mess Aug 02 18:06:03 fray: who are this group ? Aug 02 18:06:26 actually if someone does not care about backward compatibility then it will be different set Aug 02 18:06:37 khem no Aug 02 18:06:44 khem, existing oe users Aug 02 18:06:50 khem: but I can try and find it Aug 02 18:06:52 I think multilib is for sake of letting preexiting binary run as it is Aug 02 18:07:00 there is a large crop of them that expect "/lib" to always be the primary ABI Aug 02 18:07:54 sgw: I found it Aug 02 18:08:07 http://patches.openembedded.org/patch/8893/ Aug 02 18:08:13 yes this patch is needed Aug 02 18:08:19 to support armv4 Aug 02 18:08:24 khem, thanks Aug 02 18:08:32 I did this patch so :) Aug 02 18:09:04 * fray notes he's getting swamped with stuff.. Aug 02 18:09:07 fray: I think that goes well with what we have in oe Aug 02 18:09:15 khem, does your have patch headers? Aug 02 18:09:25 sgw: probably not Aug 02 18:09:43 Ok Aug 02 18:09:45 I need to fix the /bin/sh dependency somehow.. (see oe-core list for context) and I need to get to the arm tunings and get those corrected.. (or someone else needs to step in and try to resolve them) Aug 02 18:09:52 but its recorded in glibc bugzilla Aug 02 18:09:56 whats there right now will work, but last I checked it wasn't right Aug 02 18:10:16 msm: I just verified my tree contains that patch, but my usage is a little different from the cml bitbake, I'm running build from hob (bitbake ui), which allows me to do more than one build using bitbake, the segfault always happens on the 2nd build which I suspect pseudo is in some weird state after the 1st bitbake run... Aug 02 18:10:26 khem, thanks Aug 02 18:10:34 fray: I think we have to really make multilib be an addon I think Aug 02 18:10:36 jzhang did you get a core? Aug 02 18:10:40 to get it working properly Aug 02 18:10:52 but problem will come with x86/x86-64 Aug 02 18:10:58 where both will contend for /lib Aug 02 18:10:59 fray: yes, trying to look into it... Aug 02 18:11:13 thats the thing, multilib shouldn't have to be anything special.. the multilib build stuff works about 90% right now.. that last 10 we need to fix.. and we're getting better Aug 02 18:11:14 a bad start to use /lib always in oe Aug 02 18:11:53 khem, I can't control others.. but at WR we'll be using the LSB defaults for our library paths.. Aug 02 18:12:04 if a customer changes them, then they will be in unsupported territory Aug 02 18:12:27 fray: the path to pseudo should be what? Aug 02 18:12:33 fray: yes you will be sane Aug 02 18:13:15 tmp/sysroots/x86_64-linux/usr/bin/pseudo Aug 02 18:13:16 fray: but then we have to break backward compatibility in oe Aug 02 18:13:22 to get on LSB Aug 02 18:13:36 in yocto we can do that, we just can't do it in oe-core.. there is too many complainers Aug 02 18:13:56 and they see no reason to do it.. there is also a large group who don't want "/usr" to exist either, so that has to keep working Aug 02 18:14:31 sgw: actually the patch is here that you should import Aug 02 18:14:36 5bcd2b8a09ce8d5b7aa8ae47443f7e76ca2fe5c1 from oe.dev Aug 02 18:14:41 that patch has headers too Aug 02 18:15:05 jzhang you can see what the core came from if you run "strings" on the core file.. near the top should be at least part of the argv0 for whatever crashed Aug 02 18:15:08 khem thanks Aug 02 18:15:36 (you used to be able to run file and it would tell you, but that has been flaky or no longer functional for a while now) Aug 02 18:17:17 khem, that does not have a SOB line for the patch, just your name Aug 02 18:17:30 heh SOB line Aug 02 18:17:30 sgw: yes Aug 02 18:17:44 literal meaning is nicer Aug 02 18:18:18 http://sourceware.org/bugzilla/show_bug.cgi?id=12097 Aug 02 18:18:26 fray: from gdb I'm getting #0 0x080a948f in sqlite3VdbeExec (), from strings I got: CORE Aug 02 18:18:26 CORE Aug 02 18:18:27 python Aug 02 18:18:27 python /home/jzhang/yocto-latest/bitbake/bin//bitbake -R conf/hob.local.conf -t Aug 02 18:18:27 CORE Aug 02 18:18:27 CORE Aug 02 18:18:27 FLINUX Aug 02 18:18:27 IS_VALUE (value)ALUE (value)' faarning: inux-libc-headers_2.6.37.2.bb Aug 02 18:18:28 LINUX Aug 02 18:18:28 CORE Aug 02 18:18:29 CORE Aug 02 18:18:30 FLINUX Aug 02 18:18:35 has the patch in it but I guess we did not SOB patches back then Aug 02 18:18:56 khem right Aug 02 18:19:00 almost a year old Aug 02 18:19:02 jzhang whats the full back trace? Aug 02 18:19:09 sgw: you can add it Aug 02 18:19:12 sqlite3 could be python or pseudo Aug 02 18:21:50 this is the patch thats causing it Aug 02 18:21:51 http://git.openembedded.org/cgit.cgi/openembedded-core/commit/?id=036faf66c3889cd8bf4cd3c9b97c80f008f3c6e2 Aug 02 18:23:02 fray: http://pastebin.com/m1GrpZJg Aug 02 18:23:04 I think the patch is correct Aug 02 18:23:12 but its half done Aug 02 18:23:32 * khem writes to ml Aug 02 18:24:06 galak: hi Aug 02 18:24:10 jzhang darn.. it's incomplete.. Aug 02 18:24:19 galak: did you get your gcc query sorted Aug 02 18:24:26 do you know if it loaded the libraries and assorted elements? Aug 02 18:24:40 (from the strings command, it looks like it could have been python that blew out, not pseudo) Aug 02 18:25:31 fray: how can I test this "do you know if it loaded the libraries and assorted elements?" Aug 02 18:25:50 khem: not really, since I'm still confused what is going on with SYSTEMLIBS_DIR Aug 02 18:26:09 quit gdb, reload it and capture the output.. ;) Aug 02 18:28:17 fray: this happens when I try to do the 2nd build so bitbake, pseudo, etc should have been used and behaved once, please note, the 2nd build is not a fresh start of bitbake and pseudo but just whatever the state of them left with after the 1st build, I think that's the key... Aug 02 18:29:11 sgw: ping Aug 02 18:29:11 are you re-running the bitbake command the second time, or does the hob thing just fire off more tasks? Aug 02 18:29:21 the latter Aug 02 18:29:23 galak: hi Kumar Aug 02 18:29:42 sgw: hi Aug 02 18:29:49 sgw: I didn't see any comments on this patch: Aug 02 18:29:51 image-mklibs.bbclass: Add powerpc64 arch support Aug 02 18:32:16 galak: Hm, I thought RP__ was going to comment on that, fray might also have some input on that one. Aug 02 18:32:36 sgw: hmm, it seemed pretty trivial ;) Aug 02 18:37:51 fray: we had talked about galak's patch, what was your concern with this one? Aug 02 18:39:56 sgw which patch, I need to refersh my memory Aug 02 18:40:41 fray: galak's powerpc64 from a few days ago image-mklibs.bbclass was one of them. Aug 02 18:41:22 mklibs case it should be fine Aug 02 18:41:46 it was one of the others that wasn't right.. I think RP already commented on the others Aug 02 18:41:55 Ok, will grab that one up. Aug 02 18:42:38 (note, this has nothing to do with his patch, but I suspect image-mklibs.bbclass is incorrect, since the value of dnamic_loader="/lib/ld.so.1".. it really should be using a similar table to eglibc and the location dynamic to base_libdir Aug 02 18:42:39 yeah, the FPU / soft-float one is what RP commented on Aug 02 18:44:07 fray: fyi, the sqlite3 shouldn't related to python since I used it to load the core file and it reports back nothing.... Aug 02 18:46:00 galak: OK, pulling the image-mklibs, but I think the other 2 rely on the soft-float discussion, correct? Aug 02 18:47:04 sgw: sort of, one is soft-float the other really depends on how multilib is suppose to work for 32-bit vs 64-bit going forward Aug 02 18:47:27 fray says RP wants separate files for 32 vs 64 so we can drop 4/5 for now Aug 02 18:47:36 yes Aug 02 18:47:50 I have another patch to tune/arch-powerpc64.inc to bring it in sync with tune/arch-powerpc.inc Aug 02 18:49:25 galak: Ok Aug 02 19:11:53 fray: ping Aug 02 19:48:55 khem: ping Aug 02 19:51:46 yes Aug 02 19:52:24 just unearthed your strace / sigmask patch request from 7/13, is that still a valid request? Aug 02 19:52:39 yes Aug 02 19:53:01 Ok, I will build it against both uclibc and eglibc Aug 02 19:53:04 hang on Aug 02 19:53:17 ok Aug 02 19:53:55 is it same as 60d91ffc6367fe11ced5890240c6b65ada66621e Aug 02 19:55:14 Khem, yes, I would have spotted that if I had gotten that far! Aug 02 19:55:21 sorry to bother you with that one. Aug 02 20:29:43 sgw: you should use patchwork for this stuff Aug 02 20:29:50 it makes life lot easier Aug 02 20:30:15 and then you can update the list of patches as they get applied Aug 02 20:30:24 that can give you fair idea Aug 02 20:36:16 Khem: It's been on my list for 1.2 timeframe, I also want to look at gerrit, which could allow more people to participate in the review/ack process, if I understand it correctly. It's just been finding time for that. Aug 02 20:37:12 khem: on a different note, what's the status if the linaro gcc patches in oe-core relative to the 7.11 release of Linaro? Aug 02 20:37:36 oe-core does not get them Aug 02 20:37:39 they are in meta-oe Aug 02 20:39:50 Ah, ok I thought at one point you did, maybe that's it, I think we suggested it not be in oe-core, so how uptodate is the meta-oe patch set? Aug 02 21:04:28 I was looking into image and config creator ... may I know is it done? Aug 02 21:04:52 and if yes from where I can get its getting started Aug 02 21:22:27 hi zeddii Aug 02 21:23:21 when I try to build linux-korg, it also tries to build linux-yocto Aug 02 21:30:07 Noor: we're light on documentation for the image creator at the moment, can you be more explicit with your request. Are you looking for user help? Struggling to even launch? Trying to look at code? Aug 02 21:32:41 incandescant: basically need to see how it works and wanna try Aug 02 21:33:12 Noor: are you using the master branch of Poky? Aug 02 21:34:42 if so you can just use the wrapper script. Once you've sourced oe-init-build-env run hob Aug 02 21:34:58 incandescant: looking at https://wiki.yoctoproject.org/wiki/BitBake/GUI ... is bitbake -t xmlrpc -u hob does the trick Aug 02 21:35:10 just trying to figure it out where I can find it Aug 02 21:35:20 is it on poky or yocto Aug 02 21:35:35 Noor: sure, but the wrapper script is the proven/tested way to run it Aug 02 21:36:01 it's developed in upstream BitBake and pulled into our Poky repository for Yocto Aug 02 21:36:15 the entry point is bitbake/lib/bb/ui/hob.py Aug 02 21:36:58 incandescant: thanks Aug 02 21:37:17 Noor: np, if you have further questions feel free to ask Aug 02 21:37:39 the active development is occurring on the bitbake-devel mailing list with frequent patch submissions Aug 02 21:43:15 incandescant: thanks Aug 02 22:26:10 khem: ping Aug 02 22:38:19 sgw: yes Aug 02 22:38:29 re. linaro Aug 02 22:38:50 I have posted updates to meta-oe for both 4.6 and 4.5 in last couple of days Aug 02 22:39:43 khem: thanks for that info Aug 02 22:40:07 so its pretty recent Aug 02 22:40:19 khem: I am building oe-core/uclibc and encountering problems, when was your last world or core-image sato Aug 02 22:40:22 I usually do update once in couple of months for 4.5 Aug 02 22:40:32 and for 4.6 it could be a bit more frequesnt Aug 02 22:40:50 sgw: yes I am seeing coreutils failures Aug 02 22:41:24 sgw: coreutils is failing due to an artifact of autconf adding /usr/local/lib to search libdir Aug 02 22:41:41 and then QA complains that there are host path contamination Aug 02 22:42:25 this does not show up in eglibc builds because this code never gets executed with eglibc since the function exists so it never hits the other path Aug 02 22:42:50 I havent fixed it yet Aug 02 22:42:56 what errors do u see Aug 02 22:43:03 is it something different than coreutils Aug 02 22:43:28 I have made core-image-sato to build on all supported arches not long ago Aug 02 22:43:32 libxt was missing a couple of depends Aug 02 22:43:33 but oe-core moves darn quick Aug 02 22:43:39 ah Aug 02 22:43:49 I think I sent a patch for that didnt I Aug 02 22:43:53 libiconv I needed to do a cleansstate Aug 02 22:44:01 ok Aug 02 22:44:07 libiconv was updates Aug 02 22:44:10 updated Aug 02 22:44:12 Maybe means it needed a pr bump or something? Aug 02 22:44:32 dont know but sometime sstate also gets stuff wrong Aug 02 22:45:00 RPM is also failing on an undefined ref to xmalloc/xstrdup/... Aug 02 22:45:06 but PR bump would help to virtually cleansstate Aug 02 22:45:13 RPM hmmm Aug 02 22:45:17 havent tried that Aug 02 22:45:30 I usually use opkg Aug 02 22:45:43 package backend Aug 02 22:45:44 ah, ok Aug 02 22:45:54 but I can look into rpm thing Aug 02 22:45:56 I have all 3 packagers enabled Aug 02 22:46:00 sure Aug 02 22:46:47 so rpm is a problem that you have not fixed yet right ? Aug 02 22:48:08 I have not yet fixed, I can if you want me to look into it. Aug 02 22:48:24 sure go ahead Aug 02 22:48:40 since it might take me time I have stuff piled up before Aug 02 22:49:28 Ok. Aug 02 22:53:55 ok ppc build fine now Aug 03 01:10:12 :q! Aug 03 01:38:20 jzhang:: no quit allowed here :) **** ENDING LOGGING AT Wed Aug 03 02:59:57 2011