**** BEGIN LOGGING AT Thu Nov 29 02:59:59 2012 Nov 29 05:30:16 how can i capture the contents of a fb Nov 29 08:36:52 good morning Nov 29 08:38:04 good morning Nov 29 08:52:09 morning Nov 29 08:52:10 did someone ever had this error when configuring php ? "configure: error: Your system seems to lack POSIX threads." Nov 29 08:57:48 examine config.loh Nov 29 08:57:54 ups config.log Nov 29 08:59:47 ups config.log ? Nov 29 08:59:57 the config.log is weird indeed Nov 29 09:02:32 http://pastebin.com/70e4ZTAj Nov 29 09:11:08 is someone able to build oprofile? Nov 29 09:56:14 morning all Nov 29 10:02:10 morning silvio_, all Nov 29 10:13:35 hi bluelightning Nov 29 10:14:06 ok i understood why pthreads was not detected by the php autoconf i think Nov 29 10:14:10 morning Nov 29 10:22:02 I'm getting a busy loop in python code running a do_fetch. any hints how to see what's going on? Neither -v or -DD tells me anything Nov 29 10:23:35 [oe-commits] Koen Kooi : kernel bbclass: delete Nov 29 10:23:40 hooray ! Nov 29 10:27:05 so when php detects cross compilation, it thinks the is no pthreads except for netware : https://github.com/php/php-src/blob/master/TSRM/threads.m4#L89 Nov 29 10:27:34 it sounds strange no ? Nov 29 10:40:36 Zagor: what's last line in bitbake output? Nov 29 10:41:44 JaMa: 0: linux-qoriq-sdk-3.0.34-r8 do_fetch (pid 17424) Nov 29 10:42:46 I already have this package in my downloads/ directory, so it should be pretty instant. but something is confusing it. Nov 29 10:56:04 Zagor: are you sure no wget is running on background? Nov 29 10:57:15 JaMa: yes. ps u 17424 Nov 29 10:57:15 USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND Nov 29 10:57:15 bjst 17424 98.8 0.1 316460 168340 pts/0 R 11:41 2:53 python /media/s Nov 29 10:57:32 hi all Nov 29 10:57:46 I need to have gcov utility on target Nov 29 10:57:46 ah, cmdline cutoff: python /media/sdb1/fb/bjst/poky/bitbake/bin//bitbake Nov 29 10:57:55 is there any recipe for that Nov 29 10:58:11 anyway, yes, there is no wget running. it's the python script looping on something. Nov 29 10:58:18 I know gcc recipe has this but I think it is cross compiled Nov 29 10:58:56 ant_work: :) Nov 29 11:04:51 technical question Nov 29 11:05:11 will OE-Core ML accept 0.5MB email? Nov 29 11:05:44 or would you suggest other way of sharing such big patch? Nov 29 11:06:14 how can i remove udev_182 from being build ( seems that this breaks building systemd and this is needed for angstroem ) Nov 29 11:10:14 pwgen: the angstrom distro config doesn't ensure this works already? Nov 29 11:11:12 hrw: you can send a cover letter pointing to a branch on oe-core-contrib or github or somewhere else if you're concerned about the size Nov 29 11:12:34 good point Nov 29 11:12:39 i had set up ne new build system. i can build core-image-minimal, but when i add meta-systemd to bblayers, i get complains on multiple providers and udev build fails. Nov 29 11:18:15 pwgen: if you have to add meta-systemd then you probably do not do angstrom builds in angstrom way Nov 29 11:27:36 indeed... Nov 29 11:28:03 meta-systemd ought to be usable like this outside of angstrom though Nov 29 11:41:28 PREFERRED_PROVIDER_udev="systemd" solved my problem .. Nov 29 11:42:53 the Angstroem README says "At least 'meta-oe' and 'meta-systemd' are needed" Nov 29 12:10:06 pwgen: I'm surprised the angstrom distro config doesn't already do that, perhaps you can report it to the angstrom-devel mailing list Nov 29 12:10:54 maybe we should remove udev recipe from meta-oe now with newer udev in oe-core Nov 29 12:11:54 ok i started a build with the oebb.sh script, and this seems very different to these that i used with oe-core. Nov 29 12:12:31 ( bitbake 1.9 vs 1.19 on oe-core and many other revisions . Nov 29 12:22:11 JaMa: yes I'd remove it, why 2 udev nowadays? Nov 29 12:24:43 ant_work: then test patch I've just sent Nov 29 12:47:41 JaMa: if you don't use systemd there is anything to test: udev from oe-core just works Nov 29 12:51:16 ant_work: did you check the diff between oe-core and meta-oe version? Nov 29 12:51:41 not lately. littkle sense now that udev sources merged with systemd Nov 29 12:54:48 here is the diff http://bpaste.net/show/61056/ I guess at least uclibc will now fail with oe-core version Nov 29 13:07:41 JaMa: uclibc should be fixed in oe-core and not in external layers. But I see now, how is it DEPENDS differ so much between the two udev's?? Nov 29 13:08:02 s/uclibc/uclibc issues/ Nov 29 13:09:38 All I know is that Damian was asked to check meta-oe diff and include all functionality.. I don't know how carefully he read the diff and did that.. Nov 29 13:12:20 :/ Nov 29 13:13:30 I'll be back testing userland soon, I'll try to see if there are more obscure issues Nov 29 13:14:35 btw, seems you're finally sorting out the TUNES vs. armv4 thing. Kudos! Nov 29 13:14:56 I'll pester my 2 collie testers ;) Nov 29 13:15:50 http://lists.linuxtogo.org/pipermail/openembedded-core/2012-September/030043.html Nov 29 13:31:34 pwgen: sounds like that's building the OE-Classic version of angstrom... maybe you need a different branch of the setup-scripts repo? Nov 29 13:33:31 JaMa: maybe someone else knows different but I'm not sure that the udev 182 in meta-oe has ever been tested with anything other than systemd; last I checked it breaks with it Nov 29 13:33:41 s/it/sysvinit/ Nov 29 13:54:57 bluelightning: true, last version I was using without systemd was 181 Nov 29 13:55:02 bluelightning: https://lkml.org/lkml/2012/10/2/505 in case you did not hear about it Nov 29 13:55:17 bluelightning: more info here http://www.phoronix.com/scan.php?page=news_item&px=MTIzMDU Nov 29 13:55:30 bluelightning: btw: libcgroup from oe-core now fails Nov 29 13:55:31 ERROR: QA Issue: non -dev/-dbg/-nativesdk package contains symlink .so: cgroups-pam-plugin path '/work/armv4t-oe-linux-gnueabi/libcgroup/0.37.1-r2/packages-split/cgroups-pam-plugin/lib/security/pam_cgroup.so' Nov 29 13:55:36 ERROR: QA run found fatal errors. Please consider fixing them. Nov 29 13:56:28 meta-oe version had: ERROR_QA = "debug-deps dev-deps debug-files arch la2 pkgconfig la perms" Nov 29 13:56:48 oe-core version has INSANE_SKIP_${PN} = "dev-so" Nov 29 13:57:23 it's probably failing because it's not PN but cgroups-pam-plugin Nov 29 13:57:51 JaMa: ah right, I missed that subtlety in my comparison Nov 29 13:59:15 will send patch later Nov 29 13:59:48 JaMa: thanks Nov 29 14:14:11 btw "Gentoo Developers Unhappy, Fork udev" Nov 29 14:15:34 yes, saw that Nov 29 14:16:20 I'm not sure what to make of it though based on the LWN discussion about it Nov 29 14:35:57 ant_work, did you follow the g+ hilarity? Nov 29 14:37:54 morning all Nov 29 14:38:30 Daemon404: nope Nov 29 14:38:35 pb_: hello there Nov 29 14:39:09 https://plus.google.com/111049168280159033135/posts/R387kQb1zxc Nov 29 14:39:14 for the curious Nov 29 14:39:16 it make me smile Nov 29 14:43:28 well, all the issue is fondamentally sad Nov 29 14:43:42 but the reactions can be funny :) Nov 29 14:43:59 yes Nov 29 15:12:26 Daemon404: best bits of Linus in that hread with Greg KH is "We are apparently better off trying to avoid udev like the plague." Nov 29 15:12:45 ther's no good solution period Nov 29 15:17:00 otavio: ping Nov 29 15:43:21 levonmaa: pong Nov 29 15:47:36 otavio: did you find the right branch Nov 29 16:03:20 otavio: I have now also fixed the installation of the mkspecs also, but the module pri files are not getting installed correctly Nov 29 16:09:41 levonmaa: so you did a great progress on it Nov 29 16:09:52 levonmaa: I did not test your branch yet Nov 29 16:10:03 levonmaa: what the pri files are doing wrong? Nov 29 16:23:25 otavio: someone pushed with -f to git@github.com:OSSystems/meta-browser.git, removing this patch "firefox: bump PR to rebuild after libffi5 -> libffi6" any idea why? Nov 29 16:23:57 JaMa: uh?!? Nov 29 16:24:01 let me find who did Nov 29 16:24:51 thx, I can repush later, but how do you plan to find out? Are there some extra logs on github? Nov 29 16:24:57 hmm.. libffi... have to create and send patch which will add aarch64 Nov 29 16:28:17 JaMa: From github log it seems you did the last change in it Nov 29 16:28:25 JaMa: like 4 mounths ago Nov 29 16:30:27 that was when I pushed it there I guess Nov 29 16:31:16 but git remote update today shown Nov 29 16:31:17 From github.com:OSSystems/meta-browser + b8f4a7e...5d176cb master -> origin/master (forced update) Nov 29 16:31:55 and that PR bump is indeed: Nov 29 16:31:56 commit b8f4a7e489907bbaf99d4059192ddf93ef1e54bc Nov 29 16:31:56 Author: Martin Jansa Nov 29 16:31:56 Date: Mon Sep 17 06:50:23 2012 +0200 Nov 29 16:32:58 pushing it back.. Nov 29 16:40:16 otavio: the module pri files are ending up in a dir under the native env, but just under the wrong folder... Nov 29 16:41:13 otavio: it would be great if you could run it and have a look see your self as well Nov 29 16:41:30 I'll push the mkspec change there as well. Nov 29 17:04:19 levonmaa: good, please do Nov 29 18:30:24 hello. what's the designed way to use different /etc/fstab files depending on the built image? shoud I (1) provide two different base-files recipes or .bbappends or (2) do a postprocess command in the image recipe? Nov 29 18:48:22 i am sure someone will return to answer Nov 29 18:52:47 we actually do a little of both Nov 29 18:53:17 not sure there's a one-size-fits-all answer Nov 29 18:54:33 * mr_science waves at NightMonkey Nov 29 20:30:03 otavio: pushed Nov 29 21:05:30 does anyone know how /etc/shadow gets populated during an OE build? Nov 29 21:05:52 and the proper way to change the default root password Nov 29 21:06:04 I'd guess useradd.bbclass would handle it for new users, but not sure for the baseline Nov 29 21:08:16 /etc/shadow is located in the rootfs images, but does not appear to be in any of the packages Nov 29 21:08:50 so it may get generated at rootfs time (vs 1st boot, etc) Nov 29 21:09:18 that reminds me, forgot to ask in here, is anyone playing with read only rootfs nowadays? Nov 29 21:10:08 hm only pb did I think Nov 29 21:10:14 hmm, right Nov 29 21:10:24 * kergoth checks out current meta-micro Nov 29 21:22:30 cbrake: have you looked at zap_root_password which disables root pass? Nov 29 21:24:02 if it's in DISTRO_FEATURES, the function gets called after the creation of rootfs image Nov 29 21:24:26 see core-image.bbclass: ROOTFS_POSTPROCESS_COMMAND += '${@base_contains("IMAGE_FEATURES", "debug-tweaks", "", "zap_root_password ; ",d)}' Nov 29 21:24:43 IMAGE_FEATURES Nov 29 21:24:57 I think that you can append to ROOTFS_POSTPROCESS_COMMAND to do whatever you want with root password Nov 29 21:25:06 JaMa: thanks for correction :) Nov 29 21:25:28 EXTRA_IMAGE_FEATURES += "debug-tweaks" is the best way to resurrect root login, afaik Nov 29 21:26:19 true, but IMAGE_FEATURE to set some known password can be usefull too Nov 29 21:26:42 and won't need to alter opensshd config to allow passwordless login as bonus Nov 29 21:27:17 true Nov 29 21:27:29 JaMa, using the ROOTFS_POSTPROCESS_COMMAND is the way I've set the default root passwd.. Nov 29 21:27:54 it was pretty simple to specify..... Nov 29 21:28:01 (just trying to remember how offhand) Nov 29 21:29:19 I think it was "passwd --root ${D} root" or something like that.. Nov 29 21:29:20 well you can just sed it in /etc/shadow.. Nov 29 21:29:22 sorry it's ben a while Nov 29 21:29:33 sed works as well.. but then you have to figure out if you have shadow enabled or not.. Nov 29 21:30:31 fray: I'll send another batch of arm tune-* fixes today, if you find time to review them, please do Nov 29 21:31:07 ok Nov 29 21:31:34 * fray is trying to get the smart (rpm) integration tested to show it's all owrking as good or better then before Nov 30 00:22:25 Hello Nov 30 00:24:11 Just for the shake of understanding how this whole thing works… PREFERRED_PROVIDER_virtual/kernel = "linux-omap3" but the recipe is linux-omap3_git.bb, does oe choose the first available recipe with the prefix "linux-omap3" ? What is the difference between _git.bb and _2.6.34.bb? Nov 30 00:27:01 it will choose the one with the highest version number, unless you have a PREFERRED_VERSION ... set Nov 30 00:27:19 I had the meta-oe layer my yocto core-image-sato so I could pick up netperf. I see it is now moved to the meta-oe/meta-networking layer Nov 30 00:27:54 fray, thanks a lot! Nov 30 00:28:16 I added meta-oe/meta-networking to BBLAYERS, bu t I'm still getting: ERROR: Nothing RPROVIDES 'netperf' Nov 30 00:28:26 (in the omap case, it's be PREFERRED_VERSION_linux-omap = "2.6.34" for instance Nov 30 00:28:58 what happens if you bitbake netperf? Nov 30 00:29:41 netperf is also set witha 'commercial' license.. so be sure to enable that Nov 30 00:29:45 still nothing provides netperf, but Nov 30 00:29:50 i see ERROR: netperf was skipped: because it has a restricted license not whitelisted in LICENSE_FLAGS_WHITELIST Nov 30 00:30:02 yup.. thats the commercial liense.. Nov 30 00:30:13 the author of the recipe read the license file and determined something in there had commercial restrictions Nov 30 00:31:16 ok, googling where that would goes... Nov 30 00:31:40 http://www.netperf.org/svn/netperf2/trunk/COPYING Nov 30 00:31:49 "for non-commercial use only" Nov 30 00:32:09 anyway.. you need to add "commercial" to yoru LICENSE_FLAGS_WHITELIST in your local.conf file Nov 30 00:32:33 (BTW I suspect thats a bug.. the license flag should probably be "non-commercial" instead of "commercial"... Nov 30 00:34:47 fray: thanks, that worked better than LICENSE_FLAGS_WHITELIST = "netperf" Nov 30 00:36:12 does look like a bug to me... Nov 30 00:36:27 (it should really be commercial_netperf -- or as I suggested non-commercial_netperf) Nov 30 00:42:47 just an FYI. Don't have "default login swarthout password mypassword" in your .netrc Nov 30 00:43:20 it causes wget ftp://ftp.netperf.org/netperf/netperf-2.6.0.tar.bz2, to return "Login incorrect" Nov 30 01:04:46 fray: thanks for your help. I was missing the connection as to why "bitbake-layers show-recipes" reported "(skipped)" for netperf until you told me to just try bitbake netperf Nov 30 01:05:35 then I could see the ERROR: netperf was skipped: because it has a restricted license not whitelisted ... Nov 30 01:09:53 Oh, and my real name is Ed Swarthout and I've used OE in the past for for my openmoko phone and now using yocto for the Freescale soc's **** ENDING LOGGING AT Fri Nov 30 02:59:58 2012