**** BEGIN LOGGING AT Wed Feb 27 02:59:58 2013 Feb 27 08:26:55 Picking up my OE-stuff again after some away-time. Is now the time to go from denzil to danny? Feb 27 08:44:53 tasslehoff why not? Feb 27 08:49:09 good morning Feb 27 08:49:17 hi mckoan Feb 27 09:03:55 woglinde_: no idea. haven't been following the mailinglists must either, so I thought I'd ask The Knowers Feb 27 10:32:28 how can i "patch/overlay" package.bb ldconfig_postinst_fragment() in my layer ? Feb 27 10:33:28 (without copying package.bb completly) Feb 27 10:33:35 package.bbclass sry Feb 27 11:27:22 afournier1: you can do it on a per-recipe basis, or in a separate bbclass that each recipe in your layer inherits Feb 27 11:27:43 afournier1: but you can't really override just that function for every recipe Feb 27 11:28:17 yes i was thinking avour making a custom class like ldconfig-fix.bbclass Feb 27 11:29:21 meanwhile maybe you can correct it upstream Feb 27 11:29:56 i think that "[ -x /sbin/ldconfig ] && /sbin/ldconfig" should be "[ -x /sbin/ldconfig ] && /sbin/ldconfig || true", because if it's at the end of the postinst, it can return 1, and opkg does not like it :) Feb 27 11:31:03 and ldconfig is option as openembedded-core/meta/recipes-core/eglibc/eglibc-package.inc declares USE_LDCONFIG ?= "1" Feb 27 11:34:09 afournier1 whats happended when it returns 1? Feb 27 12:41:30 Hello. Feb 27 12:41:57 There is http://paste.ubuntu.com/5570374/ in receipe. Feb 27 12:42:06 I need to enable curl. Feb 27 12:42:26 Is there possibility to do a bbappend to achieve this? Feb 27 12:46:03 yes Feb 27 12:46:13 just use bbappend Feb 27 12:46:36 and use a versioning diffrent from core or what ever repo you used Feb 27 12:50:30 Yes, but how EXTRA_OECONF should look like in my bbappend? Feb 27 12:50:48 I can not do, probably, EXTRA_OECONF -= " --disable-curl" Feb 27 12:51:02 Will EXTRA_OECONF += " --enable-curl" work? Feb 27 12:51:30 Then finally it will be ./configure --foo --bar --disable-curl --car --zar --enable-curl Feb 27 12:56:50 last pararemter wins in configure too I think Feb 27 12:57:10 if not just ovveride it complete Feb 27 12:57:16 EXTRA_OECONF = Feb 27 12:57:26 of if nothings help try to filter it out Feb 27 12:57:33 with python syntax Feb 27 13:07:16 woglind, when it returns 1, opkg marks the package as "install user unpacked" instead of "install user installed" that means the postinst failed, that means it will try to launch the postinst everytime opkg configure is launched Feb 27 13:08:08 and as ldconfig is optional, it should not fail at postinst Feb 27 13:30:39 afournier1 I meant when ldconfig returns 1 Feb 27 13:31:07 it's not ldconfig that returns on, but the test Feb 27 13:31:14 ? Feb 27 13:32:03 [ -x /bin/ls.bad ] && ls; echo $? Feb 27 13:32:24 yes Feb 27 13:32:24 the script does not "fail" but the error code is != 0 Feb 27 13:32:35 should better guarded be with if Feb 27 13:32:41 maybe Feb 27 13:32:52 its not like source Feb 27 13:33:03 where the construct is used often Feb 27 13:33:20 [ -f foo] && source foo Feb 27 13:33:33 hello , can i use osx on open embedded ? Feb 27 13:33:42 no Feb 27 13:33:44 osx as a development ? Feb 27 13:33:49 ;( Feb 27 13:33:53 only linux ? Feb 27 13:34:00 ubuntu ? Feb 27 13:34:01 and oe is not this much compatible with osx Feb 27 13:34:07 there where some efforts Feb 27 13:34:19 linux is best choice Feb 27 13:34:28 which linux distribution ? Feb 27 13:34:36 an actual Feb 27 13:34:45 ubuntu ? Feb 27 13:34:51 opensuse? Feb 27 13:34:54 do not use an 7 year old suse Feb 27 13:34:55 woglinde: guardef with if/then/fi would be ok too Feb 27 13:34:55 which one best ? Feb 27 13:35:02 guarded* Feb 27 13:35:15 afournier1 sure and makes it more safety Feb 27 14:02:15 | update-alternatives: Error: cannot register alternative groups to /usr/bin/groups since it is already registered to /bin/groups Feb 27 14:02:27 grr Feb 27 15:51:32 hi there, i'm trying to write some recipes that have a few common dependencies. Feb 27 15:51:44 i want to define them all in a common parent bb file, is there a way to do that? Feb 27 15:52:02 in other words, every recipe that depends on p should look up further dependencies in p's recipe, Feb 27 15:52:12 but those should not be dependencies for p itself. Feb 27 15:55:49 brezensalzer: you can use "require" to include a common inc (or another recipe) Feb 27 15:56:21 brezensalzer: if this is common functionality to a moderately large number of recipes then you could use a .bbclass and then inherit it in each recipe Feb 27 15:59:01 use require on one programm or programmfamilies Feb 27 15:59:27 use inherit and bbclass for all other Feb 27 16:00:27 yep that's a reasonable scheme Feb 27 16:01:41 woglinde: nice summary Feb 27 16:03:57 ah no Feb 27 16:04:02 programfamily Feb 27 16:04:13 k thanks Feb 27 16:04:14 famlies would more imply inherit Feb 27 16:05:03 woglinde: funny, I read it as singular, but point taken Feb 27 16:05:24 yes I was to fast in mind too Feb 27 16:48:00 i don't understand why shadow is required when building my image Feb 27 17:11:30 i think it's because of useradd Feb 27 18:58:33 can build history show me what gets installed in an sdk created via populate_sdk? Feb 27 19:28:32 Crofton: no, it doesn't have any functionality for recording what goes into SDKs, although I've thought about adding that Feb 27 19:28:34 bbl Feb 27 19:31:58 gah Feb 27 19:32:10 bluelightening, +10 Feb 27 19:32:42 can anyone explain to me what the modules.order and modules.builtin files are go? I'm getting warnings during filesystem generate about those files being missing. (warnings from kmod's depmod) Feb 27 19:45:57 I don't suppose anyone knows if it's possible to use tmpfs instead of ramfs as initramfs? Feb 27 20:12:08 i think i missed something, in shadow_4.1.4.3.bb's postinst, there is a commande like "grpconv --root=$D". And it fails when i am building my image by displaying the usage. I saw patches to add --root argument to many shadow utilities, but it seems they are only applied to the -native version. Therefore i guess postinst should use the -native version too. What's wrong ? Feb 27 20:13:31 friend of mine in berlin has some cool python openings Feb 27 20:14:09 cool as in python/js/etc + earthquake/risk modeling Feb 27 20:18:26 wakko, shadow-native or shadow-cross should have --root option implemented in it.. Feb 27 20:18:38 you should not be using the --root option on the target, if that is occuring something else may be wrong Feb 27 20:19:03 it's used during the image baking... Feb 27 20:19:05 check that the shadow-cross was built.. if it wasn't again you may be callign the wrong version... for some reason Feb 27 20:19:12 package install? Feb 27 20:19:24 bitbake my-image Feb 27 20:19:31 the do_rootfs task? Feb 27 20:19:52 yep Feb 27 20:20:13 check the log, is it happening during the package install, or before/after the package install? Feb 27 20:20:23 and which version of oe are you using? Feb 27 20:20:28 denzil Feb 27 20:20:43 I'm not sure if it was implemented in Denzil or not Feb 27 20:20:54 * fray checks Feb 27 20:21:04 how do i know if it's after/before ? it's right in the middle of a ton of "update-alternatives" Feb 27 20:21:33 it was not Feb 27 20:21:51 :( Feb 27 20:22:06 wait.. I may be looking at the wrong thing Feb 27 20:22:29 what are you looking at more precisely ? Feb 27 20:22:38 sorry it was.. Feb 27 20:22:43 :) Feb 27 20:22:48 meta/recipes-extended/shadow/shadow-sysroot... Feb 27 20:22:55 meta/classes/useradd.bbclass Feb 27 20:23:09 ok Feb 27 20:23:45 figure out what package is causing the error and look at the usage.. either the shadow-native/shadow-sysroot versions were NOT built (as they should have been) or the package has a bug.. I know there have been a number of package and related bugs fixed since Denzil Feb 27 20:23:48 the DEPENDS does not stat any ${PN}-sysroot or similar Feb 27 20:24:03 (top of useradd.bbclass) Feb 27 20:24:03 DEPENDS_append = "${USERADDDEPENDS}" Feb 27 20:24:03 USERADDDEPENDS = " base-passwd shadow-native shadow-sysroot shadow" Feb 27 20:24:12 ha Feb 27 20:24:13 yes Feb 27 20:24:14 you should have a DEPENDS of base-passwd, shadow-native, shadow-sysroot and shadow Feb 27 20:24:30 btw it's not possible to get rid of shadow if using useradd :) Feb 27 20:24:32 if those items have not been built, then whatever the package is may not be using the useradd Feb 27 20:24:44 in Denzil, correct Feb 27 20:24:47 many packages uses that Feb 27 20:24:52 ok Feb 27 20:25:12 USERADDDEPENDS = " base-passwd shadow-native shadow-sysroot shadow" Feb 27 20:25:48 verify the right grpconv is being run... Feb 27 20:25:49 btw the failing package is shadow itself Feb 27 20:25:54 bitbake -c devshell Feb 27 20:25:57 which grpconv Feb 27 20:26:01 k Feb 27 20:26:14 it should be within the ...tmp-eglibc/sysroot//... directory Feb 27 20:26:50 /spare/alex/oe/tmp-eglibc/sysroots/i686-linux/usr/sbin/grpconv Feb 27 20:27:04 that looks correct.. Feb 27 20:27:11 ok, so the environment is right.. Feb 27 20:27:15 checking if it has the --root patch Feb 27 20:27:34 looks like it does Feb 27 20:28:20 now i am wondering, what's the point of using denzil, i had so many bugs lately... Feb 27 20:28:31 i thought it was a more stable branch Feb 27 20:28:44 is master more buggy ? Feb 27 20:28:57 denzil is old.. Feb 27 20:29:01 stuff ahs changed since then Feb 27 20:29:14 I'm looking and I don't see any obvious fixes since Denzil in the shadow package.. Feb 27 20:29:39 There may be ones but I'm not seeing them.. you'll have to simply debug what's going wrong with the grpconv Feb 27 20:29:55 i am checking the PATH Feb 27 20:30:18 if the patch was applied to the grpconv, then the bug is either in the caller or in grpconv itself.. Feb 27 20:30:36 I'm not seeing those errors in my master builds.. Feb 27 20:31:33 i was not seeing them until i did something obscure with busybox :/ Feb 27 20:31:39 but now i cannot go back Feb 27 20:35:01 the PATH looks correct Feb 27 20:40:47 i think the callee is not working Feb 27 20:41:24 it displays the usage but at the same time it returns 0... Feb 27 20:41:35 maybe shadow is ok ... Feb 27 20:49:53 as it executes all postinsts at once it's impossible to tell which postinst fails... Feb 27 20:50:59 wakko, ahh so it's working but displaying usage.. Feb 27 20:51:06 i think so Feb 27 20:52:19 Collected errors: Feb 27 20:52:19 * opkg_install_cmd: Cannot install package task-core-mytask Feb 27 20:52:24 thanks opkg Feb 27 20:53:27 BTW this issue is starting to sound familiar.. but I have no idea if it's been resolved.. I don't see that error in my own builds.. but it's possible I've just missed it Feb 27 20:53:58 * fray adds shadow to his target to try to trigger it Feb 27 20:55:45 hello Feb 27 20:57:15 is there a way to find all postinst of a task and execute them by hand from the devshell ? Feb 27 20:58:07 isn't postinst package-specific? Feb 27 20:58:22 wakko ... Feb 27 20:58:22 Output from shadow-4.1.4.3-r13@x86_64: Feb 27 20:58:22 Usage: grpconv Feb 27 20:58:29 I just got that from master Feb 27 20:58:35 echo $? Feb 27 20:58:37 no usage, it just printed "grpconv" for some reason Feb 27 20:58:40 those files get installed (by package name) in /usr/lib/opkg/info Feb 27 20:58:43 yes that's it Feb 27 20:58:46 same thing here Feb 27 20:58:49 so it's still a bug Feb 27 20:58:55 and yes, harmless.. Feb 27 20:59:12 check bugzilla.yoctoproject.org, if there isn't already a bug filed.. file one.. I suspect nobody has noticed before Feb 27 20:59:40 as you said this bug is harmless Feb 27 20:59:53 as i don't know which postinst fails it's a bit useless to fill a bug Feb 27 21:00:07 it's shadow Feb 27 21:00:14 and it's not failing.. just printing out a message Feb 27 21:00:47 if you just want to execute the postinst stuff, then "opkg configure " will do it Feb 27 21:01:16 nerdboy i can try this Feb 27 21:01:21 (from the devshell) Feb 27 21:02:07 fray: printing out a message in postinst should not disturb opkg :) Feb 27 21:02:13 probably need -r {some_root} from devshell Feb 27 21:03:01 wakko, correct.. afaik it's supposed to check the return code.. and my install (of master) says that is 0 Feb 27 21:03:12 but please file a bug.. it'll probably get fixed very quickly.. Feb 27 21:03:19 ok Feb 27 21:03:20 backport to denzil should be easy once it does Feb 27 21:04:54 wakko: opkg-cl in the native sysroot sounds like what you want Feb 27 21:05:31 nerdboy: i will try that after filling the bug, also it looks like i have to set some env var according to the run_do_rootfs Feb 27 21:07:08 IMAGE_ROOTFS maybe? Feb 27 21:07:22 D Feb 27 21:07:26 OFFLINE_ROOT Feb 27 21:07:28 IPKG_OFFLINE_ROOT Feb 27 21:07:30 OPKG_OFFLINE_ROOT Feb 27 21:07:57 = ${IMAGE_ROOTFS} Feb 27 21:08:10 yep Feb 27 21:08:42 the -r should do that in theory... Feb 27 21:08:47 ok Feb 27 21:09:42 all the right variables should be set in devshell, no? Feb 27 21:09:54 not sure Feb 27 21:11:08 you should be able to use ${STAGING_BINDIR_NATIVE}/opkg-cl -r ${IMAGE_ROOTFS} configure foo Feb 27 21:11:22 in theory Feb 27 21:12:57 maybe would be easier to put the opkg-cl ${ipkg_args} install ${package_to_install} in a for loop Feb 27 21:13:55 then why not put that in your image recipe? Feb 27 21:14:09 what are you trying to do? Feb 27 21:14:12 almost done... Feb 27 21:14:33 nerdboy: you think too fast for me :) Feb 27 21:17:23 they all passed wtf ! Feb 27 21:20:07 the bugzilla is so slow at sending mail, or i am so slow at receiving them... don't know **** ENDING LOGGING AT Thu Feb 28 02:59:58 2013