**** BEGIN LOGGING AT Thu Jul 04 02:59:59 2013 Jul 04 07:45:47 Hi. Yocto does not support arch host yet? http://www.yoctoproject.org/docs/1.4/ref-manual/ref-manual.html#detailed-supported-distros Jul 04 07:53:30 morning all Jul 04 07:54:00 lpapp: not officially, no... if you want to use it you're welcome to do so, and it may well work fine, but we can't guarantee there won't be issues Jul 04 07:54:58 bluelightning: I guess I can ask for help in here if there are issues? Jul 04 07:55:11 lpapp: sure Jul 04 07:58:40 bluelightning: yocto needs python 2? Arch has been shipping python 3 since its appearance. Jul 04 08:03:45 lpapp: that is correct Jul 04 08:04:21 lpapp: we've made some moves towards python 3 support but with a codebase such as ours it is difficult to be compatible with both Jul 04 08:05:12 bluelightning: oh, it also needs the old texinfo4? Jul 04 08:06:07 lpapp: I thought we patched in support for texinfo 5 in a bunch of different places Jul 04 08:07:04 bluelightning: ok, I just saw a thread about it in March this year. Jul 04 08:07:08 it may have changed after that. Jul 04 08:08:04 also, my company uses an old yocto version. Jul 04 08:08:41 ah, right... in which case you may have issues with that Jul 04 08:08:59 I'd suggest using a distro that is more conservative than arch in that case Jul 04 08:09:49 maybe I can install something in a chroot environment just for this. Jul 04 08:10:10 but it would be still be nice to get archlinux working with the latest so that when my company switches to a new version, I can drop the chroot environment. Jul 04 08:16:48 Hi :) Jul 04 08:18:20 I'm trying to generate a decent yocto distro for my BeagleBone Black using yocto :) I'm using git repo " https://github.com/beagleboard/meta-beagleboard.git " Jul 04 08:18:43 Now I've got the beaglebone booted :) using MLO and u-boot.img and uImage Jul 04 08:18:46 BUT Jul 04 08:18:55 I don't have a Device tree generated file :/ Jul 04 08:19:09 so I'm stuck at the last u-boot procedure Jul 04 08:19:50 at the moment I'm reading about u-boot, but that won't fix my issue Jul 04 08:20:19 could someone give me some pointers on how to look for the root cause of the problem, any help will be appreciated ;) Jul 04 08:22:57 good morning Jul 04 08:28:23 mckoan: good morning :) Jul 04 08:43:40 hi everybody Jul 04 08:44:20 does yocto provide any support for conditionally adding a patch to some package when a certain package is going to be built for an image? Jul 04 08:44:38 I'm trying to generate a decent yocto distro for my BeagleBone Black using yocto :) I'm using git repo " https://github.com/beagleboard/meta-beagleboard.git ". Now I've got the beaglebone booted :) using MLO and u-boot.img and uImage BUT I don't have a Device tree generated file :/. so I'm stuck at the last u-boot procedure could someone give me some pointers on how to look for the root cause of the problem, any help will be appreciat Jul 04 08:45:01 let's say I want to applay a patch to package X only when package Y is going to be compiled as part of my image Jul 04 08:45:02 Guest592: you can use shell commands (bash) with if's :) Jul 04 08:45:40 to check against what? just look-up my image recipe and parse that? Jul 04 08:46:16 uhm I'll look into that for you, but I'm also just a noob so don't expect fancy solutions (if I can even offer solutions) Jul 04 08:46:43 I'd expect yocto to have something fancy for this kind of problem Jul 04 08:52:16 Guest592: you can't do that directly I'm afraid Jul 04 08:52:41 Guest592: the only option would be to build two versions of the piece of software Jul 04 08:52:53 k Jul 04 08:52:55 er Jul 04 08:52:59 i.e. two recipes Jul 04 08:53:32 so X would have 2 recipes for it Jul 04 08:53:50 and I should keep myimage recipe always updated with the needed X recipe? Jul 04 08:54:21 Guest592: i'd suggest two separate image recipes as well Jul 04 08:54:45 I had hoped this would not be the case :) Jul 04 08:54:58 seems like a pretty nice feature to have into yocto though Jul 04 08:55:32 you're effectively talking about making compilation-level changes based upon the structure of the image Jul 04 08:55:38 yes Jul 04 08:55:46 I know at least one build system that can handle that :) Jul 04 08:55:50 since the image construction happens a lot later in the build process, that would be very difficult Jul 04 08:56:54 I'd have thought that right at the beginning of the build, the needed packages should be known by the build system Jul 04 08:58:33 Guest592: adding a patch conditionally is possible, the point is the condition to check Jul 04 08:59:01 condition is if the image beeing built contains a certain package Jul 04 09:00:12 yes but I think the execution shell, when building the packages (fetch - configure - compile - install - populate - ...) does not have access to that data, though the executing python script of OE should have access to this Jul 04 09:00:14 one of the issues is that the final image construction is controlled by the package manager (RPM + smart when the RPM backend is selected) Jul 04 09:00:27 that won't work, you'd need to check against some variable Jul 04 09:00:57 bitbake has an idea of what is needed to construct the image (via RDEPENDS) but different package managers can have different ideas about actual runtime dependencies, so it doesn't know exactly Jul 04 09:01:54 Guest592: finally you risk to build two different recipes under the same name... Jul 04 09:02:22 one patched, the other unpatched Jul 04 09:04:39 so now about device tree :D Jul 04 09:05:12 the other issue with doing something like this is what would happen if you built two images, one that had the conditional package and one that didn't? Jul 04 09:05:31 I'm trying to generate a beaglebone build, and I have troubles with device tree. As in that I can't find a generated (valid) device tree :) Jul 04 09:05:58 fenrig: pls try on #beagle, iirc "of" was discussed yesterday Jul 04 09:06:35 ant_work, seems like there should be something more to that than having to maintain 2 image recipes for this kind of situation Jul 04 09:06:42 Iant_work: Okay but I'm building it with yocto, so isn't it closely related to yocto itself? Jul 04 09:16:16 hi to all! I need to clean my yocto environment from heavy data...basically i need to clean sstate-cache, tmp and downloads directory. there's a bitbake option to do this or I have to clean that directories with a rude rm -rf? thanks! Jul 04 09:17:03 soldoKyn: rm -rf Jul 04 09:17:18 iirc, there is a tool to clean sstate of old files Jul 04 09:21:41 rburton: ok, I think i'll do an rm -rf! thanks! Jul 04 09:48:20 in my beaglebone.conf Jul 04 09:48:23 I found that Jul 04 09:48:27 MACHINE_ESSENTIAL_EXTRA_RDEPENDS = "kernel-devicetree-overlays" Jul 04 09:48:52 now I don't get a resulting device tree tar Jul 04 09:49:05 so I don't understand why it isn't generated :/ Jul 04 09:49:34 fenrig: is the dtc package built? Jul 04 09:51:14 ant_work: excuse me but I'm still a beginner, how can I verify that a package is being build? By looking at the deploy folder? Jul 04 09:51:33 no, in workdir Jul 04 09:52:19 in the work directory I found a dtc source :o Jul 04 09:52:35 it should be a -native package, built under x86 Jul 04 09:52:39 and I did one build only, so I think I can assume it's being built Jul 04 09:53:54 I'm sorry Jul 04 09:54:06 ? Jul 04 09:54:19 I can't help you too much being I stopped working with beagle* before devicetree Jul 04 09:54:45 afais the infrastructure is there Jul 04 09:54:57 ant_work: it's not your fault, I just don't understand yocto (openembedded) that good. It's still a complex jungle for me :o Jul 04 10:13:46 uhm how do layer.conf work? Jul 04 10:13:59 when does OE read this file :o Jul 04 10:14:06 and what is {layerdir} Jul 04 10:47:48 fenrig: from bitbake usermanual: BitBake will first search the current working directory for an optional "conf/bblayers.conf" configuration file. This file is expected to contain a BBLAY\ Jul 04 10:47:48 ERS variable which is a space delimited list of 'layer' directories. For each directory in this list, a "conf/layer.conf" file will be searched for and parsed with the LAYERDI\ Jul 04 10:47:48 R variable being set to the directory where the layer was found. The idea is these files will setup BBPATH and other variables correctly for a given build directory automatica\ Jul 04 10:47:48 lly for the user. Jul 04 10:47:56 argh.. sorry about that ;-) Jul 04 11:15:03 rburton_: are you saying that xuser is general user which it's only function is that it's not root? Jul 04 11:15:18 because I am struggling to understand, why connman needs to depend on it Jul 04 11:15:37 jackmitchell: to be honest you don't want to know Jul 04 11:15:42 is it because connman wants a non root user to switch to? Jul 04 11:16:18 I'm just confused, to why I need xuser when I don't have X11 in my image Jul 04 11:16:20 it's because the shell can run as non-root but the upstream connman DBus ACLs don't work because generally we don't have anything that says "user is at the console" Jul 04 11:16:33 and I aussume it's because I have connman in my image Jul 04 11:16:40 yes Jul 04 11:16:52 i suspect dbus will moan if the ACLs talk about a user that doesn't exist Jul 04 11:17:03 to fix this we need to make the at-console stuff work in dbus for us Jul 04 11:17:07 ok, I kind of get it Jul 04 11:17:13 the easy solution is "mandate systemd" :) Jul 04 11:17:22 well, I use systemd in my image Jul 04 11:17:56 but I think I agree it shouldn't be called xuser, it's particularly consfusing Jul 04 11:17:58 this is something that's been bugging me since i started on yocto Jul 04 11:19:23 jackmitchell: does your stuff all run as root, or do you have another "normal" user? Jul 04 11:19:43 I only have root and (since recently) xuser Jul 04 11:20:02 i wonder if dbus can ACL on a user's groups, so we can stop hard-coding that username Jul 04 11:20:07 so yes, everything currently runs as root Jul 04 11:21:21 hm, yes, it can do groups. Jul 04 11:24:47 ant_work: How can i check if it's build? Jul 04 11:28:24 fenrig: 1) you have to check for artifacts in deploydir 2) check under tmpdir/work 3) check the produced ipk/rpm 4) re-bitbake the recipe and see 0 tasks executed Jul 04 11:29:53 ant_work: I've found a binary of dtc and sources in the work directory, however I did not find a rpm (yocto distro) but that is because the target does not run device tree compiler Jul 04 11:30:16 sure, it's dtc-native Jul 04 12:54:31 So I think I found (not sure yet) why .dtb for beaglebone is not generated :) Jul 04 12:55:09 the machine conf was missing " KERNEL_DEVICETREE = ... " Jul 04 12:55:18 now I don't know for sure what to fill in " ... " Jul 04 12:55:53 at the moment I'm using " KERNEL_DEVICETREE = "arch/${ARCH}/boot/dts/am335x-bone.dts" " Jul 04 12:56:14 but for some reason it fails Jul 04 12:56:19 | ERROR: Function failed: do_devicetree_image Jul 04 12:56:35 how do I go about fixing this (can't find the exact reason why) Jul 04 12:58:23 fenrig: this is in the archives http://www.mail-archive.com/yocto@yoctoproject.org/msg07515.html Jul 04 12:59:07 try KERNEL_DEVICETREE = "${S}/arch/ Jul 04 12:59:33 (inelegant and strange, though) Jul 04 12:59:44 ant_work: I'm testing your solution Jul 04 12:59:49 but I think I know why you're struggling Jul 04 13:00:16 I fear for the black bone you'd need Angstrom and its customizations Jul 04 13:00:43 Yocto is tested on beagleboard afaik, then you need extra layers Jul 04 13:02:45 ant_work: the generated build does work, i stole a dtb file from the archlinux arm os :) Jul 04 13:02:51 surely meta-beagleboard should be all that's needed Jul 04 13:03:11 ant_work: and now it boots, unfortenately I get the same error with your ${S} fix Jul 04 13:03:23 but I noticed something I missed last time Jul 04 13:03:26 temp/run.do_devicetree_image.3545: package_stagefile_shell: not found Jul 04 13:04:50 bluelightning: I'm using it, but it generates a 3.8 linux kernel (with devicetree) but I'm missing the devicetree dtb's :) so uboot can't finish it's boot process Jul 04 13:05:36 would you guys like to see the full error response? Jul 04 13:07:31 https://gist.github.com/anonymous/7b051a307f457393c99d Jul 04 13:09:04 I think the warning can be safely ignored (allthough it bothers me that it shows up at all) Jul 04 13:19:11 the error is quite odd Jul 04 13:19:21 and I can't seem to find anything about it on the internet Jul 04 13:19:30 bluelightning: maybe a stale linux.inc ? Jul 04 13:19:34 which is also very odd :o Jul 04 13:20:39 yes, package_stagefile_shell it's from the old times iirc Jul 04 13:23:06 fenrig: see https://github.com/beagleboard/meta-beagleboard/blob/master/common-bsp/recipes-kernel/linux/linux.inc Jul 04 13:23:22 KERNEL_DEVICETREE_ is already set Jul 04 13:23:42 just for fun, remove the linux.inc you have in meta-oe Jul 04 13:26:08 are we staying with kernel 3.8 for the next release even though its EOL? Jul 04 13:27:10 Net147: zeddii_home_ would be the best person to answer that but if it follows our usual pattern we'd be using 3.10 for this release Jul 04 13:28:01 zeddii_home_: ^ Jul 04 13:34:19 fenrig: have you already commented that line? Jul 04 13:39:55 ant_work: normally KERNEL_DEVICETREE wasn't present by default, I added it so I could have the dtb file for u-boot Jul 04 13:52:24 fenrig: the way Poky/Yocto does it is /linux-dtb.inc Jul 04 14:09:41 Heya, would anyone be willing to help me with a newbie idiot question? Jul 04 14:09:55 (build related) Jul 04 14:18:15 pev: ask, don't ask to ask Jul 04 14:19:23 oh, ok...! Jul 04 14:20:56 So I've just started getting to grips with yocto. I've got a BSP thats come from someone else and I'm playing with rebuilding uboot via "bitbake -v -f -c compile u-boot-pev". This works fine. However I'm trying to read up on what the 'correct' way is to modify and update patches for it Jul 04 14:21:50 So, there's a patch file : meta-my-board/recipes-bsp/u-boot/u-boot-pev/local-changes.patch Jul 04 14:22:11 but I don't know the accepted / convenient way to modify the source / update the patch is... Jul 04 14:22:31 one way is to use the devshell function Jul 04 14:22:38 bitbake -c devshell u-boot-pev Jul 04 14:22:38 I guess I'm missing something really obvious but cant seem to see anything obvious in the documentation Jul 04 14:22:56 that drops you into the source directory, where you can edit and compile directly Jul 04 14:23:14 actually generating the patch is Your Problem, so you can use quilt or git Jul 04 14:23:22 so does that update the patch auto-magically? Jul 04 14:23:25 ah Jul 04 14:23:45 Is there a quick a-b-c walkthrough of that somewhere out there? Jul 04 14:23:50 hm, not sure Jul 04 14:23:54 if not this should be in the manual Jul 04 14:24:01 have you looked through the docs on yoctoproject.org? Jul 04 14:24:06 I'm broadly familiar with quilt through devloping around openwrt Jul 04 14:24:11 cool Jul 04 14:24:28 so in the devshell, do the quilt stuff to edit a file and generate the patch Jul 04 14:24:32 but to be honest I've set up all my sources in SVN as I'm more familiar with it than GIT and havent got time to learn at the mo... Jul 04 14:24:35 then copy it out of the work dir into the layer Jul 04 14:25:02 So you think I should generate iterative patches rather than re-generating the existing patch? Jul 04 14:25:12 depends on the problem Jul 04 14:25:21 if you're fixing a patch, re-generating makes sense Jul 04 14:26:53 at the moment fixing but adding features next so both realy Jul 04 14:26:54 Okay I found the problem: in do_devictree_image of linux.inc of meta-beagleboard/common-bsp/recipes-kernel "package_stagefile_shell()" is not found, so I've copied it from linux-dtb.inc of "meta/recipes-kernel" Jul 04 14:27:22 Snort is soo close to starting as a daemon process. But it fails just as it forks because fork can't allocate enough memory. There is a fix: set the number in /proc/sys/vm/overcommit_memory to 1. Then you can set it back to 0 once the daemon is successfully started. Is there some standard way to handle this problem? Or should I just try to make it explicit in the snort initialization script? Jul 04 14:36:31 pev: Actually, I edit in the workdir but compile from the poky/build dir when making patches. bitbake -e is nice because it tells you the values of all the environment variables that you have set, shows how they were expanded, etc. bitbake -c listtasks will tell you all the tasks available for a particular recipe. Jul 04 14:37:06 mulhern: devshell gives you a terminal with all those set for you Jul 04 14:37:07 mulhern : what do you do to recreate the patch in your world? Manually? Jul 04 14:38:33 rburton: Yep, I know, more or less the same thing. Jul 04 14:40:43 pev: My one experience with regenerating an existing patch was awkward. Right now I'm really only generating new patches. I think quilt can help you with the regeneration stuff as well, but I started using quilt two weeks ago…and that was after the regeneration experience. Jul 04 14:41:38 Ok, I'd settle for your procedure for generating new for now :-D Is it as low tech as duplicating a clean un-built dir and then manually diffing to your modified dir? I know it works but feels very clunky! Jul 04 14:42:15 using quilt in the work directory is easy enough Jul 04 14:42:26 the patches are generated in the wrong place, but you can mv them to where your recipe is easy enough Jul 04 14:43:25 I take it you have to manually take care of patch sequencing via patch file name prefixes? Jul 04 14:43:55 bitbake's SRC_URI is sorted in order of application Jul 04 14:44:02 rburton_: Is that the same as what I'm reading here : http://www.yoctoproject.org/docs/1.0/poky-ref-manual/poky-ref-manual.html#usingpoky-modifying-packages-quilt Jul 04 14:44:16 pev: yes Jul 04 14:44:21 Ok, so it's explicit via SRC_URI and not wildcarded? Jul 04 14:45:52 wildcards have gotchas Jul 04 14:45:56 so its best to be explicit Jul 04 14:46:24 i wonder if its possible to setup quilt "properly" when unpacking, so quilt refresh actually updates the patches in the layer Jul 04 14:48:13 pev: those docs are old, http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#using-a-quilt-workflow is the latest copy Jul 04 14:49:42 rburton_: thanks Jul 04 14:58:41 rburton_: pretty sure quilt refresh unlinks and recreates patches, rather than following links, so they'd have to be hardlinked, which would limit the paths to not crossing filesystem boundaries, or you'd have to alter quilt to write them in place, i think, anyway Jul 04 14:58:47 * kergoth shrugs Jul 04 14:59:23 kergoth: awww, the hardlink limitation would stop it working for me at least, so i don't care anymore :) Jul 04 14:59:31 rburton_: the patch resolver stuff will automatically update the layer files if the quilt series changes after fixing it in the patch resolver shell, iirc, but that was never very pretty Jul 04 15:00:24 I could see an argument for a quilt refresh argument which makes it modify in-place.. hmm Jul 04 15:00:33 it would be nice if the patcher automatically did a git init and effectively did a git am of each patch Jul 04 15:01:00 that could be interesting, indeed Jul 04 15:01:15 one time i had a experimental class that turned workdir into a git repo and tagged the tasks :) Jul 04 15:01:21 was interesting to examine that log Jul 04 15:01:23 ha Jul 04 15:01:26 yes i bet Jul 04 15:06:48 kergoth, shouldn't you be drinking beer and shooting fireworks? Jul 04 15:07:23 rburton_: actually, there's already a git-apply based patch applier, doubt it'd take much to extend that.. hmm Jul 04 15:08:06 heh, i hate arizona on the 4th, we never want to go watch fireworks in the evening because it's way too damn hot to be sitting outside :) Jul 04 15:08:16 heh Jul 04 15:08:28 and I figure they are worried about catching everything on fire Jul 04 15:08:44 here, we are hoping it stops raining long enough for them Jul 04 15:09:13 Hmm, somewhere around here I have a rewritten patch.bbclass which avoids the classes, resolver stuff, and had a partial implementation of series file support, so you could do file://foo.series or file://series rather than listing each file Jul 04 15:09:25 Crofton: heh, gotta love mother nature Jul 04 15:10:14 yeah Jul 04 15:10:40 there was a lot of localized flooding yesterday Jul 04 15:10:59 more possible today Jul 04 15:23:34 * rburton_ wonders what to talk about at ELCE Jul 04 19:05:27 seebs, there is a typo in your book. i am disappointed. Jul 04 19:05:53 Oh? Jul 04 19:06:11 I think I know of a couple which I've reported to APress, but I don't think sales are fast enough that additional printings are super likely. Jul 04 19:06:31 page 158 under Almquist Shell Jul 04 19:06:37 there's an extra paren Jul 04 19:06:46 (ash)) Jul 04 19:07:07 Meh. Jul 04 19:07:32 and this concludes The Daily Pedant Jul 04 19:07:37 Well, that's not so much a typo as the inevitable punishment for your moral failings, see. Jul 04 19:07:53 seems plausible. Jul 04 20:30:11 Hi Guys. Is there a way to add autotool site config options to a recipe? Jul 04 21:44:26 MWelchUK: sure - you can use CACHED_CONFIGUREVARS or meta/site/* **** BEGIN LOGGING AT Fri Jul 05 01:50:51 2013 **** ENDING LOGGING AT Fri Jul 05 02:59:58 2013