**** BEGIN LOGGING AT Fri Mar 28 02:59:59 2014 Mar 28 09:28:10 hi. anyone familiar with the Freescale community BSP here? Mar 28 09:31:47 Hi everyone. Two quick questions: Why is "unset MACHINE" set in run.do_configure? Is there an easy way to keep MACHINE available during do_configure? Mar 28 09:34:31 morning all Mar 28 09:35:05 Good morning, bluelightning. Do you maybe know why "unset MACHINE" is set in run.do_configure? Is there an easy way to keep MACHINE available during do_configure? Mar 28 09:36:58 Denwid: that variable is explicitly unexported, because some software breaks when it's set to values that we have it set to Mar 28 09:37:36 Denwid: you may be able to do "export MACHINE" within the recipe to reverse it just for that recipe Mar 28 09:38:04 Ah, ok, I will try! Thanks a lot. Mar 28 10:02:14 hi. My custom image fails due to iconv binary conflicts with two packages (eglibc and libiconv) Mar 28 10:02:25 error: file /usr/bin/iconv conflicts between attempted installs of libiconv-1.14-r1.cortexa9_vfp_neon and eglibc-utils-2.18-r1.cortexa9_vfp_neon Mar 28 10:02:48 any quick fix? Mar 28 10:12:22 vicky_: with eglibc you don't need libiconv Mar 28 10:13:04 vicky_: i guess you've an explicit dependency on libiconv somewhere, use virtual/libiconv in DEPENDS Mar 28 10:13:26 thanks. i will try Mar 28 10:15:33 i'm trying to create a bsp for my board (using i.MX233 olinuxino maxi as prototype). yocto-bsp asks for value of UBOOT_MACHINE. what is that used for? Mar 28 10:21:24 ionte: we pass that directly to the make command line for u-boot, so I would suggest looking at the u-boot documentation for that Mar 28 10:21:36 ok, thanks Mar 28 10:41:00 rburton: It didnt work Mar 28 10:42:32 and also i am getting this error with qa image Mar 28 10:44:00 what qa image? Mar 28 10:44:45 with debug support Mar 28 10:46:29 my log at http://paste.org/71455 Mar 28 11:02:36 vicky_: probably something in hmi-image then Mar 28 11:04:44 try using depexp to find out where libiconv comes from. if you have eglibc you don't need it. Mar 28 11:06:16 is the order of SRC_URI in recipe equal to order of applying patches? (matters if they depend one on another) Mar 28 11:08:16 Xz: yes Mar 28 14:36:16 hi may somebody help me I cant build exo-native on yocto-poky master (1.5+snapshot-20140328) https://gist.github.com/Yenals/9834299 ... Mar 28 14:37:04 what do i do to build image with no modules and no kernel? i would like just to build userspace Mar 28 14:37:08 yenal: see oe-devel ML Mar 28 14:37:18 yenal: there is patch for that issue Mar 28 14:37:31 oh nice I'll search for this Mar 28 14:37:35 thank you Mar 28 14:37:46 Xz: remove the kernel from the image dependencies Mar 28 14:38:00 I have kernel-modules in image install Mar 28 14:38:07 removed that Mar 28 14:38:19 apparently it's not enough Mar 28 14:38:37 Xz: are you talking about build time dependencies or installed packages in image? Mar 28 14:38:38 I inherit core-image and poky-tiny Mar 28 14:38:55 I would like my kernel builder to never trigger Mar 28 14:39:24 then you'll find quite a few build time dependencies with bitbake -g your-image Mar 28 14:39:58 JaMa: so it's not as easy as changing one line in some file... Mar 28 14:41:54 you can add PNBLACKLIST for your kernel, that will highlight all places which need it, but it will be quite a lot Mar 28 14:46:20 Xz: pre master/1.6, packagegroup-core-boot pulls in virtual/kernel; in master, virtual/kernel:do_deploy is a dependency for all images Mar 28 15:06:08 so... i've created my custom bsp and i've managed to build a complete image. i now have multiple bin-files in the deploy directory Mar 28 15:06:30 is there any documentation about how to generate an sdcard-file, like Freescale BSP does? Mar 28 15:28:58 hey JaMa ty again, exo-native built with your hint (adding intltool-native to DEPENDS_class-native) but I'm still having trouble with other xfce recipes (sound-themes, xarchiver, mousepad, xfce4-taskmanager, xfce4-closebutton-plugin, xfce4-settings, xfwm4) Mar 28 15:28:59 e.g. themes is related to "macro 'AM_GLIB_GNU_GETTEXT' not found in library" ..is there an link to maillist for actual bugfixes regarding 1.5+snapshot-20140328? Mar 28 15:41:18 seems glib-gettext.m4 and/or xdt-i18n.m4 is missing in aclocal-copy/ ..but I'm to inexperienced to understand why Mar 28 15:42:08 yenal: missing build dependencies probably, glib-gettext is part of glib. not sure about xdt-i18n.m4. Mar 28 15:46:02 mmh okay..so the recipes are defective? otherwise yocto should take care of all dependencies Mar 28 15:57:11 ty rburton adding glib-2.0 intltool to DEPENDS of recipe worked .. I hope the rest of the xfce errors could be solved likewise Mar 28 16:00:14 yenal: correct, missing dependencies. we used to copy all of aclocal but now it just copies the bits you asked for. Mar 28 16:02:14 yes, I saw that behavior when comparing dora and master dirs - aclocal-copy is full of symlinks in master and normal files in dora Mar 28 16:02:49 yeah, in master we symlink the aclocal files provided by the build dependencies you specified Mar 28 16:06:18 okay... is there a bitbake command to look for the dependencies in dora branch to correct the recipes in master? Mar 28 16:06:55 the dependencies are not written down in dora, that's the problem Mar 28 16:07:06 the command from https://community.freescale.com/docs/DOC-94953 (Show package's dependencies) puts out quiet much Mar 28 16:07:10 you'll have to look up the files that it can't find and determine what recipe provided them Mar 28 16:07:23 okay damn :/ Mar 28 16:07:29 there should be some way of querying the manifeset Mar 28 16:07:33 manifest Mar 28 16:08:31 I try to change the root password, but am still not able to login as root. Even if I modify inittab by executing /bin/sh so I can set it via command line. if I create now another user and change it it works. Just root always fails with a wrong password message. securetty looks also fine. Mar 28 16:09:22 rburton can you give me a hint what to do if even no "aclocal-copy"-dir is created? Mar 28 16:11:41 volker- : did you build with debug-tweaks? Mar 28 16:12:19 yenal: no. just enabled image feature ssh-server-openssh Mar 28 16:12:52 yenal: I see the password change in /etc/shadow Mar 28 16:13:19 volker-: Is that with or without PAM? Mar 28 16:13:27 bunk: without pam Mar 28 16:14:04 So far as I recall I had the same problem when I build without debug-tweaks and even manual editing /etc/shadow didnt help Mar 28 16:14:05 what confuses me the most is that it works for regular user I create with useradd Mar 28 16:14:33 yenal: yeah, sounds like my issue. I don't want to use debug-tweaks to keep the image as small as possible Mar 28 16:14:50 volker-: Does it help to comment out the CONSOLE line in /etc/login.defs? Mar 28 16:17:12 maybe there is a way to set the rootpassword before building? Mar 28 16:18:10 at least.. afaik there was a feature request for that Mar 28 16:18:51 yenal: no, commenting out does not help, also not reenabling the other CONSOLE line that is commented out Mar 28 16:19:15 yenal: the only thing I find in various different ways is https://wiki.yoctoproject.org/wiki/FAQ:How_do_I_set_or_change_the_root_password Mar 28 16:21:51 mhh http://comments.gmane.org/gmane.linux.embedded.poky/7820 Mar 28 16:22:51 I think actually there is no other way than what is decribed in the wiki Mar 28 16:22:54 yenal: I saw this mail thread but it didn't help Mar 28 16:23:39 especially it seems to assume that you dont have openssh installed which use ssh-server-openssh Mar 28 16:23:50 s/ssh-server-openssh/shadow/ Mar 28 16:25:11 volker-: yenal: this has been added in master (for 1.6): http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=36fe775672d66e3d83575eb532eb6ab5109343b4 Mar 28 16:26:28 damnit Mar 28 16:27:18 yesterday I spend hours on it without success. today I tried again, then I start to ask here and now I notice that /etc/passwd lists "root:*:..." but a regular user with "user:x:..." Mar 28 16:27:37 change the * to x and voila Mar 28 16:28:26 volker-: which version are you using atm? Mar 28 16:28:45 bluelightning: 1.5.1 Mar 28 16:28:59 right, ok Mar 28 16:29:00 bluelightning: 023c35795ff8edd79bb27848a01dd49239f052d4 latest git commit Mar 28 16:29:41 volker-: I suspect that the * vs x is what the adjacent patch to the one I just posted fixes: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=c38fee231b42b9123dd1fd102235eac6240ba4c8 Mar 28 16:30:16 my company would like to build against the 1.5.1 you can download as tar to have a "repeatable stable" version Mar 28 16:30:39 sure, understood Mar 28 16:30:49 and we wouldn't recommend using master over the stable version either Mar 28 16:30:56 (for production usage, that is) Mar 28 16:31:02 Now when I want to create a wiki account to add additional information to the page I am asked for biography information I do not want to provide Mar 28 16:31:25 right now I use the git version because it supports ubuntu 13.10 Mar 28 16:31:50 volker-: sorry about that, we have struggled with spammers on our wiki; you can probably get away with entering "I'd rather not provide this - sorry" Mar 28 16:33:13 bluelightning: you seem to be familar with the code (you did changes;-). Can you explain me why you dont use 'sed -i'? Old sed compatibility? I haven't seen nonsupporting -i for a long time. Mar 28 16:34:21 hmm, let me have a look Mar 28 16:34:33 we definitely use sed -i in lots of other places Mar 28 16:35:22 yeah, but I see a lot of times it is not used. Maybe there was a policy behind it, maybe just writing style of developers. Mar 28 16:35:26 just curious :) Mar 28 16:35:29 volker-: ah, the current version after the patch above does use sed -i Mar 28 16:35:56 I think the code before that change was quite old Mar 28 16:36:01 bluelightning: yes, the old one does not. Mar 28 16:38:59 I also see that a lot of accounts in /etc/passwd have /bin/sh as shell Mar 28 16:41:29 hello Mar 28 16:42:09 i have just booted Mentor Embedded Linux Kits in Pandaboard ES from this link http://www.mentor.com/embedded-software/downloads/linux-kits/?cmpid=6929 Mar 28 16:42:26 but i can't run lttng Mar 28 16:42:52 "-sh: lttng: command not found" Mar 28 16:42:57 please help Mar 28 16:44:19 ben_: I'm not familiar with that particular offering - is lttng something that's expected to be provided as part of it? Mar 28 16:45:27 normally yocto version is compatible with LTTng (http://www.mentor.com/embedded-software/news/mentor-embedded-linux-platform-achieves-yocto-project-1-3-compatibility) Mar 28 16:46:04 ben_: we have lttng recipes yes, but we can produce all sorts of images, so that doesn't necessarily mean that every image will contain lttng Mar 28 16:46:48 so which image containes lttng for pandaboard Mar 28 16:48:02 you can add it to any image you want to build. see the local.conf examples for how to add packages to your image Mar 28 16:48:59 does someone have any idea how to fix: "mousepad/Makefile.am:72: error: HAVE_DBUS does not appear in AM_CONDITIONAL" for master (1.5+snapshot-20140328) written DEPENDS are gtk+ dbus-glib gtksourceview2 Mar 28 16:49:36 ben_ : add IMAGE_INSTALL_append = " lttng" to ../conf/local.conf Mar 28 16:49:43 how can i get it ? Mar 28 16:49:53 and rebuild Mar 28 16:51:31 get what? Mar 28 16:51:54 but be sure you have added the right "recipe name" by doing: bitbake -s | grep lttng Mar 28 16:52:11 ok i will try it Mar 28 16:52:17 thank you Mar 28 16:52:17 yenal: you mean package name (since it's IMAGE_INSTALL we're talking about) Mar 28 16:52:32 yes package name Mar 28 16:53:19 bluelightning: so zap_root_password seems to be the function which breaks it. Now, is there a way to a) remove that function execution or b) overwrite it (there doesnt seem to be a bbclassappend) Mar 28 16:53:59 bluelightning: I don't see in "bitbake core-image-minimal -e" how I could use it with a "VARIALBLE -= ..." Mar 28 16:54:46 volker-: you can re-define the function in your image recipe to blank it out or specify a modified version if you wish; or alternatively apply the patch from master I linked above to fix it in image.bbclass Mar 28 16:55:00 volker-: there is no -= Mar 28 16:55:36 bluelightning: ok, so I need to define my own image recipe then Mar 28 16:56:04 volker-: there is a _remove, but that is in master and it's not really suitable for variables that aren't strictly space-separated lists (ROOTFS_POSTPROCESS_COMMAND is effectively semicolon-delimited for the shell) Mar 28 16:56:55 volker-: if you're doing anything more than trivial experimentation then you probably want your own image recipe anyway, since you'll probably want to customise its contents Mar 28 16:57:04 you could use :=, worst case. e.g. FOO := "${@FOO.replace('something i don't want', '')}". not pretty, though :) Mar 28 16:57:55 bluelightning: my idea was: use the minimal, add packages you need in conf/local.conf, make small modifications via ROOTFS_POSTPROCESS_COMMAND, create one recipes and add them via IMAGE_INSTALL_append Mar 28 16:58:24 bluelightning: this way it seemes to be easier to jump from version to version without touching much of the code Mar 28 17:00:06 volker-: so the general idea of adding things on top as opposed to modifying the core is a good one, but we provide more appropriate mechanisms than making changes via local.conf (i.e. layers) Mar 28 17:00:30 volker-: in case you hadn't seen it: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#understanding-and-creating-layers Mar 28 17:01:20 generally what we recommend is customisations go into a distro layer (or machine/BSP layer if they are specific to a particular machine) and then those parts are individually re-usable and easy to keep the same Mar 28 17:01:22 bluelightning: yeah, I understand the layer, but looking at the image layer gives me the impression that this leads to a lot of ducplicate code. Mar 28 17:01:45 local.conf changes are easy to miss out if you have to reproduce your setup, resulting in different output than you would expect Mar 28 17:02:45 volker-: it shouldn't, since the idea for the most part is to just add your changes on top (via bbappends, your preferred variable values in the distro / machine .conf instead of the default, etc.) Mar 28 17:03:24 image recipes are really the only place where copy-and-modify (into your own layer) is the best approach since they don't tend to have much that you don't want to override anyway Mar 28 17:04:45 bluelightning: from my understanding I need to copy the entire default image.bbclass file and modify ony one smaller part to get what I want. So all the other code is duplicate and I have to deal with these chagnes everytime there is a new version Mar 28 17:05:10 he just told you that you can override the class's function in the recipe Mar 28 17:05:11 :) Mar 28 17:05:14 volker-: that's not what I was suggesting Mar 28 17:06:05 volker-: there are two ways around this problem - apply the patch I pointed out on top of the core, which is a safe change because you can be assured it will be in the next stable release (1.6); or provide a modified version of the function in your image recipe Mar 28 17:07:58 bluelightning: ok, I think I can't follow then the second part if it does not require duplicate code (beside the function I want to overwrite) Mar 28 17:08:31 bluelightning: when you state image recipe, do you mean image class / a bbclass file? Mar 28 17:09:12 volker-: no, I mean the image recipe file, e.g meta/recipes-core/images/core-image-minimal.bb Mar 28 17:11:30 bluelightning: and functions I define there are overwriting functions of inherited classes? Mar 28 17:12:18 volker-: in that specific recipe after the inherit line, for 'bitbake core-image-minimal', yes Mar 28 17:12:59 volker-: (you'd copy that file to somewhere else, customise it and then build it instead in the ideal case) Mar 28 17:14:15 bluelightning: ok, let me try it. I think I missunderstood one part of it and got mixed up of classes and recipes. Mar 28 17:22:39 volker-: ok, no problem Mar 28 17:28:12 the parser seems to be somewhat sensitive. zap_root_password () { } does not work, you need to have something like zap_root_password () {\n echo 'dummy' > /dev/null\n} Mar 28 17:28:53 just use : for the line, not the echo Mar 28 17:28:56 shell no-op Mar 28 17:29:09 zap_root_password () {\n :\n} Mar 28 17:29:37 interesting, didn't know that there is a shell no-op :) Mar 28 17:47:44 bluelightning: seems to work find, thanks for the hint. Seems like I though too complicated about it :) Mar 28 17:52:45 volker-: cool, no worries Mar 28 17:53:44 bluelightning: yeah, learning curve of it. Hope the book will be released soon Mar 28 17:57:37 how can I overwrite the PACKAGE_CLASSES in my image recipe? If I set PACKAGE_CLASSES="package_deb" and the local.conf has the default ?="package_rpm", the ?= still overwrites it. Now the bitbake user manual states that ?= only overwrites it if it wasn't set before Mar 28 18:14:48 volker-: PACKAGE_CLASSES must be set somewhere "higher" than the image recipe, since it controls how other recipes' packages are produced Mar 28 18:15:14 volker-: so it would need to be set in local.conf or more concretely your custom distro config assuming you have created one Mar 28 18:23:59 bluelightning: if I change the distro I have to set it in conf/local.conf, too? Mar 28 18:24:56 volker-: you do need to set DISTRO to point to your new distro configuration, yes (the name of it) Mar 28 18:25:21 if you mean do you need to set PACKAGE_CLASSES in two places, no Mar 28 18:26:05 if the distro config sets it with = it will override whatever is set in local.conf Mar 28 18:26:19 bluelightning: no, I meant I have to touch local.conf anyway. either for the DISTRO or for the PACKAGE_CLASSES Mar 28 18:26:48 for the DISTRO yes, for PACKAGE_CLASSES if the distro config sets it as above, no Mar 28 18:28:39 bluelightning: how do I know in what kind of layer I have to set something. Like "NOISO" or "PACKAGE_CLASSES" Mar 28 18:30:29 volker-: being that those aren't really tied to the machine you're building for I would say those are distro configuration candidates, and a distro layer would be the place for that Mar 28 18:35:29 bluelightning: looking at the distrolayer, how can I just build a layer over an existing distro? Mar 28 18:43:27 volker-: you can do that to add recipes or bbappends, but if it's distro configuration you want to specify, you should just create your own distro config (possibly a copy of the one you are modifying) Mar 28 18:43:43 the one you are basing it on I mean Mar 28 18:44:32 volker-: again, the defaults are mostly set by the core automatically, so the distro config should only need to set the things you want to be different from those defaults Mar 28 18:45:18 volker-: (for reference, the core defaults are in meta/conf/bitbake.conf and meta/conf/distro/defaultsetup.conf + some inc files that the latter pulls in) Mar 28 18:46:01 yeah, but right now I use poky which is a little bit bigger Mar 28 18:54:15 volker-: a little, but not a lot Mar 28 18:55:42 when do I use the distro, when the image layer when installing image features and additional files? Mar 28 18:56:41 volker-: you'd put your image(s) and additional non-machine-specific customisations into the distro layer as well usually Mar 28 18:56:49 I see PACKAGE_CLASS as an image feature, but somehow I cant use it there Mar 28 18:57:56 volker-: as I mentioned earlier, PACKAGE_CLASSES controls how every recipe produces packages, so it must be set at a level that can influence how those other recipes are packaged; the image recipe (or indeed any individual recipe) isn't at that level Mar 28 19:00:03 bluelightning: so you say that non-machine-specific customizations should go to the distro layer. If I check the reference system I see in core-image-sato-dev.bb that the images features are in the image layer. Mar 28 19:00:37 volker-: "image layer" isn't a concept that we really have Mar 28 19:00:52 sorry I've got to head out now, will possibly be back later Mar 28 21:40:54 /OE/build/oe-core/tmp-eglibc/sysroots/qemux86/usr/include/crypto/cryptodev.h Mar 28 21:40:54 Matched in manifest-qemux86-ocf-linux.populate_sysroot Mar 28 21:41:16 ^ as someone was discussing ocf-linux removal on ML, another case where we need those sysroot providers **** ENDING LOGGING AT Sat Mar 29 03:00:00 2014