**** BEGIN LOGGING AT Thu Nov 17 02:59:57 2011 Nov 17 09:28:49 morning all Nov 17 09:42:54 morning all Nov 17 09:43:41 hi RP__ Nov 17 09:44:47 bluelightning: btw, do we have bugs open on those setscene failures? If not we probably should have :/ Nov 17 09:45:05 RP__: not yet, will file Nov 17 09:45:24 bluelightning: thanks. I'd hate to forget about them. Nov 17 09:46:22 RP__: actually we do, 1721 covers them thanks to the autobuilder and Jiajun's sharp eye Nov 17 09:46:53 bluelightning: ah, cool. Could you add any further details we've figured out then please Nov 17 09:50:01 bluelightning: at least its doing the right thing now and rebuilding the missing pieces from source Nov 17 09:50:17 yes :) Nov 17 09:50:30 * RP__ notes he didn't clean sstate on the autobuilder run he just fired off Nov 17 09:51:12 * RP__ has crazy ideas for a replacement UI for knotty Nov 17 09:51:31 RP__: does it involve ncurses? Nov 17 09:51:40 bluelightning: yes and no :) Nov 17 09:51:51 bluelightning: not in the way the previous attempt did Nov 17 10:23:13 bluelightning: http://autobuilder.yoctoproject.org:8010/builders/nightly-arm/builds/171/steps/shell_44/logs/stdio is odd :/ Nov 17 10:24:14 RP__: I never really know where to start looking when you get dependency errors at the do_rootfs stage Nov 17 10:24:43 bluelightning: whats interesting in this case is it was mainly a sstate build but it did build dbus Nov 17 10:25:06 why that wasn't good enough to work for the rootfs, I don't know Nov 17 10:25:18 what does the dbus rpm actually provide I wonder? Nov 17 10:25:43 bluelightning: good questions. I think we might have a "recipe" to reproduce this there though Nov 17 10:29:23 thinking about it, I can imagine this being caused by an upgrade to dbus in the absence of PR bumps or some other mechanism to get everything that depends upon it rebuilt Nov 17 10:29:42 where the .so version changed that is Nov 17 10:34:20 bluelightning: Could be except I don't recall a dbus version change recently Nov 17 10:34:35 no Nov 17 10:34:59 hmm Nov 17 11:55:53 bluelightning: so my test didn't reproduce :( Nov 17 11:56:23 RP__: doh... do you still have the old tmpdir? Nov 17 11:56:35 bluelightning: I moved it out the way Nov 17 11:56:56 ok, are you able to query the dbus package with rpm to see what it provides? Nov 17 11:57:11 bluelightning: ah, you mean on the autobuilder Nov 17 11:57:20 bluelightning: I should be able to get into that, yes Nov 17 11:57:24 ah yes I just realised, it was the ab not your machine Nov 17 12:06:41 bluelightning: the provides are wrong in the package (it does exist) Nov 17 12:08:58 RP__: how is that happening...? is the FILERPROVIDESLIST info not being saved somewhere? Nov 17 12:29:00 bluelightning: rpmdeps isn't able to find its magic file Nov 17 12:29:07 bluelightning: I have a fix Nov 17 12:29:15 excellent! :) Nov 17 12:33:10 RP__: error: magic_load( again? Nov 17 12:35:20 ant_work: yes, but in do_package Nov 17 12:35:54 * RP__ has expedited the fix and we'll see what the autobuilder does with it Nov 17 12:39:28 of course it will now invalidate most of the sstate cache so the original issue won't show up. I'm pretty sure this was the problem though Nov 17 12:59:34 hi Nov 17 12:59:57 i have a question about eclipse plugin Nov 17 13:00:35 i'm able to deploy and debug an application on specific hardware, using an autotools project Nov 17 13:01:10 but when i try with a more complex example, continaing 2 libs and 2 programs Nov 17 13:01:28 i have no clue how to deploy all binaries at once on the target Nov 17 13:01:40 there is a way to do that with yocto eclipse plugin ? Nov 17 13:03:45 captainigloo: A good question for jzhang, she'll be awake in a few hours Nov 17 13:05:52 RP__: ok thanks Nov 17 13:07:01 btw, i'm not using yocto but angstrom and oe-core, and the eclipse yocto plugin works pretty well :) Nov 17 13:07:49 captainigloo, any good instrcutions on setting it up? Nov 17 13:10:26 Crofton|work: i should write some blog ... Nov 17 13:10:43 but basically i build an agstrom image Nov 17 13:10:50 and an angstrom sdk Nov 17 13:11:30 after that I just followed the documentation provided by yocto Nov 17 13:56:11 captainigloo: I'm pleased its working - it was designed to be pretty generic Nov 17 14:21:25 RP__: with #1465 try to pass -b full path to .bb Nov 17 14:22:09 RP__: full path or at least relative Nov 17 14:25:34 JaMa: full patch and relative path worked Nov 17 14:26:14 worked to reproduce it or worked to fetch it? Nov 17 14:27:17 and when you're looking on local files fetcher I think that #1710 is more critical as it sometimes passes wrong files without notice Nov 17 14:27:45 RP__: it didn't fail, it did what was expected Nov 17 14:28:16 JaMa: yes, I'm just going over my open bugs trying to figure out where I'm at with them Nov 17 14:28:20 ok I'll attach more info to it when I'm home Nov 17 14:28:34 1465 isn't going anywhere as I can't reproduce :( Nov 17 14:51:22 JaMa: I just replied to #1710 - can't reproduce it either :/ Nov 17 14:52:43 ah :/, thanks Nov 17 14:54:45 JaMa: something odd is going on here, the two issues could be related Nov 17 14:55:25 yes and iirc koen had seen same issue with his setup Nov 17 14:55:30 so at least it's not just me Nov 17 14:56:33 if you want access to such broken setup let me know :) Nov 17 14:56:40 JaMa: :) Nov 17 14:56:45 but I'll try to debug here when I find time Nov 17 14:56:48 JaMa: must be something to do with layering somehow Nov 17 14:57:04 or PREMIRRORs?? Nov 17 14:57:10 JaMa: possibly Nov 17 14:58:12 JaMa: can you see if *all* file:// urls are ending up in DL_DIR or just some? Nov 17 14:59:43 right now it seems like even downloads/buildfix.patch is gone from my DL_DIR, weird Nov 17 15:00:37 could you try if you can reproduce it if you put that file to downloads yourself? Nov 17 15:00:54 like if something else is fetching file with same filename from http:// ? Nov 17 15:05:29 JaMa: now that does break... Nov 17 15:09:34 JaMa: its an "easy" fix if you look at the local.py fetcher code Nov 17 15:10:27 (disable the dldir cod) Nov 17 15:16:54 bluelightning: autobuilder.yoctoproject.org:8010/builders/nightly-x86/builds/229/steps/shell_14/logs/stdio - any ideas? Nov 17 15:17:10 something not relocatable in pulseaudio? Nov 17 15:27:10 RP__: localfetch with -b seems to behave strange on newpath = bb.utils.which(filespath, path) Nov 17 15:27:45 JaMa: "strange"? Nov 17 15:29:14 is this expected? http://paste.pocoo.org/show/509252/ Nov 17 15:29:46 bluelightning: Its a missing dependency. Could you look into that one please as I suspect you can find the right place within qt to either disable it or add the dependency? Nov 17 15:30:07 * bluelightning looks Nov 17 15:30:12 bluelightning: (pulseaudio didn't build until after qt4) Nov 17 15:30:39 ah sorry adding debug to which() itself Nov 17 15:32:27 JaMa: Its the relative paths in FILESPATH which are confusing things Nov 17 15:32:49 JaMa: I'm going to guess the current working directory is different with -b Nov 17 15:33:30 JaMa: What is FILE_DIRNAME set to? Nov 17 15:35:34 JaMa: My guess is that we need to set FILE to a fully resolved path within bitbake Nov 17 15:36:31 RP__: http://paste.pocoo.org/show/509259/ Nov 17 15:36:46 yes working directory is somewhere else Nov 17 15:37:05 JaMa: and FILE is a relative path? Nov 17 15:37:15 while running if os.path.exists(next) Nov 17 15:37:25 JaMa: I'd guess your layer config or scripts somehow place you in a different environment to mine Nov 17 15:39:12 RP__: FILE and FILE_DIRNAME from -e -b path/to/zlib.bb http://paste.pocoo.org/show/509261/ Nov 17 15:40:08 JaMa: open lib/bb/parse/parse_py/ConfHandler.py and BBHandler.py and change bb.data.setVar('FILE', fn to use abs_fn Nov 17 15:40:17 two changes Nov 17 15:40:22 then see if that looks better Nov 17 15:42:42 RP__: | WARNING: Looking for item: 'configure.ac' with cwd: '/OE/downloads' Nov 17 15:42:58 this is just os.getcwd() while running that local fetch Nov 17 15:43:16 that explains why os.path.exists() was returning false everytime Nov 17 15:43:48 and I can reproduce this even without PREMIRRORs Nov 17 15:45:34 JaMa: I'd love to know what in your setup triggers the different cwd Nov 17 15:46:07 with your change abs_fn it's still /OE/downloads but looks for right file because of abs Nov 17 15:46:25 JaMa: right. I think that fix makes sense in its own right Nov 17 15:46:40 JaMa: I'm still curious why the different cwd though Nov 17 15:47:17 and this could explain why I had extra files in downloads Nov 17 15:47:17 lib/bb/fetch2/__init__.py: save_cwd = os.getcwd(); Nov 17 15:47:17 lib/bb/fetch2/__init__.py: bb.note("Unpacking %s to %s/" % (file, os.getcwd())) Nov 17 15:47:32 if I had wrong cwd while executing it Nov 17 15:47:51 is there easy way to trace python cwd changes? Nov 17 15:57:12 RP__: hm cwd is changed in fetch only http://paste.pocoo.org/show/509268/ Nov 17 16:08:14 RP__: we're calling base_do_fetch like this: WARNING: exec_func_python(func: 'base_do_fetch', runfile: '/OE/shr-core/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/zlib-1.2.5-r1/temp/run.base_do_fetch.29088', cwd: '/OE/shr-core/downloads') Nov 17 16:12:08 JaMa: hmm, which would come from base.bbclass:do_fetch[dirs] = "${DL_DIR}" Nov 17 16:12:48 yes Nov 17 16:13:05 JaMa: I was looking at this during the unpack task... Nov 17 16:13:08 I have no idea how it could work for you Nov 17 16:13:36 JaMa: cp to workdir happens at unpack time, not fetch Nov 17 16:14:08 cd you mean? Nov 17 16:14:30 | NOTE: Unpacking /OE/shr-core/downloads/configure.ac to /OE/shr-core/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/zlib-1.2.5-r1/ Nov 17 16:14:33 | cp: cannot stat `/OE/shr-core/downloads/configure.ac': No such file or directory Nov 17 16:14:45 because without cwd changed by do_fetch, do_unpack fails.. Nov 17 16:17:09 JaMa: no, I meant cp. The cp happens during do_unpack Nov 17 16:17:18 so it can find the right files... Nov 17 16:17:39 ah no.. it fails in do_unpack again because it's looking for relative paths with cwd set to S Nov 17 16:17:44 at least here Nov 17 16:18:19 exec_func_python(func: 'base_do_unpack', runfile: '/OE/shr-core/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/zlib-1.2.5-r1/temp/run.base_do_unpack.29283', cwd: '/OE/shr-core/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/zlib-1.2.5-r1') Nov 17 16:18:30 that is WORKDIR Nov 17 16:19:02 ok, so the question is therefore how is my system managing to work with relative paths at all :/ Nov 17 16:19:20 there must be something about my environment which stops them getting into FILE Nov 17 16:20:46 ah righ WORKDIR.. and I was even using bitbake from poky to minimize diff Nov 17 16:54:44 gah, src_distribute*.bbclass could use some tlc Nov 17 16:54:47 * kergoth looks into that Nov 17 17:22:32 RP__: btw something like "Convert to use direct access to the data store (instead of bb.data.*Var*())" in oe-core should be done for bitbake too? because ie BBHandler.py seems inconsistent in bb.data.setVar and data.setVar Nov 17 17:44:29 JaMa: it should, yes Nov 17 17:46:24 JaMa: I was thinking that earlier too Nov 17 18:17:12 Any objection to separating the logic that determines what patches we have and should be applied out from do_patch, keeping the latter focused on just applying the patches? Nov 17 18:17:57 kergoth: what's your objective, out of interest? Nov 17 18:21:57 kergoth: you mean into a function that do_patch would call? Nov 17 18:38:36 RP__: yeah Nov 17 18:38:45 bluelightning: making src_distribute suck less Nov 17 18:39:01 kergoth: ah ok Nov 17 18:39:14 primarily for gpl compliance, but I'd like to emit series files to be a nicer citizen Nov 17 18:39:22 a pile of patches isn't all that useful lacking info about the order to apply them in :P Nov 17 18:39:42 kergoth: a function is reasonable Nov 17 18:39:50 I often wished for something that would just quickly verify all the files referred to in SRC_URI without unpacking, not sure if what you're proposing would help with that Nov 17 18:40:18 (by verify, I mean verify the presence of) Nov 17 18:40:21 isn't that sort of what Fetch.checkstatus is for? Nov 17 18:40:34 though i guess thats more about the fetch than the unpack Nov 17 18:40:38 well, last I checked do_fetch does not fail if a local file is missing Nov 17 18:41:12 hmm, really? that's definitely a bug if so Nov 17 18:41:35 might have to check again, I made a note of it quite some time ago with the intent to come back to it Nov 17 18:42:22 * kergoth nods Nov 17 18:53:09 You know, src_distribute*.bbclass are really rather confused about their identity and purpose. it really tries to exist both for mirror population and for license compliance concerns, but it falls short. I think the two are really rather different. for a mirror, you want things as is, unmodified, relatively flat, and you want everything, even files that aren't necessarily applied for this srcrev, most likely Nov 17 18:53:28 but for compliance, it'd be nice to provide series files, potentially even a shell script to unpack and patch the thing if we want to be really nice Nov 17 18:53:59 also the src_distribute usage of exec_func isn't ideal for performance, especially when you have a kernel with 500 patches or something Nov 17 18:54:14 * kergoth hacks on a new more specific class Nov 17 18:57:09 * kergoth ponders Nov 17 19:34:00 kergoth_: Do we really need bbclass support for mirroring these days? Nov 17 19:36:50 I doubt it, I expect most just grab DL_DIR Nov 17 19:37:25 all the more reason to drop src_distribute* in favor of something specific. which means the _local separation is unnecessary, since the whole point of all that was to facilitate population of remote locations for things like mirroring Nov 17 22:38:16 kergoth: Just noticed your last comment - I agree FWIW Nov 17 22:38:45 fray: Are you around? I think I've a pseudo issue occurring on the autobuilder :( Nov 17 22:39:28 which comment again? lost my scrollback Nov 17 22:39:30 heh Nov 17 22:39:38 too many irc clients, i should start using a proxy again Nov 17 22:40:03 kergoth: The one about dropping src_distribute in favour of something specific Nov 17 22:40:06 ah, right Nov 17 22:40:08 k Nov 17 22:55:02 I dunno if fray is around, but I'm here sporadically. What are you doing to that poor, defenseless, pseudo this time? Nov 17 22:56:18 seebs: I'm seeing this in the logs "pseudo: dir err : 70662358 ['/srv/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-arm/build/build/tmp/work/armv5te-poky-linux-gnueabi/dbus-1.4.12-r7/package/usr/lib/pkgconfig'] (db 'no path') db mode 0100755, header mode 040700 (unlinking db)" Nov 17 22:56:39 hmm Nov 17 22:56:54 seebs: the directory referred to there has some odd permissions it shouldn't have acquired (the 0700) Nov 17 22:57:02 Hmm. Nov 17 22:57:32 here now Nov 17 22:57:33 Okay, what that means is that somehow the database thought that ino 70662358 was a plain file. Nov 17 22:57:52 And then it came in with the path .../pkgconfig as a directory, which means that the file existed, but never got deleted. Nov 17 22:58:21 seebs: Could the permissions somehow "leak" from one to the other? Nov 17 22:58:39 Since it had no path in the db, that's... well, it's not common, usually. I think you can get it if you have a file descriptor open before pseudo starts, then you start pseudo and do a f*() op on the fd. Nov 17 22:58:58 Shouldn't -- as it says, it just drops the db's entry in that case. Nov 17 23:01:36 I am not sure how effective the database sanity check stuff would be in tracking something like this, but if it can be reproduced, we can probably get it. Nov 17 23:02:15 seebs: ok, thanks. I was a little unsure which way around to read that log message but that helps, thanks Nov 17 23:02:28 I would love to spend some time working on the log messages. Nov 17 23:02:29 seebs, could something that tried to open pkgconfig (before it was created as a directory) have triggered pseudo to think it was a file? Nov 17 23:02:58 If something had tried to talk to it before by that name, we'd have had the name and the right mode in the db. Nov 17 23:03:10 So something else had that inode, probably a fair while back. Nov 17 23:03:12 hmm... Nov 17 23:03:13 Which is... odd. Nov 17 23:03:20 ya.. Nov 17 23:03:29 FWIW the trouble I'm seeing is that rpmdeps --provides isn't listing the pkgconfig dependencies under some circumstances I've yet to fully understand Nov 17 23:03:43 and it would involve files being created outside pseudo context :/ Nov 17 23:03:48 /would/could/ Nov 17 23:03:59 RP__ rpmdeps --provides should be executing the pkgconfig helper script.. Nov 17 23:04:06 you should be able ot run that seperately and diagnose it that way Nov 17 23:04:38 (I'm looking for the file quickly) Nov 17 23:04:40 fray: well, running the command manually lists the dependency. Running it as part of do_package does not Nov 17 23:04:51 odd Nov 17 23:05:23 tmp-eglibc/sysroots/x86_64-linux/usr/lib/rpm/pkgconfigdeps.sh Nov 17 23:05:49 arg1 is --provides or --requires Nov 17 23:05:55 stdin is a list of files to look at Nov 17 23:06:31 (BTW I didn't realize this was even running before.. so I'm not surprised it might be broken) Nov 17 23:06:57 I'd check to see if the PATH is reasonable when it's being called from rpmdeps within packages.bbclass Nov 17 23:07:56 PKG_CONFIG_LIBDIR may need to be set -- and isn't right now [in that script] to match the ${LIBDIR} values and such.. Nov 17 23:08:12 also there is a PKG_CONFIG_SYSROOT_DIR value in the latest versions.. dunno if that is something useful or not for us Nov 17 23:08:57 Hmm.. wonder if setting PKG_CONFIG_SYSROOT_DIR='=' would work.. ;) (since -I= and -L= are both supported) Nov 17 23:33:38 fray: running the task manually "magically" fixed things Nov 17 23:33:54 odd Nov 17 23:33:59 fray: so I'm at a bit of a loss as to why the dependency disappeared Nov 17 23:34:24 only thing I can think of is something environmental that is either being filtered or not based on the options to rpmdeps and such Nov 17 23:34:36 fray: You can see the end result on: http://autobuilder.yoctoproject.org:8010/builders/nightly-arm/builds/174/steps/shell_52/logs/stdio Nov 17 23:34:53 fray: I noticed dbus also lost its provides Nov 17 23:35:06 all provides -- or just pkgconfig ones? Nov 17 23:35:31 fray: just pkgconfig Nov 17 23:35:33 this is really odd -- I havne't seen anything like these errors in a -long- time Nov 17 23:35:48 could it be any of the new bitbake changes causing the variables to get lost? Nov 17 23:35:50 fray: earlier today I found all providers going missing which I fixed Nov 17 23:36:18 fray: that was fixed with http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=f2d077255d9ddf9b87e9a781b989bcce69047cf5 Nov 17 23:36:37 fray: no bitbake changes I'm aware of doing this. Its some kind of sstate issue as a build from scratch is fine Nov 17 23:36:44 ahh ya I saw that one go in.. Nov 17 23:36:57 fray: we have some issues with useradd.bbclass packages failing sstate installs Nov 17 23:37:02 did you check that all calls to rpmdeps define that.. also it might make sense to define the tmppath as well... not sure though Nov 17 23:37:11 it falls back to just compile them but the compiled versions seem broken Nov 17 23:37:27 fray: which other rpmdeps calls are there? Nov 17 23:37:48 not sure -- I would expect all of them to be located in packages.bbclass... so that may be the only one Nov 17 23:44:42 fray: It looks like at a certain point in the build the pkg-config code doesn't work and then later it does Nov 17 23:46:01 only two reasons I can think of.. environment variables getting confused -- or the wrong pkg-config being executed (or perhaps not being executed) ;) Nov 17 23:47:46 fray: How does rpm choose the execute this script? Nov 17 23:48:03 it's defined in the macros file Nov 17 23:48:14 just a sc Nov 17 23:48:53 let me find it Nov 17 23:49:36 usr/lib/rpm/macros.d/pkgconfig is the control file.. Nov 17 23:49:38 it lists: Nov 17 23:49:42 %__pkgconfig_provides %{_rpmhome}/pkgconfigdeps.sh --provides Nov 17 23:49:42 %__pkgconfig_requires %{_rpmhome}/pkgconfigdeps.sh --requires Nov 17 23:49:50 # Note: Used iff _use_internal_dependency_generator is non-zero. The Nov 17 23:49:50 # helpers are also used by %{_rpmhome}/rpmdeps {--provides|--requires}. Nov 17 23:49:53 has that though Nov 17 23:50:14 that the value is '2' Nov 17 23:50:33 hmm or is it.. Nov 17 23:51:16 ya.. verified.. it is '2' Nov 17 23:51:26 (in otherwords, it's setup to work) Nov 17 23:51:53 fray: ok, thanks. As far as I can tell pkg-config would be present and operable Nov 17 23:52:21 fray: and I can't account for why this would not work and then work Nov 17 23:53:07 'er.. huh Nov 17 23:53:13 rpmdeps might be broken.. Nov 17 23:53:27 there are a heck of a lot of hard coded values in tools/rpmdeps.c Nov 17 23:53:39 (in the rpm sources).. I cant tell if it's using them or the macros as I would have expected.. Nov 17 23:54:13 if it's using the local version, it may end up running the wrong version of this stuff.. i.e. running a host version Nov 17 23:54:22 #define _PKGCONFIG_PROVIDES "/usr/bin/find /usr/lib -name '*.pc' | /usr/lib/rpm/pkgconfigdeps.sh -P" Nov 17 23:54:22 static const char * _pkgconfig_provides = _PKGCONFIG_PROVIDES; Nov 17 23:54:22 #define _PKGCONFIG_REQUIRES "rpm -qal | grep '\\.pc$' | /usr/lib/rpm/pkgconfigdeps.sh -R" Nov 17 23:54:22 static const char * _pkgconfig_requires = _PKGCONFIG_REQUIRES; Nov 17 23:54:31 but that may not be what is executing.. Nov 17 23:56:04 Ignorning what I just found and assuming it's -not- running that code.. Nov 17 23:56:27 what it should be doing is looking for any files that have been "colored" (identified) as PKGCONFIG.. this is via the magic file.. Nov 17 23:56:51 if it finds one, then it will run the pkgconfig helper script as specified in the RPM macro set Nov 17 23:57:45 /* XXX all files with extension ".pc" are pkgconfig for now. */ Nov 17 23:57:45 else if (_suffix(s, ".pc")) Nov 17 23:57:45 ftype = "pkgconfig file"; Nov 17 23:58:00 that is the identification chunk.. it doesn't look at the mode at all.. Nov 17 23:58:06 (not sure any of that helps) Nov 17 23:59:07 fray: In all my tests this is behaving as it should :/ Nov 17 23:59:34 ok.. then all I can suggest is tmpdir madness, pkg-config madness, or environment madness.. none of which will be easy to track down.. Nov 17 23:59:46 at least in the tmpdir case, we can just pass the same define as other calls to rpm Nov 18 00:01:51 fray: I can't see how tmpdir would explain this Nov 18 00:03:29 fray: mips and arm failed on this, ppc and x86_64 + i586 did not Nov 18 00:03:32 in this case neither can I.. the system isnt creating tmp run files -- it's simply executing the offline script and capturing the results.. Nov 18 00:03:52 /lib directory names could be it -- if so that might explain things a bit.. Nov 18 00:04:06 i.e. host and target have differnet directory names -- thus pkg-config doesn't find them (target wise) and fails? Nov 18 00:04:15 are we setting PKG_CONFIG_LIBDIR during the do_package step? Nov 18 00:04:23 if not, setting that might resolve it Nov 18 00:04:27 we always export that I think Nov 18 00:04:37 I'd start with that Nov 18 00:04:53 but how would it be libdir? Nov 18 00:05:01 the above pattern doesn't match that Nov 18 00:05:16 PKG_CONFIG_LIBDIR == /usr/lib or /usr/lib64 Nov 18 00:05:40 if the host is lib64 and target is lib.. pkg-config could be misconfigured -- no environment variable means it's going to fall back and fail.. Nov 18 00:05:41 so we'd see this on everything but x86_64 and we don't Nov 18 00:05:56 the RPM script is setting PKG_CONFIG_PATH=.... itself.. Nov 18 00:06:25 wouldn't explain why this sometimes works for me and sometimes it isn't Nov 18 00:06:42 either it would always work or it just wouldn't Nov 18 00:07:07 ya.. environment is the only thing I can think of -- or again it's ending up with the wrong pkg-config Nov 18 00:08:18 fray: I did wonder if the directory permissions were getting screwed up in pseudo somehow and making the file non-readable Nov 18 00:08:31 as it would then skip it I think Nov 18 00:08:34 that could affect it for sure Nov 18 00:10:07 fray: Can I dump the database or do I need to shell into it? Nov 18 00:10:24 pseudo db? Nov 18 00:10:30 fray: yes Nov 18 00:10:44 you can, it's simply sqlite3.. just run that and point it at the pseudo files.db Nov 18 00:10:51 I don't rmember the proper sql query offhand though.. Nov 18 00:16:26 fray: theory doesn't seem to stack up as from a pseudo shell it looks ok Nov 18 00:16:40 'k Nov 18 00:16:59 one possible way to debug this is track the execs in pseudo.. Nov 18 00:17:05 (get pseudo to log them).. Nov 18 00:17:18 you may be able to trace rpm -> pkgconfigdepends.sh -> pkg-config Nov 18 00:18:11 [pid 15653] execve("/srv/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86-64/build/build/tmp/sysroots/x86_64-linux/usr/lib/rpm/pkgconfigdeps.sh", ["/srv/home/pokybuild/yocto-autobu"..., "--requires"], [/* 32 vars */]) = 0 Nov 18 00:18:21 so it is being called in my "good" case Nov 18 00:21:26 I forgot about this.. but you can enable pseudo logging (globally) and use the pseudolog program to review the logs.. Nov 18 00:22:38 I'm not sure though if logging captures exec/fork/etc calls.. I know it captures filesystem transactions.. Nov 18 00:22:44 (it's really a transaction log of the system) Nov 18 00:22:56 add "-l" to the initial pseudo call in the bitbake wrapper... Nov 18 00:22:59 fray: without a way to reproduce the bad case I'm stuck Nov 18 00:23:10 Hmm Nov 18 00:24:46 BTW during a build, is ${PN} valid -- i.e. can I pass it into pseudo during int he fakerootenv? Nov 18 00:25:03 fray: yes Nov 18 00:25:28 FAKEROOTENV = "PSEUDO_TAG=${PN} ...." so that should work and keep changing the value? Nov 18 00:25:42 fray: yes Nov 18 00:25:49 cool.. let me see if logging works then.. ;) Nov 18 00:30:13 I'm going to suggest we assume the state of the autobuilder got corrupted somehow and we try this again :/ Nov 18 00:30:29 yup Nov 18 00:30:31 see if it reproduces or it ifs just some corner case Nov 18 00:33:36 wow the pseudo log stuff is interesting Nov 18 00:34:01 18:29:50 python ping none: [mode 0000, -] python Nov 18 00:34:01 18:29:50 python op open: [mode 0766, r+] /dev/null Nov 18 00:34:01 18:29:50 python op stat: [mode 0775, -] /home/mhatle/git/oss/oe-core/meta/recipes-multimedia/pulseaudio Nov 18 00:34:01 18:29:50 python op open: [mode 0664, r] /home/mhatle/git/oss/oe-core/meta/recipes-multimedia/pulseaudio/pulseaudio_ Nov 18 00:34:01 0.9.23.bb Nov 18 00:34:03 .... Nov 18 00:34:17 it spends all of the time right at the beginning re opening/reading the .bb, bbclass files, etc.. Nov 18 00:34:53 BTW and there are time stmaps in the logging to tell you how long an operation or set of them took.. Nov 18 00:35:04 this looks like it might be useful to your optimizing exercise Nov 18 00:35:13 (I wish I had remembered this earlier..) Nov 18 00:36:13 and verified it -does- log execs Nov 18 00:36:53 interesting: Nov 18 00:36:53 18:29:51 /bin/sh op exec: [mode 0000, x] /bin/sed Nov 18 00:36:53 18:29:51 sed ping none: [mode 0000, -] sed Nov 18 00:36:53 18:29:51 sed op open: [mode 0444, r] /proc/filesystems Nov 18 00:37:04 why is pulseaudio looking at /proc/filesystems on my host? Nov 18 00:38:34 18:33:58 none none: [mode 0000, -] server 20392 exiting: handled 387677 messages in 19.0098 seconds Nov 18 00:38:43 pulseaudio install (before your libtool change) Nov 18 00:38:56 387677 messages in almost 20 seconds to process evrything.. Nov 18 00:58:22 fray: interesting indeed... Nov 18 00:59:53 fray: I wonder how much time waiting until after parsing before enabling pseudo would buy us... Nov 18 01:00:34 probably too late to enable at that point though Nov 18 01:00:58 anyhow I'd best sleep Nov 18 01:01:00 'night all **** ENDING LOGGING AT Fri Nov 18 02:59:57 2011