**** BEGIN LOGGING AT Mon Feb 18 02:59:58 2013 Feb 18 08:22:52 good morning Feb 18 09:24:28 morning all Feb 18 09:26:56 hi bluelightning Feb 18 09:37:58 is there QT5 recepy usable for Pandaboard or Raspbery Pi ? (or am I asking something stupid again :) Feb 18 09:42:47 REalm: there is a meta-qt5 layer somewhere but last I heard its state is pre-alpha Feb 18 09:44:41 thanks Feb 18 09:47:49 REalm: https://github.com/meta-qt5 Feb 18 11:50:56 <_Lucretia_> how do I sepcify a spcific kernel in aspecific layer? Feb 18 11:50:58 <_Lucretia_> ERROR: Multiple .bb files are due to be built which each provide virtual/kernel (/home/laguest/src/yocto/gumstix/poky/meta-mibtec/recipes-kernel/linux/linux-ti-psp-omap_2.6.37.bb /home/laguest/src/yocto/gumstix/poky/meta-gumstix/recipes-kernel/linux/linux-sakoman_3.5.bb). Feb 18 11:50:59 <_Lucretia_> This usually means one provides something the other doesn't and should. Feb 18 11:53:29 _Lucretia_: PREFERRED_PROVIDER_virtual/kernel = "something" Feb 18 11:53:39 in either local.conf or more appropriately in your distro config Feb 18 11:53:40 <_Lucretia_> yeah, I have something alright Feb 18 11:53:58 <_Lucretia_> PREFERRED_PROVIDER_virtual/kernel ?= "linux-ti-psp-omap" Feb 18 11:53:59 <_Lucretia_> PREFERRED_VERSION_linux-ti-psp-omap ?= "2.6.37" Feb 18 11:53:59 <_Lucretia_> PREFERRED_VERSION_linux-libc-headers ?= "2.6.37" Feb 18 11:54:13 <_Lucretia_> is what I have, but it's selecting the wrong kernel Feb 18 11:54:27 does it make a difference if you change ?= to = ? Feb 18 11:54:45 <_Lucretia_> I need the one inside poky/meta-mibtec/recipes-kernel/linux/linux-ti-psp-omap_2.6.37.bb Feb 18 11:54:58 <_Lucretia_> which line? first one? Feb 18 11:55:54 _Lucretia_: yes Feb 18 11:58:15 <_Lucretia_> same error Feb 18 11:58:28 <_Lucretia_> and when building core-image-sato it's using the wrong kernel Feb 18 11:59:04 <_Lucretia_> and giving: NOTE: preferred version 2.6.37 of linux-libc-headers not available (for item linux-libc-headers[-dev]) Feb 18 11:59:28 linux-libc-headers does not need to match up with the kernel version usually Feb 18 12:01:34 <_Lucretia_> ok, so how do i get it to use only the mibtec supplied kernel? Feb 18 12:06:12 _Lucretia_: you need to determine why it is building the other kernel Feb 18 12:06:32 _Lucretia_: the key may be in "This usually means one provides something the other doesn't and should." Feb 18 12:07:31 <_Lucretia_> I have no idea Feb 18 12:08:16 bitbake -g output may be useful; you could also compare bitbake -e | grep '^R*PROVIDES' for each kernel Feb 18 12:08:45 _Lucretia_: where have you set those PREFERRED_* values? Feb 18 12:09:30 <_Lucretia_> conf/local.conf Feb 18 12:10:33 have you checked that the value isn't being overridden using bitbake -e ? Feb 18 12:10:49 <_Lucretia_> not yet Feb 18 12:11:26 ok, I'd recommend doing that Feb 18 12:12:44 <_Lucretia_> yup, only PREFERRED_PROVIDER_virtual/kernel="linux-sakoman" Feb 18 12:14:19 <_Lucretia_> must be due to the sato image, might have to retry xfce image instead Feb 18 12:14:40 <_Lucretia_> nope, same Feb 18 13:23:31 _Lucretia_: it'll be your distro config setting the value with = Feb 18 13:23:38 or the machine config Feb 18 13:23:56 zecke: the systemd people want more details for your journald comments :) Feb 18 13:59:34 rburton: I sent an email to the systemd ml with an early analysis Feb 18 13:59:49 rburton: (and having fun with perf on OE-Core) Feb 18 13:59:57 zecke: ah, great. Feb 18 14:00:38 rburton: well, I think they will not care but then again it is the first work day Feb 18 14:01:34 Does anyone know why the current -dbg packaging style is the default? E.g. perf only searches for debug DSOs in /usr/lib/debug/ Feb 18 14:01:56 and somehow perf report on perf data from my device didn't really work... Feb 18 14:02:24 and RPs arm stack walking for userspace is broken.. or I was too stupid to enable the DEBUG_BUILD. :} Feb 18 16:45:16 hm, need a cunning way of making update-alternative configuration specific to a distro ... Feb 18 17:02:51 rburton: maybe I'm misunderstanding, but surely just a bbappend in the distro layer? Feb 18 17:06:29 <_Lucretia_> bitbake -c menuconfig virtual/kernel - doesn't do anything Feb 18 17:06:33 <_Lucretia_> any ideas? Feb 18 17:06:43 <_Lucretia_> it's saying it's running screen but nothing Feb 18 17:07:16 bluelightning: in oe-core Feb 18 17:07:23 specific to a distro feature Feb 18 17:07:28 should have finished my sentence Feb 18 17:09:18 _Lucretia_: presumably menuconfig is erroring out for some reason Feb 18 19:55:47 So here's a question - if I want to generate my base image (so kernel, bootloader and rootfs) - what's the best way to use Poky to generate ipk's against it so I can have installable packages? Feb 18 20:11:24 actually, that's a general how. I know it can be done, just haven't found docs to cover it Feb 18 21:01:04 khem: he, did your slides ever get posted from the YDD in Barcelona? Feb 18 21:02:56 Hi folks. I'm interested in generating a custom SDK that includes some additional libraries. I'm looking to customize the adt-installer recipe to pull my ADT's rootfs and kernel. Does that seem like a reasonable thing to do? Feb 18 21:03:33 I can set up a web site with the files for it to download, but there's all these adt-ipk files/directories that seem to need to be there too Feb 18 21:04:58 Alternatively I can use the stock ADT, let it download some SDK, then replace the rootfs/kernel with my own, but that doesn't seem like the right way to do it. Feb 18 21:20:08 Garibald1, you know about running bitbake -c populate_sdk Image-naem? Feb 18 21:22:03 sounds like I'm going down the wrong path :) Feb 18 21:22:48 does that work with the adt-installer, or will it make something independent? Feb 18 21:25:21 Crofton: or am I missing a document that explains this somewhere? Feb 18 21:25:39 darknighte: I think I sent it to Jefro Feb 18 21:26:44 khem: I asked Jefro and he didn't find it. At this point, it doesn't matter all that much since you are giving an updated version tomorrow. Feb 18 21:27:00 darknighte: hmm yes Feb 18 21:27:01 ok Feb 18 21:27:22 khem: however, as well received as your presentation was last time, I hope to be able to point people to it and planned to do so in my presentation on Wed. Feb 18 21:27:40 I'm seeing the same error as stated here http://www.mail-archive.com/meta-ti@yoctoproject.org/msg01332.html but I'm using poky and meta-ti from git, not danny so would've expected it to work. Any help appreciated! Feb 18 21:27:49 I would hope it works with adt Feb 18 21:28:22 darknighte: sure, I think I will send both versions to jefro Feb 18 21:28:39 the popuslate sdk task makes an sdk with libraries that match the image Feb 18 21:28:52 I am fighting with the output and some stuff I need to build atm Feb 18 21:29:08 darknighte and khem - they will be up later this afternoon Feb 18 21:29:10 No recipes available for: Feb 18 21:29:10 /media/scratch/latest/meta-ti/recipes-graphics/mesa/mesa-dri_9.0.1.bbappend Feb 18 21:29:30 Crofton: so the output is tmp/deploy/image/image-name-qemux86.tar.bz2? Feb 18 21:29:39 tmp/deploy/sdk Feb 18 21:29:45 that is the image Feb 18 21:29:55 ok, I'll take a look -- thanks Feb 18 21:30:03 * darknighte cheers for khem and jefro Feb 18 21:31:35 for a change kbuntu eats up less battery than win7 on corp laptop Feb 18 21:31:39 the sdk should work with adt, at least it would be a bug if it dosn't :) Feb 18 21:32:10 I guess its the ant-virus's extreme scanner :) Feb 18 21:32:29 I guess my question is, does the product of that command generate the entire sdk; would that mean the end-user wouldn't need to run the adt-installer? Feb 18 21:32:56 by "entire sdk" I mean the toolchain, the rootfs, and the kernel image Feb 18 21:32:58 Garibald1: if you are a cmdline guy then you would generate the SDK and install it Feb 18 21:33:07 and just source the env script and start using it Feb 18 21:33:09 sdk is just the toolchain and libs Feb 18 21:33:25 Crofton: its also qemu+tools Feb 18 21:33:25 ah that may be my missing link Feb 18 21:33:34 is there a good place for meta-ti questions/issues? Feb 18 21:33:47 meta-ti at yoctoproject dot org Feb 18 21:34:09 I cant stand this win7 let me reboot Feb 18 21:34:12 ok, so we're skipping the adt-installer all together. Download this, the rootfs, and the kernel image and just use them Feb 18 21:39:11 and the 'populate_sdk' command will generate an sdk for my arch, no? What if the end-user has a different arch? Feb 18 21:39:38 it seemd like the adt-installer worked that out on its own Feb 18 21:39:40 exosyst: there were 2 answers on meta-ti to that question Feb 18 21:40:49 denix, I saw that but I'm using meta-ti and poky from git which is what I was advised last time (June last year). If all work is now on Danny I'll happily change it up Feb 18 21:41:16 denix, Is it the case that the stuff from git HEAD doesn't always work then? Feb 18 21:42:46 I thought you were advised to use danny Feb 18 21:43:03 yes, there was recent update to mesa in oe-core... Feb 18 21:44:32 I can't find anything *official* on which to use. The meta-ti package just says it depends on openembedded core and where it's mirrored which isn't that helpful. Feb 18 21:45:02 I can use danny if that's going to work though. Should possibly be better supported right? RIGHT? Feb 18 21:45:43 danny is stable Feb 18 21:46:21 master is a moving target. if you are afraid of getting breakage from time to time, you should stay away from it Feb 18 21:47:31 denix, OK, I've changed branches... lets see how this goes... Feb 18 21:48:30 exosyst: http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/commit/?id=988829b7f61ed78ee6ce359c951ba156bc4b49db Feb 18 21:48:50 denix, lol - I just saw that Feb 18 21:49:10 I'll see how it goes with danny Feb 18 21:50:12 Is there a good way to get poky to generate ipk files for packages or should they all come from somewhere else? I noticed that I should add package-management to my IMAGE_FEATURES, but wondered how to instruct the building of the ipks themselves Feb 18 21:51:17 denix, Also - thanks for pushing that change :D Feb 18 21:51:17 exosyst: its in local.conf.sample Feb 18 21:51:28 you can select deb,rpm or ipk Feb 18 21:53:27 khem, I have that set but I wondered how the ipk generation happens. Feb 18 21:53:54 ok, here is my next populate_sdk question Feb 18 21:54:13 khem, For example, say I wanted to generate an ipk for httpd but not install it directly - rather make it available to other beaglebones with opkg. How do i go about doing that? Feb 18 21:54:45 the app I am trying to build uses python-cheetah, but only python (for x86 is installed), how do I make that python have cheetah? Feb 18 21:56:13 exosyst: you have to attend my talk tomorrow to learn more on that Feb 18 21:56:36 khem, Heh, I'm in Cambridge, UK. How far do I need to go? :) Feb 18 21:56:42 exosyst: but you need to setup feed server and also configure your devices to look at that server Feb 18 21:56:55 exosyst, SFO Feb 18 21:57:03 exosyst: not far just walk until San Franscisco :) Feb 18 21:57:26 khem, Well this will only be an example setup so I'll be making an an NFS export of the ipks and a local-feed.conf setup ideally. Feb 18 21:57:48 khem, Hmm... Google Maps says there's a fair bit of swimming for that :-) Feb 18 21:57:51 exosyst: you can setup a http server Feb 18 21:58:00 and then add it to opkg conf on target Feb 18 21:58:13 khem: you have a talk? Feb 18 21:58:21 ideally symlink your deploy/ipk folder in http server Feb 18 21:58:43 what's there to talk about? :) everyone knows everything already... Feb 18 21:58:44 and when you have new packages you would also update the package-index Feb 18 21:59:02 and provided device is setup correclty it will be able to see the updates Feb 18 21:59:03 khem, Yeah I can do the setup for opkg, I did it before for an Angstrom setup but I just want to be able to do something like: ./ipk-magic-creator-thing -o /opkgs/deploy/ -package httpd Feb 18 21:59:08 or something :D Feb 18 21:59:22 exosyst: there doesnt exist one step solution Feb 18 21:59:36 with rpm/zypper its a bit straight forward Feb 18 21:59:51 I just need to know how to get the ipks built, preferably using the yocto/poky stuff Feb 18 22:00:16 btw. zypper is gone with 1.4 we use smartpm Feb 18 22:00:51 denix: heh yes :) Feb 18 22:01:09 So is there a way to generate just the ipks for packages without them getting installed to the rootfs? Feb 18 22:01:10 no one would be using anything else if that was the case :) Feb 18 22:01:14 package_ipk.bbclass will answer most of your questions Feb 18 22:01:34 denix, ok, i'll take a looky thanks Feb 18 22:01:48 exosyst: installation to rootfs is needed for building dependent tasks Feb 18 22:01:54 but you should not worry about it Feb 18 22:02:06 all you need to care about is deploy/ipk dir Feb 18 22:02:17 and see that the ipks are populated there Feb 18 22:02:52 khem, So what I've done so far is add the things I want to IMAGE_FEATURES but that puts the package into the rootfs as I'd expect. So you're saying that it will also output to the deploy/ipk directory? Feb 18 22:03:38 yes Feb 18 22:04:21 ah right, so if i want an installable httpd.ipk, but don't want it installed by default to the rootfs, how is that done? Feb 18 22:04:36 khem, Man, i hope that talk makes it onto youtube :D Feb 18 22:04:54 if its recorded Feb 18 22:05:00 I dont know if thats the case though Feb 18 22:05:12 is there somewhere than I can read about the expected work flow for someone who wants to provide their own SDK? Feb 18 22:05:35 I'm trying to figure out how the pieces fit together Feb 18 22:05:48 Garibald1: you also need to attend my tomorrows talk on workflow Feb 18 22:05:51 :) Feb 18 22:06:14 at YPDay Feb 18 22:06:21 maybe I can have a peek at your slides sometime? Feb 18 22:06:38 I usually make bad slides Feb 18 22:06:54 but they should be up on yp site sometime Feb 18 22:07:18 will your talk be online somewhere? :) Feb 18 22:07:43 yeah that would be helpful :D Feb 18 22:08:02 And if there's a way to generate ipks without installing them - that'd be really great! Feb 18 22:08:06 khem: you talk too much :) Feb 18 22:08:16 lol yeah Feb 18 22:08:29 tomorrow you mean YPDD? Feb 18 22:08:33 yes Feb 18 22:09:03 unfortunately I'm missing it, will be there in the evening for ELC Feb 18 22:09:04 are you there ? Feb 18 22:09:09 oh Feb 18 22:09:23 I will be there at ELC too so you can banter Feb 18 22:09:26 right now I'm running -c populate_sdk, which is taking a while -- I assume it's not the intent for the end-user to run this? Feb 18 22:09:44 Garibald1: yes if you are the SDK provider Feb 18 22:09:47 you would want that Feb 18 22:10:02 I would want the end-user to run the -c populate_sdk? Feb 18 22:10:10 I dont think so Feb 18 22:10:13 it depends Feb 18 22:10:28 but I'm running it on x86_64, what if the end-user is on i686? Feb 18 22:10:30 if your workflow has a centrally installed SDK say exported over NFS to all devs Feb 18 22:10:34 FWIW, we (TI) have Yocto based SDK products for our platforms - I've been fighting some nasty issues with that lately Feb 18 22:10:43 or you hand over a SDK install on every dev machine Feb 18 22:10:48 I'll mention some of those during my talk @ ELC as well :_ Feb 18 22:10:51 :) Feb 18 22:11:13 denix: SDK works perfectly Feb 18 22:11:17 :) Feb 18 22:11:21 what do you miss Feb 18 22:11:27 yes, when it works :) Feb 18 22:11:34 khem: yeah, my users will be "external", I'm trying to package up something to make it easy for them to get started. Feb 18 22:11:40 ah pilot errors :) Feb 18 22:11:43 I don't miss anything :) Feb 18 22:11:55 I don't even know what arch their workstations will be Feb 18 22:12:08 Garibald1: OK in that case you need to hand them the SDK installer Feb 18 22:12:22 Garibald1: may be ADT or cmdline based Feb 18 22:12:22 Garibald1: target i686, won't miss it :) Feb 18 22:12:28 oh jeez Feb 18 22:13:03 Garibald1: basically you can choose SDK_MACHINE to be x86-64 and i586 and produce two SDKs Feb 18 22:13:14 it's SDKMACHINE Feb 18 22:13:15 So am I being dense - is it as simple as doing something like: bitbake httpd and that will generate just an ipk in deploy and not install it to the rootfs? Feb 18 22:13:18 so the adt-installer downloads stuff from adtrepo.yoctoproject.org, but I'd like to supply my own rootfs and kernel w/o having to download one from there and then throw it away Feb 18 22:13:31 exosyst: yes Feb 18 22:13:36 and if your customers use non-x86 for their dev machines then it will be a bit harder Feb 18 22:13:51 yeah, I'm not too worried there Feb 18 22:13:56 at least not initially Feb 18 22:14:01 khem: that would be an interesting use case... Feb 18 22:14:22 denix: yeah people might be using fedora on arm who knows :) Feb 18 22:14:28 SOAB. I guess I missed a trick. So basically I've just read http://hambedded.org/blog/2012/11/24/from-bitbake-hello-world-to-an-image/ and http://www.openembedded.org/wiki/Bitbake_cheat_sheet before that actually clicked. Bitbake understanding is paramount to this poky stuff :-/ Feb 18 22:14:34 so how is the product of -c populate_sdk different from what the adt-installer script installs? Feb 18 22:15:30 I thought of just bbappending the adt-installer recipe and separating the URL into two, one from which to get the kernel/rootfs and the other from which to get the toolchain packages Feb 18 22:16:03 then I could give them a custom location to get a custom rootfs/kernel and let them get everything else from adtrepo.yoctoproject.org Feb 18 22:16:04 well oyu need to set YOCTOADT_REPO Feb 18 22:16:11 to point to your feeds Feb 18 22:16:32 yeah, I did, but I don't want to have to mirror the adt-ipk directory Feb 18 22:17:04 that's why I thought about separating them into two URLs Feb 18 22:17:42 you want a mix ? Feb 18 22:17:52 bad idea though if at all possible Feb 18 22:18:40 Garibald1: well it seems you are really not interested in maintaining a SDK then Feb 18 22:18:44 but image feeds Feb 18 22:18:46 all I'm doing is adding some libs, wouldn't the stock toolchain be okay with that Feb 18 22:19:23 yeah, I guess you could look at it like that. I want a custom rootfs with additional libs. Feb 18 22:19:24 well you could mirror the adt repo and add your own libs on top Feb 18 22:19:39 and run a rsync or some sort for the updates Feb 18 22:20:38 if my libs are on the rootfs, that's sufficient, no? Feb 18 22:22:28 for example, I was able to use the adt-installer to get a stock rootfs/kernel/toolchain, then I swapped out the rootfs (via e359c951ba156bc4b49dband kernel with my own Feb 18 22:22:47 err, (via runqemu-extract-sdk) Feb 18 22:23:21 then I was able to build a project using 'make -e CC="${CC}" where that project depended on libs in the rootfs Feb 18 22:24:27 (sorry if I'm not making any sense) Feb 18 22:29:48 khem: so the project of the populate_sdk was poky-eglibc-x86_64-i586-toolchain..sh Does the x86_64-i586 mean "x86-64 binarys targeting an i586 machine" ? Feb 18 22:30:09 Garibald1: yes Feb 18 22:30:31 ok Feb 18 22:30:53 Garibald1: I think swapping rootfs could work ok but is one off env Feb 18 22:32:08 anyone understand sdk generation? I need to make sure it installs something in the native sdk Feb 18 22:32:39 I mean, if generating these scripts is the "right" way to do it, I'll do that. I'm just trying to understand why the toolchain cares about what's on the rootfs (other that matching it's arch) Feb 18 22:34:00 like, when the adt-installer gets a toolchain for, for instance santo-sdk, is that toolchain customized for sato-sdk? Feb 18 22:34:10 Garibald1: it does not understand anything Feb 18 22:34:19 it just needs a rootfs to point to Feb 18 22:34:40 but any bugs that may be found could not be easy to reproduce with standard install Feb 18 22:35:54 Crofton: add it to TOOLCHAIN_HOST_TASK Feb 18 22:38:16 khem: I think I'll just generate the scripts. That seems like the least error-prone way to go about it Feb 18 22:38:22 hmm Feb 18 22:38:29 Garibald1: yes Feb 18 22:38:32 in the image recipe? Feb 18 22:38:41 Garibald1: once you have a working set then you can experiment Feb 18 22:39:24 Crofton: yes Feb 18 22:39:28 cool Feb 18 22:39:46 I really like extracting the sdk from an image, and was worried this would break it :) Feb 18 22:40:04 RP, where are you now? Feb 18 22:40:19 Crofton: San Francisco, just arrived Feb 18 22:40:27 welcome to the left coast Feb 18 22:40:35 khem: you mentioned there was a way to build an i586 toolchain on x86_64, what was that again? Feb 18 22:40:35 I'm in Mountain View Feb 18 22:40:47 Crofton: thanks. Its too bright and my head hurts ;-) Feb 18 22:40:50 rofl Feb 18 22:41:00 Garibald1: SDKMACHINE? Feb 18 22:41:04 across the freeway from the computer history museum Feb 18 22:41:29 are you still in the airport? Feb 18 22:41:44 Crofton: look forward to seeing you at some point :). No, at the hotel now Feb 18 22:41:53 RP: ah, yes -- thanks Feb 18 22:42:07 ah, how is it? Feb 18 22:42:12 I arrive in the morning Feb 18 22:42:57 RP: is it possible to mix feeds for SDK via ADT at all ? Feb 18 22:43:05 Crofton: Seems ok. I wasn't paying much attention, just wanted somewhere to lie down Feb 18 22:43:21 khem: "mix" in what sense? Feb 18 22:43:23 RP: e.g. adding some extra packages to stock Feb 18 22:43:30 khem: sure Feb 18 22:43:36 which are not published in yocto's ADT repo Feb 18 22:43:49 khem: its like any standard package management Feb 18 22:44:15 yes saw that my question was more on the lines can I specify more than one feed source to it ? Feb 18 22:44:32 khem: its just using opkg so I don't see why not Feb 18 22:44:49 hmm ok Feb 18 22:45:16 at some point there was idea to change it to use sstate Feb 18 22:45:33 khem: hasn't happened as yet Feb 18 22:45:59 I don't have any more immediate ideas for pseudo performance improvements. I'm really interested in feedback on the existing set. Feb 18 22:46:15 I am not sure whether they'll affect other builds anywhere near as much as they affect mine. Feb 18 22:46:17 RP: someone reported different behavior with own-mirrors https?:// pattern and today I got couple of LIC_FILES_CHKSUM failures from 3 recipes which had files:// instead of file:// maybe it's related somehow? Feb 18 22:47:16 JaMa: I just merged the urlparser changes so its probably found some corner cases Feb 18 22:47:49 seebs: I'm looking forward to testing that but won't be this week or next :( Feb 18 22:47:56 Heh. Feb 18 22:47:57 (in my case at least) Feb 18 22:48:28 Well, my testing has been... not super conclusive. It looks like these are most noticeable on solidly disk-bound builds. If you have stunningly fast disks and few/slow cores, it's not as impressive. Feb 18 22:48:29 RP: ah right, for files:// it looks like improvement as the old one was typo (not sure if the checksum was correctly checked or not) Feb 18 22:48:38 If you have slow disks and lots of fast cores, it's quite noticeable. Feb 18 22:49:04 Big win is just that the catastrophic time explosions we'd see with full builds running while something else was running do_rootfs seem to be mostly gone. Feb 18 22:49:12 RP: but there is no straight forward mechanism to add extra feeds to adt installer as I see Feb 18 22:49:29 khem: patches welcome ;-) Feb 18 22:49:37 khem: it can't be hard... Feb 18 22:49:49 RP: yes I should do it Feb 18 22:50:24 using yocto internally has eaten up my community badwidth Feb 18 22:50:34 s/badwidth/bandwidth Feb 18 22:52:10 khem: I know the problem... Feb 18 22:52:25 khem: thanks again for your help, I think I have a better idea of how to do this now :) Feb 18 22:52:49 khem adding python-cheetah to TOOL_CHAIN_HOST_TASK will make it install nativesdk-python-cheetah? Feb 18 22:52:58 but I have no such package .. Feb 18 22:53:06 RP: I was happier dude when it was not used internally :) Feb 18 22:53:19 success is ahrd :) Feb 18 22:53:52 Crofton: succeeding is not hard. Remaining successful is hard :) Feb 18 22:53:59 even better Feb 18 22:54:27 one of my recent concerns is everyone is getting paying work Feb 18 22:54:51 so we need to work out how to expand the comunity to fuel the growth Feb 18 22:55:14 Crofton: yes, I think its happening slowly Feb 18 22:55:47 Crofton: I hope that events like YPDD will bring more people on Feb 18 22:56:21 Crofton: we need more people taking on more responsibility for sure.... Feb 18 22:56:59 it seems like people get sucked in to paying work and have less time for "community" work Feb 18 22:57:14 do we have a recipe for devmem2 Feb 18 22:57:37 apparently we do Feb 18 22:57:42 Crofton: The trouble is paying work needs to be given a certain priority, at least some of the time Feb 18 22:58:04 yeah Feb 18 22:58:29 Crofton: yes meta-oe has recipe for devmem2 Feb 18 22:59:17 yeah, it build Feb 18 22:59:31 guy in the other room needs to prod random addresses Feb 18 23:09:10 TOOLCHAIN_HOST_TASK += "python-cheetah" Feb 18 23:09:17 can't find python-cheetah Feb 18 23:10:20 I'm seeing a failure for building uboot with meta-ti on danny. make: *** No rule to make target `am335x_evm_config'. Stop. Feb 18 23:10:23 do I need to add nativesdk to the inherit list? Feb 18 23:10:45 That's an important one in my opinion... I needs my bootloader! Feb 18 23:10:51 is that a known bug? Feb 18 23:11:33 Crofton: likley yes Feb 18 23:11:46 RP, thanks Feb 18 23:12:00 Crofton: BBCLASSEXTEND = "nativesdk" Feb 18 23:23:16 denix, so I'm building from danny and it's failing to build uboot due to run.do_compile failing to get the right target and I checked through the sources and the config am335x_evm_config isn't present. Feb 18 23:23:28 denix, Can I bump/tweak it to get the right version of uboot? Feb 18 23:29:12 TOOLCHAIN_HOST_TASK += "python-cheetah", do I need to explicitly put nativesdk- in the package anem? Feb 18 23:32:16 Crofton: its probably better to Feb 18 23:41:26 serious multi-tasking today Feb 18 23:48:46 re Feb 18 23:49:07 hmm, and exosyst just left :( Feb 18 23:55:47 Crofton, RP: ha, tell me about paying work vs. community and priorities... :) let me know if you any easy solution to that problem! Feb 19 00:05:37 ah, he's back Feb 19 00:05:56 exosyst: what is the problem you have with uboot? Feb 19 00:06:17 hmm, strange network issues here Feb 19 00:06:46 make: *** No rule to make target `am335x_evm_config'. Stop. Feb 19 00:06:46 make: *** [am335x_evm_config] Error 1 Feb 19 00:07:13 The log file it asks me to refer to, log.do_compile.16367, says the same Feb 19 00:07:55 I did a find from within the source and it is indeed missing the config. I wonder if a patch didn't apply? Feb 19 00:07:57 which u-boot version is that? Feb 19 00:08:21 1 task failed /media/scratch/latest/poky/meta/recipes-bsp/u-boot/u-boot_2011.06.bb, Feb 19 00:08:32 oh, the version was u-boot-v2011.06+git3+b1af6f532e0d348b153d5c148369229d24af361a-r3 Feb 19 00:13:53 I don't know why you are building 2011.06 - that one is too old for am335x and since it pulls from upstream, there was no am335x support back then Feb 19 00:14:22 Indeed, I'm using the danny branch for both poky and meta-ti though... You got a hitlist of things to check? Feb 19 00:14:23 exosyst: 2011.09 is the earliest version with am335x support and it was pulling from our staging tree Feb 19 00:15:32 exosyst: either way, 2011.06 is not even marked as compatible with am335x Feb 19 00:16:02 denix, Very odd - so what do I do and is this something that others might be having too? Feb 19 00:19:27 denix, See - I can't do anything right tonight. Can I force a different version in the local.conf? Feb 19 00:20:06 PREFERRED_PROVIDER_u-boot? Feb 19 00:21:59 exosyst: here's what we set for our own distro/product - http://arago-project.org/git/?p=meta-arago.git;a=blob;f=meta-arago-distro/conf/distro/arago.conf;hb=HEAD#l54 Feb 19 00:22:36 denix, Oh OK, surely this is a bug in the reference distro though? Feb 19 00:23:28 I imagine it's skipped and not reported due to a version of uboot being on the SD card already Feb 19 00:24:17 denix, do I want preferred_version rather than preferred_provider set? Feb 19 00:25:59 or is it even the case that core-image-minimal is incorrect for the beaglebone and it should be bitbake -k something-arago-something? Feb 19 00:31:23 denix, NOTE: versions of u-boot available: 2011.09+git 2011.09-psp04.06.00.08 git v2011.03+git11+19b54a701811220221fc4d5089a2bb18892018ca v2011.06+git10+b1af6f532e0d348b153d5c148369229d24af361a v2012.04.01+git9+415d386877df49eb051b85ef74fa59a16dc17c7d Feb 19 00:35:19 Gonna grab u-boot-2011.09+git-r30 and see how I get on, otherwise I'll have to just flag it up as a bug (somewhere?) and build it out of env Feb 19 00:39:53 exosyst: correct, PREFERRED_VERSION is what you need for u-boot, my bad - too much multitasking Feb 19 00:40:34 denix, I guessed as much - PREFERRED_VERSION_u-boot = "2011.09+git", and that happily worked. Feb 19 00:40:49 exosyst: you can select one you need in local.conf - there are several versions available for am335x Feb 19 00:41:15 yeah, I pasted above what the choices it gave me were. It didn't let me pick the 2012 version you suggested Feb 19 00:41:22 we currently use 2012.10 Feb 19 00:41:24 I guess there's something config'd wrong in the layers Feb 19 00:41:46 denix, Yeah, the choices maxed out at 2011.09 Feb 19 00:42:24 exosyst: ah, sorry that one is still in meta-arago and not meta-ti - it was being tested and not promoted to be stable yet Feb 19 00:42:40 denix, No worries. So should I file the uboot bug somewhere? Feb 19 00:42:45 denix: yocto all things! Feb 19 00:43:03 denix: fly out tomorrow? Feb 19 00:43:28 exosyst: u-boot-2012.10 should be moved from meta-arago to meta-ti at this time, it was part of the recent release Feb 19 00:43:35 mranostay: yep Feb 19 00:43:40 especially as you mentioned (or maybe it was khem?) that danny is the preffered branch with no^W less breakages :D Feb 19 00:44:00 exosyst: correct :) Feb 19 00:44:32 arg, cheetah is in the sdk, but the compiler vanished Feb 19 00:44:34 wtf Feb 19 00:44:39 cool - so where do I file :D Feb 19 00:45:32 if you've got time to help me through it, I'd be happy to get a fix sorted. Feb 19 00:47:16 TOOLCHAIN_HOST_TASK += "nativesdk-python-cheetah" Feb 19 00:47:28 I bet that leads to not setting it to the bits I also need Feb 19 00:51:29 heh, gotta love use of ?= in recipe context with += in cconfig context Feb 19 00:53:56 yeah Feb 19 00:54:19 it is set with ?= and I am afriad the += makes the ?= go way Feb 19 00:54:37 yeah, my lack of precision in understanding the details is horrifying :) Feb 19 00:58:16 Crofton: when you head up to SF? Feb 19 00:58:17 what is the right way to extend things in this situation? Feb 19 01:00:45 Crofton: hmm what is += appending to then? :P Feb 19 01:01:03 not sure Feb 19 01:32:08 hacked around and got cheetah in the sdk, but it want to import sgi Feb 19 01:38:20 is it possible to change a INITSCRIPT_PARAMS inside a .bbappend recipe? **** ENDING LOGGING AT Tue Feb 19 02:59:58 2013