**** BEGIN LOGGING AT Tue Nov 22 02:59:58 2011 Nov 22 11:07:03 :-) Nov 22 11:07:33 sgw: have you already returned back from Brazil ? Nov 22 11:32:07 otavio: he has but he's sleeping now! Nov 22 11:32:25 * RP__ wishes he could track down this pkgconfig dependency issue Nov 22 11:32:37 RP__: heh the trip is indeed exausting Nov 22 11:32:55 RP__: it was nice to met him :-) Nov 22 11:33:07 otavio: He mentioned you'd talked :) Nov 22 11:33:32 otavio: Its a shame I couldn't be there but its a long trip from Europe Nov 22 11:33:54 RP__: yes; quite long ... mostly from anywhere :P Nov 22 11:34:32 RP__: but I hope to meet you next year if I am able to go to ELC or other event in Europe Nov 22 11:35:00 RP__: pkgconfig issue? Nov 22 11:35:18 RP__: I found a qt issue with the generated pkgconfigs Nov 22 11:35:26 otavio: just seeing some weird errors on the autobuilder Nov 22 11:35:41 RP__: they have Libs.private pointing to /usr/lib Nov 22 11:35:46 otavio: I should be at both ELC-E in Europe and ELC in the US Nov 22 11:36:06 otavio: That should be ok since pkgconfig should add in the sysroot? Nov 22 11:36:59 RP__: not really; it cases some link issues difficult to find specially when using with sdk Nov 22 11:37:42 RP__: ofthenly we have people that use the sdk and also use the machine to regular develop and if a lib is missing on sdk it links against host one and this hides the missing lib Nov 22 11:39:21 RP__: in this case is better to get a linking problem then it linking against host libs Nov 22 11:39:38 otavio: The SDK sets up the pkgconfig sysroot environment variable thats needed though? Nov 22 11:39:56 RP__: what do you mean? Nov 22 11:40:00 otavio: We've been working to the point where we don't have to hack the living daylights out of the .pc and .la files Nov 22 11:40:54 otavio: export PKG_CONFIG_SYSROOT_DIR=/media/build1/poky/build/tmp/sysroots/qemux86 Nov 22 11:41:08 otavio: The SDK sets up that into the environment so pkgconfig does the right thing Nov 22 11:41:22 RP__: ahh yes this is done, of course Nov 22 11:41:40 RP__: but the problem is that, for example, qmake takes Libs.private in account Nov 22 11:41:57 RP__: and in case of qt, it explicitly puts an -L/usr/lib there Nov 22 11:42:00 otavio: but shouldn't that get prefixed with the SYSROOT_DIR Nov 22 11:42:24 its its not being, that sounds like a problem with pkgconfig Nov 22 11:42:47 RP__: yes but it ends up being a fallback to missing libraries Nov 22 11:43:27 RP__: and this is wrong IMO; we want SDK libraries to be the only ones to be used Nov 22 11:43:47 otavio: what exactly is falling back to /usr/lib? Nov 22 11:43:48 RP__: otherwise you can end up with ugly and difficult to figure out bugs (as I had) Nov 22 11:43:50 pkgconfig? Nov 22 11:43:58 RP__: gcc but due this info Nov 22 11:44:06 RP__: on linking Nov 22 11:44:15 otavio: its passing -L/usr/lib to the compiler? Nov 22 11:44:21 RP__: yes Nov 22 11:44:35 otavio: right, that shouldn't be happening Nov 22 11:44:44 otavio: still sounds like a pkgconfig issue though Nov 22 11:44:53 RP__: no Nov 22 11:45:02 RP__: libs.private is passed as is Nov 22 11:45:11 RP__: the problem is the generated .pc file from qt Nov 22 11:45:30 otavio: how is the .pc file being read? Nov 22 11:45:46 RP__: I did: sed -i 's,-L/usr/lib ,,g' on sysroot from sdk and it fixed the issue Nov 22 11:45:53 RP__: on the .pc files of it Nov 22 11:47:39 otavio: I can understand how that would hide the problem but it doesn't mean the /usr/lib there is incorrect Nov 22 11:47:59 otavio: Somehow that -L/usr/lib is getting out of the .pc file without the sysroot prefix being added Nov 22 11:48:07 otavio: So the real bug is how is that happening? Nov 22 11:48:11 RP__: it seems wrong for me. Nov 22 11:48:18 RP__: ok; let me paste an example Nov 22 11:48:21 hold on Nov 22 11:51:20 RP__: http://paste.debian.net/146614/ Nov 22 11:51:39 RP__: if you look at Libs.private you'll find a hardcoded /usr/lib Nov 22 11:52:02 RP__: this is not the sdk (which is rebuilding now) but from sysroot ... but the problem is the same Nov 22 11:52:59 otavio: The Lib.private line is just totally wrong :/ Nov 22 11:53:06 otavio: but what I said still stands Nov 22 11:53:07 RP__: yes Nov 22 11:53:16 otavio: -L/usr/lib there is fine Nov 22 11:53:25 RP__: that's what I said; it is wrong Nov 22 11:53:40 RP__: no; it causes linking bugs Nov 22 11:53:43 RP__: I had problems Nov 22 11:53:48 otavio: Its wrong for different reasons, the sysroot paths shouldn't be there Nov 22 11:53:54 RP__: I needed to hack it to get it fixed Nov 22 11:54:11 otavio: Can you please try and listen to what I'm saying Nov 22 11:54:51 RP__: .. go ahead Nov 22 11:55:01 otavio: Those lines get read out that file by a command like "pkg-config --static --libs" Nov 22 11:55:22 otavio: If I run that command against that file, I'd expect to see the line as its written there Nov 22 11:55:37 RP__: yes Nov 22 11:55:39 RP__: right Nov 22 11:56:03 RP__: and? Nov 22 11:56:07 otavio: however if I run "PKG_CONFIG_SYSROOT_DIR=/foo/bar/ pkg-config --static --libs" I'd expect every -L there to get prefixed with /foor/bar Nov 22 11:56:15 otavio: I'm trying to type as fast as I can Nov 22 11:56:34 * otavio test Nov 22 11:58:01 RP__: I am waiting the build to finish to test ... Nov 22 11:58:09 otavio: ok Nov 22 11:58:14 RP__: but in this case the expanded paths ought to not be there Nov 22 11:58:30 otavio: Right. As I said, its broken but for different reasons Nov 22 12:01:50 otavio: btw, we ship a pkg-config with the sdk for the reason that some versions of pkg-config have bugs in the sysroot code Nov 22 15:11:36 otavio: good morning, yes I returned my yesterday afternoon. Nov 22 15:26:38 sgw: nice :-) have you enjoyed the trip Nov 22 15:27:56 It was long and they lost my bag, but found it and it arrived late (it's was ok since I was heading home). Nov 22 21:06:28 otavio: ping Nov 22 21:21:23 is there any reason why on one machine under one user all my WHITELIST vars are getting pulled into my signature? Nov 22 21:21:37 FILE TMPDIR PATH SHELL USER etc Nov 22 21:21:43 all in my sigdata Nov 22 21:24:17 msm: they are whitelisted Nov 22 21:24:28 thats a problem, none of those should be in teh signature Nov 22 21:25:14 right Nov 22 21:25:24 its so weird that its just happening under jenkins on ubuntu Nov 22 21:25:38 it does not even happen if run this as a normal user on the same machine Nov 22 21:26:50 stuff like this Nov 22 21:26:50 changed items: set(['STAGING_DIR_HOST']) Nov 22 21:26:51 List of dependencies for variable S changed from set(['PR', 'PV', 'BRANCH']) to set(['PR', 'PV', 'TMPDIR', 'BRANCH']) Nov 22 21:26:58 lets just add in TMPDIR Nov 22 21:27:02 just for my jenkins build Nov 22 21:27:07 not for my user Nov 22 21:27:15 depending on those shouldn't be an issue unless the var itself gets pulled in, afaik Nov 22 21:28:04 BB_HASHBASE_WHITELIST still has all those values listed also Nov 22 22:17:14 kergoth_: should do_rootfs be sstate-cacheable? Nov 22 22:17:31 all the image generation do_rootfs steps seem to depend on ${TIME} Nov 22 22:17:47 images are always constructed from scratch Nov 22 22:18:00 afaik anyway Nov 22 22:18:03 * kergoth_ shrugs Nov 22 22:34:04 kergoth_: seems like they could be archived with 'inherit deploy' Nov 22 22:34:18 anyways side point =) Nov 22 22:34:38 images aren't constructed in the do_deploy task, but otherwise yeah Nov 22 22:35:25 ahh makes sense Nov 22 22:35:56 could see do_rootfs constructing the root filesystem and do_deploy constructing the image, and use deploy.bbclass to get it from workdir into deploy_dir_image Nov 22 22:36:07 separating rootfs construction from image creation might not be a bad idea anyway Nov 22 22:36:08 * kergoth_ shrugs Nov 22 22:41:55 kergoth_: too much stuff to do ={ Nov 22 22:42:23 indeed Nov 22 22:42:40 all the rootfs/image bits could some love, really, lots of remnants from early days Nov 22 22:45:11 kergoth_: we calculate hashes in one line in siggen.py right? Nov 22 22:46:39 i've taken to dumping the 'data' we are using to calculate the hashes to files for all recipes/tasks Nov 22 22:46:51 and comparing *every* dump against two machines Nov 22 22:46:58 i would think that would be enough to isolate issues Nov 22 22:48:43 the vars/values should already be in the siginfo files. you can load them into a python interpreter and poke around, they're just pickled python objects Nov 22 22:48:47 afaik, anyway Nov 22 22:50:09 yes Nov 22 22:50:22 its just a PITA to work with Nov 22 23:12:12 kergoth_: the minimal image data used for the hash is actually different when using sstate-cache Nov 22 23:12:20 some stuff gets added Nov 22 23:12:21 its weird Nov 22 23:12:44 some variables are expanded in the sstate-cache version Nov 22 23:28:25 can I call python functions defined in a bbclass from a shell function defined in the same bbclass? Nov 22 23:28:59 getting LexToken errors, wondering if this might be why... Nov 22 23:31:54 nope. shell calls shell, python calls python or shell (via exec_func). shell can't call python Nov 22 23:32:23 I was looking for some kind of inline python syntax Nov 22 23:32:28 which I think I've seen before... Nov 22 23:32:43 ${@} can be used in shell just as it is in variable definitions Nov 22 23:34:54 hrm... Nov 22 23:34:58 ${@build_syslinux_cfg()} Nov 22 23:35:13 that results in an error: NameError: name 'build_syslinux_cfg' is not defined Nov 22 23:35:29 you can only call functions from there which are defined with 'def', not those defined in the task syntax Nov 22 23:35:36 def foo(d): Nov 22 23:35:41 rather than python foo () { Nov 22 23:35:49 ah Nov 22 23:35:53 (yes, it'd be nice to consolidate these into a single form) Nov 22 23:36:13 ideally any python function would be available the way def'd functions are, and would allow argument specifications Nov 22 23:36:27 thanks kergoth_, just knowing the limitations helps a lot Nov 22 23:36:31 np Nov 22 23:36:31 I can work within them Nov 22 23:36:48 I did read the bitbake manual, but didn't find it in there Nov 22 23:37:09 something to note in my doc gaps for when I have some time to kill Nov 22 23:37:27 rule of thumb: use def for python functions which aren't tasks, so they can be called from elsewhere without exec_func, but use the standard syntax if it's a task Nov 22 23:38:03 of course, the other case when you need the standard syntax is when a task expects it to be runnable via exec_task (e.g. functions listed in SSTATETASKS or PACKAGEFUNCS) Nov 22 23:38:06 I assume "def myfunc()" can't call a "python do_something()" function? Nov 22 23:38:13 s/exec_task/exec_func/ Nov 22 23:38:19 it can, if it uses bb.build.exec_func() to do it Nov 22 23:38:47 but of course you can't get a return value from those, it truly is an exec Nov 22 23:40:29 so I presume ${@bb.build.exec_func(do_something)} could work from shell? Nov 22 23:41:29 kergoth_, I changed python to def for a function, but the parser is very unhappy with me. Nov 22 23:41:37 that wouldn't expand to anything Nov 22 23:41:53 because, again, exec_func can't return a value Nov 22 23:42:03 you probably forgot to remove the trailing } Nov 22 23:42:12 def'd functions are deliniated by indentation, not braces Nov 22 23:43:24 right.... that helped Nov 22 23:45:07 now I seem to have lost access to the global "d" in the newly def'd function Nov 22 23:47:00 def'd functions are python syntax, you need to define its arguments Nov 22 23:47:08 16:33 def foo(d): Nov 22 23:47:09 16:33 rather than python foo () { Nov 22 23:47:16 then pass d when you calli t Nov 22 23:51:48 and shell as access to "d" ? Nov 22 23:51:54 erm, no nm Nov 22 23:51:56 I get it Nov 22 23:52:02 the ${@ syntax does Nov 22 23:52:48 right **** ENDING LOGGING AT Wed Nov 23 02:59:57 2011