**** BEGIN LOGGING AT Fri Jul 11 02:59:58 2014 Jul 11 06:20:05 morning Jul 11 09:24:27 hi Jul 11 09:25:17 JaMa: what's the current state of SDK support in meta-qt5 master? Is it supposed to work now? Jul 11 09:56:34 danielki: I'm not using SDK, ask otavio Jul 11 09:57:12 ok thanks Jul 11 09:57:17 otavio: ^^ Jul 11 11:23:41 hello everybody Jul 11 11:24:14 my udevd aborts launch due to a missing epoll_create1 Jul 11 11:24:14 gm Jul 11 11:24:27 I have an initramfs Jul 11 11:24:54 udevd[915]: error creating epoll fd: Function not implemented Jul 11 11:25:35 my system image is basically a totally stripped down initramfs Jul 11 11:26:51 "strings /lib/libc.so.6 |grep poll" does give me a epoll_create1() result Jul 11 11:27:06 so I don't know why it's not working Jul 11 11:54:49 issue solved, was a kernel config item Jul 11 12:25:32 otavio: what's the current state of SDK support in meta-qt5 master? Is it supposed to work now? Jul 11 17:34:31 Hello. I updated some stuff recently (I synced with the Gumstix repo) and now I am noticing some weird things. I looks like do_rootfs has become lazy: it does not re-run when I try to make a target unless it things the input has changed. However, I have scripts called by ROOTFS_POSTPROCESS_COMMAND which would result in changes. Can I force do_rootfs without cleaning and re-compiling everything? Jul 11 17:34:56 I saw something mentioned about this in the reference manual Jul 11 17:35:04 But my problem remains Jul 11 17:40:16 I really would appreciate a tip on this if anybody has one. Jul 11 17:42:04 bryan__: there's a patch on the list to fix that exact problem, but in the meantime you could force it with -C rootfs or -f -c rootfs Jul 11 17:42:04 either will force do_rootfs to re-run Jul 11 17:42:25 Excellent! Thank you! Jul 11 17:42:49 np Jul 11 17:55:21 I have another question. My ROOTFS_POSTPROCESS_COMMAND scripts worked fine before, but now they complain that the folder (for the rootfs) does not exist. Jul 11 17:55:30 I use ${IMAGE_ROOTFS} for the path Jul 11 17:55:57 in the warning message in the terminal, the path is correct (and I can check that it does indeed exist) Jul 11 17:56:23 Is it possible that it is trying to call my scripts *before* making rootfs, instead of after? Jul 11 17:58:01 I may be mis-interpreting the error. It actually says: WARNING: Function /home/bryan/yocto/createStartupLinks.sh /home/bryan/yocto/build/tmp/work/duovero-poky-linux-gnueabi/gumstix-console-image/1.0-r0/rootfs doesn't exist Jul 11 18:11:30 Am I mis-using the ROOTFS_POSTPROCESS_COMMAND variable? Jul 11 18:29:09 Has anyone successfully shared target sstate between different hosts? Jul 11 18:29:20 It doesn't seem to be a possibility anymore Jul 11 18:47:31 ROOTFS_POSTPROCESS_COMMAND simply does not seem to allow me to call a shell script anymore. Has anybody else seen this? Jul 11 19:47:13 rburton: Hi Jul 11 19:47:30 rburton: need help on the code for it? I think I found a good way for it Jul 11 19:52:17 kergoth: If you could offer me another pointer I would appreciate it. I have tried most everything I can think of and I cannot get my post do_rootfs scripts to run. I want to invoke them using ROOTFS_POSTPROCESS_COMMAND in my local.conf file, but no luck. Jul 11 19:52:24 otavio: just using an anonymous function ran at the wrong place, going to try a PACKAGEFUNC now Jul 11 19:56:10 hm still doesnt' work Jul 11 20:01:19 otavio: so my code is adding extra rdepends. do you have anything working that does that? Jul 11 20:01:36 it appears that prepending to PACKAGEFUNCS and appending to rdepends isn't good enough Jul 11 20:01:37 yes Jul 11 20:01:53 PACKAGESPLITFUNCS =+ Jul 11 20:02:15 in reality, a packagefunc is more appropriate, as its not to do with splitting :/ Jul 11 20:02:25 http://privatepaste.com/bcfca932e0 Jul 11 20:02:37 so =+? Jul 11 20:02:45 ahh Jul 11 20:02:52 the 'read_...' call Jul 11 20:02:56 this is required Jul 11 20:03:12 ah Jul 11 20:18:08 heads up, I've mailed out a proposed patch to add pseudo 1.6.0, and I've sent pidge a URL for the tarball. Jul 11 20:18:23 There may well be issues, so the proposed patch leaves 1.5.1's recipe in-tree in case people need to revert. Jul 11 20:20:16 seebs: I see the URL, but... issues in getting to it. Jul 11 20:20:30 whee Jul 11 20:20:44 What I like about computers and IT infrastructure is how they are so completely predictable and reliable. Jul 11 20:21:23 rburton: works? Jul 11 20:21:26 Hmm. I was able to download it from this machine (which is outside our VPN). Jul 11 20:22:12 seebs: just replied :) Jul 11 20:22:45 Oh, if you mean scheduling-wise, rather than technically: No hurry from my point of view. It looks like a complete task on my end when I send the email, then I can mark it done and look like I worked this week. Jul 11 20:24:53 otavio: doesn't work, confused, doubting everything right now Jul 11 20:25:54 rburton: see my patch Jul 11 20:26:02 i have :( Jul 11 20:26:09 rburton: show yours Jul 11 20:26:42 otavio: poky-contrib ross/intel Jul 11 20:26:59 the bb.data.explode call didn't help Jul 11 20:33:39 oh Jul 11 20:33:46 let me find gitweb Jul 11 20:35:43 rburton: it needs to be in PACKAGESPLITFUNCS Jul 11 20:36:00 rburton: check the order in package.bbclass Jul 11 20:36:07 rburton: it needs to be done before Jul 11 20:36:19 tried that Jul 11 20:36:48 and reading the code i can't see why the rdepend munging in fix_symlinks will work and mine that runs a bit earlier won't Jul 11 20:38:53 +do_compile[postfuncs] += "add_xorg_abi_depends" Jul 11 20:39:08 this is wrong Jul 11 20:39:12 input seems right Jul 11 20:40:05 rburton: ^ Jul 11 20:45:21 you can see i was experimenting and just committed what i had when i needed to switch branch Jul 11 20:46:13 the style in input didn't work fwiw Jul 11 20:49:17 seebs: ok, have the binary. was PEBKAC Jul 11 20:49:48 k Jul 11 20:51:04 halstead: could you sync the releases/pseudo dir? Jul 11 20:52:55 It's totally possible that the new pseudo will break stuff, but the biggest likely-breaking change was the fchmodat stuff, which was already backported. Jul 11 20:55:37 seebs: I wonder if pushing on friday is a good idea then? :D Jul 11 20:56:01 I have no idea. I mostly wanted to get the change out where people could try it and look at it. Jul 11 20:56:17 'kay. Jul 11 20:56:19 In my defense, most of this has been in use at least somewhat for a while, the Tizen people had to go to 1.6 for the xattr support. Jul 11 20:56:33 The biggest changes to the code since a stable version are that I ported the xattr stuff to Darwin. Jul 11 20:57:02 I use Darwin as a sort of bitrot catcher, because llvm is much better at static analysis than gcc is, and because it is just different enough to provide interesting test cases. Jul 11 20:57:06 pidge, Sure. Jul 11 20:57:15 But the Darwin xattr stuff will have, I am pretty sure, no effect at all on the Linux side. Jul 11 20:57:24 Although it did reveal a typo. Jul 11 20:58:46 ... I note also, I maintain the Darwin port because I know perfectly well that the moment I decide I don't need to and start making changes without testing them there, someone will come along and announce a successful port of oe-core and bitbake to OS X, except that pseudo doesn't work. Jul 11 20:59:11 pidge, Syncing. Jul 11 20:59:27 seebs: ha, nice logic Jul 11 21:00:12 seebs: sadly the port of everything else to osx isn't that simple :/ i keep on meaning to put the gnu userspace first on my mac's $PATH and seeing what breaks. Jul 11 21:00:16 pidge, pseudo 1.6.0 is live. Jul 11 21:00:50 I use MacPorts on my Mac, and for reasons unknown to me, it installed a version of "file" which mostly threw strange errors about format string mismatches and invalid byte encodings, but did not actually produce better results for any file I knew of. Jul 11 21:01:23 i've got brew and most of the gnu tools installed, but i wasn't brave enough to eg replace bsd rm with gnu rm Jul 11 21:01:30 didn't want to break osx bootup ;) Jul 11 21:01:46 The big problem would be that most of their basic utilities are now resource-fork aware, and a lot of GNU utilities won't be. Jul 11 21:02:01 though i do spend half of my time in a terminal swearing at my fingers always typing rm foo -f Jul 11 21:02:25 And you can sort of overcome that because now the resource fork is just a special extended attribute (for handling of which their syscalls have different parameters), so if the utilities know about the xattr calls, they can probably work with cp -a, but... Jul 11 21:03:21 yeah exactly Jul 11 21:03:50 i guess step 1 of oe-core on osx would be to have a symlink farm of the gnu tools first on $path using the non-g-prefixed names Jul 11 21:04:12 but only set that $path when doing oe stuff Jul 11 21:04:59 Yeah. Jul 11 21:05:29 Anyway, I keep pseudo working there and it finds and fixes bugs. Jul 11 21:05:42 I think there's two or three cases where I really was using uninitialized values sometimes which got fixed. Jul 11 21:43:55 Another failure: Jul 11 21:43:56 framebuffer fsl-image-machine-test@imx28evk (1/5) ERROR: Recipe u-boot-fslc is trying to change PV from 'v2014.07' to 'v2014.01'. This will cause do_package_write_* failures since the incorrect data will be used and they will be unable to find the right workdir. Jul 11 21:44:00 framebuffer fsl-image-machine-test@imx28evk (1/5) ERROR: Function failed: read_subpackage_metadata Jul 11 21:44:28 RP: Any idea how I can debug it? Jul 11 21:45:12 otavio: in not merging that last patch, I think there is a subtle bug that has been introduced Jul 11 21:45:28 -addtask do_package_qa after do_package before do_build Jul 11 21:45:28 +addtask do_package_qa after do_packagedata before do_build Jul 11 21:45:33 is the likely fix Jul 11 21:45:48 otavio, fwiw, i've seen similar issues with a couple of other packages. re-running bitbake i dont see it Jul 11 21:45:49 Oh nice! Such nice merge uh?! Jul 11 21:46:22 kroon: even worse ... Jul 11 21:46:41 kroon: this means we can have other corner cases hidden Jul 11 21:59:11 RP: please let's coordinate better this kind of change next time Jul 11 21:59:26 RP: I am working on fixes all day just due that Jul 11 22:04:07 RP: i can confirm that fix helps me Jul 11 22:04:35 RP: another failure Jul 11 22:04:37 framebuffer fsl-image-machine-test@imx28evk (1/5) error: cannot open Packages database in .../build-framebuffer/tmp/sysroots/x86_64-linux/var/lib/rpm Jul 11 22:04:40 framebuffer fsl-image-machine-test@imx28evk (1/5) rpmdb: .../build-framebuffer/tmp/sysroots/x86_64-linux/var/lib/rpm/__db.002: No such file or directory Jul 11 22:04:43 framebuffer fsl-image-machine-test@imx28evk (1/5) error: db_init:.../build-framebuffer/tmp/work/x86_64-linux/rpm-native/5.4.14-r0/rpm-5.4.14/rpmdb/db3.c:1144: dbenv->open(2): No such file or directory Jul 11 22:06:36 RP: any idea? Jul 11 22:07:00 framebuffer fsl-image-machine-test@imx28evk (1/5) ERROR: Index creation command '.../build-framebuffer/tmp/sysroots/x86_64-linux/usr/bin/createrepo --update -q .../build-framebuffer/tmp/deploy/rpm/all' failed with return code 135: Jul 11 22:07:04 framebuffer fsl-image-machine-test@imx28evk (1/5) Bus error Jul 11 22:07:23 rerunning it reduces the errors but does not fix Jul 11 22:09:52 is that with db6? Jul 11 22:10:04 rburton: uh? Jul 11 22:10:16 rburton: tip of master Jul 11 22:10:17 the rpm failures Jul 11 22:10:40 rburton: does it work for you? Jul 11 22:10:58 not even sure i have rpm enabled right now Jul 11 22:16:21 otavio: hmm, I don't know much about that one. Have you had any other master builds recently? Jul 11 22:20:32 rburton, otavio: I pushed a fix for that dependency problem Jul 11 22:20:41 RP: let me rebuild Jul 11 22:21:00 RP: yes I did Jul 11 22:21:09 RP: 4 days ago or so Jul 11 22:22:12 RP: this new builder builds it hourly Jul 11 22:22:42 framebuffer fsl-image-machine-test@imx28evk (1/5) ERROR: Index creation command '.../build-framebuffer/tmp/sysroots/x86_64-linux/usr/bin/createrepo --update -q .../build-framebuffer/tmp/deploy/rpm/all' failed with return code 135: Jul 11 22:22:46 framebuffer fsl-image-machine-test@imx28evk (1/5) Bus error Jul 11 22:23:01 I am not a heavy user of rpm so no clue how to debug it Jul 11 22:23:18 rburton: rootfs builds fine for you? Jul 11 22:25:41 otavio: 7 Jul 11 22:25:48 otavio: long time no see :) Jul 11 22:25:52 * Marex emerges Jul 11 22:25:57 Marex: :-) Jul 11 22:26:05 otavio: lucky number :) Jul 11 22:26:15 Marex: hehe bastard! Jul 11 22:26:17 ;-) Jul 11 22:26:53 Marex: indeed; well I was not hoping Brazil to win ... I was not expecting it to play so badly though Jul 11 22:27:46 otavio: well, let's not polute this channel with such off-topic stuff, there are more than 7 off-topic messages here ... Jul 11 22:28:53 btw. I was actually curious, can yocto spit out a toolchain with QtE libs/headers for me as-is or do I need any additional layer for that ? Jul 11 22:28:57 otavio: I need to sleep I'm afraid. I'd suggest a build from scratch to ensure this isn't fallout from the other problem :/ Jul 11 22:29:13 otavio: the autobuilder did build things cleanly with master fwiw Jul 11 22:29:25 RP: a sigbus in RPM looks rather strange, doesn't it ? Jul 11 22:29:42 RP: no sstate? Jul 11 22:29:56 RP: without reusing sstate you mean? Jul 11 22:30:13 Marex: meta-toolchain-qte Jul 11 22:30:27 otavio: okay, do you have that built and/or isntalled already ? Jul 11 22:30:35 Marex: nops Jul 11 22:30:37 otavio: you're triggering SIGBUS in RPM ? Jul 11 22:30:45 Marex: seems so Jul 11 22:30:49 cute Jul 11 22:31:50 otavio: check the env of the command, run the command by hand with GDB attached ? Jul 11 23:17:01 RP: from scratch seems to build fine Jul 11 23:17:10 RP: I will keep building the other machines **** ENDING LOGGING AT Sat Jul 12 02:59:58 2014