**** BEGIN LOGGING AT Mon Sep 23 02:59:59 2013 Sep 23 07:37:52 morning all Sep 23 08:14:04 good morning Sep 23 08:20:25 morning #oe Sep 23 08:23:12 hi silvio*, all Sep 23 08:25:33 :-) Sep 23 08:27:46 :) hi mckoan, hi silviof , hi * Sep 23 08:39:53 morning all Sep 23 08:46:31 hi jackmitchell Sep 23 10:15:00 hi. is it possible to 'customize' an existing distro.conf file within another layer? i need to make an additional layer that can potentially touch some of my main layer distro config. is that possible? Sep 23 10:18:41 ndec: you'd have to create a separate distro config that brought in the first one with "require" Sep 23 10:19:03 bluelightning: but then it's a different distro name, right? Sep 23 10:19:13 correct, yes Sep 23 10:19:24 that's what i wanted to avoid, if possible. Sep 23 10:20:22 I would have thought that if you change the configuration it's potentially not really the same distro anymore Sep 23 10:20:25 if 2 layers have distro.conf, i guess the file from layer with higher priority is used? Sep 23 10:20:41 conf files are found using BBPATH not layer priority Sep 23 10:20:50 ok. Sep 23 10:22:08 if you ensured that your second layer prepended to BBPATH and was listed last (or alternatively listed first if all other layers append to BBPATH) then it'll be picked up before the other layer Sep 23 10:22:35 but that creates potential for confusion and misconfiguration... Sep 23 10:22:44 bluelightning: i can probably ensure that in our distro setup scripts. Sep 23 10:23:09 but then would i be able to include the 'other' distro.conf file? Sep 23 10:23:20 i understand i am trying to do something tricky... Sep 23 10:24:34 my use case is that my 'distro' can be 'extended' with proprietary bits, that not everyone might have access too. so for folks with super power who can access the proprietary bits, i don't want to 'change' distro. Sep 23 11:13:08 I;ve got an issue with lmsensors Sep 23 11:13:29 I am trying to just install lmsensors-libsensors Sep 23 11:13:50 however because of packages defined in INITSCRIPT_PACKAGES Sep 23 11:14:07 it is pulling in lmsensors-fancontrol and lmsensors-sensord Sep 23 11:14:41 is there a way to make INITSCRIPT_PACKAGES not pull in these as dependancies unless the packages themselves are depended upon? Sep 23 11:14:44 I have tried Sep 23 11:14:51 INITSCRIPT_PACKAGES_${PN}-fancontrol = "${PN}-fancontrol" Sep 23 11:14:51 INITSCRIPT_PACKAGES_${PN}-sensord = "${PN}-sensord" Sep 23 11:15:21 but inherit update-rc.d balks due to requiring an INITSCRIPT_PACKAGES var Sep 23 11:40:28 as DEPLOY_DIR_IMAGE contains now ${MACHINE}, does it still make sense that all the files there contain ${MACHINE} too? Sep 23 11:48:56 ensc|w: personally I'd prefer that they still did so I know what I have when I download them from the build machine into the same directory on my local machine Sep 23 11:50:34 ensc|w: but it should be possible for you to remove that if you don't want it simply by setting IMAGE_NAME and IMAGE_LINK_NAME as desired in your own configuration Sep 23 11:53:09 bluelightning: why was MACHINE added to DEPLOY_DIR_IMAGE? imo, this just makes paths deeper and more complicated to reach Sep 23 11:55:45 ensc|w: if you build for a number of different machines it keeps the files for each machine separate Sep 23 11:56:20 ensc|w: if you prefer the old layout you can easily set DEPLOY_DIR_IMAGE back Sep 23 12:03:36 I think I will reset it to the old value; I do not have a use case for building for multiple machines with the same project setup Sep 23 12:03:50 fair enough Sep 23 12:10:54 ensc|w, for people that build multiple mchiens (I do) it is a huge win Sep 23 12:30:19 Crofton|work: I use oe with multiple machines (omap3,4, pxa270, pxa168, imx6, imx28) plus lot of derived customer platforms, but do not see much sense into moving ${MACHINE} to the end of the path. I split machines at the project level; common stuff is moved into a common layer Sep 23 14:26:20 Hello everybody. Do you think that it is possible to slightly modify OE to include a virtual machine or a linux container in my image ? Sep 23 14:27:22 vadmeste: certainly possible Sep 23 14:28:25 vadmeste: probably the way to do it would be to construct the "image" for the virtual machine first and then separately construct the real image which would copy the contents of the vm image into it Sep 23 14:31:04 bluelightning: okay.. so OE doesn't officially support that and I have to tweak OE source files to have an image with a linux container and two rootfs, right ? Sep 23 14:31:16 vadmeste: correct Sep 23 14:31:39 bluelightning: thanks you very much bluelightning Sep 23 14:32:26 doesn't officially support is a strong way of putting it - there are no public examples of that sort of thing but its basically how a rootfs with an embedded initramfs works, which is what the hddimg files are. Sep 23 14:32:57 vadmeste: maybe the meta-virtualization layer has something you could use? http://layers.openembedded.org/layerindex/branch/master/layer/meta-virtualization/ Sep 23 14:40:48 tlwoerner: I would like to have an image which already has more than rootfs with virtualization enabled and working... Sep 23 15:02:04 Hi Sep 23 15:02:27 debugging a kernel oops on imx6 Sep 23 15:03:01 would like to run gdb but there is no /proc/kcore Sep 23 15:03:31 defconfig included CONFIG_PROC_KCORE Sep 23 15:19:14 padge_: fs/proc/Kconfig: bool "/proc/kcore support" if !ARM Sep 23 15:25:56 huh? why is it disabled for arm? Sep 23 15:29:57 if you google it there is some history Sep 23 15:33:27 so, if you use OE, no kernel debugging for you :/ Sep 23 15:34:28 this is not an OE thing at all Sep 23 15:34:56 mainline Linux kernel Sep 23 15:35:12 oh. Sep 23 15:36:02 thanks, so how do others go about debugging a kernel oops? Sep 23 15:36:53 printk? Sep 23 15:46:27 isnt there a builtin kernel debugger? Sep 23 15:46:31 perhaps try ##linux Sep 23 17:46:26 khem, ping Sep 23 17:52:00 Crofton|work: hey Sep 23 17:52:26 I still have this issue: http://pastebin.com/pLUtXHRC Sep 23 17:52:33 I need to figure it out :) Sep 23 17:53:05 remind me the env var to check Sep 23 17:54:42 DISTRO_FEATURES_LIBC Sep 23 17:54:51 and DISTRO_FEATURES_LIBC_DEFAULT Sep 23 17:54:57 tell me what do you have in those Sep 23 17:55:28 then also DISTRO_FEATURES Sep 23 17:56:29 DISTRO_FEATURES += " opengl x11" Sep 23 17:56:35 I ahd to add those to get it to parse Sep 23 17:56:41 I wonder if I did that wrong? Sep 23 17:58:09 DISTRO_FEATURES_LIBC_DEFAULT="ipv4 ipv6 libc-backtrace libc-big-macros libc-bsd libc-cxx-tests libc-catgets libc-charsets libc-crypt libc-crypt-ufc libc-db-aliases libc-envz libc-fcvt libc-fmtmsg libc-fstab libc-ftraverse libc-getlogin libc-idn libc-inet-anl libc-libm libc-locales libc-locale-code libc-memusage libc-nis libc-nsswitch libc-rcmd libc-rtld-debug libc-spawn libc-streams libc-sunrpc libc-utmp l Sep 23 17:58:09 ibc-utmpx libc-wordexp libc-posix-clang-wchar libc-posix-regexp libc-posix-regexp-glibc libc-posix-wchar-io" Sep 23 17:58:20 DISTRO_FEATURES_LIBC="ipv4 ipv6 libc-backtrace libc-big-macros libc-bsd libc-cxx-tests libc-catgets libc-charsets libc-crypt libc-crypt-ufc libc-db-aliases libc-envz libc-fcvt libc-fmtmsg libc-fstab libc-ftraverse libc-getlogin libc-idn libc-inet-anl libc-libm libc-locales libc-locale-code libc-memusage libc-nis libc-nsswitch libc-rcmd libc-rtld-debug libc-spawn libc-streams libc-sunrpc libc-utmp libc-utm Sep 23 17:58:21 px libc-wordexp libc-posix-clang-wchar libc-posix-regexp libc-posix-regexp-glibc libc-posix-wchar-io" Sep 23 18:00:31 OK that looks ok Sep 23 18:00:37 now show me DISTRO_FEATURES Sep 23 18:01:05 first thing I posted Sep 23 18:01:39 DISTRO_FEATURES += " opengl x11" Sep 23 18:01:51 that is local.conf Sep 23 18:02:01 checking what bitbake sees Sep 23 18:02:57 DISTRO_FEATURES_DEFAULT="alsa argp bluetooth ext2 irda largefile pcmcia usbgadget usbhost wifi xattr nfs zeroconf pci 3g nfc x11" Sep 23 18:03:05 DISTRO_FEATURES="opengl x11 pulseaudio sysvinit" Sep 23 18:04:39 Crofton|work: are you sure that the += works? DISTRO_FEATURES are filled in an odd way where the += might not work Sep 23 18:04:48 no :) Sep 23 18:05:14 do you have another suggestion Sep 23 18:06:50 Crofton|work: _append Sep 23 18:07:08 and if you use _append don't forget the leading space in the value you append ;) Sep 23 18:07:20 should it make a difference? Sep 23 18:08:54 the leading space does yes or you'll munge the last item in the default value and the first item in your appended value together Sep 23 18:09:29 I now about the leading space :) Sep 23 18:09:31 the problem is the default value of DISTRO_FEATURES is set using ?=, and local.conf is parsed before distro config, so if you set it using += it'll already be set by the time the ?= is parsed and thus the latter will never happen Sep 23 18:09:56 ok Sep 23 18:10:01 I think the moral of the story is if you want to set DISTRO_FEATURES, have a proper distro config Sep 23 18:10:32 the headache is it seems now we have to chose theones I am setting Sep 23 18:10:44 for some reason Sep 23 18:11:10 in what context? Sep 23 18:11:20 oe-core build without any distro config Sep 23 18:11:31 build of what? for what MACHINE? Sep 23 18:11:38 some custom machine :) Sep 23 18:12:40 the default value of DISTRO_FEATURES in OE-Core already contains x11 Sep 23 18:12:47 it doesn't contain opengl though Sep 23 18:13:42 what actually fails? Sep 23 18:14:19 hmm Sep 23 18:14:22 libc Sep 23 18:14:31 trying again with append ni case Sep 23 18:14:59 if you mean the libc error you pasted above that was a result of the += effectively wiping out all of the libc features, so that shouldn't have been the original problem Sep 23 18:15:29 Crofton|work: fwiw, in our distro, we construct DISTRO_FEATURES as http://pastebin.com/xtNYG7da (user can specify extra features with PROJECT_FEATURES and remove them with NO_PROJECT_FEATURES) Sep 23 18:35:51 changing the DISTRO_FEATURES line in local.conf from += to _append seems to solve the issue Sep 23 18:37:15 Crofton|work: using _append/_prepend ensures nobody can override a variable (or at least that is my understanding) Sep 23 18:37:53 that sounds like agood way to remember this Sep 23 18:39:03 i'm confused because my understanding is that +=/=+/.=/=. don't work with overrides and _append/_prepend do Sep 23 18:39:17 tlwoerner: what's the semantic of PACKAGE_CONFIG_class-native ??= "..." ;) Sep 23 18:39:17 but if you want to make sure nobody can override a variable, one uses _append/_prepend Sep 23 18:40:41 ensc|w: ??= indicates a very late binding if nothing else is so defined, but i have no idea how it plays with overrides (or not), i'm certainly no bb expert! Sep 23 18:42:45 we have a lot of such constructs in oe-core and I remember at least one case (util-linux) where it does not work as expected Sep 23 18:43:15 perhaps, ??= in overrides should be forbidden because nobody can explain how it works ;) Sep 23 19:26:43 if i want to enable ICU support in qtbase (meta-qt5, master) all i should need to do is to put the following in conf/local.conf, no? Sep 23 19:26:46 PACKAGECONFIG_qtbase += "icu" Sep 23 19:35:27 tlwoerner: hmm,_append, no? for exactly the same reason as above. no? Sep 23 19:36:04 note that you can check the value to see if it's set properly. bitbake -e qtbase Sep 23 19:41:06 ndec: thanks for the tip Sep 23 19:41:19 tlwoerner: does it work? Sep 23 19:41:45 i have tried both PACKAGECONFIG_qtbase += "icu" and PACKAGECONFIG_qtbase_append = " icu" and neither seem to work Sep 23 19:42:47 previously i had done this sort of thing in a .bbappends, this time i'm trying it in conf/local.conf. does it make sense to try it there? Sep 23 19:43:16 :q Sep 23 19:43:24 haha, whoops, wrong window Sep 23 19:47:57 interesting... i was able to affect the PACKAGECONFIG of qtbase by only modifying conf/local.conf, that's nice Sep 23 19:48:20 on the other hand, by only adding icu i ended up getting a whole bunch of x11 stuff pulled in too Sep 23 19:48:40 by default my qtbase PACKAGCONFIG consisted of: Sep 23 19:48:56 "release dbus udev evdev widgets openssl fontconfig freetype jpeg libpng zlib pulseaudio" Sep 23 19:49:05 after add the following line to conf/local.conf Sep 23 19:49:12 PACKAGECONFIG_DISTRO += "icu" Sep 23 19:49:21 qtbase's PACKAGECONFIG is now Sep 23 19:49:33 "release dbus udev evdev widgets openssl gl xcb xvideo xsync xshape xrender xrandr xfixes xinput2 xinput xinerama xcursor gtkstyle fontconfig freetype jpeg libpng zlib pulseaudio icu" Sep 23 19:49:41 PACKAGECONFIG_DISTRO?? Sep 23 19:50:07 ndec: i looked through the qtbase.inc file to see what i could affect, PACKAGECONFIG_DISTRO was one that was available Sep 23 19:50:26 PACKAGECONFIG ??= " \ Sep 23 19:50:26 release \ Sep 23 19:50:26 dbus \ Sep 23 19:50:26 udev \ Sep 23 19:50:26 evdev \ Sep 23 19:50:26 widgets \ Sep 23 19:50:28 openssl \ Sep 23 19:50:30 ${PACKAGECONFIG_GL} \ Sep 23 19:50:32 ${PACKAGECONFIG_FB} \ Sep 23 19:50:34 ${PACKAGECONFIG_X11} \ Sep 23 19:50:36 ${PACKAGECONFIG_FONTS} \ Sep 23 19:50:38 ${PACKAGECONFIG_SYSTEM} \ Sep 23 19:50:42 ${PACKAGECONFIG_MULTIMEDIA} \ Sep 23 19:50:44 ${PACKAGECONFIG_DISTRO} \ Sep 23 19:50:46 " Sep 23 19:50:48 maybe _SYSTEM instead? Sep 23 19:51:56 although i still think what i was attempting before should somehow work (i.e. PACKAGECONFIG_qtbase +=/_append = " icu") Sep 23 19:53:28 tlwoerner: well, it's not quite a good idea to modify .bb variables from local.conf anyways. you need to postfix with _qtbase. Sep 23 19:56:53 ndec: weird! if i put 'PACKAGECONFIG_SYSTEM += "icu"' in conf/local.conf i get a result that includes icu Sep 23 19:57:18 but if i change that to 'PACKAGECONFIG_SYSTEM_qtbase += "icu"' i don't get icu included in the result Sep 23 19:58:05 well, i don't know about that... i think in our situation using .bbappend might be cleaner anyways. Sep 23 19:58:43 ndec: okay, thanks **** ENDING LOGGING AT Tue Sep 24 02:59:59 2013