**** BEGIN LOGGING AT Wed Aug 03 02:59:57 2011 Aug 03 08:35:26 morning all Aug 03 08:37:32 hi RP__, all Aug 03 12:14:59 RP__: ping Aug 03 12:26:52 lianhao: pong Aug 03 12:32:03 RP__: I'm looking at a problem that when building lib64-libowl, somehow not only the lib64-eglibc, but also the eglibc both get built. Aug 03 12:32:42 when bitbake -g, 3 .dot files will be generated. What's the difference between the 3 files? Aug 03 13:24:52 lianhao: sorry, got distracted by other things :( Aug 03 13:25:02 lianhao: you want to look at the task-*.dot file Aug 03 13:25:24 The others show just depends and rdepends dependencies, the tasks based one is the most compelte Aug 03 13:25:41 lianhao: It sounds like some dependency somewhere isn't getting translated correctly Aug 03 13:26:20 RP__: So pn-.dot corresponds to depends, and package-*.dot corresponds to rdepends? Aug 03 13:26:50 lianhao: I think so. The original two date from before we had the upgraded dependency code in bitbake, I tend to ignore them Aug 03 13:27:00 task-*.dot is the one I'd always refer to Aug 03 13:27:14 * RP__ would consider removing the other two Aug 03 13:28:58 RP__: I think I found the problem dependency. util-macros-native DEPENDS on virtual/gettext, which in turn brings eglibc. Is it desirable or should it DEPENDS on something like virtual/gettext-native? Aug 03 13:50:41 lianhao: It should depend on virtual/${MLPREFIX}gettext Aug 03 13:52:58 RP__: why does the native depend on target gettext, not gettext-native? Aug 03 13:54:35 lianhao: native shouldn't depend on the target, that sounds like a bug Aug 03 13:55:31 RP__: so util-macros-native should DEPENDS on gettext-native, right? **** BEGIN LOGGING AT Wed Aug 03 14:05:28 2011 Aug 03 14:40:57 lianhao: yes Aug 03 14:49:41 Hi, I need baking help Aug 03 14:49:41 because "${libdir}/*.so.*" ends up in foo-dev I get... Aug 03 14:49:41 WARNING: QA Issue: foo rdepends on foo-dev Aug 03 14:49:41 What to I have to add to the recipe to get rid of that issue? Aug 03 14:51:19 holgerwrs: are you altering FILES at the moment? Aug 03 14:53:08 bluelightning: I did before, but I got rid of that, so currently: no Aug 03 14:56:41 holgerwrs: by default ${libdir}/*.so.* should be in foo, and ${libdir}/lib*.so goes in .dev Aug 03 14:56:46 that should be OK Aug 03 14:56:57 since the latter is usually a symlink Aug 03 14:57:40 bluelightning: it should, but sadly it doesn't Aug 03 14:58:04 bitbake -e foo | grep ^FILES may be informative Aug 03 14:59:22 morning all Aug 03 14:59:27 hi sgw Aug 03 15:05:33 hi sgw Aug 03 15:07:27 bluelightning: ok, thanks, it really was informative Aug 03 15:07:54 solved it Aug 03 15:08:02 hi RP__ Aug 03 15:19:18 sgw: I think I have a fix for #861 at least... Aug 03 15:19:59 That sounds like good news given how bad it hit the builds yesterday! Aug 03 15:36:13 fray: opinion on http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/ml4&id=b951f7dc6a44814fdbc060eb64a19c7d8ca5cec0 ? Aug 03 15:49:24 fray: ping Aug 03 16:28:05 Does anyone know about shell interpreter limits of 126 characters for #! ? I am seeing really strange behavior with perl-native and intltool-update with long #! paths to perl-native/perl Aug 03 16:29:06 sgw: seen the same thing Aug 03 16:29:14 sgw: not sure what the actual limit is Aug 03 16:29:22 msm: glad its not just me! Aug 03 16:29:50 i think i sent a patch to change intltool Aug 03 16:30:22 so it installs with the right perl shebang Aug 03 16:30:34 for the host Aug 03 16:30:35 msm: that patch is in Aug 03 16:30:57 msm: but the shebang path length is triggering the failure now Aug 03 16:31:35 -export PERL_virtclass-native = "/usr/bin/env perl" Aug 03 16:31:35 +export PERL = "/usr/bin/env perl" Aug 03 16:31:37 this one? Aug 03 16:31:43 im not sure if i sent it Aug 03 16:32:15 because i was not sure why the line above was not fixing the shebag to begin with Aug 03 16:32:41 Sorry not that one, the change in intltool to use perlnative Aug 03 16:32:49 and my other perlnative patch for all the other broken packages was not liked either Aug 03 16:33:19 i can send this patch to the list Aug 03 16:34:30 done if you want to give it a shot Aug 03 16:35:18 msm: that change is to intltool? The exports? That will get the host perl Aug 03 16:35:48 ya Aug 03 16:36:13 Is that what is needed to got back to the host's perl vs the perl-native? Aug 03 16:36:14 it effects the *installed* intltool scripts in sysroots/host Aug 03 16:36:27 for me, that fixed the installed tools Aug 03 16:36:47 intltool-{update,etc} to have a *working* shebang Aug 03 16:37:11 I am not sure, since we have had perl mis-match problems with host perl vs perl-native in the past (it seems to go back and forth). Aug 03 16:37:14 so sysroots/i686/usr/bin/intltool-update would not have a really long shebang Aug 03 16:37:28 right, I get that part. Aug 03 16:37:30 that line should only use the perl in the path correct? Aug 03 16:37:45 which would be the perlnative that was previously built Aug 03 16:37:50 within poky Aug 03 16:38:02 otherwise, im not 100% sure Aug 03 16:38:16 perlnative is installed in sysroots/i686/usr/bin/perl-native, which is not part of the path! Aug 03 16:38:21 what distro are you on? Aug 03 16:38:35 various depending on which machine I build (on purpose) Aug 03 16:38:54 i only see all these shebang issues on my older centos 5.5 box is why I asked Aug 03 16:39:02 sgw: well that is another problem.. Aug 03 16:39:09 Fedora and Ubuntu primarily Aug 03 16:39:13 doesnt inherit perlnative include the native perl in the path? Aug 03 16:39:30 seems not, maybe that's the problem. Aug 03 16:40:06 actaully lookint at it it does add the path Aug 03 16:41:07 This is back to the problem of things that use intltool need to inherit perlnative (already bounced right). Aug 03 16:41:31 i sent that patch in too =) Aug 03 16:41:57 but the powers that be did not want to add perlnative to every recipe Aug 03 16:42:07 they wanted another solution Aug 03 17:50:25 stupid question. is there anyway to stop parsing of a recipe and variable expansion, if you aren't actually using that recipe ? (I may not have said that clearly). Aug 03 17:51:15 zeddii: not that I know of short of moving it! Aug 03 17:51:25 thx. that was my assumption as well. Aug 03 17:51:39 git.kernel.org is either hosed or reeeealy slow and is making my life miserable ;) Aug 03 17:51:51 and there. .. it just responded. Aug 03 17:58:55 * zeddii just hacks it Aug 03 18:20:52 zeddii: BBMASK is your friend Aug 03 18:21:15 ooo. Aug 03 18:21:17 * zeddii goes to read Aug 03 18:21:58 indeed! Aug 03 18:22:07 thx khem Aug 03 21:15:43 sgw: You got my connman test fix in queue, yes? Aug 03 21:15:56 * Tartarus kicks pidgin for not being vim Aug 03 21:15:58 Tartarus: yes, my builds failed Aug 03 21:16:09 Not related to that change, I hope :) Aug 03 21:16:28 not with you change, but with the consolidated, I need to pick it apart I was about to send and found it. Aug 03 21:16:37 k Aug 03 21:17:09 sgw: If you have a minute, anything in http://git.openembedded.org/cgit.cgi/openembedded-core-contrib/commit/?h=trini/WIP-fix-build_cc-not-being-single-word&id=99c2e4faac16aff416aabc92c7582acddefa8599 make you scream? RP__, you too Aug 03 21:17:11 Or anyone else Aug 03 21:17:24 (and clearly, it needs to be broken up into a number of commits) Aug 03 21:17:49 and apt is a separate parallel make failure, just had that in my stash Aug 03 21:17:52 Is HOSTCC really used by every cml based buildsystem? Aug 03 21:19:20 yes Aug 03 21:19:44 It's what's used to build the bits to parse the .config file Aug 03 21:20:00 And since the kernel obeys it, everyone that copied it out does too Aug 03 21:20:33 * sgw sezs incoming! Aug 03 21:22:57 sgw: problem Aug 03 21:22:59 i'll reply Aug 03 21:23:07 Did I grab and old set? Aug 03 21:24:10 I grabed v2, I can resync with v3 Aug 03 21:25:10 It's just one patch out of sync, yeah Aug 03 21:25:21 my v2 branch was messed up, just noticed like 10min ago Aug 03 21:25:26 ok, maybe 20 now Aug 03 22:26:55 Tartarus: ping Aug 03 22:27:09 pong Aug 03 22:27:43 Tartarus: Did you try a nativesdk build (ie with meta-toolchain-gmae)? I just found that pkgconfig-nativesdk if failing Aug 03 22:27:53 just 'world' Aug 03 22:28:04 It's failing configure due to glib_cv_va_copy not being defined. Aug 03 22:28:05 what's failing, how/where? Aug 03 22:28:32 odd Aug 03 22:29:47 I was building MACHINE=qemuarm bitbake pkgconfig-nativesdk Aug 03 22:30:14 actaully the target was meta-toolchain-gmae, but it came down to that specific target Aug 03 22:47:53 it couldn't figure it out or ? Aug 03 22:48:00 don't have a good machine to check on atm Aug 03 22:58:14 Tartarus: it's both glib_cv___va_copy and glib_cv_va_copy for nativesdk Aug 03 22:58:32 what's the error tho Aug 03 22:58:34 pastebin pls Aug 03 22:59:23 from the configure log it's one line: Aug 03 22:59:26 | checking for an implementation of va_copy()... configure: error: in `/vol/1/sgw/builds/meta/tmp/work/x86_64-nativesdk-pokysdk-linux/pkgconfig-nativesdk-0.25-r0/pkg-config-0.25/glib-1.2.10': Aug 03 23:00:02 didn't see the fail bit :) Aug 03 23:00:51 here's more Aug 03 23:00:52 http://pastebin.com/fL92YwfX Aug 03 23:01:03 looking Aug 03 23:01:27 But, why doesn't it fail when actually cross compiling pkg-config Aug 03 23:01:49 nativesdk does things differently. Aug 03 23:01:53 Yeah Aug 03 23:02:06 But, can you bake pkgconfig for the target quick and see what it does there? Aug 03 23:02:45 without the copy in siteinfo correct Aug 03 23:03:05 correct Aug 03 23:10:50 hm.. how would you define this license (klibc) ? http://paste.debian.net/125036/ Aug 03 23:13:51 sgw: oh, can you pastebin the full failure log? or at least the top bits where it says what site files it loaded? Aug 03 23:14:50 Sure, do you want the config.log or the log.do_configure? Aug 03 23:14:59 log.do_configure\ Aug 03 23:16:54 http://pastebin.com/SfUcZFUn Aug 03 23:19:49 sgw, OK, so, hummm Aug 03 23:19:54 I bet on the target we don't re-use old glib Aug 03 23:20:19 digging Aug 03 23:20:55 ant__: Maybe verify with the author on that one, otherwise seems like GPL & BSD & MIT Aug 03 23:21:03 Tartarus: thanks Aug 03 23:21:13 sgw: For nativesdk we can or cannot get at our own other libs? I assume we can Aug 03 23:21:49 Hell, we even have glib-2.0-nativesdk already as a recipe Aug 03 23:22:02 sgw: ok, I'll ask hpa Aug 03 23:22:07 thx Aug 03 23:22:36 sgw: Not for popt, but that'd be trivial to fix Aug 03 23:22:40 That would be my suggestion Aug 03 23:22:49 I can clone and post but not build easily atm Aug 03 23:23:06 Tartarus: I can run a test build Aug 03 23:23:50 k, It'll be maybe 20min, starting a clone now Aug 03 23:36:34 sgw: http://git.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=trini/fixup-pkgconfig-nativesdk Aug 03 23:37:34 Ok, let me give it a spin Aug 03 23:38:08 Didn't, but probably should have, bumped PR on pkgconfig Aug 03 23:39:00 Ok will fix that Aug 03 23:39:45 k Aug 03 23:52:44 Tartarus: this seems to have introduced a dependency loop with pkgconfig-native in glib-2.0 and pkgconfig including glib-2.0 Aug 03 23:52:57 So that's why we do that :( Aug 03 23:53:14 OK, I'll whip up something else Aug 03 23:54:42 sgw: Can you real quick do a TCLIBC=uclibc and make sure pkgconfig-nativesdk still loads meta/site/common-glibc Aug 03 23:59:20 Tartarus: building now Aug 03 23:59:55 sgw: OK, there's a trini/update-siteinfo-round-2-v4 branch, assuming my guess is right. I imagine host uclibc will have more problems so I'm not overly worried about skipping putting this into meta/site/common-uclibc too Aug 04 00:06:14 Tartarus: so revert the popt change or keep that also? Aug 04 00:06:51 sgw: Drop the fixup-pkgconfig-nativesdk branch Aug 04 00:06:57 so drop popt change too Aug 04 00:07:55 Ok, just wanted to confirm Aug 04 00:34:02 Tartarus: still around? Aug 04 00:34:56 pong Aug 04 00:35:03 something else broke? Aug 04 00:35:54 uclibc failed still, it does not include the common-uclibc, it does include common-glibc, same with eglibc! I can patch it here directly. Aug 04 00:36:52 does glibc work? Aug 04 00:37:14 what do you mean? patching glibc-common? Aug 04 00:38:34 I mean with TCLIBC=glibc and v4 of the branch does pkgconfig-nativesdk build? **** ENDING LOGGING AT Thu Aug 04 02:59:57 2011