**** BEGIN LOGGING AT Fri Mar 20 02:59:59 2015 Mar 20 08:13:49 good morning Mar 20 08:25:06 hi mckoan Mar 20 08:32:31 morning all Mar 20 08:34:50 hi woglinde, bluelightning Mar 20 09:20:45 solar eclipse in 10 min. Mar 20 11:07:17 I am trying to find where rootfs' /etc/passwd is created, is it https://github.com/openembedded/oe-core/blob/master/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb#L61 ? Mar 20 11:18:18 funman: that is the basis of it, but it gets updated through recipes using useradd.bbclass and possibly extrausers.bbclass from the image recipe Mar 20 11:18:38 if you want to add to it the latter two methods are preferred Mar 20 11:21:28 I am building angstrom and want to find out why I end up with a 'root:*:' root password in shadow rather than 'root::' Mar 20 11:21:42 so I'm looking for a modification rather than an addition Mar 20 11:22:01 passwd.master has the expected 'root::' Mar 20 11:22:31 although it's part of base-passwd-update which wasn't part of the rootfs Mar 20 11:23:40 ah, that would perhaps be debug-tweaks in (EXTRA_)IMAGE_FEATURES Mar 20 11:24:49 hmm, wait... Mar 20 11:24:59 funman: ROOTFS_POSTPROCESS_COMMAND_remove = "zap_empty_root_password" Mar 20 11:25:00 meta/classes/image.bbclass:ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains_any("IMAGE_FEATURES", [ 'debug-tweaks', 'empty-root-password' ], "", "zap_empty_root_password ; ",d)}' Mar 20 11:25:10 Net147: thanks :D Mar 20 11:25:27 Net147: that's not really the recommended means of having a proper root password Mar 20 11:26:04 I somehow forget doing previous builds which had empty root passwords, I might Mar 20 11:26:10 *mis-remember though Mar 20 11:26:18 depends if you really want an empty password for root or not Mar 20 11:26:31 But it made me think I should rather add some SSH keys to root/.ssh/authorized_keys Mar 20 11:29:00 bluelightning: any thoughts on what we should do about the minimum kernel version when using systemd? Mar 20 11:30:45 Net147: I saw your patch - did that not address the issue? Mar 20 11:31:28 bluelightning: it does... but I wasn't sure if it was going to be accepted for M4 cutoff Mar 20 11:33:39 bluelightning: since it wasn't added to poky-contrib Mar 20 11:33:45 Net147: I've poked some people in #yocto about it Mar 20 11:34:52 bluelightning: thanks Mar 20 13:38:37 JaMa, any idea when meta-oe/master-next will be merged? Mar 20 14:20:53 first patch sent \o/ Mar 20 14:44:40 funman: thanks :) Mar 20 14:44:42 trying to figure out why i can't get "make menuconfig" working for a kconfig-based project. it inherits cml1, but when i run bitbake -c menuconfig, it fails to find curses.h and cannot compile the lxdialog bits. However, doing bitbake -c menuconfig on busybox or kernel works fine, and curses.h is in my native sysroot Mar 20 14:44:50 wow, how did we end up with no SRC_URI checksums in that recipe? Mar 20 14:53:44 bluelightning: shouldn't "gcc" point to my native gcc (built by OE) in a devshell? when "make menuconfig" runs it uses gcc to compile the lxdialog files. And it tries to include , which of course it won't find unless gcc isn't looking in the proper sysroot (i guess?). And by inspecting the cmdline passed to gcc, no additional include paths are provided by -I Mar 20 14:54:40 mag0: I don't believe so, no... $CC should provide the correct compiler command to use though Mar 20 14:55:31 bluelightning: for target compiling, yeah, but what about native stuff? i guess cml1 is a bit special, since it uses the native compiler to compile the menu stuff but it uses the crosscompiler for building the actual software Mar 20 14:56:33 ah yes... hmm Mar 20 14:57:08 bluelightning: in the busybox case, something adds -isystem/path/to/my/x86_64/usr/include .. this does not happen in my other kconfig-based project. I guess that's missing link here, and the reason to why it can't find curses.h Mar 20 14:57:31 *adds -isystem/... to my CFLAGS* Mar 20 14:58:25 maybe BUILD_CC ? Mar 20 15:05:41 hmm, I guess not, BUILD_CC is just gcc Mar 20 15:05:52 which of course makes perfect sense Mar 20 15:06:17 mag0: I wasn't thinking straight - there is no native gcc built by OE Mar 20 15:06:17 bluelightning: it seems like -isystem is passed to compilation. But only for some of the files, so i suspect there is something in this project that locally overrides the CFLAGS Mar 20 15:06:54 mag0: however BUILD_CFLAGS will give you the arguments to pass to it (including -isystem...) Mar 20 15:06:56 bluelightning: I wonder if in some way hg fetches did not verify checksums, just like git Mar 20 15:06:58 bluelightning: really? i thought it always built a native gcc using the gcc provided by host to ensure a reproducable environment Mar 20 15:07:22 I looked at bitbake bb/lib/fetch2 log but didn't see anything obvious Mar 20 15:07:56 funman: oh, right... yes, I missed it was fetching from mercurial - actually why do we need checksums at all then? Mar 20 15:08:42 maybe because it fetches a specific revision? Mar 20 15:09:10 actually the right patch could be to make bitbake ignore checksums for any hg fetch Mar 20 15:09:59 the thing is, we do regularly build vim AFAIK and apparently didn't see an error, so something strange is going on Mar 20 15:10:01 http://pastie.org/10042180 Mar 20 15:10:43 I added IMAGE_INSTALL += "vim" in my layer Mar 20 15:11:34 not sure what I could have done to get this error :/ Mar 20 15:12:13 I reused the downloads folder from a previous build Mar 20 15:19:11 bluelightning: aha! busybox-cross-menuconfig.patch seems to fix the same issue in busybox.. turns out it was HOST_EXTRACFLAGS getting overridden within the lxdialog build Mar 20 15:27:27 bluelightning: what's the best way to handle a RDEPENDS that changes with the kconfig? Mar 20 15:28:39 mag0: you could apply those at packaging time (from a populate_packages_prepend() python function) Mar 20 15:29:24 bluelightning: so that would involve parsing the .config and then adding to RDEPENDS? Mar 20 15:29:34 yes Mar 20 15:30:07 bluelightning: do you know of another recipe that does this? Mar 20 15:30:10 is this a dependency from a module package on another package? Mar 20 15:30:24 i.e. does it simply depend upon whether the module is there or not? Mar 20 15:30:27 Crofton: 1-2 days, jenkins is still running Mar 20 15:32:24 bluelightning: it's a monolithic program, and you can optionally make it use libcurl. so now i'm getting a warning from OE that my program depends on libcurl but it's not in RDEPENDS Mar 20 15:32:46 mag0: oh, I see Mar 20 15:32:49 JaMa, thanks Mar 20 15:33:04 mag0: just add it unconditionally to DEPENDS Mar 20 15:33:18 mag0: in this case it's not so big that you'd care if it had to be built first I would think Mar 20 15:33:56 that QA message could really do with some clarification IMO Mar 20 15:34:06 bluelightning: okay, so not add it to RDEPENDS then? Mar 20 15:34:12 cause it's really a RDEPENDS .. Mar 20 15:34:40 mag0: in the case of a library dependency the RDEPENDS will be figured out automatically (and already is, hence the warning) Mar 20 15:35:21 mag0: what it's telling you is "hey, there's nothing to ensure this thing is around at build time so a from-scratch build might fail in future" Mar 20 15:35:38 which is really DEPENDS, although an explicit RDEPENDS will also take care of it Mar 20 15:36:02 (as opposed to the implicit RDEPENDS that is being put in at packaging time in this instance) Mar 20 15:37:35 okay, thanks Mar 20 18:24:10 Is there anyway to put kernel-modules to be modularized on a yocto recipe ? Mar 20 18:25:48 realBigfoot: inherit module (or module-base)... there are some examples around Mar 20 18:26:19 bluelightning, i ran bitbake linux-yocto -c menuconfig Mar 20 18:26:26 and put M in some modules Mar 20 18:26:53 I'd like to put this on recipe instead of editing menuconfig Mar 20 18:27:09 i have tried use MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS, but it didn't work Mar 20 18:27:12 oh, right, I see Mar 20 18:27:27 you need to take the config it has generated and put it back into the kernel recipe Mar 20 18:27:27 if I use RDEPENDS it says that nothing provides the module :( Mar 20 18:27:31 s/yocto recipe/oe recipe/g Mar 20 18:27:46 the .config file you say? Mar 20 18:28:18 yes - this should be covered in the YP kernel manual: http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html Mar 20 18:28:46 there's some new stuff around generating config fragments from menuconfig changes, I don't know if that got documented or not Mar 20 18:29:43 bluelightning, alright I will have this figured out :) Mar 20 18:29:44 thanks Mar 20 19:33:01 bluelightning: it did, and it works Mar 20 19:33:37 pretty old in the kernel training thing, 1.4 i think... Mar 20 19:33:49 nerdboy: bluelightning is out (just in case you haven't realized). Mar 20 19:34:23 * nerdboy 's proxy missing some stuff i guess... Mar 20 19:34:37 yup Mar 20 19:36:38 realBigfoot: it's in here => https://www.yoctoproject.org/sites/default/files/kernel-lab-1.4.pdf Mar 20 19:37:17 nerdboy, nice!!! Thanks Mar 20 19:37:33 nerdboy, I got it figured out... i made a bbappend with a custom .config file and it worked nicely Mar 20 19:39:27 yeah, still need a .bbappend to add fragments too, so flip a coin... Mar 20 19:40:01 nerdboy, I see.... thaks :) Mar 20 19:40:08 meh Mar 20 19:40:30 Hmm, anyone have python folding working well in vim? Mar 20 19:40:38 not having it is starting to irk me, need to pick a plugin for it Mar 20 19:46:37 kergoth: as in http://www.vim.org/scripts/script.php?script_id=1494 ? Mar 20 19:48:37 yeah..some of those have performance issues due to the expr method, though, so was curious about actual experience with the alternatives Mar 20 19:54:15 that one comes with lady-of-vi recommendation Mar 20 19:54:20 * nerdboy hasn't tried it Mar 20 19:55:22 stephanie lives in screen/vi so i would expect it to be not-so-horrible... **** ENDING LOGGING AT Sat Mar 21 02:59:59 2015