**** BEGIN LOGGING AT Tue Nov 08 02:59:57 2011 Nov 08 07:47:05 I have an issue building a "ext2.gz.u-boot" image for mpc8315erdb. the image file is not built but the link is there (broken). has anyone else had the same issue? Nov 08 08:24:04 good morning Nov 08 10:03:34 morning all Nov 08 10:04:49 morning Nov 08 13:09:45 gp Nov 08 13:15:00 RP? Nov 08 15:07:32 hi, is there a doc concerning SYSROOTPOSTFUNC, SYSROOTFUNC, SSTATEPOSTINSTFUNCS & co ? Nov 08 15:24:37 RP__: any problem with my patches for dhcp? Nov 08 15:24:59 RP__: they weren't acked/nacked or replied Nov 08 15:25:15 RP__: also libcap and device table changes Nov 08 15:25:20 otavio: sorry, I'll try and get to them shortly Nov 08 15:28:58 RP__: master-next also seems unused Nov 08 15:29:23 otavio: whilst master is broken its mind of a moot point :( Nov 08 15:29:34 (which is what I've been trying to fix) Nov 08 15:29:44 RP__: i see Nov 08 15:30:16 RP__: hi, I read your email concerning SYSROOTPOSTFUNC, SYSROOTFUNC, SSTATEPOSTINSTFUNCS : is there a place documenting these variables ? Nov 08 15:30:41 RP__: I'd like to push systemd onto oe-core; this is working fine in meta-oe and I've been using it on our images Nov 08 15:31:10 ericben: No, we're creating them for internal use by that class Nov 08 15:31:13 RP__: I got a class for easy use of it and also patches for few recipes adding it into a specific -systemd package. Nov 08 15:32:01 RP__: any concern about me preparing a branch with it? Nov 08 15:32:17 otavio: I'm not merging anything like that until things are more stable Nov 08 15:32:36 RP__: but are you against merging it? Nov 08 15:32:42 otavio: We have a load of half working bits that have merged which work for the original submitters but the remaining issues are getting left as Yocto's problem Nov 08 15:32:46 RP__: if not, I will start working on that Nov 08 15:32:59 RP__: ok stupid me I understand now after reading again the code. Should turn on the brain before asking this kind of question ;-) thanks Nov 08 15:33:20 RP__: anything I can help with? Nov 08 15:33:28 otavio: It depends how it works. If it is opt-in and not too invasive I'm not against it Nov 08 15:33:40 otavio: See all the open high/critical/major bugs :/ Nov 08 15:33:50 otavio: the bad_recommends is one of them Nov 08 15:34:11 RP__: yes; this is a blocker for me Nov 08 15:34:35 otavio: What I don't want to do is take more things whilst we have all the current issues Nov 08 15:34:44 RP__: right, i agree Nov 08 15:34:55 RP__: but I'd like to start preparing the branch for merging Nov 08 15:35:07 RP__: I will keep adding the stuff into meta-oe for now Nov 08 15:35:22 RP__: but will then start moving stuff onto core branch Nov 08 15:35:47 otavio: ok, a branch is fine Nov 08 15:36:31 RP__: but I want to finish our blocking stuff for our product before Nov 08 15:36:44 RP__: bad recommends is one of them Nov 08 15:36:51 RP__: is someone working on it? Nov 08 15:37:17 otavio: I'm trying to figure out how to find someone Nov 08 15:37:32 otavio: looks likely it will have to be me Nov 08 15:37:45 otavio: but when I'm doing that I'm not reviewing/merging patches Nov 08 15:37:49 RP__: did you got the issue well understood? Nov 08 15:37:56 otavio: no Nov 08 15:38:04 otavio: even triaging it takes a lot of time :( Nov 08 15:38:10 RP__: it replaces the status file when first install command is done Nov 08 15:38:23 RP__: so opkg ends adding the recommended packages Nov 08 15:38:36 RP__: so it is a bug in opkg, not oe Nov 08 15:39:44 RP__: i have a commitment how; bbl; leave a message if you need anything from me to fix it Nov 08 15:39:48 RP__: or test Nov 08 15:40:22 otavio: will do, thanks Nov 08 16:32:30 JaMa: ping Nov 08 16:32:35 pong Nov 08 16:33:10 Hi There, I am still having a problem with the xf86-video-omapfb SRCREV Nov 08 16:33:26 I have tried to git clone directly Nov 08 16:34:07 from http://git.pingu.fi/xf86-video-omapfb? Nov 08 16:34:44 the clone is failing Nov 08 16:35:55 I've just checked http://git.pingu.fi/xf86-video-omapfb/refs/heads/master and that's our SRCREV Nov 08 16:37:04 sgw: http://paste.pocoo.org/show/504657/ Nov 08 16:40:36 $ git://git.pingu.fi/xf86-video-omapfb Nov 08 16:40:37 Cloning into xf86-video-omapfb... Nov 08 16:40:37 fatal: unable to connect to git.pingu.fi: Nov 08 16:40:37 git.pingu.fi[0: 81.22.249.143]: errno=Connection timed out Nov 08 16:41:53 http:// right? Nov 08 16:48:08 jama, ok got it working, still not sure what's going on since I get a failure Nov 08 16:49:04 JaMa: must still be a problem with the mirror maybe, not sure what's going on then. Nov 08 16:49:42 yes could be as me and koen have premirrors with right archive Nov 08 18:02:58 I am trying to use the external toolchain external-csl2008q3 (setting toolchain TCMODE = "external-csl2008q3" in /meta-yocto/conf/distro/poky.conf) on qemuarm. When building with bitbake core-image-minimal (machine = qemuarm) I get dependency loops. Has someone experience with the tcmode-external-csl2008q3.inc distro? Should it be a running example or it is meant as "pseudo code"? Nov 08 18:05:36 JaMa: OK, got it working finally, seems I had some stuck bits. Nov 08 18:06:15 great Nov 08 19:50:13 kergoth: Any thoughts on the append/prependVar change? (I've sent a patch to the bitbake list) Nov 08 19:53:35 RP__ I've got my local version of rpm executing the wrapper.. but it's not quite right yet.. Nov 08 19:53:45 I'm glad you made the patch.. the PSM thing would have taken me forever to find Nov 08 19:53:50 (PSM_CHROOT_IN/OUT) Nov 08 19:54:34 fray: I'm glad its helping :) Nov 08 19:55:23 (problem I'm having now is I'm not finding the external script that should have been called.. something funky is happening with it and the paths..) Nov 08 19:55:33 fray: I did try my own version of it but ended up going for the sledgehammer approach Nov 08 19:55:41 it was really close Nov 08 19:55:50 fray: Have a look at the other bits of my patch ;-) Nov 08 19:55:54 it was just missing the optional glue Nov 08 19:56:09 fray: Its removes the chroot prefix which is why I commented out some of that other code Nov 08 19:56:24 I worked around that -- I think Nov 08 19:57:11 fray: I think some of that code may force it into a chroot if it wasn't in one already Nov 08 19:58:01 I've definitely escaped the chroot... but it's the generated script that doesn't seem to be there.. I'm wondering if maybe it got shuffled off somewhere else Nov 08 20:02:12 fray: it gets put in a build path within the chroot? Nov 08 20:02:36 yes.. it should have been put into /var/tmp/... within the rootfs directory.. Nov 08 20:02:38 but I'm not seeing it.. Nov 08 20:02:44 fray: no Nov 08 20:02:47 which is why I'm wondering it errored or went somewhere else Nov 08 20:02:59 fray: prefix is the native sysroot Nov 08 20:03:11 This is my current debugging: Nov 08 20:03:13 /home/mhatle/git/oss/oe-core/build-x86_64/tmp-eglibc/work/qemux86_64-oe-linux/core-image-sato-1.0-r0/rootfs/ /bin/sh /home/mhatle/git/oss/oe-core/build-x86_64/tmp-eglibc/sysroots/x86_64-linux/usr/var/tmp/rpm-tmp.19581 1 pwd=/home/mhatle/git/oss/oe-core/build-x86_64/tmp-eglibc/work/qemux86_64-oe-linux/core-image-sato-1.0-r0/rootfs found=? Nov 08 20:03:39 first is the rootfs directory, second is what to run, third is the first argument and fourth is the parameter list.. (followed by pwd and if we found $3) Nov 08 20:03:59 Your script will be in /home/mhatle/git/oss/oe-core/build-x86_64/tmp-eglibc/work/qemux86_64-oe-linux/core-image-sato-1.0-r0/rootfs/home/mhatle/git/oss/oe-core/build-x86_64/tmp-eglibc/sysroots/x86_64-linux/usr/var/tmp/rpm-tmp.19581 Nov 08 20:04:00 the problem is that the third arg file doesn't seem to exist.. but it should.. so I'm at a bit of a loss to explain where it went.. still tracing through Nov 08 20:04:03 any udev experts? I have a possible patch for the dmesg sanity issue, but I am not sure it's correct Nov 08 20:04:36 RP__ if thats the case, we have a bug in the system... it shouldn't be that deep Nov 08 20:04:48 I'll look and see if that is what is happening.. if so, it'll be easy to fix Nov 08 20:04:50 fray: it should, look at the $prefix we build rpm-native with Nov 08 20:04:59 fray: its perfectly fine ;-) Nov 08 20:05:20 no.. it should be using target paths within the rootfs.. we have a host path leaking in which is wrong.. Nov 08 20:05:22 sgw: I can look at it... Nov 08 20:05:35 I suspect its as simple as _vartmp isn't being configured properly when cross installing Nov 08 20:06:15 fray: fair enough, but I can understand rpm wanting to use a tmpdir within the native sysroot for some stuff Nov 08 20:06:54 ya that is exactly what is happening.. that is easy to fix Nov 08 20:07:34 it also means the on-target db -could- be constructed incorrectly.. (it's not, but thats an artifact of another reason) Nov 08 20:07:57 it might be related to the action=add that came in recently, I could fix it by adding /dev/md0 to the blacklist, but I was not sure that's correct Nov 08 20:09:33 RP__ likely stupid question, but what is the localestatedir when called within a shell portion of package_rpm.bbclass.. is it simply "${localstatedir}"? Nov 08 20:09:55 fray: yes Nov 08 20:11:49 (and on a completely different topic)... there was a Tesla in the parking lot of the dr office today Nov 08 20:12:13 Wonder how that will hold up in the winter! Nov 08 20:12:15 bright lime green Nov 08 20:14:10 RP__ ya.. it was the var/tmp not being set right.. and the path -was- in the root Nov 08 20:15:56 RP__: another possibility is disabling raid (md) by default, not sure if we really need that Nov 08 20:16:00 zeddii: ping Nov 08 20:18:09 sgw: you can probably just blacklist it tbh Nov 08 20:18:22 sgw: Is this coming from the udev automount code? Nov 08 20:18:31 That was my first thought, patch forth coming shortly. Nov 08 20:19:16 RP__ ok.. so now that I have this working.. is there any way to query the system for the value of "D"? (I think D is the only thing scripts are allowed to reference) Nov 08 20:19:45 ...that and of course the PATH has been cleansed... Nov 08 20:19:46 fray: query what piece of the system? Nov 08 20:19:57 fray: D is the path to the rootfs Nov 08 20:20:05 fray: and yes, you need PATH too Nov 08 20:20:06 in OE, is there any way for an external shell script to get the value of D, PATH and other piecs Nov 08 20:20:19 RP__: yes, but not from the udev mount script (unless I put debugging messages in the wrong place!) Nov 08 20:20:37 fray: I was thinking rootfs_rpm could write the shell script (or sed in the values) Nov 08 20:20:49 fray: or write a file for it to source Nov 08 20:20:54 ya.. that is what I'm guessing well have to do as well Nov 08 20:21:02 BTW, did you pick up josh's meta-yocto .bb -> .bbappend patch? Nov 08 20:21:03 just wodnering if there was another way.. Nov 08 20:21:17 sgw: yes, its in Nov 08 20:21:26 Most be inbetween syncs! Nov 08 20:21:35 also, I assume there is no way to inject a task into bitbake to be executed right? i.e. I can't single bitbake to execute an arbitrary shell script (i.e. the pre/post job) wait for it to exit and return control to RPM? Nov 08 20:21:47 fray: "bitbake -e" but that is recursive calling of bitbake and disallowed. So no, no easier way Nov 08 20:21:54 'k Nov 08 20:27:58 I've got to run.. should be back in a coupel of hours.. let me push what I have so far Nov 08 20:29:26 ok.. what I have so far is no in contrib mhatle/rpm Nov 08 20:29:57 work still to be done.. update package_rpm.bbclass (or rootfs_rpm.bbclass) to generate the appropriate wrapper script.. and then to pass the path to the wrapper as a parameter to the install of the packages.. Nov 08 20:34:24 fray: looks good so far Nov 08 23:55:05 Looking at Richard's patch removing bash-isms from various classes. So I assume going forward our shell code should be dash-compatible? Nov 08 23:55:58 well, POSIX compliant is the aim - but essentially yes Nov 08 23:56:07 we don't want to have to ask people to change their shell Nov 08 23:57:44 * zenlinux starts dancing to dash's tune Nov 09 02:24:42 <_JOEL_> evening guys **** ENDING LOGGING AT Wed Nov 09 02:59:57 2011