**** BEGIN LOGGING AT Tue Mar 17 02:59:58 2015 Mar 17 03:08:24 anyone have any experience booting off a raid0 rootfs? Mar 17 07:41:38 Hey guys Mar 17 07:41:52 I received this error when I tried to build a atom-pc build of Yocto Mar 17 07:41:53 http://pastebin.com/bu6fQV39 Mar 17 07:42:00 Could anybody please advise? Mar 17 07:50:17 <_4urele_> hi cart_man, I never used for atom, it seems that the options to generate the taball are not correct... Mar 17 07:50:42 <_4urele_> maybe you could try to remove the "tar.gz" as output file Mar 17 07:51:15 <_4urele_> look at IMAGE_TYPES Mar 17 07:52:17 <_4urele_> (but this is a strange error, maybe someone can help you more than me ;), but to start you can take a look at IMAGE_TYPES ) Mar 17 07:58:31 Do any of you know of a way to implement packages on a (mostly) read only system? Mar 17 07:59:04 Goal being to have a rootfs that's deployed with a writable directory, and then later install / upgrade packages based on a writable directory somewhere. Mar 17 08:46:51 _4urele_, Thanks allot.. well I cant find IMAGE_TYPS though.. is it in the local.conf file? Mar 17 08:47:36 I received this error when I tried to build a atom-pc build of Yocto ...http://pastebin.com/bu6fQV39 Ill be repeating this because I really need help Mar 17 08:51:38 <_4urele_> cart_man, which image are you using? Mar 17 09:02:05 _4urele_, Im using the "atom-pc-dylan-9.0.0" Mar 17 09:02:14 Then I say source oe... etc Mar 17 09:02:22 then do the conf for atom-pc Mar 17 09:02:30 good morning Mar 17 09:02:39 then I say bitbake core-image-minimal Mar 17 09:02:49 Hi mckoan Mar 17 09:04:19 hi cart_man Mar 17 09:05:52 _4urele_, Take not that I have built images successfully before soo the environment should be right.. Although it did say that "Ubuntu-14.04" has not been validated Mar 17 09:05:57 or warn rather Mar 17 09:06:18 other builts had no problem.. is that atom-pc-dylan-9.0.0 maybe old? Mar 17 09:08:59 from your logs it appears that bitbake is trying to stage quilt-native from sstate but tar is saying the file isn't a tar archive. Not sure why your sstate might be damanaged but you could try bitbake -c cleansstate quilt-native and then run your build again Mar 17 09:20:12 joshuagl, If I run that command it fails and then seems to say the exact same thing in the log files Mar 17 09:29:38 hmm, strange - is there anything indicative in tmp/work/x86_64-linux/quilt-native/0.63-r0/temp/log.do_cleansstate ? Mar 17 09:30:16 your quilt-native temp path may be different Mar 17 09:30:23 * joshuagl is using dizzy on x86_64 Mar 17 09:33:37 joshuagl,Ok might it be because im changing build directories everytime I use a new version of Yocto Mar 17 09:34:06 Example.. I have built Yocto manny times in /home/b/build/ dir Mar 17 09:34:18 then I downloaded the Atom-PC version and I said Mar 17 09:34:26 source oe-... ~/build2 Mar 17 09:35:05 The it automatically created the evironment in build2 right... so might it be somethng I did wrong there/? Mar 17 09:35:11 are you sharing sstate between build dirs? Mar 17 09:35:30 I have no idea what sstate even does Mar 17 09:36:07 probably not then Mar 17 09:36:08 http://www.yoctoproject.org/docs/1.7.1/ref-manual/ref-manual.html#shared-state-cache Mar 17 09:43:13 at quilt-native you're not very far into the build, have you tried deleting the build dir and starting fresh? Mar 17 09:43:25 joshuagl, Which OS do you use to build your Yocto projects Mar 17 09:43:35 joshuagl, Yes ive just tried that actualy Mar 17 09:43:37 : / Mar 17 09:44:15 I'm running Fedora, but I doubt Ubuntu is the problem. Many of the Yocto developers are using it Mar 17 09:44:23 cart_man: same error? Mar 17 09:45:14 Yip exact same Mar 17 09:45:23 Ohh wait.. I just noticed Mar 17 09:45:48 that theres 2 build directories... 1 in /home/b/ and one in /home/b/atom-pc.. / Mar 17 09:45:55 so im deleteing both and trying again Mar 17 09:49:28 No still happens... Task 7 of 63 Mar 17 09:51:39 Morning all, I m trying to change owner of a file, but nothing happen, not even a warning during bitbake. User is probably not create a this moment and I don't understand why. Mar 17 12:08:49 what is the default Yocto username and password? Mar 17 12:08:59 When you boot with an image I mean Mar 17 12:09:01 for the first time Mar 17 12:16:55 did you try root without password? Mar 17 12:18:00 neverpanic, Nope..but it must be because I almost instantly panicked : / Mar 17 12:18:27 Do you guys maybe know which Yocto build will the best for a celeron cpu? Mar 17 13:01:22 joshuagl,By the way ... It stopped working when I used the " source oe ... " from the ATOM build folder.. is it possible that some files that the first " source oe... " created might be clashing with the new ones? Mar 17 13:01:46 How do I remove the entire Yocto build environment and all its temp files.. I want to restart clean Mar 17 13:02:33 just delete the tmp directory in your build folder Mar 17 13:05:04 because now I have a new error -.- " libsdl-native is set to be ASSUME_PROVIDED but sdl-config can't be found in PATH. Please either install it , or configure qemu not to require sdl " ..im not even building for it Mar 17 13:17:22 cart_man: what OS are you using for your build OS? Mar 17 13:17:38 if u might want to install libsdl-dev package Mar 17 13:18:36 Ubuntu 14.04 Mar 17 13:19:30 chankit1, Well the thing is that I have built the genericx86 before .. all im trying to do is build for atom-pc now Mar 17 13:19:55 now its complaining about quilt-native ... AGAIN Mar 17 13:20:21 I just want it back to the state where I could at least build genericx86 Mar 17 13:26:22 are you using a clean terminal instance/tab or have you sourced multiple environment files in the same terminal? Mar 17 13:31:42 joshuagl, I didn't at first but about 6 try builds back I even restart the computer... I have sourced the atom-pc and the poky-dizzy files in one terminal yes.. I realized that was dumb Mar 17 14:00:43 Hi Mar 17 14:00:56 does the following look a valid commad in yocto recipe? Mar 17 14:00:57 inherit pkgconfig Mar 17 14:00:57 DEPENDS += "pkgconfig(gmock)" Mar 17 14:05:26 zaman - no.. that is not valid.. Mar 17 14:05:46 You need to depend on the package that provides whatever that is.. you can't 'depend' on a runtime value.. Mar 17 14:06:06 there is an rdepends +=, but even that is still not valid there.. as that is an RPM specific runtime dependency.. Mar 17 14:58:07 morning Mar 17 14:58:29 <_4urele_> hi, I'm working on a library, and for each try I bitbake my image. I noticed that on one build, there was an application which was build with the old version of the library (I'm using DEPENDS and not RDEPENDS) Mar 17 14:59:21 <_4urele_> maybe i made an error with th dependencies... Mar 17 15:55:06 ok so for my trouble I had to add RDEPENDS_ntpdate+="useradd" and not RDEPENDS_${PN}+="useradd" nor RDEPENDS_${PN}_ntpdate+="useradd" Mar 17 20:02:06 The recent kernel staging dir changes copies the kernel .config to "work-shared/(machine)/kernel-build-artifacts" and the kernel tree to "kernel-source" directory. Mar 17 20:02:17 however, building linux-backports requires both the .config and kernel tree Mar 17 20:02:58 should I update the creation of the "kernel-source" directory to also copy in the .config artifact? or is there something I can point my linux-backports recipe to? Mar 17 20:37:32 when using oe_runmake to make my linux-backport/compat-wireless, i get the following make line: Mar 17 20:37:32 make -j 4 KLIB_BUILD=/usr/src/gw-yocto-master/build/tmp/work-shared/myspecialmachine/kernel-source KLIB=/usr/src/gw-yocto-master/build/tmp/work/myspecialmachine-poky-linux-gnueabi/compat-wireless-all/20150129-r0/image KERNEL_PATH=/usr/src/gw-yocto-master/build/tmp/work-shared/myspecialmachine/kernel-source KERNEL_VERSION=3.10.53-1.1.0_ga+yocto CC=arm-poky-linux-gnueabi-gcc LD=arm-poky-linux-gnueabi-ld.bfd AR=arm-poky-linux-gnue Mar 17 20:37:32 abi-ar O=/usr/src/gw-yocto-master/build/tmp/work-shared/myspecialmachine/kernel-build-artifacts Mar 17 20:38:05 However, this causes linux-backports to complain unless I copy a .config file to the KLIB_BUILD directory Mar 17 20:39:15 i'm trying to look for the right solution: Should I somehow get the kernels' build directory and use that? or should i patch whatever functions creates the kernel-source directory and copy in the .config there as well? Mar 17 20:39:56 for the second option, i would submit a patch upstream Mar 17 20:55:49 we have variables for both paths. pass them in. Mar 17 21:00:23 but linux-backports makesystem is looking at the KLIB_BUILD variable only? I can't pass in one without overwriting the other. Mar 17 21:00:52 Plus that's what I was trying with the "O=" Mar 17 21:01:15 so patch it to separate the two Mar 17 21:04:49 hm, I suppose that makes sense. I'd have to think about if that's the 'best' solution over another method. Mar 17 21:09:19 mangling the kernel.bbclass process isn't it, and submitting a patch upstream is just a second step after creating the patch in the first place. Mar 17 21:16:45 the patch certainly fixes the build issue. and I do agree that touching kernel.bbclass isn't the correct thing to do. Mar 17 21:17:01 thanks for the suggestion, I think it's appropriate to do it this way. Mar 18 01:10:58 If I add iptables to my IMAGE_FEATURES will that build in the kernel modules as well? Mar 18 02:13:32 I got this kind of error while bitbaking beignet...any idea? Mar 18 02:13:34 | NOTE: make -j 12 DESTDIR=/home/autoeye/dizzy/poky/buildDizzy/tmp/work/corei7-64-poky-linux/beignet/1.0.1-r0/image install Mar 18 02:13:35 | make: *** No rule to make target `install'. Stop. Mar 18 02:34:52 missing make target? wrong source tree? Mar 18 02:55:11 hello everybody **** ENDING LOGGING AT Wed Mar 18 02:59:58 2015