**** BEGIN LOGGING AT Wed Feb 22 02:59:59 2012 Feb 22 06:51:21 morning. can I add users to my image compile-time? Feb 22 07:06:59 tasslehoffwrk: u r working on which OE classic or core? Feb 22 07:13:38 Noor: classic Feb 22 07:14:15 my core image is almost ready, but not early enough to be used for our first release Feb 22 07:14:37 tasslehoffwrk: then I am afraid you cant do it .... thats my thinking .... I have beginners exp in OE more experience ppl can comment on it as well Feb 22 07:23:00 Noor: ok. thanks :) Feb 22 07:24:32 tasslehoffwrk: in oe-core there is a class useradd ... u can loo into that if u want Feb 22 07:24:38 look Feb 22 07:25:01 Noor: that's the one I've seen discussed here, and the reason I asked Feb 22 07:25:07 :) Feb 22 08:26:42 good morning Feb 22 10:11:20 i am having issue compiling ti dsplink and lpm and all those friends as it always does errors regarding wrong vfp settings between the modules Feb 22 10:48:25 morning Feb 22 10:50:15 tasslehoffwrk: useradd shouldn't be too hard to port to oe classic Feb 22 10:50:28 tasslehoffwrk: ahh, forget ... Feb 22 10:50:44 tasslehoffwrk: it uses sstage methods ... Feb 22 10:50:55 tasslehoffwrk: i do believe it won't be trivial Feb 22 11:37:35 I ma orking on oe-core and bit confused on do deply function Feb 22 11:38:31 I can see u-boot is being deployed in DEPLOYDIR but I am not able to understand how it does to DEPLPY_DIR_IMAGE folder Feb 22 11:38:39 can somebosy give me a pointer Feb 22 11:39:14 somebody Feb 22 11:40:59 * Noor typing is getting worse day by day Feb 22 11:48:34 Noor: does bitbake -e u-boot | grep DEPLOY_DIR_IMAGE help? Feb 22 11:48:56 * bluelightning -> office, back in 1hr Feb 22 12:09:10 Trying to build cpufrequtils with openembedded I recieve this error: http://pastebin.com/1NSdi5Ym Feb 22 12:09:34 could anyone shed any light on what the issue is, it seems to be missing 'install' but other pakges seem to use it without issue... Feb 22 12:11:43 jackmitch do you use oe-classic or oe-core? Feb 22 12:11:52 oe-core Feb 22 12:13:32 are you sure? Feb 22 12:13:34 tmp-angstrom_2010_x-eglibc Feb 22 12:14:13 besides that check of /usr/bin/install is there Feb 22 12:14:23 I think so, I am trying to build for the beaglebone and have followed the instructions here: http://www.angstrom-distribution.org/building-angstrom Feb 22 12:14:26 and check if the tools /usr/bin/install uses are there Feb 22 12:14:51 what branch of setup-srcipts did you check out? Feb 22 12:15:00 master I would imagine Feb 22 12:15:19 yes, master Feb 22 12:17:23 To be honest all I want to do is re-compile my beaglebones kernel to enable SPI, but the meta-ti layer can't be used with anything other than angstrom and you have to rebuild the whole distribution. Bit of a nightmare to be honest. Feb 22 12:18:27 I tried doing it through the way I know by using the layers and sourcing the oe script, but it failed so I thought it would be easy to use the 'pre-configured' script that it told me to use but alas... not very easy. Feb 22 12:19:04 https://github.com/Angstrom-distribution/meta-ti Feb 22 12:19:52 no Feb 22 12:20:13 bitbake -c menuconfig virtual/kernel Feb 22 12:20:25 or bitbake -c menuconfig linux Feb 22 12:20:38 bitbake -c devshell foo and copy your config out Feb 22 12:20:51 but I would have to do that after I had used the angstrom script yes? Feb 22 12:21:20 than dont use the script Feb 22 12:21:29 its in the docs how to do it Feb 22 12:22:15 I must be beign daft, which documents are you refering to, I feel like i've been going in circles all morning! Feb 22 12:23:13 http://www.angstrom-distribution.org/building-angstrom Feb 22 12:23:21 MACHINE=beagleboard ./oebb.sh bitbake virtual/kernel Feb 22 12:23:41 to hard to find? Feb 22 12:24:11 ah right ok, yes but I thought if I was bulding master then the if I built the kernel alone it wouldn't be compatible with my current 'demo image' userland? Feb 22 12:24:27 its the same source Feb 22 12:24:39 maybee some newer patches Feb 22 12:24:39 so I would build the latest 'generic' angstrom and then rebuild the kernel to my spec afterwards Feb 22 12:24:43 look the recipe Feb 22 12:24:59 you mean you are building toolchain Feb 22 12:25:33 angstroem are the ipk's for the target which falls out in the end Feb 22 12:25:53 In my head I would build the latest angstrom distro, then load my beaglebone, then I would add a to the kernel recipe to give me the functionallity I required, then rebuild Feb 22 12:26:07 add a patch* Feb 22 12:26:29 again for kernel you only need gcc-cross in the end Feb 22 12:26:41 nothig more Feb 22 12:27:02 ok, right i'll try just building the kernel but then what happens Feb 22 12:28:04 OR Feb 22 12:28:16 you download sdk from narcissus and following this Feb 22 12:28:24 http://bec-systems.com/site/521/best-practices-for-kernel-development-with-openembedded Feb 22 12:31:24 ok, i'll have a read thanks - I have been using Yocto recently and the development cycle seems a lot less convoluted but I don't know if that is due to Texas Instruments or the Angstrom disto, but I suppose with them depending on each other it makes no difference.. Feb 22 12:32:17 o,O Feb 22 12:32:42 angstroem and yocto editing recipes and running bitbake is all the same Feb 22 12:32:57 both using oe Feb 22 12:33:35 indeed, but Yocto seems to be more barebones without the need for a complicated wrapper script Feb 22 12:34:22 *sigh* Feb 22 12:34:31 I tried pulling the layers down seperatly with bitbake, set the machine to beaglebone as in the meta-ti layers conf and ti bottled out within the first 5 minutes Feb 22 12:35:01 you cannt pull the layers with bitbake Feb 22 12:35:14 ok my mis-wording, I pulled them in with git Feb 22 12:35:50 so I cloned openembedded-core, then in that i cloned bitbake, meta-ti and the other layers it required Feb 22 12:35:59 sourced the oe-script so setup the buld environment Feb 22 12:36:04 did you read the readme? Feb 22 12:36:05 https://github.com/Angstrom-distribution/meta-ti Feb 22 12:36:13 This layer depends on: Feb 22 12:36:58 yes, I pulled in all the required layers and it still failed, which I why I turned to the script Feb 22 12:39:32 yes Feb 22 12:41:28 and you run MACHINE=beaglebone ./oebb.sh bitbake virtual/kernel Feb 22 12:41:34 nor? Feb 22 12:43:00 when I cloned the layers manually I changed the MACHINE variable to beaglebone and tried to build the systemd-image which failed, just now I used the script and it sucessfully built the kernel Feb 22 12:43:35 so now I'll add a new SRC_URI to to the kernel .bb file which my patch and it should build Feb 22 12:52:03 exactly Feb 22 12:52:13 dont forgot to update the defconfig Feb 22 12:52:25 if you change something on the config Feb 22 12:52:33 and maybee alter the revision Feb 22 12:52:48 so you are sure you not interfere with official packages Feb 22 13:08:54 Noor: did you figure it out? Feb 22 13:09:07 bluelightning: yeah Feb 22 13:09:21 sstate is doign the trick Feb 22 13:10:08 bluelightning: it happend by seeting SSTATETASKS += "do_deploy" do_deploy[sstate-name] = "deploy" do_deploy[sstate-inputdirs] = "${DEPLOYDIR}" do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}" in deply.bbclass Feb 22 13:10:43 I thought that was just telling sstate to monitor that directory for files... Feb 22 13:11:16 if we remove these lines files are not outputed to deploy/images folder Feb 22 13:12:19 bluelightning: i set do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}" with do_deploy[sstate-outputdirs] = ~/ttteee and images where created in ~/tttee when do_deploy function was executed Feb 22 13:12:29 sstate is still mistry for me :D Feb 22 13:12:30 ah ok, interesting Feb 22 13:12:36 need to get hold of it Feb 22 13:13:12 and it pick the images from do_deploy[sstate-inputdirs] = "${DEPLOYDIR}" Feb 22 13:19:50 I'm trying to make a rootfs image, right now only with twt, and I'm trying to get glxgears to run as a demo. I have task-xserver, xf86-video-omapfb, mesa-demos, xterm, twt and xinit added to IMAGE_INSTALL, but when I try to do glxinfo I get: Error: couldn't find RGB GLX visual or fbconfig. Any idea why this is? Feb 22 13:30:51 yeah, seems like I just had to add mesa-xlib instead of mesa-dri Feb 22 15:17:56 Noor, bluelightning: the deploy tasks outputs to DEPLOYDIR. without those flags, it won't take the DEPLOYDIR files and send them to DEPLOY_DIR_IMAGE Feb 22 15:18:30 kergoth: yeah thats what I figure it out Feb 22 15:18:45 * kergoth nods Feb 22 15:19:02 in classic it was much simpler :) Feb 22 15:19:36 in classic the cached binaries implementation was recipe wide, not task level Feb 22 15:19:39 which is part of it Feb 22 15:22:06 * Noor really needs to understand the sstate code and how sstate is being saved Feb 22 15:22:09 yeah Feb 22 15:23:24 kergoth that means if you add your own task then you need to tell sstate to add it Feb 22 15:24:16 if you want to use sstate with it, yes. that's not always the case. for example, for the source archival stuff, we'll likely want to exclude it from sstate entirely if we can, as it doesn't make sense to re-archive DL_DIR files into more archives :) Feb 22 15:26:35 hhhhmmmm Feb 22 15:27:09 but if we have to add it in sstate we need to do some more work or it will be automatically added ... that was my question Feb 22 15:28:33 I'm not sure what you mean by automatically added. To a certain extent it depends on where the task fits into the task graph, since afaik sstate assumes that tasks that an sstate task depends upon have been satisfied once that sstate is used Feb 22 15:29:44 hhhmmm Feb 22 16:27:09 khem: ping Feb 22 16:40:43 hi Feb 22 16:41:04 please I need suggestions for a simple https server for cortex-m3 + gcc :) tx Feb 22 16:45:04 Mazingaro you could try http://www.fefe.de/gatling/ Feb 22 16:45:30 thanks Feb 22 16:45:49 or http://www.cherokee-project.com/doc/cookbook_https_accelerator.html Feb 22 16:45:56 and update the cherokee recpie Feb 22 16:45:57 ;) Feb 22 16:46:19 I'm running on a baremetal system, no os on it Feb 22 16:59:11 msm: pong Feb 22 17:03:37 khem: can you give me a few bits of detail on the gcc version strategy Feb 22 17:03:45 my gcc appears to report as 4.6.3 Feb 22 17:04:00 then, the subversion revision we are using does not align with upstream 4.6.2 release Feb 22 17:04:07 and 4.6.3 is unreleased at this point? Feb 22 17:04:48 msm: yes dont be encumbered with release numbers Feb 22 17:05:10 FWIW gcc only major releases matter Feb 22 17:05:19 khem: OK Feb 22 17:05:22 .x.x.x releases are bug fix releases Feb 22 17:05:31 so basically no new features nothing Feb 22 17:05:33 im just trying to get internal patches posted upstream Feb 22 17:05:41 and i want to make sure they should apply or if things are appropriate Feb 22 17:05:41 4.6.2 is 4.6.1+bug fixes Feb 22 17:06:05 i just noticed powerpc-gcc -v reports 4.6.3 as well? Feb 22 17:06:20 yes once 4.6.2 is released that version bumps Feb 22 17:06:49 so we are not top of 4.6 branch but we are some patches behing Feb 22 17:06:54 khem: OK - that's sort of confusing for end users sometimes (esp. ones that want to know exactly which gcc version) Feb 22 17:06:56 we track the branch not the releases Feb 22 17:07:08 khem: makes sense from the oe-core side Feb 22 17:07:20 ill have to explain this properly... Feb 22 17:07:35 I think the nature of packages matter Feb 22 17:07:49 some packages change features between minor releases Feb 22 17:07:52 but gcc does not Feb 22 17:08:09 khem: ok - so i want to submit internal toolchain patches (ones that might never be really accepted upstream) Feb 22 17:08:14 khem: just for powerpc32/64 though Feb 22 17:08:14 Its easy to maintain if we track the branch Feb 22 17:08:29 and these are tested internally to some degree Feb 22 17:08:37 ok Feb 22 17:08:40 so - is there any caveat with doing something like that? Feb 22 17:08:43 here is testing reference Feb 22 17:09:02 http://sakrah.dontexist.org/files/gcc-tests/ Feb 22 17:09:24 so if your tests dont regress they should be fine Feb 22 17:09:28 err patches Feb 22 17:09:56 from lame user pov you should mention we are at 4.6.2+patches state Feb 22 17:10:03 who care about numbers Feb 22 17:10:15 since its really like that Feb 22 17:10:47 where we get the cumulative patches from svn instead of adding them individually to SRC_URI Feb 22 17:10:50 makes sense ? Feb 22 17:11:02 khem: yep - you answered everything Feb 22 17:11:20 khem: getting gcc to say 4.6.2+ instead of 4.6.3 might be nice - but not something im doing to try to change =) Feb 22 17:13:17 yes I thought about that. Feb 22 17:13:31 since it needed a living patch I slacked Feb 22 17:13:52 but if it makes air cleaner I can think of it Feb 22 17:14:25 but only after 4.6.3 is released since I dont want to go back in order Feb 22 17:14:59 gcc names some dirs with that number in installation dir Feb 22 17:24:35 khem: right, i saw that… it would'nt be fun - and little benefit Feb 22 17:58:35 Has anyone experienced problems with 'reboot' command and systemd? I can only reboot using 'reboot -f' at the moment. Feb 22 18:00:41 ahoy Feb 22 18:03:09 ERROR: QA Issue with gkrellm: Architecture did not match Feb 22 18:03:30 is there a work-around for this? Feb 22 18:04:22 it builds fine, but then errors out in do_package Feb 22 18:05:02 mr_science: sounds like executables being compiled for the host instead of the target maybe? Feb 22 18:08:13 yeah, but why? Feb 22 18:08:52 pretty much everything else built fine Feb 22 18:09:00 more or less... Feb 22 18:11:23 i'll try it from a clean tmp and see what happens, but other than that I got nothin' Feb 22 18:13:17 why? hard to say without looking at the way gkrellm builds itself Feb 22 18:30:54 bluelightning, mostly because the ordering of build images/provides seems to trigger different dependency resolution Feb 22 18:31:53 for example, if i go straight for our TI image build from a clean tmp, python-native will fail Feb 22 18:32:20 and then it builds fine if i run the same command again Feb 22 18:32:53 wheras if i build the rescue-image first (a very minimal image) then python-native doesn't fail Feb 22 18:36:08 mr_science: so there's a missing dependency somewhere Feb 22 18:36:13 mr_science: what's the failure? Feb 22 19:45:09 bluelightning, i'll have to run that one again, but i just built gkrellm with our previous TI build version and it built fine Feb 22 19:45:36 also on a different build host tho... Feb 22 20:42:24 hm Feb 22 20:44:10 in recipes, are DEPS build time or run time dependencies? I'm trying to get package P to enable support for feature F, and dependency D enables that. I have D listed as a dependency, but when package P goes to configure itself it says it can't find D and therefore won't include feature F. Feb 22 21:32:18 tzanger, the only thing i can think of is the STAGING_LIBS thing, but it also seems like you shouldn't have to do that... Feb 22 21:32:57 you RDEPENDS Feb 22 21:33:10 DEPENDS are for building RDEPENDS are for runtimes Feb 22 21:35:10 woglinde: hm, that is what I thought... ok. DEPENDS = "D" is there. does rm_work screw things up if it is in D's recipe? Feb 22 21:35:48 ? Feb 22 21:36:03 rm_works deletes the unpackaged source dir Feb 22 21:36:13 and the tmp packages building dirs Feb 22 21:53:58 strange. the only thing I can think of is that the dependency doesn't have the .h file in FILES_${PN} and it's not sticking around for the package that needs to see it Feb 22 21:54:19 this is for asterisk and libpri, don't mean to act mysterious, just trying ot state the problem plainly Feb 22 21:54:38 tzanger: most probably the files are not packaged correctly Feb 22 21:54:52 what do you have in packages-split/ Feb 22 21:55:55 asterisk DEPENDS on libpri right ? Feb 22 21:56:17 khem: yes, asterisk DEPENDS contains libpri (and openssl and a bunch of other things that are getting found correctly) Feb 22 21:56:29 forgive me... what is packages-split/? Feb 22 21:56:32 so which one is missing ? Feb 22 21:56:43 tzanger you working on meta-telephony? Feb 22 21:56:57 woglinde: no, that's not me Feb 22 21:57:05 khem: libpri doesn't get found Feb 22 21:57:10 ok. Feb 22 21:57:36 tzanger than not double the work Feb 22 22:00:05 hm I asked zecke where he put meta-telephony Feb 22 22:05:12 tzanger -> https://gitorious.org/sysmocom-openembedded/meta-telephony/commits/master Feb 22 22:11:38 woglinde: checking it out, thank you Feb 22 22:11:59 woglinde: gitorious does not work well with bitbake in non interactive mode Feb 22 22:12:01 although I think I may have found the issue... depending on libpri-dev instead of libpri, since the .h is there Feb 22 22:12:13 It was a pain to get efikamx kernel Feb 22 22:12:36 khem I wonder why you need bitbake Feb 22 22:12:39 just use git Feb 22 22:12:47 tzanger: well if you have libpri in DEPENDS then libpri-dev will get staged automatically Feb 22 22:12:55 in which case it should have found the header Feb 22 22:13:12 woglinde: since I dont have buttbake :) Feb 22 22:19:11 khem: hmm ok Feb 22 22:24:43 kenws: http://video.linux.com/categories/2012-embedded-linux-conference Feb 22 22:25:59 bluelightning, ping Feb 22 22:26:05 hi Crofton|work Feb 22 22:26:18 hey, I am getting my oe-core build up again Feb 22 22:26:26 ah, great :) Feb 22 22:26:29 are your qt patches somewhere I can pull them? Feb 22 22:26:30 I should be able to see the header files in the staging dir shouldn't I? Feb 22 22:26:56 Crofton|work: sure, one sec Feb 22 22:27:34 Crofton|work: http://cgit.openembedded.org/openembedded-core-contrib/log/?h=paule/qmake-target Feb 22 22:27:47 Crofton|work: you'll probably want to rebase on top of current master though Feb 22 22:28:09 yeah Feb 22 22:31:55 khem: watching your talk now btw :) Feb 22 22:32:58 bluelightning: it was second last talk and immediately after lunch. not best time to grab attention Feb 22 22:33:26 khem: seems pretty good so far :) you mentioned a few small things about OE-classic I left out Feb 22 22:33:45 actually I don't think I spent a lot of time talking about classic Feb 22 22:34:05 bluelightning: yeah we have to get people past the hump :) Feb 22 22:34:20 bluelightning: one thing that people did point out is documentation Feb 22 22:34:27 which is not helping so much in migration Feb 22 22:34:34 yeah :/ Feb 22 22:34:49 maybe I will get time to do another piece this week Feb 22 22:36:39 yes. I plan to go through wiki myself as well. Feb 22 22:37:01 only once I go past through these horrendous reviews at work Feb 22 22:43:08 ahh, for some reason libpri is being built for x86-64 (the host) instead of teh target Feb 22 22:43:28 good nite Feb 22 22:52:52 tzanger: are you using oe.classic ? Feb 22 22:53:26 tzanger: I think the host one should be libpri-native which should be coming from another dependency Feb 22 22:53:42 I have no idea if it's classic or new coke. it's just a standard angstrom build that we've been slwoly adding to Feb 22 22:57:49 I think we had a problem like this in another library Feb 22 22:58:35 had to add TARGET_CC_ARCH += " ${LDFLAGS} " Feb 22 22:59:33 why is that a problem Feb 22 23:00:08 it's not, I just dont' understand why I had to add it Feb 22 23:00:15 is it something configure automatically does? Feb 22 23:00:20 no Feb 22 23:00:48 it just adds the hash related flags that this packages build system does not respect otherwise through normal LDFLAGS settings Feb 22 23:01:22 otavio: any progress wrt udev unification? Feb 22 23:45:13 ant__: partially Feb 22 23:45:19 ant__: want to try it? Feb 22 23:45:51 to be honest is because I'd like to get rid of one .bbappend to udev in meta-oe Feb 23 00:12:10 kergoth: how would I shared the B between two recipes Feb 23 00:12:19 kergoth: is there existing provisions ? Feb 23 00:13:04 khem: for S, there's the shared worktree stuff that richard put in, for B, no clue, probably nothign in place Feb 23 00:13:07 one way I can think of is copy the whole built tree into somewhere in staging Feb 23 00:15:25 ant__: I am also working on it with that goal Feb 23 00:17:26 * khem like OEBasichash Feb 23 00:18:53 koen: ping Feb 23 00:29:40 bitbake -e is returning wrongly as it was interrupted Feb 23 00:31:05 ohhh fixed in master Feb 23 00:31:08 got it now Feb 23 01:01:27 Crofton|work: let me know how you get on with the qt patches Feb 23 01:01:32 * bluelightning is off to bed, nite all Feb 23 01:45:05 bitbake is failing now with Feb 23 01:45:05 DEBUG: while parsing sstate_installpkg, in call of bb.build.exec_func, argument 'preinst' is not a string literal Feb 23 01:45:09 DEBUG: while parsing do_clean, in call of bb.build.exec_func, argument 'f' is not a string literal Feb 23 01:45:12 ERROR: Command execution failed: Exited with 1 Feb 23 01:45:12 any idea why? Feb 23 01:47:31 I am trying to trace it with no success Feb 23 02:07:03 otavio: same error here, the error message doesn't give much away Feb 23 02:07:24 icanicant: at least i am not the only one Feb 23 02:08:35 just lost a couple of hours debugging an error in meta-handheld after updating, only to find it was fixed an hour ago. should have stayed away from bleeding edge :D Feb 23 02:11:24 icanicant: heh Feb 23 02:11:28 icanicant: normal Feb 23 02:23:35 icanicant: did you figure which recipe raises the error? Feb 23 02:31:21 otavio: it's the first time i've delved into the bitbake sources. looks like it's just executing 'rm_work_all' commands. think i'll leave it for the morning, 2.30am here now. **** ENDING LOGGING AT Thu Feb 23 02:59:58 2012