**** BEGIN LOGGING AT Wed Dec 07 02:59:57 2011 Dec 07 05:34:52 msm... thanks. I will look into that. Dec 07 05:36:36 my problem is that I have a whole bunch of old-time developers here who are extraordinarily crotchety. Not sure if that will fly. (ie. using sdk to compile and ssh packages over). Dec 07 05:37:10 they are going to want a way to compile a full image, but point at their local svn checkout. Dec 07 05:37:46 I'd like to write up and document both ways of doing it, if possible. Dec 07 05:38:30 I'll try out the S= trick. Dec 07 05:38:55 Is there a way to have what is checked into the recipe point to the 'regular' spot, and then override for one build? Dec 07 05:40:39 *** re-reading the recommendations for the third time, now, I think I finally grok what you are saying. I'll try some stuff out and get on the mailing list if I have more questions. Dec 07 05:45:47 mebrown: just build an lsb-sdk image Dec 07 05:45:55 then compile on the target Dec 07 05:46:07 wow Dec 07 05:46:10 probably not Dec 07 05:46:21 I think we have 64mb flash Dec 07 05:46:44 network? Dec 07 05:47:11 I think I get two suggestions from the above... a layer with S=/local/src/.../ and also one where you use SDK to compile a pkg and ssh it over Dec 07 05:47:43 network would be getting rather sophisticated Dec 07 05:48:04 and I am dealing with a dev team that is rather... um... un... sophisticated Dec 07 05:48:11 mebrown: im saying Dec 07 05:48:14 use nfs Dec 07 05:48:17 for development Dec 07 05:48:27 make an lsb-sdk, nfs development Dec 07 05:48:36 then you can package their final stuff up Dec 07 05:48:51 first, I'm sure folks would pull their hair out, I don't think our board is that fast. Dec 07 05:49:19 I'm doing good just getting them to look at yocto, but I've been able to impress so far. Dec 07 05:49:32 cached build at 6 minutes down from 2 hours with the old system Dec 07 05:49:54 msm, but I do understand what you are saying about doing an lsb-sdk Dec 07 05:50:27 mebrown: or you can just use a "merge-files" type recipe Dec 07 05:50:30 I'll look into that, too. I just don't think people are going to like that. IIRC, we have a 200mhz chip or so Dec 07 05:50:50 have your developers scripts install stuff to a specific folder, which is then included in the root fs Dec 07 05:51:11 easier than dealing with cross compiling and all the other foo Dec 07 05:51:13 what do you mean by merge-files recipe? Dec 07 05:51:29 honestly, the cross compiling hasn't been the hard part. Dec 07 05:53:27 So far, I've gotten 60 open source packages ported over to use yocto, and it took all of two weeks. Dec 07 05:53:36 Now I'm working on our proprietary stack on top of that. Dec 07 05:53:57 and this is where people are going to want to be able to make changes in a local svn checkout, compile and test. Dec 07 07:00:32 Hi All, whats the correct way of building in-tree kernel modules? I found the out-of-tree kernel module build using "inherit module". kernel-module-* seem to only copy module to rootfs if already existing in modules.tgz. What I want to do is build an in-tree kernel module after the kernel itself has been built.. Dec 07 10:06:22 morning all Dec 07 10:21:38 morning Dec 07 11:05:14 morning Dec 07 13:17:48 What are the cariable locality rules for PREFERRED_PROVIDER?, I seem to be unable to choose virtual/kernel from my image.bb Dec 07 13:18:35 *variable Dec 07 13:20:59 d4ny: I think that you could only do that within either your machine.conf file, your distro configuration or local.conf Dec 07 13:21:21 bluelightning: Arrgh .. Dec 07 13:21:58 i would have thought in most cases the machine configuration is the appropriate place to set the preferred kernel Dec 07 13:22:19 bluelightning: I think the variable locality restrictions are somewhat to restrictive sometimes. In this case I want to create a debug-version of the same kernel Dec 07 13:23:22 bluelightning: I probably should not create a new machine for a debug flavoured kernel, it feel wrong somehow... Dec 07 13:23:29 hmm, that does sound like a good use case Dec 07 13:25:33 Or if there is some existing mechanism to inject kernel .config mods to the original kernel might be even prettier. Dec 07 13:26:33 well, there is, if modifying that kernel is the right thing in your situation Dec 07 13:27:46 Point me in the right direction, i.e. example .bb file :) Dec 07 13:28:55 well, you'd just add your additional kernel configuration options to a .cfg file and add that to the end of SRC_URI for the kernel recipe Dec 07 13:30:16 Yes, but that would mean I have to edit the kernel recipie evertime I wanted to switch kernel flavour, no ? Dec 07 13:30:45 yes, it's not going to help with your separate image thing Dec 07 13:31:05 the thing about PREFERRED_PROVIDER is it's for build time dependencies, not runtime Dec 07 13:32:50 I think this might be a question to post to the mailing list; it really does sound like something we'd want to support even if there is no mechanism to do it right now Dec 07 13:33:25 uderstood, will do .. Thanks for clearing it up bluelightning Dec 07 14:35:37 RP__: regarding the initramfs packages, I'm tempt to name the recipe initramfs-framework_1.0.bb ... would you be OK with that? Dec 07 14:48:24 otavio: yes Dec 07 14:56:07 RP__: good; will prepare it and send Dec 07 16:07:57 RP__: can we talk about #1711 here? Dec 07 16:08:09 JaMa: yes Dec 07 16:08:19 JaMa: I have an idea what might be wrong Dec 07 16:08:35 from that diff is clear that GID is different for crespo and palmpre machine Dec 07 16:09:07 JaMa: different numerical IDs are unintersting Dec 07 16:09:10 but the .ipk file created in armv7a-vfp-neon can be either from crespo build or palmpre build (depends who built dbus later) Dec 07 16:09:45 JaMa: what matters more is whether the file ownerships was correct or not Dec 07 16:09:58 so it's only testlab problem that it's showing wrong owners? Dec 07 16:11:14 JaMa: no, I didn't say that Dec 07 16:11:38 JaMa: Its expected that a given group can change its ID Dec 07 16:11:52 JaMa: but all files belonging to that group should have the correct IDs Dec 07 16:12:34 so all of avahi's files should belong to avahi, it doesn't matter which numerical ID avahi has Dec 07 16:13:13 agreed but that file should belong to messagebus in both images not to avahi for palmpre Dec 07 16:14:41 JaMa: right, that is true and I think I was misreading some of this Dec 07 16:19:18 the broken image (with avahi) is here: http://build.shr-project.org/shr-core-staging/004/images/palmpre/old/ and tar -tvf ../shr-lite-20111207-palmpre.rootfs.tar.gz | grep dbus-daemon-launch Dec 07 16:19:22 -rwsr-xr-- root/avahi 184808 2011-12-05 01:19 ./usr/libexec/dbus-daemon-launch-helper Dec 07 16:19:39 JaMa: can you build that broken image at will? Dec 07 16:19:41 is what's wrong here Dec 07 16:20:06 probably yes with right order of machines used Dec 07 16:20:22 JaMa: If so, I've attached a patch to the bug in the bugzilla which I think might be the problem Dec 07 16:20:26 (untested) Dec 07 16:21:13 JaMa: summary, pseudo needs to use the rootfs passwd/group files, not the sysroot ones Dec 07 16:21:16 at rootfs time Dec 07 16:21:30 ok I'll test it later (after I can confirm that I'm able to reproduce it at will) Dec 07 16:23:00 isn't similar problem when creating packages? Dec 07 16:24:13 ie do_populate_sysroot from sstate (but created by different machine with different STAGING_DIR_TARGET) and then packaging to .ipk while looking to different STAGING_DIR_TARGET? Dec 07 16:31:13 JaMa: we need the users present in the config in the sysroot but we don't really care about the permissions/owners of files in the sysroot itself Dec 07 16:32:04 ok Dec 07 16:33:06 and any input on TUNE_PKGARCH as OVERRIDE? Dec 07 16:43:00 JaMa: I don't think I've even seen that discussion :/ Dec 07 16:44:19 ok, let me search log Dec 07 16:45:19 RP__: http://paste.pocoo.org/show/517600/ Dec 07 16:51:39 JaMa: I think the tune files should add overrides if they need them Dec 07 16:52:01 JaMa: There is not a general case for TUNE_PKGARCH making sense Dec 07 16:54:57 isn't what about extra optimalization ie for mplayer which are usefull for whole arch like armv7a(armv7a-vfp-neon)? would you apply patch to add armv7 override to meta/conf/machine/include/arm/arch-armv7.inc ? Dec 07 16:56:01 I'm trying to resolve this: http://patches.openembedded.org/patch/15777/ Dec 07 17:11:39 sgw: are you around? I'm wondering if we need two versions of qt-x11-free in meta-qt3 Dec 07 17:16:09 RP__: your patch for #1711 seems to help Dec 07 17:16:31 RP__: I was able to build another broken image without it and then just with this patch another one was OK Dec 07 17:17:21 bluelightning: here, I think I need more context on the qt-x11-free issue Dec 07 17:18:06 sgw: we have two versions in meta-qt3 (3.3.6 and 3.3.7), they have been there from the beginning so there isn't history recording why we have both Dec 07 17:18:32 sgw: http://git.yoctoproject.org/cgit/cgit.cgi/meta-qt3/tree/recipes-qt3/qt3 Dec 07 17:20:47 bluelightning: you would have to check with Xiaofeng on that one, is one get DEFAULT_PREFERENCE set? Dec 07 17:21:06 sgw: no DEFAULT_PREFERENCE no Dec 07 17:21:26 actually it looks as if 3.3.6 depends on uicmoc3-native which we don't even have, so I can't see it being of much use Dec 07 17:22:25 Then I guess it can be removed, I also just noted PREFERRED_VERSION_qt-x11-free = 3.3.7 in the 3.3.7 recipe, not sure that belongs there either. Dec 07 17:25:02 sgw: yeah I saw that too, will remove it Dec 07 17:26:05 does anyone know if there is a specific meta-oe that was testing against edison branch? Dec 07 17:29:58 JaMa: cool, I suspect it is the cause of the problem you're describing Dec 07 17:30:51 RP__: yup, I'll reopen and bug you again if I get broken images later .. Dec 07 17:35:08 JaMa: I'll propose the patch on the list Dec 07 17:36:33 does anyone use meta-oe with yocto? Dec 07 17:37:22 msm: I do, in a way. I use a seperate repo model like the oe folk do, and add meta-yocto to it after ripping it out of poky Dec 07 17:38:34 we should turn that into a separate repo... Dec 07 17:38:49 * RP__ keeps meaning to but also finding other higher priority stuff :/ Dec 07 17:38:53 kergoth`: do you encounter any issues? Dec 07 17:38:59 kergoth`: or just use top of tree? Dec 07 17:39:01 * kergoth` has a daily script that does cd poky.git; git fetch; git filter-branch -f --subdirectory-filter meta-yocto --tag-name-filter cat -- --all Dec 07 17:39:16 msm: seems fine so far. we're using both meta-yocto and meta-oe in systembuilder Dec 07 17:39:29 hmm Dec 07 17:39:52 not sure what the layer priorities are relative to one another, need to make sure my bbpath priority order matches up with the BBFILE_PRIORITY_* Dec 07 17:40:31 kergoth`: side rant (our BJ people are having issues with this) Dec 07 17:45:37 RP__: and the arm7 tune? Dec 07 17:46:14 msm: what sort of issues, out of curiosity? Dec 07 17:47:44 JaMa: well, its pretty sad that meta-oe is angstrom only Dec 07 17:47:59 I do builds iwth meta-oe without angstrom every week Dec 07 17:48:10 unless they broke it recently? Dec 07 17:48:29 RP__: do you intentionaly ignore SHR? :) Dec 07 17:48:34 kergoth`: hard to say exactly Dec 07 17:48:36 kergoth`: the mplayer recipe uses angstrom specific overrides apparently Dec 07 17:48:39 there's micro also Dec 07 17:48:45 but the example that gave was after adding the later, cramfs-native failed to build Dec 07 17:48:56 ERROR: Could not include required file recipes-graphics/xorg-driver/xorg-driver-input.inc Dec 07 17:48:58 JaMa: Ah, ok, shr and angstrom specific :) Dec 07 17:49:13 as i said, i've built it before with micro. not every recipe, admittedly Dec 07 17:49:22 I'm sure they'd take patches to fix any brokenness Dec 07 17:49:33 kergoth`: It got NAK'd by koen Dec 07 17:50:23 IMO if meta-oe ever becomes angstrom specific, a large number of people will just stop using it entirely Dec 07 17:50:26 including Mentor Dec 07 17:50:45 kergoth`: http://patches.openembedded.org/patch/15777/ Dec 07 17:51:14 kergoth`: I'm not happy about the general principle here, that is what is irritating me Dec 07 17:52:05 no, OE-Core didn't take FEED_ARCH into OVERRIDES and there was discussion about why. We should be solving the problem, not doing the above Dec 07 17:52:22 RP__, kergoth`: I agree with koen that keeping FEED_ARCH in meta-oe makes it closer to OE-classic Dec 07 17:52:25 his response doesn't indicate that its angstrom specific, just that it has a specific expectation for its distros, but fair enough, I disagree with him on this as well Dec 07 17:53:06 and we need replace FEED_ARCH overrides with something when ie importing some recipe from OE-classic (like mplayer2) Dec 07 17:53:10 kergoth`: Its not in the default settings in OE-Core, or in poky so neither of those will work as expected with that recipe Dec 07 17:53:42 JaMa: agreed but as I said, I think some specific overrides in the tune files may make more sense Dec 07 17:53:54 JaMa: yeah, it should been addressed when the recipe was added to meta-oe Dec 07 17:53:59 the x86 platforms now add an x86 override for example Dec 07 17:54:18 RP__: I'm really worried that there's going to be a proliferation of layer forks if things continue as is Dec 07 17:54:29 RP__: so again, can I send patch adding armv7 override to include/arm/arch-armv7.inc (and the same for armv6)? Dec 07 17:54:38 kergoth`: of which layers? meta-oe? Dec 07 17:55:06 JaMa: I think so, yes. If nothing else we need to discuss that Dec 07 17:55:27 well, there are a number of issues that can cause you to need to fork. in this case meta-oe administrative, but there are also issues with mismatches of bbappend vs core recipe version, as per the thread where it was mentioned that shr is maintaining their own branches Dec 07 17:55:54 personally, I'm having to lock down to a specific oe-core/meta-yocto/meta-oe set of hashes and bump explicitly or I get bit in the ass every day :) Dec 07 17:56:29 kergoth`: right, there is certainly a problem there we need to solve Dec 07 17:56:43 I have no clue what a solution would look like though :| Dec 07 17:56:46 its nontrivial Dec 07 17:56:58 kergoth`: I wonder if we put wildcards into bbappend filenames? Dec 07 17:57:46 * RP__ is thinking out loud so if this has some nasty implication I haven't thought of yet I wouldn't be surprised Dec 07 17:58:22 It would certainly solve that problem and be easy to implement in bitbake Dec 07 17:59:05 a related issue I got bit by is wanting to add a bbappend to a common layer whose recipe exists in a bsp layer. if I leave that bsp layer out to build a different one, build fails due to the append of a nonexistent recipe. so I have to either fork the upstream bsp layers or add my own bsp specific layers on top of them :\ Dec 07 18:10:06 but .bbappends are not worst issue imho, ie todays gcc patch applied twice can go completely unnoticed if it didn't break build later Dec 07 18:10:58 locking revisions could for for me too but the tooling wasn't here (and maybe still isn't) so I've started contrib/shr branches Dec 07 18:12:55 kergoth`: I guess there are other ways to achieve that but I know what you mean Dec 07 18:19:28 well, I can't see a way that isn't annoying one way or another :) bsp specific branches in the common layer, etc Dec 07 18:19:31 * kergoth` shrugs Dec 07 18:19:51 It'd be nice if somehow we could modify metadata via rulesets Dec 07 18:19:53 Dec 07 19:56:09 zeddii, ping Dec 07 19:56:17 zeddii, is meta-kernel-dev working for you? Dec 07 19:56:32 it's prepending git:/// to my local git URL and failing to clone it Dec 07 19:57:42 it works here, but my clones were about a week out of date. I just built with it not 10 minutes ago. Dec 07 19:57:52 then I pulled to merge your changes. Dec 07 19:57:56 I should try again :) Dec 07 19:58:00 KSRC_linux_yocto=/home/dvhart/source/linux/linux-yocto-3.0.git Dec 07 19:58:02 is that right? Dec 07 19:58:17 if I clone that specific string with git it works Dec 07 19:58:24 but bitbake craps out with: Dec 07 19:58:38 | ERROR: Function 'Fetcher failure for URL: 'git:///home/dvhart/source/linux/linux-yocto-3.0.git;protocol=file;nocheckout=1;branch=yocto/standard/fri2,meta;name=machine,meta'. Unable to fetch URL git:///home/dvhart/source/linux/linux-yocto-3.0.git;protocol=file;nocheckout=1;branch=yocto/standard/fri2,meta;name=machine,meta from any source.' failed Dec 07 19:59:45 from the looks of it, it didn't take your overridden name. Dec 07 20:00:44 I have: KSRC_linux_yocto ?= /home/bruce/yocto-kernel/linux-yocto-3.0.git Dec 07 20:00:53 and it worked fine, but I'm doing a full clean now. Dec 07 20:04:07 ugh Dec 07 20:04:18 appears to have been permissions issues on my NAS mounted downloads dir Dec 07 20:04:23 I have to figure out how to fix that Dec 07 20:04:30 phew. (for me, not you). Dec 07 20:04:33 (and how to get the error message to indicate such a failure) Dec 07 20:04:36 fixed and rolling Dec 07 20:04:43 I'm testing my efi scc fixes now Dec 07 20:04:53 http://pastebin.com/ar468QqQ Dec 07 20:04:55 ^ preview there Dec 07 20:04:58 mind having a look? Dec 07 20:05:24 I haven't tested booting -rt with EFI yet Dec 07 20:05:34 but I imagine we'll need those EFI patches there as well Dec 07 20:06:15 efi changes look solid to me. I'm about to do one build and push the kernel tree out, so they'll be in place pretty soon. Dec 07 20:06:35 you still need the ecc patches from me though Dec 07 20:06:48 ecc cfg and scc patches for meta I mean Dec 07 20:06:52 I have the kernel ones, you mean the .scc ones. yes. I'll hold for those. Dec 07 20:08:57 OK, grr, hitting some meta related failures Dec 07 20:09:11 will pound through them and get your the scc patches as soon as I can Dec 07 20:09:57 no worries. I have plenty to keep me busy :) Dec 07 20:12:05 zeddii, ok, this is strange Dec 07 20:12:19 zeddii, mv: cannot stat `/build/poky/fri2/tmp/work/fri2_noemgd-poky-linux/linux-yocto-3.0.8+git68+ae3e64c077972fe87f09946bd215620df68ca327_2+bdb0cabe7bd20b74c47d6d4e65d14c633028bfea-r2/linux-fri2-noemgd-standard-build/.tmp.config*': No such file or directory Dec 07 20:12:19 creation of pre-processed config data failed Dec 07 20:12:35 the *-build dir is empty Dec 07 20:12:49 this is do_kernel_configme Dec 07 20:13:03 the meta-series looks sane to me Dec 07 20:13:19 hmm. that's what happens to wrap the new merge_config.sh script. Dec 07 20:13:35 so you've got something happening that isn't here. Dec 07 20:13:40 let me go have a look. Dec 07 20:14:49 I've added cfg/efi-ext.scc to the KERNEL_FEATURES Dec 07 20:15:08 but I had cfg/smp.scc there before Dec 07 20:15:28 but I guess I hadn't yet tried with the merge-config stuff yet Dec 07 20:15:54 do I have enough to do that same build here ? I'm not seeing any failures. checking more now. Dec 07 20:16:06 you need the scc files Dec 07 20:16:15 oh no, you need my fri2 branch too Dec 07 20:16:16 hrm Dec 07 20:16:33 hmm. I'm wondering if you aren't running the merge_config.sh with my 3 changes (which I need to send upstream) Dec 07 20:16:38 * zeddii nags himself Dec 07 20:16:55 well... how could I be then? Dec 07 20:16:58 without my changes, you wouldn't get that output file. Dec 07 20:17:06 and hence it wouldn't move away. Dec 07 20:17:33 dvhart, do you have a merge_log.txt in your meta/cfg/ directory structure ? Dec 07 20:17:39 so... are you saying HEAD will fail now b/c it doesn't have those changes? Dec 07 20:17:59 no HEAD should be fine. I sent them up with the kern_tools update. as I stage to get everything in tree. Dec 07 20:18:13 but I'm wondering if another merge_config.sh that you have on a path was picked up first ? Dec 07 20:18:17 $ cat ./yocto/standard/fri2/merge_log.txt Dec 07 20:18:28 /build/poky/fri2/tmp/sysroots/x86_64-linux/usr/bin/configme: line 183: merge_config.sh: command not found Dec 07 20:18:32 oops Dec 07 20:18:50 interesting. now that's not supposed to happen. Dec 07 20:18:55 * zeddii goes to look Dec 07 20:19:00 that output needs to be in the bitbake log output Dec 07 20:19:20 indeed. it never failed, so I'm not even trapping the return code. making that change now. Dec 07 20:19:42 dvhart@envy:~/source/linux/linux-yocto-3.0/meta [dvhart/meta/efi] Dec 07 20:19:42 $ find . -name merge_config.sh Dec 07 20:20:06 it should be coming from the kern_tools "make install" Dec 07 20:20:10 hrm... I'm not using a meta-kernel-dev kernel-tools I don't think Dec 07 20:20:26 I thought you sent patches to prefer the in tree ones Dec 07 20:20:42 I did. but things are still out of tree, I'm merging them in now. Dec 07 20:20:58 aha, ok, so I need to use kernel_tools from meta-kernel-dev Dec 07 20:21:34 you shouldn' t have to. the changes can co-exist. So I sent a new SRCREV for kern tools that should have installed merge_config.sh into the sysroot while I migrate to in-tree building. Dec 07 20:28:21 ah, maybe I'm not using a new enough master Dec 07 20:28:25 I don't refresh very often Dec 07 20:28:50 * zeddii makes no claims on that part either. in particular when deep in kernel hacking. Dec 07 20:29:34 yup, there is a change, /me cherry picks Dec 07 20:30:27 * zeddii once again that dvhart makes him remember to code defensively. Dec 07 20:30:34 s/that/notes that/ Dec 07 20:30:38 hehe Dec 07 20:30:58 I modified things to pickup those conditions. at least I logged it ;) Dec 07 20:31:07 thank you much! Dec 07 20:32:16 ok, the build is off and going again. Grabbing lunch and hopefully things run to completion. Will send efi scc patches as soon as I can test them. Dec 07 20:32:20 thanks zeddii Dec 07 20:32:35 np. I'm building what I have so far to be ready. Dec 07 22:54:17 zeddii, efi scc patches away Dec 07 22:54:29 zeddii, sorry, I ran into one additional hiccup, but got that resolved **** BEGIN LOGGING AT Wed Dec 07 23:52:25 2011 Dec 08 00:58:06 mebrown: ping **** ENDING LOGGING AT Thu Dec 08 02:59:57 2011