**** BEGIN LOGGING AT Sun Jan 20 02:59:59 2013 Jan 20 06:26:31 Are there any good write-ups on how companies/teams manage their local OE setups vs upstream? Jan 20 08:42:09 | * check_data_file_clashes: Package font-alias wants to install file /home/hrw/HDD/devel/canonical/aarch64/openembedded/build/tmp-eglibc/work/genericarmv8-oe-linux/core-image-lsb-dev/1.0-r0/rootfs/usr/share/fonts/X11/misc/fonts.alias Jan 20 08:42:13 | But that file is already provided by package * xorg-minimal-fonts Jan 20 08:42:16 ugly Jan 20 08:42:21 hchapman: ping Jan 20 08:43:21 hchapman: take a look at http://git.linaro.org/gitweb?p=openembedded/meta-aarch64.git and http://git.linaro.org/gitweb?p=openembedded/meta-linaro.git repos. I use them both + meta-openembedded + openembedded-core for doing my builds Jan 20 08:44:39 hchapman: there are some bbappend files to change packages (pulseaudio in meta-aarch64 has other dependencies), own images (linaro-image-minimal is core-image-minimal + nfs + ssh) Jan 20 08:45:47 hchapman: came back at better time - european day would be perfect Jan 20 09:14:00 hrw: thanks! Jan 20 09:16:33 Maybe a stupid question: Could I, for example, create a layer, meta-hchapman, that layers on top of meta-aarch64 and uses its kernel bbapand files and then my own in my layer, too? Or do I have to copy the aarch64 changes into my own layer? Jan 20 09:17:27 I guess it's about 10:15 in France. Of course, it is sunday. Jan 20 09:22:45 hchapman: you better do not layer on top of meta-aarch64. unless you do some bringup for aarch64 architecture. Jan 20 09:23:07 some of changes in that layer may break other architectures Jan 20 09:24:18 hchapman: for most of situations own layer on top of oe-core + meta-oe is enoug Jan 20 09:24:19 h Jan 20 09:24:20 hrw: well, in my case, I'd be using the meta-gumstix layer which has special tweaks for their boards, except we have our own custom board which requires some u-boot and kernel MUX and code changes. For the most part we want everything they do with a few changes here and there for us. Jan 20 09:24:41 cool Jan 20 09:25:28 so, would I make our layer in parallel to theirs? or would I clone and branch theirs to suit us? I'm just looking for what has worked for others. Jan 20 09:26:05 if you need their changes and your changes are separate to theirs then parallel Jan 20 09:26:22 if you need to change their layer then two options Jan 20 09:26:24 I think I understand the new layers approach of OE-core (we're on OE-dev) only about 75%. Jan 20 09:26:50 1. branch their and do own changes. cons: you have to merge all their changes each time Jan 20 09:27:16 Well, they would add an overo/ subtree to U-boot and we would change things in their added files to make sense for our pinouts Jan 20 09:27:18 2. make your layer on top of their layer. pros: just fetch their layer, no merging. Jan 20 09:27:37 2 seems more appealinh Jan 20 09:27:47 yes Jan 20 09:28:01 will the recipes stack? Jan 20 09:28:18 from time to time you will have to do some managing work due to version changes or patches changed but doable Jan 20 09:28:31 Our current bit bake doesn't and so I'm not sure how the bbappends work. Jan 20 09:28:39 layers have priority field Jan 20 09:28:58 but I do not remember how stack of bbappends behave Jan 20 09:29:27 right. we would lock to a version of their repo and then have a (e.g.) quarterly process of reviewing all our upstream repos and decided how far to move forward. Jan 20 09:29:34 layers were done when I was off from OE ;D Jan 20 09:29:48 good idea Jan 20 09:30:00 We've been stuck on OE-dev and not even a recent release. Jan 20 09:30:19 hchapman: remember to freeze on all layers Jan 20 09:30:30 OE-dev as OE/classic no layers? Jan 20 09:30:33 Well, I'm just trying to avoid a lot of maintenance merging and other busy work Jan 20 09:30:45 freeze? Jan 20 09:30:52 yes Jan 20 09:30:55 OE classic Jan 20 09:31:07 fetch all needed layers and use one set of revisions for longer time Jan 20 09:31:08 they call it OE-dev in all of the wikis and docs. Jan 20 09:31:19 yeah, that's what I meant. Jan 20 09:31:54 I always had problem with OE wikis/docs. wrote some parts of them but nearly never read them Jan 20 09:32:13 we're a very small team, 4-5, and everything other than coding falls to me. Well, plus coding. So, if I want time to code... Jan 20 09:32:22 in March I will celebrate 9 years with Oe Jan 20 09:32:26 nice Jan 20 09:32:39 I spent a lot of time with buildroot before OE. Jan 20 09:33:37 I've found the yocto docs to be quite helpful Jan 20 09:35:37 I think it would be nice if there were a "Maintainers" manual that covered the kind of questions I have. It would also cover how to setup OE for teams where you share build state and package output between a central build server and dev machines. Jan 20 09:36:39 It seems like there are finally docs for single devs getting started, but nothing about how to use OE in a team environment. Jan 20 09:37:32 I'm looking forward to getting that kind of stuff working. Currently, if I make a single tweak to Qt, every dev's next build will take 1-4 hours while they wait for Qt to be re-built. Jan 20 09:38:20 Also, it would help to keep the size of the dev VMs down. Jan 20 09:40:45 Out of curiosity: do you know what parts of "tmp" are required to be copied in order to duplicate a build environment. I.e, I've copied all of the layers. Now I want to copy the bare minimum to produce a build. I'd also love to wipe out my sysroot folders and figure out how to get OE to rebuild them just using the pieces needed currently for my build. Jan 20 09:41:04 * hchapman gets back to work. Jan 20 09:44:27 do not copy TMPDIR at all Jan 20 09:44:38 share sstate-cache Jan 20 09:44:46 I see. Jan 20 09:45:03 hchapman: check http://marcin.juszkiewicz.com.pl/2013/01/11/doing-openembedded-builds-in-ram/ Jan 20 09:45:32 hchapman: in http://marcin.juszkiewicz.com.pl/archives/ you can find more OE related posts but most are about OE classic Jan 20 09:46:21 cool Jan 20 09:46:55 OE classic articles are still relevant as I migrate us from dev to core Jan 20 09:50:58 The RAM bit just sunk in… For my day to day development of a couple small recipes and production of build images, I could wipe out my TMPDIR and put it in RAM. Jan 20 09:51:32 which would be big enough to build our apps and produce an image. Jan 20 09:52:09 well, depending on what gets generated. I'll try that on disk and see how big TMPDIR is when I'm done. Jan 20 12:11:53 Is it possible to run a raspberrypi sd img in qemu ? Jan 20 12:58:31 kroon: it requires a bit of messing about and you will need "-cpu arm1136-r2" support in your qemu so pretty recent GIT. It's been a while since I messed with it as RPi's are not exactly hard to come by to mess with ;) Jan 20 13:01:39 DJW|Home, ok.. I thought it was "-cpu arm1176" ? I'm using qemu-linaro from git, and I do see a arm1136-r2 in the list, so I'll give it a shot Jan 20 13:02:45 kroon: IIRC the old profile is lacking some fixes needed for the RPi but I can't vouch for it. Also, as mentioned its been a fair while since I tried the images on qemu ;) Jan 20 13:56:00 I'm confused.. I have created my own image, that just inherits from core-image. If I build this image, I get the kernel-modules installed in the resulting image. If now add a line 'IMAGE_INSTALL += "e-wm"', the resulting image will _not_ have the kernel-modules shipped with it... Jan 20 14:24:13 oh.. think I get it, I guess I was setting IMAGE_INSTALL to "e-wm" only, thereby skipping packagegroup-core-boot Jan 20 15:25:51 what is the variable for changing package options? Jan 20 17:14:26 Crofton|work, PACKAGE_CLASSES ? Jan 20 17:31:42 kroon, http://cgit.openembedded.org/openembedded-core/commit/?id=7a58911f6951abd56db9ebb37f8d6284d91fa514 Jan 20 17:51:58 Crofton|work, aha Jan 20 17:56:32 there are a few of use using the gnuradio recipe Jan 20 17:56:44 and I know the other guys keep editing the options it is built with :) Jan 20 18:23:16 gah Jan 20 18:23:30 PACKAGECONFIG does not work with cmake recipes Jan 20 18:23:53 RP, awake? Jan 20 22:32:00 Crofton|work: technicallu Jan 20 22:51:19 RP, would adding Jan 20 22:51:37 + appendVar('EXTRA_OECONF', extraconf) Jan 20 22:52:05 + appendVar('EXTRA_OECMAKE', extraconf) Jan 20 22:52:10 be OK? **** ENDING LOGGING AT Mon Jan 21 02:59:58 2013