**** BEGIN LOGGING AT Wed Apr 30 02:59:59 2014 Apr 30 08:00:01 Hi all... i am trying to compile meta-atmel in poky distro for my atmel board so that i compiled kernel using at91_dt_defconfig by coping to (meta-atmel/receipes-kernel/files/at91sam9x5ek/defconfig ) if i do like this i getting pastebin error http://pastebin.com/w7WsEGDq how to solve this. Apr 30 08:02:14 if i use default defconfiguration which is given by meta-atmel layer (files/at91sam9x5ek/defconfig ) my kernel is not getting compiled. please any one help me to solve this error. Apr 30 08:06:06 why are people asking that over and over? Apr 30 08:08:27 ah no, its not "people", its just you Apr 30 08:09:00 under the nicknames elinuxer and yasni so far. well then, i already answered two times. no need for a third attempt. Apr 30 08:44:23 LetoThe2nd: Sorry..don't mistake me..i have tried in atmel 3.10 kernel even thought i am getting same error thatswhy again asking and i have changed configuration also.i don't know what to do further.. Apr 30 08:47:46 atmel: then you haven't changed the configuration in the correct way. the error message is pretty clear about it: no board type is selected. Apr 30 08:50:11 morning all Apr 30 08:50:33 please tel me... where to specify board type. whether in kernel or meta recipes.. Apr 30 08:52:47 atmel: kernel config, of course. just use the menuconfig system. Apr 30 09:00:06 LetoThe2nd: Kindly check this configuration which is am using http://pastebin.com/4mVSKXWb..can you tell me changes..please Apr 30 09:00:43 i am using atmel at91sam9x5ek board.. Apr 30 09:15:16 paste not accessible. Apr 30 09:23:35 LetoThe2nd: Please http://pastebin.com/4mVSKXWb Apr 30 09:27:42 atmel: you see that #CONFIG_MACH_AT91SAM_DT=y is commented out. probably thats the problem. Apr 30 09:38:41 LetoThe2nd:As per your advise in the same config i enabled this CONFIG_MACH_AT91SAM_DT=y and recompiled the kernel. Now i am getting paste bin log . i am getting this error from begging onwards. Apr 30 09:43:13 you didn't show anything. Apr 30 09:56:00 atmel: you didn't show anything. Apr 30 10:00:26 LetoThe2nd: kindly check this http://pastebin.com/2qA5BXe6 Apr 30 10:17:54 ******** Hi all, is there any option to conditionally install any files to a package depending on which image it is built for ?? Apr 30 11:27:39 atmel: i think you haven' changed the config successfully. Apr 30 12:33:50 Hi all, how can I display the description for a target? Apr 30 13:39:23 N/2 Apr 30 17:05:16 yocto seems to be sensitive when it comes to file permissions Apr 30 17:05:37 how so? Apr 30 17:05:49 cp: cannot create regular file `/var/lib/jenkins/jobs/yocto-distro-nas-main_git_genericx86-64/workspace/poky/build/tmp/work/x86_64-poky-linux/cv-all-tests/1.0-r0/././python-imports.py': Permission denied Apr 30 17:06:01 the files permission is 444 Apr 30 17:06:29 sounds like a trivial bug in one recipe, hardly worthy of such a widely scoped claim about sensitivity Apr 30 17:06:50 second recipe where it happens. I think that could be because the recipe that is checked out does not has any write permission to any files Apr 30 17:07:21 that doesn't make sense Apr 30 17:07:29 recipes aren't users, they don't have "write permission" Apr 30 17:07:43 but from recipes are files copied Apr 30 17:07:46 if you mean the tasks run by a recipe, then that's still not the case Apr 30 17:07:53 no, recipes describe what bitbake will do Apr 30 17:08:27 yes, but 'SRC_URI = "file://*"' will copy the file Apr 30 17:08:39 and the file it copied does have 400 permission in this case. Apr 30 17:09:19 and if you re-run the recipe (because it has changed) and copy the files over it seems to fail in this step Apr 30 17:12:56 volker-: the file should not have 4xx permissions in the first place Apr 30 17:13:23 bluelightning: perforce always checks files out without write permission Apr 30 17:13:49 well; ok... it probably shouldn't preserve the original mode if that's what it's doing Apr 30 17:14:36 it checks for umask (my default one is 077), but not for this file permission Apr 30 17:15:09 so let me know if this is a bug or feature I run into Apr 30 17:15:18 sounds like a bug to me Apr 30 17:15:42 k, I will submit a bug then Apr 30 17:15:44 Its debatable, I expect. bitbake generally leaves permissions alone, whereas what you're asking for here is for it to modify your permissions rather than obeying them as is. I've seen similar cases, where someone wanted bitbake to extract a tarball, but not obey the permissions in the tarball Apr 30 17:15:49 * kergoth shrugs Apr 30 17:16:02 kergoth: that's a different case though Apr 30 17:17:26 That's true, the main difference being the behavior of the cp could be non-deterministic, whereas the tarball encoded a specific set of permissions into the file. The peculiarities of the user's environment shouldn't change the input to our tasks Apr 30 17:17:48 but then, obeying the user's umask would have similar problems Apr 30 17:18:00 (of course, we override it for many tasks) Apr 30 17:21:21 any ideas in which category I should file this in bugzilla? Apr 30 17:21:38 bitbake? layers? Apr 30 17:23:03 bluelightning, hi, arent you at OEDAM ? Apr 30 17:23:18 kroon: no, wasn't able to make it unfortunately Apr 30 17:23:22 volker-: bitbake. The implementation of do_unpack is in bitbake nowadays, and that's where it should be addressed, most likely Apr 30 17:23:26 afai Apr 30 17:23:27 k Apr 30 17:23:42 bluelightning, well, me neither, but I hope my boss will me go next year Apr 30 17:23:57 volker-: this shouldb e pretty straightforward for you to work around, though. do_unpack[postfuncs] += "fixup_perms" fixup_perms () { chmod +w -R ${S} } or so Apr 30 17:24:07 volker-: as a temporary thing to get you past your issue Apr 30 17:24:09 kroon: I hope we'll have a European equivalent in future Apr 30 17:24:26 bluelightning, oh. I thought there already was one Apr 30 17:24:40 kroon: we had them in the past, but this is the first official developer meeting for a while Apr 30 17:24:46 I fix it in my build snippet that prepares the build. I don't see a problem for a workaround. It is more a 'what you guys think' and 'should a bug be filed'. Apr 30 17:24:57 * kergoth nods Apr 30 17:25:11 kroon: (we being OE that is) Apr 30 17:25:53 and kergoth is one of the founding fathers of OE ? Apr 30 17:26:17 or bitbake Apr 30 17:27:28 One of them, yes. I drove its creation early on and was the first maintainer for a few years. Apr 30 17:27:32 it's come a long way since then :) Apr 30 17:29:44 still going strong Apr 30 17:31:24 bbl Apr 30 17:34:11 I track the master branches, and I rebuild alot.. Am a little worried about wearing out the harddrive Apr 30 17:34:53 Are there any tricks in this area ? I dont think I have enough ram in my laptop to build in a tmpfs mounted partition Apr 30 17:35:17 6GB ram in total Apr 30 17:41:59 kergoth: btw, your workaround is nice :) Apr 30 17:46:13 volker-: :) Apr 30 17:50:05 kergoth: hmm, just don't seem to work here ;-) Apr 30 17:50:23 in your case you might need to chmod all of ${WORKDIR} rather than ${S} Apr 30 17:50:39 not sure Apr 30 17:50:47 true; Apr 30 17:51:16 have to play around with it. I would have put it somewhere else, but your solution is nicer. Apr 30 18:02:28 anyone knows when the Yocto book is to be expected? Apr 30 18:03:20 Maybe otavio? Apr 30 18:04:57 I messaged him a while ago here and haven't received a response. Apr 30 18:10:23 volker-: We hope this goes out in mid of May Apr 30 18:10:34 volker-: we are awaiting for some final review Apr 30 18:10:43 volker-: I didn't get your e-mail I think Apr 30 18:12:40 otavio: ok, that sounds great :) The publisher page still listed April yesterday. Apr 30 18:13:23 volker-: I'll push them Apr 30 18:13:24 otavio: let me know if you need an incomplete review from me ;-) Apr 30 19:39:09 is there a small framework for firstboot scripts? Apr 30 19:40:30 postinsts are used for that. Any postinst we couldn't run at image creation time will instead get postponed to first boot. So you could leverage that Apr 30 19:40:43 not sure if there's anything else offhand Apr 30 19:41:52 kergoth: do you reference to the postinst on the package level? Apr 30 19:42:13 postinsts are by definition per-package, yes, as they're one of the package scripts which are run when packages are installed Apr 30 19:42:43 kergoth: so I don't understand how this should work to get it run on the first boot only Apr 30 19:43:03 when the postinst is run at do_rootfs time, the env variable D is defined, as the full path to the rootfs Apr 30 19:43:28 so the common idiom is to check the value of this variable to decide whether to run something at image creation time or at first boot Apr 30 19:43:31 grep around, you'll find examples Apr 30 19:53:15 kergoth: I think I found it in meta/recipes-devtools/run-postinsts, but looking through the code I do not see how it can handle ro-rootfs Apr 30 19:53:41 It can't. By definition first boot scripts modify the rootfs Apr 30 19:53:50 if what you want to do can't be run at rootfs creation time, and you want r/o, you're hosed Apr 30 19:55:42 or you can run 'mount -o rw,remount /', what you do e.g. on upgrades. Apr 30 19:56:10 assuming your rootfs can be mounted r/w, and you're willing to risk that, yes, that's definitely an option Apr 30 19:56:44 kergoth: we have thousands of devices in the field where we do it when we have to update the software. Yes, there is a risk during this time. Apr 30 19:56:51 * kergoth nods Apr 30 19:57:34 Field upgrades are an interesting thing, I'd like to see a nice overview of the various approaches and their tradeoffs. Maybe pidge's talk at oscon about updates will cover some of that :) Apr 30 19:58:31 I looked into grub as fail over. Right now I create two identical partitions. But grub is not able to say inside of the MBR "if part1 fails, boot part2". You need to have a separate /boot partition for that Apr 30 19:59:37 Ah, yeah, that makes sense. You'd have to write some sort of flag to persistent storage, or set something up with your initramfs to do the failover at that level, i expect Apr 30 19:59:41 at my previous company we created the entire bootloader ourself incl. watchdog and splitted the flash into different partitions and flipped a value if the watchdog had to restart it Apr 30 19:59:58 impressive Apr 30 20:00:53 kergoth: yeah, I don't like the grub approach, I wish they could put something like "if file part1/xyz not found, boot part2". I mean, it has to read from the partition anyway to boot Apr 30 20:02:46 An initramfs approach that leveraged kexec to switch both kernel and rootfs could be interesting, as long as the first partition's kernel could even get that far :) if not... Apr 30 20:03:06 course if you dont have to deal with kernel upgrades it'd be a fair bit simpler Apr 30 20:03:15 kergoth: as I said, grub seems to have something in it, but they need to load it from the /boot partition. Apr 30 20:03:29 * kergoth nods Apr 30 20:04:41 what I really haven't found in yocto is examples how to install it to an actuall device incl. grub or similar. I had to hack my own way to it by dd + chroot + grub-* Apr 30 20:42:57 hello there, I'm at ELC, and have been looking to migrate from buildroot to yocto. I've had some success building the poky-tiny/core-image-minimal for qemux86 and xilinx zedboard... but I'm running into some difficulty. Apr 30 20:43:47 I am trying to use systemd, but when it builds libcap, I've discovered that nftw() has not been built into the toolchain's libc. Apr 30 20:43:59 Where can I find how the toolchain is configured? Apr 30 20:46:51 see DISTRO_FEATURES_LIBC in meta-yocto/conf/distro/poky-tiny.conf. it pares down the glibc configuration to save space Apr 30 20:47:15 if you just want to make progress, you may want to build with poky, otherwise you'll need to determine the libc feature you need to enable. compare DISTRO_FEATURES_LIBC in poky to the one in poky-tiny Apr 30 20:47:19 that makes a lot of ssense Apr 30 20:48:29 where can I find.... okay, poky.conf as a reference Apr 30 20:49:05 jlamorie: I would run grep -r "DISTRO_FEATURES_LIBC" meta* Apr 30 20:49:48 right next to poky-tiny.conf, but yeah, grep is a sane way to go, since you don't know exactly where it's defined. alternatively, bitbake -e | grep DISTRO_FEATURES_LIBC= with both DISTRO=poky and DISTRO=poky-tiny, and it won't matter where it happened to be defined Apr 30 20:50:12 kergoth: yeah, that confuses me, why is the big DISRO_FEATURES_LIBC defined in poky-tiny.conf and not in poky.conf? Apr 30 20:50:21 I think I've found it... meta/conf/distro/include/default-distrovars.inc Apr 30 20:50:33 yeah, its the default value for any distro that doesn't override it Apr 30 20:50:53 that's where the default is, which is 'accepted' by poky.conf and .... yeah, what kergoth said Apr 30 20:50:58 * kergoth nods Apr 30 20:53:10 To be lazy, I think I will just comment out the override of DISTRO_FEATURES_LIBC in my distro/foo.conf and pare it down later Apr 30 20:55:05 Seems reasonable Apr 30 20:55:23 thanks for your help folks, time to get back to the ELC sessions Apr 30 20:56:41 * kergoth needs to get to ELC again (or ELC-E) next year, missed them this year Apr 30 21:11:06 jmpdelos: Your don't "comment out" in yocto, you define your own distro with this setting, base your distro on another one (e.g. via require conf/distro/poky.conf) and then just add that setting (which "overwrites" the previous setting). Apr 30 21:11:45 ok, he left :-/ Apr 30 21:32:56 volker-: maybe that was intended for someone else? if not, I have no idea of the context or your comment Apr 30 21:33:30 ah -- I see, it was intended for jlamorie Apr 30 21:33:52 yes, tab completion gone wrong. sorry. Apr 30 21:49:21 What would be the best way to create something like "if directory unittests in recipe directory, then copy all files and folders from it to /path/in/image" Apr 30 21:49:56 why can't you just use shell tests? Apr 30 21:50:08 oh, recipe directory Apr 30 21:50:33 you can inspect the $(WORKDIR) assuming you also mandate that someone adds stuff to SRC_URI Apr 30 21:50:44 rburton: plan is to run one script that executes all shell/python/perl/whatever scripts in a folder to run the tests on the final image. Apr 30 21:51:23 rburton: my hope is to get that code snippets outside of every recipe. Apr 30 21:51:26 implement them as ptests and you'll get some support magically? Apr 30 21:51:47 * rburton -> tidy and bed Apr 30 21:53:08 ptests wiki looks promissing. thanks :) Apr 30 21:54:00 I'm in and out of sessions, but I just wanted to feed back that my poky-tiny build with 'complete' LIBC completed successfully. Thanks for your support. Apr 30 21:55:59 volker-: lots of recipes in oe-core use it now to optionally have on-image tests. distro-level feature to turn on/off and then image-level feature to control whether they are in the image or not. Apr 30 21:57:09 rburton: yeah, thanks, looking into it already. Not by default in, but that should still be sufficient for me :) Apr 30 22:24:36 do I want to have ptest-pkgs in DISTRO_FEATURES enabled for production builds? Apr 30 22:24:52 s/production/final release/ Apr 30 22:25:32 It's most useful to be able to do runtime testing on target. If you don't need to do that in production, then you don't need it. I'd enable it for QA and disable it for release Apr 30 22:25:33 * kergoth shrugs Apr 30 22:26:03 kergoth: can you enable DISTRO_FEATURES in local.conf? I didn't find an indication in that template Apr 30 22:26:32 as long as you use _append, yes Apr 30 22:28:27 I have to think about the workflow then **** ENDING LOGGING AT Thu May 01 02:59:58 2014