**** BEGIN LOGGING AT Mon Sep 30 02:59:58 2013 Sep 30 07:23:44 morning! Sep 30 07:52:56 good morning Sep 30 08:32:42 hello everyone. I am trying to use a toochain from meta-sourcery layer - Mentor Graphics(Code Sourcery) - and I get the following error when building a recipe: ERROR: ExpansionError during parsing /media/sdc1/fb/alvd/test/broadcom/poky/meta-sourcery/recipes/meta/external-sourcery-toolchain.bb: Failure expanding variable sysroot_stage_all: ShellSyntaxError: LexToken(LPARENS,'(',0,0) followed by: LexToken(TOKEN,'GCC-r22/sysroot-destdir/ Sep 30 08:33:25 Can you offer some suggestions, or hints for solving this error. Sep 30 08:33:34 Thank you, Alex Sep 30 08:41:48 morning all Sep 30 09:39:33 Morning all! Sep 30 09:40:35 Is there a way that in my layer I can "undo" things added from a layer I'm inheriting from. i.e. Ive inherited from someone elses BSP but they've included some demo apps which I don't want to have included in the image. Sep 30 09:40:50 Also they used udhcpc which I want to take out and go back to static IP... Sep 30 09:43:06 pev: Have you tried IMAGE_INSTALL_remove = "udhcpc" ? Sep 30 09:43:28 pev: Assuming you're using master of Poky... Sep 30 09:45:37 Saur: I havent - didn't know it existed! I'll give that a go now, thanks Sep 30 09:46:22 pev: It's new in the upcoming 1.5 release AFAIK. Sep 30 09:48:29 yes, only appeared in git a few weeks back. Sep 30 09:50:21 Saur: Ah, dont think it exists in my build then yet.... Do you know if it'll be a simple feature merge? Sep 30 09:50:27 Sounds like it'd be very handy Sep 30 09:50:59 pev: It requires a new version of BitBake Sep 30 09:51:29 Ah... Sep 30 09:51:38 easiest thing to do would be to use your own image recipe; failing that, just bbappend the image recipe and set IMAGE_INSTALL outright Sep 30 09:53:31 Hm, looking at it I think udhcpc is a bit of an oddity as it's coming in as part of busybox by the looks of it so outside the scope of IMAGE_INSTALL... :-/ Sep 30 09:54:45 well, it is a separate package; it can be installed or not Sep 30 09:55:08 although it is recommended by busybox Sep 30 09:55:31 you can set your own busybox defconfig in your layer with a bbappend Sep 30 09:55:43 (or even change the RRECOMMENDS) Sep 30 09:56:53 Yeah, I've already got a bbappend for busybox.... We talked about it ages ago as I didn't realised it had to be a bit hacky and use sed in an do_prepare_config_append Sep 30 09:57:36 But I guess that's not the right thing to do to remove it as busybox-udhcpc is actually a package as opposed to a config option munge? Sep 30 09:57:37 depending on which version of the build system you are using, busybox recipe supports config fragments Sep 30 09:58:00 It's 10.4 + few extra merges from upstream Sep 30 09:58:23 I think when I tried before config fragments didnt work though... Sep 30 09:58:53 you could just try RRECOMMENDS_${PN} = "${PN}-syslog" in your busybox bbappend Sep 30 10:04:38 bluelightning: Sorry for being thick but how does the override ${PN}-udhcpc ? Sep 30 10:05:44 pev: the original recipe (at least in master) has ${PN}-udhcpc in RRECOMMENDS_${PN} Sep 30 10:05:55 I'm assuming that's how it's being pulled in in your case Sep 30 10:07:22 Doh! I see so you just rewrite the whole var to equal what it was without the udhcpc... Gotcha, thanks! :-) Sep 30 10:09:08 That looks better - is there an idiomatic way under yocto to configure static IP's via the init instead or should I just roll my own as appropriate? Sep 30 10:11:48 I think the standard way is to just provide your own interfaces file by bbappending init-ifupdown (or netbase in versions prior to 1.4) Sep 30 10:45:24 bluelightning: Ah, like http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/tree/meta-sys940x/recipes-core/init-ifupdown?h=dylan Sep 30 10:46:40 pev: pretty much, except that the only line you need in the bbappend is the FILESEXTRAPATHS_prepend line Sep 30 10:53:12 bluelightning: Thanks... I like the look of the PRINC trick - is that pretty standard? Sep 30 10:53:49 pev: it's not really needed anymore with dylan and later assuming you enable the PR service - PR will be incremented automatically in that case Sep 30 11:04:40 bluelightning: Actually, after all that I'll probably have to re-write ifupdown anyway... :-/ Sep 30 11:06:07 bluelightning: I need to do RFC5227 (ish) conflict detection and will prob be better off managing directly looking at it... Sep 30 11:36:25 hi, is it expected that SPL is not built when building u-boot? Sep 30 11:41:52 I should set the SPL_BINARY variable, or why it is empty by default? Sep 30 11:41:56 (u-boot.inc) Sep 30 11:48:41 http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-bsp/u-boot/u-boot.inc#n31 -> based on this, it should run make foo; make all where "foo" is my target, right? Sep 30 12:28:23 WARNING: Host distribution "Unknown" has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution. -> hmm, using debian 7.0 wheezy, and /etc/issue contains that properly. Why am I still getting such a warning then with dylan? Sep 30 12:37:36 lpapp: install lsb-release Sep 30 12:37:56 rburton: it is. Sep 30 12:38:44 iirc, the old code reads /etc/debian_version, and the new code reads the LSB release files Sep 30 12:38:56 so i presume you've base-files installed Sep 30 12:39:37 surew Sep 30 12:39:38 sure* Sep 30 12:44:47 rburton: I am getting loads of these license warnigns as well: http://paste.kde.org/~lpapp/p4176da50/ Sep 30 12:45:56 that might be related to the unknown distribution? Sep 30 12:46:26 lpapp: nope, the distro warning is a one-off sanity that has no bearing on anything else. *do* those files exist? Sep 30 12:48:43 rburton: I will check in a few hours when the build is over Sep 30 12:49:08 oh, I can do that with a trick now, too. Sep 30 12:49:12 yes, those files do exist. Sep 30 12:49:26 perms right? Sep 30 12:49:35 that codepath clearly needs better error handling Sep 30 12:49:45 I raised two months ago Sep 30 12:49:54 it* Sep 30 12:50:09 rburton: 0644 Sep 30 12:50:29 i suspect the target directory has bad perms then Sep 30 12:50:32 wherever that is Sep 30 12:51:17 easily debugging your end by putting a print statement into license.bbclass to find out where its trying to write, and then checking the perms of that directory. Sep 30 12:53:42 rburton: what statement? Sep 30 12:54:00 copy_license_files has that message in Sep 30 12:59:07 rburton: wouldn't it be enough to check the target directory permission? Isn't that somewhat "static" we can do with a print? Sep 30 12:59:19 yes, exactly that Sep 30 12:59:29 throw a print in to get the path its writing to, and then check the perms Sep 30 12:59:48 s/with/without/ Sep 30 13:00:07 the problem is that the process is running, and I cannot throw. Sep 30 13:00:21 that is why I thought just checking with ls -l would be possible for now before the long build finishes. Sep 30 13:01:43 a single control-c will abort the build cleanly (letting the current tasks finish) if you want to look at it now, or you can trace back and determine where its writing to. Sep 30 13:02:41 can I have gcc installed by default in my uclibc image? Sep 30 13:05:38 rburton: ok, the process has now just finished. Sep 30 13:05:42 Krz-: certaily, should just be a matter of adding "gcc" to IMAGE_INSTALL Sep 30 13:05:45 how can I retrigger it with /clean/ state? Sep 30 13:05:55 to get the warnings again withour hours of rebuilding. Sep 30 13:06:34 Krz-: you may also want "gcc-symlinks", not sure Sep 30 13:09:14 lpapp: new tmpdir, share sstate, will be very quick. Sep 30 13:09:21 depends if the error happens every build or not Sep 30 13:09:27 as i've never seen it, i can't comment Sep 30 13:09:38 rburton: hmm, I was wrong. Sep 30 13:10:31 rburton: print('Test: %' %destdir) did not print out anything. :/ Sep 30 13:10:45 yet, I am getting the warnings if I just run "bitbake core-image-minimal" without the clean up. Sep 30 13:11:27 use bb.warn, maybe the prints are getting sucked into a log file Sep 30 13:14:17 rburton: right, that works. Sep 30 13:14:44 644 on the printed folders. Sep 30 13:14:46 is that wrong? Sep 30 13:14:49 hmm, it is. Sep 30 13:14:55 it should have the executable bit, maybe. Sep 30 13:15:05 I do not know if bitbake steps into or not. Sep 30 13:15:12 yeah, directories with +x are pretty useless Sep 30 13:15:14 but for getting the file, you have to. Sep 30 13:15:17 no? Sep 30 13:15:23 without, even Sep 30 13:15:29 right Sep 30 13:15:33 so why does it have the wrong perms? Sep 30 13:15:41 Anyway, sounds like a bugreport for error reporting. Sep 30 13:15:49 a umask when seriously wrong somewhere. Sep 30 13:15:56 yes, file a bug. Sep 30 13:16:02 no idea how to replicate though. Sep 30 13:16:14 tell me to run the command. :} Sep 30 13:16:40 umask Sep 30 13:16:41 0022 Sep 30 13:16:45 that looks good to me. Sep 30 13:17:53 rburton: the parent has the executable bit. Sep 30 13:19:11 rburton: where is destdir created? Sep 30 13:20:24 not sure, sorry. Sep 30 13:20:59 rburton: your permission is 755? Sep 30 13:21:58 lpapp: presumably, as you can't do a lot on a directory without x bits Sep 30 13:22:05 132 def copy_license_files(lic_files_paths, destdir): Sep 30 13:22:05 133 bb.warn('TEST: %s' %destdir) Sep 30 13:22:06 134 bb.mkdirhier(destdir) Sep 30 13:22:07 hier? Sep 30 13:22:18 hierarchy Sep 30 13:22:19 ah, hierarchy, not the german "hier" (here) Sep 30 13:22:20 yes Sep 30 13:22:42 rburton: well, I would still encourage to double check. Sep 30 13:23:04 lpapp: you'll need to tell me what directory its poking at then Sep 30 13:23:20 I can copy files out of 644 folders when doing a quick test on my host. Sep 30 13:23:34 as a simple user in my home folder. Sep 30 13:24:09 http://paste.kde.org/~lpapp/p274f6666/ -> here is the proof. Sep 30 13:25:12 rburton: e.g., /home/lpapp/Projects/polatis/Yocto/poky-dylan-9.0.1/build/tmp/work/x86_64-linux/libgpg-error-native/1.11-r0/license-destdir/libgpg-error-native Sep 30 13:25:25 poky-dylan-9.0.1/build/tmp/work/x86_64-linux/python-setuptools-native/0.6c11-ml5/license-destdir/python-setuptools-native Sep 30 13:25:33 build/tmp/work/x86_64-linux/libffi-native/3.0.11-r1/license-destdir/libffi-native Sep 30 13:25:38 build/tmp/work/x86_64-linux/libcap-native/2.22-r5/license-destdir/libcap-native Sep 30 13:25:47 build/tmp/work/x86_64-linux/libgcrypt-native/1.5.0-r2/license-destdir/libgcrypt-native Sep 30 13:25:52 such things. Sep 30 13:28:11 bb.copyfile looks ok to me at first. Sep 30 13:30:17 (it seems to handle any error case) Sep 30 13:37:44 sgw_: I am looking at u-boot build failure in meta-fsl-arm Sep 30 14:01:20 zeddii: already working on 3.12-rc with linux-yocto-dev? Sep 30 14:04:03 yep. should be out in a day or so. finishing up some 3.10 bug squashing as well. Sep 30 14:05:41 great Sep 30 15:44:27 hmm, is there any documentation anywhere on setting the default shell? Sep 30 15:45:11 or is it just a matter of overriding the ALTERNATIVE_* variables, as is done in the bash recipe? Sep 30 15:55:31 jackmitchell: surely that's a per-user setting, i.e /etc/passwd ? Sep 30 15:56:12 bluelightning: I'm looking to change /bin/sh -> /bin/bash to /bin/sh -> /bin/sh so it needs to be done at the time the symlink is created Sep 30 15:56:34 sorry, I meant /bin/sh -> busybox Sep 30 15:57:43 jackmitchell: I see, in that case you'd have to either set the alternative priorities so busybox was above bash for /bin/sh or call update-alternatives manually to switch over to busybox in a shell function called by ROOTFS_POSTPROCESS_COMMAND Sep 30 15:58:41 bluelightning: ok, I've just done a build with ALTERNATIVE_PRIORITIES overidden in a bash bbappend to be less than the default busybox, so I will see if that has worked Sep 30 16:02:09 bluelightning: hmm, no such luck; is it possible to override a VAR = x, with another VAR = x Sep 30 16:02:31 or should the recipe be var ?= x, and then I override with var =x Sep 30 16:03:21 jackmitchell: if the statement you are adding follows the original in parse order (and if it's in a bbappend, it always will) yours will take effect if both are = or the original is ?= (or ??= for that matter) Sep 30 16:15:08 bluelightning: ok that worked, thanks for the help Sep 30 16:15:50 jackmitchell: ah, it sounded like it didn't earlier, what did you do differently the second time? Sep 30 17:24:00 Hi, I am trying to write a recipe to include libjsoncpp into the list of packages available to Yocto. I downloaded the source tar from sourceforge (https://sourceforge.net/projects/jsoncpp/) but it is compiled using scons. Since I am both a yocto and a python newbie, I do not know how to write the do_install portion of the recipe. I appreciate any help I can get. Sep 30 17:36:36 The libjsoncpp README says to install I should run $ python scons.py platform=linux-gcc. I added this to my libjsoncpp.bb but I get the following error while making the image: Sep 30 17:36:37 Error: libjsoncpp not found in the base feeds (wandboard_quad cortexa9hf-vfp-neon cortexa9hf-vfp armv7ahf-vfp-neon armv7ahf-vfp armv6hf-vfp armv5ehf-vfp armv5hf-vfp noarch any all). Sep 30 17:37:16 josh-adtec_: so if your recipe inherits scons then it should have a proper do_install already Sep 30 17:37:50 josh-adtec_: the error you're getting is almost certainly because the package is empty and therefore not produced Sep 30 17:39:01 oh okay. How might I fix that? So if I inherit do_install, I can just leave that portion blank? Sep 30 17:39:42 josh-adtec_: if you inherit scons, you shouldn't need to define your own do_install in the recipe as far as I can see Sep 30 17:40:25 I guess that makes sense. From what I read about scons, it just checks if anything is out of date and rebuilds Sep 30 17:41:51 I just have to figure out why the package is empty. My SRC_URI is from "http://sourceforge.net/projects/jsoncpp/files/jsoncpp/0.6.0-rc2/jsoncpp-src-0.6.0-rc2.tar.gz". I know the specific version is often set as a variable, but I didn't want to do that until I can get this version to compile. Is that something I should change now? Sep 30 17:42:42 josh-adtec_: could you use pastebin to show the contents of the recipe you are using to build this? Sep 30 17:43:39 Sure, although it is sort of in pieces now Sep 30 17:43:40 http://pastebin.com/SbXSh7xE Sep 30 17:44:09 I also had issues with the license checksum, which is why it is currently set as "closed". Sep 30 17:46:39 josh-adtec_: so your recipe is called jsoncpp_0.6.0-rc2.bb ? Sep 30 17:47:24 No, I called it libjsoncpp.bb. Is that my problem? S = "${WORKDIR}/libjsoncpp" ? Sep 30 17:48:13 S is definitely not set correctly, it needs to match the contents of the archive Sep 30 17:49:12 josh-adtec_: looking in the archive it contains a subdirectory "jsoncpp-src-0.6.0-rc2", so you should have S = "${WORKDIR}/jsoncpp-src-0.6.0-rc2" Sep 30 17:49:53 josh-adtec_: add "inherit scons" and you should get a bit further Sep 30 17:50:12 thanks Sep 30 17:52:41 Here are the changes I made: http://pastebin.com/ym3yUR80. Sep 30 17:53:27 I now get the error: scons: Reading SConscript files ... You must specify a "platform" Sep 30 17:58:31 would you have any idea where I should specify the platform for scons? Sep 30 18:00:35 I tried do_install(){ scons -f S/SConstruct platform=linux-gcc} but that results in the same error message. Sep 30 18:00:51 josh-adtec_: add any extra arguments you need to EXTRA_OESCONS Sep 30 18:09:15 could you explain what you mean by "add any extra arguments you need to EXTRA_OESCONS"? Is this a variable that I set? Sep 30 18:09:29 For instance, would I do EXTRA_OESCONS = "scons -f S/SConstruct platform=linux-gcc" Sep 30 21:35:30 seebs: any chance on sorting out pseudo or should I patch what we have? Sep 30 21:38:44 You attempted to reach yoctoprojectchallenge.intel.com, but the server presented an invalid certificate. Sep 30 21:55:47 JaMa: I've heard yesterday on irc about problems on Gentoo64 with pseudo. Example given was dbus Sep 30 21:57:22 ant_home: issues like what? Sep 30 21:57:51 I see the same issues on gentoo64 as ubuntu64 Sep 30 21:58:00 example being dbus do_install trying to chown messagebus:messagebus blah blah Sep 30 21:58:24 nerdboy> ubuntu works fine, gentoo barfs Sep 30 21:58:45 was #oe yesterday night Sep 30 21:59:11 this works for me in gentoo Sep 30 22:00:00 biggest issue I know about has now patch in master, thanks RP/seebs Sep 30 22:01:17 I see Sep 30 23:50:26 anyone realised that when using smart upgrade smart doesn't remove the old package? It only installs the new package on top Sep 30 23:50:42 so if the package has a update-rc script, it will not be removed.. Sep 30 23:50:50 any ideas on how to fix it? Oct 01 01:30:56 root Oct 01 01:31:00 whoops haha! Oct 01 01:31:13 (don't worry, that was the password ;) **** ENDING LOGGING AT Tue Oct 01 02:59:58 2013