**** BEGIN LOGGING AT Thu Mar 17 02:59:58 2016 Mar 17 11:08:40 hi Mar 17 11:09:31 guys, am I supposed to wipe out tmpdir and build clean when upgrading from yocto 2.0 to 2.0.1? Mar 17 11:14:06 basically I am getting a strange error for a package that inherits core-image Mar 17 11:14:07 https://pastebin.mozilla.org/8864014 Mar 17 11:14:21 license related... it can't find some file, but I am not sure who was supposed to put that file there in the first place Mar 17 11:14:28 Exception: OSError: [Errno 2] No such file or directory: '/poky-devel-build/build/sysroots/dss11-1gb-t1/pkgdata/runtime-reverse/Collected' Mar 17 11:14:30 any clues? Mar 17 11:25:19 hmm, but from what I read I should have probably cleaned TMP Mar 17 11:58:54 I'm trying to integrate with a BSP (meta-iveia) which lists the master branches of oe-core and meta-oe as being dependencies (in its readme). When The build kicks off, it throws a few expansion errors that end with an EOL while scanning string literal KERNEL_VERSION. As I poke around I see they're only defining kernel 3.9, and the master branches are up at 4+... Is it safe to say this somewhat cryptic python-sounding error is real Mar 17 12:09:34 rburton: something tells me you probably know the answer to this. I am trying to run a build against a different BSP than I've been building against and it immediately kicks out several ExpansionError messages that end with: EOL while scanning string literal KERNEL_VERSION. The BSP seems to be patching 3.9, but the minimum in what they state is their required base layers are all 4+. Does this error mean it couldn't cross-reference Mar 17 12:14:25 sounds like the layer is broken Mar 17 12:14:33 are you using corresponding branches? Mar 17 12:15:34 Trying to. Their README hasn't been touched in 2 years, but it lists the master branches of oe-core and meta-oe as dependencies. Those layers have a minimum kernel version in the low 4's, so that's what I'm thinking is really the issue... Their layer is meant for the 2-year old "master" branch. Mar 17 12:17:10 Which...flipping through the branches I don't see an oe-core with 3.9 in it. Mar 17 12:17:14 hmm Mar 17 12:19:37 yeah Mar 17 12:19:41 saying "master" doesn't really help Mar 17 12:20:09 Funny, they also list angstrom as their test build, but even looking at that it's saying dizzy is the meta-oe and oe-core branches, which would have been 3.10. Mar 17 12:20:45 So if this error message really means "kernel version mismatch" then I'm not sure how this ever built... Mar 17 12:36:30 Is there a way to build certain recipes with a different GCC version then the rest of the system? Mar 17 12:39:39 bachp: I haven't found a way to do that yet. I ultimately had to resort to using PREFERRED_VERSION for my particular layer so that the system would get built against that specific toolchain. Mar 17 12:40:02 (disclaimer: I'm very new at this as well...so take my opinion with huge grains of salt.) Mar 17 12:41:43 you can't set preferred version in a layer and expect it to be localised to that layer Mar 17 12:42:13 rburton: FWIW I tried tweaking their recipe by changing the dependency to 3.14, one of the kernels in my layers, and the error persists. This seems to just be a REGEX error for parsing KERNEL_VERSION out of a path. Mar 17 12:43:26 rburton: oh, I know that. That was just my way of enforcing it so that my layer would certainly build. Probably the better way is to tell whoever is using my layer to ensure they've set the version in their local.conf, etc. Mar 17 12:43:38 or have a distro config which sets it Mar 17 12:44:48 To bachp's question though, I've read articles on using secondary toolchains but I couldn't get it to work for me. Mar 17 12:44:59 Perhaps there's a cleaner way to have a recipe build with one toolchain different than the rest of the system. Mar 17 12:45:30 entirely different toolchain is likely easier than different gcc version, afaik Mar 17 12:50:12 hi Mar 17 12:50:16 hi Mar 17 12:50:17 i have a question Mar 17 12:52:12 i bitbake i2c-tools then add i2c-tools in IMAGE_FEATURE in core-image-x11.bb, but when i bitbake core-image-x11, but error appear and hints these i2c-tools cant be added, so how do i add it into image? looking forward to experts' reply, thanks Mar 17 12:57:34 zxc678: check what packages the i2c-tools recipe actually built. Mar 17 12:58:10 zxc678: oe-pkgdata-util list-pkg-files —recipe i2c-tools Mar 17 13:03:37 hi, i use your command and get many output like i2c-tools: /usr/sbin/eeprog /usr/sbin/eeprom ....., i2c-tools-dev: /usr/include/linux/i2c-dev-user.h, ...... Mar 17 13:04:07 i cant write all of them here,do u need me to list all of them? Mar 17 13:05:43 $ oe-pkgdata-util list-pkg-files --recipe i2c-tools Mar 17 13:05:44 i2c-tools-misc: Mar 17 13:09:13 rburton: so then ? Mar 17 13:10:36 find what you want to install, add them to IMAGE_INSTALL Mar 17 13:10:55 if that doesn't work then tell us what the actual error is instead of saying "error appears" Mar 17 13:11:26 ok,wait a moment Mar 17 13:12:57 zxc678: or pipe then output into pastebinit Mar 17 13:14:16 how to pipe, i use mirc, it is a command in mirc? Mar 17 13:14:55 paste to pastebin.com Mar 17 13:15:09 ok Mar 17 13:17:57 Has anyone else run into issues with INITRAMFS_IMAGE_BUNDLE = "1" causing "recipe linux-yocto is trying to install files into a shared area when those files already exist." for README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt ? Mar 17 13:22:20 ok, i try and it success to bitbake, so i should use IMAGE_INSTALL for it, thank expert very much Mar 17 13:22:39 eengie: thanks I also read about the secondary toolchains but not about different gcc versions Mar 17 13:23:43 I think we will have a look into that and I hope we can come up with a soltuion that others can benefit too. I will write a proposal to the mailing list Mar 17 13:25:10 bachp: looking back, what I did was specify in my layer GCCVERSION="4.8%" (I guess I abandoned PREFERRRED_VERSION). So I may be misunderstanding it, but I thought that ultimately helped the toolchain to use 4.8 as well (which for me, with -fpermissive, fixed many template compile errors) Mar 17 13:26:09 hrm. I think the initramfs-image do_rootfs is creating README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt (in meta/lib/oe/rootfs.py) then do_deploy for linux-yocto tries to do it and blows up. Mar 17 13:28:09 i have another question, I modify the imx6dl-wandboard.dtsi and wandboard.h files in work folder, then bitbake -f to get the local file compliled and use them to get image, now i wish to build recipes and put them in own layer, but how to know original recipes for these files to build patch or bbpend? Mar 17 13:28:37 zxc678: oh yeah, IMAGE_FEATURE is for generalised features like dev-pkgs or tools-debug, IMAGE_INSTALL is for packages Mar 17 13:29:05 mhm, clean build did not help, I still get exactly the same error: https://pastebin.mozilla.org/8864014 Mar 17 13:29:13 what is this "collected" stuff, how can I resolve the issue? Mar 17 13:48:32 anyone? :P Mar 17 13:57:43 Sorry Jin^eLD, I dont think I'm going to be much of a help on that one. I'm tracing down my own thing that seems to be a python error too. Mar 17 13:58:33 eengie: I would like to avoid having to set the toolchain to an older version just because of one component, that's why a would prefer a secondary toolchain, which in this case would be an older gcc version Mar 17 13:58:55 Though mine is from the linux-kernel-base class' get_kernelversion method that seems to be checking a path that doesn't exist yet... Mar 17 13:58:56 well, I was rather hoping for someone to shed some light on what this pkgdata/runtime-reverse is all about and who or what needs it Mar 17 14:00:30 bachp: Right, I am in the same boat but couldn't figure out a way to enforce one toolchain for one layer, but let the other layers use whatever they wanted, other than the secondary toolchain route (which I didn't get working) Mar 17 14:19:48 rburton: The issue seems to be that the kernel class sets KERNEL_VERSION to expand using the get_kernelversion, passing ${B} to it. But nothing is creating the tmp-glibc/work/ directory prior to that point. Mar 17 14:21:04 rburton: I've been trying to cross-reference this layer's linux recipe against a working one to see what might be causing that directory not to get created first but I don't see it. Mar 17 14:56:48 What part of the bitbake process causes the tmp-glibc/work/ path to be created? I've also been trying to inject some print statements (even exceptions) into linux-kernel-base class' get_kernelversion, but I'm unable to make headway on debugging this problem. Mar 17 14:59:26 eengie: use bb.warn or bbwarn (python or shell) and you'll see the messages Mar 17 15:02:39 rburton: I added to the python function bb.warn("fn: {0}".format(fn)) but I don't see the output when running bitbake -e linux-z7e. The process dumps immediately while parsing recipes with this error about being unable to expand KERNEL_VERSION because the get_kernelversion method failed with the "EOL while scanning string literal..." Mar 17 15:04:44 failing during parse means it won't run any code Mar 17 15:06:30 Not that I'm trying to disagree, but it sure seems to be trying to execute something. The error says the expression it couldn't expand was ${@get_kernelversion()} "which triggered eception SyntaxError: EOL while scanning string literal (KERNEL_VERSION, line 1)" Mar 17 15:07:55 "which triggered" suggests it's doing something, and the error matches a Python exception...though it seems to get there without actually executing the function. Mar 17 15:10:18 Even with the --verbose flag it doesn't give me anything else to go on in the log about this path it took to suddenly die. Mar 17 15:19:14 This is the error: ERROR: ExpansionError during parsing /projects/atlas/oe-core/../meta-iveia/recipes-kernel/linux/linux-z7e_3.9.0.bb: Failure expanding variable kernel_do_install: ExpansionError: Failure expanding variable KERNEL_VERSION, expression was ${@get_kernelversion('/projects/atlas/build/tmp-glibc/work/atlas_i_z7e-oe-linux-gnueabi/linux-z7e/3.9.0-${MACHINE_KERNEL_PR}/zynq_kernel')} which triggered exception SyntaxError: EOL Mar 17 16:54:57 I think I'm reconciled to the idea that this iveia layer is just jacked. It sources a kernel tarball that was deleted from their repo a few months back anyway, so if I got past this odd expansion error it's of little utility anyway. Mar 17 16:57:12 hey bluelightning, do you have a short moment? Mar 17 16:57:24 Jin^eLD: what's up? Mar 17 16:58:25 I am struggling with a strange problem after upgrading from 2.0 to 2.0.1 Mar 17 16:58:40 and so far onone had a clue, I am triyng to at least understand what the message is all about in the first place Mar 17 16:58:42 https://pastebin.mozilla.org/8864014 Mar 17 16:58:44 its about licenses Mar 17 16:58:54 where something fails during image generation Mar 17 16:59:01 I even did a clean build, wiped tmpdir Mar 17 16:59:07 but nothing helped Mar 17 16:59:19 the recipe that fails is my image recipe that inherits core-image, nothing really special Mar 17 17:06:12 Jin^eLD: any idea where this string "collected" is coming from? Mar 17 17:08:54 that's what I was hoping to hear from you :) I thought you might find it familiar or somehting Mar 17 17:09:13 what is supposed to be in that dir anyway? Mar 17 17:09:16 package names? Mar 17 17:10:20 yes Mar 17 17:11:34 I have no string "Collected" neither in package names nor in my custom classes Mar 17 17:11:42 just grepped my whole layer Mar 17 17:12:36 also, the whole build dir has no "Collected" fil in it Mar 17 17:13:06 ha! Mar 17 17:13:07 in 2.0.1 Mar 17 17:13:07 poky/meta/lib/oe/rootfs.py: self.log_check_regex = '(exit 1|Collected errors)' Mar 17 17:13:46 but 2.0 had the same code Mar 17 17:14:25 however it can only come from here, no? that's the only match on the "Collected" string, especially considering the starting uppecarse C Mar 17 17:23:15 Jin^eLD: I wonder if an error is making its way into the manifest and then being picked up from there Mar 17 17:24:15 i.e. somewhere in sstate-control/manifest * Mar 17 17:24:44 sstate-control]$ grep -r "Collected" * Mar 17 17:24:47 returns empty Mar 17 17:25:18 I found some posts by RP from 2014 or so, suggesting it was a dependency thing (although the error was different, it was really stating the package name there and not just "Collected") Mar 17 17:25:28 and that a clean build was supposed to fix that but I guess I have a different situation Mar 17 17:27:31 Jin^eLD: are you using rpm, ipk or deb packaging? Mar 17 17:27:34 ipk Mar 17 17:29:06 so, have a look for package.manifest under tmp/deploy/licenses/ Mar 17 17:29:16 does it have that string in it at all? Mar 17 17:29:52 it has three files in there Mar 17 17:29:52 COPYING.MIT generic_MIT LICENSE Mar 17 17:30:08 neihter of them greps for "Colleceted" Mar 17 17:30:40 and I think the MIT comes from a test I did Mar 17 17:30:43 that can't be the right directory, there should be package.manifest Mar 17 17:30:45 originally the package was not providing any LICENSE Mar 17 17:30:52 hten I thought maybe thats the problem and added MIT Mar 17 17:30:55 but that had no effect Mar 17 17:31:10 poky-devel-build/build/deploy/licenses/digitalstrom-rootf Mar 17 17:31:11 the default value from image.bbclass is MIT so that wouldn't make a difference, no Mar 17 17:31:39 there is no package manifest in that dir.. Mar 17 17:31:54 aaah Mar 17 17:31:55 build/tmp/deploy/licenses/core-image-minimal-qemux86-64-20160307012508/package.manifest Mar 17 17:32:00 that's what I have here Mar 17 17:32:02 yeah I did not consider the renaming Mar 17 17:32:07 ./digitalstrom-devel-rootfs-dss11-1gb-t1-20160317113017/package.manifest Mar 17 17:32:12 I was looking for the .bb name Mar 17 17:32:30 thats it! Mar 17 17:32:35 "Collected" is the first line Mar 17 17:32:47 of package.manifest Mar 17 17:33:27 so opkg list_installed is printing out things it shouldn't... what exactly is there? Mar 17 17:34:03 uhm... in what context? or where exactly do I run opkg list_installed? Mar 17 17:34:21 ah, when the rootfs is done in the depths of oe Mar 17 17:34:35 ok I should look into that Mar 17 17:34:44 because we actually use an older opkg version Mar 17 17:34:50 newer one does not support libopkg Mar 17 17:34:58 I think you just helped me a lot :) Mar 17 17:35:06 because now I actually have an idea Mar 17 17:35:13 where this could be coming from Mar 17 17:35:15 thank you! Mar 17 17:40:05 Jin^eLD: no problem **** ENDING LOGGING AT Fri Mar 18 02:59:58 2016