**** BEGIN LOGGING AT Thu Jan 26 02:59:57 2012
**** ENDING LOGGING AT Thu Jan 26 03:37:48 2012

**** BEGIN LOGGING AT Thu Jan 26 03:55:12 2012
Jan 26 07:43:33 <rafayocto> hi
Jan 26 07:43:41 <rafayocto> i have a problem in yocto
Jan 26 07:43:51 <rafayocto> can any one assist me please
Jan 26 07:43:52 <rafayocto> ?
Jan 26 07:45:16 <rafayocto> i am trying to run
Jan 26 07:45:28 <rafayocto> bitbake meta-ide-support
Jan 26 07:45:42 <rafayocto> and keep getting stuck at stage 15
Jan 26 07:45:49 <rafayocto> NOTE: Running task 15 of 63 (ID: 60, /home/user/yocto-project/poky-edison-6.0/meta/recipes-devtools/m4/m4-native_1.4.16.bb, do_fetch) NOTE: package m4-native-1.4.16-r0: task do_fetch: Started
Jan 26 07:45:50 <rafayocto> code:
Jan 26 07:52:17 <rafayocto> hi Jama
Jan 26 07:53:06 <JaMa> hi
Jan 26 07:54:13 <rafayocto> can you hel e?
Jan 26 07:54:16 <rafayocto> *help
Jan 26 08:00:49 <rafayocto> there are like 50 people in this channel
Jan 26 08:00:56 <rafayocto> no one offers any help
Jan 26 08:01:00 <rafayocto> great
Jan 26 08:01:22 <seebs> dunno where you are; here, it's about 2 AM and I was on my way to bed.  :)
Jan 26 08:01:56 <rafayocto> here its about 10AM
Jan 26 08:06:35 <rafayocto> bye
Jan 26 08:27:31 <mrAlmond> Hi guys
Jan 26 08:28:09 <mrAlmond> Does a recipe for wvdial exist in yocto?
Jan 26 08:53:35 <bluelightning> mrAlmond: there's one in OE-Classic you could port
Jan 26 08:56:14 <bluelightning> http://git.openembedded.org/openembedded/tree/recipes/wvdial
Jan 26 08:58:22 <mrAlmond> thank you guys...in the meantime I wa looking at ofono...do you think that it's better than wvdial to handle a 3G USB device?
Jan 26 09:02:01 <bluelightning> mrAlmond: I would say yes, a fair amount of work has gone into ofono to support 3g modems
Jan 26 09:02:54 <bluelightning> we've had some people on the yocto team doing 3g modem testing with ofono as well, so it should work pretty well
Jan 26 09:03:10 * bluelightning -> office, brb
Jan 26 09:06:16 <mrAlmond> Ok...I'm compiling it, thank you bluelightning !
Jan 26 10:22:28 <ag> Hello everybody.
Jan 26 10:22:33 <ag> ANybody around?
Jan 26 10:49:05 <ag> Still nobody here?
Jan 26 10:53:11 <abustany`> ag: I would say the rule is "don't ask to ask, just ask" :)
Jan 26 10:54:48 <ag> Thank you.
Jan 26 10:55:46 <ag> Well. I want to understand this part of bzip2: PROVIDES_append_virtclass-native = " bzip2-full-native"
Jan 26 10:56:09 <jekhor> Hi. Can new board configurations be approved to meta-yocto inclusion?
Jan 26 10:56:15 <ag> This is because i got into a strange behavior on a x64 machine.
Jan 26 10:56:36 <ag> gcc fails because some bzip arhives are empty.
Jan 26 10:57:00 <ag> Well, this -full- thing, what is it used for? Why isn't -native as all the other?
Jan 26 10:57:49 <ag> the only dependency for this is in quilt.
Jan 26 10:58:08 <ag> Is anybody able to explain me why?
Jan 26 11:05:04 <ant_work> ag: seems coming from old days
Jan 26 11:05:06 <ant_work> http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=e419523cbf54ee3d3d05325ad9ab5d09c52e8308
Jan 26 11:05:32 <ag> I know.
Jan 26 11:05:41 <ag> I thought it was something that was still functional
Jan 26 11:05:44 <ag> i will commit the change
Jan 26 11:05:47 <ant_work> is still in oe-classic
Jan 26 11:05:52 <ag> Thank you ant_work
Jan 26 11:05:56 <ant_work> yw
Jan 26 11:06:39 <ag> @jenkor You could ask this in mailing list.
Jan 26 11:17:45 <bluelightning> jekhor: we tend to have just one reference board per architecture in meta-yocto
Jan 26 11:18:28 <bluelightning> jekhor: otherwise we would encourage you to create another BSP layer for the device
Jan 26 11:22:33 <jekhor> bluelightning, OK, thanks
Jan 26 11:23:12 <bluelightning> jekhor: what board are you looking to support, if you don't mind me asking?
Jan 26 11:25:41 <ag> Intel Midfield :)
Jan 26 11:27:54 <jekhor> bluelightning, p2020rdb
Jan 26 11:28:05 <jekhor> freescale, powerpc
Jan 26 11:28:33 <ag> p2020rdb.conf
Jan 26 11:28:43 <ag> This is already done in a meta layer.
Jan 26 11:28:56 <ag> Wait a sec to give you the git link.
Jan 26 11:29:18 <ag> git://git.yoctoproject.org/meta-fsl-ppc
Jan 26 11:29:22 <jekhor> there is separated meta-fsl layer, yes
Jan 26 11:29:51 <ag> Indeed. You can add this layer to your build.
Jan 26 11:30:38 <ag> I'm not sure why would you like to include this in meta-yocto.
Jan 26 11:32:06 <jekhor> Our customer something wants strange things :)
Jan 26 11:32:47 <ag> :) Goo done.
Jan 26 11:32:49 <ag> good
Jan 26 11:34:11 <ag> Your customer may wants this machine in meta-yocto?
Jan 26 11:34:32 <ag> Your customer wants this machine in meta-yocto?
Jan 26 11:34:59 <jekhor> ag, yes :)
Jan 26 11:36:20 <ag> :) Funny. Anyway, the best way to do it is to use that meta layer. About including this machine in meta-yocto.... don't know. And sa Chris said.... "we tend to have just one reference board per architecture in meta-yocto"
Jan 26 11:36:50 <ag> As a final result you want a build and not layers. So you will have the result in this way.
Jan 26 11:37:05 <bluelightning> jekhor: I would suggest going back to your customer and pointing out that there's already a Freescale-supported layer for this machine
Jan 26 11:37:27 <bluelightning> jekhor: is this ppc64?
Jan 26 11:37:40 <jekhor> He knows about it.
Jan 26 11:38:09 <ag> And what is the problem with this layer?
Jan 26 11:38:36 <jekhor> powerpc-e500v2 core
Jan 26 11:39:12 <jekhor> 32 bit
Jan 26 11:40:11 <ag> Yes. e5500 has a 65bit version as i remember.
Jan 26 11:40:40 <ag> 64*
Jan 26 11:43:28 <bluelightning> jekhor: I don't know but it's possible we might change the official ppc machine (and maybe add a ppc64 one)... as ag suggested probably best to ask on the yocto mailing list
Jan 26 11:44:42 <bluelightning> what we provide in meta-yocto is really just for reference though
Jan 26 15:44:00 <autif> I wrote a recipe and it seems to work - I have expected files in tmp/work/core2-poky-linux/mono-2.10/image/usr/lib - however not all of these file make it to tmp/deploy/images/core-image-autif-crownbay.ext3
Jan 26 15:44:30 <autif> How is the image built from individual recipes?
Jan 26 15:46:55 <bluelightning> autif: there are some details, but basically everything in IMAGE_INSTALL goes into the image
Jan 26 15:47:05 <bluelightning> i.e. every package named in that variable
Jan 26 15:50:24 <autif> bluelightning - true, I do have IMAGE_INSTALL += "mono" in core-image-autif.bb - and mono does get built - its make makes (say) 80 binaries - all of these are copied correctly to tmp/work/core2-poky-linux/mono-2.10/image/usr/lib and tmp/work/core2-poky-linux/mono-2.10/image/usr/bin
Jan 26 15:51:04 <autif> bluelightning - however, out of these 80 binaries only like 20 or 40 are copied to tmp/deploy/images/core-image-autif-crownbay.ext3
Jan 26 15:51:19 <autif> why might that be?
Jan 26 15:51:21 <bluelightning> autif: so I'm assuming those go into separate packages
Jan 26 15:51:25 <kergoth`> autif: each recipe emits binary packages. PACKAGES in a recipe is a list of packages that will be emitted. FILES_<package name> is a list of globs which match the files to be included in that package.
Jan 26 15:51:27 <autif> chances are that I am missing something somewhere
Jan 26 15:51:36 <bluelightning> autif: have a look at packages-split in the mono workdir
Jan 26 15:51:58 * autif looks into that
Jan 26 15:54:30 <autif> ah, what goes into the image is not the output of the recipe, but what packages are included - I was not aware of this
Jan 26 15:54:32 <autif> thanks!
Jan 26 15:54:46 <autif> will add mono-dev and others to my imge recipe
Jan 26 15:54:49 <autif> that should work
Jan 26 15:54:50 <autif> right?
Jan 26 15:55:07 <autif> bluelightning
Jan 26 15:55:08 <autif> ?
Jan 26 15:55:33 <bluelightning> autif: if what's in mono-dev is what you want in your image, then absolutely yes
Jan 26 15:55:50 <autif> thats true - will do thanks again!
Jan 26 15:55:53 <bluelightning> np
Jan 26 16:05:32 <vmeson> is there a good reason for not having ruby in oe-core/yocto? I see that there is openembedded.git/recipes/ruby/ruby_1.8.7-p302.bb
Jan 26 16:05:54 <kergoth`> oe-core is meant to be a minimal core
Jan 26 16:05:55 <vmeson> probably no one needed it yet...?
Jan 26 16:07:39 <vmeson> what layer/repo would be appropriate for yocto? Likely doing ruby-1.9.3
Jan 26 16:17:12 <bluelightning> vmeson: we probably need a meta-ruby
Jan 26 16:17:41 <vmeson> or a meta-languages
Jan 26 16:17:54 <autif> isnt the meta-development
Jan 26 16:17:55 <fray> Ruby (just based on demand and usage) falls outside the core.. but a meta-ruby or as you just mentioned, a meta-languages might be useful..
Jan 26 16:18:07 <fray> autif, perhaps..  this is where things get a bit interesting..
Jan 26 16:18:55 <fray> Things submitted to Yocto need to have a maintainer.  Either in an existing project/layer -- or via a new project/layer...
Jan 26 16:18:57 <autif> sorry, I confused recipies-devtools with meta-devtools - it does not exist
Jan 26 16:19:42 <autif> yes, so yes, we probably need a meta-languages/meta-dev/meta-devtools
Jan 26 16:20:23 <fray> this is also where the meta-oe comes into place.. if it's a single component, it's a reasonable first step to publish the item, especially if the author isn't likely to do more then simple maintenance on it..
Jan 26 16:20:43 <fray> I hate to say it this way, but meta-oe is kind of a dumping ground when it's not obvious where to put the component otherwise
Jan 26 16:21:33 <bluelightning> so whatever division you make there has to be someone (or a small group) prepared to maintain all of the recipes in the layer
Jan 26 16:21:55 <bluelightning> so a division such as meta-ruby would make sense; meta-languages is likely to be unmanageable
Jan 26 16:21:59 <bluelightning> or become that way
Jan 26 16:22:12 <fray> yup...
Jan 26 16:22:30 <bluelightning> fray: yes, there's a danger of meta-oe being seen as that
Jan 26 16:23:08 <fray> thats something we (oe) folks are trying to watch..  keeping it from being a pile of unmaintained garbage..
Jan 26 16:23:16 <fray> as long as the components in it remain useful, we're good..
Jan 26 16:24:41 <ant_work> bluelightning: I'd like to separate the klibc recipes, maybe meta-initramfs
Jan 26 16:25:25 <bluelightning> ant_work: what else will that have in it?
Jan 26 16:25:40 <ant_work> the recipes building static packages
Jan 26 16:25:57 <ant_work> i.e. kexec-tools-klibc
Jan 26 16:26:27 <ant_work> (I have to talk with sgw about the right naming btw)
Jan 26 16:31:19 <ant_work> bluelightning: ideally klibc would reside in oe-core, though
Jan 26 16:31:56 <bluelightning> ant_work: have you floated that idea with sgw/RP?
Jan 26 16:32:39 <ant_work> I did not insist yet. I'll try soon with upcoming klibc_2.x.
Jan 26 16:33:00 <ant_work> I've had some talk with Darren fwiw
Jan 26 16:34:47 <ant_work> klibc makes sense for "tiny"
Jan 26 16:43:42 <xumbi> has anyone built boost recently?  my build seems to be generating x86 binaries rather than arm
Jan 26 16:46:07 <zenlinux> xumbi, I'm wondering if the machine layer you're using might have issues. Try building for qemuarm and see if it does the same thing?
Jan 26 16:47:14 <xumbi> zenlinux: sure I'll give it  a try, seems odd that it would just be that one recipe though
Jan 26 16:48:02 <zenlinux> true
Jan 26 16:48:22 <zenlinux> if the build of boost results in a failure, pastebin'ing your error msg might help too
Jan 26 16:52:40 <zenlinux> xumbi, I'm off to a meeting, will be gone for at least an hour
Jan 26 16:53:09 <xumbi> zenlinux: ok thanks, I'll try a qemuarm build in the meantime
**** ENDING LOGGING AT Thu Jan 26 17:46:57 2012

**** BEGIN LOGGING AT Thu Jan 26 17:48:20 2012
Jan 26 18:32:23 <xumbi> zenlinux: I just verified that boost is using the system g++ by renaming /usr/bin/g++, now to figure out why...
Jan 26 18:34:52 <zenlinux> xumbi, are you using a particular poky release, or building from master?
Jan 26 18:35:39 <xumbi> I'm using poky-edison-6.0
Jan 26 18:37:25 <zenlinux> looking at the recipe, it's not using autotools. I believe we typically ensure Poky's compiler is used by setting CC within the build environment. My first guess would be that a boost makefile is overriding this somewhere
Jan 26 18:37:58 <xumbi> yes that's my guess too, I'm reading up on boost cross compiling
Jan 26 19:27:41 <autif> how is it determined if a specific library goes into mono or mono-dev package - in my case libmono.so goes to mono, however libMonoPosixHelper.so goes to mono-dev package - under tmp/work/core2/mono/packages-split
Jan 26 19:28:10 <autif> is id determined by yocto/OE or by autotools in mono?
Jan 26 19:28:16 <autif> or something completely else
Jan 26 19:32:28 <zenlinux> autif, I think you'll find the hueristics in package.bblcass
Jan 26 19:32:45 <zenlinux> you can of course override anything using the FILES_ metadata variables
Jan 26 19:53:53 <khem> autif: where is libMonoPosixHelper.so installed ?
Jan 26 19:54:21 <khem> autif: generally .so are symlinks to .so.X which are really only needed for development
Jan 26 19:54:45 <autif> it is supposed to be in /usr/lib - however it is mono-dev package, I need it to be in mono package
Jan 26 19:54:57 <khem> same will be true for libmono.so as well. unless the recipe has packaged it differently
Jan 26 19:55:12 <khem> yes thats ok. Is it a symlink ?
Jan 26 19:55:18 <autif> That is true, except that libmono.so is indeed in the mono package
Jan 26 19:55:37 <khem> and is libmono.so a symlink too
Jan 26 19:55:46 <autif> none of these are symlinks
Jan 26 19:55:51 <autif> they are proper files
Jan 26 19:56:22 <khem> ok by default package splitter thinks that if a file ends in .so then its a symlink
Jan 26 19:56:30 <autif> I did mean the full files - when in fact I was referirng to their symlinks
Jan 26 19:56:42 <autif> let me check again
Jan 26 19:56:50 <khem> so if you know your package is anamoly then make sure you add it properly to FILE_<package>
Jan 26 19:57:01 <khem> ?
Jan 26 19:58:08 <autif> khem - http://pastebin.com/fTh6PW8F     <———— this is what it is currently
Jan 26 19:59:18 <autif> I need lines 11, 15 and 19 to be in mono package
Jan 26 19:59:41 <autif> I have added FILES_${PN} += "${libdir}/lib*${SOLIBS}"
Jan 26 19:59:45 <autif> to my recipe
Jan 26 20:00:42 <autif> how do I clean and rebuild the image - so that only mono and the image is rebuilt
Jan 26 20:03:57 <walters> do you guys have any tooling around modifying upstream sources?  it seems to me the best thing here is exactly what you have to do in fedora/debian since you're working from a tarball; git init;git add.;git commit -a -m 'upstream' in the unpacked tarball, then modify, git format-patch -1 HEAD, add the patch to the recipe?
Jan 26 20:13:30 <autif> khem - now I see your point. Mono is funny this way it seems - it had made at least 3 file (not symlinks)  that end with .so and atleast one of these is required for .NET Windows Forms apps to run properly
Jan 26 20:13:53 <khem> autif: add FILES_${PN} += "${libdir}/libMonoSupportW.so" to your recipe
Jan 26 20:13:55 <autif> that file would be libMonoPosixHelper.so
Jan 26 20:14:20 <autif> yes I have added something even better I think
Jan 26 20:14:22 <autif> FILES_${PN} += "${libdir}/lib*${SOLIBS}"
Jan 26 20:14:30 <autif> stole it from one of the recipes
Jan 26 20:14:46 <khem> that would be wrong
Jan 26 20:14:59 <autif> enlighten me :-)
Jan 26 20:15:20 <khem> since now it will also get libmono-2.0.so into mono which should be be -dev
Jan 26 20:15:40 <autif> true
Jan 26 20:15:50 <khem> its alsways better to be explicit
Jan 26 20:15:59 <khem> regexps are greedy
Jan 26 20:16:12 <autif> understood - will add the three libs in my recipe
Jan 26 20:16:19 <khem> thanks
Jan 26 20:16:36 <khem> this other example you saw probabaly is wrong too
Jan 26 20:16:42 <khem> which recipe is it ?
Jan 26 20:17:11 <autif> Its from the poky ref manual
Jan 26 20:17:13 <autif> http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#var-PN
Jan 26 20:17:24 <autif> section 3.1.5
Jan 26 20:18:26 <khem> autif: actually what you did it correct
Jan 26 20:18:47 <khem> SOLIBS = ".so.*"
Jan 26 20:19:18 <khem> can you try with the original fix you had ?
Jan 26 20:19:30 <khem> and see where does libmono-2.0.so goes ?
Jan 26 20:20:12 <autif> test is running
Jan 26 20:20:31 <autif> do_package() is running, not done yet
Jan 26 20:20:33 <khem> I think your problem should not be solved with FILES_${PN} += "${libdir}/lib*${SOLIBS}"
Jan 26 20:23:13 <autif> funny, no difference - http://pastebin.com/pJWnEuav - notice that mono's recipe revision changed from r0 to r1
Jan 26 20:23:42 <khem> thats what I expected
Jan 26 20:23:42 <autif> do I need to clean some cache or something?
Jan 26 20:23:54 <khem> what did you do ?
Jan 26 20:24:05 <khem> did you use FILES_${PN} += "${libdir}/lib*${SOLIBS}" ?
Jan 26 20:24:16 <autif> Added FILES_${PN} += "${libdir}/lib*${SOLIBS}" to the recipe
Jan 26 20:24:25 <autif> yes
Jan 26 20:24:39 <autif> oh becaise SOLIBS is .so.
Jan 26 20:25:03 <autif> so, I need to be explicit
Jan 26 20:25:07 <khem> right
Jan 26 20:25:11 <autif> like your other example
Jan 26 20:25:12 <autif> will do
Jan 26 20:25:34 <autif> will report in a few - image is still building - i just peeked in the work/../temp directory
Jan 26 20:42:20 <autif> Seems like I have what I wanted to have http://pastebin.com/vtQrp3u8
Jan 26 20:42:33 <autif> khem
Jan 26 20:45:09 <khem> ok
Jan 26 20:48:49 <autif> thanks for all the help!
Jan 26 21:40:06 <fray> ls
Jan 26 21:40:10 <fray> oops
Jan 27 01:58:15 <dvhart> sgw, so ranpwd and genmac still don't install
Jan 27 01:58:24 <dvhart> genmac doesn't even have a log.do_install log
Jan 27 02:00:54 <sgw> dvhart: you cleaned netbase or bump'ed it's PR right?
Jan 27 02:01:09 <dvhart> I did a cleanall, did not bump the PR
Jan 27 02:01:16 <dvhart> the cleanall should be sufficient
Jan 27 02:01:22 <dvhart> and it did rebuild
Jan 27 02:01:39 <sgw> yes it should, but a PR bump for an RDEPENDS is warranted.
Jan 27 02:02:56 <dvhart> how did we decide to do PR bumps in bbappends?
Jan 27 02:03:07 <dvhart> not sure I saw a final resolution on that...
Jan 27 02:03:40 <sgw> oh, I missed that this was a .bbappend!
Jan 27 02:04:21 <sgw> We would have to consult the ml archives on that, I am not sure I remember either, or take a look in meta-oe
Jan 27 02:05:00 <dvhart> it's irrelevant anyway
Jan 27 02:05:09 <sgw> PRINC := "${@int(PRINC) + 1}"
Jan 27 02:05:10 <dvhart> I bumped it, it rebuilt, the other files still do not appear
Jan 27 02:07:07 <sgw> So genmac is being build, but not installed?
Jan 27 02:07:29 <dvhart> yes, same with ranpwd
Jan 27 02:07:42 <sgw> what does -g -u depexp show?
Jan 27 02:07:56 <sgw> on netbase
Jan 27 02:08:01 <dvhart> netbase->genmac->renpwd
Jan 27 02:08:11 <sgw> what about on the image you are building?
Jan 27 02:08:36 <dvhart> need a moment for that...
Jan 27 02:09:31 <dvhart> same
Jan 27 02:10:19 <sgw> dvhart: you got me, I am at a loss at this point, RDEPENDS should get it installed on the image.
Jan 27 02:10:42 <dvhart> Thanks for having a look. I'm guessing I broke the do_install or something
Jan 27 02:10:49 <dvhart> not sure what to look for though
Jan 27 02:12:19 <sgw> you could try simplifing it to an echo and see if do_install gets run
Jan 27 02:14:36 <dvhart> OK, I'll let it stew, I've burned all the time I can on it for now, need to get back to another BSP boot debug
Jan 27 02:14:55 <dvhart> thanks for having a look
Jan 27 02:15:15 <sgw> dvhart: sure thing, sorry I could not get you fixed up, probably something we are both overlooking.
Jan 27 02:15:40 <sgw> 30min+ and the genext2fs is still running!
Jan 27 02:21:30 <dvhart> sgw, little overzealous with the debug were we?
Jan 27 02:21:53 <sgw> no just a 4G image and no -02!
**** ENDING LOGGING AT Fri Jan 27 02:59:57 2012

**** BEGIN LOGGING AT Fri Jan 27 02:59:58 2012
Jan 27 09:07:08 <bluelightning> hi all
Jan 27 10:07:29 <RP__> morning all
Jan 27 10:09:02 <bluelightning> hi RP__
Jan 27 10:43:38 <ant_work> hi RP__
Jan 27 10:51:26 <ant_work> about that tzdata postinst, do you mean to let it run twice? First on host (instead of providing /etc/localtime on do_install)  then on target by pkg upgrade?
Jan 27 12:51:39 <ant_work> JaMa: do you have any hint about ^^ ?
Jan 27 12:52:31 <JaMa> I think he meant to create $D/etc/localtime in postinst
Jan 27 12:52:55 <JaMa> which works right for both do_rootfs and "upgrade"
Jan 27 12:53:13 <ant_work> in fact if you look at the ebuild, there is cp -f "${ROOT}"/usr/share/zoneinfo/"${tz}" "${etc_lt}"
Jan 27 12:53:22 <ant_work> I have overlooked it
Jan 27 12:53:38 <ant_work> I intended to run only on target
Jan 27 12:54:05 <JaMa> but running on do_rootfs is also usefull ie for read-only rootfs
Jan 27 13:50:37 <ant_work> JaMa: I would not like to abuse of [[  ]] &&  constructs
Jan 27 13:55:58 <ant_work> JaMa: seems to be posix (documented in ksh)
Jan 27 13:57:53 <JaMa> I don't see the need for them
Jan 27 13:58:12 <JaMa> and gtg
Jan 27 15:35:14 <Zagor> where can I read about the initial/intermediate/final package concept in yocto?
Jan 27 15:35:34 <denisATeukrea> that's for toolchains
Jan 27 15:35:57 <Zagor> yes, and libc
Jan 27 15:36:19 <Zagor> I still want to know about it :-)
Jan 27 15:43:20 <kergoth`> google for info on building crosscompiler toolchains. it isn't specific to yocto
Jan 27 15:43:29 <kergoth`> the naming is, but the concept is not
Jan 27 15:43:53 <Zagor> I've built tons of cross compilers, but I never used three stages like yocto does
Jan 27 15:44:26 <kergoth`> intermediate becomes necessary when you introduce c library addons like nptl
Jan 27 15:50:56 <Zagor> kergoth`: ok, thanks. do you know if that is described anywhere?
Jan 27 15:57:29 <kergoth`> hmm, not offhand, might try googling for building a crosscompiler with nptl
Jan 27 15:58:24 <fray> Zagor all cross compilers run in three stages, and have for a very long time..
Jan 27 15:58:44 <fray> it's not just nptl, it's matching the C library to the compiler.. the compiler will munge the kernel headers and C libraries slightly to "fix" things..
Jan 27 15:59:05 <fray> NPTL support does cause more updates then regular..
Jan 27 15:59:12 <kergoth`> ah, right
Jan 27 15:59:37 * kergoth` clearly doesn't build them by hand anymore, and lets khem do all the oe work :)
Jan 27 15:59:50 <walters> where does /usr/bin/libtool (not /usr/bin/libtoolize) come from?  on fedora it appears to be from the same package that provides libtoolize, but i'm not getting it in the libtool.rpm in deploy-rpms
Jan 27 16:00:03 <fray> usual order is...  kernel headers, binutils, bootstrap gcc, bootstrap glibc, full gcc, full glibc
Jan 27 16:00:05 <walters> the upstream libtool Makefile.am  clearly has bin_SCRIPTS = libtoolize libtool
Jan 27 16:00:27 <fray> 'er.. that bootstrap_two gcc, full glibc, full gcc.. :P
Jan 27 16:00:39 <kergoth`> hehe, was thinking that wasn't quite everything
Jan 27 16:00:45 <walters> i had it at one point and then changed my package set, now it appears to be gone
Jan 27 16:00:52 <fray> walters in the cross compiler.. there is a libtool-cross that populates the sysroot..
Jan 27 16:01:04 <fray> on a target system.. the libtool package I believe provides both libtool and libtoolize..
Jan 27 16:01:28 <fray> wow.. my english is apparently leaving me..
Jan 27 16:01:36 <fray> lets try that first statement again..
Jan 27 16:01:47 <fray> walters: when cross compiling.. there is a libtool-cross that populates the sysroot..
Jan 27 16:01:59 <walters> right, that makes sense
Jan 27 16:02:01 <kergoth`> i was picturing walters in a crosscompiler somewhere, lost
Jan 27 16:02:03 <kergoth`> :)
Jan 27 16:02:03 <walters> i want libtool on the target system
Jan 27 16:02:13 <fray> kergoth, so was I after I re-read that.. :P
Jan 27 16:02:18 <kergoth`> hehe
Jan 27 16:02:23 <fray> ya, it SHOULD just be the target libtool package..
Jan 27 16:02:29 <walters> although i did end up just fixing the bug in libxml2 where its autogen.sh looks for /usr/bin/libtool even though it just runs libtoolize
Jan 27 16:02:35 <fray> it's not normally installed in any of the images, other then perhaps anSDK image..
Jan 27 16:02:54 <walters> ok, i'll see if i can dig into why it's not being installed on target
Jan 27 16:03:36 <fray> ya.. the libtool target package on my system contains both libtool and libtoolize
Jan 27 16:03:43 <fray> libtool-2.4.2-r0.0.x86_32-dbcc721.rpm
Jan 27 16:04:04 <fray> (ignore the -dbcc721 bit... thats something local to my build)
Jan 27 16:04:30 <walters> $ rpm -qpl tmp-eglibc/work/i586-gnomeos-linux/libtool-2.4-r4/deploy-rpms/i586/libtool-2.4-r4.i586.rpm |grep /usr/bin
Jan 27 16:04:30 <walters> warning: tmp-eglibc/work/i586-gnomeos-linux/libtool-2.4-r4/deploy-rpms/i586/libtool-2.4-r4.i586.rpm: Header V4 DSA/SHA1 Signature, key ID 9f977b0c: NOKEY
Jan 27 16:04:30 <walters> /usr/bin
Jan 27 16:04:30 <walters> /usr/bin/libtoolize
Jan 27 16:04:35 <walters> $
Jan 27 16:04:59 <fray> I have both /usr/bin/libtool and /usr/bin/libtoolize here
Jan 27 16:05:34 <fray> looks like my version is newer then yours.. 2.4.2-r0
Jan 27 16:06:30 <d4ny> Hi All, whats the point with the three step build of the compiler ? i.e. gcc-cross-initial, gcc-cross-intermediate, gcc-cross
Jan 27 16:06:55 <fray> gcc-cross-initial is the first bootstrap..  this gives the system the ability to process raw binaries for a given target
Jan 27 16:07:08 <fray> gcc-cross-intermediate gives the ability for the system to produce basic binaries for a given Linux system..
Jan 27 16:07:20 <fray> gcc-cross includes the ability to produce binaries for a given Linux system & libc
Jan 27 16:08:07 <fray> usual order is...  kernel headers, binutils, bootstrap gcc, bootstrap glibc, second bootstrap gcc, full glibc, full gcc
Jan 27 16:08:20 <fray> each step needs the items produced from the prior step to work
Jan 27 16:08:21 <bluelightning> there's an echo in here I feel sure of it...
Jan 27 16:08:24 <bluelightning> ;)
Jan 27 16:08:29 <fray> yup
Jan 27 16:08:50 <bluelightning> probably would be worth documenting this briefly somewhere
Jan 27 16:09:12 <fray> there used to be a cross toolchain generation script.. but for the life of me I can't remember what it was called..
Jan 27 16:09:24 <fray> it could build cross toolchains for most major architectures...
Jan 27 16:09:35 <bluelightning> er, crosstool...?
Jan 27 16:09:39 <fray> that might have been it
Jan 27 16:09:48 <bluelightning> well, crosstool-ng now I think
Jan 27 16:09:58 <fray> ya.. thats it (the orgiinal version)
Jan 27 16:10:02 <d4ny> But why ?, last time I compiled a cross-gcc, or even a canadian cross. It was a one shot build. Why is this special ?
Jan 27 16:10:05 <fray> I helped the guy who originally wrote it get the order right..
Jan 27 16:10:16 <bluelightning> fray: cool :)
Jan 27 16:10:27 <fray> you need to have kernel headers and glibc headers and glibc libraries in place to build the cross compiler..
Jan 27 16:10:35 <fray> without those, you won't get a functional cross compiler due to the dependencies
Jan 27 16:10:46 <d4ny> ah, I see
Jan 27 16:10:54 <fray> if you have final kernel headers and glibc, you can skip the bootstrap and intermediate and go right to the final
Jan 27 16:11:21 <fray> it's been this way for a long time now.. 2002/2003 time frame...
Jan 27 16:11:49 <fray> prior to that it was a two step process.. because the glibc/gcc were not linked..
Jan 27 16:11:53 * fray has to go.. back in a bit
Jan 27 16:12:07 <d4ny> thx for the explanation.
Jan 27 16:15:07 <denisATeukrea> hi, I got no answer in #oe so I post here
Jan 27 16:15:36 <denisATeukrea> could that be the cause of the illegal instruction I get:    0x2c050044 <+540>:			; <UNDEFINED> instruction: 0xffffd3d4
Jan 27 16:24:44 <denisATeukrea> or is this normal gdb stuff
Jan 27 16:25:01 <denisATeukrea> because for instance symbols that are to be loaded are undefined
Jan 27 16:25:12 <denisATeukrea> U in arm*-nm
Jan 27 16:36:45 <zeddii>  /me thinks he is missing something in master
Jan 27 16:36:51 * zeddii also can't use IRC.
Jan 27 16:37:04 <zeddii> | Makefile:432: *** No gnu/libc-version.h found, please install glibc-dev[el]/glibc-static.  Stop.
Jan 27 16:37:08 * zeddii pulls
Jan 27 16:38:56 <zeddii> after my update: ERROR: Task do_package_setscene depends upon nonexistant task /home/bruce/poky/meta/recipes-extended/shadow/shadow-native_4.1.4.3.bb:do_populate_sysroot_setscene
Jan 27 16:38:59 <zeddii> ech.
Jan 27 16:39:04 * zeddii tries again.
Jan 27 16:39:24 <fray> thats due to a recent bug fix..
Jan 27 16:39:29 <fray> but why it errored, I don't know
Jan 27 16:39:43 <fray> (note, I havn't updated since that fix was introduced)
Jan 27 16:39:47 <zeddii> yah. I am now fully up to date.
Jan 27 16:39:55 * zeddii suggests that you don't, unless you want to fix it. :)
Jan 27 16:41:02 <fray> I think it was RP and zenlinux working on the original fix..
Jan 27 16:41:14 * fray updates to see if it's busted
Jan 27 16:41:26 <fray> (or if Zeddii is having a bad day)
Jan 27 16:42:23 <RP__> zeddii: that doesn't sound good. My builds work and the autobuilder doesn't seem to be doing so badly
Jan 27 16:42:40 <fray> RP__ could it be due to an existing package cache or something?
Jan 27 16:42:41 * zeddii is trying to debug now.
Jan 27 16:42:57 * zeddii would definitely have stale caches floating around.
Jan 27 16:43:03 <RP__> zeddii: try moving tmp/cache out the way
Jan 27 16:43:12 <zeddii> will do.
Jan 27 16:44:28 <RP__> zeddii: you're using poky, right?
Jan 27 16:44:34 <zeddii> RP__, correct.
Jan 27 16:44:41 <zeddii> and no changed with the move of cache
Jan 27 16:44:46 <RP__> zeddii: not bitbake and oe-core separately or anything like that
Jan 27 16:44:58 <zeddii> nope. full poky, that's it.
Jan 27 16:45:09 <zeddii> + my kernel grafts. but they wouldn't be in play here.
Jan 27 16:45:30 <RP__> zeddii: can you pastebin the bitbake output please, I'd like to see that error in context
Jan 27 16:47:32 <zeddii> RP__, http://pastebin.com/ga2eBLwK  .. let me know if that's not the output you wanted. I can dump the env, etc.
Jan 27 16:48:01 <RP__> d4ny: FOr toolchain info please see the mailing list archives. Its been covered by me there before
Jan 27 16:48:19 <d4ny> RP__: OK, thx
Jan 27 16:51:05 <RP__> zeddii: If it helps, if I bitbake linux-yocto here I see that error
Jan 27 16:51:16 <RP__> zeddii: other targets have been working fine
Jan 27 16:51:39 <zeddii> interesting. something changed underneath. hmm.
Jan 27 16:52:24 <zeddii> I was doing final builds and boots on 3.2 hence my multiple provider warning.
Jan 27 16:52:31 <RP__> zeddii: as a workaround, add another target like dbus
Jan 27 16:52:40 <RP__> zeddii: I'll figure out why this is breaking
Jan 27 16:53:14 <RP__> zeddii: I think your build has to include something from the useradd class
Jan 27 16:53:42 <RP__> what a lovely odd bug to end the day with
Jan 27 16:54:12 <zeddii> indeed. it's mid friday for me, and I could do without it as well. I can yank my bzImage directly out of the build as well to keep moving.
Jan 27 16:56:06 <RP__> zeddii: you could also just revert out the last useradd change to workaround this
Jan 27 16:56:23 * zeddii does just that.
Jan 27 16:57:58 <RP__> zeddii:  I have a proper fix too, will push
Jan 27 16:58:32 <zeddii> thx RP__ most appreciated. back to kernel building and booting then~!
Jan 27 17:00:18 <RP__> zeddii: np, fix should be in master now
Jan 27 17:04:06 <sgw> zeddii: have you got a patch for the edison 1.1.1 kernel done (maybe I missed it)?
Jan 27 17:24:51 <zeddii> sgw, josh has it and just emailed me about it.
Jan 27 17:26:55 <incandescant> sorry zeddii, apparently the place I was yesterday didn't have WWW so I'm a bit behind :-/
Jan 27 17:27:10 <zeddii> no worries!
Jan 27 17:28:36 <zeddii> fray: checkout my next error.
Jan 27 17:28:41 <zeddii> /home/bruce/poky/build/tmp/sysroots/x86_64-linux/usr/bin/rpmbuild.real: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory
Jan 27 17:28:48 * zeddii clears out more
Jan 27 17:39:29 <bluelightning> kergoth`: that code I added to collect overlayed recipes in cooker collect_bbfiles?
Jan 27 17:39:53 <bluelightning> turns out, bitbake retains information in the cache about recipes that directly overlay eachother
Jan 27 17:40:07 <bluelightning> so that code was unnecessary... oh well
Jan 27 17:41:21 <kergoth`> heh, hate it when that happens
Jan 27 17:58:15 <sgw> kergoth`: have you had a chance to look at the Source Archiver Email?
Jan 27 18:49:24 <fray> zeddii, looks like Steve Sakoman found the problem... a missing quote
Jan 27 19:48:51 <kergoth> ERROR: Package version for package wpa-supplicant-cli went backwards which would break │
Jan 27 19:48:54 <kergoth> package feeds from (0:0.7.3-r7 to 0:0.7.3-r7.1)
Jan 27 19:48:56 <kergoth> wtf?
Jan 27 19:49:03 <kergoth> since when is 0.7.3-r7 newer than 0.7.3-r7.1?
Jan 27 19:58:43 <ant__> RP__: last commit (63d006b) lacks a double quote in USERADDSETSCENEDEPS
Jan 27 19:59:40 <seebs> kergoth:  I don't know how yocto does it specifically, but version number comparisons make SCSI termination seem comprehensible.
Jan 27 19:59:48 <kergoth> haha, true
Jan 27 19:59:56 <kergoth> I like the approach P2 (in eclipse) took
Jan 27 20:00:38 <kergoth> they encode the information used to split up the version into components into the version string itself. under the hood, everything gets a common form, but you can use it to say this version is under rpm rules, that one under debian, ..
Jan 27 20:00:45 <seebs> It might be that { 3, r7.1 } is smaller than { 3-r7 }
Jan 27 20:00:46 <kergoth> no need for a central authority, since its self contained
Jan 27 20:01:02 <kergoth> good point, i'll append to PV instead for now
Jan 27 20:01:38 <seebs> It's the only obvious thing I can think of; the trailing ".1" could be preventing something from noticing the - seperator.
Jan 27 20:01:39 <seebs> Actually.
Jan 27 20:01:51 <seebs> Yeah, that would make sense.  Split on ., then check the last one for a -rN.
Jan 27 20:02:12 <kergoth> the thing is, it should be separating on any number/letter/separator boundary, and logically extending a shorter one to match a longer one with zeros
Jan 27 20:02:15 <kergoth> (imo anyway)
Jan 27 20:02:20 <seebs> ... in other news, I can totally spell separator most of the time.
Jan 27 20:02:24 <kergoth> hehe
Jan 27 20:03:00 <seebs> I was thinking the - thing might be a special case, used for stuff like svn checkouts which are often -rN for integer N.
Jan 27 20:03:32 <seebs> Of course, sometimes version numbers are Just Plain Wrong.  I know of at least one case where 1.0 is later than 1.9.
Jan 27 20:03:39 <kergoth> http://wiki.eclipse.org/Equinox/p2/Omni_Version - i was thinking it'd be cool to make bitbake support it internally, and take any non-marked-up version and say it's the current scheme, to avoid breaking compatibility
Jan 27 20:03:49 <kergoth> heh, yeah, not much you can do about those, other than bump epoch, which is why we have epoch :)
Jan 27 20:05:14 <seebs> Wow, that's really neat.
Jan 27 20:05:35 <seebs> I have this vague sense that this is probably one of the highest sinks of developer time and attention compared to the marginal value out there.
Jan 27 20:06:46 <kergoth> I really dont' envy the people that created that omniversion scheme. trying to come up with a format syntax that'd cover everything coudlnt' have been fun
Jan 27 21:23:39 <khem> RP__: commit 63d006b2d3fc2223c74f81b91f70f5c841108c80 has a missing quote
Jan 27 21:23:55 <khem> can you please correct it before you head to weekend :)
Jan 27 21:24:47 <khem> http://paste.ubuntu.com/819336/
Jan 27 21:24:50 <khem> is the fix
Jan 27 21:25:14 <khem> RP__: bb parsing is broken otherwise
Jan 27 21:25:17 <khem> with errors like
Jan 27 21:25:32 <khem> ERROR: Nothing PROVIDES '"base-passwd'
Jan 27 21:25:39 <kergoth> s/parsing/build/
Jan 27 21:25:50 <khem> err yes :)
Jan 27 21:27:02 <khem> gold finds interesting issues with linking
Jan 27 21:27:13 <khem> that GNU ld will never see in its life time
Jan 27 21:27:16 <khem> I am happy
Jan 27 21:27:36 <khem> like accessing hindden symbols from .so
Jan 27 21:28:39 <kergoth> neat
Jan 27 21:28:43 <kergoth> that sounds useful
Jan 27 21:29:01 <khem> I always wondered why exception handing was not working on mips here
Jan 27 21:29:08 <khem> and it was a folklore
Jan 27 21:31:11 <khem> now I know how it does it on i386
Jan 27 21:31:40 <khem> SIGFOOD
Jan 27 21:31:56 <khem> oops ECAFECLOSED
**** ENDING LOGGING AT Sat Jan 28 03:00:00 2012

**** BEGIN LOGGING AT Sat Jan 28 03:00:00 2012
**** ENDING LOGGING AT Sun Jan 29 02:59:58 2012

**** BEGIN LOGGING AT Sun Jan 29 02:59:58 2012
Jan 29 13:19:48 <gilsport> hello
Jan 29 13:19:57 <gilsport> is anyone online here?
Jan 29 13:20:07 <gilsport> or should i go to #poky
**** ENDING LOGGING AT Mon Jan 30 02:59:59 2012

**** BEGIN LOGGING AT Mon Jan 30 02:59:59 2012
Jan 30 05:28:45 <Renat> HI! Yocto support compulab cm-x270?
Jan 30 10:23:15 <bluelightning> morning all
Jan 30 10:24:59 <JaMa> moin
Jan 30 10:26:14 <JaMa> RP__: kergoth: fwiw: after reverting switch to futures d104f29871c04a5a36600a35b2568b49e5b21ca0 I haven't seen bitbake hanging in last couple of days
Jan 30 10:39:19 <RP__> morning all
Jan 30 10:39:36 <RP__> JaMa: kergoth knows that area of the code much better than I do :/
Jan 30 10:42:58 <JaMa> RP__: I know, just adding you to "To:" as it doesn't look like sqlite issue at all now
Jan 30 14:10:54 <otavio> RP__: do you have any objection about merging gitpkgv onto oe-core? It is going to be used by other layers and they might to not depends on meta-oe just for this class.
Jan 30 14:11:44 <otavio> RP__: I'd like to prepare and send a patch for it but would like to check with you before. meta-ti seems to be the first layer going to use it.
Jan 30 14:17:20 <RP__> otavio: Remind me what this adds which the fetcher can't do?
Jan 30 14:17:44 <otavio> RP__: it allows for use of git describe output for package versioning
Jan 30 14:19:16 <RP__> otavio: I think I've said this before but it really should be an option in the fetcher, a bit like BB_GIT_CLONE_FOR_SRCREV is to trigger git rev-list
Jan 30 14:19:50 <RP__> otavio: or do I remember rightly that this just injects the package version at package creation time now?
Jan 30 14:20:29 <otavio> RP__: it wasn't easy to integrate onto the fetcher
Jan 30 14:21:09 <otavio> RP__: besides, using it on the fetcher doesn't fix our use case as we'd need a newer bitbake and it won't happen soon (and a higher version requirement as well)
Jan 30 14:22:06 <otavio> RP__: besutes it also supports multiple repositories
Jan 30 14:22:25 <otavio> RP__: is it not complex but it doesn't seem to fit the fetcher code
Jan 30 14:22:42 <otavio> RP__: (by SRCREV_FORMAT)
Jan 30 14:23:03 <RP__> otavio: Looking at the code, there is no good reason there shouldn't be a helper in the fetcher which that code could all into, just like SRCPV
Jan 30 14:23:30 <RP__> otavio: I don't buy the version requirements argument, yet it means it needs some thought but its not really a blocking issue, just takes a little bit of effort
Jan 30 14:23:47 <RP__> otavio: SRCPV supports multiple repositories too...
Jan 30 14:24:11 <RP__> s/all into/call into/
Jan 30 14:24:22 <otavio> RP__: I don't understand the fetcher code well enough to do that myself ...
Jan 30 14:24:46 <otavio> RP__: couldn't we go by the easy path as merging it and later refatoring it? it has been in use by ages in meta-oe
Jan 30 14:24:53 <otavio> RP__: I and others use it a lot.
Jan 30 14:25:06 <RP__> otavio: Who is going to refactor this later?
Jan 30 14:25:16 <RP__> otavio: everyone will just say "too hard"
Jan 30 14:25:39 <otavio> RP__: maybe I; no problem. But I'd like to get it merged soon so we don't hold on this refator requirement for now.
Jan 30 14:26:01 <RP__> otavio: I'm not taking that patch, this needs cleanup before it gets merged
Jan 30 14:26:02 <otavio> RP__: and depending on a newer version of bitbake is a problem for us right now as it might take too long
Jan 30 14:26:04 <RP__> otavio: sorry
Jan 30 14:26:37 <otavio> RP__: besides you not agreeing with it not being done in bitbake's internal, there's any other reason?
Jan 30 14:27:01 <RP__> otavio: not really, I just want to see it done properly
Jan 30 14:27:30 <RP__> otavio: We have way too much of a mess in the fetcher code already. Several of us have tried very hard to improve things, this would be  significant backwards step
Jan 30 14:27:39 <otavio> RP__: many things are not done properly in OE currently ... it will always have batter ways of doing things
Jan 30 14:27:58 <otavio> RP__: it  will not. It will be ONE class
Jan 30 14:28:06 <RP__> otavio: I think many things have been steadily improving
Jan 30 14:29:05 <RP__> otavio: Its one class until the next one. This same argument has been used for many other things, even by you on occasion
Jan 30 14:29:10 <otavio> RP__: sure ... I agree but I really disagree with the reasoning of you nacking the code. It is well written code, it works and works well for more then ONE user.
Jan 30 14:29:43 <otavio> RP__: sure. I can't wait for everything be perfect before having things done.
Jan 30 14:30:16 <otavio> RP__: you merged not ready code on occasion ... nobody has shout this in your fact (until now)
Jan 30 14:30:37 <otavio> RP__: so you don't seem to follow your own rules
Jan 30 14:30:37 <RP__> otavio: You're not even *trying* to refactor this or fix the problem I'm talking about
Jan 30 14:30:59 <RP__> otavio: I try very hard to be very clear about why decisions get made
Jan 30 14:31:24 <otavio> RP__: well, I am not paid to work on this. I am paid to work in our product ... so I don't have all the time to work on refator stuff all the time.
Jan 30 14:31:59 <otavio> RP__: I do contribute refatoring improvements (if you don't recall my contributions, this is a bad thing)
Jan 30 14:32:17 <otavio> RP__: but expect I'll have time for everything is no sense
Jan 30 14:32:20 <RP__> otavio: As far as I can see, this class not being in oe-core doesn't severely impact your product
Jan 30 14:32:40 <otavio> RP__: as I said, it is going to be used by other layers
Jan 30 14:32:50 <RP__> otavio: I do remember and appreciate your contributions and I'm puzzled about what I've said above which would suggest otherwise
Jan 30 14:33:12 <otavio> RP__: and depending on meta-oe just for this class is going on the wrong direction of making users need satisfied.
Jan 30 14:33:36 <RP__> otavio: and merging code that isn't ready into oe-core isn't correct either
Jan 30 14:33:59 <RP__> otavio: Its not a hard job to fix this properly. I could even probably do it if I was given a suitable incentive
Jan 30 14:34:14 <otavio> RP__: It is ready. It can not be the best possible code, sure ... and I agree on that. But it works for all users of it and works fine.
Jan 30 14:34:34 <RP__> instead I'm just getting accused of various things here which doesn't really encore me
Jan 30 14:34:42 <RP__> s/encore/encourage/
Jan 30 14:35:21 <otavio> RP__: this is not the point. I could do it too ... but this seems the wrong thing to do now. I do have a deadline for product in end of Feb and a big backlog to work on.
Jan 30 14:35:52 <otavio> RP__: so what seems wrong for me is you forbit to merge it just because it wasn't done as you'd like it to be done.
Jan 30 14:36:03 <otavio> RP__: this is not a technical reason
Jan 30 14:36:12 <otavio> RP__: it is a matter of taste
Jan 30 14:36:15 <RP__> otavio: It is not in keeping with the effort to clean up the whole fetcher mess
Jan 30 14:36:28 <RP__> otavio: I'm asking it try and be in keeping with that effort
Jan 30 14:36:33 <otavio> RP__: well and neither making it worse
Jan 30 14:36:46 <otavio> RP__: as the fetcher doesn't support it currently
Jan 30 14:37:06 <RP__> otavio: It does make the situation worse, this s what you're not seeing
Jan 30 14:37:42 <otavio> RP__: I'll stop discussing it here. I will send the pull request and we discuss it on mailing list.
Jan 30 14:37:56 <otavio> RP__: this is no sense for me
Jan 30 14:38:24 <RP__> otavio: I will respond as I have here and we can discuss from there
Jan 30 14:38:31 <otavio> RP__: (not the refactoring possibility, I agree with it, but it being a reason for non-mergning)
Jan 30 14:39:20 <RP__> otavio: Its not even like this is a new problem. I've asked this happen before, I just get ignored
Jan 30 14:39:49 <otavio> RP__: I said, I don't know bitbake enough to do it
Jan 30 14:40:04 <otavio> RP__: it would take a lot of time for me to figure it, and I don't have this time now.
Jan 30 14:40:11 <otavio> RP__: so I won't work on this now.
Jan 30 14:40:36 <otavio> RP__: I am working on udev right now and won't move from it for this.
Jan 30 14:40:36 <RP__> otavio: Instead of accusing me of various things above, why don't you perhaps ask if I can give some pointers about how to improve this, maybe even write a patch that you could help test?
Jan 30 14:41:22 <otavio> RP__: the problem is not about doing it ... as I said above; the problem is you nacking it without a technical reason for it.
Jan 30 14:41:29 <otavio> RP__: due a taste matter
Jan 30 14:41:42 <otavio> RP__: I know you can do it in 15min or less ...
Jan 30 14:41:46 <RP__> otavio: technical reason is very clear, you just don't like being told no
Jan 30 14:41:58 <otavio> RP__: but this wouldn't change it
Jan 30 14:42:41 <otavio> RP__: it is not a technical reasoning. And it has nothing to do with 'no'. But with: No, because I don't like it.
Jan 30 14:43:27 <otavio> RP__: but no problem. I will back to udev work
Jan 30 14:43:54 <otavio> RP__: ahh, I've been working on it for tree weeks ... (see? refactoring)
Jan 30 14:44:50 <RP__> otavio: I know you do refactoring work and I appreciate it. Again, I'm puzzled where you think I said otherwise
Jan 30 15:57:49 <kergoth> RP__: not sure if you saw, but ensc in #oe found that the ParseError/ExpansionError block of the exception handling in parse_next() is missing a shutdown(clean=False), apparently
Jan 30 15:57:59 * kergoth wonders how/why this is the case, must have been an oversight
Jan 30 16:08:17 <RP__> kergoth: ah, that does sound like an oversight and might explain JaMa's problem?
Jan 30 16:11:47 <kergoth> makes me wonder if that case was missing in the pre-futures switch too. don't know how i could have missed that
Jan 30 16:19:25 <JaMa> I'll revert that revert when this is pushed and will test if I still see any hangs
Jan 30 16:20:02 <kergoth> if you're up for it, test a few different types of parse failures. e.g. do rp's s/setVar/setVar2/ in teh native conditional in sstate.bbclass
Jan 30 16:21:51 <JaMa> I got 2 hangs per day with normal usage on buildhost.. so I'm not planing any special cases..
Jan 30 16:22:17 <kergoth> yes, but you already said you didn't see the previous hangs
Jan 30 16:22:38 <kergoth> still good to verify, but we need to cover our bases too :)
Jan 30 16:22:50 * kergoth 'll do some testing too if he manages to find some spare minutes
Jan 30 16:23:32 <JaMa> I meant that I haven't had any hangs before switch to futures, then I got 2 per day and now it's fine since revert of futures switch
Jan 30 16:26:37 <kergoth> I know, and I'm explaining that we had hangs in both cases, so we need to make sure that *neither* happen before we can say with any confidence that the underlying issues are resolved
Jan 30 16:32:51 <RP__> kergoth: if you have a patch for this, feel free to merge it. If not I'll get to it but probably not until quite a bit later on
Jan 30 16:32:58 <kergoth> k
Jan 30 16:33:28 <kergoth> it certainly shouldn't hurt anything, so i'll do some basic testing to sanity check and then push it today if i have the time
Jan 30 16:34:43 <RP__> kergoth: thanks
Jan 30 17:04:07 <khem> I am seeing bitbake hangups after finishing parse it never gets to runqueue stage and Ctrl+c doesnt work as well
Jan 30 17:04:19 <khem> machine uses 8 python processors
Jan 30 17:04:45 <khem> anyone else seeing it ?
Jan 30 17:05:06 <khem> this is something new in past week
Jan 30 17:08:38 <JaMa> khem: same here, see my messages above
Jan 30 17:09:01 <kergoth> khem, if it's what we think it is, it should only happen if you have a parse/expansion error. see lib/bb/cooker.py, go down to parse_next(), see the exception catch of ParseError/ExpansionError. try copying and pasting the shutdown(clean=False) from the other blocks. see if that takes care of it
Jan 30 17:11:33 <JaMa> kergoth: the same for SyntaxError?
Jan 30 17:12:55 <kergoth> probably
Jan 30 17:14:22 <khem> kergoth: in my case if I start the bitbake second time all works fine
Jan 30 17:14:31 <khem> to me it seems its an error clause
Jan 30 17:14:48 <khem> mine seems not to be that since it works ok second time around
Jan 30 18:52:23 <kergoth> khem: hmm, interesting, anything special about your setup? any idea how to reproduce it? I haven't found a way yet
Jan 30 18:52:48 <kergoth> khem: oh, regarding the ppc/mips 32 vs 64 thing for the external toolchain, apparently the prefix is the same, distinguished via -m64/-m32
Jan 30 18:54:00 <khem> kergoth: it happens with angstrom.
Jan 30 18:54:11 <khem> bitbake systemd-image
Jan 30 18:54:21 <khem> and my machine has 4 cores
Jan 30 18:54:28 <khem> so spawns 8 threads while parsing
Jan 30 20:12:27 <khem> kergoth: so I just tried with the fix you suggested but my hang still remains
Jan 30 20:12:37 <khem> kergoth: I have to kill python and not bitbake
Jan 30 20:12:56 <khem> if I kill bitbake python is still running as defunt process
Jan 30 20:12:57 <kergoth> Anyone seen an issue where there ends up being no font-alias package? It seems to be a missing dependency or similar, build ordering. Sometimes it emits just -dev and -dbg, but no mian package. if i clean and rebuild it without going from sstate, it emits all 3
Jan 30 20:13:14 <kergoth> i usually just pkill -9 -f bitbake
Jan 30 23:54:59 <bluelightning> pidge: any luck with buildhistory?
Jan 30 23:56:13 <pidge> bluelightning: I think it's PEBKAC atm. my AB class isn't picking up that yes, you do want to inherit this. But, I needed to run MUT, so I'll look at it tonight after MUT.
Jan 30 23:56:26 <bluelightning> pidge: ok, cool
Jan 30 23:56:52 * bluelightning is very tired, time for some sleep
Jan 30 23:57:04 <bluelightning> night
Jan 30 23:57:05 <pidge> night bluelightning
Jan 31 00:12:51 <sgw> kergoth: reading back, for font-alias are you getting no fonts, thus square blank characters?
Jan 31 00:18:12 <kergoth> nope. I'm getting a failure to emit a package, thus a do_rootfs construction failure due to font-util depending on it
Jan 31 00:18:24 <kergoth> but i haven't managed to reproduce it reliably
Jan 31 00:27:11 <sgw> kergoth: Ok, I am seeing a different issue with the square font.
Jan 31 00:27:24 <kergoth> ah
Jan 31 00:45:09 <khem> sgw: square fonts issue is probably due to cairo not doing the right job is it when you boot core-image-sato
Jan 31 00:45:17 <khem> sgw: and is it with uclibc/eglibc
Jan 31 00:45:38 <sgw> khem: with eglibc
Jan 31 00:46:19 <khem> sgw: login into the system using a console
Jan 31 00:46:31 <khem> and then d pango-querymodules
Jan 31 00:46:37 <khem> see if that succeeds
Jan 31 00:49:37 <jlcawood>   /help
Jan 31 00:51:17 <sgw> khem: thanks I will give that a try shortly.
Jan 31 01:20:10 <sgw> khem: that did fix it, not sure why it's not working at first.
Jan 31 01:27:37 <khem> sgw: is this a new root file system
Jan 31 01:27:48 <khem> sgw: it only is run once
Jan 31 01:30:33 <sgw>  wanRight, I guess it's a rootfs install issue.  I have to look at rpm vs ipk rootfs might be part of it.
Jan 31 01:31:06 <khem> what are you using ?
Jan 31 01:31:11 <khem> I know ipk works
Jan 31 01:33:49 <sgw> actually it's IPK!
Jan 31 01:40:32 <khem> hmm
Jan 31 01:40:56 <khem> well I build core-image-sato over weekend from top of tree and all booted fine into qemu
Jan 31 01:41:13 <khem> using ipk and oe-core only
Jan 31 02:19:49 * kergoth glares at font-alias
Jan 31 02:30:14 <kergoth> hmm
Jan 31 02:30:19 <kergoth> I wonder if there's a problem with allarch
Jan 31 02:31:22 <kergoth> this font-alias recipe somehow ended up with a native-like prefix, the files in package/ are the path in sysroot, not usr
Jan 31 02:31:27 * kergoth peruses allarch
Jan 31 02:32:27 <kergoth> hrm
Jan 31 02:34:08 <khem> kergoth: I wonder if allarch should have multilib suffic
Jan 31 02:34:10 <khem> suffix
Jan 31 02:34:26 <khem> meta/conf/multilib.conf has BBCLASSEXTEND_append_pn-font-alias = " ${MULTILIBS}"
**** ENDING LOGGING AT Tue Jan 31 02:59:58 2012

**** BEGIN LOGGING AT Tue Jan 31 02:59:58 2012
Jan 31 08:53:53 <gilsport_> hi
Jan 31 08:53:54 <gilsport_> i am using yocto
Jan 31 08:54:07 <gilsport_> and i am in the middle of the installation of the env now i ran the command
Jan 31 08:54:13 <gilsport_> bitbake meta-ide-support
Jan 31 08:54:36 <gilsport_> and it is running for like 10 hours and downed my diskspace in more then 5GB
Jan 31 08:54:36 <gilsport_> normal!?!
Jan 31 09:31:59 <bluelightning> morning all
Jan 31 10:55:51 <JaMa> kergoth: bitbake hanging again with master and that shutdown added
Jan 31 10:57:15 * JaMa lunch
Jan 31 13:01:03 <RP__> zeddii: ping?
Jan 31 13:15:37 <gilsport_> ????
Jan 31 13:16:16 <gilsport_> pong
Jan 31 13:16:27 <gilsport_> :D
Jan 31 13:56:37 <Blok> At what stage are files in SRC_URI (specified in a recipe) copied to the WORKDIR?
Jan 31 13:59:19 <bluelightning> Blok: do_fetch
Jan 31 13:59:42 <bluelightning> or if they are to be unpacked, do_unpack
Jan 31 14:03:45 <Blok> bluelightning: I am trying to run this simple recipe http://tinyurl.com/yocto-recipe but it does not fetch any of the files specified in SRC_URI. Do you know why?
Jan 31 14:05:09 <bluelightning> Blok: where are the files you refer to in SRC_URI?
Jan 31 14:06:35 <RP__> Blok: "do_fetch" will get files over the network and ensure they're on local storage. "do_unpack" will place them in WORKDIR
Jan 31 14:06:43 <Blok> bluelightning: ...meta-test/recipes-demo/helloworld/files and the recipe is in .. relative to that path
Jan 31 14:06:51 <RP__> Blok: For file:// urls, do_fetch doesn't do anything
Jan 31 14:06:56 <RP__> since they're already local
Jan 31 14:07:10 <bluelightning> right, yes, my mistake
Jan 31 14:08:06 <bluelightning> Blok: that layout ought to work..
Jan 31 14:10:04 <Blok> bluelightning: Then would not "bitbake myimage -f -c unpack" move the files?
Jan 31 14:10:18 <bluelightning> it would copy them, not move them
Jan 31 14:10:29 <bluelightning> but yes
Jan 31 14:10:32 <Blok> bluelightning: oh, sorry, copy
Jan 31 14:13:27 <Blok> bluelightning: No files are copied to /opt/test/build/tmp/work/image/helloworld-1.0-r0 .
Jan 31 14:13:56 <RP__> Blok: what is the recipes filename?
Jan 31 14:14:25 <Blok> RP__: helloworld_1.0.bb
Jan 31 14:14:50 <RP__> Blok: a good tip would be to run "bitbake helloworld -e | grep ^WORKDIR" and see what WORKDIR really is
Jan 31 14:15:08 <RP__> Blok: your path above doesn't look right to me
Jan 31 14:16:45 <bluelightning> Blok: I just tried that here and it works; so something else must be going wrong there...
Jan 31 14:17:22 <bluelightning> Blok: what machine are you building for?
Jan 31 14:17:37 <Blok> WORKDIR="/opt/test/build/tmp/work/image/helloworld-1.0-r0"
Jan 31 14:17:51 <Blok> P4080
Jan 31 14:19:14 <bluelightning> hmm, how did you end up with "image"...?
Jan 31 14:19:27 <RP__> bluelightning: I'm wondering that too
Jan 31 14:19:49 <bluelightning> Blok: what about "bitbake helloworld -e | grep WORKDIR" and "bitbake helloworld -e | grep MULTIMACH_TARGET_SYS"
Jan 31 14:24:23 <Blok> Sorry, stupid obfuscation by me. WORKDIR is /opt/test/build/tmp/work/ppce500mc-foo-linux/helloworld-1.0-r0
Jan 31 14:25:58 <bluelightning> right, that looks a bit more like it
Jan 31 14:26:14 <Blok> bluelightning: Just to make sure, when you run it it copies the files? (or tries to)?
Jan 31 14:26:23 <Blok> bluelightning: Sorry about that :)
Jan 31 14:27:01 <bluelightning> Blok: yes, it does
Jan 31 14:31:01 <bluelightning> Blok: just to confirm, "bitbake -e helloworld | grep ^FILE=" points to the recipe you think it does?
Jan 31 14:31:52 <Blok> yup, it points to my helloworld_1.0.bb
Jan 31 14:31:58 <bluelightning> ok, just checking
Jan 31 14:32:00 <bluelightning> hmm
Jan 31 14:33:10 <Blok> bluelightning: It is a pre-built run that I am trying to rerun. Would that mess up the unpack for example?
Jan 31 14:34:05 <bluelightning> Blok: should not... especially in the above example when you specified -f, that forces it
Jan 31 14:34:32 <bluelightning> you can do "bitbake -c clean helloworld" to start over
Jan 31 14:36:12 <bluelightning> Blok: what does /opt/test/build/tmp/work/ppce500mc-foo-linux/helloworld-1.0-r0/log.do_unpack have in it?
Jan 31 14:38:53 <Blok> bluelightning: now it works! Thanks!
Jan 31 14:39:36 <Zagor> that would indicate -f doesn't do the same things as after clean
Jan 31 14:45:17 <bluelightning> I'm not sure I understand exactly what Blok did beforehand...
Jan 31 14:46:47 <kergoth> JaMa: damnit.
Jan 31 14:51:08 <JaMa> kergoth: btw: should parallel parsing respect BB_NUMBER_THREADS or some similar variable?
Jan 31 14:51:32 <JaMa> with BB_NUMBER_THREADS = "1" I see like 8 bitbake processes during parsing
Jan 31 14:52:17 <JaMa> then it reduces it to 3-4 python.*bitbake processes which is still more then I would expect with BB_NUMBER_THREADS = "1"
Jan 31 14:52:26 <kergoth> BB_NUMBER_PARSE_THREADS, iirc. the potentially unexpected bit is that it defaults to the number of cores, not BB_NUMBER_THREADS
Jan 31 14:53:09 <JaMa> ok will grep bitbake source to check, thanks
Jan 31 14:54:06 <kergoth> I think we should make BB_NUMBER_THREADS default to the number of cores. given optimal is more like 2xcores, that should be conservative enough to make use of the user's resources without interfering with their ability to use the system
Jan 31 14:54:26 <kergoth> heh
Jan 31 14:54:36 <JaMa> but it should take amount of memory into account..
Jan 31 14:54:53 <kergoth> yeah, true
Jan 31 14:55:03 <JaMa> because with 4 cores with 2GB of ram in virtual machine I got lot of swappiness
Jan 31 14:55:12 <JaMa> which is not to my happiness :)
Jan 31 14:59:55 <kergoth> okay, I'm stuck on this issue. sometimes font-alias ends up built with the prefix pointing to the native sysroot rather than the target, and as a result ends up with no ${PN} package emitted. if it does this and i cleansstate and rebuild it, it works fine. my only guess was that maybe allarch doesn't work well with variants, and somehow a native/nativesdk was overwriting the content from the target version,
Jan 31 14:59:58 <kergoth> but thats unlikely given that there's no font-alias-native -- it doesn't define BBCLASSEXTEND :)
Jan 31 15:00:00 <kergoth> anyone have any ideas?
Jan 31 15:00:55 <Zagor> kergoth: are you using -jN with N>1 ?
Jan 31 15:01:20 <Blok> bluelightning: I modified my Makefile, but for some reason it uses some cached version. bitbake -f -c clean helloworld does not help. How do I get rid of the cache?
Jan 31 15:01:56 <Zagor> or is this pure bitbake?
Jan 31 15:02:09 * Zagor is new here :)
Jan 31 15:02:29 <bluelightning> Blok: when you say cached do you mean it only does setscene tasks when you rebuild?
Jan 31 15:04:09 <Blok> bluelightning: It also runs unpack etc
Jan 31 15:04:23 <bluelightning> Blok: what version of poky are you using?
Jan 31 15:04:25 <JaMa> kergoth: and does bitbake read local.conf soon enough to see BB_NUMBER_PARSE_THREADS value there? I still have quite a few processes http://paste.pocoo.org/show/543568/
Jan 31 15:04:47 <kergoth> JaMa: yes. it uses the configuration metadata, the exact same way BB_NUMBER_THREADS does.
Jan 31 15:04:57 <kergoth> it wouldn't be able to parse the recipes if the config metadata hadn't already been parsed, obviously
Jan 31 15:15:23 <kergoth> hmm
Jan 31 15:22:59 <Blok> bluelightning: I just made a really silly mistake :) I had an old file in an archive and incorrectly assumed that files were cached
Jan 31 15:28:24 <bluelightning> Blok: ah ok, no problem
Jan 31 15:28:35 <bluelightning> Blok: I would be more worried if something was broken :)
Jan 31 15:28:59 <Blok> bluelightning: Now everything looks good, I am happy. Thanks again!
Jan 31 15:30:11 <bluelightning> Blok: happy to help :)
Jan 31 15:30:47 <Zagor> Blok: so the "clean" vs -f thing was just a mistake?
Jan 31 15:42:17 <diget> hi there
Jan 31 16:03:41 * zeddii had this window hidden. hmm.
Jan 31 16:46:02 <autif> I want to patch the kernel source before it is built - how do I do this?
Jan 31 16:48:56 <incandescant> autif: we have some documentation for that http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#dev-manual-kernel-appendix
**** BEGIN LOGGING AT Tue Jan 31 17:23:32 2012
Jan 31 17:37:41 <autif1> incandescant - the section (B.1.1) talks about setting up git repositories - I am working off of tarballs - edison 6.0 yocto 1.0
Jan 31 17:37:46 <autif1> still groking though
Jan 31 17:42:20 <incandescant> autif1: I'm not intimately familiar with the documentation but I thought it covered tarballs too
Jan 31 17:50:12 <autif> I have read these twice and I can not find it - there is no section like it
Jan 31 20:35:37 <jlcawood> ok, two things I need modified.
Jan 31 20:35:59 <jlcawood> the cc exp date needs to be in one field and in MMYY format
Jan 31 20:36:36 <jlcawood> and needed to add a country abbreviation selection box
Jan 31 20:37:04 <jlcawood> everything else is completed.
Jan 31 21:55:44 <autif> I have created a new bbappend file - how do I make bitbake pick these changes up - this is a new bbappend file for an existing recipe
Jan 31 21:56:18 <fray> the name has to be the same as the .bb file (pn_pv.bbappend), and it has to exist in a layer that bitbake knows about..
Jan 31 21:56:22 <fray> otherwise it's automatic
Jan 31 21:56:34 <autif> oh, it is in a different layer
Jan 31 21:56:41 <autif> and I want to keep it that way
Jan 31 21:56:42 <fray> I just posted a new layer to git.yoctoproject.org --  look at the meta-selinux layer
Jan 31 21:57:03 <fray> the conf directory matters, and the items in everything but recipes-security are simply small .bbappend fragments
Jan 31 21:59:05 <autif> true - but i have different problem - the recipe.bbappend file seems to be fine or should be fine, but when I bitbake -b path/to/recipe -c clean, bitbake -b path/to/recipe - it does not regenerate pseudo, so bitbake thinks that it can get the recipe from the cache or whatever
Jan 31 21:59:32 <fray> did you change the PR in the bbappend?
Jan 31 21:59:34 <autif> the layer for recipe and recipe.bbappend are different
Jan 31 21:59:38 <autif> yes
Jan 31 21:59:51 <fray> then it's not working if it's reusing the older version
Jan 31 22:00:16 <fray> verify your new layers configuration is correct.. that confused me for a bit when I first made the layer
Jan 31 22:00:18 <autif> hmmmn, is there a way to clean pseudo cache
Jan 31 22:00:32 <fray> bitbake -c cleansstate
Jan 31 22:00:36 <autif> or force it to rebuild
Jan 31 22:00:45 <autif> and this will not clean everything
Jan 31 22:00:46 <autif> right?
Jan 31 22:00:52 <autif> i dont want to wait another 5 hours
Jan 31 22:00:53 <autif> :-)
Jan 31 22:01:02 <fray> clean removes files.. cleansstate runs clean -and- removes the sstate cache files for the package..
Jan 31 22:01:21 <fray> bitbake -c cleansstate <recipe>
Jan 31 22:01:26 <fray> cleans for one recipe
Jan 31 22:01:28 <autif> ah - got it
Jan 31 22:01:32 <autif> thanks fray!
Jan 31 22:01:33 <fray> bitbake -c cleansstate [no recipe] does world
Jan 31 22:01:37 <fray> (I think)
Jan 31 22:01:45 <autif> cool!
Jan 31 22:01:49 <fray> http://git.yoctoproject.org/cgit/cgit.cgi/meta-selinux/tree/conf/layer.conf
Jan 31 22:02:05 <fray> the BBPATH and BBFILES are the critical lines for the bbappend files to be triggered..
Jan 31 22:02:18 <autif> yup - macthes mine - i have working recipes from it - just not bbapend stuff
Jan 31 22:02:28 <fray> BBPATH adds the layers.. bbfiles adds recipes and bbapppends..
Jan 31 22:02:33 <autif> of course instead of _selinux, mine have autif
Jan 31 22:02:34 <fray> you have both the *.bb and *.bbappend?
Jan 31 22:02:37 <fray> yup
Jan 31 22:06:10 <autif> git it - thanks again
Jan 31 22:06:25 <autif> bbappend was misspelled
Jan 31 22:06:28 <autif> that swas it
Jan 31 22:06:35 <autif> picked up the bumped up PR
Jan 31 22:06:40 <autif> thanks fray!
Jan 31 22:06:53 <autif> it would not have struck me to look at conf files
Jan 31 22:06:54 <fray> :)
Jan 31 22:07:02 <fray> ya, it took me a while to find everything as well..
**** ENDING LOGGING AT Wed Feb 01 02:59:57 2012

**** BEGIN LOGGING AT Wed Feb 01 02:59:57 2012
Feb 01 09:59:03 <bluelightning> morning all
Feb 01 10:18:09 <RP__> hi bluelightning
Feb 01 10:21:38 <bluelightning> hi RP__
Feb 01 12:40:45 <abustany> Hello there, using bitbake recipes, how do I get the equivalent of %config in a RPM spec? ie. I would like to mark a file as "configuration file" so that it does not overwrite a local version.
Feb 01 12:48:44 <otavio> RP__: did you see the udev cache patch? does it looks fine?
Feb 01 12:49:36 <otavio> RP__: I will copy 164 onto meta-freescale for now as it lacks kernel newer then 2.6.35 (making it unusable with newer udev) and finish the update to newer udev.
Feb 01 13:21:30 <bluelightning> abustany: I could be wrong, but I'm not sure we currently have a mechanism for that
Feb 01 13:22:11 <RP__> otavio: its looks better, its still many more forks that the rest of the boot process has :(
Feb 01 13:22:58 <RP__> bluelightning, abustany: CONFFILES?
Feb 01 13:23:05 <bluelightning> abustany: actually I tell a lie, for RPM at least we have CONFFILES
Feb 01 13:23:18 <RP__> bluelightning: works for ipk too
Feb 01 13:23:35 <bluelightning> deb has a reference to it, presumably that works too
Feb 01 13:23:41 * bluelightning learns something new :)
Feb 01 13:24:01 <bluelightning> hmm, it's not in our documentation though...
Feb 01 13:28:06 <abustany> bluelightning: yes, I found CONFFILES, thanks :)
Feb 01 13:39:48 <bluelightning> ok, I've emailed Scott R about adding that to the docs
Feb 01 14:49:14 <Crofton|work> must finiah packing
Feb 01 15:37:35 <autif> I added SRC_URI += "file:// …" in my recipe - however, I get en error - Here are the .bbappend and :q
Feb 01 15:37:45 <autif> sorry, this is premature - ignore
Feb 01 15:38:03 <autif> will have a full question with pastebin in a few
Feb 01 15:45:00 <autif> OK, so I am trying to patch the kernel before it is built - based on Bruce Ashfield's answer to my question on the mailing list, I am trying to write a bbappend file with just SRC_URI += "file://..." to patch the kernel - however I get an error - I have tried a few combinations, but nothing seems to work - Here are all the relevant files - http://pastebin.com/DXBiuY35
Feb 01 15:45:31 <autif> The error is Unable to fetch URL file://linux/drivers/hid/hid-core.c.diff
Feb 01 15:48:34 <autif> If I copy the my recipes/linux/linux directory at meta/recipes-kernel/linux/linux - this error does not seem to pop up, however, the patch is not applied
Feb 01 15:48:46 <autif> but that is another story
Feb 01 15:53:40 <kergoth> you have to add the path where the bbappend lives to the file:// search path
Feb 01 15:53:44 <kergoth> grep for FILESEXTRAPATHS
Feb 01 15:54:06 <autif> ah - thats what I was missing
Feb 01 15:54:07 <autif> thanks!
Feb 01 15:55:34 <kergoth> np
Feb 01 16:10:13 <msm> anyone see
Feb 01 16:10:14 <msm> https://gist.github.com/1717755
Feb 01 16:10:33 <msm> its a remaining useradd issue on edison1.1.1
Feb 01 16:11:23 <msm> looking over the recipes its not immeadily obvious why this is an issue
Feb 01 16:11:31 <msm> maybe its a race with another useradd?
Feb 01 16:20:44 <autif> kergoth - I have added files extra paths, bitbake moves further - as in completes the do_fetch and do_patch, however, my .diff files are not copied or applied to the tmp/work/i586/linux-xxx-r3/linux/drivers/hid/hid-ids.h file. what else can I be missing?
Feb 01 16:24:42 <autif> do_fetch just wraps base_do_fetch
Feb 01 16:24:46 <bluelightning> msm: I've seen something similar recently... the problem is anything that reads /etc/group or /etc/passwd might do so at a time when it's being written to
Feb 01 16:25:04 <bluelightning> (by useradd)
Feb 01 16:26:20 <autif> however, do_patch() does not seem to call do_patch_base() - Is this a difference between kernel and non kernel recipes?
Feb 01 16:29:21 <khem> autif: for kernel you should look in kernel.bbclass lot of stuff happens there instead of recipe
Feb 01 16:37:59 <kergoth> ERROR: Bitbake's cached basehash does not match the one we just generated (/scratch/clarson/mel5/qemu/sb-core/recipes/images/devel-image.bb.do_rootfs)
Feb 01 16:38:01 <kergoth> hmm
Feb 01 16:38:08 <msm> bluelightning: hmm, so we need a global useradd lock or osmething?
Feb 01 16:38:12 <kergoth> anyone have a clue what this one is about, before I dive into the bitbake code?
Feb 01 16:38:26 <bluelightning> msm: in theory, but how do you do a lock for every call to getgrnam for example?
Feb 01 16:39:11 <bluelightning> msm: in the case of your error though where a lock is already being taken I think it might be enough if we just retried it enough times until it worked
Feb 01 16:42:09 <msm> bluelightning: alright well ill look closer in a sec
Feb 01 16:43:34 <dvhart> zeddii, I'm using meta-kernel-dev again (been a while actually) and it always rebuilds the kernel, even if I don't change anything
Feb 01 16:43:40 <dvhart> zeddii, have you noticed this?
Feb 01 16:44:28 <dvhart> zeddii, this obviously breaks most iterative workflows
Feb 01 16:44:59 <zeddii> zeddii. doesn't do that here. maybe there's a bitbake variable we need to tweak ?
Feb 01 16:45:30 <dvhart> hrm
Feb 01 16:45:36 <dvhart> no idea what that would be
Feb 01 16:45:37 <zeddii> s/zeddii//
Feb 01 16:45:47 <dvhart> :)
Feb 01 16:45:48 * zeddii is losing it. doing 4 things at once.
Feb 01 16:45:55 <dvhart> talking to yourself in public again
Feb 01 16:46:04 <zeddii> exactly. gotta keep that hush hush
Feb 01 16:46:05 <dvhart> only 4? light work day.
Feb 01 16:48:39 <kergoth> man, I'm trying to single task more, but doing work that involves 1h+ build times makes that a little difficult unless you want to stare at build output
Feb 01 16:48:42 <kergoth> heh
Feb 01 16:48:56 <dvhart> kergoth, so true
Feb 01 18:30:00 <autif> I want to learn more about packages - for example - I want to copy some JPG files in /home/root/pics, when I bitbake my recipe, I get everything in image directory as desired, however, nothing in packages-split/recipe directory. How do I tell the recipe what to put where. Here is my recipe - http://pastebin.com/jJ9hKj0h
Feb 01 18:30:11 <autif> I get WARNING:   /home/root/cardiopics/zion2.jpg
Feb 01 18:30:44 <autif> WARNING: For recipe cardiopics, the following files were installed but not shipped in any package:
Feb 01 18:30:44 <autif> WARNING:   /home/root/cardiopics/zion2.jpg
Feb 01 18:32:52 <kergoth> FILES_<package name> = "list of files or globs to put in this package"
Feb 01 18:33:03 <kergoth> read bitbake.conf for the default list of PACKAGES to emit and FILES that go in them
Feb 01 18:33:25 <kergoth> you really shouldn't be including anything from /home in a package ever, though :)
Feb 01 18:37:04 <autif> kergoth - true - we are still in the phase where we are exploring a lot, eventually this will likely belong in /opt somewhere
Feb 01 18:37:22 <autif> this as you may have guessed is for the app and not for the system
Feb 01 18:37:48 * kergoth nods
Feb 01 18:56:50 <kergoth> autif: FILES_${PN} += "/home" or similar should do it for you, btw
Feb 01 19:04:00 <autif> yup, I did that and it worked - initially I did ${S}/*jpg and that did not work, so I cheated off of some of the recipes in meta, so, not I have /home/root/pics/*.jpg, seems to work, image is bulding
Feb 01 19:04:22 <autif> thanks for the help!
Feb 01 19:04:56 <autif> this was something that I was interrupted for - now back to trying to patch the kernel
Feb 01 20:13:45 <msm> so there seems to be an issue with distutil recipes
Feb 01 20:14:10 <msm> when doing a build, it seems to cache the linker step somehow such that it pulls out ld arguments from sstate-cache from a previous build
Feb 01 20:14:21 <msm> instead of using ones for the current machine
Feb 01 20:14:41 <msm> this has the effect of passing a —sysroot to ld that is incorrect, and consequently it can't find libraries to link against
Feb 01 20:15:54 <msm> soemthing like this fixes it by adding the correct sysroot
Feb 01 20:15:55 <msm> https://gist.github.com/1719059
Feb 01 20:18:20 <incandescant> msm: ick!
Feb 01 20:22:17 <msm> i know nothing about distutils either
Feb 01 20:23:44 <incandescant> it sounds like we need to make some changes to the class to cope better with sstate, I don't know exactly what they'd be though
Feb 01 20:23:50 <incandescant> msm: care to file a bug?
Feb 01 20:24:10 <msm> always export LDFLAGS, CFLAGS, etc would probably fix issues
Feb 01 20:24:38 <msm> this is a 1.1.1 issue too, not sure about master
Feb 01 20:24:46 <msm> so filing a properly bug becomes problematic
Feb 01 20:25:14 * msm sighs
Feb 01 20:25:39 <incandescant> msm: it does? you should be able to file bugs against 1.1
Feb 01 20:25:48 <incandescant> msm: I can file it for you if it's an issue
Feb 01 20:26:37 <msm> im filing against 1.1.1
Feb 01 20:26:41 <msm> not sure if it effects 1.2
Feb 01 20:27:05 <incandescant> thanks
Feb 01 20:31:26 <otavio> incandescant: hi
Feb 01 20:31:38 <incandescant> hi otavio
Feb 01 20:31:41 <otavio> incandescant: i just sent a patch for udev, can you give it a test?
Feb 01 20:32:07 <msm> incandescant: http://bugzilla.yoctoproject.org/show_bug.cgi?id=1948 - let me know if that makes sense
Feb 01 20:32:12 <incandescant> otavio: sure, I'll kick a build off promptly
Feb 01 20:32:15 <otavio> incandescant: it takes into account the changes asked by RP__; i did a test here and seems to work fine
Feb 01 20:33:04 <incandescant> msm: that makes sense, thanks
Feb 01 20:33:22 <incandescant> otavio: gotcha, I'll build and boot test on a board here and let you know
Feb 01 20:33:48 <kergoth> msm: want me to try testing the external toolchain changes against edison? it's never been tested there, we're tracking master at the moment
Feb 01 20:34:45 <otavio> incandescant: good
Feb 01 20:35:01 <otavio> incandescant: i am using a 173 udev locally and now moving to 175
Feb 01 20:37:52 <msm> kergoth: i'd say if you guys want that in our next SDK
Feb 01 20:37:57 <msm> kergoth: =)
Feb 01 20:38:09 <msm> kergoth: im happy to add it if it's working
Feb 01 20:38:15 <msm> i think it benefits all
Feb 01 20:41:53 <kergoth> agreed. wanting to use an external toolchain is quite a common thing. actually, I'd like to take the time to get an external toolchain recipe for crosstool-ng toolchains too one of these days..
Feb 01 20:41:55 <kergoth> heh
Feb 01 20:41:56 <incandescant> otavio: should there be a PR bump?
Feb 01 20:42:13 <otavio> incandescant: indeed
Feb 01 20:42:17 <otavio> incandescant: forgot it
Feb 01 20:42:25 <incandescant> otavio: I do that *every* time...
Feb 01 20:42:34 * incandescant can't wait for auto PR bumps
Feb 01 20:43:10 <otavio> incandescant: mostly in the cases as now that I am playing with that all the time and changing various udev versions
Feb 01 20:43:15 <otavio> incandescant: easy to forget
Feb 01 20:43:21 <otavio> incandescant: me too
Feb 01 23:11:25 <incandescant> otavio: udev builds and boots without error here
Feb 02 00:25:34 <nitink> fray: ping
**** ENDING LOGGING AT Thu Feb 02 02:59:57 2012

**** BEGIN LOGGING AT Thu Feb 02 02:59:58 2012
Feb 02 06:44:16 <Jerry_> hi
Feb 02 07:24:04 <snkt> can anyone help me how to download files from lxr?
Feb 02 08:46:28 <JaMa> kergoth: Hi, after looking at "[PATCH] setup.py: Install concurrent too" I guess that another difference in my setup is that I was using system concurrent and futures, not the version bundled in bitbake (as I'm using setup.py to install bitbake in gentoo)
Feb 02 09:46:03 <bluelightning> hi all
Feb 02 09:59:31 <florian> good morning
Feb 02 12:43:01 <halstead> denix, Mail to you is bouncing again.  [denix.org.		3600	IN	MX	10 denix.no-ip.org.]
Feb 02 15:02:48 <kergoth> JaMa: hmm, that's interesting, will try reproducing that way. what distro?
Feb 02 15:03:55 <JaMa> kergoth: gentoo, but you can use my chroot with it
Feb 02 15:04:49 <kergoth> JaMa: url?
Feb 02 15:05:15 <JaMa> http://git.shr-project.org/git/?p=shr-chroot.git;a=summary
Feb 02 15:05:57 <JaMa> and notice last patch there.. to reproduce it you need to revert this
Feb 02 15:06:09 <kergoth> k
Feb 02 15:07:27 <kergoth> that clone takes a while :)
Feb 02 15:09:15 <JaMa> pushing after rebuild with newer glibc is a lot worse :)
Feb 02 15:11:43 <kergoth> hehe, i bet
Feb 02 15:11:59 <kergoth> also, you know what i really hate about http cloning? no progress bar
Feb 02 15:12:08 <kergoth> the git folks should really look into that if possible :)
Feb 02 15:18:33 <JaMa> kergoth: you should use git:// and depth limited to 2 :)
Feb 02 15:19:09 <kergoth> ah, didn't realize there was a git-daemon running. your gitweb doesn't show it :)
Feb 02 15:19:12 <kergoth> thanks
Feb 02 15:19:44 <JaMa> ah it shows only git+ssh option, but public is enabled too
Feb 02 15:19:46 <kergoth> nope, there isn't, will stick to http, but the depth limit is a great idea :)
Feb 02 15:20:11 <JaMa> http:// doesn't support --depth AFAIK
Feb 02 15:20:16 <kergoth> git:// doesn't work here, does the 'remote end hung up unexpectedly' thing
Feb 02 15:20:18 <JaMa> or didn't when I tried last time
Feb 02 15:20:37 <kergoth> yep, indeed
Feb 02 15:20:38 <JaMa> weird it's used by most users here (our Makefile is using git:// + depth
Feb 02 15:20:45 <kergoth> huh, weird
Feb 02 15:20:48 * kergoth double checks the url
Feb 02 15:20:49 <JaMa> git://git.shr-project.org/shr-chroot.git
Feb 02 15:21:33 <kergoth> oh, right, yeah, i jus trealized that too. realized the repo prefix was only in the web server config :)
Feb 02 15:21:37 <JaMa> unless it died from http:// workload :)
Feb 02 15:21:38 <kergoth> s/repo/'repo'/
Feb 02 15:21:47 <kergoth> thanks again, will try to repro the hang with this
Feb 02 15:23:15 <sgw> kergoth: good morning, any chance you have had a look at the Source Archiver email (on oe-dev list)?
Feb 02 15:25:54 <kergoth> sgw: it looks relatively sane to me, that sort of hook approach was what I was thinking as well. The key bit that I think is missing from this is determination of where in the task graph this occurs. If you just use a funcs type approach, that just runs that series of operations from your task, but it doesn't change where in the build process the task occurs. thoughts?
Feb 02 15:26:13 <kergoth> e.g. after unpack before patch, after patch before configure, ..
Feb 02 15:26:50 <Zagor> what happened to conf/machine/include/tune-ppc440.inc? I see a patch for it in the mailing list archive, but I don't find it in the git repo
Feb 02 15:28:09 * kergoth ponders
Feb 02 15:32:21 <sgw> kergoth: right, I thought I put that timing in there, there's another issue I thought about which is if we want the do_compile/do_install logs/scripts, but not all the build bits, we would need to use an alternate ${S} for the unpack/patch possibly.
Feb 02 15:33:47 <kergoth> yeah, i was thinking that too. maintaining a parallel dir and if needed pulling bits over from ${S}/${WORKDIR} perhaps via task completion events. hmm
Feb 02 15:35:47 <khem> gm
Feb 02 15:36:06 <khem> kergoth: I figured my kmod problem is really a pseudo issue.
Feb 02 15:36:25 <khem> kergoth: pseudo does not wrap opendir() calls
Feb 02 15:36:42 <khem> and kmod does opendir() and then openat()
Feb 02 15:36:48 <sgw> interesting idea, I think that's what RP suggested based on the way sstate works, this would be analogous to but would just capture source,patches,log based on distro requirements.
Feb 02 15:36:51 <khem> and openat() is wrapped
Feb 02 15:38:08 <kergoth> khem: ah! interesting
Feb 02 15:39:15 <kergoth> sgw: in an ideal world, I'd like to see bitbake paying attention to both input *and* output of tasks, not just metadata. so if the metadata for this task changes, but when run it doesn't change its output, the tasks which depend on it would end up being skipped/noexec, or something.. </pipe dream>
Feb 02 15:39:16 <kergoth> heh
Feb 02 15:39:28 <khem> sgw: whats holding up patches some regressions
Feb 02 15:39:56 <khem> kergoth: how do you track output
Feb 02 15:40:03 <khem> its in time
Feb 02 15:40:17 <Zagor> aha, it's in meta-xilinx.
Feb 02 15:40:18 <khem> iow you wont know until after
Feb 02 15:40:36 <khem> fray: around ?
Feb 02 15:41:48 <kergoth> khem: would have to mark up the tasks with the directories they write to, and track their changes with git or similar. non-trivial.
Feb 02 15:44:36 <sgw> kergoth: gotcha.
Feb 02 15:45:16 <kergoth> not directly related, just dreaming :)
Feb 02 15:45:32 <sgw> khem: are you asking about your patches?  I have been a little distracted, and moving slower on patches this week, RP has been working through some.
Feb 02 15:46:21 <Zagor> what is the reason for putting ppc440 under meta-xilinx instead of under meta, like e500 etc?
Feb 02 15:50:43 <Zagor> I'm not complaining, just trying to understand
Feb 02 16:53:04 <autif> I am tuning the ext4 filesystem for faster builds - as described on the wiki - https://wiki.yoctoproject.org/wiki/Build_Performance - I was wondering how to get the information after tuning - is there something like ext4dump command which tells me what the "has_journal" is set to, likewise for barrier, commit etc
Feb 02 16:56:11 <ag> autif: what you want is to check for journal on a ext4 partition
Feb 02 16:56:12 <ag> ?
Feb 02 16:56:26 <autif> I guess
Feb 02 16:56:46 <autif> how do I do this? I am not sure of the command is
Feb 02 16:57:02 <ag> The fastest idea that comes into my mind is dmesg | grep EXT4.
Feb 02 16:57:08 <autif> ah
Feb 02 16:57:10 <autif> will do
Feb 02 16:57:15 <autif> thanks!
Feb 02 16:57:21 <ag> You should see something like: EXT4-fs (dm-3): mounted filesystem without journal
Feb 02 16:57:39 <ag> No prob.
Feb 02 17:01:45 <khem> sgw: I was asking about the fonts issue you had did you find offending patch
Feb 02 17:02:15 <khem> I dont worry about patches going upstream as long as they are out there for someone to try
Feb 02 17:02:28 <khem> beauty of distributed scms
Feb 02 17:12:49 <msm> can anyone suggest a better fix here?
Feb 02 17:12:50 <msm> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=mattsm/edison1.1.1&id=183967bded26ca4d31a65846044fba0bc30096a1
Feb 02 17:13:07 <msm> useradd locks /etc/passwd
Feb 02 17:13:35 <fray> I'd suggest changing useradd/group add to have a locking / retry argument
Feb 02 17:13:51 <fray> this could potentially be a problem during target filesystem installs as well if things become threaded
Feb 02 17:15:13 <msm> fray: add an argument to these bash functions?
Feb 02 17:15:39 <fray> no.. actually modify useradd and groupadd (from shadow-utils) to support a retry option..
Feb 02 17:16:32 <fray> our other --root change was accepted upstream, the shadow maintainer might be interested in a retry option when we let him know we have a multithreaded package creation/install framework that is running into problems..
Feb 02 17:16:54 <fray> we need to either handle the lock/retry outside of the adduser/group calls -- or do it internally.. I prefer centralizing the functionality
Feb 02 17:17:13 <msm> fray: i dont disagree
Feb 02 17:21:33 <khem> fray: got few moments
Feb 02 17:21:45 <khem> fray: I have something lurking in pseudo
Feb 02 17:21:50 <fray> I'm here
Feb 02 17:22:19 <khem> fray: ok. here is problem when kmod/depmod is run under pseudo
Feb 02 17:22:31 <khem> it segfaults pseudo
Feb 02 17:22:37 <khem> and I traced it a bit
Feb 02 17:22:59 <khem> it happens at openat() wrapper
Feb 02 17:23:20 <fray> Hmm.. ok
Feb 02 17:25:14 <seebs> oooh
Feb 02 17:25:19 <seebs> *is summoned*
Feb 02 17:25:23 <fray> ahh you made it here.. ok
Feb 02 17:25:30 <fray> khem, seebs is the maintainer of pseudo..
Feb 02 17:25:36 <fray> he's more likely to know what is doing on then I am
Feb 02 17:25:40 <fray> (at least w/ openat)
Feb 02 17:25:46 <seebs> My static answer:  Must be user error.
Feb 02 17:25:50 <fray> HAHAH
Feb 02 17:26:05 <seebs> ...  What's distressing is how often that's actually turned out to be correct, but I am inclined to think that a segfault is highly suspicious at the least.
Feb 02 17:26:18 <seebs> The *at() stuff isn't as carefully tested probably because it's only used sometimes.
Feb 02 17:27:48 <seebs> So.  1.  What version of pseudo?  ("pseudo -V" should say something like 1.2.)  2.  Do you have a reproducer?  3.  Any hope that you can give me a tiny test program that reproduces?  4.  chroot functionality involved?
Feb 02 17:28:35 <seebs> Oh, and what's the host system?  32/64, x86/something-else, kernel version, etc.?
Feb 02 17:36:46 <khem> seebs: its amd64
Feb 02 17:37:05 <khem> reproducer is there but its a bit large
Feb 02 17:37:15 <seebs> where do I get source for kmod to look at it?
Feb 02 17:38:57 <seebs> Ahh, nevermind.
Feb 02 17:39:02 <seebs> fray found it.
Feb 02 17:39:06 * fray finishes relaying messages?
Feb 02 17:39:08 <seebs> I didn't know dirfd(DIR *) existed.
Feb 02 17:39:30 <seebs> Lemme make you a test patch.
Feb 02 17:40:11 <fray> Hmm, I've never seen that function either.. ;)
Feb 02 17:40:35 <fray> stream -> fd conversion for directories..
Feb 02 17:41:10 <khem> seebs: heh
Feb 02 17:41:58 <khem> I am happy to change to something equivalent that pseudo understands
Feb 02 17:43:29 <khem> hmm posix says
Feb 02 17:43:31 <khem> This interface was introduced because the Base Definitions volume of POSIX.1-2008 does not make public the DIR data structure.
Feb 02 17:44:16 <seebs> Yeah.
Feb 02 17:44:53 <fray> ha..
Feb 02 17:45:07 <khem> its implementation defined if opendir returnd fd somehow you wont need it
Feb 02 17:45:30 <khem> but all we have is glibc
Feb 02 17:48:36 <khem> seebs: I try hard to not make "user errors" :)
Feb 02 17:48:44 <seebs> madness
Feb 02 17:48:59 <seebs> I don't think you're allowed to use pseudo anymore, because I require that users be hilariously incompetent and not make work for me.
Feb 02 17:49:04 <seebs> You aren't in our target demographic, see.
Feb 02 17:49:15 <seebs> Okay, there'll be a delay while the ftp server moves stuff, but
Feb 02 17:49:25 <seebs> ftp://ftp.windriver.com/pub/pseebach/opendir.patch
Feb 02 17:49:33 <seebs> Give it a try.  All I can promise is that it compiled.
Feb 02 17:50:57 <khem> No such file `opendir.patch'
Feb 02 17:51:07 <fray> it can take up to 5 minutes
Feb 02 17:51:12 <khem> oh wow
Feb 02 17:51:19 <khem> can you put it on pastebin.com
Feb 02 17:51:20 <seebs> ?
Feb 02 17:51:22 <khem> thats faster
Feb 02 17:51:22 <fray> we drop it on an internal server, and it's automatically mirrored
Feb 02 17:51:32 <seebs> I probably can, actually.
Feb 02 17:51:38 <khem> you can use patebinit <file>
Feb 02 17:51:46 <khem> its handy cmdline utility
Feb 02 17:51:59 <khem> err pastebinit
Feb 02 17:52:02 <seebs> Neat!
Feb 02 17:52:07 <seebs> That is an awesome tool.
Feb 02 17:52:17 <khem> it is
Feb 02 17:52:41 <seebs> pastebin.com/XgjBA3su
Feb 02 17:52:46 <seebs> It made me do captcha stuff
Feb 02 17:54:22 <nitink> halstead: ping
Feb 02 17:54:40 <halstead> nitink, What's up?
Feb 02 17:54:53 <seebs> ima have breakfast, lemme know whether this helps
Feb 02 17:55:03 <khem> seebs: ok will do
Feb 02 17:55:04 <nitink> halstead: sent you a private email regarding git repository descriptions
Feb 02 17:55:12 * fray hopes dirfd doesn't do anything funky that can allow for the fd to change.. but otherwise the patch looks reasonable ot me
Feb 02 17:55:35 <seebs> if dirfd is that crazy, it DESERVES to segfault
Feb 02 17:55:51 <seebs> I still think it's funny that back when I started I made a dummy "error out with a message" implementation for renameat.
Feb 02 17:56:04 <seebs> Three (?) years later, no one's ever noticed except in code review.
Feb 02 17:56:42 <seebs> this sorta makes me wonder how needed that function really was.
Feb 02 17:56:44 <fray> I think I was the one that noticed?
Feb 02 17:57:03 <seebs> yup
Feb 02 17:57:17 <seebs> also donn during the initial review, i think.
Feb 02 17:57:31 <fray> heh
Feb 02 17:59:18 <khem> ok pseudo compiled with this patch
Feb 02 17:59:21 <khem> btw. I am at 1.2
Feb 02 17:59:29 <fray> seebs promise passed the test..
Feb 02 17:59:36 <halstead> nitink, Done. Is meta-x32 still experimental?
Feb 02 17:59:56 <seebs> Hey, I didn't promise that it WOULD compile, only that it DID.
Feb 02 17:59:57 <fray> nitink, btw I'm about to bring the x32 patch into the main prelink branch..
Feb 02 18:00:01 <seebs> <-- very careful
Feb 02 18:00:04 <khem> lets enable pseudo and off it goes to build image
Feb 02 18:00:13 <nitink> halstead: yes
Feb 02 18:00:14 <khem> I will know in few minutes if it died
Feb 02 18:00:27 <halstead> nitink, Ok. We're set.
Feb 02 18:00:35 <khem> I could test something small but I want to test the same crap
Feb 02 18:00:45 <nitink> fray: good, let me know when you do that then I will take it out from the the x32 layer
Feb 02 18:00:51 <nitink> halstead: thanks !
Feb 02 18:00:58 <seebs> It *should* work.  Heh.
Feb 02 18:01:15 <khem> seebs: are you one of those power programmers
Feb 02 18:01:19 <khem> :)
Feb 02 18:01:35 <khem> oh well the patch looks ok. now that I understand pseudo better than I did yesterday
Feb 02 18:01:49 <fray> will do
Feb 02 18:02:21 <seebs> I'm stereotypical ADHD.  I can do the hard parts, but I still have trouble with stuff like missing semicolons or changing the name I use for a variable from one line to the next.
Feb 02 18:02:26 <seebs> It makes life interesting!  :)
Feb 02 18:02:36 <khem> heh
Feb 02 18:03:03 <khem> I run a languages forus at my work here and 99% problems are user errors
Feb 02 18:03:30 <seebs> That low?  :)
Feb 02 18:03:48 <JaMa|Off> khem: Hi, do you remember my gcc issues after switching machines? the one with unsafe -L from host? here is work-shared diff http://paste.pocoo.org/show/544740/
Feb 02 18:04:17 <JaMa|Off> khem: but doesn't look very interesting except sdk dirs and temp/* changes
Feb 02 18:04:27 <khem> seebs: here is next problem
Feb 02 18:04:29 <khem> renameat
Feb 02 18:04:38 <seebs> ...
Feb 02 18:04:46 <seebs> ...
Feb 02 18:04:48 <seebs> AHHHAHH
Feb 02 18:05:02 <khem> now that opendir is taken care of this is the next pitfall
Feb 02 18:05:35 <seebs> I am amazed.
Feb 02 18:05:44 <seebs> I never thought I'd see renameat used.
Feb 02 18:06:58 <fray> hahahaha
Feb 02 18:07:04 <seebs> Oh, huh.
Feb 02 18:07:05 <fray> you found the first user of renameat
Feb 02 18:07:10 <seebs> So, looking at it.
Feb 02 18:07:22 <fray> I wonder if the author of kmod is trying to use as many obscure apis as possible
Feb 02 18:07:55 <seebs> The changes we had to make to rename() to handle the MAY_UNLINK/DID_UNLINK stuff.
Feb 02 18:08:14 <seebs> Mean that the same implementation could be used for renameat(), I think.  With a couple of tweaks.
Feb 02 18:08:42 <seebs> I could do the thing where rename(a, b) becomes renameat(AT_FDCWD, a, AT_FDCWD, b)
Feb 02 18:09:03 <seebs> khem:  Mind if it takes a few hours to get back to this?  I wanna do it carefully and that requires me to be more awake and less on the phone.
Feb 02 18:11:08 <sgw> khem: back the font patch, the problem was that the image I was creating was using ipk and did not have package-management feature, so it was not running the post-installs correctly on the target.
Feb 02 18:17:30 <khem> seebs: no problem take your time
Feb 02 18:17:44 <khem> sgw: got it
Feb 02 18:22:28 <khem> JaMa|Off: hmmm
Feb 02 18:23:56 <khem> fray: they are not obscure they are newer
Feb 02 18:24:05 <khem> so less used yet
Feb 02 18:24:09 <khem> but effective
Feb 02 18:24:26 <fray> renameat is obscure..
Feb 02 18:24:52 <fray> we've been running with it as an error in pseudo for a couple (3?) years.. and this is the first time it's been triggered
Feb 02 18:25:11 <seebs> Yeah.  dirfd has been around since 4.3BSD, and I never knew about it!  :)
Feb 02 18:25:12 <fray> (dirfd I would say we were previously lucky not to hit)
Feb 02 18:26:05 <seebs> I would argue that until *at() were common, dirfd() was mostly useless.
Feb 02 18:26:15 <fray> ya
Feb 02 18:26:39 <fray> # Your branch and 'origin/master' have diverged,
Feb 02 18:26:39 <fray> # and have 1 and 6853 different commit(s) each, respectively.
Feb 02 18:26:41 <fray> -wow-
Feb 02 18:26:56 <khem> kernel
Feb 02 18:26:58 <khem> ?
Feb 02 18:27:02 <fray> no bloody idea..
Feb 02 18:27:17 <fray> I wonder if I broke the "master" of my poky checkout at some point by accident..
Feb 02 18:27:19 <khem> just rebase it
Feb 02 18:27:27 <fray> I just did.. ;)
Feb 02 18:27:34 <fray> no divergence any longer
Feb 02 18:29:10 <khem> systemd is another exotic piece of software which uses all kind of apis
Feb 02 18:29:25 <khem> even beyond posix
Feb 02 18:33:26 <msm> fray: i think shadow utils already has a lock retry in place
Feb 02 18:33:48 <msm> fray: its just the build machine is so bogged down, its not enough
Feb 02 18:34:03 <fray> Hmm
Feb 02 18:34:40 <msm> fray: there are a few build parameters
Feb 02 18:34:50 <msm> as in if there are other locking mechanisms in place
Feb 02 18:34:53 <msm> it might use those
Feb 02 18:35:00 <fray> Hmm..
Feb 02 18:35:02 <msm> could be an issue with the old linux distro we build on
Feb 02 18:35:10 <fray> RHEL 5? (4?)
Feb 02 18:35:21 <msm> and shadow-native is not getting built with "good defaults"
Feb 02 18:35:37 <msm> CentOS 5.X
Feb 02 18:36:20 <msm> anyone seeing: | cp: cannot stat `/opt/yocto/cache-build/p3060qds/build_p3060qds_release/tmp/sysroots/p3060qds/usr/share/aclocal/gst-element-check-0.10.m4': No such file or directory
Feb 02 18:36:55 <msm> seems like this macro is not packaged properly, and then all the packages that depend on it fail
Feb 02 18:37:01 <msm> its quite rare...
Feb 02 18:37:12 <msm> when building from cache
Feb 02 19:35:47 <denix> halstead|afk: thanks! I think I found the issue - looks like it was a stupid misconfiguration on my end... Will keep an eye on it
Feb 02 19:56:32 <halstead> denix, You're welcome. We don't want you bouncing off of our lists. :)
Feb 02 20:00:38 <otavio> :-)
Feb 02 20:01:50 <denix> :)
Feb 02 20:04:52 <kergoth> CMAKE_AR-NOTFOUND cr libmodman.a  CMakeFiles/modman.dir/module_manager.cpp.o
Feb 02 20:04:55 <kergoth> hmmm
Feb 02 20:31:19 <vhrosale> hello, I'm having an issue with image-core-rt
Feb 02 21:20:22 <seebs> Okay, time to go look at renameat()
Feb 02 21:53:17 <seebs> khem:  http://pastebin.com/iZQC9sX5
Feb 02 21:53:32 <seebs> First pass at renameat.  Haven't tested it, but it compiled and it makes sense to me.  ... that's not much of an endorsement.
Feb 02 21:54:48 <fray> replacing or in addition to the previous patch?
Feb 02 21:56:23 <seebs> In addition to.
Feb 02 22:20:19 <khem> seebs: ok will try it now
Feb 02 22:29:29 <khem> seebs: seems these two patches do the trick on pseudo 1.2
Feb 02 22:29:38 <khem> I am able to build images with kmod now
Feb 02 22:30:08 <seebs> Cool.
Feb 02 22:30:17 <khem> and ......
Feb 02 22:30:18 <seebs> That renameat thing has been lurking forever.
Feb 02 22:30:30 <khem> boots too
Feb 02 22:31:49 <khem> seebs: cool. so will you make 1.3 release soon
Feb 02 22:32:04 <khem> or should we apply these two on top of 1.2 and be happy in oe-core
Feb 02 22:32:08 <seebs> Dunno.  I'm gonna get these changes in for review anyway.  I might call it 1.2.1 or something.
Feb 02 22:32:17 <khem> ok
Feb 02 22:32:31 <khem> I will keep testing them on using various images
Feb 02 22:33:08 <seebs> Thanks.
Feb 02 22:33:25 <khem> I got interesting problem on the side
Feb 02 22:33:49 <khem> is there a way to find if loop device got wrong minor number due to bug in libc mknod
Feb 02 22:34:19 <seebs> I'd say the answer is about 99% likely to be no, because I can't imagine libc mknod being broken in such a way and it only breaking one device.
Feb 02 22:35:00 <khem> seebs: its definitely a libc bug (uclibc that is)
Feb 02 22:35:15 <seebs> Well, okay, I'll believe nearly anything about uclibc.
Feb 02 22:35:16 <khem> since stat on /dev/loop255 works
Feb 02 22:35:27 <khem> but /dev/loop256 return EOVERFLOW
Feb 02 22:35:29 <khem> from kernel
Feb 02 22:35:35 <seebs> hmm
Feb 02 22:35:49 <khem> so I guess stat is not at fault here
Feb 02 22:35:50 <seebs> I don't know what the official ranges are for major and minor numbers.
Feb 02 22:35:57 <khem> its the process of node creation
Feb 02 22:36:41 <khem> since kernel will return something proper if it was not hosed during creation
Feb 02 22:37:00 <seebs> Maybe.  Hmm.
Feb 02 22:37:52 <seebs> I don't actually have a spec handy for what values are reasonable.  A quick check, though, suggests that major and minor are at a higher level than mknod(2).
Feb 02 22:38:02 <seebs> mknod(2) just takes a dev_t.
Feb 02 22:38:19 <khem> yes dev_t is created in a fancy way
Feb 02 22:38:50 <khem> dev_t is usually long long int on arm
Feb 02 22:40:41 <khem> hmmm I guess more pseudo worries since core-image-sato failed
Feb 03 02:06:50 <khem> seebs: here is next culprit
Feb 03 02:07:04 <khem> fstatat
Feb 03 02:07:24 <khem> seebs: it seems now we need *at() wrappers sound
Feb 03 02:10:54 <khem> seebs: kmod uses following at functions openat() unlinkat() fstatat() renaemat()
Feb 03 02:16:00 <seebs> openat, unlinkat, and fstatat should all work, we use all of those.
Feb 03 02:16:15 <seebs> renameat() was the only *at() that we didn't see regularly used on some hosts.
Feb 03 02:18:35 <khem> anyway I see that fstatat is failing now
Feb 03 02:18:54 <seebs> That's... odd.  What are the arguments to it?
Feb 03 02:19:19 <seebs> Historical note:  With the exception of rename/renameat, we do everything through calls to the *at functions.
Feb 03 02:19:35 <seebs> So under the hood, we're treating stat as fstatat(AT_FDCWD, ...)
Feb 03 02:19:41 <seebs> (slightly oversimplified)
Feb 03 02:19:59 <seebs> So we use our wrappers on these even on hosts that don't have them.
Feb 03 02:21:51 <khem>        if (fstatat(dirfd(d), "modules.dep", &st, 0) != 0) {
Feb 03 02:21:51 <khem>                 err = -errno;
Feb 03 02:21:51 <khem>                 ERR("could not fstatat(%s, modules.dep): %m\n", dirname);
Feb 03 02:21:51 <khem>                 closedir(d);
Feb 03 02:21:51 <khem>                 return err;
Feb 03 02:21:53 <khem>         }
Feb 03 02:22:24 <seebs> hmm
Feb 03 02:22:40 <khem> d is DIR*
Feb 03 02:22:55 <seebs> I wonder whether the creation of d is somehow bypassing the opendir() stuff that's supposed to stash the fd for a DIR * when it's opened.
Feb 03 02:23:25 <seebs> That's new -- this is the first time I've ever seen dirfd used, so that code isn't heavily tested.
Feb 03 02:23:52 <seebs> hmmmm
Feb 03 02:23:57 <seebs> Well, there's another possibility.
Feb 03 02:24:18 <seebs> We actually trap _fxstatat, as I recall, because on all the systems we've tested on, fstatat() really calls that.
Feb 03 02:25:31 <seebs> Oh, it's __fxstatat.  Same concept, though.
Feb 03 02:25:32 <khem> DIR *d = opendir(dirname);
Feb 03 02:25:45 <seebs> I guess run with debugging on and see whether pseudo is noticing the calls.
Feb 03 02:26:04 <seebs> In theory, opendir(dirname) should be stashing the path to its associated fd, so fstatat should work.
Feb 03 02:29:43 <seebs> Just a quick dummy program doing nothing but the opendir/fstatat works under pseudo for me.
Feb 03 02:30:55 <khem> ok make a neagtive test
Feb 03 02:31:01 <khem> where the file does not existi
Feb 03 02:31:21 <seebs> Yup, I get ENOENT as expected.
Feb 03 02:31:51 <seebs> If the file doesn't exist, I get a -1 and errno is ENOENT.  Which was passed up from the underlying call, I believe.
Feb 03 02:33:16 <khem> seebs: it says if pathname is absolute then dirfd is ignored . thats from fstatat manpage
Feb 03 02:33:19 <khem> and is my case
Feb 03 02:35:39 <seebs> hmm
Feb 03 02:36:06 <seebs> Yeah, that's what it does.
Feb 03 02:36:31 <seebs> We end up calling pseudo_root_path(__func__, __LINE__, dirfd, path, flags)
Feb 03 02:37:02 <seebs> And that ends up in base_path, which ignores dirfd if path starts with a /.
Feb 03 02:37:55 <seebs> But "modules.dep" isn't an absolute path; I was looking at that case, since that was the code I had seen.
Feb 03 02:39:14 <khem> modules.dep is not yes
Feb 03 02:40:08 <seebs> Anyway, I tried also with an absolute path, and got the expected behaviors.
Feb 03 02:40:31 <seebs> Can you make a self-contained reproducer for the failure?
Feb 03 02:40:35 <khem> hmm ok
Feb 03 02:41:01 <khem> I think right now I only know that it works without pseudo. It could be that pseudo is catching an error in kmod
Feb 03 02:41:05 <khem> who knows
Feb 03 02:41:23 <khem> depmod is called with -F <path to system.map>
Feb 03 02:41:27 <seebs> Possible, but... hmm.
Feb 03 02:41:30 <khem> and system.map does not exist
Feb 03 02:41:48 <seebs> I will say, I've not seen any errors with fstatat as such before.  The opendir stuff was new, but that should work too now.
Feb 03 02:42:00 <khem> ok
Feb 03 02:42:22 <seebs> So if you can make a small test program where fstatat returns a different value under pseudo than not under pseudo, I can look at that.
Feb 03 02:42:35 <khem> yes let me see
Feb 03 02:43:34 <seebs> afk for a bit, but I check on this channel, so I'll see stuff "eventually".
**** ENDING LOGGING AT Fri Feb 03 02:59:57 2012

**** BEGIN LOGGING AT Fri Feb 03 02:59:57 2012
Feb 03 05:51:33 <khem> seebs: ok I think its fdopendir() thats causing pseudo gripes
Feb 03 05:58:08 <seebs> hmm
Feb 03 05:58:19 <khem> seebs: dfd=dirfd(); fd = openat(dfd); subdir = fdopendir(fd);
Feb 03 05:58:22 <seebs> oohhhh
Feb 03 05:58:30 <seebs> hang on.
Feb 03 05:58:51 <seebs> If you do dir = fdopendir(fd), then closedir(dir), does that close fd?
Feb 03 05:59:16 <khem> yes
Feb 03 05:59:20 <seebs> Anyway, if you can assemble a small reproducer, I can try to fix it.
Feb 03 05:59:51 <seebs> That looks like it *should* work.
Feb 03 06:05:23 <khem> seebs: could not fstatat(/home/kraj/work/angstrom/sources/openembedded-core/build/tmp-uclibc/work/qemuarm-oe-linux-uclibceabi/core-image-sato-1.0-r0/rootfs/lib/modules/3.2.2-yocto-standard+, modules.dep): No such file or directory
Feb 03 06:05:36 <khem> but /home/kraj/work/angstrom/sources/openembedded-core/build/tmp-uclibc/work/qemuarm-oe-linux-uclibceabi/core-image-sato-1.0-r0/rootfs/lib/modules/3.2.2-yocto-standard+/modules.dep exists
Feb 03 06:05:56 <khem> and it does not happen without pseudo
Feb 03 06:06:18 <seebs> Any hope you can get a small program that just makes the necessary calls to illustrate that?
Feb 03 06:06:24 <khem> i will try to reduce it but I dont know how successful I will be
Feb 03 06:06:41 <khem> let me try
Feb 03 06:06:47 <khem> and I should just do
Feb 03 06:06:53 <khem> pseudo ./myproh
Feb 03 06:07:00 <khem> and that will run it under pseudo
Feb 03 06:07:09 <seebs> Idle question, any chance that the + is relevant?  I don't think I've ever seen a + on a directory name, and for all I know this triggers a hilarious bug in the path resolution.
Feb 03 06:07:12 <seebs> That should, yeah.
Feb 03 06:07:54 <seebs> And the idea is if you can make a small program that does various opendir, dirfd, fstatat, etc. calls and it fails, then we have something to try to fix.
Feb 03 06:11:12 <khem> ok
Feb 03 06:11:16 <khem> i might have it soon
Feb 03 09:56:20 <ag> Hello.
Feb 03 09:57:02 <ag> I faced a problem today. An upstream SRC_URI - keyutils has a bug: the archive even as it is bz2 file is not compressed.
Feb 03 09:57:27 <ag> And if i want to compile it my build fails with bzip2: /home/agherzan/work/wrs/yocto-adige/2012-02-02-21-53/../downloads/keyutils-1.5.4.tar.bz2 is not a bzip2 file.
Feb 03 09:58:01 <ag> Is there any way i can force or specify to build system that this is not a compressed archive?
Feb 03 09:58:10 <ag> Or the only solution is local file archive?
Feb 03 09:58:20 <ag> local file archive + rename
Feb 03 10:41:02 <jerry_> Hi d4ny, I am Jerry
Feb 03 11:39:56 <otavio> hi there
Feb 03 12:03:37 <ant_work> hi otavio
Feb 03 12:06:43 <otavio> :-)
Feb 03 12:14:54 <ant_work> otavio: about udev cache, it does cause issues on some devices when using meta-oe
Feb 03 12:15:07 <ant_work> why don't make it opt-in ?
Feb 03 12:15:21 <otavio> ant_work: really? what issues?
Feb 03 12:15:50 <ant_work> the root fs is still RO when the script is executed
Feb 03 12:15:56 <otavio> ant_work: i am looking forward to fix all issues and it is opt-in.
Feb 03 12:16:05 <ant_work> maybe because of broken initscripts in meta-oe
Feb 03 12:16:49 <otavio> ant_work: in this case, you might set BAD_RECOMMENDANTIONS and blacklist udev-cache
Feb 03 12:16:51 <dimmu> I am trying to bitbake core-image-minimal I get a error
Feb 03 12:16:52 <ant_work> http://patches.openembedded.org/patch/20103/
Feb 03 12:16:53 <dimmu> ERROR: '/media/work/yocto-prevas/poky-edison-6.0/meta/recipes-core/update-rc.d/update-rc.d_0.7.bb' failed
Feb 03 12:17:04 <dimmu> anyone who has experienced this before?
Feb 03 12:17:52 <ant_work> otavio: with devtmpfs all that device stuff seems crap to me
Feb 03 12:18:29 <otavio> ant_work: I agree; I personally do not use it in my images ... but I didn't want to drop features when updating the udev
Feb 03 12:18:49 <otavio> ant_work: instead of disabling the cache on the default file, we might drop the recommends
Feb 03 12:18:59 <ant_work> well, Koen was the first who suggested to remove the devcache stuff
Feb 03 12:19:03 <ant_work> :)
Feb 03 12:20:22 <otavio> ant_work: http://paste.debian.net/154605/
Feb 03 12:20:29 <otavio> ant_work: see if it works for you
Feb 03 12:22:35 <ant_work> I'll do, thx, still I'm unsure this initial devacche adds value to the oe-core recipe
Feb 03 12:22:56 <otavio> ant_work: I'd like to not drop features at this moment
Feb 03 12:23:11 <otavio> ant_work: we can remove it later if people really do not use it
Feb 03 12:23:38 <otavio> ant_work: but I'd like to make it an upgrade with same features at first
Feb 03 12:23:43 <ant_work> if there are any, they are in meta-oe, not here
Feb 03 12:23:57 <ant_work> (users needing it)
Feb 03 12:24:11 <otavio> ant_work: i am trying to have no udev in meta-oe (except the appends to systemd)
Feb 03 12:24:20 <ant_work> I see, righto
Feb 03 12:24:41 <otavio> ant_work: so better to have it on oe-core and remove later if noone use it
Feb 03 12:24:48 <ant_work> then we'll have only xserver-nodm-init to unify
Feb 03 12:25:13 <ant_work> 'only' means urgently
Feb 03 12:25:33 <otavio> ant_work: yes
Feb 03 12:25:41 <ant_work> nice !
Feb 03 12:26:37 <ant_work> btw, I was looking about xinput-calibrator and wanted to port it to oe-core
Feb 03 12:26:40 <ant_work> but..
Feb 03 12:26:48 <ant_work> I see there are systemd bits in the recipe..
Feb 03 12:26:56 <ant_work> what would yo do?
Feb 03 12:27:02 <ant_work> purge and commit?
Feb 03 12:27:52 <otavio> put it in oe-core and move the systemd bits to a bbappend in meta-oe
Feb 03 12:28:21 <JaMa> ant_work: those are only in my branch no? I don't see any systemd bits in xinput-calibrator
Feb 03 12:28:44 <ant_work> maybe I was looking at you branch, can be...
Feb 03 12:30:01 <ant_work> JaMa: I'm a bit amazed in oe-core kdrive and tslib seem to live and work well ;)
Feb 03 12:30:36 <ant_work> I was under the impression recent kdrive lost that ability
Feb 03 12:31:30 <JaMa> xf86-input-tslib was lost for some time http://git.openembedded.org/meta-openembedded/commit/?id=506d5f781f5ee93e3c9b8ca51a7fb65f40d4a8b8
Feb 03 12:34:41 <JaMa> khem: similar unsafe host libs while building gcc-cross-canadian-arm-4.6.2+svnr181430-r27 http://paste.pocoo.org/show/545133/
Feb 03 12:44:06 <vhrosale> anyone, can you build an image-core-rt with poky 6.0?
Feb 03 12:46:07 <vhrosale> without geting an error fetching the kernel linux-yocto-rt-3.0.4
Feb 03 12:51:33 <d4ny_> Hi All, is there any more detailed documentation on the 'pseudo' project ?
Feb 03 13:20:47 <CcSsNET> hi all
Feb 03 14:42:30 <ag> Saul? Arou you around?
Feb 03 14:42:33 <ag> are*
Feb 03 15:26:27 <RP__> d4ny: It has a good man page which has a lot of info about how to use it
Feb 03 15:26:42 <RP__> ag: You want sgw and he probably isn't up yet
Feb 03 15:27:26 <ag> RP__: I guess.
Feb 03 16:07:08 <sgw> Some one ping me this morning?
Feb 03 16:08:05 <sgw> ag: You rang earlier?
Feb 03 16:18:00 <ag> sgw: Ye si did.
Feb 03 16:18:04 <ag> Yes*
Feb 03 16:18:24 <ag> Saul, I updated js.
Feb 03 16:18:34 <ag> the new package name is js185
Feb 03 16:19:36 <ag> In this way, the library is now named libjs185 bla bla bla. The problem is that web use -js. As a temporary workaround a create a symlink named libjs .so. And things seems to be ok.
Feb 03 16:20:28 <ag> Here is the commit: https://github.com/agherzan/yocto-dev/commit/f6ea44018ace05e47c73920f5db9072f4a6ce28f
Feb 03 16:21:17 <gebi> hi all :)
Feb 03 16:23:22 <sgw> ag: Thank you very much, I will review this and work with RP to merge next week.
Feb 03 16:24:16 <ag> sgw: No problem. One more thing. I resent the patch of Otavo's about dhcp.
Feb 03 16:24:38 <ag> In this way you eon't have to deal any conflicts between these two.
Feb 03 16:25:14 <ag> won't*
Feb 03 16:25:14 <ag> https://github.com/agherzan/yocto-dev/commit/f6ea44018ace05e47c73920f5db9072f4a6ce28f
Feb 03 16:25:21 <kergoth> RP__: thanks for merging the external toolchain bits. think we can get http://lists.linuxtogo.org/pipermail/openembedded-core/2011-December/014432.html in as well? can't build core-image-sato with external without it
Feb 03 16:27:42 <sgw> ag: I saw that also, thanks for the rebase.
Feb 03 16:28:13 <ag> sgw: No problem.
Feb 03 16:29:08 <gebi> any idea why tslib in yocto doesn't work with usbhid touchscreens?
Feb 03 16:32:39 <RP__> kergoth: yes, I'll add that
Feb 03 16:33:24 <RP__> kergoth: its in
Feb 03 16:33:26 <kergoth> k, thanks
Feb 03 16:35:59 <RP__> kergoth: I was already halfway to that, had flagged his email as something to check :)
Feb 03 16:36:33 <kergoth> :)
Feb 03 16:59:41 <ag> I'm out. Have a nice weekend!
Feb 03 17:19:44 <kergoth> this rampant systemd proliferation in meta-oe with no way to disable it is really starting to piss me off. someone needs to explain to koen that meta-oe is generic, not angstrom specific
Feb 03 17:20:01 * kergoth thinks about avoiding that layer entirely
Feb 03 17:22:09 <Jay7> kergoth: you are not alone
Feb 03 17:25:54 <otavio> Can someone help me to identify a dependency loop? it is not clear for me what the error message say's
Feb 03 17:26:36 <incandescant> otavio: I can try
Feb 03 17:26:37 <otavio> http://paste.debian.net/154677/
Feb 03 17:27:52 <incandescant> is that not chicken depending on itself?
Feb 03 17:28:23 <otavio> incandescant: maybe; I just don't see where it is done
Feb 03 17:28:48 <incandescant> otavio: share the recipe? increase the debug level (Pass -D's, more D's = more debugging i.e. -DDDD)
Feb 03 17:29:03 <otavio> https://github.com/OSSystems/meta-chicken/blob/master/recipes-devtools/chicken/chicken_4.7.2.bb
Feb 03 17:31:05 <incandescant> hmm, I don't think I've ever seen BBCLASSEXTEND = "cross" - I wonder if that's buggy?
Feb 03 17:31:53 <otavio> incandescant: heh
Feb 03 17:32:19 <otavio> incandescant: this is the problem ... but not a big deal ... I just copied the cross to the openembedded class dir
Feb 03 17:32:50 <otavio> incandescant: I don't understand why the recipe did not use th class frm the layer
Feb 03 17:35:22 <incandescant> otavio: nor I without diving into it, perhaps you could write a bug report/mailing list post?
Feb 03 17:35:24 <otavio> incandescant: we did it to avoid having duplicated recipes to all
Feb 03 17:36:13 <otavio> incandescant: I talked about having the cross extend merged with RP__ but he had a complain about something .. I don't recall what
Feb 03 17:36:41 <incandescant> hmm
Feb 03 17:38:09 <RP__> otavio: you copied and pasted code that was clearly wrong for a -cross recipe iirc
Feb 03 17:38:13 <darknighte> hey all, anyone seen issues with networking on the qemumips target?
Feb 03 17:38:26 <RP__> otavio: I replied on the mailing list to the patch explaining what the problem was
Feb 03 17:38:46 <otavio> RP__: I found the reply
Feb 03 17:38:51 <RP__> darknighte: no, and the autobuilder would show that up
Feb 03 17:38:54 <otavio> RP__: I am looking at the code now.
Feb 03 17:39:14 <otavio> RP__: can I paste the end result here for you to take a look before sending it to ml?
Feb 03 17:39:18 <darknighte> RP__: hmmm, that's what I thought.  I guess I need to dig a bit deeper.
Feb 03 17:39:28 <RP__> otavio: I'm going to be finished for the say shortly
Feb 03 17:39:36 <RP__> s/say/day/
Feb 03 17:39:43 <otavio> RP__: oh OK
Feb 03 17:39:47 <otavio> RP__: no problem then
Feb 03 18:09:30 <vhrosale> "ERROR: Function 'Fetcher failure for URL: 'git://git.yoctoproject.org/linux-yocto-3.0.git"
Feb 03 18:09:38 <vhrosale> anyone else with this problem?
Feb 03 18:12:18 <paulobear> Hi folks
Feb 03 18:14:03 <paulobear> I'm having some problems with getting boost into my image. I was wondering if someone could provide some insights?
Feb 03 18:53:36 <dvhart> zeddii, tomz1, my sys940x build is failing while trying to merge yocto/emgd-1.10 as it can't find the branch. I checked upstream and it's there. I check the workdir, and it isn't listed, only yocto/emgd is.
Feb 03 18:54:12 <dvhart> zeddii, tomz1, so I expect this is a SRCRV issue of sorts... but I only specify the SRCREV for the yocto/standard/base and meta branches.... so it isn't clear what is required to see yocto/emgd-1.10
Feb 03 18:54:16 <dvhart> any ideas?
Feb 03 18:57:36 <tomz1> dvhart: sounds like the build isn't picking up the updated repo
Feb 03 18:58:10 <tomz1> dvhart: is the old autobuilder bug back?
Feb 03 18:58:41 <paulobear> OK, maybe if I provide more specifics, like dvhart. :) I have created a layer, complete w/images directory, and recipes and added it to bblayers.conf. Bitbake finds everything and doesn't complain (even w/-DDD)
Feb 03 19:00:42 <paulobear> In the image recipe, I have successfully added qt4-embedded to IMAGE_INSTALL, but when I add boost, nothing shows up in the image, nor the SDK. I've had a look at the boost recipe to get some clues (really funny read though! :)) and I've searched the gmane archives for clues as well. What am I doing wrong?
Feb 03 19:00:55 * zeddii reads
Feb 03 19:00:59 <dvhart> tomz1, could be
Feb 03 19:01:08 <zeddii> yah. sounds like autobuilder not feeding the new branches again.
Feb 03 19:01:09 <dvhart> tomz1, I'm also hitting the module ABI version issue
Feb 03 19:01:25 <dvhart> emgd is 8 and server is 11, mouse/keyboard are 11 and server is 13
Feb 03 19:01:29 <dvhart> so server fails to start
Feb 03 19:01:48 <dvhart> I cleaned the xorg-input bits and rebuilt, same failure (that worked last time)
Feb 03 19:01:49 <dvhart> sigh
Feb 03 19:02:29 <dvhart> paulobear, does boost get built?
Feb 03 19:02:41 <dvhart> paulobear, if so, is the image dir in the boost workdir populated?
Feb 03 19:04:36 <paulobear> dvhart: boost does get built, find finds it. I'll check the image dir
Feb 03 19:06:16 <dvhart> did you add boost to IMAGE_INSTALL in the image recipe as well?
Feb 03 19:06:27 <paulobear> dvhart: yes, the image dir has both include and lib dirs, and are populated.
Feb 03 19:06:38 * dvhart notes there have been A LOT of "why doesn't my recipe get installed to my image questions lately
Feb 03 19:07:16 <dvhart> hrm
Feb 03 19:07:49 <paulobear> dvhart: yes, I put it in the image recipe. That recipe is of the type, where a base image is "required" and then I add in the needed packages to the IMAGE_INSTALL.
Feb 03 19:07:52 <dvhart> pidge, poke
Feb 03 19:08:21 <dvhart> pidge, see yocto/emgd-1.10 branch failures with linux-yocto - suspect AB isn't getting the new branches again
Feb 03 19:08:35 <paulobear> dvhart: I've also tried IMAGE_FEATURES, and DEPENDS (now there's a variable that needs renaming! :)) and EXTRA_IMAGE_FEATURES.
Feb 03 19:09:04 <dvhart> paulobear, try POKY_EXTRA_INSTALL += "boost" (or whatever the pkg name is) in your local.conf
Feb 03 19:09:07 <dvhart> and rebuild
Feb 03 19:09:18 <dvhart> that will at least show if the boost recipe is working correctly
Feb 03 19:09:25 <paulobear> ok
Feb 03 19:09:29 <dvhart> then you will need to look at your IMAGE_INSTALL assignments
Feb 03 19:09:34 <dvhart> also, before you do that
Feb 03 19:09:37 <dvhart> send us the output of:
Feb 03 19:09:54 <dvhart> bitbake -e $YOURIMAGE | grep "IMAGE_INSTALL="
Feb 03 19:10:03 <dvhart> pastebin if it's long
Feb 03 19:10:32 <paulobear> dvhart: Add to POKY... and remove from IMAGE_... rebuild. Correct?
Feb 03 19:11:14 <paulobear> dvhart: but send the contents of the bitbake command above first.
Feb 03 19:12:22 <dvhart> don't remove the IMAGE_ settings
Feb 03 19:12:25 <dvhart> just leave them as is
Feb 03 19:12:34 <paulobear> ok
Feb 03 19:12:57 <paulobear> dvhart: running now.
Feb 03 19:17:04 <paulobear> dvhart: these are the lines which are not commented out:
Feb 03 19:17:04 <paulobear> IMAGE_INSTALL="task-core-boot     task-base-extended                            task-core-basic     task-core-lsb      task-qt4e-base boost boost-dev"
Feb 03 19:18:53 <paulobear> that's w/o the POKY_EXTRA_INSTALL set
Feb 03 19:19:15 <dvhart> OK, so boost is listed there, interesting
Feb 03 19:19:42 <dvhart> I suggest trying the POKY_EXTRA_INSTALL bit, then sending the results, including the above experiement, and the image recipe contents to the mailing list.
Feb 03 19:19:48 * dvhart heas to hop in the car
Feb 03 19:20:54 <paulobear> ok, will do
Feb 03 19:21:10 <paulobear> thanks, dvhart
Feb 03 19:28:32 <incandescant> the IMAGE_INSTALL line should be package names, so it's probably libboost?
Feb 03 19:32:05 <dvhart> incandescant, that crossed my mind as well
Feb 03 19:32:25 <dvhart> but the fact that they built made me think otherwise...
Feb 03 20:49:54 <dvhart> zeddii, PING
Feb 03 20:50:02 <dvhart> oops, silly capslock
Feb 03 20:50:19 <dvhart> zeddii, we need a quick fix for the emgd-1.10 issue
Feb 03 20:50:37 <dvhart> zeddii, wondering if we should just push a change to the sys940x.scc to use yocto/emgd
Feb 03 20:50:45 <dvhart> this is what fri2 does still
Feb 03 20:51:01 <dvhart> we can pull them all up to emgd-1.10 together once it works?
Feb 03 20:51:12 <dvhart> tomz1, what has your plan been on this?
Feb 03 20:51:41 <dvhart> pidge, is it possible we just need to refresh the linux-yocto-3.0.git mirror on the mirror?
Feb 03 20:52:22 <tomz1> dvhart: I thought both fri2 and crownbay would be using emgd-1.10
Feb 03 20:52:45 <dvhart> not according to the linux-yocto-3.0.git pull I just did
Feb 03 20:53:05 <dvhart> crownbay has it actually
Feb 03 20:53:18 <dvhart> fri2 does not
Feb 03 20:53:27 <dvhart> and for me, fri2 builds and sys940x does not
Feb 03 20:53:28 <tomz1> dvhart: hmm, did I forget to do that for fri2?
Feb 03 20:53:36 <dvhart> I thought I saw the patch go by
Feb 03 20:53:44 <dvhart> maybe it just got dropped on accident during the push
Feb 03 20:54:03 <dvhart> tomz1, have you successfully built crownbay without meta-kernel-dev?
Feb 03 20:55:05 <dvhart> if I have PREMIRRORS="", then I should be doing a git clone directly to git.yoctoproject.org right?
Feb 03 20:55:31 <tomz1> dvhart: i thought i had, but it looks like it was fri2
Feb 03 20:55:37 <dvhart> doh :)
Feb 03 20:56:00 <tomz1> dvhart: but i think the autobuilder has, lemme check
Feb 03 20:57:05 <dvhart> interesting, I have two linux-yocto.3.0 git dirs in my downloads
Feb 03 20:57:11 <dvhart> one with a .git extension, one without
Feb 03 20:57:19 <dvhart> the one without has 1.10, the one without does not
Feb 03 20:57:28 * dvhart thinks this is the git bug rp found
Feb 03 20:57:34 <dvhart> killing both and trying again
Feb 03 20:58:55 <tomz1> dvhart: hmm, yeah, well crownbay on the ab didn't have the whitelist so failed du to that
Feb 03 20:59:09 <dvhart> It's building now
Feb 03 20:59:15 <dvhart> so I just hit the git alternatives bug
Feb 03 20:59:25 <dvhart> phew, one less thing to deal with
Feb 03 20:59:54 <tomz1> dvhart: anyway, I think changing the merge to emgd-1.10 should fix the fri2, and I'll verify the crownbay indpendently without meta-kernel-dev
Feb 03 21:00:23 <tomz1> dvhart: though i'm curious how my fri2 without meta-kernel-dev built
Feb 03 21:00:29 <dvhart> well the fri2 isn't broken in this regard :)
Feb 03 21:00:36 <dvhart> yocto/emgd still exists
Feb 03 21:00:42 <tomz1> dvhart: well it should be
Feb 03 21:00:47 <dvhart> how so?
Feb 03 21:01:26 <tomz1> dvhart: well, at least the userspace 1.8 is gone, the kernel yeah, would still have merged
Feb 03 21:01:32 <dvhart> ah
Feb 03 21:01:43 <dvhart> ok, that might explain some of the Xorg issues I'm having with the fri2
Feb 03 21:02:21 <tomz1> dvhart: so definitely the 1.10 kernel merge should help, I'll submit a patch to bruce for that
Feb 03 21:02:32 <dvhart> ok, cool
Feb 03 21:02:33 <dvhart> thanks
Feb 03 21:03:00 <tomz1> sure, sorry it somehow slipped through the cracks with the other stuff
Feb 03 21:06:06 <dvhart> I thought I saw it, but not finding it now
Feb 03 21:06:13 <dvhart> the git alternatives were the bigger issue
Feb 03 21:06:47 <dvhart> Bug 1859 is also giving me grief - I'll rebuild that with emgd-1.10
Feb 03 21:12:19 <autif> what recipe will I have to tweak if I also want to create a squashfs image?
Feb 03 21:13:51 <khem> IMAGE_TYPES += "squashfs" in your local.conf
Feb 03 21:13:53 <khem> will do it
Feb 03 21:14:19 <autif> cool, even better
Feb 03 21:14:22 <autif> thanks khem
Feb 03 21:39:38 <khem> libdrm got updated I guess and now it needs open_memstream
Feb 03 21:40:06 <khem> which is not there in uclibc. Its hard to keep adding all so called _GNU_SOURCE extentions
Feb 03 21:43:09 <khem> alright so lets enable UCLIBC_HAS_GLIBC_CUSTOM_STREAMS
Feb 03 21:47:57 <paulobear> dvhart, incandescant: sorry for the delay. 16" of snow needed to be cleared, and lunch as well. :) saw your comments above re: libboost. Trying that now. The POKY_EXTRA_INSTALL did not work, btw.
Feb 03 22:07:04 <paulobear> dvhart: Adding libboost to IMAGE_INSTALL did not do the trick. Will pastebin the recipe and conf. however...
Feb 03 22:07:19 <paulobear> dvhart: do I need boost both as a target on the command line *and* in IMAGE_INSTALL?? I kicked off a build like this: bitbake -k boost, and suddenly all kinds of packages are getting rebuilt. eglibc, linux-libc-header, gcc-cross, binutils-cross.
Feb 03 22:07:28 <ant__> IMAGE_INSTALL_append = " boost "
Feb 03 22:07:39 <ant__> try this
Feb 03 22:08:08 <ant__> or libboost fwiw
Feb 03 22:08:35 <paulobear> hi ant_. sure, will do. willing to try just about anything at this point. :)
Feb 03 22:09:31 <ant__> iirc there is something obscure about boost... :/
Feb 03 22:11:15 <paulobear> ant__: can you please tell me why libboost instead of boost? trying to learn about it...
Feb 03 22:11:42 <ant__> sorry I miss the first part of your conversation...
Feb 03 22:12:00 <ant__> I thought you're trying to force-install  a package
Feb 03 22:12:08 <ant__> or a lib fwiw
Feb 03 22:12:21 <paulobear> ant__: I'm having a hard time getting the boost libs and headers into an image and sdk
Feb 03 22:13:04 <ant__> well, for a normal image what I wrote above will work
Feb 03 22:13:13 <ant__> can't say for the sdk
Feb 03 22:14:31 <paulobear> ant__: I wrote a layer w/images directory and recipes. recipes use the "require ....core-image-lsb-sdk" plus IMAGE_INSTALL += formula. I tried to follow the templates in the manual.
Feb 03 22:16:42 <ant__> which recipe is complaining about boost?
Feb 03 22:18:03 <ant__> btw, I'm grepping and I find that
Feb 03 22:18:08 <ant__> "./recipes-support/boost/boost.inc:# "boost" is a metapackage which pulls in all boost librabries
Feb 03 22:18:08 <ant__> "
Feb 03 22:20:02 <khem> paulobear: you have to differentiate between input recipes which are used to generate output packages
Feb 03 22:20:15 <khem> there could be multiple packages generated from single recipe
Feb 03 22:20:40 <khem> IMAGE_INSTALL variable wants output packages _not_ input recipe names
Feb 03 22:20:53 <ant__> hi khem
Feb 03 22:21:19 <khem> so bitbake -e boost | egrep "^PACKAGES="
Feb 03 22:21:26 <khem> and see what all it generates
Feb 03 22:21:29 <khem> ant__: hello
Feb 03 22:34:49 <paulobear> khem: thanks for the clarification.
Feb 03 22:35:32 <paulobear> khem: will do re: bitbake command
Feb 03 22:40:12 <paulobear> ant__: thanks for the tip re: boost meta package. I didn't catch that. I was looking in the recipe to find the packages, and I only saw the individual boost libs being added as packages.
Feb 03 22:43:26 <paulobear> khem: Oh, I think I see what you're saying, and yes, I have seen that in various recipes. boost recipe creates several "packages." ant__ just clarified that boost itself is a metapackage. So, if I put boost in IMAGE_INSTALL, it should build and install, right?
Feb 03 22:45:31 <khem> paulobear: yes
Feb 03 22:45:45 <khem> paulobear: although make sure that it gets into final IMAGE_INSTALL
Feb 03 22:46:29 <khem> IMAGE_INSTALL_append_pn-<your image name> = " boost" should be safer in local.conf
Feb 03 22:48:09 <ant__> khem: related to this, I seem to lack a simple knob to install kernel + modules on every image. I'd prefer to avoid
Feb 03 22:48:11 <ant__> IMAGE_INSTALL_append = " kernel-base kernel-image "
Feb 03 22:48:19 <ant__> in our machine.conf
Feb 03 22:48:44 <ant__> the point is, e.g. core-image-minimal and opie-image do not run task-base-extended
Feb 03 22:52:34 <khem> ant__: well tasks are defined for this kind of stuff
Feb 03 22:52:49 <ant__> heh
Feb 03 22:53:14 <khem> if you need something extra create a new task
Feb 03 22:53:21 <ant__> so you suggest to touch the images...
Feb 03 22:53:33 <khem> no
Feb 03 22:54:10 <ant__> well, core-image-minimal is inheriting core-base.bbclass so there isn't much to do
Feb 03 22:54:25 <ant__> *core-image.bbclass
Feb 03 22:55:59 <paulobear> khem: dvhart had me do the bitbake -e $MYIMAGE | grep IMAGE_INSTALL, and that showed that boost was in the build.
Feb 03 22:56:20 <paulobear> khem: here's a pastebin of my layer, and conf files: http://pastebin.com/Efxaw9V7
Feb 03 22:57:27 <kergoth> dangit, where'd JaMa disappear to
Feb 03 22:58:25 <paulobear> khem:
Feb 03 22:58:25 <paulobear> (12:17:04 PM) paulobear: dvhart: these are the lines which are not commented out:
Feb 03 22:58:25 <paulobear> (12:17:04 PM) paulobear: IMAGE_INSTALL="task-core-boot     task-base-extended                            task-core-basic     task-core-lsb      task-qt4e-base boost boost-dev"
Feb 03 22:59:06 <ant__> khem: testing  MACHINE_ESSENTIAL_EXTRA_RDEPENDS ?=
Feb 03 23:00:28 <khem> paulobear: ok. So its not building you say ?
Feb 03 23:01:28 <paulobear> I think it's building. It's in work/core2-poky-linux. However, it's not getting into my image, nor the SDK.
Feb 03 23:03:42 <paulobear> khem: more importantly, it's in work/core2-poky-linux/boost-blah/image/user/[include lib]
Feb 03 23:04:24 <khem> paulobear: yes so its built
Feb 03 23:04:36 <khem> paulobear: and it should be packaged into your image too
Feb 03 23:04:51 <khem> if it does not thats a  problem but I dont see why
Feb 03 23:05:04 <khem> I have something like this IMAGE_INSTALL_append_pn-core-image-minimal = " ltp"
Feb 03 23:05:13 <khem> and when I bitbake core-image-minimal
Feb 03 23:05:27 <khem> I get ltp into the final image
Feb 03 23:05:44 <khem> dont know what your problems could be
Feb 03 23:06:32 <paulobear> khem: oh, well, I have nothing like that. Do I need to add that sort of line to my recipe? Adding it to IMAGE_INSTALL isn't sufficient?
Feb 03 23:08:04 <khem> paulobear: you seem to be doing it anyway
Feb 03 23:08:17 <khem> its another form of expression with overrides
Feb 03 23:08:31 <khem> where makes ltp only go into core-image-minimal and not other images
Feb 03 23:08:46 <ant__> urgh.. git.yoctoproject.org[0: 140.211.169.122]: errno=Connection timed out
Feb 03 23:08:55 <paulobear> khem: oic. interesting.
Feb 03 23:09:12 <khem> ant__: there was some downtime planned
Feb 03 23:09:25 <khem> CPU %: 337%
Feb 03 23:09:29 <khem> I like it
Feb 03 23:09:45 <ant__> opkg-utils is failing to fetch here
Feb 03 23:09:54 * paulobear would like a cpu like that. :)
Feb 03 23:10:12 <khem> seebs: on the pseudo end there seems no problem with pseudo but the problem was with kmod which I fixed
Feb 03 23:10:26 <khem> seebs: so now I am able to generate kmod based images
Feb 03 23:10:35 <seebs> HAH!  Back to my usual stance that it's always a user error.
Feb 03 23:10:39 <seebs> :P
Feb 03 23:10:46 <khem> heh
Feb 03 23:11:03 <seebs> Seriously, though, thanks for the excellent bug reports.  And for giving us a real test case for renameat.  :)
Feb 03 23:11:14 <incandescant> ant__: should be back up in 10-20mins, seems to have been fairly short notice downtime
Feb 03 23:11:30 <ant__> already fetched, np
Feb 03 23:11:38 <khem> seebs: np.
Feb 03 23:11:41 <paulobear> khem: If I clean boost, and then re-run my build, then it should build boost from scratch, yes? That would test whether my recipe was building boost?
Feb 03 23:12:05 <khem> paulobear: yes bitbake -ccleansstate boost
Feb 03 23:12:18 <ant__> incandescant: ah, no, now is gone   Unable to fetch URL from any source
Feb 03 23:12:19 <paulobear> khem: yep
Feb 03 23:12:20 <ant__> ;)
Feb 03 23:12:46 <khem> ant__: go fetch yourself some beer and wait till its back up
Feb 03 23:14:09 <khem> seebs: so now I can build for minimal and sato images fine and they boot too
Feb 03 23:14:40 * incandescant looks forward to using kmod
Feb 03 23:15:07 <khem> incandescant: its already on my user branch if you are brave try it out
Feb 03 23:15:25 <ant__> khem: I'm following the kmod stuff too, what about the 'module_autoload' code now?
Feb 03 23:15:26 <khem> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/misc
Feb 03 23:15:40 <incandescant> khem: I may see if I can squeeze a build/test in but my cores are all hot atm
Feb 03 23:16:12 <khem> incandescant: yeah it does have some other patches alongwith but I dont have much time to separate them out
Feb 03 23:16:51 <khem> one that might bite you is task-core-tools: Divide it into 3 recipes
Feb 03 23:17:22 <khem> other are harmless
Feb 03 23:17:39 <incandescant> khem: so I see! rationale seems sane to me :-)
Feb 03 23:18:48 <khem> incandescant: yes it avoids extra build time and space
Feb 03 23:19:21 <paulobear> khem: building my image did not result in boost being built. It jumped right into populating meta-toolchain-sdk, ide-support, & rfs. So I guess therein lies the problem.
Feb 03 23:22:42 <halstead> The network change is complete and service should be restored.
Feb 03 23:22:49 <khem> paulobear: ok
Feb 03 23:22:55 <khem> do this in local.conf
Feb 03 23:23:05 <halstead> pidge, Can you check that the master came up ok?
Feb 03 23:23:20 <khem> IMAGE_INSTALL_append_pn-meta-toolchain-sdk = " boost"
Feb 03 23:23:29 <khem> and retry bitbake meta-toolchain-sdk
Feb 03 23:23:50 <paulobear> khem: ok
Feb 03 23:25:40 <khem> paulobear: well may be meta-toolchain-sdk does not create a target image
Feb 03 23:25:55 <khem> better would be some other image which creates a real target image
Feb 03 23:25:58 <paulobear> khem: yeah, I figured, but it's a good test.
Feb 03 23:26:06 <seebs> khem:  fwiw, the rebased patches for opendir/fstatat/renameat interactions are now in the github pseudo tree.
Feb 03 23:26:17 <khem> seebs: ok.
Feb 03 23:26:37 <khem> I have proposed them for oe-core too
Feb 03 23:26:49 <paulobear> khem: did you have a minute to scan my pastebin? Maybe I'm just taking the wrong approach altogether.
Feb 03 23:27:50 <seebs> I'd prefer to have oe-core or whoever else pick up the merged and cleaned up commit I checked in, one of the people who's better at Python than me (a large set) suggested some cleanup in makewrappers.
Feb 03 23:29:41 <khem> paulobear: are you trying to create SDK and SDK only ?
Feb 03 23:29:55 <paulobear> khem: no. image + SDK
Feb 03 23:31:06 <khem> paulobear: ok and boost you want in your SDK
Feb 03 23:31:42 <paulobear> khem: image based on core-image-lsb. I'm guessing I'll need boost in both? the libs anyway.
Feb 03 23:32:35 <paulobear> *core-image-lsb-sdk
Feb 03 23:38:29 <khem> paulobear: what you are doing seems to be ok
Feb 03 23:39:02 <khem> paulobear: ok add IMAGE_INSTALL_append_pn-phoenix-image-sdk = " boost-dev"
Feb 03 23:39:06 * paulobear is happy to hear that, but not relieved. :)
Feb 03 23:39:11 <khem> and then do bitbake phoenix-image-sdk
Feb 03 23:39:26 <khem> does that pull it in ?
Feb 03 23:39:55 <paulobear> khem: just waiting for the last build to complete.
Feb 03 23:40:25 <paulobear> khem: add the above to local.conf, or recipe?
Feb 03 23:40:40 <khem> local.conf
Feb 03 23:40:55 <paulobear> ok
Feb 03 23:41:34 <paulobear> I've already got the meta-toolchain-sdk override in there as well. So, we'll see how that turns out as well.
Feb 03 23:41:36 <pidge_> ping
Feb 03 23:41:51 <pidge_> gah, wrong window.
Feb 03 23:43:09 <ant__> khem: sigh, systemd sneaking in unwanted :/  http://paste.debian.net/154741/
Feb 03 23:43:36 <ant__> (I removed /systemd to show the culprit)
Feb 03 23:44:38 <ant__> I think JaMA spotted thi sbefore
Feb 03 23:44:52 <khem> yeah I wish it was cleaner
Feb 03 23:45:13 <khem> so you could choose systemd or sysvinit with a snap of finger
Feb 03 23:45:30 <ant__> this systemd experiment should really have been done on a separate layer :/
Feb 03 23:47:17 <ant__> and funny enough can't be fecthed right now ;)
Feb 04 00:06:11 <paulobear> khem: looks like no joy. At least from what's showing up on the build screen. I'll check to see what actually shows up when it's done. But I don't see any build of boost going on.
Feb 04 00:12:16 <ant__> khem: I bisected up to "[oe-commits] Otavio Salvador : systemd.bbclass: depends on systemd"
Feb 04 00:12:18 <khem> :/
Feb 04 00:12:54 <ant__> khem: no issues reverting it
Feb 04 00:12:59 <paulobear> khem: actually, when looking at the stamps, the image is i586-poky-linux, not core2. There are no stamps for boost in i586-poky-linux, and nothing in the work dir either.
Feb 04 00:18:18 <paulobear> well, there's the cleansstate stamps for i586
Feb 04 00:20:59 <ant__> gn
Feb 04 00:25:29 <paulobear> khem: 'DOH! when using IMAGE_INSTALL +=, does one have to put a leading space in the quoted list??
Feb 04 00:35:15 <khem> paulobear no not with += or =+
Feb 04 00:35:22 <khem> only with _append and _prepend
Feb 04 00:35:33 <paulobear> oh, ok, I saw it w/the append.
Feb 04 00:36:14 <paulobear> khem: still no joy. It's 5pm on Friday. I think I'm going to call it a week.
Feb 04 00:37:10 <paulobear> khem, dvhart, incandescent, and ant__: thanks all for being so patient with me.
Feb 04 00:40:37 <khem> enjoy super bowl I guess you are in PST
Feb 04 00:40:53 * paulobear is in MDT :)
Feb 04 00:40:59 <khem> I dont like that sport so much
Feb 04 00:41:09 <khem> I prefer rugby instead
Feb 04 00:43:25 <paulobear> I'm not a big football fan. Played in high school, messed up my knee and shoulders (wrestling contributed to the shoulders mostly). I don't follow it much, but our local team, Denver, has a very charismatic quarterback named Tebow.
Feb 04 00:43:34 * paulobear is a bigger tennis fan. :)
Feb 04 00:43:54 <incandescant> isn't Tebow supposed to be the second coming?
Feb 04 00:44:42 <paulobear> pretty much. He's been very vocal about his religious leanings, and so he tends to kinda lean over and put his elbow on his knee and fist on his forehead. :D
Feb 04 00:45:11 <paulobear> Are we putting ka6sox to sleep? :)
Feb 04 00:45:19 <incandescant> sadly for Denver the power of Christ didn't compel them to the superbowl
Feb 04 00:45:45 <paulobear> heh, incandescant. too true.
Feb 04 00:45:56 <khem> Tebow yeah he is news
Feb 04 00:46:03 <khem> heh
Feb 04 00:46:53 <paulobear> He did a pretty good job keeping them out of the cellar in their division, and getting the Donkeys into the playoffs. Gotta give him is "props" for that. ;)
Feb 04 00:47:54 <paulobear> Alright, time to call it a night. thanks again!
Feb 04 02:35:26 <khem> sgw: around ?
Feb 04 02:50:58 <sgw> khem late for both of us
**** ENDING LOGGING AT Sat Feb 04 02:59:58 2012

**** BEGIN LOGGING AT Sat Feb 04 02:59:58 2012
Feb 04 03:36:10 <khem> sgw: indeed, wanted to know if you picked patches from my pull request then I have updated them with some feedback
Feb 04 03:36:32 <khem> if not done then its fine but if you did then repick them
Feb 04 17:11:58 <paulobear> Hi - are there any toolchain recipe knowledgeable developers available? I have a question about adding a library to a toolchain, any toolchain.
Feb 04 17:29:20 <paulobear> In particular, I am trying to get boost libraries installed into the qte sdk. I have tried adding boost to the RDEPENDS list directly in task-qte-toolchain-target. I saw how the GMAE toolchain used SDK-EXTRAS, so I tried adding that to my local.conf, and to the target toolchain recipes (qte and core both). But nothing has seemed to work so far. Can someone point me in the right direction?
Feb 04 17:29:42 <paulobear> boost is in the image.
Feb 04 17:31:22 <paulobear> I have checked the dependencies using bitbake -g, and it does look like (to my untrained eye) that the toolchain does depend on boost.
Feb 04 18:40:38 <halstead> pidge, The new DNS setup is complete.
Feb 04 18:41:02 <halstead> pidge, Please let me know if all is well for the builders now.
Feb 04 18:53:21 <halstead> E-mail would be best while I'm away or afk.
Feb 04 19:11:58 <khem> paulobear: what is your target image that you are building
Feb 04 19:12:18 <khem> paulobear: add it to RDEPENDS in that recipe
Feb 04 19:12:22 <khem> and see if that works
Feb 04 19:13:08 <khem> SDK-EXTRAS is gmae SDK only thing
Feb 04 19:13:14 <khem> wont work on qt or something
Feb 04 19:13:18 <khem> its a local variable
Feb 04 19:13:23 <paulobear> khem: it's the same we talked about last nite. The phoenix-image-sdk layer. I do have boost in that image now.
Feb 04 19:13:50 <khem> what is your bitbake blah
Feb 04 19:14:36 <paulobear> khem: I tried adding SDK-EXTRAS variable to the meta-toolchain-qte task and/or sub-tasks/recipes to force it. I also tried adding boost and boost-dev to those recipes to force it.
Feb 04 19:15:04 <khem> answer me what i asked first
Feb 04 19:15:10 <khem> lets go step by step
Feb 04 19:17:44 <paulobear> khem: bitbake -k phoenix-image-sdk \
Feb 04 19:17:44 <paulobear>            meta-toolchain-qte meta-ide-support \
Feb 04 19:17:44 <paulobear>            | tee build.log
Feb 04 19:18:05 <khem> wow try one image at a time please
Feb 04 19:18:21 <khem> lets try bitbake phoenix-image-sdk
Feb 04 19:18:32 <paulobear> Oh, well this morning I'm only building this: bitbake -k meta-toolchain-qte
Feb 04 19:18:46 <khem> ok get that -k out of it for a while
Feb 04 19:19:23 <paulobear> The phoenix-image-sdk is building correctly. It has boost in the /usr/include and libs dirs.
Feb 04 19:20:12 <paulobear> ok, I'll drop the -k. Want to die immediately, sure.
Feb 04 19:20:12 <paulobear> So, I'm 1/2 way there, yah? :)
Feb 04 19:21:12 <paulobear> I have been studying the toolchain recipes all morning.
Feb 04 19:23:58 <khem> ok so you want boost in both sdks
Feb 04 19:25:19 <paulobear> No, not really. I have been building both, just to see what happens. My project is only going to be using qte for app development.
Feb 04 19:25:41 <khem> so you want it only in qt sdk
Feb 04 19:25:46 <paulobear> yes
Feb 04 19:25:54 <khem> ok
Feb 04 19:27:42 <paulobear> from what I read in the class recipe, the target sdk gets the dev stuff (includes, libraries), and the nativesdk gets executables. do I read that right?
Feb 04 19:28:10 <khem> sorry kids needed some attention
Feb 04 19:28:27 <paulobear> no worries. I probably need to take my wife to lunch soon. :)
Feb 04 19:28:37 <khem> ok add TOOLCHAIN_TARGET_TASK += "boost-dev"
Feb 04 19:28:43 <khem> to your local.conf
Feb 04 19:28:52 <khem> that should do it for QT SDK
Feb 04 19:32:30 <paulobear> Why didn't it work when I added it directly to the RDEPENDS?
Feb 04 19:33:25 <paulobear> I saw that TTT variable, but thought that if I added boost-dev to the RDEPENDS it would pick it up. Clearly some other foo going on...
Feb 04 19:38:43 <khem> did it work now ?
Feb 04 19:40:08 <khem> it is because sdk populating class overwrites normal depends and expects it to be specified in TOOLCHAIN_TARGET_TASK and TOOLCHAIN_HOST_TASK
Feb 04 19:40:24 <khem> you should checkout my presentation from last ELC
Feb 04 19:40:29 <paulobear> checking...
Feb 04 19:40:49 <paulobear> Oh. Can you post the link?
Feb 04 19:41:09 <khem> dont have it
Feb 04 19:42:37 <paulobear> Nice try, but no ceegar. IIRC, the meta-toolchain-qte uses "=" not "+=" for TTT. GMAE has TT_GMAE_TARGET, which uses += to set, and then it assigns TTGT to TTT.
Feb 04 19:43:21 <khem> ok then it is restrictive of what it wants
Feb 04 19:43:36 <khem> so either you can create a new sdk recipe where you add your stuff on top
Feb 04 19:43:47 <paulobear> whoops
Feb 04 19:44:16 <khem> you can create a patch to let it accept +=
Feb 04 19:44:44 <khem> sdk's are restrictive in what they provide
Feb 04 19:45:55 <khem> so either you can do something like gmae or create your own sdk recipe whih does basically inhrit all qt does + adds boost to it
Feb 04 19:46:06 <paulobear> I was thinking about adding that patch. I was also thinking I could create a recipe in my layer which requires meta-toolchain-qte and adds what I need.
Feb 04 19:46:09 <paulobear> lol
Feb 04 19:46:28 * khem has a crystal ball
Feb 04 19:46:37 <paulobear> I have forced it for now in meta-toolchain-qte to verify.
Feb 04 19:46:57 <paulobear> re: crystal ball -- apparently :)
Feb 04 19:47:21 <khem> alright enjoy your new sdk
Feb 04 19:47:22 <paulobear> ok, I gotta take my wife to lunch. I'll let you know how it goes. thanks!
Feb 04 19:47:29 <khem> i think you now know what to do
Feb 04 19:47:40 <khem> alright enjoy
Feb 04 19:47:47 <paulobear> yup.. it's at least getting clearer.
**** ENDING LOGGING AT Sun Feb 05 02:59:59 2012

**** BEGIN LOGGING AT Sun Feb 05 02:59:59 2012
Feb 05 08:07:55 <mckoan> good morning
Feb 05 08:07:57 <mckoan> greetings from FOSDEM, Bussels - Belgium
**** BEGIN LOGGING AT Sun Feb 05 08:38:10 2012
Feb 05 15:41:38 <ag> CHeers all!
Feb 06 01:31:21 <James> hi,all
**** ENDING LOGGING AT Mon Feb 06 02:59:58 2012

**** BEGIN LOGGING AT Mon Feb 06 02:59:58 2012
Feb 06 08:13:21 <mckoan> good morning
Feb 06 09:21:01 <RP__> morning all
Feb 06 09:51:30 <Zagor> I'd really like to remove the use of absolute paths in bitbake
Feb 06 09:57:15 <CcSsNET> id really like to remove bitbake
Feb 06 09:57:41 <Zagor> hehe
Feb 06 09:58:06 <Zagor> what would you replace it with?
Feb 06 09:58:12 <CcSsNET> then again i havented tried yocto yet
Feb 06 09:58:30 <CcSsNET> only tried bitbake on oe, found it cumbersome
Feb 06 09:59:31 <CcSsNET> Zagor: i currently use sourcemage gnu/linux for just about everything, although i poke around with openwrt, and ttylinux.net buildroot and my own buildscript from scratch (based on lfs)
Feb 06 09:59:33 <CcSsNET> :)
Feb 06 10:00:21 <CcSsNET> http://atccss.net. my website, im going to try yocto soon though for fun anyway. learned about its existance at designcon east 2011 in boston mass
Feb 06 12:16:08 <RP__> CcSsNET: which bit about absolute paths bother you?
Feb 06 12:20:17 <CcSsNET> i didnt mention that. read above more
Feb 06 12:20:45 <CcSsNET> Zagor mentioned that
Feb 06 12:22:55 <Zagor> two things bother me: I can't move my build dir to another place without rebuilding everything. and I can't even fool it by symlinking, since it resolves symlinks and uses the absolute physical path anyway.
Feb 06 12:23:11 <RP__> CcSsNET: sorry, evidently not enough caffeine yet
Feb 06 12:23:16 <CcSsNET> lol
Feb 06 12:24:08 <RP__> Zagor: Hmm, it does that for a reason. The sstate files *are* relocatable though
Feb 06 12:24:14 <Zagor> what is the reason?
Feb 06 12:24:25 <RP__> Zagor: too many of the pieces of software we build encode paths within themselves
Feb 06 12:25:04 <RP__> Zagor: If you build somewhere else with the sstate-cache, you'll get the same effect as relocating but the relocation issues will get handled
Feb 06 12:25:17 <CcSsNET> Zagor maybe you would be interested in helping finish the script i started working on recently: http://atccss.net/projects/build-toolchain.sh
Feb 06 12:25:46 <CcSsNET> my main focus of the script is easy to read based on the KISS principle of coding
Feb 06 12:26:12 <Zagor> CcSsNET: in that case, stick to <80 column lines :)
Feb 06 12:26:19 <CcSsNET> lol
Feb 06 12:26:24 <CcSsNET> O:-)
Feb 06 12:26:44 <CcSsNET> but but. i got 1280x1024 desktop hehe
Feb 06 12:27:54 <Zagor> I have 2560x1600 and still only write 80 column code
Feb 06 12:28:45 <CcSsNET> hmph
Feb 06 12:30:07 <CcSsNET> script currently assumes tarballs are already in a local folder with the script. current bugs are in stage 3,4, and 6. will work on it again soon
Feb 06 12:30:45 <CcSsNET> missing patches and such
Feb 06 12:30:55 <Zagor> I'm not sure what you are trying to do, but my focus is on improving yocto.
Feb 06 12:31:15 <CcSsNET> ah yea. my goal is completely independant so nvm it then
Feb 06 12:31:34 <CcSsNET> i highly dislike bitbake as i stated prior
Feb 06 12:32:42 <Zagor> I think your goal is different from yocto's.
Feb 06 12:32:57 <CcSsNET> not so much :)
Feb 06 12:33:29 <CcSsNET> but i guess my goal is to keep the process of scripting as small as possible for readability sake
Feb 06 12:36:31 <CcSsNET> but i feel this is off topic for yocto. sorry all
Feb 06 12:39:18 <Zagor> RP__: can you give me a few examples of packages behaving like this? do you have a ballpark figure how many they are?
Feb 06 12:40:07 <Zagor> I gues I'm naive but I figured most packages use autoconf which shouldn't depend on location
Feb 06 12:57:56 <RP__> Zagor: Given sstate allows you to relocate and not have to rebuild everything, the thinking is there are bigger issues to solve
Feb 06 12:58:46 <RP__> Zagor: I don't have numbers, I know how nasty the sstate relocation was to fix and that was enough :/
Feb 06 13:15:44 <Zagor> RP__: how is that done in sstate-cache? I see the full path in my .siginfo files
Feb 06 13:44:05 <Zagor> another question: how come in depexp all non-native targets reverse-depend on themselves?
Feb 06 13:52:54 <RP__> Zagor: Those paths are for logging purposes only
Feb 06 13:53:02 <Zagor> aha
Feb 06 13:54:13 <RP__> Zagor: as for the second question, depexp shows collapsed dependencies (i.e. not task based). I suspect its the likes of do_package depends on do_install which depends on do_compile etc
Feb 06 13:54:44 <RP__> Zagor: bitbake X -g and looking at task-depends.dot is the most accurate view, albeit harder to read
Feb 06 13:54:54 <Zagor> ok
Feb 06 14:21:52 <Zagor> if I remove a feature from MACHINE_FEATURES, what do I need to do to make it take effect in the generated rootfs? I removed 'keyboard' but still get /etc/init.d/keymap.sh installed in my root dir.
Feb 06 14:39:15 <bluelightning> Zagor: if you've already built packages or task packages that looked at that feature, changing it after the fact won't force a rebuild of the package
Feb 06 14:50:17 <Zagor> bluelightning: fair enough. but how can I know which packages/tasks are affected by a feature?
Feb 06 14:51:29 <bluelightning> Zagor: probably the easiest way would be to git grep for it... perhaps git grep _FEATURES | grep keyboard
Feb 06 14:52:31 <bluelightning> looks like it'll be task-core-base and task-base
Feb 06 14:53:13 <bluelightning> ideally these kinds of options get set before starting any builds; that's not always possible, but that's the ideal situation
Feb 06 14:54:03 <Zagor> right. in this case I'm learning and exploring, and thus modify iteratively
Feb 06 15:03:45 <mckoan> does anybody knows internal details of hob? http://www.yoctoproject.org/projects/hob
Feb 06 15:04:06 <mckoan> I don't understand how it works, where are sources?
Feb 06 15:05:04 <bluelightning> mckoan: the sources of v1 are within bitbake (lib/bb/ui/..)
Feb 06 15:05:29 <bluelightning> mckoan: v2 is being worked on and is currently available in poky-contrib branches
Feb 06 15:05:44 <mckoan> bluelightning: so it could be considered 'a graphical bitbake' then?
Feb 06 15:06:13 <bluelightning> mckoan: it's a frontend to bitbake, yes, the same logic is used to run the actual builds behind it
Feb 06 15:06:58 <mckoan> bluelightning: hmmmm... interesting thanks. Just what i imagined when I started uding OE in 2007 ;-)
Feb 06 15:56:47 <kergoth`> Hmm, I need to get a clearer picture of the interaction of the UI and the server during a failure / shutdown, to make certain that the UI event queue is being drained
Feb 06 16:06:27 <RP__> kergoth`: I think we handle it pretty badly tbh :(
Feb 06 16:07:40 <RP__> kergoth`: Have you done any profiling of our builds or have ideas on how we could reduce build times?
Feb 06 16:07:45 <kergoth`> I suspect so. we should probably set another variable, and if that var is set and we get None as our event, break instead of continuing. that way it continues until it runs out of work to do
Feb 06 16:07:53 <kergoth`> (in knotty, that is)
Feb 06 16:08:07 <kergoth`> not recently
Feb 06 16:09:16 <RP__> kergoth`: yes, that might be a better way to shut down gracefully although it might not cope with a still alive server which wasn't ready to return any event I guess
Feb 06 16:10:38 <kergoth`> I'd hope our server always shut down, but that's true, we should make absolutely certain
Feb 06 16:14:22 <RP__> kergoth`: Have a think about build time and whether there is anything creative we can do to improve it. Most of the ideas I've had have been implemented now :/
Feb 06 16:14:57 <RP__> kergoth`: I suspect the biggest issue is our correct but long dependency chains
Feb 06 16:16:37 <mckoan> RP__: what about something like a pre-compiled dependency chain?
Feb 06 16:16:54 <RP__> mckoan: like sstate? :)
Feb 06 16:19:00 <mckoan> RP__: i don't know sstate sorry
Feb 06 16:19:44 <RP__> mckoan: sstate is a way of caching things you've build before and reusing them in later builds. There are details on the mailing list and in the manuals about it
Feb 06 16:20:09 <mckoan> https://wiki.yoctoproject.org/wiki/Enable_sstate_cache
Feb 06 16:20:13 <mckoan> I see
Feb 06 16:20:32 <mckoan> sounds like what I said
Feb 06 16:22:06 <mckoan> but I suspect that sstate will re-parse the whole dependency chain
Feb 06 16:22:22 <mckoan> sstate provides a cache mechanism, where sstate files from server can be reused to avoid build from scratc
Feb 06 16:22:49 <mckoan> a pre-compiled dependency chain is something different
Feb 06 16:23:19 <kergoth`> one of these days i'd really like to try building a more full chroot, with more of the -natives already satisfied with sane versions, add them to ASSUME_PROVIDED, and see how that affects the times, but I haven't bothered. and as you say, sstate makes it at least a mostly one time cost
Feb 06 16:23:36 * mckoan apologise for his lack of yocto knowledge but is starting to evaluate its potential just now
Feb 06 16:25:26 <RP__> kergoth`: There is an image target in OE-Core which is a self contained system with all OE's build deps present
Feb 06 17:30:21 <halstead> sgw shall I call you?
Feb 06 17:31:20 <sgw> halstead: on a call right now
Feb 06 17:33:36 <halstead> Okay, ping me when you have spare time.
Feb 06 18:50:29 <ag> Hello.
Feb 06 18:51:00 <ag> I have a strange problem. I'm trying to build a core0image minimal onli with oe-core.
Feb 06 18:51:14 <ag> Everything works ok NOTE: Tasks Summary: Attempted 63 tasks of which 0 didn't need to be rerun and all succeeded.
Feb 06 18:51:24 <ag> After that I see The OE build configuration
Feb 06 18:51:30 <ag> And :
Feb 06 18:51:39 <ag> NOTE: Resolving any missing task queue dependencies NOTE: Preparing runqueue NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks NOTE: Tasks Summary: Attempted 63 tasks of which 63 didn't need to be rerun and all succeeded.
Feb 06 18:51:54 <ag> Here stays for 10-15 minutes and fails with;
Feb 06 18:52:09 <ag> openembedded-core/scripts/bitbake: line 23: /bin/grep: Argument list too long
Feb 06 18:52:50 <ag> openembedded-core/scripts/bitbake: line 33: /usr/bin/python: Argument list too long
Feb 06 18:53:00 <ag> What's wrong?
Feb 06 18:54:17 <fray> scripts/bitbake is a shell script.. it attempts to setup some things for you..
Feb 06 18:54:23 <fray> it sounds like something went wrong in the setup phase..
Feb 06 18:54:45 <fray> run it with bash -x and see if you can figure out what grep went too long
Feb 06 18:55:22 <fray> there is this one:
Feb 06 18:55:24 <fray>  /usr/bin/env python --version 2>&1 | grep "Python 3"
Feb 06 18:55:45 <ag> Yes. I saw the referenced line.
Feb 06 18:55:50 <fray> bitbake -e | grep STAGING_BINDIR_NATIVE=\" | cut -d '=' -f2 | cut -d '"' -f2
Feb 06 18:55:54 <ag> If i run it by hand nothing is returned/
Feb 06 18:55:59 <fray> and that is it..
Feb 06 18:56:26 <fray> the second one I posted you'll need to run from the bitbake/bin directory to avoid the shell wrapper
Feb 06 18:57:00 <fray> but the line 23 is the first grep.. the version check..
Feb 06 18:57:12 <fray> if /usr/bin/env python --version doesn't work.. your system is hosed..
Feb 06 18:57:33 <ag> Python 2.7.2+
Feb 06 18:57:36 <ag> It works.
Feb 06 18:57:38 <fray> Python 2.6.4
Feb 06 18:58:05 <fray> then you need to figure out why it didn't work in your first run due to the error on that line..
Feb 06 18:58:08 <fray> similarly:
Feb 06 18:58:13 <fray> python -c 'import sys; print sys.version_info >= (2,6,0)'
Feb 06 18:58:15 <fray> says it failed as well
Feb 06 18:58:47 <ag> python -c 'import sys; print sys.version_info >= (2,6,0)' True
Feb 06 18:58:53 <ag> Very very strange
Feb 06 18:59:13 <fray> ok.. what in /bin/sh on your system
Feb 06 18:59:21 <fray> since that is the shell being used to run the script?
Feb 06 19:00:22 <ag> bash
Feb 06 19:00:41 <fray> so run bash <path>/scripts/bitbake  and what does it do?
Feb 06 19:01:17 <sgw> ag: Can you resend your updated patches for js and nspr as patches, I am having trouble fetching the git from your machine.
Feb 06 19:02:06 <ag> sqw: yes. Just after i will figure out what is wrong with my build with fray
Feb 06 19:02:24 <ag> fray: nothing
Feb 06 19:02:31 <sgw> ag: Ok thanks
Feb 06 19:02:43 <fray> so run it with bash <path>/scripts/bitbake <target>  does it suddenly work?
Feb 06 19:02:50 <fray> (vs just running bitbake <target>)
Feb 06 19:03:32 <ag> No output.
Feb 06 19:03:54 <fray> run it with bash -x ...
Feb 06 19:04:00 <fray> what is the last thing it does?
Feb 06 19:05:54 <ag> + PSEUDO_DISABLED=1 + {build}tmp-eglibc-eglibc/sysroots/i686-linux/usr/bin/pseudo {path}openembedded-core/scripts/bitbake cassini-image
Feb 06 19:06:04 <ag> And stays here
Feb 06 19:06:20 <fray> your path i messed up.. it's going recursive
Feb 06 19:06:34 <ag> Ye si see...
Feb 06 19:06:36 <ag> yes..
Feb 06 19:06:42 <fray> BITBAKE=`which bitbake`
Feb 06 19:07:00 <fray> OLDPATH=$PATH
Feb 06 19:07:01 <fray> export PATH=`echo $PATH | sed s#[^:]*/scripts:##`
Feb 06 19:07:23 <fray> so either your path has a second case of "Scripts" in it.. or something else that says scripts..
Feb 06 19:07:31 <fray> this may very well be a "real" bug.. but usually the path is:
Feb 06 19:07:58 <ag> No it;s not a bug. I'm trying to setup my scripts
Feb 06 19:07:58 <fray> <path>/scripts:<path>/bitbake/bin/:<rest of path>
Feb 06 19:08:20 <fray> so it should have the poky scripts -first- in the path, os it can be removed easily
Feb 06 19:08:39 <fray> (and prevent you from running anything accidently on the command line other then the bitbake script)
Feb 06 19:08:48 <ag> yes obv
Feb 06 19:08:53 <ag> anyway thank you
Feb 06 19:08:59 <ag> now i know where to look into it
Feb 06 19:09:38 <fray> cool..
Feb 06 19:10:31 <ag> Uh. I didn't know that i'm talking with a wr guy
Feb 06 19:10:39 <ag> :)
Feb 06 19:11:06 <fray> :)
Feb 06 19:11:14 <ag> cheers colleague  !
Feb 06 19:11:29 <ag> back to evening work
Feb 06 19:14:19 <kergoth`> Hmm. staticdev sanity check wants a /.debug/*.a to be in -staticdev, not -dbg
Feb 06 19:14:37 <fray> that's incorrect..
Feb 06 19:14:52 <fray> the debug stuff should be excluded from the -staticdev checking
Feb 06 19:15:43 <fray> (normally though .a isn't extracted for dbg.. or so I though.. maybe I'm forgetting that)
Feb 06 19:15:45 * kergoth` nods
Feb 06 19:16:43 <kergoth`> damnit, I changed a PKGV_<pkg> and it didn't change the sig for do_package_write
Feb 06 19:16:45 * kergoth` adds to todo
Feb 06 19:19:30 <fray> ya, definitely a todo item.. that needs to work
Feb 06 19:20:24 <kergoth`> thought we'd already covered most of our bases on the packaging vardeps, but guess we missed one :)
Feb 06 19:21:28 <fray> yup
Feb 06 20:13:15 <ag> Anybody had any problems in setting collections BBFILE_PRIORITY in oe?
Feb 06 20:13:18 <ag> Anybody had any problems in setting collections BBFILE_PRIORITY in oe?oe-core
Feb 06 20:13:37 <ag> I have a layer with BBFILE_PRIORITY_mine = "6"
Feb 06 20:13:48 <ag> and oe-core has: BBFILE_PRIORITY_normal = "5"
Feb 06 20:14:09 <ag> Whatever package i try it is taken the one from oe-core
Feb 06 20:14:31 <ag> Is there a known bug about this or a missed variable from me.
Feb 06 20:14:32 <ag> ?
Feb 06 20:14:37 <kergoth`> not a known issue, works fine here
Feb 06 20:14:51 <fray> do you have the layer stuff setup properly?  every time I create a new layer I seem to missing something in the setup fils
Feb 06 20:15:21 <fray> (thats really my only peave with the layer mechanism.. it's a pain to setup the first itme)
Feb 06 20:15:29 <fray> http://git.yoctoproject.org/cgit/cgit.cgi/meta-selinux/tree/conf/layer.conf
Feb 06 20:15:40 <kergoth`> speaking of which, we should really improve all the layer.confs in the main layers. some are still using := from before the forced LAYERDIR expansion was in bitbake
Feb 06 20:15:56 <kergoth`> heh
Feb 06 20:15:57 <fray> you need to setup the BBPATH right, BBFILES has to have the right expressions, as well as the others.. which I can't say I even understand well enough to change if they needed it
Feb 06 20:16:04 <ag> all right
Feb 06 20:16:10 <ag> nothing skipped.
Feb 06 20:16:14 <ag> BBPATH
Feb 06 20:16:16 <ag> BBFILES
Feb 06 20:16:22 <kergoth`> 'mine' is in BBFILE_COLLECTIONS?
Feb 06 20:16:23 <ag> COLLECTIONS
Feb 06 20:16:29 <kergoth`> and the BBFILE_PATTERN_mine is correct?
Feb 06 20:16:32 <ag> yes
Feb 06 20:16:42 <kergoth`> well, you're doing something wrong, the only question is where :)
Feb 06 20:16:47 <fray> kergoth` yes we should..  I patterned mine after the examples in Yocto.. but if they're wrong.. they should be fixed and explain why..
Feb 06 20:16:49 <kergoth`> try putting the layer.conf on a pastebin
Feb 06 20:17:07 <fray> ...and that is the other thing, I'd love a way to verify the contents of the layer.conf is "functional"..
Feb 06 20:17:24 <fray> i.e. list the related rcipes /appends found.. that kind of thing.. it would help find incorrect files
Feb 06 20:17:43 <ag> http://pastebin.com/BQD7dJiR
Feb 06 20:18:01 <ag> everything is ok.
Feb 06 20:18:05 <ag> trust me.
Feb 06 20:18:13 <ag> somewhere else is the problem...
Feb 06 20:19:06 <fray> isn't PRIORITY, the lower the number the higher the priority?
Feb 06 20:19:12 <kergoth`> nope
Feb 06 20:19:12 <fray> so if normal is "5".. your stuff will be ignored..
Feb 06 20:19:19 <kergoth`> afaik anyway
Feb 06 20:19:27 <kergoth`> could be wrong, though
Feb 06 20:19:30 <fray> also make sure that, ${LAYERDIR}/recipes-*/*/*.bb ${LAYERDIR}/recipes-*/*/*.bbappend  actually maps to the right recipes
Feb 06 20:20:21 <ag> All bb files and bb append are ok
Feb 06 20:20:29 <ag> and the paths
Feb 06 20:20:39 <fray> then it's likely the priority..  lower the number the higher the priority of the files
Feb 06 20:20:42 <ag> So bigger PRIOROTY is better right?
Feb 06 20:20:50 <fray> 4 is higher priority then 5
Feb 06 20:20:55 <fray> -1 is highest priority?
Feb 06 20:20:56 <ag> Damn
Feb 06 20:21:07 <fray> this is one of those things that isn't well documented
Feb 06 20:21:16 <ag> yes indeed
Feb 06 20:21:18 <fray> (I know it -is- documented, but it's not a FAQ item and probably should be
Feb 06 20:21:32 <ag> Never saw this writtem
Feb 06 20:21:36 <ag> written
Feb 06 20:21:47 <ag> so
Feb 06 20:21:54 <ag> my priority is 4 now
Feb 06 20:22:05 <ag> and still consolekit is from oe-core
Feb 06 20:22:11 <kergoth`> huh, how did I not know about LAYERDEPENDS?
Feb 06 20:22:18 <ag> Tonight it;s not my night...
Feb 06 20:23:13 <fray> I don't think layer depends is actually validated anywhere.. it's just used to help people figure things out
Feb 06 20:23:42 <kergoth`> according to the code in cooker.py, it's used
Feb 06 20:23:59 <kergoth`> further, it adds up the layer priorities of your deps to adjust yours
Feb 06 20:24:09 <fray> huh, didn't realize it was ever enabled.. we talked about it a yer ago
Feb 06 20:24:14 * kergoth` nods
Feb 06 20:24:29 * kergoth` 'll have to try using it and see what blows up
Feb 06 20:24:52 <fray> ya.. I dunno.. this is the confusing stuff for me.. I really don't understand the priority mechanisms in bitbake..
Feb 06 20:24:58 <ag> found it in cooker as well
Feb 06 20:25:07 <fray> it seems to me that it makes more "obvious" sense to follow the priority of the BBLAYERS variable instead..
Feb 06 20:25:19 <fray> first item listed should be highest or lowest priority.. with everything going off of that..
Feb 06 20:25:27 <fray> in the WR build system last item listed is highest priority
Feb 06 20:25:34 <ag> yes
Feb 06 20:25:37 <ag> in LDAT
Feb 06 20:25:40 <fray> (assumption there is with the layers each layer sits on top of each other layer)
Feb 06 20:25:58 <fray> bitbake though has no concept of that.. it just has a list of layers, the priorities are set by the layers and can be overriden by the user..
Feb 06 20:26:03 <fray> I find it very confusing myself
Feb 06 20:26:26 <ag> anyway... right now it's not working at all :)
Feb 06 20:26:39 <fray> the bitbake / oe docs say 6 > 5 in the priority field..
Feb 06 20:26:47 <fray> but I swear last time I tested it, it was the other way around
Feb 06 20:27:05 <ag> hm... not good
Feb 06 20:27:34 <ag> 6 or 4, nothing works
Feb 06 20:27:35 <kergoth`> I agree wrt BBLAYERS, the problem is today the priority of conf/classes is independent of recipes, but whats worse, they're in two different areas of responsibility. one the user, one the layer maintainer
Feb 06 20:28:09 <kergoth`> my old COLLECTIONS implementation handled both via a single priority ordered variable
Feb 06 20:28:12 <kergoth`> heh
Feb 06 20:29:06 <fray> I have no problem with being able to manually select the priority.. it's lack of automatic inheritence for priority that annoys me..
Feb 06 20:32:23 <ag> ERROR: Nothing PROVIDES 'gnome-common' (but {...}openembedded-core/meta/recipes-support/consolekit/consolekit_0.4.5.bb DEPENDS on or otherwise requires it)
Feb 06 20:32:29 <ag> ERROR: gnome-common was skipped: incompatible with license GPLv3
Feb 06 20:32:47 <ag> And i have another one in my layer priority 6.
Feb 06 20:32:57 <ag> where there is no gnime
Feb 06 20:33:00 <ag> gnome*
Feb 06 20:34:24 <fray> ERROR: gnome-common was skipped: incompatible with license GPLv3
Feb 06 20:34:26 <fray> thats the error..
Feb 06 20:34:32 <ag> i know
Feb 06 20:34:34 <fray> you have GPLv3 disabled in your configuration
Feb 06 20:34:38 <fray> so you have no gnome-common package available to you
Feb 06 20:34:45 <ag> but the recipe is taken from ore-core
Feb 06 20:35:14 <fray> the gnome-common .bb file it found was listed as GPLv3.. you have that blacklisted.. so it will ignore it
Feb 06 20:35:26 <ag> I know
Feb 06 20:35:29 <ag> i wrote that code :)
Feb 06 20:35:42 <fray> if you are providing your own that should NOT be ignored.. in your own layer, then something else is happening
Feb 06 20:35:43 <ag> I didn't make this issue clear.
Feb 06 20:35:48 <ag> So.
Feb 06 20:35:52 <ag> I have 2 layers
Feb 06 20:35:57 <ag> both with consolekit
Feb 06 20:36:11 <ag> one with consolekit with depends on gnome
Feb 06 20:36:18 <ag> one with consolekit without depends on gnome
Feb 06 20:36:33 <ag> The one without gnome is in a layer with prority 6
Feb 06 20:36:48 <ag> The one with gnome is in a layer with prority 5 - oe-core
Feb 06 20:36:55 <ag> Clear now?
Feb 06 20:36:59 <fray> run bitbake -s
Feb 06 20:37:08 <fray> that will show you the versions it found and the one its selecting
Feb 06 20:37:27 <fray> are the version numbers -exactly- the same between the two?
Feb 06 20:37:35 <fray> i.e. are they both consolekit_xxxx.bb  ?
Feb 06 20:38:31 <ag> consolekit                                          :0.4.5-r7
Feb 06 20:38:37 <ag> this is from my layer = prority 6
Feb 06 20:38:45 <kergoth`> bitbake-layers may be helpful too
Feb 06 20:38:51 <kergoth`> not sure what all it shows nowadays
Feb 06 20:39:33 <fray> ya, bitbake-layers show-recipes is likely what you want
Feb 06 20:39:48 <ag> let's check
Feb 06 20:39:50 <ag> never used this
Feb 06 20:39:55 <fray> consolekit:
Feb 06 20:39:55 <fray>   meta                 0.4.5
Feb 06 20:39:58 <fray> thats my stock config
Feb 06 20:40:21 <ag> Strange
Feb 06 20:40:28 <ag> wheel i found the problem
Feb 06 20:40:34 <ag> my layer has 0 prority
Feb 06 20:40:45 <ag> even if i have it set in conf
Feb 06 20:40:46 <ag> as 6
Feb 06 20:40:50 <ag> well*
Feb 06 20:45:43 <ag> i realized the problem. I had 2 layers but when creating the last one i forgot to edit _[name of collection]. So i had 2 layers with the same _[name of collection] variables. And from a strange behavior, the rewritten layers ends in 0 priority.
Feb 06 20:45:57 <fray> interesting
Feb 06 20:46:13 <ag> yeah...
Feb 06 20:46:49 <ag> this is not normal... it should be a mechanism of checking these variables somehow
Feb 06 20:47:00 <ag> i will think about his and maybe write some code on this problem
Feb 06 20:49:17 <ag> Thank you chris and mark
Feb 06 20:49:47 <ag> i i learnt some stuff today with you guys
Feb 06 20:49:55 <fray> so did I..
Feb 06 20:50:11 <fray> I'm really surprised higher number is higher priority...  I swear it was the other way around
Feb 06 20:50:41 <ag> Nope.
Feb 06 20:51:11 <ag> It was this way. I used this before. But i went on your hand... as you are MARK H. :)
Feb 06 20:51:28 <fray> ha
Feb 06 20:54:54 <ag> It's 23:00
Feb 06 20:55:44 <ag> and i'm still at work... outside is Apocalypse as my car is stuck into snow. So wish me good luck! And have a great night /day!
Feb 06 20:57:38 <fray> g'night!
Feb 06 20:59:44 <kergoth`> hmm, this article mentions that the verastile express emulation in qemu can go above 256 megs of ram. that could be useful
Feb 06 21:00:01 <kergoth`> anyone seen the texinfo build fail with:  | make[2]: makedoc: Command not found
Feb 06 21:00:06 <kergoth`> I'm guessing a missing dep :)
Feb 06 21:04:53 <fray> sounds like it..
Feb 06 21:04:59 <fray> I havn't seen that before, but it doesn't surprise me
Feb 06 21:12:54 <kergoth`> doc generation tools are a damn nightmare
Feb 06 21:15:28 <fray> I just found a bug in the arch-armv7.inc file
Feb 06 21:15:32 <fray> # VFP Tunes
Feb 06 21:15:32 <fray> AVAILTUNES += "armv7hf armv7thf armv7hf-neon armv7thf-neon
Feb 06 21:15:37 <fray> no trailing '"'
Feb 06 21:16:09 <kergoth`> heh, oops
Feb 06 21:16:16 <fray> I really wish bitbake would catch that instead of treating the first " in the line as a litteral
Feb 06 21:16:18 <kergoth`> we should really just not allow that to happen
Feb 06 21:16:20 <kergoth`> yeah
Feb 06 22:46:57 <RP__> Second time in a week I've seen that causing problems :/
Feb 07 01:09:19 <sgw> khem, you around?  I am getting build failures with the kmod (see: http://pastebin.com/mxnjAnqF)
Feb 07 02:23:35 <khem> sgw: hey
Feb 07 02:25:01 <khem> that pastenbin id is invalid
Feb 07 02:25:07 <khem> sgw: repase
Feb 07 02:47:38 <sgw> khem:  sorry forgot to prove I was human: http://pastebin.com/y1pJ2Yzn
Feb 07 02:48:06 <khem> heh
Feb 07 02:48:32 <khem> sgw: your host does not have docbook-xsl installed
Feb 07 02:49:03 <sgw> Is docbook-xsl a new requirement?
Feb 07 02:50:52 <khem> sgw: for lot of gnome-utils yes
Feb 07 02:51:08 <khem> sgw: We might need it as a -native tool as well I think
Feb 07 02:51:30 <khem> xsltproc and stylesheets
Feb 07 02:52:34 <sgw> We have gnome-utils
Feb 07 02:53:11 <khem> sgw: yeah its on top can you add something like --disable-gtk-doc to EXTRA_OECONF ?
Feb 07 02:53:14 <khem> and see if it helps
Feb 07 02:53:15 <sgw> for fedora, I see we include docbook-style-xsl and others but not on Ubuntu.  Maybe these need to be -natives
Feb 07 02:53:32 <khem> although I hate to disable building docs but this could be a workaround
Feb 07 02:53:53 <sgw> I agree, in the long run we want to increase building docs.
Feb 07 02:54:02 <khem> yes we definitely need to have these tools -native versions
Feb 07 02:54:53 <sgw> I will check meta-oe and oe-classic and then build out recipes if needed.  BTW, thanks for taking a lead on the meta-oe/oe-core thing, it been on the burner for me, but prep for ELC and DevDay has consumed my extra time!
Feb 07 02:55:05 <khem> its nicer to have documents in portable formats so avoiding xsl will not go long
Feb 07 02:55:42 <khem> yes we need to clear up the layers now we are there
Feb 07 02:56:42 <sgw> I think this will be discussed a little at ELC and on the ML in summary form.
Feb 07 02:57:22 <khem> btw. kmod is a hot potato it will take some time for it to settle in so dont propose itf or oe-core yet
Feb 07 02:57:42 <khem> I think I need people to test it out a lot before going upstream
Feb 07 02:57:58 <khem> as I mentioned in my email as well
Feb 07 02:58:17 <sgw> Khem, can you break that out of your pull requests and do the task, uclibc as 2 separate pull requests.
Feb 07 02:59:20 <khem> sgw: drop image.bbclass,kernel.bbclass: Use kmod-native instead of module-init-tools-cross
Feb 07 02:59:26 <khem> module-init-tools: Delete
Feb 07 02:59:34 <khem> kmod: Add recipes
Feb 07 02:59:49 <khem> those three patches are essentially which does the switch
**** ENDING LOGGING AT Tue Feb 07 02:59:58 2012

**** BEGIN LOGGING AT Tue Feb 07 02:59:58 2012
Feb 07 03:00:17 <khem> I could have added virtuals for it to coexist with module-init-tools as a transition time
Feb 07 03:01:08 <khem> so just git rebase --onto <SHA>~1 <SHA>
Feb 07 03:01:19 <khem> will punt them out
Feb 07 03:01:23 <khem> you have to do it three times
Feb 07 03:02:01 <sgw> khem, if you could help me out and create separate requests that would be best, I have to head out now.
Feb 07 03:02:05 <khem> if you prefer it I can rebase the kraj/misc tree so they are not there
Feb 07 03:02:12 <khem> ok
Feb 07 03:02:17 <khem> let me do that in  a min
Feb 07 03:02:22 <khem> then you can head out
Feb 07 03:04:41 <khem> ok the tree kraj/misc is rebased and kmod is gone
Feb 07 03:04:56 <khem> sgw: now it should be ok to repull it
Feb 07 08:28:59 <mckoan> good morning
Feb 07 10:07:26 <bluelightning> morning all
Feb 07 11:40:45 <ag> Hello guys.
Feb 07 11:41:01 <ag> Again i'm into trouble with my oe-core build - core image minimal.
Feb 07 11:41:06 <ag> It's very similar to https://dev.yoctoproject.org/bugzilla-3.6.1/show_bug.cgi?id=1491
Feb 07 11:41:12 <ag> But on db-native package.
Feb 07 11:42:12 <ag> I saw that pseudo i running correctly and i use bitbake from script but still... i'm into this error. Any ideas? I've been looking into this for more than 4 hours... And right now i'm out of ideas.
Feb 07 11:43:50 <ag> ERROR: Task 310 ({oe-core-path}meta/recipes-support/db/db_5.1.19.bb, do_install) failed with exit code '1'
Feb 07 11:43:59 <ag> And above a lot of:
Feb 07 11:45:00 <ag> chown: changing ownership of `{buildpath}/tmp-eglibc-eglibc/work/i686-linux/db-native-5.1.19-r4/image{buildpath}/tmp-eglibc-eglibc/sysroots': Operation not permitted
Feb 07 11:45:27 <ag> This is because in bb we have chwon -R root:root {D}
Feb 07 11:45:34 <ag> chown*
Feb 07 14:17:52 <RP__> ag: Sounds like pseudo isn't working correctly
Feb 07 14:28:07 <ag> RP__: The problem was the chown intercept script. This script is hardcoded in native.class. I moved this script directory for a local project.
Feb 07 14:28:22 <ag> Anyway a symlink solved my problem.
Feb 07 14:28:24 <ag> Thank you.
Feb 07 14:29:03 <RP__> ag: ah, pleased you got it sorted :)
Feb 07 14:59:13 <autif> tomz2 - Fetcher failure for URL: 'file://lib'. Unable to fetch URL file://lib from any source.
Feb 07 14:59:19 <autif> what am I doing wrong?
Feb 07 14:59:36 <autif> I just switched from yocto 1.0 to 1.2 M2
Feb 07 14:59:57 <autif> this is for package emgd-driver-bin-1.8-r8
Feb 07 15:00:29 <autif> It must be 7 am on the west coast - will try the mailing list I guess.
Feb 07 15:17:17 <tomz2> autif: yeah, emgd 1.8 is gone, replaced by 1.10
Feb 07 15:18:12 <autif> ok, so how do i create the image?
Feb 07 15:18:17 <tomz2> autif: I think if you use master instead of 1.2, it should work
Feb 07 15:18:29 <autif> hmmmn
Feb 07 15:20:16 <autif> so, master for meta-intel - right - not yocto M2 - I can mix these two version - keep yocto 1.2 and use master meta-intel - until M3 is released _ i suppose
Feb 07 15:21:40 <tomz2> autif: yeah, meta-intel, but actually 1.2 m2 should still work with 1.8, lemme try here
Feb 07 15:22:56 <tomz2> autif: 1.2m2 does use 1.10, so not sure why you'd be seeing 1.8 errors
Feb 07 15:23:21 <autif> not good - what could I be missing?
Feb 07 15:23:35 <autif> why does bitbake try to compile 1.8 for me instead of 1.10?
Feb 07 15:23:58 <tomz2> autif: that's the question - it shouldn't be
Feb 07 15:26:48 <autif> my steps are what they used to be in 1.0 - . /path/to/poky/oe-init-build-env build, followed bu editing of conf/bblayers.conf - added meta-intel and meta-intel/meta-crownbay, then bitbaked core-image-sato
Feb 07 15:28:22 <autif> I also do ln -s /downloads downloads - so that only new stuff is downloaded from the website(s)
Feb 07 15:28:38 <autif> the /downloads have everything from 1.0 builds
Feb 07 15:28:42 <autif> this should be fine
Feb 07 15:29:00 <tomz2> autif: yeah, there shouldn't be anything left in meta-intel that mentions 1.8
Feb 07 15:30:06 <tomz2> autif: there is the LICENSE_FLAGS_WHITELIST that you now need to do, but that wouldn't explain why it's using 1.8
Feb 07 15:31:14 <autif> hmmmn - where is this license flags whitelist supposed to go and what should it be populated with?
Feb 07 15:32:06 <tomz2> autif: in your local.conf - see the README in meta-crownbay
Feb 07 15:33:19 <tomz2> autif: I'm building 1.2m2 from scratch here, will let you know how it goes
Feb 07 15:34:01 <tomz2> autif: but I'm sure I've done it a couple times and all was well...
Feb 07 15:34:34 <autif> thanks tomz2 - I read the README in meta-crownbay  - there is nothing like WHITELIST there
Feb 07 15:36:41 <tomz2> autif: ah, ok, i'm actually not looking at 1.2m2 then, but master.  Let me try 1.2m2 for real then.
Feb 07 15:37:02 <autif> he he he :-)
Feb 07 15:39:21 <tomz2> autif: so anyway, for 1.8, you did set up the emgd-driver-bin as usual ala the README
Feb 07 15:40:39 <autif> yes, MACHINE = crownbay,
Feb 07 15:41:00 <autif> and adding meta-intel and meta-intel/meta-crownbay on conf/bblayers/conf
Feb 07 15:41:02 <autif> thats it
Feb 07 15:41:04 <autif> nothing else
Feb 07 15:41:05 <autif> right?
Feb 07 15:41:30 <autif> that is all that I get from README
Feb 07 15:42:15 <tomz2> autif: I mean the part where you have to dowload the emgd driver, extract the binaries, put them in the right place in meta-intel, etc.  See 'II. Special notes for building the meta-crownbay BSP layer' in the README
Feb 07 15:42:39 <tomz2> autif: the 1.10 changes get rid of all that, so it might be easier for you to just use master
Feb 07 15:42:40 <autif> hmmn - I have not done that - likely thats what I am missing
Feb 07 15:43:14 <autif> let me get back to you after groking section II
Feb 07 15:43:18 <autif> thanks for all the help!
Feb 07 15:43:44 <tomz2> autif: ok
Feb 07 16:23:40 <autif> Another one - I have a line in my recipe - FILES_${PN} += "${libdir}/libgdiplus.so" - However, in 1.2 aka M2 - I get an error - ERROR: QA Issue: non -dev/-dbg/-nativesdk package contains symlink .so: libgdiplus path '/work/core2-poky-linux/libgdiplus-2.10-r0/packages-split/libgdiplus/usr/lib/libgdiplus.so'
Feb 07 16:23:54 <kergoth`> don't do that
Feb 07 16:24:02 <autif> instead ....
Feb 07 16:24:25 <kergoth`> the real library goes in the main package. the .so symlink is only required when compiling, and is as such placed in -dev
Feb 07 16:24:59 <autif> yes, but libgdiplus is incorrectly written - its library is indeed libgdiplus.so
Feb 07 16:25:47 <autif> sorry - not true - that is required for mono to run properly
Feb 07 16:26:11 <autif> such .NET so libraries are indeed incorrectly written in mono - not libgdiplus as i stated
Feb 07 16:26:24 <autif> so, suppose that I do want this - how do I do it?
Feb 07 16:26:29 <kergoth`> if the library was .so and wasn't a symlink, that QA error wouldn't have occurred
Feb 07 16:26:35 <autif> short of including package libgdiplus-dev
Feb 07 16:26:42 <kergoth`> but fair enough, there are ways to disable the qa checks
Feb 07 16:27:00 * kergoth` doesn't remember the exact variable offhand though, maybe someone else does
Feb 07 16:27:20 <autif> I can grep in the recipes - anything ring a bell?
Feb 07 16:27:44 <kergoth`> you're probably better off checking the classes that do the qa checking
Feb 07 16:27:54 <RP__> autif: INSANE_SKIP
Feb 07 16:28:09 <kergoth`> ah, right, thats the one :)
Feb 07 16:28:14 <kergoth`> thanks
Feb 07 16:29:18 <kergoth`> that reminds me, i set INSANE_SKIP_<pkg> on some packages in the external toolchain recipe, yet it still whines about GNU_HASH. wonder if i typoed them or something
Feb 07 16:29:20 * kergoth` digs
Feb 07 16:42:01 <kergoth`> haha
Feb 07 16:42:18 <kergoth`> RP__: if I make knotty drain the events after it exits its loop, I can't reproduce the parse error hang anymore
Feb 07 16:42:34 <kergoth`> my suspicion may well have been accurate
Feb 07 16:42:37 * kergoth` digs further
Feb 07 16:42:45 <RP__> kergoth`: which one, the original or the new one?
Feb 07 16:45:05 <ag> sgw: About your last email with Signed-off mesages.
Feb 07 16:45:08 <ag> messages
Feb 07 16:45:23 <ag> I will recommit with signed-off in my patch but should i add signed-off to patches that were applying as they are from the last version?
Feb 07 16:45:43 <ag> I mean all i changed was that lcrypt in LIBS.
Feb 07 16:45:54 <ag> And i will modify the header of that patch.
Feb 07 16:45:58 <kergoth`> RP__: actually, this is testing with the homerolled process pool i tried to use to fix the cancellation issue without futures, will test the others too
Feb 07 16:50:31 <sgw> ag: if you made changes to the patches then add your signed-off-by, if they are from before then you do not need to add SOB
Feb 07 16:59:22 <ag> sgw: ok
Feb 07 17:07:46 <kergoth`> I can't help but wonder.. does anyone ever ^C bitbake without then ^C'ing it further to get out right away? It seems like the cases where I want to be patient are few and far between, especially given re-running the task doesn't always result in redoing all its work over again
Feb 07 17:08:50 <bluelightning> kergoth`: I do occasionally
Feb 07 17:09:17 <bluelightning> kergoth`: usually when I'm stopping it because it's making my machine too slow and I plan to resume it later
Feb 07 17:09:55 <bluelightning> lots of people wouldn't be patient enough for that though
Feb 07 17:09:57 <kergoth`> I'm just wondering about the value it adds. Most of the time a user expects their software to respond immediately, or close to it, and re-running part of a task rarely causes any sort of problem
Feb 07 17:10:08 <bluelightning> especially if you do it in the middle of eglibc do_package for example :/
Feb 07 17:11:02 <kergoth`> heh, yeah, thats one of the ones that hurts
Feb 07 17:12:02 <kergoth`> most of the time i just end up hammering on ^C until it stops, I wonder what others users do. maybe I should do a poll or something
Feb 07 17:17:01 <autif> kergoth`, RP__ - Another one - ERROR: QA Issue: Architecture did not match (3 to 62) on /work/core2-poky-linux/mono-2.10.8.1-r0/packages-split/mono/usr/lib/mono/2.0/mcs.exe.so - INSANE_SKIP_${PN} = "dev-so" does not seem to help
Feb 07 17:28:02 <RP__> autif: but arch in there might?
Feb 07 17:29:46 <autif> RP__: I did not understand that
Feb 07 17:30:17 <kergoth`> autif: dev-so is the check for .so symlinks not in -dev packages. you didn't tell it to skip the architecture check
Feb 07 17:31:02 <autif> ah, INSANE_SKIP_${PN} = "dev-so arch"
Feb 07 17:34:52 <autif> OMG, I still have another QA error - ERROR: QA Issue: non debug package contains .debug directory - whats the magic for that? grep did not reveal anything in existing recipes - o I could read the code where packaging is done - where is that?
Feb 07 17:35:06 <kergoth`> bitbake.conf
Feb 07 17:35:11 <kergoth`> meta/conf/bitbake.conf
Feb 07 17:35:26 <kergoth`> this is the main configuration file, it includes all the others, including local.conf
Feb 07 17:37:57 <autif> it does not seem to list either "arch" or "dev-so" - where are those checked?
Feb 07 17:38:11 <kergoth`> insane.bbclass is what does the checks
Feb 07 17:38:12 <autif> what would it be for nondebug?
Feb 07 17:38:17 <autif> ah
Feb 07 17:38:29 <kergoth`> .debug directories belong in -dbg packages. this isn't something you should override, its something you should fix in your FILES variables
Feb 07 17:40:41 <autif> i considered this - it seems like these files are manually copied from another source - I will weed thru that another time (really, I will :-), however for now, I just want to move on to M2 to debug my kernel issues
Feb 07 17:41:03 * kergoth` nods
Feb 07 17:41:07 <autif> so, for now, I just want to override
Feb 07 17:41:44 <autif> magic keyword seems to be "debug-files"
Feb 07 17:42:02 <autif> thanks for the help kergoth`
Feb 07 17:43:20 <kergoth`> np
Feb 07 17:49:59 <kergoth`> RP__: that prototype task status footer you did for knotty was rather nice, but I think we'd need some sort of separator or background/foreground color difference to keep it visually separate from the rest of the output
Feb 07 17:50:36 <kergoth`> RP__: it felt slightly cluttered and the eye didn't quickly spot the deliniation, for me anyway, but the value was definitely there, I think
Feb 07 17:52:25 <RP__> kergoth`: Agreed, I think its the right thing to do but didn't merge it yet as it didn't seem 100% right
Feb 07 17:52:43 <RP__> kergoth`: There is at least one case it gets confused somehow with the linenumbers
Feb 07 17:53:08 <RP__> kergoth`: With 30 processes running it also makes me feel ill with the refreshed
Feb 07 17:53:11 <RP__> refreshes
Feb 07 17:57:25 <RP__> kergoth`: I just need some time to spend on it but colour difference would be a good way to show the user what was happening
Feb 07 18:06:08 <ag> Isn't true that all static libraries should go in -staticdev/ ?
Feb 07 18:06:24 <ag> ${PN}-staticde
Feb 07 18:06:26 <ag> ${PN}-staticdev
Feb 07 18:14:52 <kergoth`> RP__, JaMa: okay, https://github.com/kergoth/bitbake/compare/hang-issue-fix seems to fix both issues. I'd like JaMa to verify this since he seems to hit the non-failure hang more often than most. Also, I think I can probably kill the Feeder process here, I'll look into that next to simplify, but this does seem to resolve both issues relatively cleanly
Feb 07 18:17:06 <kergoth`> i tested both forms of interruption (one ^C, two ^C's), a single task failing, setVar2 in sstate.bbclass, and a parse error in a single recipe. ran 100+ parses without issues so far
Feb 07 18:17:27 <kergoth`> and of course verified that building to completion seems to work fine as well
Feb 07 18:18:21 * kergoth` kicks off a few more builds with it
Feb 07 18:19:53 <sgw> ag: yes, for the most part static libraries go into -staticdev
Feb 07 18:20:37 <sgw> ag: I have been doing some further review of the js upgrade and I am trying to understand why you removed all the patches?  This might partly explain why you are having trouble with the internal nspr.
Feb 07 18:26:40 <ag> sgw: configure.ac: i use configure from package
Feb 07 18:27:00 <ag> jsautocfg.h Didn't complain about it.
Feb 07 18:31:05 <ag> buildcc.patch jskwgen is compiled for host ok.
Feb 07 18:31:17 <ag> file host_jskwgen host_jskwgen: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, not stripped
Feb 07 18:35:42 <ag> About usepic.patch and link_with_gcc.patch... i think they should be back...
Feb 07 18:36:06 <ag> Can;t remember why i removed them. Maybe in my struggle to make nspr compile
Feb 07 18:36:31 <ag> And after that, after seeing that evering compiles without them, i kept them removed.
Feb 07 18:36:50 <ag> everything*
Feb 07 18:38:51 <sgw> ag: sorry got called away
Feb 07 18:39:31 <ag> No problem
Feb 07 18:39:51 <ag> Let me check once more to compile intenal nspr with those patches
Feb 07 18:39:51 <sgw> ag:  for configure.ac you should compare what is different, there are probably some setting in there that are needed to make it build correctly.
Feb 07 18:40:58 <sgw> ag: thanks, its always important to look at those difference, that's one of the reasons we want to have accurate Upstream-Status info, so we now if the patch is there because of a bug or configuration stuff.
Feb 07 18:41:52 <ag> but actually the package is ok without all these packages and configure stuff
Feb 07 18:43:28 <ag> The fpic patch is for MIps.
Feb 07 18:43:42 <ag> There is a log and description in the patch
Feb 07 18:43:54 <ag> But the other one is blown away
Feb 07 18:44:40 <ag> Anyway. Gimme some time to check again for nspr.
Feb 07 18:44:47 <ag> sgw: Anyway. Gimme some time to check again for nspr.
Feb 07 18:45:25 <sgw> ag: Ok, I will hold on the js and nspr patches, I am looking at the dhcp one again.
Feb 07 18:49:15 <sgw> ag: for the dhcp patch, I just noticed that those where not git renames, did you use "git mv" to rename the files?  That would be better to prerve the history.
Feb 07 18:50:22 <ag> sgw: my bad. Won't happen again. Do you want to resubmit it?
Feb 07 18:50:34 <sgw> ag: Yes please
Feb 07 18:50:45 <ag> SOmt hing else/
Feb 07 18:50:53 <ag> Something else/
Feb 07 18:50:57 <ag> Something else?
Feb 07 18:51:25 <ag> (hard to work with this new Dell keyboard)
Feb 07 18:52:00 <sgw> ag: I hope not, I look at all patches a number of times from different angles and at different points in the process, I am sorry I don't always find all the issues first thing.
Feb 07 18:52:25 <ag> sgw: no problem. In the first place is my fault.
Feb 07 19:04:33 <ag> sgw: about js i think the only solution is with external nspr. i cannot find any nspr code internally. "By default, ./configure will use the nspr-config program, installed as part of NSPR, to find the appropriate way to include and link to NSPR." I will resend the link_with_gcc.patch and usepic.patch patches
Feb 07 19:07:06 <ag> "link_with_gcc.patch and usepic.patch patches" modified to match the new version
Feb 07 19:18:37 <ag> sgw: what do you say? Do you have an arm build? would you please test js on it? If you have time...
Feb 07 19:19:09 <otavio> sgw: did you see my dhcp patch?
Feb 07 19:20:19 <sgw> otavio: ag: you both have dhcp patches that need a merge, Can I get a coordinated change set please.
Feb 07 19:20:54 <otavio> sgw: for me, it seems logical for him to add mine in his tree and send both
Feb 07 19:21:01 <otavio> ag: works for you?
Feb 07 19:21:01 <ag> I already rebased otavio's
Feb 07 19:21:09 <otavio> ag: i did changes on it
Feb 07 19:21:15 <ag> uh...
Feb 07 19:21:16 <otavio> ag: check current one if you did
Feb 07 19:21:17 <sgw> ag: I have all arches in various states, I will have to look at the JS patch more closely, RP__ mentioned that he did  the orignal recipe and may have some insights.
Feb 07 19:21:31 <otavio> ag: it has an if on the post scripts
Feb 07 19:21:52 <ag> yeah. i will send yours as well.
Feb 07 19:24:04 <otavio> ag: please take a look on it and if you have any problem ping me
Feb 07 19:25:23 <ag> otavio: 10 minutes and
Feb 07 19:25:37 <ag> otavio: 10 minutes and i will send your patch with mine
Feb 07 19:27:10 <otavio> ag: cool
Feb 07 19:27:49 <sgw> ag: great
Feb 07 19:28:21 <incandescant> otavio: hey!
Feb 07 19:28:30 <otavio> incandescant: hi
Feb 07 19:28:51 <incandescant> otavio: I'm wondering about trying to look at the BitBake changes for gitpkgv.bclass - any objections?
Feb 07 19:28:58 * incandescant is trying to lower barriers for systemd in core
Feb 07 19:29:43 <otavio> incandescant: sure not
Feb 07 19:30:04 <otavio> incandescant: when you'd like to look at other systemd stuff I'm more then welcome to talk about that
Feb 07 19:30:32 <incandescant> otavio: atm I'm trying to figure out what's required, I see a big changeset proposed for meta-oe - haven't looked in depth at that yet
Feb 07 19:30:38 <sgw> otavio: so you decoupled the udev-cache, but that will slow down non-systemd bootup time.
Feb 07 19:31:02 <otavio> sgw: not really
Feb 07 19:31:20 <otavio> sgw: most people are using devtmpfs and cache is slower then regular boot
Feb 07 19:31:26 <incandescant> iirc the yocto kernel has devtmpfs
Feb 07 19:31:35 <otavio> incandescant: exactly
Feb 07 19:31:52 <incandescant> it's enabled by default at least for MACHINEs I've looked at
Feb 07 19:32:07 <sgw> otavio: have you done any tests to confirm this?  RP__ was thinking we need to add it back in our images.
Feb 07 19:32:45 <otavio> sgw: not recently ... i did compare it but i don't have numbers off hand
Feb 07 19:33:59 <otavio> incandescant: systemd is hard to get well integrated
Feb 07 19:34:22 <otavio> incandescant: what we have in meta-oe is more or less ok but far from best alternative
Feb 07 19:34:47 <incandescant> otavio: that's the impression I've got too, my initial inclination is that it needs to be a DISTRO thing, to enable various OECONF etc
Feb 07 19:34:59 <otavio> incandescant: the right thing to do is what i suggested on the patchset.
Feb 07 19:35:05 <sgw> otavio: any chance of providing some numbers, I will integrate this change, but want to figure out if we need to bring it back for some set of images.
Feb 07 19:35:12 <incandescant> otavio: I'd best read that today then
Feb 07 19:35:46 <otavio> incandescant: the state of art would to have both -systemd and -sysvinit packages for every package and at image building choose
Feb 07 19:36:21 <otavio> sgw: not easy for me to redo it as i am half way of getting udev 180 done and i'd need to undo a lot of stuff
Feb 07 19:36:56 <incandescant> otavio: that seems like a good goal but I wonder if it's possible? for units vs initscripts sure, but what about where packages use systemd interfaces?
Feb 07 19:37:15 * incandescant was pondering some shim implementation of the systemd interfaces for non-systemd systems
Feb 07 19:37:32 <otavio> incandescant: an acceptable solution for me is to have them generated depending on a distro feature
Feb 07 19:37:47 <otavio> incandescant: give an example, plz
Feb 07 19:38:36 <incandescant> otavio: I'd love to but wiki.fd.o appears down
Feb 07 19:39:07 <otavio> incandescant: tell me, not need to be a pointer
Feb 07 19:39:17 <otavio> incandescant: by interface, what do you mean
Feb 07 19:39:59 <incandescant> otavio: API, configuration files, etc.
Feb 07 19:40:05 <incandescant> otavio: systemd is defining some interfaces which are being adopted by glib, X11, etc. d-bus API's, fi and I'm trying to figure out a nice way to support those in the core
Feb 07 19:40:17 <incandescant> i.e. locale.conf and localed
Feb 07 19:40:43 <sgw> otavio: since you have had your hands in udev, does it really need to RRECOMMED usbutils-ids and pciutils-ids?  Can we get away with out those?
Feb 07 19:41:08 <incandescant> otavio: I don't think it's an immediate concern but I expect as systemd becomes more popular that software we build will rely on more of its features
Feb 07 19:41:21 <otavio> incandescant: well, in fact i do think we won't be able to build complex images without systemd in not a  far future
Feb 07 19:41:45 <incandescant> otavio: I hope that's not so, but I can see how that might be
Feb 07 19:41:45 <otavio> sgw: did't check it
Feb 07 19:41:48 <otavio> sgw: but i can do it
Feb 07 19:41:59 <otavio> sgw: but i will do after finishing 180 changes
Feb 07 19:42:21 <sgw> otavio: please, since in the minimal-image it adds a significant amount of space.
Feb 07 19:42:26 <otavio> sgw: most probably in a patch before applying the newer version but that i will do after
Feb 07 19:42:32 <otavio> sgw: sure, will do
Feb 07 19:43:11 <sgw> otavio: ok thank. lspci and lsusb bring them in for those human readable commands, which should be sufficient if udev does not need human readable output.
Feb 07 19:43:22 <kergoth`> if it becomes not possible to build complex images without systemd, people will just not use OE and homeroll or go back to buildroot
Feb 07 19:43:44 <otavio> incandescant: i'm not sure about what kind of uses udisks and polkit does when linking with systemd
Feb 07 19:44:12 <otavio> kergoth`: newer code will be more and more dependant of systemd in future. that is my impression
Feb 07 19:44:27 <incandescant> kergoth`: agreed, that's why I'm trying to figure out this stuff sooner rather than later
Feb 07 19:44:37 <kergoth`> then people will use other projects. it'll never be ubiquitous, it'll just be popular
Feb 07 19:44:41 <otavio> kergoth`: not oe explicitly but some packages might enfore it
Feb 07 19:44:48 <kergoth`> then people won't use those packages.
Feb 07 19:45:01 <otavio> kergoth`: that's why i said complex images
Feb 07 19:45:12 <otavio> kergoth`: that involved desktop envinronments and like
Feb 07 19:45:14 <kergoth`> and? using alternative packages doesn't imply anything about complexity
Feb 07 19:45:21 <kergoth`> there are plenty of desktop environments around
Feb 07 19:45:39 <otavio> kergoth`: my idea is not to discuss
Feb 07 19:45:51 <otavio> kergoth`: but have systemd into core without breaking stuff
Feb 07 19:46:25 <kergoth`> as long as you can disable it, fine with me. I'd be happy enough if just meta-oe wasn't useless to me, heh
Feb 07 19:47:27 <otavio> kergoth`: if you skip to use their tasks, it works fine without systemd
Feb 07 19:47:38 <otavio> kergoth`: i have images without systemd
Feb 07 19:47:44 <sgw> ag: is the udpated dhcp patch coming soon?
Feb 07 19:47:46 <kergoth`> images, yes, but it still forces you to *build* it
Feb 07 19:47:54 <otavio> ahh
Feb 07 19:47:54 <kergoth`> youc an't even build busybox without building it, its ridiculous
Feb 07 19:48:01 <incandescant> huh?
Feb 07 19:48:07 <otavio> kergoth`: this is going to be fixed
Feb 07 19:48:13 <kergoth`> there's a busybox bbappend in meta-oe that inherits systemd, yanking it into DEPENDS
Feb 07 19:48:16 <kergoth`> good
Feb 07 19:48:20 <ag> sgw: yes. i had some conflicts in my branches with so many changes...
Feb 07 19:48:44 <sgw> I am just trying to get a bigger pull request done.
Feb 07 19:48:55 * sgw has to meet with someone back soon
Feb 07 19:54:43 <ag> oravio: would you please give me your commit one again?
Feb 07 19:54:47 <ag> otavio: would you please give me your commit one again?
Feb 07 19:54:51 <otavio> ag: sure
Feb 07 19:55:05 <ag> otavio: my repo is a mess...
Feb 07 19:55:44 <ag> otavio: the new one
Feb 07 19:55:53 <otavio> ag: i am trying to connect on github; hold a sec
Feb 07 19:56:25 <ag> otavio: bitbucket is a better solution.
Feb 07 20:00:45 <otavio> ag: https://github.com/OSSystems/oe-core/commit/f3c82bbf545c086ccd89c06020f8721637fe9202
Feb 07 20:02:19 <ag> otavio: slow...
Feb 07 20:07:33 <otavio> incandescant: your gitpkgv work won't depends on newer bitbake to be released and oe-core minimal version bumped?
Feb 07 20:08:09 <kergoth`away> couldn't you have the class try the bitbake methods and fall back to internal ones, to retain compatibility for a period?
Feb 07 20:08:28 <incandescant> that sounds like a reasonable approach
Feb 07 20:09:11 <otavio> kergoth: this will be even uglier
Feb 07 20:09:12 <otavio> heh
Feb 07 20:09:13 <otavio> crap
Feb 07 20:09:53 <incandescant> otavio: if it's blocking on the review comments I don't see how we can address that without a newer BitBake version requirement?
Feb 07 20:10:19 <incandescant> I'm not opposed to it being merged as is but there hasn't been any movement on that suggestion
Feb 07 20:10:20 <kergoth> otavio: how so? it makes perfect sense to me. the class will get cleaned up when the minimum bitbake version is bumped.
Feb 07 20:10:35 <kergoth> either you bump the version, or the class gets adjusted, you only have so many options
Feb 07 20:11:20 <otavio> heh
Feb 07 20:12:04 <otavio> well; let me keep working on fixing my tree here
Feb 07 20:12:34 <incandescant> otavio: if you have alternative suggestions I'm open to them?
Feb 07 20:12:58 <otavio> incandescant: mine was to merge it and clean it up when support for bitbake was make available
Feb 07 20:13:21 <otavio> incandescant: but it's not my call
Feb 07 20:13:43 <ag> otavio: http://git.gherzan.ro/yocto-dev/changesets Check there if your patch is ok.
Feb 07 20:13:51 <incandescant> otavio: nor mine, but it hasn't been merged so I'm assuming we need to address the review concerns
Feb 07 20:14:03 <otavio> incandescant: right
Feb 07 20:17:15 <ag> otavio: hope i didn't miss anything
Feb 07 20:31:09 <ag> sgw: Sent patches to mailing list.
Feb 07 20:31:53 <sgw> ag. back and thanks, will review and test
Feb 07 20:32:29 <ag> sgw: I'm waiting for your feedback so that i can go to bed. :)
Feb 07 20:33:03 <sgw> ag: JS is on hold, let me look at dhcp and get a build going
Feb 07 20:36:44 <ag> sgw: One more thing about js. Fallowing Phil Blundell  comment about js i removed the .so from nspr. Now it is in nspr-dev. In this way js needs this library at runtime. So a RDEPENDS is needed here or .so back to main rpm.
Feb 07 20:37:02 <ag> sgw: If you want i can upload a new patch
Feb 07 20:39:41 <sgw> ag: this depends greatly on how the .so* are created and linked.  Many times the version'ed .so.x.y is the real file which belongs in the ${PN} package, and the .so is a link that goes into the ${PN}-dev, do you need to understand how the .so files are linked.
Feb 07 20:40:07 <sgw> ag: what kind of runtime testing did you do with dhcp?
Feb 07 20:42:05 <ag> dhclient
Feb 07 20:42:13 <ag> sgw: dhclient
Feb 07 20:42:50 <ag> on a x86
Feb 07 20:43:05 <ag> I didn't have time for more.
Feb 07 20:43:29 <ag> If you want you can postpone it and i will have some serious testing on it.
Feb 07 20:45:33 <sgw> ag: I am sending another email, about some warnings, please address that, I think your testing should be OK.
Feb 07 20:46:18 <ag> sgw: 5 minutes
Feb 07 20:46:46 <sgw> ag, I might go ahead and pull otavio's dhcp while you addess the dchp issues and I will get the upgrade tomorrow, OK?
Feb 07 20:47:15 <ag> Ok then. I will leave it for tomorrow.
Feb 07 20:48:18 <sgw> ag, thanks and good night then, it must be late there.
Feb 07 20:48:40 <ag> sgw: i will finish this warnings after that
Feb 07 20:48:53 <ag> sgw: i will finish these warnings after that
Feb 07 20:52:34 <JaMa> kergoth: pong, does it mean that I should enable futures again first right?
Feb 07 20:59:55 <otavio> ag: i have images both for client and daemon of dhcp
Feb 07 21:00:10 <otavio> ag: if you provide patches against oe-core i can test them
Feb 07 21:00:55 <JaMa> otavio: thanks for that DEPENDS change :)
Feb 07 21:01:52 <otavio> JaMa: np; please review and ack it
Feb 07 21:03:17 <JaMa> I'm thinking how to fix that issue with polkit RDEPENDING on systemd
Feb 07 21:03:45 <JaMa> at least we should add note about it in this .bbappend
Feb 07 21:04:11 <otavio> JaMa: maybe if it builds a library only when it links against systemd we might put that on a package
Feb 07 21:04:15 <ag> otavio: do you know the discussion sgw is talking about in his email about those warnings? I can't find those emails.
Feb 07 21:04:52 <JaMa> otavio: without http://git.shr-project.org/git/?p=meta-smartphone.git;a=blob;f=meta-shr/recipes-extended/polkit/polkit_0.104.bbappend;hb=HEAD systemd ends in images and breaks boot
Feb 07 21:04:59 <otavio> ag: i don't recall the mails but the concern is to avoid having /sbin and /bin files linking at /usr/lib libraries
Feb 07 21:05:35 <JaMa> otavio: iirc it's same library linked to consolekit or systemd
Feb 07 21:05:49 <JaMa> otavio: so we would need to split lib from systemd
Feb 07 21:06:07 <otavio> JaMa: or have a distro feature for systemd
Feb 07 21:06:28 <JaMa> /usr/libexec/polkitd -> libsystemd-login.so.0
Feb 07 21:06:39 <otavio> JaMa: it looks like we won't be able to have systemd/sysvinit as an image decision but we'd need to have it as a distro decision
Feb 07 21:06:42 <JaMa> so we can split libsystemd-login from systemd package
Feb 07 21:07:08 <JaMa> but it won't help people which need consolekit much (unless libsystemd-login can work without systemd)
Feb 07 21:07:12 <otavio> JaMa: i doubt polkit will work without it
Feb 07 21:07:47 <JaMa> yup but Andreas patchset is step in right direction
Feb 07 21:07:58 <otavio> JaMa: please reply about that in Andreas patchset
Feb 07 21:08:10 <otavio> JaMa: specially on the polkit issue
Feb 07 21:08:18 <sgw> ag: look for Duplicate Recipes (thread kind of morphed), also the timezone discussion with Koen
Feb 07 21:08:52 <otavio> sgw: dhcp and udev patches are going in your pull request?
Feb 07 21:09:01 <sgw> yes
Feb 07 21:09:05 <sgw> otavio: ^^
Feb 07 21:10:56 <otavio> sgw: just send two new patches ;-)
Feb 07 21:11:00 <sgw> otavio: is your recent dhcp patch with cross.bbclass different that the orignal one?
Feb 07 21:11:07 <otavio> sgw: no
Feb 07 21:11:09 <otavio> sgw: same
Feb 07 21:11:28 <otavio> sgw: just send it because it is in our tree for pushing
Feb 07 21:11:31 <sgw> Ok, well those two are going the next 2 will wait for the next request.
Feb 07 21:11:38 <otavio> sgw: sure
Feb 07 21:11:57 <JaMa> otavio: ok...
Feb 07 21:12:04 <otavio> sgw: those new two has been tested in our chicken based imaged and worked fine
Feb 07 21:12:21 <JaMa> otavio: for now SHR is still using sysvinit and systemd support is in separate branch
Feb 07 21:12:23 <otavio> sgw: but take your time, no problem
Feb 07 21:12:31 <otavio> JaMa: i see
Feb 07 21:12:36 <ag> sgw: /var/lib/dhcp is empty. Should i remove it or add it in client rpm/
Feb 07 21:12:37 <JaMa> otavio: I plan to switch all images to systemd after next release
Feb 07 21:12:48 <otavio> ag: it is need by the client
Feb 07 21:12:50 <sgw> otavio: understood, I am just trying to get something together today for RP__
Feb 07 21:12:56 <JaMa> otavio: but I have problem with some devices which have only quite old kernel (palmpre*)
Feb 07 21:12:58 <otavio> ag: and mine patch handled it
Feb 07 21:12:58 <ag> otavio: i thought so
Feb 07 21:13:22 <JaMa> otavio: so per image would be much easier for me to keep palmpre support without creating new kernel for it
Feb 07 21:13:33 <otavio> ag: with my patch in, it shouldn't be created
Feb 07 21:13:39 <sgw> ag: my guess is that /var/lib/dhcp will be needed by the running system so needs to be installed by the ${PN} package
Feb 07 21:13:48 <otavio> JaMa: yes but polkit now is the blocker for it
Feb 07 21:13:57 <otavio> JaMa: it works in one way or another
Feb 07 21:14:15 <otavio> sgw: not needed to be installed as postinst handles it
Feb 07 21:14:47 <JaMa> otavio: yes we need to test standalone libsystemd-login.so.0 (without systemd itself)
Feb 07 21:14:56 <otavio> sgw: and both client and server needs the /var/lib/dhcp so it is not fair to put it on a single package ;-)
Feb 07 21:14:58 <JaMa> otavio: because if it works it would be easiest way out
Feb 07 21:14:59 <sgw> otavio: Ok then it should be removed from the image.
Feb 07 21:15:25 <sgw> otavio: right, I am running a little slow today, too much stuff in the air and trying to finish off 2 presentation for ELC!
Feb 07 21:15:35 <ag> otavio: with your patch i receive WARNING:   /var
Feb 07 21:15:35 <ag> WARNING:   /var/lib
Feb 07 21:15:36 <ag> WARNING:   /var/lib/dhcp
Feb 07 21:15:45 <otavio> sgw: heh, np
Feb 07 21:16:08 <otavio> ag: put an rmdir on the do_install_append and let postinsts handle it
Feb 07 21:16:09 <sgw> ag: right, you should just rm then in the do_install_append() function
Feb 07 21:16:18 <ag> deal
Feb 07 21:16:33 <ag> just wanted to know if it is handled
Feb 07 21:16:35 <sgw> otavio: I owe you a drink sometime, too bad you can not come to ELC next week.
Feb 07 21:17:17 <otavio> sgw: heh, indeed ... i wanted to go but i couldn't make it
Feb 07 21:17:28 <otavio> sgw: but you owe me nothing
Feb 07 21:17:32 <otavio> sgw: heh
Feb 07 21:17:50 <otavio> sgw: but i'd accept it anyway heheh
Feb 07 21:17:52 <otavio> lol
Feb 07 21:18:17 <ag> sgw: invite me! :)
Feb 07 21:19:06 <otavio> ok; enough for today ...
Feb 07 21:19:11 <otavio> i gotta go
Feb 07 21:19:13 <otavio> see ya
Feb 07 21:19:15 <ag> cheers
Feb 07 21:19:25 * sgw brain hurts today
Feb 07 21:19:38 <sgw> otavio: talk to you later.
Feb 07 21:28:43 <ag> sgw: sent patch
Feb 07 21:30:12 <sgw> ag: Ok, will still be in the next round, thanks.
Feb 07 21:32:39 <ag> sgw: abou .so's. I know how are linked but in this nspr case there are only {libraryname}.so files.
Feb 07 21:33:53 <sgw> ag: then they would go in ${PN} directly.
Feb 07 21:35:31 <ag> sgw: It was the way i did it in the first place. But Phil wanted me to remove that. Anyway. I will post back these files.
Feb 07 21:35:54 <sgw> Add better commit message to help us understand why
Feb 07 21:36:09 <ag> deal. sorry
Feb 07 21:40:54 <ag> that should be it for today
Feb 07 21:41:18 <ag> cheers!
Feb 07 21:44:06 <autif> tomz1 - on crownbay - how do I get the kernel to send output to serial port? dmesg shows /dev/ttyPCH0,1,2,3 - after boot completes, I can successfully communicate over /dev/ttyPCH2, but when I pass console=ttyPCH2,115200n8, I do not get anything on the other end of the serial port, Do I need something more/else?
Feb 07 21:45:44 <tomz1> autif: I've always just done boot console=ttyS0,115200
Feb 07 21:46:03 <autif> on crownbay - right?
Feb 07 21:46:13 <autif> E640 based mobo
Feb 07 21:46:25 <tomz1> autif: yeah, that's what I use
Feb 07 21:48:09 <autif> I recall that not working, let me enumerate thru all of those - can you please "dmesg | grep -i uart" and verify that the kernel enumerates serial ports as ttyS* instead of ttyPCH*
Feb 07 21:48:22 <autif> s/enumerate/iterate
Feb 07 21:53:01 <autif> ttyS* do not exist for me in /dev - instead ttyPCH* do and I can communicate over them after boot completes - I am still not sure, how to divert kernel messages to the serial port
Feb 07 21:56:19 <tomz1> autif: sent you the output
Feb 07 21:57:26 <autif> thanks tomz1
Feb 07 21:58:36 <tomz1> autif: sure, np
Feb 07 22:05:38 <autif> tomz1 - I am on 1.2 (aka M2) and I do not have the second set of lines (except the first one - which does not count) - was this something new after M2 or am I missing something - I am using the core-image-ato image
Feb 07 22:07:26 <tomz1> autif: this was after M2, basically a test image for emgd 1.10
Feb 07 22:07:36 <autif> hmmmn
Feb 07 22:14:09 <autif> I have copied my dmesg to http://pastebin.com/htnJQ7JX - serial shows up around line 550, as you can see there is no ttyS in that file - what could be the difference between your and my setup?
Feb 07 22:19:20 <autif> leaving for home now - will catch you tomorrow. meanwhile the window is open - so I will get the messages in case you type something here, thanks for all the help again :-)
Feb 07 23:07:13 <sgw> khem: did you fix up zlib also?
Feb 07 23:15:36 <tomz1> autif: please send/post your kernel config
Feb 07 23:54:31 <nitink> halstead|afk: ping me when you are back
Feb 08 02:50:59 <khem> sgw: no zlib not yes I need to reproduce it first
Feb 08 02:56:44 <sgw> khem: not sure what else I can tell you I am running Ubuntu
Feb 08 02:58:34 <khem> sgw: me too :)
Feb 08 02:58:42 <khem> 64bit 11.10
Feb 08 02:59:19 <khem> ok is it possible for you to expose the build dir of one of failing packages
Feb 08 02:59:20 <sgw> khem same here, which libtool it pixman finding?  I see it using a local libtool
Feb 08 02:59:44 <sgw> khem not easy, it's my work desktop.
**** ENDING LOGGING AT Wed Feb 08 02:59:57 2012

**** BEGIN LOGGING AT Wed Feb 08 02:59:57 2012
Feb 08 03:00:41 <khem> what was the third package
Feb 08 03:00:47 <khem> pixman gconf and
Feb 08 03:01:11 <sgw> polkit
Feb 08 03:01:14 <khem> ok
Feb 08 03:04:46 <khem> cleaned sstate
Feb 08 03:04:52 <khem> again all builds fine
Feb 08 03:05:02 <khem> i586/eglibc
Feb 08 03:08:08 <khem> sgw: did you do a clean build ?
Feb 08 03:08:24 <khem> sgw: or do u have remnants from previous builds
Feb 08 03:08:29 <sgw> I did cleansstate on polkit, pixman and zlib, zlib-native
Feb 08 03:08:30 <khem> in your staging
Feb 08 03:08:59 <khem> ok and do you find zlib.la in your sysroot
Feb 08 03:09:32 <sgw> for the 2.6 build no zlib.la in sysroot
Feb 08 03:10:18 <khem> sgw: ok. did you also clean gconf
Feb 08 03:11:43 <sgw> yes and gconf-native
Feb 08 03:11:53 <sgw> khem: cleansstate
Feb 08 03:12:21 <khem> sgw: ok can you post the temp dirs of these three somewhere
Feb 08 03:12:36 <khem> sgw: let me look at the build logs
Feb 08 03:12:40 <khem> may be something will pop us
Feb 08 03:12:49 <sgw> I am on the phone right now will do it shortly
Feb 08 03:13:00 <sgw> do you have an ftp location I drop them?
Feb 08 03:13:57 <khem> hmm not really
Feb 08 03:14:09 <sgw> Let me think about this maybe on ab infra
Feb 08 03:14:21 <khem> tar them up and email me
Feb 08 03:17:45 <khem> sgw: to be clear you did not do totally clean build from scratch right ?
Feb 08 03:17:54 <khem> i.e. with new zloib
Feb 08 03:17:57 <khem> zlib
Feb 08 03:18:14 <sgw> not totally clean, partial build with new zlib
Feb 08 03:18:23 <khem> hmm that could be the problem
Feb 08 03:18:31 <sgw> and then cleansstate of broken items and they still broke
Feb 08 03:18:42 <khem> ok can you search for zlib in your target sysroot
Feb 08 03:19:05 <khem> yeah you will know how evil libtool can be
Feb 08 03:19:24 <khem> there are indirect deps somewhere I believe
Feb 08 03:24:43 <khem> sgw: can you try a totally fresh bitbake pixman
Feb 08 03:24:54 <sgw> khem will do so later
Feb 08 03:24:55 <khem> sgw: just to be sure whats going on
Feb 08 03:27:42 <khem> sgw: you did not submit the thumb rework did you see any regression because of them
Feb 08 03:39:09 <sgw> khem: RP__ asked me not to, still some concerns about them.
Feb 08 03:39:20 <sgw> I have no way to test those directly.
Feb 08 04:01:46 <khem> sgw: ok, I will talk to RP__
Feb 08 04:16:14 <sgw> khem, clean (w/sstate) build completed OK with new zlib for pixman, so there is some sort of contamination going on.
Feb 08 04:16:26 <sgw> Do we need PR bumps for some set of recipes to fix that?
Feb 08 05:18:11 <khem> sgw: could be. I have no idea which ones those are
Feb 08 05:18:42 <khem> sgw: can you check for zlib.* in your faulty sysroot
Feb 08 05:18:46 <khem> that might give some idea
Feb 08 07:07:00 <cmra> hi there, is there any interest on adding pandaboard to the supported hardware?
Feb 08 07:11:21 <JaMa> kergoth: on faster host I got today http://paste.pocoo.org/show/547645/ with those 2 patches from oe-core ML on top of bitbake/master
Feb 08 07:31:13 <JaMa> kergoth: and it seems to be hanging since then http://paste.pocoo.org/show/547654/
Feb 08 07:35:50 <JaMa> kergoth: and it seems reproducible here.. only with BB_NUMBER_PARSE_THREADS = "1" it works
Feb 08 09:07:28 <mckoan> good morning
Feb 08 09:08:54 <Zagor> what is the idea of the linux-yocto-dev repo? the description says "tracks the next mainline release" but it's by no means tracking the torvalds repo
Feb 08 09:54:26 <bluelightning> morning all
Feb 08 09:55:02 <Zagor> morning
Feb 08 09:55:33 <Zagor> bluelightning: can you tell me the idea of the linux-yocto-dev repo? the description says "tracks the next mainline release" but it doesn't appear to be tracking the torvalds repo
Feb 08 09:56:41 <bluelightning> Zagor: I'm not the best person to advise on our kernel stuff I'm afraid, your best bet is to talk to dvhart or tomz1 when they come online (US east coast time)
Feb 08 09:56:52 <Zagor> ok
Feb 08 09:57:05 <bluelightning> or zeddii, he's also a kernel guy
Feb 08 11:18:55 <otavio> morning
Feb 08 11:58:26 <bluelightning> hi otavio
Feb 08 12:12:19 <otavio> ag: btw, prepare a patch for meta-oe for dhcp too.
Feb 08 12:13:46 <otavio> bluelightning: how are you doing? :)
Feb 08 12:14:28 <bluelightning> otavio: good thanks, and you?
Feb 08 12:15:03 <otavio> bluelightning: doing fine as well :)
Feb 08 12:23:53 <ag> otavio: today i will resend that
Feb 08 12:25:06 <ag> Any ideas about -mno-unaligned-access flag in gcc?
Feb 08 12:25:34 <ag> My imx53 kernel build fails while gcc says that it cannot understand that flag.
Feb 08 12:28:53 <otavio> ag: are you using meta-fsl?
Feb 08 12:30:22 <ag> otavio: yes. meta-freescale
Feb 08 12:30:47 <otavio> ag: hum it built fine here last time I tried
Feb 08 12:30:56 <otavio> ag: but have you changed kernel?
Feb 08 12:31:11 <ag> otavio: Nothing changed! Only userspace packages.
Feb 08 12:31:20 <otavio> ouch!
Feb 08 12:31:22 <ag> otavio: meta-freescale + oe-core
Feb 08 12:31:46 <ag> Something's crashed in gcc there...
Feb 08 12:31:49 <otavio> ag: I have meta-oe here so it might have changed the result
Feb 08 12:32:09 <ag> Dunno.
Feb 08 12:32:36 <ag> Anyway if i solve it i will tell you the result.
Feb 08 12:32:42 <otavio> ag: you might try to add meta-oe and try
Feb 08 12:32:54 <otavio> ag: just for a test, it might be worth it
Feb 08 12:33:06 <ag> otavio: i will
Feb 08 12:33:28 <otavio> ag: please do. I've been merging fixes in meta-fsl from time to time and if you can provide an github pull request, even better ;)
Feb 08 12:35:56 <otavio> RP__: I think I have done what you wished with cross.bbclass ... in fact we where doing it byhand on recipes so it changed nothing for us
Feb 08 12:44:16 <Crofton|work> urg, back on the plane again
Feb 08 12:47:49 <florian> hi Crofton|work
Feb 08 12:49:36 <Crofton|work> hi florian
Feb 08 13:02:44 <RP__> otavio: thanks, that is exactly what I feared. I'd rather not have code in there which isn't useful
Feb 08 13:34:02 <Crofton|work> why is my bag so heavy!
Feb 08 13:34:50 <zeddii> Zagor, linux-yocto-dev tracks what will become the next yocto release. I'm updating it to 3.3-rcX at the moment. It lags briefly when I produce a release kernel. (i.e. they were both 3.2 for a while, so I stopped linux-yocto-dev)
Feb 08 13:35:55 <Zagor> zeddii: aha, ok. thanks.
Feb 08 14:04:10 <kergoth> JaMa: hmmm, k, thanks for testing
Feb 08 14:04:17 <kergoth> JaMa: will dig in to it today
Feb 08 14:08:18 <kergoth> JaMa: what host is this?
Feb 08 14:09:49 <kergoth> JaMa: try going to line 1470 of bitbake/lib/bb/cooker.py and changing 0.25 to timeout=0.25. see if that fixes it
Feb 08 14:17:04 <JaMa> I've changed it to 1 in the morning and since then it builds
Feb 08 14:18:08 * kergoth nods, k
Feb 08 14:18:11 <JaMa> kergoth: it was doing this on both hosts depending on BB_NUMBER_PARSE_THREADS value (fails when > 1) http://git.shr-project.org/git/?p=shr-chroot.git;a=commit;h=befe455c0d4178534d17891488fe4d0f6873e8a1
Feb 08 14:19:07 <JaMa> and I'm not using futures now
Feb 08 14:20:08 <kergoth> without the timeout=, i think it's taking the 0.25 as the value of 'block', rather than timeout. block is generally boolean, so maybe its translating that to 0/1. will investigate further
Feb 08 14:25:25 <JaMa> kergoth: if you still have shr-chroot you can just update to get this :)
Feb 08 14:25:44 <kergoth> i have it, but I never had any luck reproducing with it
Feb 08 14:25:46 <kergoth> heh
Feb 08 14:26:06 <kergoth> tried on a more resource limited vm, but that didn't seem to do it, will try slowing it down further
Feb 08 14:26:14 <JaMa> can it be also size of metadata it needs to parse?
Feb 08 14:26:38 <JaMa> I can give you 2 lines to reproduce also metadata (layers) I'm using
Feb 08 14:27:01 <kergoth> could be, sure
Feb 08 14:27:58 <JaMa> kergoth: http://wiki.shr-project.org/trac/wiki/Building%20SHR
Feb 08 16:02:02 <sgw> kergoth: Good Morning
Feb 08 16:02:50 * kergoth fights bitbake and loses
Feb 08 16:03:28 <sgw> kergoth: I ran builds last night with your updated External-CSL patches and ran into build failures, seems that we build external-csl regardless, could you add a patch to disable it when not configured, please.
Feb 08 16:03:42 <sgw> kergoth: you can see the failure here: http://autobuilder.yoctoproject.org:8010/builders/nightly-arm/builds/294/steps/shell_34/logs/stdio
Feb 08 16:05:15 <kergoth> hmm, it shouldn't be built unless its tcmode is set, will look into it. I suspect we just need to add another default provider preference for gdb/gdbserver
Feb 08 16:06:38 <khem> bitbake -g will help to find why its being pulled in
Feb 08 16:06:38 <khem> NOTE: multiple providers are available for runtime gdbserver (external-csl-toolchain, gdb)
Feb 08 16:06:42 <khem> NOTE: consider defining a PREFERRED_PROVIDER entry to match gdbserver
Feb 08 16:06:57 <sgw> kergoth: that's one, possibly something else also, thanks for looking into it as it's in master now and needs a quick fix.
Feb 08 16:07:19 <kergoth> khem: figured, thanks
Feb 08 16:07:39 <sgw> khem, you will note there is also issues with sat-solver and oprofile due to the zlib update
Feb 08 16:07:42 <khem> I think real problem probably is that external-csl-toolchain is providing something more than that
Feb 08 16:07:44 <ag> otavio: dhcp sent
Feb 08 16:08:39 <khem> sgw: kergoth or there is a decrepency between what gdb provides and what csl toolchain recipe provides
Feb 08 16:09:18 <khem> sgw: hmm I figured that there are lot of  packages that add libz.la to its .la files thats why you see those errors on incremental builds
Feb 08 16:09:23 <sgw> ag: thanks for rebasing, I will build and test today.
Feb 08 16:09:37 <khem> sgw: I have written a script which is groking the relevant packages
Feb 08 16:10:03 <sgw> khem, so I should expect PR bumps for those (with DEPENDS updates if needed)?
Feb 08 16:10:06 <khem> I dont know if we should just recommend a clean rebuild
Feb 08 16:10:13 * kergoth tests
Feb 08 16:10:28 <khem> sgw: its a LOT of recipes
Feb 08 16:10:31 <khem> almost a rebuild
Feb 08 16:10:52 <sgw> khem: that's pretty draconian for a point release of a recipe!
Feb 08 16:11:05 <ag> sgw: again, no problem. I will look a little deeper into js tonight. When are you planing the next pull req?
Feb 08 16:11:13 <khem> yeah I wonder if we should just bump the ABI version
Feb 08 16:11:31 <kergoth> adding PREFERRED_PROVIDER_gdb = "gdb" to tcmode-default.inc should fix this issue, verifying now
Feb 08 16:11:35 <khem> one day I will get rid of all .la in OE
Feb 08 16:11:47 <kergoth> that'd be nice
Feb 08 16:11:55 <sgw> ag: It's kind of random dependant on pending and my overall workload, but later today probably a small one.
Feb 08 16:13:21 <ag> sgw: i moved client to usr/bin/ I will resend the patch cause i didn't mention this in the commit message. But i will do this change after you review it so i'm waiting for a feedback from you tonight.
Feb 08 16:15:52 <kergoth> sgw: think i'll just go ahead and commit this to oe-core directly if no one objects, it's a one line addition of a PREFERRED_PROVIDER to fix a build problem, so best to get it in quickly
Feb 08 16:16:34 <sgw> kergoth: verify that with RP__ please
Feb 08 16:16:54 <kergoth> k
Feb 08 16:18:13 <kergoth> RP__: mind if I check https://github.com/kergoth/oe-core/commit/4ef5e70f531f48cef90805402c16ec02ad3f2b92 into oe-core? it's needed as the external toolchain now provides gdbserver
Feb 08 16:23:10 <sgw> khem, can you look at the sat-solver failure, this occurs even with a clean build (just verified). - http://pastebin.com/C7jYCsr0
Feb 08 16:25:24 <RP__> kergoth: let me pull that in, I'm not sure you can push there
Feb 08 16:25:32 <RP__> kergoth: I was just talking about this with sgw
Feb 08 16:25:34 <kergoth> RP__: that works, thanks
Feb 08 16:26:35 <kergoth> sorry for the build breakage, I should have realized that would happen
Feb 08 16:28:17 <RP__> kergoth: I should have waited on the test builds too ;-)
Feb 08 16:28:22 <RP__> kergoth: its merged
Feb 08 16:29:35 <kergoth> damn, it's still possible to ^C at the exact wrong place during a bitbake build and result in the server choking on no rqexe defined. hmm, i thought that had been fixed
Feb 08 16:30:36 <kergoth> hmm, maybe the signal() call to ignore SIGINT in the server hadn't yet been reached at that point
Feb 08 16:30:39 <RP__> kergoth: I've seen that before, its annoying but hard to reproduce when you actually try to...
Feb 08 16:30:43 * kergoth nods
Feb 08 16:31:13 <kergoth> one issue is, we want the UI to catch sigint and then shutdown the server, but the question is how to handle it before the UI starts :)
Feb 08 16:31:22 <kergoth> we know the server shouldn't receive SIGINT at all once it starts, but..
Feb 08 16:31:23 <RP__> kergoth: btw, I was thinking it might be a good idea to have external-toolchain* raise a SkipRecipe if they're not configured
Feb 08 16:31:35 <RP__> kergoth: Just so they really can't run when we don't want them
Feb 08 16:31:42 <ag> RP__: Sorry about all my childish errors with comments and stuff. I'm in learning stages. :) I will re-upload the patch with a detailed comment.
Feb 08 16:32:11 <kergoth> RP__: yeah, probably a good idea, better to be safe
Feb 08 16:36:15 <otavio> ag: to meta-oe?
Feb 08 16:37:45 <ag> ag: you already replied on it. :) After we decide what to do with dhcp client / lcrypto i will edit the changelog.
Feb 08 16:37:53 <ag> otavio: you already replied on it. :) After we decide what to do with dhcp client / lcrypto i will edit the changelog.
Feb 08 16:38:03 <otavio> ag: yes
Feb 08 16:38:17 <otavio> ag: I'd say it ought to be another commit.
Feb 08 16:38:32 <otavio> ag: be it fixing dhcp or libcrypto
Feb 08 16:38:47 <ag> otavio: i can do it as well.
Feb 08 16:38:53 <otavio> ag: and does it really needs libcrypto?
Feb 08 16:39:03 * otavio has no clue why it would use it
Feb 08 16:39:35 <ag> otavio: :) do we have a doubt about this? i will check what is really linked to this.
Feb 08 16:40:40 <otavio> ag: this might be the easiest and preferred fix. In any case it ought to be in another commit.
Feb 08 16:41:18 <otavio> ag: I've trying to keep changes as small as possible so it is easy for review and also to spot what has broken something
Feb 08 16:41:36 <otavio> ag: sometimes I fail on this though lol!
Feb 08 16:41:55 <ag> otavio: thanks for advice. i will apply it from now on.
Feb 08 16:43:39 <otavio> kergoth: https://github.com/OSSystems/meta-oe has the fixes to avoid building systemd on busybox ;-)
Feb 08 16:43:48 <kergoth> nice
Feb 08 16:44:31 * kergoth sighs at bitbake
Feb 08 16:46:12 <sgw> ag: as was mentioned above is libcrypto really required?  Is there a configure option to disable or not require it, this seems to be a new requirement?
Feb 08 16:47:36 <ag> sgw: i'm digging into it right now
Feb 08 17:03:11 <sgw> khem, thanks for helping us to get to 100% Upstream-Status in patches.
Feb 08 17:07:54 <kergoth> sgw: do you know why one of the 4 external toolchain commits was dropped? I didn't see any reply to it indicating a problem
Feb 08 17:10:58 <ag> sgw: it seems like dhclient doesn't need lcrypto. I think the best approach would be at lcrypto only to the needed module in dhcp. I cant remember which. But i will find it. What do you say?
Feb 08 17:11:35 <ag> Right now my patch adds lcrypto in configure and after it LIBS will include lcrypto for all makefiles.
Feb 08 17:13:56 <ag> "at" = "to add"
Feb 08 19:19:48 <incandescant> kergoth: ping? wondering if you can offer tips on doing REPL-like interactions with BitBake? I want to play around with fetch2 without running full builds.
Feb 08 19:19:59 <incandescant> I seem to recall seeing some github gists in the past but can't find them
Feb 08 19:30:29 <khem> RP__: around ?
Feb 08 19:32:23 <khem> RP__: with zlib upgrade I am trying to abandon the .la file and infact the autoreconf we do since upstream zlib does not use configure the way its meant to be so we better not autoreconf it. now the problem is lot of other .la files include it so when you do incremental build they fail to find libz.la
Feb 08 19:32:57 <khem> I got all of the recipes who owned those .la files bumped PRs but it does not help either
Feb 08 19:33:20 <khem> I believe thats because there are other missing dependencies and therefore the order
Feb 08 19:33:24 <khem> is different for building
Feb 08 19:35:14 <khem> I think this needs a LAYER_CONF_VERSION bump
Feb 08 20:35:59 <autif> tomz1 - did you have a chance to look at my kernel config?
Feb 08 20:38:22 <tomz1> autif: yeah, it looks the same as mine, so not missing any config options as i suspected
Feb 08 20:39:13 <tomz1> autif: I guess I'll have to build M2 then and see if I see that here
Feb 08 21:05:23 <msm> nitink1: did you see my latest reply about distutils?
Feb 08 21:05:38 <msm> nitink1: i think im just gonna send the patch and see what everyone things
Feb 08 21:05:41 <msm> thinks*
Feb 08 21:06:29 <nitink1> msm: Yes I saw your response. Go ahead and send it
Feb 08 21:06:40 <msm> k
Feb 08 21:10:24 <nitink1> msm: BTW that change can be contained inside distutils_do_compile()
Feb 08 21:12:27 <msm> nitink1: well, i was playing it safe =) what if someone adds do_compile_append?
Feb 08 21:12:44 <msm> nvm - that would not matter
Feb 08 21:12:57 <msm> anyways, i can send a v2 if there are no other comments
Feb 08 21:13:01 <nitink1> do_compile_append would not hurt it
Feb 08 21:13:12 <nitink1> it does not remove anything from do_compile
Feb 08 21:13:20 <msm> nitink1: i realized that after i spoke
Feb 08 22:45:30 <khem> sgw: I am sending a revised zlib patch which fixes some DEPENDS and bumps PR of the recipes that need zlib
Feb 08 22:45:52 <khem> sgw: with that now you should be able to do incremental build
Feb 08 22:46:16 <sgw> khem, ok, I will try it with an incremental build today.
Feb 08 22:46:51 <khem> yeah discovered that pixbuf needs to depend on libpng
Feb 08 22:47:00 <khem> and some more missing depends on zlib
Feb 08 22:47:08 <khem> so overall it should be an improvement
Feb 08 22:47:30 <ant____> sgw, khem: a doubt about staticdev and .a files
Feb 08 22:47:32 <khem> sgw: let me push it to the ml
Feb 08 22:47:58 <khem> ant____: staticdevs are useless unless you want static rootfile system imo
Feb 08 22:48:12 <khem> static meaning statically linked
Feb 08 22:48:26 <khem> so its good they reside in package of their own
Feb 08 22:49:03 <ant____> but for a libc isn't it normal to have some exception packaged in -dev ?
Feb 08 22:49:12 <khem> for libc yes
Feb 08 22:49:30 <ant____> klibc-1.5.25: non -staticdev package contains static .a library: libklibc-dev path '/work/poodle-oe-linux-gnueabi/klibc-1.5.25-r0.0/packages-split/libklibc-dev/lib/klibc/lib/libc.a'
Feb 08 22:49:32 <khem> usually we have to .a which are PIC are still ok
Feb 08 22:49:54 <khem> thats a staticdev item
Feb 08 22:51:24 <ant____> I see
Feb 08 22:52:04 <ant____> khem: another question: in klibc.bbclass we
Feb 08 22:52:16 <ant____> export CFLAGS="" export CPPFLAGS="" export LDFLAGS=""
Feb 08 22:52:30 <ant____> in fact, this is only needed fo kexec-tools-klibc
Feb 08 22:52:57 <ant____> other binaries can be compileed with std oe flags
Feb 08 22:53:04 <khem> sgw: just pushed the revised zlib patch to kraj/misc
Feb 08 22:53:15 <ant____> I'm wondering: better to let klcc do its' things alone?
Feb 08 22:53:51 <khem> kexec-tools-klibc is jusr klcc ?
Feb 08 22:54:32 <ant____> is compiled by ${TARGET_PREFIX}klcc"
Feb 08 22:55:02 <khem> ok then who all need klibc.bbclass
Feb 08 22:55:26 <khem> should klibc.bbclass be called klcc.bbclass instead ?
Feb 08 22:55:29 <ant____> it's an easy way to set compiler and reset flags
Feb 08 22:55:36 <ant____> well, maybe
Feb 08 22:55:42 <khem> or may be klcc-cross.bbclass
Feb 08 22:55:53 <ant____> the recipe just have yo inherit that class
Feb 08 22:55:59 <ant____> *to
Feb 08 22:56:54 <ant____> then, if you want a static version you have to edit its do_compile usually
Feb 08 22:57:27 <ant____> i was wondering if this can be automated in some way
Feb 08 22:58:08 <khem> add a variable like BUILDSTATIC
Feb 08 22:58:16 <khem> and let recipes set it
Feb 08 23:00:01 <ant____> hm.. see e.g. the two nandlogical .bb's http://cgit.openembedded.org/meta-handheld/tree/recipes-bsp/zaurus-utils
Feb 08 23:00:11 <ant____> diffs are at minimum
Feb 08 23:01:36 <ant____> well, we'd gain 2 line setting BUILDSTATIC ;)
Feb 08 23:02:27 <ant____> hm..., -I${STAGING_INCDIR}
Feb 08 23:03:14 <khem> yeah thats not needed.
Feb 08 23:03:34 <khem> but since you reset CFLAGS in klibc.bbclass
Feb 08 23:03:36 <ant____> be careful, klcc uses nostdinc and so on
Feb 08 23:03:56 <khem> then it should move into the class
Feb 08 23:04:09 <khem> if its common enough
Feb 08 23:05:06 <ant____> khem: I can't really judge, I just beat the packages to compile statically
Feb 08 23:05:19 <ant____> (mostly with patches)
Feb 08 23:05:51 <ant____> prolly all can be done in the recipe in an elegant way
**** ENDING LOGGING AT Thu Feb 09 00:04:03 2012

**** BEGIN LOGGING AT Thu Feb 09 00:12:17 2012
**** ENDING LOGGING AT Thu Feb 09 00:58:30 2012

**** BEGIN LOGGING AT Thu Feb 09 01:10:18 2012
**** ENDING LOGGING AT Thu Feb 09 02:59:57 2012

**** BEGIN LOGGING AT Thu Feb 09 02:59:58 2012
Feb 09 09:02:44 <mckoan> good morning
Feb 09 09:03:28 * Zagor raises his cup
Feb 09 10:20:20 <Zagor> is PARALLEL_MAKE used explictly in each recipe, or inherited from higher level? it looks to me like a lot of tasks don't use it (currently looking at do_compile_kernelmodules)
Feb 09 10:21:27 <Zagor> s/looking at/running/
Feb 09 10:22:14 <bluelightning> Zagor: it's inherited from local.conf
Feb 09 10:22:54 <Zagor> yes I define it there, but it seems it is not always used
Feb 09 10:23:08 <bluelightning> Zagor: some recipes override it ("") because they can't safely build in parallel (or couldn't, in the past)
Feb 09 10:23:11 <Zagor> which makes sense in a way, since not all projects are parallel safe
Feb 09 10:23:42 <Zagor> I would have thought the kernel wasn't one of them though :)
Feb 09 10:25:04 <bluelightning> well, do_compile_kernelmodules explicitly passes PARALLEL_MAKE to make so it ought to be building in parallel...
Feb 09 10:30:31 <Zagor> not in my version (edison). it just runs: oe_runmake modules  CC="${KERNEL_CC}" LD="${KERNEL_LD}"
Feb 09 10:30:59 <Zagor> and as far as I can see oe_runmake() doesn't do it itself?
Feb 09 10:32:37 <Zagor> right, $(PARALLEL_MAKE} was added later
Feb 09 10:33:26 <bluelightning> Zagor: ah yes, I didn't check... looks like Richard added that in december
Feb 09 10:34:46 <Zagor> couldn't oe_runmake contain ${PARALLEL_MAKE} instead, since we override it in packages that don't support it?
Feb 09 10:35:23 <Zagor> or am I missing something in the inheritance chain?
Feb 09 10:35:34 <bluelightning> Zagor: it gets prepended to EXTRA_OEMAKE in bitbake.conf
Feb 09 10:35:53 <bluelightning> I'm not sure why it has been implemented that way but I'd imagine there was a reason
Feb 09 10:37:26 <Zagor> aha, and that too was added after edison. I should probably consider upgrading.
Feb 09 10:39:37 <bluelightning> Zagor: well, there hasn't been a release since edison... (next is planned for april)
Feb 09 10:40:20 <bluelightning> not a full release at least, we have had a couple of milestone releases
Feb 09 10:41:51 <Zagor> oh, bitbake.conf sets EXTRA_OEMAKE_prepend_task-compile, which I guess isn't used for do_compile_kernelmodules?
Feb 09 10:42:15 <Zagor> which would explain the seemingly redundant addition in kernel.bbclass
Feb 09 10:42:25 <Zagor> there's a lot to learn! :-)
Feb 09 13:57:02 <ag> otavio: Did you ever managed to boot a imx53sdb?
Feb 09 13:57:31 <otavio> ag: imx53qsb, yes
Feb 09 13:57:37 <otavio> ag: many times
Feb 09 13:57:38 <ag> otavio: I just cannot make it say anything on serial.
Feb 09 13:57:52 <otavio> ag: humm
Feb 09 13:57:58 <otavio> ag: are you using what?
Feb 09 13:58:02 <ag> I used a image with uboot uImage and rootfs from fsl and it works.
Feb 09 13:58:23 <ag> But if i want to burn a uboot by myself... nothing happens.
Feb 09 13:58:36 <ag> yes qsb
Feb 09 13:59:35 <otavio> ag: ahh it ought to be the offset
Feb 09 13:59:38 <ag> otavio: i erased the sd card with "sudo parted --script /dev/mmcblk0 mklabel msdos" and burned uboot with "sudo dd if=u-boot.bin of=/dev/mmcblk0 seek=1 bs=1024"
Feb 09 14:00:00 <ag> otavio: and minicom is mute...
Feb 09 14:00:29 <otavio> ag: check the sdcard_image class
Feb 09 14:00:42 <otavio> ag: it generated a sdcard image as result
Feb 09 14:00:54 <otavio> ag: and this is what i've been using
Feb 09 14:01:37 <ag> otavio: i see. so you never used uboot and uimage separately. just as image
Feb 09 14:02:14 <otavio> ag: i used; but i ended writting a class to make my life easier and generated an image with them
Feb 09 14:02:27 <otavio> ag: but on the class, has the dd command i used
Feb 09 14:02:49 <ag> found it.
Feb 09 14:02:57 <ag> otavio: thank you very much
Feb 09 14:03:05 <otavio> ag: np :)
Feb 09 14:04:43 <ag> otavio: about that dhcp problem. We don't have any conclusion now, right?
Feb 09 14:05:09 <otavio> ag: it seems people said for you to move crypto to /lib
Feb 09 14:05:21 <ag> otavio: you said it :)
Feb 09 14:05:30 <ag> otavio: ok then :)
Feb 09 14:22:54 <Zagor> do_package_ipk would be nice to run in parallel
Feb 09 14:24:55 <Zagor> BB_NUMBER_THREADS is only used by runqueue, right?
Feb 09 14:25:11 <fray> yes
Feb 09 14:26:46 <Zagor> are there any tasks that run jobs in parallel other than by running make -j?
Feb 09 14:27:06 <fray> i doubt there are
Feb 09 15:07:12 <kergoth> cmake or some other similar make replacements might, not sure
Feb 09 15:07:17 * kergoth shrugs and yawns
Feb 09 15:08:56 <JaMa> kergoth: fwiw I haven't seen any hang with your patch (and that small tweek with float->int) but this is without futures, where I haven't seen hangs before..
Feb 09 15:09:24 <kergoth> JaMa: k. well at least it didn't make it any worse for you, that's something :)
Feb 09 15:10:05 <JaMa> :)
Feb 09 15:25:35 <Zagor> has anyone produced training material for bitbake/yocto?
Feb 09 15:57:22 <d4ny> Zagor: There is a bunch of videos over here -> https://wiki.yoctoproject.org/wiki/Main_Page
Feb 09 15:59:42 <Zagor> d4ny: ah, nice
Feb 09 16:46:02 <ag> otavio: Would you please review my last 2 commits here: http://git.gherzan.ro/yocto-dev/changesets. Just take a look if you have time. Thanks in advance
Feb 09 16:46:58 * otavio looking
Feb 09 16:48:52 <otavio> ag: you are not moving dhclient to base_sbindir...
Feb 09 16:48:59 <otavio> ag: seems wrong to me
Feb 09 16:50:32 <ag> otavio: base_sbin?
Feb 09 16:51:26 <ag> otavio: Aren't we talking about base_libdir?
Feb 09 16:51:58 <otavio> http://git.gherzan.ro/yocto-dev/changeset/17d185de4280#chg_meta/recipes-connectivity/dhcp/dhcp.inc_oldline50
Feb 09 16:52:07 <otavio> ag: yes; but you dropped this code
Feb 09 16:53:13 <ag> otavio: Uh. I didn't push that commit. Just the openssl one.
Feb 09 17:01:36 <ag> otavio: uploaded the dhcp patch as well
Feb 09 17:22:32 <ag> Is there any way i can include a class in a an image file only for a specific MACHINE?
Feb 09 17:23:09 <khem> ag: thats quite goofy why would you do that
Feb 09 17:23:59 <ag> khem: :) For example i want to include sd_img class only for imx and not for a qemu or beagleboard as i use the same image for all of them.
Feb 09 17:24:53 <khem> well best I can suggest is if something is controllable in machine.conf
Feb 09 17:26:05 <ag> This is what i was looking for. But as well, this class should be loaded after rootfs is done. So this pointed me to the image file.
Feb 09 17:27:33 <khem> what does this class do anyway
Feb 09 17:27:45 <ag> Create an sd card image.
Feb 09 17:28:03 <ag> It is in freescale meta layer.
Feb 09 17:28:48 <ag> It uses parted and creates a boot-able sd-image from uboot, zimage and rootfs.
Feb 09 17:29:23 <khem> IMAGE_PREPROCESS_COMMAND_<machine> = "<task from sd_img>"
Feb 09 17:29:40 <khem> or post_process
Feb 09 17:29:43 <ag> YES.
Feb 09 17:29:44 <khem> whereever you want it
Feb 09 17:29:47 <ag> Post.
Feb 09 17:29:54 <ag> Thank you very much.
Feb 09 17:30:42 <khem> you want it after rootfs right ?
Feb 09 17:30:49 <khem> or after image generation
Feb 09 17:31:01 <ag> after rootfs.
Feb 09 17:31:39 <khem> ROOTFS_POSTPROCESS_COMMAND =+ "task"
Feb 09 17:31:42 <ag> ROOTFS_POSTPROCESS_COMMAND
Feb 09 17:32:07 <ag> And this can me machine dependent as well right?
Feb 09 17:32:27 <otavio> ag: both patches are OK :)
Feb 09 17:32:31 <khem> no
Feb 09 17:33:07 <ag> otavio: Thanks. You are my first oe friend. :)
Feb 09 17:33:16 <ag> khem: But this is what i want.
Feb 09 17:33:21 <ag> Only for a specific machine.
Feb 09 17:33:51 <ag> I guess it's not possible...
Feb 09 17:34:42 <khem> ag: where are the sources of this class
Feb 09 17:35:40 <ag> khem: freescale
Feb 09 17:36:37 <ag> khem: or you mean the sources as needed files?
Feb 09 17:38:01 <ag> khem: If so, it needs uboot, rootfs, and kernel from DEPLOY_DIR_IMAGE.
Feb 09 17:38:24 <otavio> ag: ahah :-) you're welcome
Feb 09 17:38:39 <khem> ag: the class itself
Feb 09 17:39:38 <ag> khem: Don't think i understand you question, sorry.
Feb 09 17:46:34 <khem> ag: I wanted to look at the class sources itself
Feb 09 17:46:42 <khem> nevermind found it
Feb 09 17:46:52 <ag> khem: Got it now. Wait a sec.
Feb 09 17:48:25 <ag> khem: https://gitorious.org/yocto/meta-freescale/blobs/master/classes/sdcard_image.bbclass
Feb 09 17:51:27 <khem> ag: ok you have to hack something like this http://paste.ubuntu.com/835498/
Feb 09 17:52:07 <khem> then rename that class to be called image-sdcard.bbclass
Feb 09 17:52:36 <ag> khem: oh. nice one!
Feb 09 17:52:48 <khem> then in your local.conf IMAGE_FSTYPES_append_beagleboard = " sdimg"
Feb 09 17:53:23 <ag> or in conf.
Feb 09 17:53:28 <ag> machine conf
Feb 09 17:53:55 <khem> yeah that works too you dont need the override then
Feb 09 17:54:14 <ag> yes
Feb 09 17:54:50 <ag> Thank you.
Feb 09 17:55:22 <khem> actually beaware of sdcard and sdimg I might have mixed it up
Feb 09 17:55:31 <khem> but you know now
Feb 09 17:55:52 <ag> khem: yes. thanks
Feb 09 17:56:03 <khem> np
Feb 09 18:37:58 <otavio> ag: they provide right feedback about the lib moving
Feb 09 18:38:19 <otavio> ag: you need to deal with case of base_libdir and libdir be the same
Feb 09 18:39:04 <otavio> ag: and also use sed with vars so it works with prefix not being usr
Feb 09 18:41:40 <ag> otavio: yes. They are right about those.
Feb 09 18:41:55 <ag> otavio: But should i move devel file to /lib as well?
Feb 09 18:42:10 <otavio> ag: fix and send the patch to your tree and i do a fast check
Feb 09 18:42:28 <ag> check as in build?
Feb 09 18:42:33 <otavio> ag: devel, not need but you need to be sure the links point to the right files
Feb 09 18:43:15 <ag> otavio: ok
Feb 09 18:56:36 <kergoth> JaMa: if you happen to have time at some point in the near future, could you test with https://github.com/kergoth/bitbake/compare/hang-issue-fix ? the current version of that branch should resolve the float vs int thing
Feb 09 18:57:57 <JaMa> kergoth: sure
Feb 09 18:58:09 <kergoth> thanks, appreciate it
Feb 09 19:07:52 <ag> otavio: o have to go. i will resend the patch later and send you an email. thanks for your help
Feb 09 19:07:56 <ag> i*
Feb 09 19:08:19 <otavio> ag: sure; np
Feb 09 19:44:41 <khem> sgw: did you have a chance to try my new patch for zlib ?
Feb 09 19:47:49 <ag> otavio: This should be it. http://git.gherzan.ro/yocto-dev/changeset/88908b5b45ae Hope i didn't miss anything again....
Feb 09 19:55:03 <sgw> khem, building now, yesterday turned out to be a bust for me, but I am  seeing an issue with sat-solver and gzread and gzclose on the qemuarm build
Feb 09 19:55:45 <khem> yes I am seeing that as well. when I build them alone
Feb 09 19:56:36 <sgw> khem: you working on resolution?
Feb 09 19:57:35 <khem> sgw: havent analysed it yet. but yes.
Feb 09 19:57:45 <khem> it could be something else in going wrong
Feb 09 19:58:00 <khem> zlib is crazy about supporting any weird platform and compilers out there
Feb 09 19:58:12 <khem> they use macros like ON OFF
Feb 09 19:58:20 <khem> which could be a problem here
Feb 09 20:00:21 <sgw> khem, thanks for looking into this one, I am sorry it opened up a larger mess.
Feb 09 20:02:10 <khem> sgw: yeah sometimes keeping the lid on is better
Feb 09 20:02:11 <khem> :)
Feb 09 20:08:18 <khem> sgw: would it be possible for you to squeeze in a uclibc based core-image-sato build for one arch say x86 for regular builds
Feb 09 20:08:45 <khem> now that it works we should keep it that way
Feb 09 20:09:48 <sgw> khem, I will talk with pidge about that, I think she has plans for other builds, but they are not implemented yet, probably for post 1.2 as we are staring to lock down changes on the AB for 1.2 release.
Feb 09 20:11:20 <khem> ok that would be nice
Feb 09 20:42:24 <pidge> sgw: Yes, there are plans for other builds. khem, if you email me directly with what you need, I'll see if I can get it incorporated before M4. I have 3 extra nightly targets going in (hopefully before M4, but if not, post-1.2 as no AB changes are allowed unless entirely needed in M4)
Feb 09 20:49:48 <khem> pidge: ok sent
Feb 09 20:50:06 <pidge> khem: ty. I'll look at this after ELC
Feb 09 20:52:24 <khem> pidge: fine
Feb 09 21:29:00 <ag> otavio: I modified a little my last commit.
Feb 09 21:29:07 <ag> otavio: This should be it.
Feb 09 21:30:05 <ag> otavio: Wanna take a look before sending it to oe-core?
Feb 09 23:53:15 * davest able to rejoin IRC, must have reinstalled the client correctly
Feb 09 23:53:27 <davest> Now for jabber...
Feb 10 00:12:32 <khem> heh
Feb 10 00:12:58 <khem> sgw: sat-solver was a lousy bit of programming. I have fixed it
Feb 10 00:13:11 <khem> sgw: you can grab the latest from kraj/misc
Feb 10 00:15:10 <sgw> Ok will do, so far other than that bit things are looking good.  I am really happy to say that World is mostly building clean, need to fix a couple of issues on some target machines
Feb 10 00:15:27 <khem> nice.
Feb 10 00:15:55 <khem> if you have servers which are bored let me know I can give you scripts that can keep them busy doing all kind of stuff
Feb 10 00:16:04 <sgw> I think we might add world targets to the nightly AB for 1.3 and hold peoples feet to the fire if it breaks!
Feb 10 00:16:22 <sgw> Not to worry, we keep our cpu's pretty active around here.
Feb 10 00:16:54 <sgw> I think for 1.3 we are going to try and get a regular fuzzy going again on at least on of the AB machines
Feb 10 00:17:03 <khem> currently I am running a build where its rebuilding each recipe from scratch
Feb 10 00:17:14 <khem> which will tell me any assumed deps
Feb 10 00:17:20 <khem> this will break a recipe
Feb 10 00:17:21 <sgw> nice, that will find all sorts of fun deps issues
Feb 10 00:17:39 <khem> yes and it can take a week to run all combos
Feb 10 00:17:48 <sgw> zenlinux had a script to do that for checking documentation, he used bitbake -s to generate the list.
Feb 10 00:18:32 <sgw> khem what else does it do eglibc vs uclibc, poky vs plain oe?
Feb 10 00:19:19 <khem> right now I only test with package_ipk and plain oe-core
Feb 10 00:19:31 <sgw> that takes a week?
Feb 10 00:19:37 <khem> oh no
Feb 10 00:20:06 <sgw> Oh, I bet you clean after each recipe, vs building in the same tmp space (which is what zenlinux does).
Feb 10 00:20:17 <khem> right now I have all kind of machines that e.g. angstrom supports
Feb 10 00:20:28 <sgw> ah ok
Feb 10 00:20:49 <khem> this is one of excercise I am doing with individual recipe build
Feb 10 00:21:00 <khem> but usually I let my machine do useful builds
Feb 10 00:21:09 <khem> no time for other things
Feb 10 00:21:22 <khem> it was prompted with zlib change
Feb 10 00:22:25 <khem> I think next in line would be to get rid of .la linking its evil at best
Feb 10 00:22:45 <khem> let me write a nuke_la task for laughs
Feb 10 00:23:03 <sgw> Khem, go for it!
Feb 10 00:23:12 <khem> we still have license warnings
Feb 10 00:23:21 <khem> someone should try to do another pass on it
Feb 10 00:23:32 <sgw> I can see break everywhere.
Feb 10 00:23:45 <khem> e.g. sat solver says WARNING: BSD for sat-solver could not be copied for some reason. It may not exist. WARN for now.
Feb 10 00:24:03 <khem> LICENSE = "BSD"
Feb 10 00:24:04 <sgw> regarding license warnings, pidge is still working that.
Feb 10 00:24:27 <sgw> I have also seen staticdev warnings that I need to fix.
Feb 10 00:24:36 <sgw> it's getting better slowly.
Feb 10 00:25:34 <khem> another thing I saw was we have 46 PARALLEL_MAKE = ""
Feb 10 00:25:41 <khem> that should be fixed as well
Feb 10 00:25:48 <khem> will give some built time perf boost
Feb 10 00:27:22 <khem> may be around 40 is what really are there
Feb 10 00:27:44 <khem> recipes-devtools/gcc/gcc-cross-canadian_4.6.bb has it
Feb 10 00:27:46 <khem> I wonder why
Feb 10 00:28:39 <sgw> no idea
Feb 10 00:29:06 <khem> that must be really a looong compile
**** ENDING LOGGING AT Fri Feb 10 02:59:57 2012

**** BEGIN LOGGING AT Fri Feb 10 02:59:57 2012
**** BEGIN LOGGING AT Fri Feb 10 07:28:11 2012
Feb 10 07:53:06 <Zagor> where do I find the actual tasks/features from https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.2_Status ?
Feb 10 08:12:00 <sgw> Zagor: look at the schedule page that's associated with 1.2, will post it in a minte
Feb 10 08:13:03 <sgw> Zagor: https://wiki.yoctoproject.org/wiki/Yocto_1.2_Schedule also check the first link [1] just under the Yocto Project 1.2 header for the bugzilla entries that shows what's resolved and pending.
Feb 10 08:13:52 <Zagor> excellent. thanks!
Feb 10 08:18:05 <mckoan> good morning
Feb 10 08:18:23 <halstead> We just had a small downtime on the main website. All service should be normal now.
Feb 10 08:19:46 <sgw> halstead: what happened?
Feb 10 08:19:58 <halstead> Security update for openssl.
Feb 10 08:20:12 <sgw> good deal thanks
Feb 10 08:20:18 <halstead> It doesn't look like anyone received a page load error.
Feb 10 08:20:30 <halstead> Did you see any issue on the wiki?
Feb 10 08:20:44 <sgw> nope just looked at 5 minutes ago and it was fine
Feb 10 08:21:38 <halstead> It shouldn't have caused any problems but I wanted to mention in case anyone had a page load timeout.
Feb 10 09:32:26 <d4ny> Hi All, is there anyway to tell yocto to do shallow clone:s of SRCU_URI git repos ?
Feb 10 09:32:40 <d4ny> s/yocto/bitbake/g
Feb 10 14:32:22 <walters> does Koen Kooi irc here?
Feb 10 14:35:44 <JaMa> not this channel
Feb 10 14:36:18 <walters> also, is there no image task in meta-oe?  I just wanted "bootable image for qemu with systemd" to look at it, i have git master of meta-oe and poky.  I could make my own image class inheriting from task-basic i guess but
Feb 10 14:37:03 <JaMa> you can add meta-angstrom for image recipes
Feb 10 14:44:27 <walters> you know what i need
Feb 10 14:44:38 <walters> is just a one-line definition of the terms here
Feb 10 14:45:08 <walters> i.e. poky, yocto, meta-oe, angstrom
Feb 10 14:45:13 <walters> and how these relate to each other
Feb 10 14:46:05 <walters> i get that meta-oe is a collection of recipes.  but the relationship between poky/yocto/oe-core is still fuzzy to me, and what makes angstrom different I still don't know after reading the whole FAQ
Feb 10 14:48:28 <walters> hm, maybe a key distinction of angstrom is it publishes the binary packages, so it's more like "linux distribution built with OE"
Feb 10 14:49:11 <bluelightning> and crucially, does not expect you to change its distro configuration
Feb 10 14:49:26 <walters> right, ok
Feb 10 14:50:06 <bluelightning> yocto is the umbrella project including a number of sub-projects, one of which is poky (the build system)
Feb 10 14:50:23 <walters> bluelightning, before you type more, let's figure out where to store this permanently
Feb 10 14:50:56 <walters> the yocto wiki?
Feb 10 14:51:00 <bluelightning> sure
Feb 10 14:51:03 <bluelightning> we do have a faq
Feb 10 14:51:34 <bluelightning> I think Jefro is currently addressing some of these definitions btw, so we might not need to do anything for the moment
Feb 10 15:02:34 <kergoth> morning
Feb 10 15:04:54 <JaMa> morning
Feb 10 15:05:05 <JaMa> kergoth: no hangs today :)
Feb 10 15:06:57 <kergoth> great, thanks
Feb 10 15:19:04 <JaMa> hmm zlib-native build somehow breaks system's /etc/ld.so.cache
Feb 10 15:20:12 <JaMa> I have to touch /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/libstdc++.so.6 && /sbin/ldconfig; calling ldconfig isn't enough to repair cache
Feb 10 15:27:17 <kergoth> that doesn't seem possible if you aren't running as root, unless its sneaking in a sudo or something :)
Feb 10 15:37:29 <JaMa> kergoth: shr-chroot is owned by user running build
Feb 10 15:38:19 <JaMa> exporting LDCONFIG = true is enough to circumvent it, but not sure if right solution
Feb 10 15:38:24 <JaMa> will send RFC to list and see
Feb 10 15:39:53 <kergoth> ah
Feb 10 15:40:31 <kergoth> I wonder if any similar issues are floating around that just aren't noticed due to running in a root/root fs
Feb 10 15:40:33 <kergoth> heh
Feb 10 15:42:02 <JaMa> at least for this libstdc++ issue I guess zlib is not only one calling ldconfig :/
Feb 10 15:42:21 * JaMa gtg, cya
Feb 10 16:11:02 <denisATeukrea> hi, is __stpncpy_chk implementation part of gcc or glibc ?
Feb 10 16:27:27 <msm> hmm
Feb 10 16:49:51 <denisATeukrea> not in gcc
Feb 10 16:49:55 <denisATeukrea> and not in glibc
Feb 10 16:50:01 <denisATeukrea> so I wonder where it can be
Feb 10 16:50:06 <denisATeukrea> *where it is
Feb 10 16:53:00 <denisATeukrea> maybe in the atomic builtin lib
Feb 10 17:09:16 <sgw> sgarman: I had to head out, back in about 1 hour
Feb 10 20:24:16 <ag> Hello.
Feb 10 20:24:54 <ag> I have a recipe which fails with "nspr-tests rdepends on nspr-dev"
Feb 10 20:25:14 <ag> I added: RDEPENDS_${PN}-tests = "${PN}-dev" But still nothing.
Feb 10 20:25:28 <ag> Am i missing something?
Feb 10 20:26:28 <bluelightning> ag: maybe it's complaining about the dependency rather than the lack of it...?
Feb 10 20:27:02 <ag> ERROR: QA Issue: nspr-tests rdepends on nspr-dev ERROR: QA Issue: nspr-tests rdepends on nspr-dev ERROR: QA run found fatal errors. Please consider fixing them.
Feb 10 20:27:28 <bluelightning> right, I think by default we assume that a non-dev package should not depend on a -dev package
Feb 10 20:27:40 <bluelightning> and therefore if one does then it's a bug
Feb 10 20:28:16 <ag> I see.
Feb 10 20:28:25 <ag> I didn't get that from code.
Feb 10 20:28:35 <ag> Thank you.
Feb 10 20:28:43 <bluelightning> if that's definitely not correct for your recipe you could use INSANE_SKIP to avoid the QA warning
Feb 10 20:28:43 <khem> denix:
Feb 10 20:28:59 <khem> ups
Feb 10 20:29:06 <denix> ?
Feb 10 20:29:27 <khem> denisATeukrea is whom I wanted to address
Feb 10 20:29:33 <khem> tab completion failed me
Feb 10 20:29:43 <khem> :)
Feb 10 20:30:04 <khem> btw. I just wanted to check if Denys you are awake and paying attention or not
Feb 10 20:31:18 <denix> always awake!
Feb 10 20:31:23 <denix> when not sleeping :)
Feb 10 20:31:33 <denix> khem: who's LC?
Feb 10 20:31:59 <khem> no idea
Feb 10 20:32:20 <denix> khem: aren't you at LC?
Feb 10 20:32:34 <khem> oh yes Linaro Connect
Feb 10 20:32:42 <khem> I was there monday and Tuesday
Feb 10 20:32:56 <khem> but had to span my days since I will be at ELC too
Feb 10 20:33:23 <khem> and cant go AWOL for 2 straight weeks where none of those conferences interest my employer :)
Feb 10 20:33:55 <khem> I might go tonight to say good bye to hrw and other tools folks
Feb 10 20:39:07 <ag> bluelightning: INSANE_SKIP_${PN} = "1" THis should skip all QA tests?
Feb 10 20:39:28 <bluelightning> ag: I don't think so; even if it did I'm not sure if you really want that
Feb 10 20:39:44 <ag> Yes i want. Just for test.
Feb 10 20:39:46 <bluelightning> you should name the test(s) to skip explicitly
Feb 10 20:40:44 <ag> as i see in insane.bbclass : WARN_QA ?= "ldflags useless-rpaths rpaths unsafe-references-in-binaries unsafe-references-in-scripts staticdev"
Feb 10 20:40:57 <ag> these are the test names?
Feb 10 20:41:03 <ag> uh no
Feb 10 20:41:11 <ag> ERROR_QA ?= "dev-so debug-deps dev-deps debug-files arch la2 pkgconfig la perms"
Feb 10 20:41:14 <ag> These are.
Feb 10 20:47:09 <ag> bluelightning: Still nothing... :(
Feb 10 20:48:12 <bluelightning> ag: so INSANE_SKIP_${PN} = "dev-deps" does not do it?
Feb 10 20:49:19 <ag> did an "insane" INSANE_SKIP_${PN} = "dev-so debug-deps dev-deps debug-files arch la2 pkgconfig la perms"
Feb 10 20:49:23 <ag> and didn't work
Feb 10 20:50:55 <bluelightning> ag: ah right, I think in your case it should be INSANE_SKIP_${PN}-tests = "dev-deps"
Feb 10 20:51:06 <bluelightning> ag: it's the specific package name that's needed
Feb 10 20:51:31 <ag> checking
Feb 10 20:53:06 <ag> it worked. Don't worry i know the riscs.
Feb 10 20:53:14 <ag> it worked. Don't worry i know the risks.
Feb 10 20:53:24 <bluelightning> ag: ok cool :)
Feb 10 20:53:36 <ag> bluelightning: thanks once again
Feb 10 20:53:40 <bluelightning> np :)
Feb 10 20:57:46 <ag> sgw: Are you around?
Feb 10 21:27:02 <khem> RP__: kergoth what do you think of a patch like this http://paste.ubuntu.com/837095/
Feb 10 21:27:22 <khem> this would help BBCLASSEXTEND a bit
Feb 10 21:27:32 <khem> I have not tested it fully
Feb 10 21:28:08 <kergoth> it shouldn't be 'virtclass-target', as it's not a virtual. beyond that naming issue, seems reasonably sane to me
Feb 10 22:10:24 <ag> bluelightning: Do we build tests fro packages?
Feb 10 22:10:26 <ag> for*
Feb 10 22:10:54 <ag> I mean in yocto. If a package come with a test suite do we build it as different rpm or something?
Feb 10 22:17:47 <bluelightning> ag: I don't think we currently do, no... we run build tests and sanity tests for images
Feb 10 22:19:23 <ag> bluelightning: For example i compiled nsfr with tests. I wanted to make sure that nsfr is ok.
Feb 10 22:19:49 <ag> And right now i don't know if a rpm -tests would be good.
Feb 10 22:37:29 <sgw> ag: I am around now
Feb 10 22:54:19 <otavio> bluelightning: combo-layer needs one fix
Feb 10 22:54:36 <bluelightning> otavio: what's the issue?
Feb 10 22:54:45 <otavio> bluelightning: in case you run it, and it has no change to commit, it rewrites the conffile and do another commit ;)
Feb 10 22:55:14 <bluelightning> otavio: ah right, yes, will fix that... thx
Feb 10 22:55:23 <otavio> bluelightning: ;-)
Feb 10 22:55:50 <otavio> have you built gtk+ after current patches ?
Feb 10 22:55:57 <otavio> it fails on me currently
Feb 10 22:57:03 <bluelightning> otavio: no, not since a week ago
Feb 10 23:00:34 <bluelightning> time to sleep... night all
Feb 11 02:22:25 <khem> kergoth: ok.
**** ENDING LOGGING AT Sat Feb 11 02:59:57 2012

**** BEGIN LOGGING AT Sat Feb 11 02:59:57 2012
Feb 11 12:47:54 <otavio> ag: hi
**** ENDING LOGGING AT Sun Feb 12 02:59:56 2012

**** BEGIN LOGGING AT Sun Feb 12 02:59:56 2012
**** ENDING LOGGING AT Mon Feb 13 02:59:58 2012

**** BEGIN LOGGING AT Mon Feb 13 02:59:58 2012
Feb 13 08:20:06 <mckoan> good morning
Feb 13 09:22:20 <bluelightning> hi all
Feb 13 09:22:49 <Zagor> hi
Feb 13 09:25:02 <JaMa> is someone already working on PR bumps to get rid of missing libz.la ?
Feb 13 09:25:11 <JaMa> I have list so I can send it today
Feb 13 17:13:43 <JaMa> khem: for some reason your PR bumps weren't enough in some cases so today I've sent another PR bump round which fixed it in my builds
Feb 13 17:14:21 <JaMa> maybe something in meta-oe was still pulling libz.la and then it ended in more .la files even when they were rebuilt
Feb 13 17:51:29 <khem> JaMa: yes thanks for doing it.
Feb 13 17:51:55 <khem> JaMa: its a difficult problem I think these kind of issues are rare but bound to happen
Feb 13 17:52:25 <khem> unless we get rid of .la completely which is a reality that I am seriously thinking about these days
Feb 13 17:52:26 <JaMa> agreed, I'm not complaing about your patch.. it's libtool fault anyway :)
Feb 13 17:52:56 <JaMa> pity that we cannot use lafilefixer like gentoo does to just "fix" .la files without rebuilding everything
Feb 13 17:53:11 <khem> yeah such a tool would be handy
Feb 13 17:53:29 <khem> but then why not get rid of it to start with
Feb 13 17:53:41 <khem> we have compilers that understand sysroot very well.
Feb 13 17:54:06 <khem> so probably not providing .la would make things better
Feb 13 17:54:37 <JaMa> lafilefixer expands included .la entries so when some project stops shipping .la then it won't fail and still finds correct lib
Feb 13 17:54:44 <khem> it would also fix the problem where packages dont have adjusted to new 2.4 libtool syntax etc.
Feb 13 17:54:51 <JaMa> so it makes transition a lot easier
Feb 13 18:58:38 <nitink> khem: ping
Feb 13 18:59:39 <khem> nitink: yes
Feb 13 19:00:03 <nitink>  khem: how do I influence the specs of resulting gcc
Feb 13 19:00:38 <khem> nitink: hmmm why do you need that I would ask first
Feb 13 19:00:53 <nitink> khem: for multilib
Feb 13 19:01:22 <nitink> I need to adjust the dynamic linker settings in the specs
Feb 13 19:01:22 <khem> nitink: ok and what would you like to change
Feb 13 19:01:47 <khem> nitink: so do you want to rebuild the compiler or not
Feb 13 19:02:09 <nitink> I want to modify building process so that I cen get specs output as I wanted
Feb 13 19:02:17 <JaMa|Off> khem: btw: I have just switched SHR to use gold.. I hope you still belive it's good idea :)
Feb 13 19:02:33 <khem> if you can rebuild the compile then gcc/config/<arch>/linux.h is best
Feb 13 19:02:39 <nitink> khem: I know I can add a specs file later also
Feb 13 19:02:42 <khem> JaMa|Off: I think its a good path to tread on
Feb 13 19:02:53 <nitink> khem: ok thanks for the tip
Feb 13 19:03:46 <khem> nitink: LINK_SPEC is i think the variable you need to muck with
Feb 13 19:04:18 <khem> JaMa|Off: btw. did you notice any build speedup becasue of gold ?
Feb 13 19:04:52 <nitink> khem: now I know where to look, will ping you later if I still need more help
Feb 13 19:05:05 <khem> JaMa|Off: I think I like the idea of munging la files to get rid of other .la dependencies
Feb 13 19:05:12 <khem> nitink: no worries
Feb 13 19:05:57 <khem> JaMa|Off: so I think we can have two way process where do la munging in any case its good and will speed up linking
Feb 13 19:06:07 <khem> second step means death to .la files
Feb 13 19:06:20 <khem> which would them make la munging moot later on
Feb 13 19:15:33 <JaMa|Off> khem: not yet.. but I wanted to enable gold now, because I'm rebuilding from scratch
Feb 13 19:16:30 <khem> JaMa|Off: ok.
Feb 13 19:16:42 <khem> JaMa|Off: dont expect a smooth ride with gold. for few reasons
Feb 13 19:16:45 <khem> 1. Its strict
Feb 13 19:16:51 <khem> 2. It does not overlink
Feb 13 19:17:15 <khem> so you might have packages not linking due to missing libs blah blah
Feb 13 19:17:20 <khem> but I think you know how to fix them
Feb 13 19:17:29 <khem> and those patches will make sense upstream as well
Feb 13 19:22:40 <kergoth> those should be fixed anyway, no? doesn't recent ld no longer do the implicit linking stuff?
Feb 13 19:22:43 * kergoth yawns
Feb 13 19:23:14 <JaMa|Off> khem: you with latest binutils from oe-core I had to fix those issues already
Feb 13 19:23:57 * kergoth got bit by it with the fall release codebench/sourcery toolchain
Feb 13 19:24:11 <khem> kergoth: hopefully but SHR has lot of layers which arent build by me regularly
Feb 13 19:24:37 <kergoth> i mean they need to be fixed whether we use gold or not, not that they're all arleady fixed :)
Feb 13 19:25:00 <kergoth> khem: didn't realize you're presenting at elc, cool
Feb 13 19:25:12 <khem> kergoth: yes I did not either unless last week :)
Feb 13 19:25:25 <khem> I will talk on layers
Feb 13 19:25:43 <khem> hopefully it will inform people new ways of doing things with OE
Feb 13 19:26:14 <khem> kergoth: will you be attending ELC
Feb 13 19:26:39 <kergoth> yeah
Feb 13 19:26:49 <kergoth> I'm sure there's no shortage of confused people wrt layers :)
Feb 13 19:27:46 <khem> yes
Feb 13 19:27:53 <khem> cool.
Feb 13 19:28:24 <khem> I would like to understand bitbake's memory consumption so may be talking to you will help
Feb 13 19:28:36 <khem> it currently holds 600M of memory during build
Feb 13 19:28:41 <khem> probably can be reduced
Feb 13 19:29:28 <khem> e.g. bsd make that we use here hold around 128M of memory at max during dep generation here and our codebase is lot larger than OE
Feb 13 19:33:22 <kergoth> I did some work on that in the past, but apparently either that was lost or more needs to be done
Feb 13 19:33:39 <kergoth> at one point it wouldn't build with 1024 megs of ram, it does in that now, but its still ridiculously high
Feb 13 19:35:00 <walters> note a big difference here is 32 bit hosts versus 64 bit hosts
Feb 13 19:35:12 <walters> the cpython interpreter is very pointer-heavy
Feb 13 19:44:38 <khem> kergoth: thats where golang can be handy since its compiled lang
Feb 13 19:50:32 <walters> khem, now you're just making stuff up; the fact that the language is "compiled" has only a tangential relationship to the amount of memory processes created with it will use
Feb 13 19:51:07 <walters> the fact that every Python object carries around a mutable dictionary *is* expensive
Feb 13 19:51:34 <walters> but one can easily make a language that "compiles" and also allows that
Feb 13 19:51:53 <walters> basically if you have a performance problem - use profiling tools
Feb 13 19:57:31 <walters> you can use __slots__ in python to drop the dynamic dictionary which can be a very large improvement if creating a large number of objects
Feb 13 19:57:32 <walters> http://docs.python.org/release/2.5.2/ref/slots.html
Feb 13 20:01:35 <khem> walters: I definitely was thinking something else when I wrote
Feb 13 20:01:44 <khem> however I was thinking of speed
Feb 13 20:01:56 <khem> at the expense of memory and different gc
Feb 13 20:02:20 <khem> we hold on to data for speed reasons
Feb 13 20:02:26 <khem> in some cases
Feb 13 20:03:01 <khem> treating bitbake like a compiler is probably not the right thing where memory usage is in spurts
Feb 13 20:03:15 <khem> it should be treated more like vm
Feb 13 20:37:12 <ag> otavio: Hello.
Feb 13 20:37:49 <otavio> ag: hi :)
Feb 13 20:38:07 <ag> otavio: I uploaded a version o patch for nspr with tests. I don't know where to install these tests in fs.
Feb 13 20:38:17 <ag> otavio: I picked /opt/nspr-tests.
Feb 13 20:38:26 <ag> otavio: But i don't think is the best idea.
Feb 13 20:38:47 <otavio> ag: i'd use ${libdir}/nspr/tests/
Feb 13 20:39:40 <ag> otavio: I you pick your experience. Thanks a lot.
Feb 13 20:41:11 <ag> i'll*
Feb 13 20:44:12 <otavio> ag: :)
Feb 13 22:29:35 <otavio> bluelightning: i didn't test your new patch yet but will do soon
Feb 13 22:29:46 <bluelightning> otavio: thanks
Feb 13 22:31:08 <otavio> bluelightning: np
Feb 13 22:31:25 <otavio> bluelightning: btw, why we still have qt 4.7?
Feb 13 22:32:10 <bluelightning> otavio: I want to hear from people using qt that they're happy for 4.7 to go away before removing it
Feb 13 22:32:32 <otavio> bluelightning: is there any regression from user's pov?
Feb 13 22:32:51 <otavio> bluelightning: i didn't update my systems to .8 yet but will do later this week
Feb 13 22:32:59 <bluelightning> otavio: I wouldn't know, I haven't extensively tested it
Feb 13 22:33:22 <bluelightning> qt is a pretty seriously-sized library
Feb 13 22:33:41 <otavio> bluelightning: but featurewise it is the same? the embedded (framebuffer) flavour
Feb 13 22:33:56 <bluelightning> otavio: it should be, yes
Feb 13 22:34:15 <bluelightning> otavio: like I said I want to hear from people using it "in anger" that 4.8 is ok
Feb 13 22:35:17 <otavio> bluelightning: i will give it a test later this week
Feb 13 22:35:36 <RP__> morning all
Feb 13 22:36:11 <otavio> morning
Feb 13 22:36:18 <khem> hi RP__ already in CA ?
Feb 13 22:36:20 * otavio in my world side, night
Feb 13 22:36:37 <RP__> khem: yes, arrived a short while ago
Feb 13 22:36:45 <khem> RP__: k,
Feb 13 22:36:51 <khem> welcome
Feb 13 22:36:55 * otavio envy people by not be there :)
Feb 13 22:37:02 <ant____> bluelightning: In sight of a less maintained meta-oe for the next months, how to proceed? Send RFC for first splits?
Feb 13 22:37:20 <RP__> otavio: "morning" as in arriving. My day started at 3am "local" time ;-)
Feb 13 22:37:29 <otavio> lol
Feb 13 22:37:51 <khem> weather is not best these days here
Feb 13 22:38:06 <bluelightning> ant____: I think it would be worth just proposing the splits before sending patches
Feb 13 22:38:10 <otavio> khem: here it is sunny and hot heh
Feb 13 22:38:13 <RP__> khem: so I noticed, I wasn't expecting to need the umbrella ;-)
Feb 13 22:38:36 <otavio> khem: et least, this is better here hehe
Feb 13 22:38:38 <khem> RP__: yes, hopefully it will get better and people drive so slow here when it rains
Feb 13 22:39:01 <RP__> khem: I dread to think what would happen with snow then ;-)
Feb 13 22:39:18 <RP__> khem: Its light drizzle, not rain...
Feb 13 22:39:20 <khem> RP__: heh
Feb 13 22:39:44 <khem> RP__: are you put up in same hotel as the conf ?
Feb 13 22:39:52 <RP__> khem: yes
Feb 13 22:40:51 <khem> RP__: I will be there tomorrow. I think if it rains I have to leave may be 30 mins early
Feb 13 22:41:19 <RP__> khem: People drive very differently in the US...
Feb 13 22:41:43 <khem> yeah
Feb 13 22:42:03 <ant____> yes, they insist keeping the right lane ;)
Feb 13 22:43:57 <khem> ant____ more so becasue left lanes are HOV lanes
Feb 13 22:44:10 <khem> and you dont want to pay 300+ dollars early in the morning
Feb 13 23:09:49 <otavio> RP__: is there a way to avoid two tasks to not run concurrently?
Feb 13 23:11:21 <kergoth> otavio: there's the lockfiles flag
Feb 13 23:12:02 <kergoth> but I don't think bitbake tries to adjust the runqueue to avoid trying to run them simultaniously going by the flag, so they could still run at the same time, just one would block
Feb 13 23:12:04 <kergoth> heh
Feb 13 23:12:27 <otavio> kergoth: I did it at https://github.com/OSSystems/meta-chicken/commit/ca868b52ca1af66406681b22231809c734d0f8f2
Feb 13 23:12:41 <otavio> kergoth: but it didn't work properly
Feb 13 23:13:33 <kergoth> otavio: lockfiles flag is a space separated list of lockfiles to automatically acquire on starting the task and release on ending it
Feb 13 23:14:18 <otavio> kergoth: i didn't understand ... have any example for me to look at?
Feb 13 23:14:34 <kergoth> yes, git grep is your friend
Feb 13 23:14:37 <kergoth> it's used in a number of places
Feb 13 23:14:50 <otavio> grep by lockfiles?
Feb 13 23:15:08 <kergoth> line 39 of rootfs_rpm.bbclass, line 128 of image.bbclass, etc
Feb 13 23:18:27 <otavio> kergoth: http://paste.debian.net/156168/ would be equivalent?
Feb 14 01:40:01 <RP__> khem:
Feb 14 01:41:15 <khem> RP__: yes
Feb 14 01:41:46 <RP__> khem: sorry, tab completion from earlier gone wrong :/
Feb 14 01:42:03 <khem> ok happens to me as wel
**** ENDING LOGGING AT Tue Feb 14 02:59:56 2012

**** BEGIN LOGGING AT Tue Feb 14 02:59:56 2012
Feb 14 09:11:07 <erbo> anyone using yocto (poky) + meta-ti to get pandaboard support?
Feb 14 09:41:43 <bluelightning> morning all
Feb 14 10:42:04 <otavio> bluelightning: morning
Feb 14 10:42:27 <bluelightning> hi otavio
Feb 14 10:45:44 <otavio> bluelightning: your patch worked :)
Feb 14 10:46:50 <bluelightning> otavio: great thanks for testing, will send a pull request out including it soon
Feb 14 10:47:22 <bluelightning> otavio: I also implemented your wish of being able to specify the component to update
Feb 14 10:47:33 <otavio> bluelightning: cool
Feb 14 10:47:43 <otavio> bluelightning: and branches
Feb 14 10:48:38 <bluelightning> otavio: you can already specify the branch for each component, or is that not what you mean?
Feb 14 10:48:59 <otavio> bluelightning: no no; this is what i meant
Feb 14 10:49:45 <bluelightning> branch = branchname
Feb 14 10:49:48 <bluelightning> (default master)
Feb 14 10:49:50 <otavio> ok
Feb 14 10:49:51 <otavio> :)
Feb 14 10:49:56 <bluelightning> although I still need to add it to the example config file
Feb 14 12:08:27 <JaMa|Off> khem: I've noticed that target gcc doesn't depend on target zlib but is looking for zlib.h, does it break sstate when I add zlib to DEPENDS in gcc-package-target.inc ?
Feb 14 12:17:04 <JaMa|Off> khem: ah found similar discussion in [PATCH] gcc-4.6: Some small performance tweaks thread and added it there
Feb 14 13:30:47 <ag> Cheers!
Feb 14 13:31:14 <ag> Is there any way i can skip a package from parsing / taking into build consideration in a image / build conf?
Feb 14 13:44:02 <ant_work> ag: http://cgit.openembedded.org/openembedded-core/commit/meta/conf?id=a9dc7873415a21f28270d7f81db3e3c39a09b8f6
Feb 14 13:50:40 <ag> ant_work: thank you
Feb 14 16:34:21 <JaMa|Off> khem: have you seen u-boot failing like this after switching to gold?
Feb 14 16:34:22 <JaMa|Off> | arm-oe-linux-gnueabi-ld: error: u-boot.lds:34:24: OVERLAY section type is unsupported
Feb 14 16:34:25 <JaMa|Off> | arm-oe-linux-gnueabi-ld: error: address of section '.bss' moves backward from 0x8004c6b0 to 0x8004c6a0
Feb 14 19:17:13 <khem> JaMa|Off: i submitted a patch to meta-ti for addressing this issue
Feb 14 19:19:11 <JaMa|Off> ok I'll check that ML.. thanks
Feb 14 19:19:28 <JaMa|Off> btw that zlib.h issues is imho also for that nativesdk case you mentioned before me in that thread
Feb 14 19:20:04 <khem> yes
Feb 14 19:20:34 <khem> uboot can not use gold so the patch alwyas uses gnu ld
Feb 14 19:21:20 <JaMa|Off> found it
Feb 14 19:22:58 <khem> ok
Feb 14 19:28:28 <JaMa|Off> sofar it looks good with gold, one patch for webkit-efl and resulting packages are a bit smaller (in most cases)
Feb 14 19:31:35 <hollisb> pseudo just segfaulted on me immediately after starting a build. any suggestions?
Feb 14 19:34:07 <seebs> ... that's interesting.
Feb 14 19:34:16 <seebs> The official answer is that there are no bugs in pseudo, only user errors.
Feb 14 19:34:23 <seebs> But a segfault... well.  That sounds bad.
Feb 14 19:35:31 <hollisb> http://pastebin.com/U8UJ3LaW
Feb 14 19:35:46 <hollisb> I'd be happy to provide more info if somebody tells me how :)
Feb 14 19:44:01 <seebs> First thing, I guess, would be to try to run something other than bitbake.
Feb 14 19:44:33 <seebs> What we ideally want is a minimal reproducer that illustrates the failure.
Feb 14 19:44:37 <seebs> Also, what's the host?
Feb 14 19:45:07 <hollisb> CentOS 5.4
Feb 14 19:45:55 <seebs> I guess I'd say start by making a copy of the script which is failing, and changing it so that it invokes <various setup> pseudo echo foo
Feb 14 19:46:19 <seebs> If that segfaults, that's pretty informative.  If it works, then we have to try to figure out what bitbake's doing that's triggering it.
Feb 14 19:46:21 <hollisb> well, if I just run the binary without any args, it also segfaults
Feb 14 19:56:04 <seebs> Well, the default is to try to invoke $SHELL.
Feb 14 19:56:28 <seebs> If you get segfaults from "pseudo echo foo", that's a more interesting data point, because then we know the called executable isn't doing anything interesting.
Feb 14 20:00:00 <hollisb> well, I deleted the pseudo binary and am rebuilding things
Feb 14 22:31:54 <hollisb> poky for beagleboard seems to be missing USB drivers, e.g. g_cdc
Feb 14 22:32:01 <hollisb> am I missing something?
Feb 14 22:45:59 <hollisb> hmm... meta-yocto/conf/machine/beagleboard.conf has usbgadget in MACHINE_FEATURES, but the modules don't exist in the build output
**** ENDING LOGGING AT Wed Feb 15 02:59:57 2012

**** BEGIN LOGGING AT Wed Feb 15 02:59:57 2012
Feb 15 06:18:49 <msm> JaMa: some section grew too large to satisfy where the linker script said that should go
Feb 15 07:45:32 <JaMa> msm: you mean the u-boot issue? resolved by khem's patch to disable gold
Feb 15 09:36:02 <bluelightning> morning all
Feb 15 10:29:34 <otavio> morning
Feb 15 12:24:32 <MWelchUK_work_> In meta/classes/image_types_uboot.bbclass, the IMAGE_CMD functions run the un-wrappered command followed by mkimage to wrapper them. For some reason these commands end up in the run script on a single line and this breaks the build. Shouldn't these commands be separated by a ";" or "&&"?
Feb 15 12:26:19 <MWelchUK_work_> I'm using the edison branch, these commands look the same in the head, but I'm not sure if something else has changed.
Feb 15 13:50:11 <denisATeukrea> hii, where does libc.h comes from?
Feb 15 13:50:15 <denisATeukrea> *hi
Feb 15 13:59:54 <denisATeukrea>  error: implicit declaration of function '__stpncpy_chk'
Feb 15 13:59:57 <denisATeukrea> oops
Feb 15 15:19:27 <sgw> bluelightning: you around?  Wanted to ask about the universe issue with virtual/* and Multiple .bb files, are you working on a patch for that?
Feb 15 15:23:24 <bluelightning> hi sgw, yes I sent a patch to the bitbake list the other day
Feb 15 15:24:12 <bluelightning> sgw: http://lists.linuxtogo.org/pipermail/bitbake-devel/2012-February/001856.html
Feb 15 15:24:31 <sgw> bluelightning: missed it I will look again, this time at the bitbake list!
Feb 15 15:24:41 <sgw> bluelightning: thanks, now out for a run.
Feb 15 15:24:46 <bluelightning> sgw: no worries
Feb 15 15:24:50 <bluelightning> sgw: enjoy :)
Feb 15 15:26:48 <sgw> bluelightning: patch looks good, just need to wait for RP on it now.
Feb 15 15:26:55 <sgw> bluelightning: thanks
Feb 15 15:30:05 <bluelightning> np
Feb 15 19:11:42 <otavio> ls -l
Feb 15 19:12:37 <JaMa|Off> p0rn
Feb 15 19:13:46 <JaMa|Off> drwxr-xr-x  9 bitbake bitbake 4096 Feb 13 16:42 yyy
Feb 16 00:05:43 <hollisb> is the .scc file syntax described anywhere?
**** ENDING LOGGING AT Thu Feb 16 02:59:57 2012

**** BEGIN LOGGING AT Thu Feb 16 02:59:58 2012
Feb 16 09:35:15 <bluelightning> morning all
Feb 16 09:38:25 <erbo> morning
Feb 16 09:51:03 <MWelchUK_work__> morning
Feb 16 11:16:43 <ag> Hello guys.
Feb 16 11:17:35 <ag> Is there anyway i can set a package preferred version in a image file?
Feb 16 11:18:54 <bluelightning> ag: no, this must be done as part of distro/local configuration
Feb 16 11:20:04 <ag> So, if a have a layer with multiple recipes version of a package, i cannot define 2 images with different package versions?
Feb 16 11:21:46 <bluelightning> ag: I don't think so, no...
Feb 16 11:21:55 <ag> Thank you.
Feb 16 11:22:20 <bluelightning> you might be able to fake it using RPROVIDES and RDEPENDS but that's not really what that mechanism is designed for
Feb 16 11:23:06 <ag> This is a little bit tricky.
Feb 16 11:23:17 <ag> It think is a needed functionality.
Feb 16 11:23:23 <ag> I*
Feb 16 11:24:21 <bluelightning> ag: are you able to be more specific about why you need this?
Feb 16 11:24:32 <ag> yes i can.
Feb 16 11:24:41 <ag> I have a Genivi package - layer-management.
Feb 16 11:24:49 <ag> With two versions.
Feb 16 11:25:19 <ag> My client needs a version of this package in a image1 and another version of this package in another image.
Feb 16 11:25:22 <ag> image2
Feb 16 11:28:29 <bluelightning> ag: is this for maintaining an older product and developing a newer one at the same time?
Feb 16 11:28:44 <ag> Exactly.
Feb 16 11:28:48 <bluelightning> ok
Feb 16 11:29:08 <bluelightning> normally I would expect people to use branches in the metadata to handle this, thus preserving the integrity of the older product
Feb 16 11:29:49 <ag> The source is a git repo.
Feb 16 11:30:08 <ag> With SRV_REV for every different version.
Feb 16 11:31:23 <bluelightning> an alternative way would be to have separate distro configs for each product, each setting PREFERRED_VERSION for the package as appropriate
Feb 16 11:32:02 <bluelightning> either way, you have more freedom to change the new product without affecting the old product than if the version was selected at the image level
Feb 16 11:34:21 <ag> Thank you for you suggestions. I will go with the distro idea.
Feb 16 12:04:31 <otavio> ag: For this, I'd do it differently
Feb 16 12:04:53 <ag> otavio: Shoot me! :)
Feb 16 12:05:27 <otavio> ag: I'd have a <package> <package>-<ng|master|next|etc>
Feb 16 12:05:37 <otavio> and use image to use one or another
Feb 16 12:06:08 <otavio> they are from different branches so clearly different packages for thsi case
Feb 16 12:11:56 <otavio> ag: works for your goal, i think
Feb 16 12:12:03 <otavio> ag: and avoids two distros
Feb 16 12:12:13 <otavio> ag: and reduce total build time
Feb 16 12:13:05 <ag> Uh. I good idea.
Feb 16 12:13:08 <ag> A*
Feb 16 12:22:08 <otavio> ag: did you also did nss package? besides nspr?
Feb 16 12:23:07 <ag> Nope. Only nspr.
Feb 16 12:24:34 <otavio> can you export the patch somewhere and put it for me to pick it? I want to update firefox build to use it
Feb 16 12:26:54 <ag> git.gherzan.ro
Feb 16 12:27:18 * otavio found so many problems in rootfs generation using ipk ... that is really sad that people seems to not test it very much
Feb 16 12:28:23 <otavio> ag: is it yocto or oe-core?
Feb 16 12:28:28 <ag> yocto
Feb 16 12:29:18 <otavio> grr ok :P
Feb 16 12:29:34 <ag> merged :)
Feb 16 12:30:00 * otavio is cloning it to export the patches ... 
Feb 16 12:30:05 <otavio> :-(
Feb 16 12:31:04 <ag> Smile. It's not over! :)
Feb 16 13:06:00 <otavio> ag: you merged yocto master; so it is not easy to spot what patches where not merge
Feb 16 13:06:04 <Zagor> argh. if I have multple kernel_x.y.z.bb files, and PREFERRED_VERSION_virtual/kernel = "3.0.21", why would bitbake choose another version? it insists on selecting my 3.2.6 recipe instead.
Feb 16 13:06:26 <otavio> ag: please, rebase them and export them for me to be able to pick them somewhere
Feb 16 13:07:23 <otavio> Zagor: something might be setting it to 3.2.6 later
Feb 16 13:08:17 <Zagor> nothing does. there is literally not a single file containing "3.2.6". is there some sort of "choose latest" logic somewhere?
Feb 16 13:09:52 <otavio> Zagor: yes, bitbake but P_V overrides it
Feb 16 13:10:09 <otavio> Zagor: ah
Feb 16 13:10:19 <otavio> Zagor: you need P_V_linux
Feb 16 13:10:34 <otavio> Zagor: and P_P_virtual/kernel = "linux
Feb 16 13:10:36 <otavio> "
Feb 16 13:15:56 <Zagor> aha, P_V_virtual/kernel is wrong?
Feb 16 13:16:51 <Zagor> right, P_V_linux fixed it. thanks!
Feb 16 13:19:05 <ag> otavio: Do you need this right now?
Feb 16 13:19:21 <ag> otavio: May  come back to this this evening.
Feb 16 13:19:24 <ag> ?
Feb 16 13:31:07 <otavio> ag: sure; this night works fine
Feb 16 13:31:25 <ag> Thank you.
Feb 16 13:31:42 <otavio> ag: i am trying to prepare a tree with changes i do need and will later maybe do a pull request with all this ... after well tested.
Feb 16 13:32:45 <ag> otavio: Are there changes not merged in my repo?
Feb 16 13:33:33 <otavio> ag: not yours but many others heheh
Feb 16 13:34:45 <ag> yes indeed
Feb 16 13:35:56 <otavio> ag: and i want to use yours to test our environment needs to see if it is going to break or not
Feb 16 13:36:26 <otavio> ag: am also in desire to get the systemd changes in our layer so we can prepare others that might depends on those
Feb 16 13:37:23 <ag> otavio: Tonight.
Feb 16 15:43:38 <MWelchUK_work__> Anyone seen this failure: http://dpaste.org/hYTQc/
Feb 16 15:44:25 <sgw> bluelightning: regarding qt3 branch, should I just move the edison 1.1.1 tag up to HEAD-1?
Feb 16 15:44:30 <sgw> MWelchUK_work__: looking
Feb 16 15:45:34 <MWelchUK_work__> On mainline. Didn't get it in Edison, but TBH the configuration is a bit different for each build
Feb 16 15:45:40 <bluelightning> sgw: yes that should be fine
Feb 16 15:45:41 <sgw> MWelchUK_work__: no, I have not seen that perl failure
Feb 16 15:46:05 <sgw> bluelightning: OK, I will work with folks here to straighten that out and get another 1.1.1 build going.
Feb 16 15:46:24 <MWelchUK_work__> sgw: There is no config.sh-x86-linux, but there is a config.sh-i586-linux
Feb 16 15:48:51 <sgw> MWelchUK_work__: what machine are you building for and did you tweak the machine configuration ?
Feb 16 15:49:35 <MWelchUK_work__> sgw: qemux86, just doing a comparison
Feb 16 15:52:03 <MWelchUK_work__> The newer sample local.conf is enabling buildstats. I'm running with image_type_uboot inherited, BB_N_T = 2; P_M = "-j 2" and modified fetch commands (to work around a killer local proxy).
Feb 16 15:52:33 <MWelchUK_work__> Haven't enabled our layer yet, hence compiling for qemux86.
Feb 16 15:58:07 <MWelchUK_work__> sgw: I assume this is a new dependence, I can't seem to find the build in my tmp dir for 1.1
Feb 16 16:00:11 <sgw> MWelchUK_work__: interesting, I do builds all the time and have not seen this failure
Feb 16 16:00:33 * MWelchUK_work__ wondering whether I'm using the right tree...
Feb 16 16:01:13 <MWelchUK_work__> git://git.yoctoproject.org/poky
Feb 16 16:01:30 <sgw> Was this a build that started with edison(1.1) and then you moved to master? Or fresh build in a new tmp dir for the master?
Feb 16 16:01:47 <MWelchUK_work__> Fresh build
Feb 16 16:02:58 <MWelchUK_work__> I had two builds running concurrently on my machine. I'm wondering whether something's gone a little wrong somewhere (different build and source trees)
Feb 16 16:03:17 <sgw> MWelchUK_work__: what's your host OS / Version
Feb 16 16:03:34 <MWelchUK_work__> Ubuntu 10.04
Feb 16 16:03:45 <MWelchUK_work__> 32-bit
Feb 16 16:03:56 <sgw> Oh, older OS, I wonder if that's causing the isssue.
Feb 16 16:04:18 <sgw> Alot of us are at ELC, I will touch base with some later this morning.
Feb 16 16:04:55 <sgw> My build show's Target arch is i586-linux in the first couple lines of the perl build.
Feb 16 16:05:03 <MWelchUK_work__> I tend to run LTS to LTS...
Feb 16 16:05:51 <sgw> MWelchUK_work__: understood.
Feb 16 16:06:24 <MWelchUK_work__> Thanks sgw
Feb 16 16:07:42 <MWelchUK_work__> sgw: I'll run a fresh build over night, with nothing else going to see what happens.
Feb 16 16:09:25 <sgw> MWelchUK_work__: can you post your log.do_configure in pastebin
Feb 16 16:11:17 <MWelchUK_work__> Um, sorry just blew it all away to start a fresh build for tonight.
Feb 16 16:11:30 <sgw> MWelchUK_work__: actually your run.do_configure.<pid> would be better, the last 5 lines or so creates the Cross/config file which sets x86
Feb 16 16:11:43 <sgw> MWelchUK_work__: or in my case I see the i586 is set for ARCH
Feb 16 16:12:05 <MWelchUK_work__> sgw: If it fails again tonight I'll try and do a bit more digging.
Feb 16 16:12:24 <sgw> MWelchUK_work__: oh well.  I am going to look backwards more, are you around alittle longer?
Feb 16 16:12:51 <MWelchUK_work__> sgw: Not long - getting towards home time for me.
Feb 16 16:13:29 <sgw> MWelchUK_work__: one small request then, can you run a bitbake -e perl > env and post the env file output.
Feb 16 16:13:39 <sgw> you might have to kill your current build and then restart
Feb 16 16:16:13 <MWelchUK_work__> sgw: http://dpaste.org/wqkag/
Feb 16 16:16:32 <MWelchUK_work__> Hmm, TUNE_PKGARCH_TMP="x86"
Feb 16 16:17:42 <MWelchUK_work__> Though looking at it, I'm not sure that's relevant.
Feb 16 16:18:09 <sgw> MWelchUK_work__: the TUNE_ARCH should be i586, PKGARCH is not what we are looking for
Feb 16 16:18:37 <hollisb> how can I get the kernel recipes to use a local (modified) copy of the linux-yocto-3.0 tree, instead of pulling it from git.yoctoproject.org?
**** ENDING LOGGING AT Thu Feb 16 16:19:53 2012

**** BEGIN LOGGING AT Thu Feb 16 16:20:20 2012
Feb 16 16:20:38 <MWelchUK_work__> hollisb, I think you'd need to provide at least a bbappend file in a layer or a whole new kernel bb file in a layer to do that.
Feb 16 16:21:12 <sgw> MWelchUK_work__: your TARGET_ARCH and TUNE_ARCH look correct
Feb 16 16:23:07 <hollisb> MWelchUK_work__: thanks... my trouble is always figuring out exactly which recipe to look at. there's a huge chain of them for the kernel
Feb 16 16:23:26 <MWelchUK_work__> sgw: I'll try the build again tonight. Thanks for your time.
Feb 16 16:24:13 <MWelchUK_work__> hollisb, np. I hope that's right, I'm a little more familiar with classic OE than Yocto...
Feb 16 16:24:22 <sgw> MWelchUK_work__: no worries, I will check with other today also.
**** ENDING LOGGING AT Thu Feb 16 16:24:35 2012

**** BEGIN LOGGING AT Thu Feb 16 16:26:17 2012
Feb 16 17:16:28 <sgw> ag: ping
Feb 16 17:16:51 <ag> sgw: pong
Feb 16 17:16:55 <ag> :)
Feb 16 17:17:07 <ag> I rebased the patches for otavio
Feb 16 17:17:33 <sgw> ag: thanks, I apperciate it, do you have a git repo or github location with your patch set?
Feb 16 17:18:00 <ag> Yes indeed.
Feb 16 17:18:07 <ag> git.gherzan.ro
Feb 16 17:18:12 <ag> git@bitbucket.org:agherzan/yocto-dev.git
Feb 16 17:18:22 <ag> Branch dev.
Feb 16 17:21:03 <sgw> ag, I now have 3 different gits from you, this one seems to require a key
Feb 16 17:23:53 <ag> Thi sneeds a key? git clone git@bitbucket.org:agherzan/yocto-dev.git
Feb 16 17:23:56 <ag> needs*
Feb 16 17:24:41 <sgw> ag: see my pm to you
Feb 16 17:46:06 <ag> holgerwrs: Hello Holger!
Feb 16 18:06:14 <ag> Is here anybody who used meta-xilinx with poky 1.2 lately ?
Feb 16 18:14:14 <ag> TARGET_ARCH was reanamed to TUNE_ARCH?
Feb 16 19:32:32 <paw> hi, trying to run a qemuppc image from git here and when I run "runqemu qemuppc", it hangs after "Running qmu-system-ppc..." message. Can anyone advise?
Feb 16 19:43:01 <hollisb> I cloned the linux-yocto-3.0 git tree, added a patch, and changed SRC_URI and SRCREV in meta/recipes-kernel/linux/linux-yocto_3.0.bb
Feb 16 19:43:34 <hollisb> however, when I try to build, I get "ERROR: Function failed: do_validate_branches"
Feb 16 19:44:04 <hollisb> and no further information is present in /mnt/poky.git/build/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto-3.0.18+git2+7af8d6f8769335b79c1b76c8bded256b8f909c74_1+368e38c673ffac8b37fc2a2d4c1e4a1e6f8abf19-r3/temp/log.do_validate_branches.4796, although the error message says there should be
Feb 16 19:44:07 <hollisb> what am I missing?
**** ENDING LOGGING AT Thu Feb 16 22:21:34 2012

**** BEGIN LOGGING AT Thu Feb 16 22:22:15 2012
Feb 17 00:54:06 * kergoth digs into bitbake memory usage a bit again
Feb 17 01:02:08 <kergoth> hmm, interesting, it's only showing about 30-40 megs of python objects in the server at various points. that's not too bad. time to check the individual python processes.. hmm, i wonder if heapy or meliae provide a diff/subtract mechanism to compare two memory objects
**** ENDING LOGGING AT Fri Feb 17 02:59:57 2012

**** BEGIN LOGGING AT Fri Feb 17 02:59:57 2012
Feb 17 03:38:31 <kergoth> aw, no __del__ usage in bitbake, so don't get to blame cycles+__del__ for memory issues
Feb 17 03:39:51 <kergoth> hmm, though, spoke too soon, it is used in the pysh code, but I don't think we keep around references to the pysh objects, and I don't see any cycles with those. ah well
Feb 17 04:16:09 <mebrown> any ideas why bitbake would exit with non-zero exit status on a successful build?
Feb 17 04:16:29 <mebrown> "NOTE: Tasks Summary: Attempted 2064 tasks of which 202 didn't need to be rerun and 0 failed.",   yet $ echo $?
Feb 17 04:16:29 <mebrown> 1
Feb 17 04:17:07 <mebrown> this is on edison with stock yocto + my layers
Feb 17 04:18:58 <kergoth> mebrown: it likely emitted ERROR messages. they cause a non-zero exit code. check the log/scrollback
Feb 17 04:19:31 <kergoth> newer yocto than edison uses a bitbake which now summarizes the number of errors seen, so you know why the exit code is what it is more easily
Feb 17 04:19:39 <mebrown> ah. ok.
Feb 17 04:19:42 <mebrown> grep time
Feb 17 04:19:44 <kergoth> yep
Feb 17 04:22:27 <mebrown> Guess who forgot to tee the output to a logfile. :/   rebuild time I suppose
Feb 17 07:52:50 <mckoan> good morning
Feb 17 08:35:07 <MWelchUK_work_> morning
Feb 17 10:18:57 <bluelightning> morning all
Feb 17 15:44:54 <kergoth> morning
Feb 17 15:58:04 <ag> Hello guys.
Feb 17 19:49:57 <kergoth> Hmm, how does one go about creating a page on the yocto wiki? Would I need special rights to do that, or ask someone to create the page for me?
Feb 17 19:51:08 <kergoth> (looking to create BitBake/PerformanceImprovement or similar, as a place to hold notes on bitbake's performance and analysis, so we have our discoveries in a single place
Feb 17 19:51:10 <kergoth> )
Feb 17 19:51:48 <kergoth> maybe Performance or PerformanceNotes would be better, less wordy
Feb 17 19:51:53 <fray> you should be able to go to the new page, and then edit..
Feb 17 19:52:12 <halstead> kergoth, visit https://wiki.yoctoproject.org/wiki/index.php?title=Special%3ASearch&search=BitBakePerformanceImprovement&go=Go
Feb 17 19:52:23 <kergoth> oh, right, i'm an idiot
Feb 17 19:52:28 <halstead> and click on the link after "Create the page"
Feb 17 19:52:31 <kergoth> didn't confirm the email address, you can browse but not create until after that :)
Feb 17 19:55:23 * kergoth 's finding cProfile.run/cProfile.runctx to be invaluable
Feb 17 19:57:28 <halstead> kergoth, were you able to confirm your e-mail and create the page?
Feb 17 19:58:01 <kergoth> yep, all good now, feel free to ignore me
Feb 17 19:59:28 <kergoth> RP__: did some basic task execution profiling, on this machine I have a per-task exec time of 0.6 to 1.0 seconds without exec_task in the mix (os._exit(0) before exec_task). I emitted cprofile data for the parse / cache load, and it turns out that parse is around 0.55 seconds of the total task run time on this machine
Feb 17 19:59:45 <kergoth> I'm curious about the remaining 0.1 to 0.5 seconds of overhead, though
Feb 17 20:00:09 <RP__> kergoth: Interesting. That sounds a lot higher than I remember the overhead being
Feb 17 20:00:41 <kergoth> this is in a VM on my macbook air, so I'm sure it's less on your beast of a machine :) but still quite interesting
Feb 17 20:01:40 <RP__> kergoth: Could be something to do with CoW in the VM
Feb 17 20:01:56 <RP__> We really depend on good CoW behaviour
Feb 17 20:02:14 <kergoth> that could be. I noticed there's roughly 34M of unique set size for each task process, by the way. not sure how accurate smem is in that context, need to check meliae on the tasks yet
Feb 17 20:02:37 <kergoth> on this machine, the parse process gets up to 240 megs for just oe-core, but drops down to 70 megs in the main server process after that. not too bad
Feb 17 20:03:02 <kergoth> I expect depends_cache is the majority of that spiking ram usage, what you'd expect
Feb 17 20:03:22 * kergoth digs in some more
Feb 17 20:05:44 <RP__> kergoth: In my case I see numbers like that but I never see the drop off - its as if the gc doesn't trigger
Feb 17 20:05:57 <kergoth> Hmm, that's quite interesting
Feb 17 20:06:09 <kergoth> we should investigate the gc behavior, I know there are controls  you can fiddle with
Feb 17 20:08:26 <RP__> kergoth: I've wondered if we could tweak anything
Feb 17 20:34:22 <kergoth> one task parse, 22387 ast.walk calls? sheesh
Feb 17 20:34:39 <kergoth> wonder how much of that was parse_python
Feb 17 20:35:16 <kergoth> ah, right, yep, there it is
Feb 17 20:36:15 <kergoth> aside: python -m pstats <profile data> is a nice interactive way to explore the profile
Feb 17 20:39:30 <kergoth> RP__: ah ha the pstats browser lets you add other profile data to its  statistics, so you can join together the data from multiple workers, or workers + server to get an overall picture!
Feb 18 01:34:55 <RP__> kergoth: Both those things sound rather interesting. I'll have to play around
**** ENDING LOGGING AT Sat Feb 18 02:59:58 2012

**** BEGIN LOGGING AT Sat Feb 18 02:59:58 2012
Feb 18 21:02:06 <R2D2> hello
**** ENDING LOGGING AT Sun Feb 19 02:59:58 2012

**** BEGIN LOGGING AT Sun Feb 19 02:59:58 2012
Feb 19 12:49:37 <CcSsNET> yocto support bcm47xx series? specificly the common ethernet of this series? is there support for ubicom32 v5? (ip8k chips)
Feb 19 12:53:55 <CcSsNET> i ment to type also inbetween those questions... woops
**** ENDING LOGGING AT Mon Feb 20 03:00:00 2012

**** BEGIN LOGGING AT Mon Feb 20 03:00:00 2012
Feb 20 08:58:37 <bluelightning> morning all
Feb 20 18:51:00 <ag> Hello everybody.
Feb 20 18:51:14 <ag> One tiny question.
Feb 20 18:52:12 <ag> In kernel do install we remove modules.order and modules.buildin.
Feb 20 18:52:24 <ag> Why?
Feb 20 19:52:51 <ag> Anybody around?
Feb 20 20:05:54 <seebs> People are often not around, but page back in occasionally.
Feb 20 20:06:15 <seebs> When I switched from asking whether people were around to just writing up my question to a quiet channel, I started getting lots more helpful answers.
Feb 20 20:06:23 <seebs> ... some of them 2-3 hours after I wrote the questions.
Feb 20 20:06:40 <kergoth> indeed. IRC is typically quite async. ask the question, wander off and get the answer whenever it arrives
Feb 20 20:06:56 <kergoth> one of the best things about it, really. fewer issues with timezones
Feb 20 20:07:23 <khem> ag: we did not ship them ever in oe are you seeing issues ? we do cross module stuff
Feb 20 20:08:41 <ag> khem: Got over that. But i need these files.
Feb 20 20:08:55 <ag> And i found a very strange behavior.
Feb 20 20:08:57 <khem> if they are to be packaged they should go with kernel image package
Feb 20 20:09:06 <ag> Wanted to add them in base-files.
Feb 20 20:09:13 <khem> base files ?
Feb 20 20:09:23 <ag> Just add them there.
Feb 20 20:09:34 <khem> empty ?
Feb 20 20:09:38 <ag> Yes.
Feb 20 20:09:45 <ag> I need them to avoid a warning
Feb 20 20:09:57 <khem> what is the warning ?
Feb 20 20:09:59 <ag> at runtime
Feb 20 20:10:01 <ag> kmod
Feb 20 20:10:05 <ag> not in poky
Feb 20 20:10:34 <khem> ok what is the warning ? is this warning valid
Feb 20 20:10:52 <ag> modules.order: No such file or directory
Feb 20 20:10:54 <khem> or is kmod being overly paranoid
Feb 20 20:11:01 <ag> yes it is
Feb 20 20:11:06 <ag> but i just want to avoid this
Feb 20 20:11:16 <ag> and i added these file in base files
Feb 20 20:11:16 <khem> ok then kmod should be fixed since these files are not must they are optional
Feb 20 20:11:40 <ag> added /lib/modules/${KERNEL_VERSION}
Feb 20 20:11:43 <ag> in dir744
Feb 20 20:11:58 <ag> dirs755
Feb 20 20:12:15 <ag> But it just ignores my install lines.
Feb 20 20:12:25 <ag> and de /lib directory is not installed anymore at all
Feb 20 20:12:31 <ag> the*
Feb 20 20:12:44 <ag> What the???
Feb 20 20:13:16 <ag> After seeing this... i did a checkout on base-file, clean + rm sstate and... NO LIB DIR in image!
Feb 20 20:13:30 <ag> LIB DIR = /lib
Feb 20 20:13:39 <ag> shoot me... if you got any idea
Feb 20 20:16:14 <ag> khem: what do i do wrong?
Feb 20 20:17:53 <khem> add install -d /lib/modules/${KERNEL_VERSION}
Feb 20 20:18:34 <ag> I did this in dirs755
Feb 20 20:19:06 <ag> i added in dirs755 that path and then in install there is a for for this:
Feb 20 20:19:08 <ag> for d in ${dirs755}; do
Feb 20 20:19:16 <ag> install -m 0755 -d ${D}$d
Feb 20 20:19:38 <ag> nothing works...
Feb 20 20:20:49 <ag> and these lines: <------>install -m 0644 ${WORKDIR}/modules.dep ${D}/lib/modules/modules.dep
Feb 20 20:20:49 <ag> <------>install -m 0644 ${WORKDIR}/modules.order ${D}/lib/modules/modules.order
Feb 20 20:20:49 <ag> <------>install -m 0644 ${WORKDIR}/modules.builtin ${D}/lib/modules/modules.builtin
Feb 20 20:20:53 <ag> are just skipped
Feb 20 20:20:57 <ag> no error
Feb 20 20:21:03 <ag> no log no nothing
**** ENDING LOGGING AT Tue Feb 21 02:59:58 2012

**** BEGIN LOGGING AT Tue Feb 21 02:59:58 2012
Feb 21 10:11:08 <bluelightning> hi all
Feb 21 10:56:55 <ag> bluelightning: Hi!
Feb 21 10:57:05 <bluelightning> hi ag
Feb 21 11:31:23 <kenws> Hi there, I've heard that there was a presentation at the Yocto Developer Day about harddrives killed due to the yocto (daily?)build.
Feb 21 11:31:43 <kenws> Being held by the build manager or similar - I don't remember : /
Feb 21 11:32:00 <kenws>  Does anyone know if her talk/presentation can be found online?
Feb 21 12:33:07 <kenws> (probably the talk wasn't about dying hdds exclusively but touched this topic at least)
Feb 21 15:29:10 <d4ny> Hi All, what packages are included in the meta-toolchain and how do I control it ?, all packages using BBCLASSEXTED = "nativesdk" ??
Feb 21 16:08:04 * fray needs to figure out his yocto ToDo items.. been out of the way for too long w/ meetings, travel and holiday yesterday
Feb 21 16:15:20 <RP__> d4ny: There is a list in one of the task-* packages
Feb 21 16:15:32 <RP__> fray: I know the feeling...
Feb 21 16:15:44 <fray> did Song just say there are no bugs?
Feb 21 16:15:52 <fray> so we're good..  woohoo, no more work
Feb 21 16:16:02 <RP__> fray: for 1.1.1 ;-)
Feb 21 16:16:20 <Zagor> :-)
Feb 21 16:16:26 <fray> drat
Feb 21 16:16:26 <RP__> Is Bjorn here?
Feb 21 16:16:31 <Zagor> RP__: that's me
Feb 21 16:16:48 <RP__> Zagor: ah, we should get people to include their irc names :)
Feb 21 16:17:02 <Zagor> hehe
Feb 21 16:17:11 <RP__> Zagor: I hope the call isn't too confusing with all the names and people
Feb 21 16:17:53 <d4ny> RP__: task-core-sdk  I guess
Feb 21 16:17:55 <RP__> Zagor: good to have you there though!
Feb 21 16:18:00 <Zagor> thanks
Feb 21 16:18:24 <RP__> d4ny: task-sdk-host-nativesdk
Feb 21 16:18:45 <RP__> Zagor: If you want to know who anyone is or have any questions feel free to ask here or on the call
Feb 21 16:19:14 <d4ny> Zagor: Sorry, I missed that meeting.
Feb 21 16:19:32 <Zagor> RP__: ok. I'm sort of standing quietly in the back learning still.
Feb 21 16:19:46 <RP__> Zagor: thats fine :)
Feb 21 16:41:59 <fray> he's probably talking to mute.. ;)
Feb 21 16:45:15 <JaMa|Off> RP__: when you have time I have another round of interesting sstate issues :)
Feb 21 16:47:07 <Zagor> [meeting] I'm rather having the opposite feeling, that bitbake isn't parallelizing aggressively enough
Feb 21 16:48:15 <RP__> Zagor: I was specifically talking about memory usage for the task execution
Feb 21 16:48:32 <RP__> Zagor: Where do you feel it could be more parallel out of interest?
Feb 21 16:48:32 <Zagor> right, it's not exactly the same issue.
Feb 21 16:48:57 <RP__> Zagor: I have done a lot of work trying to get more parallelisation but I'd love to find more ways to improve! :)
Feb 21 16:49:04 <RP__> JaMa|Off: Sounds like we need to talk
Feb 21 16:49:11 <halstead> pidge, Do you want to do a follow up call with me?
Feb 21 16:49:18 <RP__> JaMa|Off: I did see some emails from you but haven't had a chance to read them yet
Feb 21 16:49:53 <Zagor> I haven't looked into it in detail but I get the feeling it's blocking on packages that are not bottlenecks for the rest of the build. but I need to investigate more to be sure.
Feb 21 16:50:36 <JaMa|Off> RP__: yup, one is maybe just bug in bitbake-diffsigs.. but 2nd (with RDEPENDS on machine specific recipes) seems like conceptual problem
Feb 21 16:50:47 <pidge> halstead: sure, have my number?
Feb 21 16:50:57 <halstead> pidge, yep.
Feb 21 16:51:56 <RP__> JaMa|Off: I agree there is a conceptual issue there. We started to address it with changes like http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/lib/oe/sstatesig.py?id=0bf6f8035cfe14dbc2b357bdc3e98d6e081561a1
Feb 21 16:52:11 <RP__> JaMa|Off: This is the cleanest way I could find to handle this
Feb 21 16:52:14 <bluelightning> kenws: I'm told the sessions were videoed and should be posted as soon as they get processed
Feb 21 16:52:28 <bluelightning> kenws: (the presentations, at least)
Feb 21 16:53:48 <JaMa|Off> RP__: ah.. I was wondering how x11-common is not depending on formfactor but my xinput-calibrator depends on pointercal-xinput config recipe.. that could be it
Feb 21 16:55:01 <JaMa|Off> RP__: but this would be much nicer declared in recipe then in global sstatesig.py as I have few more recipes in meta-oe and meta-smartphone too
Feb 21 16:55:11 <RP__> JaMa|Off: I'm hoping we can isolate this list to a smaller list of known good packages
Feb 21 16:55:12 <kenws> bluelightning: aah, ok - sounds good. : ) Please let me know if you spot them.
Feb 21 16:55:19 <bluelightning> kenws: will do
Feb 21 16:55:29 <kenws> thanks!
Feb 21 16:55:32 <bluelightning> kenws: I wasn't there either so I'm keen to catch up as well :)
Feb 21 16:55:35 <RP__> JaMa|Off: We could do that globally but in reality people would just do it everywhere there is a PACKAGE_ARCH = MACHINE_ARCH
Feb 21 16:55:50 <RP__> JaMa|Off: I think we need to be careful about machine specific dependencies
Feb 21 16:57:25 <JaMa|Off> RP__: well but this doesn't cover my test case with kernel-module-* :/
Feb 21 16:57:56 <RP__> JaMa|Off: The kernel module issue I have noticed and don't have a good answer for
Feb 21 16:58:37 <JaMa|Off> because sometimes such recipe (e.g. RRECOMMENDING some kernel module) is pretty deep in dependency tree and everything above is reexecuting do_package
Feb 21 16:58:39 <RP__> JaMa|Off: That code can't tell why there is a dependency as at the level it operates it just sees a dependeny on linux-*
Feb 21 16:58:57 <RP__> JaMa|Off: yes, this is a problem :/
Feb 21 17:01:34 <JaMa|Off> cannot we introduce something like RRECOMMENDS_${PN} = "kernel-module-foo" and then RRECOMMENDS_${PN}[taskdepsexclude] = "something" ?
Feb 21 17:01:36 <bluelightning> sgw / RP__: when did we disable rootless X? I built an image prior to FOSDEM and that was still using it (in broken form)
Feb 21 17:02:27 <JaMa|Off> so that sstate code will detect from taskdepsexclude that we don't care how kernel-module-foo is built or if it's built at all, that we just want right metadata field filled in .ipk or .rpm
Feb 21 17:04:15 <ant_work> bluelightning: have you added meta-oe to that build?
Feb 21 17:04:40 <bluelightning> ant_work: I don't think I did, but let me check
Feb 21 17:05:48 <bluelightning> ant_work: no, just poky + a small layer for pinpoint
Feb 21 17:06:41 <ant_work> ah, ok then
Feb 21 17:15:26 <JaMa|Off> sgw: ping.. "The zlib patches were pulled" I have seen only PR bumps pulled.. not 2nd zlib patch from that pull request (which is still valid)
Feb 21 17:16:41 <sgw> JaMa|Off: PR Bump and the remove ldconfig was pulled:
Feb 21 17:16:41 <sgw> b2196ca zlib: remove ldconfig call from install-libs
Feb 21 17:16:41 <sgw> 0761649 recipes: bump PR to rebuild .la files without libz.la
Feb 21 17:16:55 <sgw> JaMa|Off: am I missing another one?
Feb 21 17:17:27 <JaMa|Off> no but I don't see b2196ca http://git.openembedded.org/openembedded-core/log/ or in git pull --rebase
Feb 21 17:17:58 <JaMa|Off> but it's in poky
Feb 21 17:18:21 <JaMa|Off> maybe just pending git push somewhere :0
Feb 21 17:20:46 <sgw> JaMa|Off: yeah, that's weird because normally they would be in oe-core first
Feb 21 17:22:23 <bluelightning> Richard is in a meeting atm but I'm sure he will look at it afterwards
Feb 21 17:22:25 <sgw> JaMa|Off: it might be stuck in RP__'s local repo still and he needs to push it.
Feb 21 17:24:20 <JaMa|Off> sgw: yup.. then it's relatively safe, thanks
Feb 21 17:25:59 <halstead> pidge, ab02 is ready with the minimum -devel packages as listed in the quickstart. (38 total with dependencies)
Feb 21 17:33:10 <pidge> halstead: Ok, I'll kick a world and see if anything blows up. I have ab02 out of the pool now.
Feb 21 17:40:08 <RP__> JaMa|Off: sorry, my fault. It was locally applied, I'd missed the push
Feb 21 17:53:23 <JaMa|Off> RP__: no problem, thanks
Feb 21 20:00:04 <autif1> qemuarm - does it have an FPU? If yes is it FPA or VFP? I need to define one of these (NONE, FPA, VFP) to compile mono.
Feb 21 21:35:59 <JDuke128> hello , on Windows every window has ID named HWND , on Linux , how can i access other apps windows? they have something like HWND ? My real problem is , i've java app , i want to show some video on C++ side combining with java but java slows up , I want to bypass Java side and directly render some video on HWND on Windows but i could not found any solution on Linux , how can i fix problem
Feb 21 21:48:35 <RP__> JDuke128: Its not really this room's area of expertise. I'd look at how some of the linux video player applications do it. There are X extensions iirc
Feb 21 22:04:40 <autif> tomz1 - /usr/bin/X: symbol lookup error: /usr/lib/xorg/modules/drivers/emgd_drv.so: undefined symbol: EDID_bin_read
Feb 21 22:04:49 <autif> I am on 1.2 M2
Feb 21 22:05:15 <autif> I followed the steps in README in meta-crownbay - for 1.8
Feb 21 22:05:26 <autif> copied the libs etc as described
Feb 21 22:08:32 <RP__> autif: tomz is not around today, will be back tomorrow
Feb 21 22:08:56 <autif> RP__ - thanks! will ping him tomorrow
Feb 21 22:09:42 <autif> on another note - mono ran wonderfully on ARM - trying out other qemu targets - mips, PPC, will have something on github tomorrow
Feb 21 22:09:51 <autif> will let people know on mailing list too
Feb 21 22:10:01 <autif> it is happenning :-)
Feb 21 22:18:15 <RP__> autif: sounds good, looking forward to the layer :)
Feb 21 22:18:30 <khem> autif: mono is known to work on x86 and arm it would be interesting to see how it does on ppc and mips
Feb 21 22:18:46 <khem> RP__: back home ?
Feb 21 22:19:31 <RP__> khem: yes, finally :)
Feb 21 22:21:38 <khem> RP__: when you have a time can you comment on http://lists.linuxtogo.org/pipermail/openembedded-core/2012-February/017689.html
Feb 21 22:22:18 <khem> this will give us an override depening on recipe type. Sometimes we do need target recipe override e.g.
Feb 21 22:23:33 <autif> khem - i meant the mono produced in the image by my recipe, w/o my recipe - mono is also known to run on mips and ppc - in fact - there are alpha, hppa, s390 and sparc as supported architectures. I will of course only test those for which yocto/poky has provided a qemu
Feb 21 22:23:49 <RP__> khem: it will break old school -native recipes mixed with virtclass
Feb 21 22:23:59 <RP__> khem: I guess we probably don't care now though
Feb 21 22:24:40 <RP__> autif: Did it work on arm first time out of interest?
Feb 21 22:25:53 <khem> RP__: hmm you mean foo-native.bb having a BBCLASSEXTEND = "native-sdk" or somesuch ?
Feb 21 22:26:03 <RP__> khem: I guess I'd just suggest a) calling it CLASSOVERRIDES b) drop the DISTRO ??= "" from that patch c) add directly to OVERRIDES, don't leave it until the end since that is less clear
Feb 21 22:26:16 <RP__> er, CLASSOVERRIDE
Feb 21 22:26:16 <khem> yeah that distro think it a cruft
Feb 21 22:26:44 <khem> ok will add your feedback thx
Feb 21 22:26:58 <RP__> khem: maybe assume its set and add the : in bitbake.conf too
Feb 21 22:27:04 <autif> nope - It was missing a declaration for FPU - NONE, FPA or VFP, but adding a -DARM_FPU_NONE=1 for CFLAGS_append made it work - no major errors after that - there was a packaging error - there are some .so files that are being included unnecessarily - strip fails on this files - I am not sure how to deal with this error - but it is benign
Feb 21 22:27:41 <RP__> autif: great, was just curious how we were doing on portability :)
Feb 21 22:27:54 <RP__> autif: Fancy writing a blog post? :)
Feb 21 22:27:58 <khem> guess you are testing on armv5t ?
Feb 21 22:29:18 <autif> I intend to - I talked with my powers that be - they are very excited about all this - there are 2 blog posts in the works - one talking about why we chose yocto over android, buildroot, LFS and desktop distros like ubuntu/fedora - and the second about what all I had to do to get mono recipe
Feb 21 22:30:09 <RP__> autif: sounds good - I'd love to get those some visibility with the yocto blog :)
Feb 21 22:30:14 <autif> these need to be pre-cleared by my manager(s)
Feb 21 22:30:21 <RP__> autif: no problem, I understand
Feb 21 22:30:27 <autif> what yocto blog?
Feb 21 22:30:35 <seebs> reason #3:  pseudo is so amazing that even if you don't actually use it it just makes life better to know it's there.
Feb 21 22:30:59 <RP__> autif: http://www.yoctoproject.org/blogs
Feb 21 22:31:25 <autif> are you suggesting I write these in yocto blog - because - one of the thinkgs open to debate is where do put these things - should we host it - or use somethign by google etc - if one exists for yocto - that owuld be ideal
Feb 21 22:31:49 <RP__> seebs: why am I tempted to reply with some performance numbers about it being frustrating? ;-)
Feb 21 22:32:27 <autif> RP__ - cool - have not seen this, do I have write permissions to this? does everyone? if yes, then i am amazed at lack of spam
Feb 21 22:32:28 <RP__> autif: if you post somewhere else I'm imagining we can link to it
Feb 21 22:32:32 <seebs> Well, keep in mind.  Pseudo's design goal was "it may be slow but it will not force us to abandon projects and rebuild from scratch".
Feb 21 22:32:46 <RP__> autif: I think we could also arrange for you to put something on there
Feb 21 22:33:00 <seebs> The prior state was that if I built 20-30 projects, at least one would fail with cryptic errors like "rmdir: cannot remove foo: File is a directory."
Feb 21 22:33:25 <autif> I am creating an account as we speak
Feb 21 22:33:26 <RP__> seebs: I know, but you did set yourself up for that reply ;-)
Feb 21 22:33:54 <seebs> nonsense!  pseudo is benevolent and well-loved.  people sing anthems to it every morning.
Feb 21 22:35:06 * RP__ notes to send seebs some performance figures
Feb 21 22:35:20 <seebs> ... Also worth noting, since I wrote it, computers have gotten enough faster that performance under pseudo is now probably better than it used to be without.  :)
Feb 21 22:35:39 * RP__ wonders if this argument can hold for bitbake
Feb 21 22:35:48 <RP__> it certainly does for parsing on a 12 core :)
Feb 21 22:36:46 <RP__> autif: if you've any problems please pester jefro or halstead can probably help too
Feb 21 22:36:55 <khem> RP__: reason to add CLASSOVERRIDE at the end was to have only one of this kind. if I do OVERRIDE += ".." in classes it might end with more than one of these in final OVERRIDES
Feb 21 22:37:15 <RP__> khem: I mean add to the OVERRIDES definition in bitbake.conf
Feb 21 22:37:28 <khem> RP__: ah thats what I thought secondly
Feb 21 22:37:34 <khem> ok
Feb 21 22:38:49 <khem> I hope the userspace chroot feature in kernel gets implemented soon
Feb 21 22:39:32 <ag> khem: userspace chroot in kernel soon?
Feb 21 22:40:17 <khem> containers
Feb 21 22:40:22 <ag> uh
Feb 21 22:40:35 <halstead> autif, New website users need extra permissions to post blog entries.
Feb 21 22:40:47 <halstead> autif, I can help with that when you're ready.
Feb 21 22:41:58 <autif> thanks halstead - I have an account now (username autifkhan) - I should have clearance in about a week - my VP is out on vacation returning in March - Will ping when he is back.
Feb 21 22:42:34 <halstead> autif, Great.
Feb 21 22:43:50 <Bagder> someone should clean the spam from the blog
Feb 21 22:44:15 <Bagder> clearly there's no filter or too eager admins
Feb 21 22:44:35 <Bagder> for example, see the comments to http://www.yoctoproject.org/blogs/sgarman/2011/proxy-problem
Feb 21 22:45:13 <seebs> Wow, yeah.
Feb 21 22:48:23 <khem> use akismet on wordpress works great
Feb 21 22:48:47 <Bagder> yes, that's great
Feb 21 22:49:01 <bluelightning> halstead: Jefro: ^
Feb 21 22:52:58 <Jefro> bluelightning thanks - missing part of the conversation, what happened?
Feb 21 22:53:12 <bluelightning> Jefro: spam on some of our blog posts apparently
Feb 21 22:53:35 <bluelightning> comment spam, that is
Feb 21 22:54:07 <ant__> dvhart: ping
Feb 21 22:55:45 <dvhart> pong
Feb 21 22:56:51 <ant__> hi there, I gave a try to linux-yocto-tiny but w/out proper magic th ekernel won't fetch...
Feb 21 22:57:29 <ant__> maybe I'm missing some layer to be able to provide my defconfig crumbs?
Feb 21 22:58:47 <dvhart> hrm... won't fetch?
Feb 21 22:58:59 <dvhart> are you using any layers?
Feb 21 22:59:23 <ant__> no, any Poky/Yocto layer atm
Feb 21 22:59:46 <dvhart> So currently the linux-yocto-tiny recipe uses the linux-yocto repository
Feb 21 23:00:01 <dvhart> The config is also not particularly minimized
Feb 21 23:00:18 <dvhart> I still need to push that into the meta data for linux-yocto tiny branch
Feb 21 23:00:24 <dvhart> (ktype rather)
Feb 21 23:00:31 <dvhart> but you should not have any trouble fetching
Feb 21 23:00:36 <dvhart> what is the exact error you receive?
Feb 21 23:00:58 <ant__> seems stalled fetching
Feb 21 23:01:49 <ant__> tring to fetch i.e. linux-yocto-tiny-3.0.12+git1+04a52a32cbdf0972033b97b83eaa83eb275dfdc9_1+f389d310965a56091f688b28ea8be6d9cbb7fbbe-r1
Feb 21 23:02:11 <dvhart> that's a *huge* git repository btw
Feb 21 23:02:21 <dvhart> how long have you let it run and what is your bandwidth?
Feb 21 23:02:36 <ant__> uh oh ....
Feb 21 23:02:47 <ant__> not so long tbh
Feb 21 23:03:13 <ant__> I have about 20MB D/L
Feb 21 23:03:32 <dvhart> ok, so you've got good bandwidth, it will still take a few minutes
Feb 21 23:03:42 <dvhart> if you haven't received an error, then it's probably just fetching
Feb 21 23:03:47 <dvhart> you can check your downloads dir
Feb 21 23:03:52 <dvhart> do a du on it
Feb 21 23:03:53 <ant__> Imy doubt is how to match my arm machine
Feb 21 23:03:59 <dvhart> ensure it's still growing
Feb 21 23:05:03 <dvhart> I think by itself that repo is something like 1.5 GB
Feb 21 23:05:21 <ant__> I'm a bit confused by the KMACHINE I should use: I decided to go with 'base'
Feb 21 23:05:34 <dvhart> are you building for a different machine?
Feb 21 23:05:59 <ant__> fyes, for some old armv4 and armv5te
Feb 21 23:06:11 <dvhart> OK
Feb 21 23:06:18 <ant__> usually I use vanilla
Feb 21 23:06:32 <dvhart> for now, the biggest difference between poky and poky-tiny is the userspace image
Feb 21 23:06:40 <dvhart> the kernel is still the same
Feb 21 23:07:07 <dvhart> I have to refactor all the config fragments and get them into the ktype/tiny definition in  linux-yocto
Feb 21 23:07:14 <ant__> ah, that's why #KMACHINE = "yocto/standard/tiny/base"
Feb 21 23:07:42 <dvhart> so for now, you might try your regular kernel via PREFERRED_PROVIDER_virtual/kernel
Feb 21 23:08:53 <ant__> can I add the (few) patches to SRC_URI for the moment?
Feb 21 23:09:46 <dvhart> of course, you can always do that
Feb 21 23:10:04 <dvhart> but just don't expect to get a very small kernel out of linux-yocto-tiny at the moment
Feb 21 23:10:13 <dvhart> the default config still builds a fairly large kernel
Feb 21 23:10:37 <dvhart> should be better by next week
Feb 21 23:11:17 <ant__> I've noticed the bits of code are adding in-kernel modules (=y)
Feb 21 23:11:37 <ant__> that's fine for me , at least for basic boot-features
Feb 21 23:11:52 <dvhart> which bits of code are you referring to?
Feb 21 23:12:05 <ant__> ata.cfg i.e.
Feb 21 23:12:09 <dvhart> ah
Feb 21 23:12:38 <dvhart> yes, in terms of getting a small userspace I opt to, by default, eliminate the need for an initrd
Feb 21 23:13:25 <ant__> you see, I squezed the defconfigs with do_savedefconfig and now I'm trying to modularize it
Feb 21 23:14:20 <ant__> but having to boot from SD/CF/USB and expecting ext2,3,4/vfat,jffs2,ubifs .. I have no chocie to compile modules
Feb 21 23:15:40 <ant__> in fact, at first I'm looking at linux-yocto-tiny to better modularize linux-kexecboot if I can
Feb 21 23:16:30 <dvhart> right
Feb 21 23:16:38 <dvhart> sorry I haven't gotten back to you on that btw
Feb 21 23:16:55 <ant__> btw there is a new meta-initramfs layer pending
Feb 21 23:16:56 <dvhart> still in my todo list
Feb 21 23:17:10 <dvhart> I'd like to have a look
Feb 21 23:17:15 <ant__> pls wait a couple of days more ;)
Feb 21 23:17:42 <Jefro> I*)&U spammers. I already got rid of them once.
Feb 21 23:21:05 <dvhart> ant__, no problem :-) please send me a link when you think it's ready
Feb 21 23:22:14 <ant__> sure, me and bluelightning we were discussing about where to host it
Feb 21 23:22:39 <ant__> at first will be committed in meta-openembedded/meta-initramfs I think
Feb 21 23:24:43 <ant__> but being it just depends on oe-core it could maybe live outside meta-openembedded
Feb 21 23:29:38 <Crofton|work> ant__, you can put layers inside meta-oe and enable them individually
Feb 21 23:29:57 <Crofton|work> that would reduce repo-madness :)
Feb 21 23:31:19 <ant__> sure, I did that as first step
Feb 21 23:31:44 <ant__> but as I said (too) many times, there are recipes within the layer which need special care
Feb 21 23:32:19 <ant__> like klibc and klcc-cross, very sensible to breakages due to changes in oe-core
Feb 21 23:32:54 <Crofton|work> that is true for many recipes
Feb 21 23:33:18 <ant__> and finally I think that at least klibc would belong to oe-core
Feb 21 23:33:40 <ant__> (so I can give up with maintenance ;)
Feb 21 23:38:10 <JaMa|Off> ant__: can you please try with reversed order of layers?
Feb 21 23:38:20 <ant__> heh
Feb 21 23:40:18 <JaMa|Off> strange.. your order looks like meta-handheld version should won.. ah that's probably because you're not building spitz right?
Feb 21 23:40:39 <ant__> yes, only poodle
Feb 21 23:41:08 <ant__> anyway you are right about moving alltogether
Feb 21 23:41:18 <JaMa|Off> and 3.2 version have only spitz in COMPATIBLE_MACHINES
Feb 21 23:41:38 <ant__> I just tested with a single .bbappend
Feb 21 23:42:15 <ant__> unfortunately klibc_2 is still delayed
Feb 21 23:42:32 <ant__> so we should stay with 3.1 or add patches
Feb 21 23:43:06 <ant__> or a klibc_git
Feb 21 23:43:15 <hollisb> when people talk about the meta-ti layer, are they referring to git://git.angstrom-distribution.org/meta-texasinstruments ?
Feb 21 23:43:53 <JaMa|Off> well 3.2 as kernel works fine, 3.1 is needed just to build klibc once :)
Feb 21 23:44:19 <ant__> yes, we can let it only in meta-initramfs
Feb 21 23:44:33 <JaMa|Off> so please don't remove recipes just because we don't have compatible klibc yet
Feb 21 23:45:47 <incandescant> hollisb: I believe so, one of it and http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/ is a mirror of the other
Feb 21 23:45:50 <denix> hollisb: http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/ which is currently the same as one at angstrom URL
Feb 21 23:46:08 <hollisb> ahh
Feb 21 23:46:26 <ant__> JaMa|Off: I'm looking at linux-yocto- kernels as next step
Feb 21 23:46:32 <hollisb> I've been wondering if meta-texasinstruments was intentionally named differently from "meta-ti"
Feb 21 23:46:36 <denix> just don't get used to the one on angstrom, as it might go away in the future, due to some infrastructure problems
Feb 21 23:46:51 <hollisb> meta-ti isn't listed at http://www.openembedded.org/wiki/LayerIndex ; should it be?
Feb 21 23:47:07 <denix> it is listed there
Feb 21 23:47:37 <hollisb> meta-texasinstruments is
Feb 21 23:47:39 <hollisb> meta-ti is not
Feb 21 23:47:57 <hollisb> (the former being the one you just told me might go away :)
Feb 21 23:48:06 <denix> meta-texasinstruments vs. meta-ti - historical reasons, first got renamed into second
Feb 21 23:48:44 <denix> the contents of both are the same, they are just public mirrors of our internal repository
Feb 21 23:49:31 <hollisb> I get that now, but when all I see is people talking about meta-ti, and all I have is meta-texasinstruments, I wondered if they're the same... so if there are also infrastructure issues, maybe LayerIndex should point to meta-ti instead?
Feb 21 23:50:21 <denix> ok, I'll update LayerIndex wiki with the new url...
Feb 21 23:50:39 <hollisb> cool
Feb 21 23:55:12 <bluelightning> denix: I can do that for you if you like
Feb 21 23:58:04 <denix> bluelightning: you don't trust people editing your page? :)
Feb 21 23:58:48 <bluelightning> denix: I don't mind either way... sometimes people don't already have access and it may be quicker for me, but if you want to do it go ahead :)
Feb 21 23:58:51 <denix> I'll be splitting meta-ti into sublayers soon, so will eventually need to populate repo subdir column too
Feb 21 23:59:08 <bluelightning> ok
Feb 21 23:59:24 <bluelightning> I have to admit I have not done that for meta-intel, probably should
Feb 21 23:59:37 <bluelightning> i.e. listed the sublayers out
Feb 22 00:00:43 <hollisb> denix: so if I just add meta-ti to my Yocto bblayers.conf, that will override the built-in beagleboard recipes?
Feb 22 00:00:55 <denix> bluelightning: well, don't you think oe director ought to have wiki access? :-P
Feb 22 00:01:21 <bluelightning> denix: I think yes, but that doesn't mean key people haven't been locked out before in recent times ;)
Feb 22 00:01:37 <bluelightning> not intentionally
Feb 22 00:01:50 <denix> bluelightning: I know, just teasing you :)
Feb 22 00:02:31 <denix> hollisb: not so easy, there were some issues reported recently with angstrom dependencies getting into the way when trying to use meta-ti with oe-core/yocto directly...
Feb 22 00:03:11 <denix> hollisb: you might want to read on the corresponding mail thread - there were some short-term workarounds suggested
Feb 22 00:03:11 <hollisb> :(
Feb 22 00:04:28 <denix> hollisb: but it's one of my tasks to make it work with oe-core/yocto as well as angstrom, arago etc., and not just angstrom
Feb 22 00:05:26 <hollisb> denix: do you have a link to that thread?
Feb 22 00:08:37 <hollisb> ah, it was a beaglebone thread?
Feb 22 00:09:58 <denix> https://lists.yoctoproject.org/pipermail/meta-ti/2012-February/thread.html - read the "building Yocto for Pandaboard" both threads (I don't know why it split in 2)
Feb 22 00:11:19 <hollisb> thanks
Feb 22 00:11:52 <dvhart> hollisb, heya ;)
Feb 22 00:13:38 <hollisb> hey dvhart
Feb 22 00:19:11 <ant__> gn
Feb 22 00:24:40 <halstead> bluelightning, Mollom is what most Drupal sites use instead of Aksimet. I've updated and enabled strict checking for it.
Feb 22 00:25:12 <bluelightning> halstead: ok cool, just wanted to draw your attention to the existing spam
Feb 22 00:26:16 <halstead> khem, ^
Feb 22 00:31:16 <halstead> We are going to disable viewing comments until we can get them cleaned up.
Feb 22 02:13:25 <nlogax_> anyone in here?
Feb 22 02:48:20 <seebs> Just ask and leave yourself logged in for a few hours.  IRC is mostly asynchronous.
**** ENDING LOGGING AT Wed Feb 22 02:59:58 2012

**** BEGIN LOGGING AT Wed Feb 22 02:59:59 2012
Feb 22 04:13:45 <nlogax_> I'm following the quickstart guide and when I try to build an image using 'bitbake -k core-image-sato' I get an error message. "ERROR: .../recipes-gnome/gnome-vfs_2.24.4.bb" failed amongst others. This is task 4367. I'm not sure what's going on.
Feb 22 04:20:30 <autif1> nlogax_ - still here?
Feb 22 04:25:46 <autif1> guess not, assuming that you are still there - take a look at tmp/work/<your chosen architecture>/gnome-vfs_2.24.xxx/temp and see what step failed
Feb 22 04:26:04 <autif1> you can also send the error to the mailing list where people can help
Feb 22 04:37:57 <autif1> gn now
Feb 22 04:46:31 <nlogax_> is there a specific file where I have to look?
Feb 22 12:06:32 <JaMa|Off> RP__: quick question.. is order of runtaskdeps important for hashing algoritm? or does http://paste.pocoo.org/show/554961/ look sane?
Feb 22 12:32:54 <ag> Hi! Is there any PREFERRED_PROVIDER_qemu = "qemu-custom" juslt for uboot and kernel?
Feb 22 12:35:48 <JaMa|Off> RP__: ignore this patch.. sorting is not enough.. I'll split it to 2 different cases (task was changed and same tasks with different checksums)
Feb 22 12:40:55 <otavio> :-)
Feb 22 12:41:28 <otavio> bluelightning: I did a fix in qt4-native; mind to take a look before I send the patch for pull?
Feb 22 12:42:01 <otavio> bluelightning: http://paste.debian.net/157180/
Feb 22 12:43:10 <otavio> bluelightning: we have some code generation tools that are written in qt4 that needs to be available for building the target packages, that's why i found this issue
Feb 22 12:44:09 <ant_work> JaMa|Off: any idea about what's happening to your build?
Feb 22 12:47:23 <JaMa|Off> ant_work: no..
Feb 22 12:47:50 <ant_work> as you've seen I got bitten by udev, needing meta-oe
Feb 22 12:47:58 <ant_work> but bitbake did signale that
Feb 22 12:53:34 <JaMa|Off> try to find someone with nickname jkd to confirm he had same configuration yesterday..
Feb 22 12:53:37 <JaMa|Off> 13:36:26 < jkd> I only get "ERROR: Command execution failed:"
Feb 22 12:53:40 <JaMa|Off> 15:00:17 < jkd> Is there anyway to get more info on why bitbake fails? first run after init oe-core it fails with only ERROR: Command execution failed: Exited with 1, -v and/or -DDD gives nothing more and cooker.log only gives same line
Feb 22 12:55:44 <ant_work> JaMa|Off: and he was also using meta-handheld ?
Feb 22 13:05:07 <JaMa|Off> no idea
Feb 22 13:32:08 <RP__> JaMa|Off: Right, there are a few cases to consider in that code :)
Feb 22 13:34:26 <JaMa|Off> RP__: it was there already, just hidden in one extra if :)
Feb 22 13:34:56 <RP__> JaMa|Off: I tried to fix that code recently but it sounds like I got the logic slightly wrong
Feb 22 13:36:56 <JaMa|Off> have you seen my patch? Imho it's step in right direction
Feb 22 13:50:07 <JaMa|Off> RP__: I'm looking at def get_taskhash code in siggen.py is there any way to pass more info to rundep_check (especially from where we got e.g. linux-gta04_git.bb.do_package_write dependency from RRECOMMENDS_${PN} or something else)
Feb 22 13:50:40 <JaMa|Off> RP__: I was trying to filter those kernel-modules but best I got is to drop all linux-*.do_package_write :/
Feb 22 14:10:21 <RP__> JaMa|Off: This is where I got stuck last time I looked too
Feb 22 14:11:09 <RP__> JaMa|Off: there is always a way but its not simple in this case :/
Feb 22 14:12:06 <JaMa|Off> I'm using this now, but maybe excludes more then what you would allow in default oe-core http://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/test&id=250d478a2d585408cc1c2ec90c1b11aa4d3cc341
Feb 22 14:13:10 <JaMa|Off> and I guess adding recipes from other layers like this http://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/test&id=8ca28c599a596341f43a2c3cd97394a3011e5ff9 also doesn't scale right :/
Feb 22 14:18:35 <ant_work> JaMa|Off: right, we have still to commit xinput-calibrator/pointercal
Feb 22 14:19:30 <ant_work> if this lands in oe-core we'll have a problem less
Feb 22 14:38:07 <RP__> JaMa|Off: I replied to the diffsigs patch, its not quite as simple as your patch :/
Feb 22 14:43:29 <JaMa|Off> ok I see what you mean, do you have some example where task is changed without hash change? or will any recipe rename work?
Feb 22 14:45:17 <JaMa|Off> "Dependency on task linux-nokia900-meego_git.bb.do_package_write was replaced by linux-gta04_git.bb.do_package_write with same hash." OK?
Feb 22 14:46:29 <RP__> JaMa|Off: I don't think we need to print anything in the case it matches
Feb 22 14:46:39 <RP__> JaMa|Off: bitbake will treat that as not being any different
Feb 22 14:47:56 <RP__> JaMa|Off: btw, in your patch above, i'd add:
Feb 22 14:47:56 <RP__> if depname.startswith("linux") and not (recipename.startwith("linux") or recipename.startwith("kernel")) and ...
Feb 22 14:48:12 <RP__> or something like that. I worry about external kernel modules in this context :/
Feb 22 14:52:22 <JaMa|Off> yes and also e.g. linux-libc-headers
Feb 22 14:56:57 <JaMa|Off> for -diffsigs I'm testing something like http://paste.pocoo.org/show/555052/
Feb 22 15:26:30 <RP__> JaMa|Off: I have an idea for the kernel issue in the sigs
Feb 22 15:26:39 <JaMa|Off> great
Feb 22 15:27:46 * JaMa|Off trying to debug why sstate_hardcode_path doesn't work sometimes
Feb 22 15:29:05 <JaMa|Off> I guess it packages sstate right, but if you still have image directory around and do_package is relaunched then it populates package with same old hardcoded paths from image
Feb 22 15:29:47 <JaMa|Off> and if you delete workdirectory and sstate has to unpack package from sstate-cache then it replaces paths right
Feb 22 15:42:41 <msm> what version of gcc is edison 1.1 supposed to ship with?
Feb 22 15:43:17 <msm> there is this patch:
Feb 22 15:43:18 <msm> git show fd70cc0a
Feb 22 15:43:27 <msm> which bumps to version but it appears to only add a patch
Feb 22 15:50:23 <msm> and it looks like our gcc recipe is using a different svn tag number than the official tag?  http://gcc.gnu.org/viewcvs/tags/?view=log
Feb 22 15:51:07 <msm> which is 180516 - where as we have 181460
Feb 22 15:56:32 <RP__> msm: you should ask Khem, he's done the verison bumps
Feb 22 15:58:30 <RP__> JaMa|Off: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/a0&id=dc39271e949952647fafbe1f72b1a2e664321d64
Feb 22 15:58:43 <RP__> JaMa|Off: Its gone from about 100 lines down to that :)
Feb 22 15:58:55 <RP__> JaMa|Off: only issue is the ABI change. I think the test does what we want
Feb 22 15:59:31 * RP__ is also dubious about exposing dataCache like this but I don't see the alternative
Feb 22 16:01:18 <RP__> JaMa|Off: I need to clean bits up but it might give you something to experiment with
Feb 22 16:14:28 <msm> RP__: yep, thanks
Feb 22 16:42:34 <ag> Anybody saw this error / warning in qemu?
Feb 22 16:42:56 <ag> warning: implicit declaration of function 'cpu_physical_memory_read'
Feb 22 16:43:00 <ag> warning: nested extern declaration of 'cpu_physical_memory_read'
Feb 22 16:43:06 <ag> undefined reference to `cpu_physical_memory_read'
Feb 22 16:43:22 <ag> All in git/target-arm/translate.c
Feb 22 16:55:13 <msm> fray: ping
Feb 22 18:15:18 <autif> meta-mono is in OE Layer Index. Please take a look, specially at the README and let me know if any changes are warranted, do let me know if it worked for you. It will make me happy.
Feb 22 18:15:26 <autif> email to the mailing list is forthcoming
Feb 22 18:19:03 <bluelightning> autif: great work :)
Feb 22 18:19:15 <bluelightning> autif: I've just fixed the git URI on the index page btw
Feb 22 18:20:16 <autif> thanks!
Feb 22 18:20:45 <autif> what was my error?
Feb 22 18:21:07 <autif> i previewed 3-4 times before hitting save
Feb 22 18:21:13 <autif> wonder what went wrong
Feb 22 18:21:17 <bluelightning> I could be wrong but I think the address you had there was the writable one that only works if you're authorised
Feb 22 18:21:31 <bluelightning> I just changed it to match the other github ones (and tested it)
Feb 22 18:22:10 <autif> ah, and I would not have known this - thanks!
Feb 22 18:22:29 <bluelightning> yeah, easy to do... np
Feb 22 18:22:31 <halstead> autif, I need to get you access to meta-mono.
Feb 22 18:23:07 <halstead> autif, pm?
Feb 22 18:23:38 <autif> sure
Feb 22 18:23:42 <autif> halstead - sure
Feb 22 18:24:29 <autif> I am not sure what you mean that you will give me access to meta-mono - i have access to meta-mono on KokoFitClub - do you mean in someplace else?
Feb 22 18:44:37 <autif> thanks kergoth
Feb 22 18:47:53 <pidge> autif: excellent on the meta-mono!
Feb 22 18:51:57 <autif> thanks pidge!
Feb 22 19:11:18 <halstead> autif, git@git.yoctoproject.org:meta-mono.git is ready for you to clone.
Feb 22 19:11:36 <halstead> It's seeded with the github data.
Feb 22 19:12:36 <autif> great
Feb 22 19:15:35 <autif> looks good
Feb 22 19:17:05 <autif> meta-mono has not yet shown up at http://git.yoctoproject.org/
Feb 22 19:17:20 <autif> is than not dynamic?
Feb 22 19:17:42 <autif> I guess it isn't because git seems to be working fine for me
Feb 22 19:21:19 <halstead> Ah. There is some caching of that page.
Feb 22 19:21:25 <halstead> I'll clear it out.
Feb 22 19:22:02 <autif> cool, will wait for your signal
Feb 22 19:30:57 <halstead> autif, All cleared. You should see it now.
Feb 22 19:31:30 <autif> got it, thanks, email on its way
Feb 22 20:06:13 <autif> tomz1 - symbol lookup error: /usr/lib/xorg/modules/drivers/emgd_drv.so: undefined symbol: EDID_bin_read
Feb 22 20:06:24 <autif> tomz1 - I get this error on corwnbay with M2
Feb 22 20:06:55 <autif> tomz1 - I have setup the libraries as defined in README
Feb 22 20:11:17 <tomz1> autif: this is where?
Feb 22 20:18:34 <autif> tomz1 - corwnbay 1.2 M2
Feb 22 20:20:33 <tomz1> autif: I mean the error - Xorg.log I guess.  What does your xorg.conf look like?
Feb 22 20:29:10 <autif> tomz1- for some reason vi is not playing nice with my xorg.conf - it seems like it is a single line file with many ^M - may be something bad happened to it - let me sort this out and get back to you.
Feb 22 20:32:17 <autif> tomz1 - http://pastebin.com/j66zjAhp    <——— this is my xorg.conf
Feb 22 20:32:23 <autif> I still get the same error
Feb 22 20:39:15 <tomz1> autif: no idea, haven't seen anything like that before, not sure why it would be trying to call EDID_bin_read in any case.  Let me try here.
Feb 22 20:41:28 <tomz1> autif: will take a while to build, will let you know when i have something
Feb 22 20:42:19 <autif> thanks, will ping later
Feb 22 20:54:08 <msm> fray: ping again =)
Feb 22 20:56:43 <autif> tomz1 - I have emailed you the contents of emgd-driver-bin-1.8 directory - there is a chance I am missing some library in there
Feb 22 20:56:53 <fray> msm, hey.. didn't see any ping before
Feb 22 21:00:55 <dvhart> bluelightning, ping
Feb 22 21:01:03 <bluelightning> hi dvhart
Feb 22 21:01:19 <dvhart> b62249f3db4f20dde50309b9ab3fbd4c5ac52e7e.
Feb 22 21:01:39 <dvhart> bluelightning, I was having issues with bitbake saying it was interrupted when I hadn't interrupted it
Feb 22 21:01:55 <bluelightning> hmm :(
Feb 22 21:02:03 <dvhart> and it would just say 63 of 63 tasks completed successfully, then it would return non zero
Feb 22 21:02:07 <dvhart> (or said it was)
Feb 22 21:02:19 <dvhart> but it wouldn't build what I asked (which had never been built before)
Feb 22 21:02:28 <dvhart> I reverted that and it's building again
Feb 22 21:02:50 <msm> fray: im trying to solve my multilib issue where i can't use ppc64e5500 but i can use powerpc64
Feb 22 21:03:10 <bluelightning> dvhart: ok I will take a look at it now
Feb 22 21:03:27 <dvhart> thanks
Feb 22 21:03:57 <fray> msm, do you have your config file(s) somewhere?  or is the config working, just not the multilib itself
Feb 22 21:04:03 <fray> 'er.. multilib config that is
Feb 22 21:05:25 <msm> fray: yes, one sec
Feb 22 21:06:54 <bluelightning> dvhart: hmm, seems I didn't look closely enough at the variable I used to check interrupted, it's set under other conditions :/
Feb 22 21:07:33 <bluelightning> dvhart: the result being if it thought it needed to build pseudo, it did that and then nothing else
Feb 22 21:07:50 <msm> fray: first, how does multilib know which other arches are compatible?
Feb 22 21:08:03 <fray> you specify it, it assumes they are compatible
Feb 22 21:08:18 <otavio> dvhart: indeed; last changes in bitbake has broken it
Feb 22 21:08:21 <dvhart>  bluelightning sounds right
Feb 22 21:08:23 <fray> the software install side though has some compatibility settings.. but in general it's automatic (with rpm at least) based on ELF type
Feb 22 21:08:24 <msm> fray: this is what I have
Feb 22 21:08:24 <msm> https://gist.github.com/1887278
Feb 22 21:08:44 <msm> but it doesn't like the ppc64e5500 bit.. its a valid tune and powerpc64 there instead works
Feb 22 21:09:03 <fray> ya.. that should be all that is required..
Feb 22 21:09:14 <fray> where is your ppc64e5500 tuning file?
Feb 22 21:09:21 <fray> does your machine include the tuning file?
Feb 22 21:09:49 <msm> fray: it needs to include both?
Feb 22 21:10:20 <fray> machine needs to include the tuning file so that the options are available..
Feb 22 21:10:21 <msm> this is the machine conf
Feb 22 21:10:22 <msm> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-ppc/tree/conf/machine/p5020ds.conf?h=edison
Feb 22 21:10:28 <fray> the machine should include all possible tunes, and then set the default
Feb 22 21:10:54 <fray> looks reasonable.. the e5500.inc shoud have includes the ppc config..
Feb 22 21:11:45 <fray> require conf/machine/include/tune-ppce5500-32b.inc
Feb 22 21:11:49 <fray> where is that file?
Feb 22 21:12:18 <otavio> hehe
Feb 22 21:12:33 <otavio> found it... bitbake -e now return non-zero
Feb 22 21:12:37 <otavio> this is wrong IMO
Feb 22 21:12:47 <msm> fray: that's in oe-core
Feb 22 21:13:00 <bluelightning> otavio: yes I know, I'm fixing it now
Feb 22 21:13:08 <otavio> bluelightning: ah ok; good
Feb 22 21:13:24 <fray> looking
Feb 22 21:14:00 <fray> ok.. both a 32b and 64b tune file exists..
Feb 22 21:14:09 <msm> fray: right.. should it be just one?
Feb 22 21:14:10 <fray> I didn't see the commit, or I would have recommended there only be ONE of them
Feb 22 21:14:19 <msm> fray: ok… i can fix this
Feb 22 21:14:30 <msm> i need to follow the ia32 one where they have TWO in one tune file?
Feb 22 21:14:34 <fray> I'd suggest combining the two.. then adjusting the machine to include the one..
Feb 22 21:14:40 <fray> ia32 is "different"
Feb 22 21:14:46 <msm> lol
Feb 22 21:14:50 <msm> ok which is a good example then?
Feb 22 21:14:54 <fray> looking
Feb 22 21:16:00 <fray> ya.. it's the file let me work it out.. need to look at it locally quick..
Feb 22 21:16:21 <msm> fray: by the way, if this config is "wrong" bitbake sort of locks up with no messages
Feb 22 21:16:24 <msm> so its hard to debug =)
Feb 22 21:16:37 <fray> (it may be right that there are two..  I didn't see it before that powerpc was also split..)
Feb 22 21:16:51 <fray> if it's locking up, that is a bug.. keep the files so it can be reproduced.. it absolutely should not be doing that..
Feb 22 21:16:54 <msm> fray: well i can take some time here to fix it all up
Feb 22 21:17:00 <fray> I thought you were just getting incorrect results or errors trying to process the multilibs
Feb 22 21:17:11 <msm> fray: no… im also using edison currently too
Feb 22 21:17:22 <msm> fray: should have said that up front
Feb 22 21:17:29 <fray> shouldn't matter on that
Feb 22 21:17:42 <msm> but this isn't new either - been here since 1.1 released
Feb 22 21:20:19 <fray> the FSL name is e5500 right, not PPC e5500?
Feb 22 21:20:25 <kergoth> the hang bug in bitbake is fixed in current master, fyi
Feb 22 21:20:25 <fray> (the official part name/core name?)
Feb 22 21:23:09 <msm> it's an e5500 core
Feb 22 21:23:11 <fray> and does the e5500 have traditional hardware floating point?
Feb 22 21:23:18 <msm> its 32/64 bit part
Feb 22 21:23:39 <msm> yes it has an FPU
Feb 22 21:27:39 <msm> i think there are some wires crossed too
Feb 22 21:27:45 <msm> ppce5500 vs. ppc64e5500
Feb 22 21:27:52 <fray> ö
Feb 22 21:27:53 <fray> http://pastebin.com/0wzBuYuX
Feb 22 21:28:00 <msm> e5500-32b v. e5500-64b
Feb 22 21:28:00 <fray> let me explain this quickly.. and I think you'll get it..
Feb 22 21:28:18 <msm> yes
Feb 22 21:28:22 <msm> this is sort of what i though
Feb 22 21:28:24 <msm> the += bits
Feb 22 21:28:39 <msm> and other stuff
Feb 22 21:28:43 <fray> there is one file for the ppce5500.inc.. it includes arch-powerpc64.inc which defines HOW to specify a 64-bit thing.. and in turn includes the powerpc (32-bit) version which defines the basic PowerPC settings, including if it's hard float or not
Feb 22 21:29:25 <fray> in this file we define a single additional tune value, e5500.. if set will enable the e5500 optimization, and also augment the TUNE_ARCH to include e5500.. (tune_arch is automatically set to "powerpc" or "powerpc64" based on the m32 or m64 feature setting)
Feb 22 21:29:47 <fray> with this file, you should get two new availabel tunings..  ppce5500 and ppc64e5500.. by default ppce5500 (32-bit) will be used..
Feb 22 21:30:02 <fray> include this with the machine, and then in the multilib config add the ppc64e5500 as the alternative config..
Feb 22 21:30:07 <fray> does that make sense?
Feb 22 21:30:19 <fray> (note I haven't tried this.. just worked it out in pastebin, but it should be close)
Feb 22 21:30:50 <msm> yes
Feb 22 21:31:00 <msm> i think this make sense
Feb 22 21:31:27 <fray> but in short.. the way to add new tunings is by adding a minimal TUNEVALID and settings..  then later in the file specify all valid combinations..  DEFAULTTUNE simply sets teh default unless the machine (or user) overrides it
Feb 22 21:31:31 <msm> we will no longer need the other tune file either?
Feb 22 21:31:47 <msm> files*
Feb 22 21:31:53 <fray> ya, the two other files should go away.. (for the change, I'd suggest renaming the 32b one to tune-ppce5500.inc, then making this change..
Feb 22 21:31:56 <msm> this one handles both arches
Feb 22 21:31:59 <fray> it should be more obvious in a diff what changed then
Feb 22 21:32:00 <fray> yes
Feb 22 21:32:04 <msm> ya
Feb 22 21:33:28 <fray> (on PPC at least it's pretty clear the default should almost always be 32-bit.. but witht eh DEFAULTTUNE ?=, it's easy to change to 64-bit if someone wanted to)
Feb 22 21:35:05 <fray> msm, if you remind me.. I'll try to write up a "how to define a new process/core tuning file" document..
Feb 22 21:35:21 <fray> but you may have to pester me a bit..  I'm swamped from now through the first week of March
Feb 22 21:36:16 <msm> fray: heh, maybe just file a bug
Feb 22 21:36:48 <msm> fray: this looks to be working as you typed it.. so far =)
Feb 22 21:36:58 <tomz1> autif: the binaries you sent look fine, the EDID_bin_read function looks like it gets called by emgd_drv.so, but I'm not sure which .so that lives in
Feb 22 21:37:13 <fray> ;)
Feb 22 21:37:42 <autif> tomz1 - ack
Feb 22 21:37:45 <autif> so what next?
Feb 22 21:37:47 <tomz1> autif: I mean EDID_bin_read.  I'm also wondering why this hasn't been seen before, probably something different about your display
Feb 22 21:38:09 <autif> have you been able to repro this with your M2 build?
Feb 22 21:38:18 <tomz1> autif: and the EDID-related settings in the xorg.conf
Feb 22 21:38:40 <tomz1> autif: I haven't finished building yet, but will try
Feb 22 21:38:45 <autif> ok
Feb 22 21:39:04 <tomz1> autif: will let you know later, but need to leave for a couple hours now
Feb 22 21:39:21 <autif> I am trying SVDO - which I have been told is any standard monitor
Feb 22 21:39:29 <autif> connected thru a VGA cable
Feb 22 21:39:44 <autif> no problem, will catch you tomorrow or something
Feb 22 21:39:54 <fray> msm - BTW I suggest you use -e and veriy the values of TUNE_ARCH, and PACKAGE_EXTRA_ARCHS is reasonable...
Feb 22 21:40:31 <tomz1> autif: ok, I'll let you know once I've tried to reproduce
Feb 22 21:44:10 <bluelightning> otavio: fixed
Feb 22 21:45:28 <msm> fray: i spoke too soon it wasn't working right out of hte box
Feb 22 21:45:38 <msm> fray: whats the difference bettwen TUNE_ARCH and TUNE_PKGARCH
Feb 22 21:45:50 <fray> On PowerPC the TUNE_PKGARCH is set based on a default value
Feb 22 21:46:05 <fray> PPCPKGARCH = "${TUNE_ARCH}${PPCPKGSFX_FPU}"
Feb 22 21:46:05 <fray> TUNE_PKGARCH ?= "${PPCPKGARCH}"
Feb 22 21:46:29 <fray> since you don't have the e500 FPU stuff.. (and aren't runnign no fpu) the PPCPKGSFX_FPU is blank..
Feb 22 21:46:36 <fray> TUNE_ARCH then is used to define it..
Feb 22 21:46:44 <fray> TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "m32", "powerpc", "", d)}"
Feb 22 21:46:59 <fray> TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", [ "m64" ], "powerpc64", "", d)}"
Feb 22 21:47:05 <fray> ...and then the new line
Feb 22 21:47:09 <fray> TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "e5500", "e5500", "", d)}"
Feb 22 21:47:11 <msm> ah thats wht its looking for powerpce5500
Feb 22 21:47:16 <fray> so you should get powerpce5500
Feb 22 21:48:30 <fray> (note I prefer ppc over powerpc -- but that was an OE thing that we kept.....)
Feb 22 21:48:49 <fray> to be truely correct is should probably be "power" and "power64".. but ANYWAY
Feb 22 21:50:23 <msm> fray: its needed me to add arch info to meta/class/siteinfo.bbclass
Feb 22 21:50:40 <bluelightning> dvhart: fixed, thanks
Feb 22 21:50:55 <fray> Hmmm..
Feb 22 21:50:57 <dvhart> yup. and pulled. thanks for the super quick fix!
Feb 22 21:50:59 <msm> fray: its not really a new arch though
Feb 22 21:51:05 <fray> no..  thus the Hmmm
Feb 22 21:51:28 <fray> what error are you getting from siteinfo?
Feb 22 21:51:34 <msm> fray: then binutils does not like the target either
Feb 22 21:51:55 <msm> its using powerpce550 instead of waht the old tunes where for the target machine type
Feb 22 21:52:07 <msm> ERROR: Unable to determine endianness for architecture 'powerpce5500'                                  | ETA:  --:--:--
Feb 22 21:52:07 <msm> ERROR: Please add your architecture to siteinfo.bbclass
Feb 22 21:52:11 <fray> Ahh...  that might be my mistake
Feb 22 21:52:20 <fray> just a sec
Feb 22 21:53:50 <fray> sorry back..
Feb 22 21:53:59 <fray> Ya.. TUNE_ARCH should not have been changed..
Feb 22 21:54:20 <fray> so remove the: TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "e5500", "e5500", "", d)}"
Feb 22 21:54:21 <fray> thats wrong
Feb 22 21:54:59 <fray> add in TUNE_PKGARCH_tune-ppce5500 = "powerpce5500" and TUNE_PKGARCH_tune-ppc64e5500 = "powerpc64e5500"
Feb 22 21:55:05 <fray> I think that will then do the right thing
Feb 22 21:55:23 <fray> (those later two should be added after line 10 and 14 of the original pastebin
Feb 22 21:57:35 <msm> ahh
Feb 22 21:57:40 <msm> i see you are updating the pastebin
Feb 22 21:57:45 <msm> look at the one other fix:
Feb 22 21:57:45 <msm> http://pastebin.com/diff.php?i=s3aQWtBN
Feb 22 21:58:25 <msm> but it's still complaining about arch
Feb 22 21:58:36 <fray> I wasn't meaning to update it.. ;)
Feb 22 21:59:22 <fray> I didn't do the "${PACKAGE_EXTRA_ARCHS_tune-powerpc64}" because I don't see it defined in powerpc64.. ;)  (it likely should be)  ;)
Feb 22 21:59:47 <fray> I'd consider that a bug in the existing powerpc/arch-powerpc64.inc BTW.. so feel free to fix it.. ;)
Feb 22 22:00:01 <fray> for the arch, what is it being evaluated to now?
Feb 22 22:00:06 <fray> it should be simple powerpc and powerpc64
Feb 22 22:00:28 <fray> (we -really- need a readme file or something to document expectations for various architectures and cores)
Feb 22 22:00:52 <msm> fray: how can I tell?
Feb 22 22:00:56 <msm> fray: bitbake locks up
Feb 22 22:00:59 <fray> bitbake -e
Feb 22 22:01:25 <fray> switch to oe-core, latest master bitbake and try.. see if that resolves the lock up like kergoth said
Feb 22 22:01:44 <fray> if it does, we need to get the back into Yocto.. if it doesn't.. it's a bug that has to be found.. tunings should never cause lockups
Feb 22 22:02:06 <fray> I have to run.. I've got my kids birthday in an hour and a half and need to get ready for it..
Feb 22 22:02:25 <fray> drop me an email, mark.hatle at windriver.com if you need more help...
Feb 22 22:02:33 <msm> fray: PACKAGE_EXTRA_ARCH isnt' defined in arch-powerpc.inc either
Feb 22 22:02:38 <msm> fray: ok thanks for the help
Feb 22 22:11:19 <autif> meta/classes/kernel.bbclass has variables like moule_autoload_xxx = "xxx" - I am guessing that this makes the module load after boot up. Now, I can not append a bbclass, and I want to add my own module_autoload_yyy = "yyy" to load the yyy module at stat up. How do I do this from my own meta-layer?
Feb 22 22:22:08 <dvhart> autif, I've also hit the emgd error, just opened bug 2023
Feb 22 22:25:13 <fray> msm: PACKAGE_EXTRA_ARCHS_tune-powerpc-nf = "powerpc-nf"
Feb 22 22:25:23 <fray> ...and PACKAGE_EXTRA_ARCHS_tune-powerpc = "${PACKAGE_EXTRA_ARCHS_tune-powerpc-nf} powerpc"
Feb 22 22:25:26 <fray> are in mine..
Feb 22 22:25:42 <fray> (note, the second looks wrong to me... since nf and (hardware float) are not compatible
Feb 22 22:25:42 <msm> fray: ah powerpc-nf has some
Feb 22 22:26:07 <fray> the second should simply be "powerpc"
Feb 22 22:26:41 <fray> (there is apparently a lot of misconception that nf ppc and float ppc work together, because most things don't use floating point registers for argument passing.. but it's still wrong, even if it might work, sometimes..
Feb 22 22:26:54 <fray> (bash is a good example of something that doesn't work when mixed..  signal handling gets fowled up)
Feb 22 22:27:01 <autif> dvhart - thanks - that helps
Feb 22 22:28:05 <autif> tomz1 will get to the bottom of this - likely a missing library - everything compiled fine - just a runtime issue, so likely a missing library
Feb 22 22:28:50 <msm> fray: ok.. i think ive almost got this sorted out.. and learned a little too
Feb 22 22:29:03 <msm> i'll CC you on a patch that cleans this up
Feb 22 22:30:25 <khem> msm: what are some differences between e5500 and e500mc  other than e5500 is 64bit
Feb 22 22:30:59 <msm> khem: not much, there are some new instructions
Feb 22 22:31:19 <msm> khem: its almost annoying to have to deal with e5500 - but someone things it's worth the possible perf gains
Feb 22 22:31:22 <khem> msm: so if I am using e5500 in 32bit mode its as good as e500mc
Feb 22 22:31:29 <msm> khem: basically
Feb 22 22:31:50 <khem> ok, does e5500 let you boot with 32bit kernel ?
Feb 22 22:31:50 <fray> msm thanks
Feb 22 22:32:41 <msm> khem: yes
Feb 22 22:32:55 <msm> khem: and 64 bit, hence the interest in multilib =)
Feb 22 22:33:35 <khem> msm: ok. I remember a IBM SOC which needed 64bit kernel since it could not boot into 32bit
Feb 22 22:34:25 <msm> khem: we still require some 32-bit for booting even so 32-bit is required
Feb 22 22:34:37 <khem> msm: ok.
Feb 22 22:35:12 <khem> So do you have some nifty doc where it explains what do I lose if I use e5500 in 32bit mode
Feb 22 22:35:17 <khem> like instructions etc.
Feb 22 22:35:53 <khem> iow, does e5500 offer something more on top of say p2020 in 32bit mode
Feb 22 22:36:50 <msm> khem: not too sure about that
Feb 22 22:36:57 <msm> if you send me an email I can try to follow up
Feb 22 22:37:10 <khem> msm: ok
Feb 22 22:37:40 <msm> khem: the core should be "better" overall even in 32-bit mode
Feb 22 22:37:45 <msm> khem: but not sure about specifics
Feb 22 22:40:00 <fray> ok.. I'm gone.. later
Feb 22 22:42:08 <khem> msm: better hmm in what sense
Feb 22 22:45:13 <msm> khem: higher clock, larger caches are the obvious ones that come to mind
Feb 22 22:45:22 <msm> but that's beynd the core a little
Feb 22 22:45:59 <msm> improved hypervisor/virtualization support
Feb 22 22:46:40 <msm> https://www.freescale.com/webapp/Download?colCode=E5500RM&location=null&fpsp=1&WT_TYPE=Reference%20Manuals&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Documentation&Parent_nodeId=1276525621883714098789&Parent_pageType=product
Feb 22 22:46:47 <msm> what a lovely link
Feb 22 22:52:38 <ant__> dvhart: http://cgit.openembedded.org/meta-openembedded/tree/meta-initramfs
Feb 22 23:03:39 <khem> msm: it asks me to register :)
Feb 22 23:03:53 <khem> in order to view that link
Feb 22 23:08:07 <msm> khem: yes.. but that's the relevant manual =)
Feb 22 23:26:28 <Crofton|work> on topic, http://htwins.net/scale2/
Feb 22 23:26:31 <Crofton|work> barely :)
Feb 22 23:31:55 <khem> I now know there is something smaller than yocto :)
Feb 22 23:34:29 <kergoth> hehe
Feb 22 23:38:21 <dvhart> that was awesome!
Feb 22 23:38:33 <dvhart> Planck just doesn't have the same ring to it though
Feb 22 23:40:08 <khem> I think debian should rename itself to yotta
Feb 23 00:05:01 <tomz1> autif: my crownbay 1.2m2 build worked - since Darren has also seen it and opened bug 2023, can you also add your information there e.g. Xorg.0.log and dmesg as well as your display setup, thanks
Feb 23 00:05:58 <dvhart> hrm, have we bumped the xorg recipes since m2 ?
Feb 23 00:06:32 <tomz1> dvhart: are you using m2 or master?
Feb 23 00:06:36 <dvhart> master
Feb 23 00:07:59 <tomz1> dvhart: autif is using m2 with the same result
Feb 23 00:08:03 <dvhart> ah
Feb 23 00:26:55 <autif1> tomz1, dvhart - dmesg and Xorg.0.log are attached to the bug - since this is the first time I have attached something, can you please let me know it made it OK, thanks!@
Feb 23 00:35:10 <tomz1> autif1: yeah, it made it there, thanks
Feb 23 02:42:03 <otavio> Humm /me fighting with bitbake
Feb 23 02:42:25 <kergoth> I do that pretty regularly :)
Feb 23 02:42:33 <otavio> kergoth: :-)
Feb 23 02:42:49 <otavio> kergoth: I am getting exit 1 in parsing
Feb 23 02:42:59 <otavio> kergoth: but I didn't find where
Feb 23 02:43:14 <otavio> kergoth: it happens with last master tip only
Feb 23 02:46:10 <otavio> DEBUG: BB /home/otavio/hacking/ossystems/embedded-linux/openembedded-core/meta/classes/autotools.bbclass: handle(data, include)
Feb 23 02:46:13 <otavio> ERROR: Command execution failed: Exited with 1
Feb 23 02:46:18 <otavio> kergoth: Any clue?
Feb 23 02:46:58 <otavio> kergoth: I tried to change the code in bitbake to show more information about where it is running to try to catch it but it is too complex to my head ;-)
**** ENDING LOGGING AT Thu Feb 23 02:59:58 2012

**** BEGIN LOGGING AT Thu Feb 23 02:59:58 2012
Feb 23 03:35:48 <otavio> kergoth: i found the parsing error ...
Feb 23 03:38:07 <Eddward> Hi.  Would it be difficult to twist yocto into a tool for build a toolchain to build portable Linux binaries.
Feb 23 03:38:35 <Eddward> That is instead of build full cross-compiled disk images?
Feb 23 03:40:49 <RP__> Eddward: probably not, depending on exactly you wanted to achieve. Its a fairly generic build system
Feb 23 03:41:50 <Eddward> Yocto make it easy to build Linux images for embedded use....
Feb 23 03:42:34 <Eddward> I'd like to do something similar and build a toolchain that can the produce binaries that should run on multiple distros/releases
Feb 23 03:42:35 <RP__> Eddward: but I once used the build system to cross compile an application for arm-darwin :)
Feb 23 03:42:58 <Eddward> There are similar problems to address.
Feb 23 03:42:59 <RP__> Eddward: have a look at the meta-toolchain we generate (and the other nativesdk packages)
Feb 23 03:43:18 <RP__> Eddward: we generate a standalone python for example
Feb 23 03:43:43 <Eddward> I'll give it a try and see what I can do.  Thanks
Feb 23 03:44:07 <Eddward> btw, I'm just following up on a thread here --> http://www.desura.com/groups/desura/forum/thread/missing-libraries#720252
Feb 23 03:44:19 <Eddward> I'm just starting by looking for code to reuse.
Feb 23 03:45:42 <RP__> Eddward: defintely have a look at the meta-toolchain pieces :)
Feb 23 03:45:45 * RP__ -> Zzzz
Feb 23 09:16:58 <bluelightning> morning all
Feb 23 09:20:07 <JaMa|Off> morning
Feb 23 09:53:37 <RP__> morning all
Feb 23 09:54:01 <RP__> JaMa|Off: I posted the sstate kernel-module patches yesterday. Are there any other sstate issues you're still seeing?
Feb 23 09:55:18 <JaMa|Off> I've added those to my branches.. running tests now
Feb 23 09:55:41 <JaMa|Off> but at least I'll need to extend that list of excluded recipes
Feb 23 09:56:35 <JaMa|Off> now with datacache available, can we declare "sstate ignored" dependencies in recipe and add section to sig handler to ignore those?
Feb 23 09:56:49 <RP__> JaMa|Off: thanks. I'm in two minds about that exclusion list. I really only want things in there that are really needed
Feb 23 09:57:05 <RP__> JaMa|Off: recipe writers will just start excluding all kinds of things
Feb 23 09:57:40 <JaMa|Off> which is imho better even for stuff like pointercal, that we can exclude it from 1 recipe and keep it in some other
Feb 23 09:58:01 <JaMa|Off> yes but they will do it in their layers
Feb 23 09:58:27 <RP__> JaMa|Off: I've been hoping this list can be very very small
Feb 23 09:58:30 <JaMa|Off> not asking you to exclude all kinds of valid entries you haven't even seen because it's in some layer somewhere
Feb 23 09:58:55 <JaMa|Off> I have "config" recipes for lot of fso and shr stuff..
Feb 23 09:59:33 <JaMa|Off> I know I can create my own SHRbasichash .. but that would require duplicate more stuff
Feb 23 09:59:35 <RP__> JaMa|Off: pulled in by task packages or dependencies from the apps themselves?
Feb 23 09:59:52 <JaMa|Off> and also imply that meta-smartphones depend on own basichash..
Feb 23 10:00:03 <JaMa|Off> usually from apps
Feb 23 10:00:17 <JaMa|Off> so apps are rebuilt
Feb 23 10:00:32 <RP__> JaMa|Off: I guess I have no choice in this
Feb 23 10:01:20 <JaMa|Off> I think that "recipe writers will just start excluding all kinds of things" is just their problem.. it's the same as when they don't set (R)DEPENDS correctly etc..
Feb 23 10:02:04 <RP__> JaMa|Off: well, we can try and stop them shooting themselves in the foot...
Feb 23 10:02:23 <RP__> JaMa|Off: perhaps we should do this at the layer level
Feb 23 10:02:53 <JaMa|Off> that some layer files lists excludeable recipes?
Feb 23 10:03:22 <RP__> JaMa|Off: yes. recipe level doesn't entirely make sense unless the exclusion list is per recipe which is going to cause duplication
Feb 23 10:03:58 <RP__> (since we want all users of pointercal to exclude it and if the info is in pointercal itself, that is a hard problem)
Feb 23 10:04:01 * JaMa|Off is not sure if duplication in this case is so big problem
Feb 23 10:04:22 <JaMa|Off> if pointercal is included from xserver-common then we probably don't want to make xserver-common machine specific
Feb 23 10:04:26 <RP__> JaMa|Off: I mean every *user* of pointercal or base-files would have to exclude it
Feb 23 10:04:52 <JaMa|Off> but if it's included in task-foo, than maybe it's good that task-foo keeps pointercal as dep
Feb 23 10:05:26 <RP__> Either these things have a stable interface or they do not
Feb 23 10:06:55 <JaMa|Off> I mean that if task-foo is machine specific, than excluding pointercal from its deps doesn't have any advantage IMHO
Feb 23 10:07:18 <JaMa|Off> so we can be more carefull with excluding only from recipes where it does matter
Feb 23 10:07:37 <JaMa|Off> but I see your point about stable or not
Feb 23 10:10:15 <JaMa|Off> bbl
Feb 23 10:10:26 <RP__> JaMa|Off: I have a patch I'll propose
Feb 23 10:34:33 <otavio> morning all
Feb 23 10:34:52 <bluelightning> hi JaMa|Off, otavio, RP__
Feb 23 10:49:00 <icanicant> otavio: how did you get on with the build error?
Feb 23 10:49:53 <otavio> icanicant: i had an error in one recipe
Feb 23 10:50:03 <otavio> icanicant: most probably you also have it
Feb 23 10:50:27 <otavio> icanicant: not easy to trace it.
Feb 23 10:51:13 * bluelightning -> office
Feb 23 10:52:09 <otavio> RP__: this is one thing it would be nice to get better in bitbake (although looking at code seems not easy to do) ... when bitbake trigger event as bb.command.CommandFailed it would be nice to have the recipe name that has it
Feb 23 10:52:54 <bluelightning> otavio: I think we should be able to address that
Feb 23 10:53:00 <icanicant> otavio: did you find out which recipe yet?
Feb 23 10:53:22 <otavio> bluelightning: it took me two hours to trace it since it just blow up heh
Feb 23 10:53:35 <otavio> icanicant: it was one in our internal layer
Feb 23 10:55:44 <icanicant> otavio: ah, ok. for me it happened when i pulled down updated layers last night.
Feb 23 10:56:01 <otavio> icanicant: what layers do you use?
Feb 23 10:56:36 <icanicant> otavio: the full angstrom set and a couple of custom ones
Feb 23 10:57:26 <icanicant> will dig deeper later. i just assumed it was a generic problem seeing as you saw something similar at the same time.
Feb 23 10:58:06 <otavio> icanicant: me too; but then i traced it down to our recipe
Feb 23 11:14:25 <RP__> otavio: there is an open bug about the error handling
Feb 23 11:14:40 <RP__> otavio: somehow the multiprocess parsing seems to be eating the error messages :/
Feb 23 11:16:23 <otavio> RP__: heh
Feb 23 12:34:33 <Zagor> is there support for a read-only remote sstate cache/archive?
Feb 23 12:34:59 <Zagor> or even a read-only local one
Feb 23 12:35:28 <Zagor> the refman only mentions SSTATE_DIR
Feb 23 12:36:08 <bluelightning> Zagor: yes, SSTATE_MIRRORS is what you want to set for that
Feb 23 12:36:28 <bluelightning> it functions exactly like MIRRORS / PREMIRRORS, so local URIs can be used as well
Feb 23 12:36:53 <Zagor> excellent
Feb 23 12:37:27 <bluelightning> the next release should have much better sstate documentation btw :)
Feb 23 12:37:55 <Zagor> nice!
Feb 23 13:30:37 <d4ny>  bluelightning: What the state of the SSTATE_MIRROR over http for edison. I can't seem to get it to accept anything from the remote side.
Feb 23 13:31:47 <bluelightning> d4ny: it should work if you've set SSTATE_MIRRORS (note _MIRRORS not _MIRROR) correctly
Feb 23 13:57:42 <JaMa|Off> is there any limit to cmd in os.system(cmd)? sed call for all from perl's sstate_hardcode_path is 560410 characters long and doesn't seem to be executed from python, but when I execute same command in shell it does work
Feb 23 14:17:01 <RP__> JaMa|Off: hmm, we probably should break that up a bit :/
Feb 23 14:17:17 <RP__> JaMa|Off: I don't know what limitations os.system has in the regard
Feb 23 14:18:23 <RP__> Zagor: You can see the current documentation at http://www.yoctoproject.org/documentation/docs-in-progress
Feb 23 14:19:22 <Zagor> ok
Feb 23 14:19:41 <RP__> Zagor: http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html does reference SSTATE_MIRROR
Feb 23 14:19:47 * RP__ just wanted to check :)
Feb 23 14:19:56 <Zagor> yeah, I checked too :-)
Feb 23 14:20:19 <JaMa|Off> RP__: I was thinking about executing that send with find directly, do you see any issue with that?
Feb 23 14:20:56 <JaMa|Off> well as long as SSTATE_SCAN_CMD _is_ find :/
Feb 23 14:21:24 <RP__> JaMa|Off: I think we should just split into say 100 file chunks
Feb 23 14:21:34 <JaMa|Off> but appending " | xargs ${SED_CMD} " should work too
Feb 23 14:21:35 * RP__ did this somewhere else recently, where was that? :/
Feb 23 14:22:09 <RP__> JaMa|Off: see chunks() in package.bbclass
Feb 23 14:22:56 <Zagor> can I get more debug output from do_fetch? one target doesn't fetch from my mirror and I'd like to see what it does.
Feb 23 14:23:38 <JaMa|Off> RP__: and is it better (or faster) to read them in python just to join them back together for sed?
Feb 23 14:24:15 <RP__> JaMa|Off: likely that should be fine
Feb 23 14:24:18 <JaMa|Off> RP__: or is it just to generate sfixmepath ? we can do that too in pipe after SSTATE_SCAN_CMD
Feb 23 14:24:34 <RP__> JaMa|Off: it would be less exec calls than calling sed for eas file
Feb 23 14:24:38 <RP__> s/eas/each/
Feb 23 14:25:39 <JaMa|Off> that's possible with xargs too, isn't it?
Feb 23 14:25:51 <RP__> JaMa|Off: true
Feb 23 14:26:14 * JaMa|Off thinks it's even default xargs behavior
Feb 23 14:26:22 <JaMa|Off> to split it only to system posible chunks
Feb 23 14:27:36 <JaMa|Off> heh for cross it attaches all files even twice..
Feb 23 14:27:54 <JaMa|Off> I guess 2 expressions in one sed command are also faster
Feb 23 14:28:16 <JaMa|Off> if it's not some extension of sed not portable to other systems
Feb 23 14:34:50 <JaMa|Off> RP__: I'll test something like http://paste.pocoo.org/show/555558/ tonight
Feb 23 14:57:06 <Zagor> likewise, it's not using my sstate mirror either. I'd like to see why.
Feb 23 15:00:07 <RP__> JaMa|Off: looks good
Feb 23 15:00:48 <RP__> Zagor: -DDD might help you see what's happening
Feb 23 15:01:03 <RP__> Zagor: what did you set SSTATE_MIRRORS to?
Feb 23 15:01:45 <Zagor> "file://.*/.* http://<hostname>/sstate-cache/"
Feb 23 15:02:09 <ant_work> JaMa|Off: I didn't follow in detail, does it mean we can have xinput-calibrator & pointercal in oe-core soon?
Feb 23 15:03:32 <JaMa|Off> ant_work: moving them to oe-core doesn't really depend on anything..
Feb 23 15:04:16 <JaMa|Off> ant_work: you can just copy latest version from meta-oe and add pointercal-xinput to SIGGEN_EXCLUDERECIPES_ABISAFE
Feb 23 15:05:15 <JaMa|Off> ant_work: there was even patchset doing that maybe half year ago.. but author haven't used latest meta-oe version so it was full of machine specific stuff and after review comments he never sent v2 :/
Feb 23 15:06:04 <ant_work> I think it makes sense now that xinput is in oe-core
Feb 23 15:06:54 <ant_work> and if I don't add the SIGGEN_ stuff what happens? lot of rebuilds? tolerable?
Feb 23 15:06:56 <Zagor> RP__: neither -DDD nor -vvv gives me any more info. just "task do_fetch: Started" and "task do_fetch: Succeeded"
Feb 23 15:08:17 <JaMa|Off> ant_work: same behavior as now.. so it's fine to add it now and then update SIGGEN_EXCLUDERECIPES_ABISAFE later when RP's patch is in
Feb 23 15:09:00 <ant_work> JaMa|Off: I plan to launch a multimachine build, I'll note what will be rebuilt
Feb 23 15:10:09 <JaMa|Off> hmm from where this is? :/ sh: /OE/oe-core/tmp-eglibc/sysroots/x86_64-linux/usr/lib/rpm/bin/rpmdeps-oecore: No such file or directory
Feb 23 15:11:28 <Zagor> weird. gcc is fetched from yoctoproject while binutils fetches from my mirror.
Feb 23 15:12:23 <JaMa|Off> ant_work: better use RP's method to detect rebuilds without actually building them
Feb 23 15:13:25 <JaMa|Off> I've automated it for all machines like this:
Feb 23 15:13:27 <JaMa|Off> find tmp-eglibc//stamps/ -name \*sigdata\* | xargs rm -f; for MACHINE in om-gta01 om-gta02 nokia900 om-gta04 palmpre palmpre2 crespo; do export MACHINE; bitbake shr-image task-shr-feed -S;  find tmp-eglibc/stamps/ -name \*sigdata* | sort > stampsall.${MACHINE}; grep -v "\(om_gta0\)\|\(nokia900\)\|\(palmpre\)\|\(crespo\)" stampsall.${MACHINE} > stamps.${MACHINE}; done
Feb 23 15:14:30 <ant_work> nice. I can only say things have improved much e.g. when configuring multiple kernels
Feb 23 15:14:53 <ant_work> for similar machines
Feb 23 15:22:49 <Zagor> RP__: any suggestions how I can troubleshoot this?
Feb 23 15:24:16 <Zagor> SSTATE_MIRRORS appears to have no effect whatsoever. PREMIRRORS_prepend have effect on some/most packages but is strangely ignored for others.
Feb 23 15:26:58 <khem> RP__: with gcc 4.7 now libstdc++ will need libgcc build tree :(
Feb 23 15:27:00 <RP__> Zagor: Try file://.*
Feb 23 15:27:19 <khem> RP__: so I looked briefly what we do
Feb 23 15:27:40 <khem> RP__: I guess we need to change how we build libgcc a bit
Feb 23 15:27:48 <RP__> khem: why? That is a major step backwards
Feb 23 15:27:50 <khem> RP__: as well gcc-runtime
Feb 23 15:28:05 <khem> RP__: I dont know ask gcc devs
Feb 23 15:29:07 <khem> RP__: to cope with it I think what I did is stuff the gcc-cross build tree into staging instead of just libgcc install tree
Feb 23 15:29:29 <khem> then unroll it in both libgcc and gcc-runtime
Feb 23 15:30:08 <khem> I guess I can cut it more down to just needed files
Feb 23 15:30:21 <khem> instead of whole tree as I do now
Feb 23 15:30:35 <JaMa|Off> btw today I got couple off build issues with gcc-cross-initiall (undefined constants) is it possible that libgcc.do_headerfix is breaking shared gcc code if runs in parallel with gcc-cross-initial?
Feb 23 15:31:08 <JaMa|Off> or is do_headerfix executed only on local copy of shared gcc code?
Feb 23 15:31:12 <khem> how can libgcc.do_headerfix run in parallel with gcc-cross-initial
Feb 23 15:31:37 <JaMa|Off> mmt I'll find that cooker log
Feb 23 15:32:00 <JaMa|Off> but I have seen that 3 times in the morning (always build from scratch without sstate or anything)
Feb 23 15:32:02 <khem> sometimes I feel we should have done a unified tree build for toolchain
Feb 23 15:32:12 <Zagor> RP__: that seems to work better.
Feb 23 15:32:21 <RP__> khem: I think stuffing the tree is our best option
Feb 23 15:32:26 <RP__> Zagor: cool :)
Feb 23 15:34:23 <JaMa|Off> khem: cooker log http://paste.pocoo.org/show/555585/ and referenced do_compile.log http://paste.pocoo.org/show/555586/
Feb 23 15:35:04 <JaMa|Off> khem: I'm not 100% sure they were running in parallel just that libgcc.do_headerfix was close to that build error is suspicious
Feb 23 15:35:28 <JaMa|Off> khem: also that constant didn't disappear without reason.. reruning same build finished fine then
Feb 23 15:35:29 <Zagor> oh, that was what manual actually says... *facepalm*
Feb 23 15:36:25 <khem> JaMa|Off: what did we do to break it
Feb 23 15:36:48 <khem> are there some patches that got you there ?
Feb 23 15:39:55 <JaMa|Off> khem: not sure if it's the same error (or cause) I've sent you while ago.. maybe it's
Feb 23 15:40:13 <zeddii> RP__, is the bitbake-devel list subscriber post only ? I can't get the pages to come up to check :) and was trying to bast off my patch.
Feb 23 15:40:19 <JaMa|Off> khem: so it could be old issue just making things faster shows it more often now
Feb 23 15:44:12 <bluelightning> zeddii: hmm, lists.linuxtogo.org seems to be having some issues
Feb 23 15:44:31 <bluelightning> at least the web part anyway
Feb 23 15:44:44 <bluelightning> florian: do you know what's happening there?
Feb 23 15:47:39 <florian> bluelightning: yes only the webserver bexause od some spam problems and noone with time to get it fixed. :-(
Feb 23 15:48:51 <zeddii> I can work around that if I can post without being a subscriber .. otherwise, I'm in a catch-22 :)
Feb 23 16:06:42 * JaMa|Off bbl (4hours)
Feb 23 16:06:52 <kergoth> hmm, does the poky repo use combo-layer? I thought it did, but there doesn't appear to be a combo-layer.conf for it
Feb 23 16:30:14 <fray> msm: were you able to get the lock up resolved
Feb 23 16:35:38 <msm> fray: yes, i think it was fixed in master anyways
Feb 23 16:35:48 <msm> fray: i've tested those patches i sent against master
Feb 23 16:35:59 <msm> first i should ask if you saw the patches I posted
Feb 23 16:36:35 <fray> I didn't.. I'll go look again
Feb 23 16:36:47 <fray> ahh I see them now..
Feb 23 16:39:49 <fray> msm, ya it looks fine
Feb 23 16:40:11 <msm> fray: forgot to cc you
Feb 23 16:40:21 <fray> no problem
Feb 23 16:40:34 <fray> this should also simplify things
Feb 23 16:43:25 <autif> halstead - did something change between yesterday and today? when I git clone meta-mono, I get fatal: remote error: access denied or repository not exported: /meta-mono
Feb 23 16:43:57 <autif> no issues with poky or meta-intel
Feb 23 16:49:29 <halstead> autif, Let me check.
Feb 23 16:52:14 <halstead> autif, I missed a line in the config. It should be fixed now.
Feb 23 16:53:35 <autif> helstead - got it - works now, thanks!
Feb 23 18:32:07 <sgw> bluelightning: you have a couple of RFC's pending, are they now final as they have no comments?
Feb 23 18:32:29 <bluelightning> sgw: philip has just found an issue with the qt one
Feb 23 18:32:50 <bluelightning> sgw: the other two, I'll resend them as non-rfc
Feb 23 18:32:59 <sgw> bluelightning: Ok thanks.
Feb 23 18:36:06 <autif> dvhart, tomz1- I built master, when I startx on corwnbay - I get twm, xterm, xclock not found - I bitbaked core-image-sato
Feb 23 18:36:50 <tomz1> autif: so are you past the edid problem>
Feb 23 18:37:35 <autif> tomz1 - this is on master - so, yes likely it is past the edid issue
Feb 23 18:38:32 <autif> http://pastebin.com/Ryarmp7V   <————    result of startx
Feb 23 18:38:36 <tomz1> autif: so you're in a sato desktop, but the problem now is you're not finding the apps you want?
Feb 23 18:38:39 <autif> need Xorg.0.log too?
Feb 23 18:39:04 <autif> no, sot in sato, there is no X
Feb 23 18:39:15 <autif> screen is text only
Feb 23 18:41:35 <tomz1> autif: normally x is started using /etc/init.d/xserver-nodm start
Feb 23 18:42:47 <autif> got it - before M2 - I was able to startx
Feb 23 18:43:19 <autif> anyway = /etc/init.d/xserver-modm seems to be working - I just need to fix the hsync and vsync
Feb 23 18:43:21 <tomz1> autif: so, before M2, everything worked fine, sato, etc
Feb 23 18:43:39 <autif> yes, before M2 - on edison - everything worked
Feb 23 18:44:04 <autif> it broke with M2 and seems like it is fixed in master - so I might stay with master until M3 is cut
Feb 23 18:44:39 <autif> still waiting for xorg.conf changes from Jeff (local X expert)
Feb 23 18:45:47 <tomz1> autif: ok, so bug 2023 is only 1.2 M2 for you, master works fine, and edison works fine, on the same hardware, etc?
Feb 23 18:48:55 <autif> yes, i think so
Feb 23 18:49:07 <autif> master seems to be running fine
Feb 23 18:49:38 <autif> something is wrong with my xorg.conf
Feb 23 18:49:54 <autif> incorrect resolution
Feb 23 18:50:00 <autif> that should be resolvavble
Feb 23 18:50:07 <autif> i think I might be all set
Feb 23 18:50:11 <autif> thnaks!
Feb 23 18:51:04 <tomz1> autif: ok, yes, xorg.conf can sometimes be hard to get right
Feb 23 18:56:11 <dvhart> hrm
Feb 23 18:56:24 <dvhart> wonder what is happening with the fri2 bsp then
Feb 23 19:36:24 <bluelightning> sgw: done
Feb 23 19:36:30 <sgw> bluelightning: thanks
Feb 23 19:36:42 <bluelightning> also sent out the corresponding poky patch
Feb 23 20:41:27 * mranostay yawns
Feb 23 21:38:23 <mranostay> so silly question time. does poky not have a amend.bbclass functionality?
Feb 23 22:43:26 <ant__> dvhart: linux-yocto(-tiny) is slowly fetching, I was just too impatient
Feb 23 22:52:13 <ant__> pidge: ping
Feb 23 22:53:02 <pidge> ant_: pong
Feb 23 22:53:32 <ant__> pidge: hi, how would you match with spdx scheme a recipe generally declaring  BSD/GPL ?
Feb 23 22:54:19 <ant__> (is klibc, I'm reading the copyright file in the debian packages)
Feb 23 22:54:29 <pidge> ant__: which GPL version?
Feb 23 22:54:33 <ant__> heh
Feb 23 22:54:52 <ant__> let me see if git has more info
Feb 23 22:55:09 <kergoth> mranostay: not needed anymore. bitbake supports it directly now
Feb 23 22:55:24 <pidge> LICENSE = "BSD & GPL-2.0" (or GPLv2.0 but it should be M.m)
Feb 23 22:55:29 <kergoth> mranostay: for <filename>.bb, create a <filename>.bbappend, and ensure it's in BBFILES
Feb 23 22:55:49 <kergoth> mranostay: all bbappends will be added onto the end of the recipe parse. this is instrumental to the use of layers, it'd be extremely difficult to leverage layers without it
Feb 23 22:57:26 <ant__> pidge: wrt BSD, here says 'clause 3'  http://git.kernel.org/?p=libs/klibc/klibc.git;a=blob;f=usr/klibc/LICENSE
Feb 23 22:58:26 <ant__> and GPL "version 2"
Feb 23 23:00:39 <pidge> ant__: then LICENSE = "BSD-3-Clause & GPL-2.0" Although I'm seeing disagreement amongst distros on this. OBS says one thing Gentoo .ebuild another.
Feb 23 23:01:01 <ant__> I'm looking at the sources in kernel.org
Feb 23 23:01:20 <ant__> I think we can trust those
Feb 23 23:02:15 <pidge> ant__: Are you pkging up zlib with it?
Feb 23 23:02:32 <ant__> iirc no, let me see
Feb 23 23:02:41 * pidge notices zlib under the src tree
Feb 23 23:03:37 <pidge> ant__: one moment, let me verify this.
Feb 23 23:04:46 <ant__> well, we package gzip
Feb 23 23:05:25 <pidge> ant__: ok, so, from the LICENSE file info I'm seeing this: LICENSE = "BSD & GPL-2.0 & MIT"
Feb 23 23:05:33 <pidge> ant__ the last bit is MITish
Feb 23 23:06:07 <ant__> oh, I did not sroll enough
Feb 23 23:06:10 <mranostay> kergoth: thanks
Feb 23 23:06:35 <ant__> pidge, what about clause 3?
Feb 23 23:06:38 <pidge> ant__: yeah, but from the gzip recipe, correct?
Feb 23 23:06:54 <ant__> I suppose yes, maybe zcat too
Feb 23 23:07:36 <kergoth> mranostay: np. downside is you have to create a bbappend for each recipe, whereas amend.inc could apply to multiple at once, but the upside is it gets around a few evaluation order problems amend.bbclass had, and is built into bitbake, so performs better
Feb 23 23:07:41 <ant__> pidge: I was confusing with kexec-tools-klibc, where we have EXTRA_OECONF += "--without-zlib"
Feb 23 23:09:22 <pidge> ant__: Sorry.  LICENSE = "BSD-3-Clause & GPL-2.0 & MIT" (If it's --without-zlib). if not then it's: LICENSE = "BSD-3-Clause & GPL-2.0 & MIT & Zlib"
Feb 23 23:10:31 <ant__> pidge: many thanks
Feb 23 23:10:42 <ant__> I'm forwarding the info in #klibc
Feb 23 23:10:44 <mranostay> kergoth: yeah i noticed....
Feb 23 23:10:57 <mranostay> oh well
Feb 23 23:23:10 <mranostay> kergoth: so I assume INCOMPATIBLE_LICENSE="GPLv3" is dumb in that can't see that a "GPLv2 & GPLv3" is okay, right..?
Feb 23 23:26:15 <pidge> mranostay: That's not dumb. If something contains both GPLv2.0 and GPLv3.0 then it's incompatible as it has components that have those licenses. I'm not sure about " GPLv2.0 | GPLv3.0 " though. In that case it probably shouldn't set as incompatible.
Feb 23 23:27:09 <mranostay> ah right d'oh
Feb 23 23:27:56 <mranostay> Zyrtec has shut my brain off it seems
Feb 23 23:29:49 <ant__> dvhart: so far so good, linux-yocto-tiny is applying my patch and fetching my bootlogo
Feb 23 23:30:40 <dvhart> ant__, great!
Feb 23 23:30:45 <ant__> dvhart: ah, is failing now :/
Feb 23 23:30:53 <dvhart> pffff
Feb 23 23:30:59 <ant__> d9cbb7fbbe-r1/poodle/gen_poodle_desc.scc_tmp: No such file or directory
Feb 23 23:31:14 <ant__> 'ERROR. Could not update yocto/standard/base'
Feb 23 23:31:22 <dvhart> the first error is the problem
Feb 23 23:31:38 <dvhart> confirm that the file is in the FILESPATH and that it is listed on the SRC_URI
Feb 23 23:31:45 <ant__> ERROR: required features were not found. aborting
Feb 23 23:31:58 <ant__> hm.. I have to feed it with more infos...
Feb 23 23:54:04 <ant__> dvhart: somehow patch is failing, is trying to patch twice... hm..
Feb 23 23:54:28 <dvhart> are you applying a patch?
Feb 23 23:54:55 <dvhart> if so, do you have it listed twice? once in the scc and once in the recipe?
Feb 23 23:55:16 <ant__> yes
Feb 23 23:55:17 <ant__> http://paste.debian.net/157359/
Feb 23 23:55:51 <ant__> http://paste.debian.net/157360/
Feb 23 23:56:22 <ant__> w/out .scc was erroring out
Feb 24 00:01:08 <ant__> dvhart: ok, adding an empty .scc is a way to go ahead... now, how to inject the initramfs like done in kernel.bbclass?
Feb 24 00:01:22 <ant__>  /linux/scripts/gen_initramfs_list.sh: Cannot open 'initramfs.cpio.lzma'
Feb 24 00:03:50 <dvhart> ant__, sorry, I wish I could dig into this right now - but I'm a bit buried in some time sensitive tasks atm
Feb 24 00:04:16 <ant__> np, sorry for having bothered you so much ;)
Feb 24 00:04:24 <dvhart> ant__, I suggest an email to the yocto list with tomz, myself, and zedd on CC
Feb 24 00:04:35 <dvhart> ant__ not at all, I want to see what you're doing
Feb 24 00:04:48 <dvhart> sometimes other things get in the way of the fun stuff though :/
Feb 24 00:04:50 <ant__> well, I'll spend some more hours on it before
Feb 24 00:04:58 <ant__> sending a mail ;)
Feb 24 00:05:12 <ant__> still some obscure edges
Feb 24 00:05:27 <ant__> thanks again
Feb 24 00:05:58 <dvhart> sure
Feb 24 00:39:23 <ant__> dvhart: -rw-r--r-- 1 andrea users 1570288 Feb 24 01:37 zImage-3.0.12-yocto-standard+
Feb 24 00:39:26 <ant__> :)
Feb 24 00:42:30 <ant__> yahwnn.
Feb 24 00:42:32 <ant__> gn
**** ENDING LOGGING AT Fri Feb 24 02:59:58 2012

**** BEGIN LOGGING AT Fri Feb 24 02:59:58 2012
Feb 24 03:20:19 <seebs> hah
Feb 24 03:20:32 <seebs> So I got a bug report about pseudo.  Sure enough, user error.
Feb 24 03:20:40 <seebs> ... I was the user who'd written that hunk of build system.
Feb 24 03:20:52 <seebs> Hoist by my own petard.
Feb 24 03:29:24 <mebrown> :)
Feb 24 04:13:47 <mebrown> Question about rebuilds. I know that if you edit a recipe, bitbake will automatically rebuild that recipe. How about when a recipe points to a git repo? Is there any way to have bitbake automatically rebuild a recipe when things have been checked into the repo?
Feb 24 08:25:32 <bluelightning> morning all
Feb 24 11:11:26 <otavio> morning
Feb 24 12:02:47 <Zagor> wrapping wget to produce a parameter log turned out to be a useful tool for debugging my mirror settings
Feb 24 12:05:08 <bluelightning> Zagor: did the log.do_fetch not help at all? if not we should probably improve the debugging output
Feb 24 12:05:34 <Zagor> oh, I missed that suggestion.
Feb 24 12:06:00 <Zagor> I only tried the -DDD and -vvv options
Feb 24 12:06:06 <bluelightning> ah right
Feb 24 12:06:30 <bluelightning> -DDD should be printing out everything in log.do_fetch however it will print out a lot of other noise
Feb 24 12:07:19 <Zagor> in that case I would say log.do_fetch is insufficient
Feb 24 12:08:39 <bluelightning> Zagor: ok, if you could elaborate on what we could print out that it currently doesn't that would be great
Feb 24 12:09:23 <Zagor> whee. with download and sstate mirror my "build" now takes 7m instead of 3h :-)
Feb 24 12:09:38 <bluelightning> :)
Feb 24 12:09:51 <bluelightning> sstate can make a massive difference
Feb 24 12:12:43 <Zagor> even with -DDD do_fetch says nothing other than "Started" and "Succeeded".
Feb 24 12:13:02 <Zagor> I would suggest it at least prints the URLs it tries, and any non-successful results
Feb 24 12:13:45 <bluelightning> hmm... that doesn't sound right
Feb 24 12:13:53 <bluelightning> I'll try that here now
Feb 24 12:14:00 <Zagor> I'm on edison btw
Feb 24 12:14:09 <Zagor> haven't tried on trunk
Feb 24 12:14:32 <bluelightning> ok
Feb 24 12:16:54 <bluelightning> hmm, even with master you're right, it doesn't print anything for the task itself
Feb 24 12:17:00 <bluelightning> this is a bug I think
Feb 24 12:19:52 <bluelightning> still, it definitely does log useful info to log.do_fetch
Feb 24 12:20:21 <Zagor> oh, where is the log?
Feb 24 12:20:35 <bluelightning> for example http://pastebin.com/yWgWJRBT
Feb 24 12:21:22 <bluelightning> you can find it in TMPDIR/work/*/pn-pv-pr/temp/log.do_fetch
Feb 24 12:21:56 <Zagor> right, that looks better
Feb 24 13:06:32 <Zagor> I'm seeing odd behaviour with the sstate mirror. it just compiled dbus from source, but after a "cleanall dbus" it happily fetched it from my mirror!
Feb 24 13:06:53 <Zagor> the mirror being unmodified between the runs
Feb 24 13:17:38 <RP__> mebrown: There is a way of enabling automatically incrementing source revisions
Feb 24 13:17:47 <RP__> mebrown: Look for information about AUTOREV
Feb 24 13:22:58 <RP__> Zagor: keep in mind the sstate files are not fetched as part of do_fetch
Feb 24 13:23:27 <RP__> Zagor: There are separate _setscene tasks which would do the sstate files fetch/install
Feb 24 13:24:07 <RP__> Zagor: The trouble is cleanall can't clean a remote mirror
Feb 24 13:24:32 <Zagor> right, but it looks to me like it made different decisions the two different runs based on the same information
Feb 24 13:25:56 <Zagor> the first run was in a clean dir without even having the download/ and sstate-cache/ local directories
Feb 24 13:26:15 <Zagor> and the second was after "cleanall dbus"
Feb 24 13:27:48 <RP__> Zagor: so you're saying cleanall didn't remove something it should have from downloads or sstate-cache?
Feb 24 13:28:21 <Zagor> I'm saying from my understanding both runs should have done the same thing: either fetching from the mirror or building from source
Feb 24 13:29:19 <Zagor> s/fetching/downloading/
Feb 24 15:09:19 <JaMa|Off> RP__: can we disable package creatin in shadow-sysroot_4.1.4.3.bb somehow?
Feb 24 15:09:48 <RP__> JaMa|Off: set PACKAGES = "" ?
Feb 24 15:09:59 <JaMa|Off> RP__: dbus-dev depends on shadow-sysroot-dev which depends on shadow-sysroot and this as another copy of /etc/login.defs already provided by shadow
Feb 24 15:10:15 <JaMa|Off> s/this as/this has/
Feb 24 16:35:53 <RP__> JaMa|Off: did PACKAGES = "" help?
Feb 24 16:36:09 <RP__> JaMa|Off: I'm also curious if you tried my suggested altnerative to the NATIVESDK vars?
Feb 24 16:37:33 <JaMa|Off> RP__: build still running for PACKAGES
Feb 24 16:37:43 <JaMa|Off> and haven't tried NATIVESDK var yet
Feb 24 16:37:56 <JaMa|Off> but it's in my queue
Feb 24 16:38:10 <mranostay> er INCOMPATIBLE_LICENSE="GPLv3" picks up the native bintuils. how can you build anything? :)
Feb 24 16:38:31 <ant_work> RP__: hi, so I'v seen the fix for the QA about unpackaged empty dirs is to remove them before packaging
Feb 24 16:38:48 <RP__> ant_work: it depends on the particular case
Feb 24 16:39:23 <RP__> JaMa|Off: ok, I'm just working through the patches on the list and wondered about those ones :)
Feb 24 16:39:50 <ant_work> RP__: I see, I have a couple of QA to fix in klibc, one is about empty dirs, the other about missing staticdev
Feb 24 16:40:04 <JaMa|Off> RP__: I guess it won't work for me.. because I was scannig whole -e output for variables which match my python location...
Feb 24 16:40:42 <ant_work> RP__: and finally with the help of pidge we could sort out the correct license for klibc :)
Feb 24 16:41:11 <RP__> JaMa|Off: The STAGING_DIR* variables should be close
Feb 24 16:41:26 <RP__> JaMa|Off: One looked like it would need a ../ in it
Feb 24 16:41:33 <RP__> ant_work: great
Feb 24 16:44:56 <kergoth> mranostay: hah
Feb 24 16:45:08 <kergoth> mranostay: yeah, i've noticed that excluding gplv3 is not an easy prospect right now :|
Feb 24 16:45:55 <mranostay> kergoth: iirc compiler + linker GPLv3 can produce non-GPLv3 code right? :)
Feb 24 16:46:19 <kergoth> :)
Feb 24 16:46:27 <kergoth> clearly the INCOMPATIBLE bits need a bit of love
Feb 24 16:46:52 <JaMa|Off> RP__: PACKAGES = "" helps a bit.. package doesn't exist so opkg wont be able to install it.. only issue is bug in opkg doesn't remove package entries from /var/lib/opkg/status so it complains "Package shadow-sysroot-dev is not available from any configured src." instead of "unsatisfied recommendation for shadow-sysroot-dev", but I'll send patch tonight as it's still improvement
Feb 24 16:47:07 <RP__> Its not covered by the autobuilder, it is covered by manual QA. Its what is now blocking 1.1.1 being released
Feb 24 16:47:24 <RP__> JaMa|Off: ok
Feb 24 16:47:33 <JaMa|Off> and of course dbus-dev still depends on shadow-sysroot-dev
Feb 24 16:47:46 <JaMa|Off> s/depends/recommends/
Feb 24 16:47:53 <JaMa|Off> -on
Feb 24 16:49:23 <RP__> JaMa|Off: right, that is a bit messy
Feb 24 16:50:11 <RP__> JaMa|Off: although no worse than the 100s of other broken depends that code injects
Feb 24 16:52:59 <JaMa|Off> yep
Feb 24 16:54:03 <JaMa|Off> RP__: btw are you reviewing/build testing that sstate hardcoded-paths patch from yesterday?
Feb 24 16:54:22 <RP__> JaMa|Off: You said you were testing it further?
Feb 24 16:54:39 <JaMa|Off> RP__: I've tested it with my favourite qemux86-64copy and it's solid
Feb 24 16:55:44 <RP__> JaMa|Off: cool, I'll pull that in then
Feb 24 16:55:58 * mranostay goes off to battle the trees
Feb 24 16:56:00 <JaMa|Off> I've changed sstate.bbclass to keep SSTATE_BUILDDIR and then greped all SSTATE_BUILDDIRs in tmpdir for qemux86-64copy and it was clean
Feb 24 16:56:24 <RP__> JaMa|Off: sounds good :)
Feb 24 16:57:17 <khem> RP__: some time ago I posted patches for thumb tuning. It would be nice if you could look at them ?
Feb 24 16:57:50 <RP__> khem: I remember looking at them and they seemed wrong. I've not got back to figure out why I felt they were wrong but I think Phil replied
Feb 24 17:06:37 <khem> RP__: let me find Phil's reply
Feb 24 17:07:17 <khem> hmm ltg is down it seems
Feb 24 17:07:57 <JaMa|Off> khem: have you found any more patches for thumb+gold issue? I've rebuilt my image with bfd and I can confirm the issues are caused by gold only
Feb 24 17:08:46 <JaMa|Off> khem: and I guess important part is that affects only armv4t, armv5t and higher seems fine
Feb 24 17:10:07 <khem> JaMa|Off: I had a hunch it was gold bug
Feb 24 17:10:29 <khem> JaMa|Off: I will try to reproduce it here and see if I can dig out a fix
Feb 24 17:10:57 <JaMa|Off> great, thanks
Feb 24 17:16:38 <khem> RP__: ok I refreshed thumb issue
Feb 24 17:17:21 <khem> RP__: problem we have is following. We changed the meaning of 'thumb' with tuning overhaul
Feb 24 17:17:43 <khem> RP__: thumb use to be in overrides if the code was being compiled in thumb mode
Feb 24 17:18:03 <khem> but now its in overrides if the given core supports thumb
Feb 24 17:18:28 <khem> thats a big semantic difference and some recipes use thumb override
Feb 24 17:18:46 <khem> in the sense that code it being compiled for thumb mode
Feb 24 17:19:20 <khem> now when I think a bit more I think we have used thumb to denote interworking semantics
Feb 24 17:19:30 <khem> where we append 't' and 't2' to packages
Feb 24 17:19:43 <khem> while the package itself may not be compiled in thumb mode
Feb 24 17:20:47 <khem> so I think we have two aspects. 1. how its built what ISA is used 2. What package arch is it
Feb 24 17:22:08 <khem> right now we kind of take care of 2.
Feb 24 17:22:22 <khem> for 1. we use ARM_INSTRUCTION_SET variable
Feb 24 17:24:46 <RP__> khem: I'm sorry but I don't have time to do this conversation justice right now :(
Feb 24 17:28:35 <seebs> I will be sort of interested if you find a good way to resolve that distinction, because I know the WR build system has some kludges in that general area too.
Feb 24 17:29:05 <seebs> The possibility of intermixing code for two things that would otherwise be considered CPU variants breaks a number of assumptions.
Feb 24 17:29:14 <otavio> ERROR: Task do_package_setscene depends upon nonexistant task /home/otavio/hacking/ossystems/embedded-linux/openembedded-core/meta/recipes-core/base-passwd/base-passwd_3.5.22.bb:do_populate_sysroot_setscene
Feb 24 17:29:14 <khem> yes
Feb 24 17:29:30 <otavio> I wipped out tmpdir and deploy; now my build fails with this
Feb 24 17:29:33 <khem> seebs: thats why I introduced thumb and thumbmode
Feb 24 17:29:41 <otavio> any clue what might be the cause of it?
Feb 24 17:29:42 <khem> where thumb means the core supports thumb
Feb 24 17:29:54 <khem> and thummode means the code is compiled in thumb intructions
Feb 24 17:30:57 <khem> I think what packaging care about is if the code is interworking or not
Feb 24 17:31:10 <khem> it really does not care if its compiled in thumb or arm
Feb 24 17:38:30 <RP__> otavio: were you trying that externalsrc code?
Feb 24 17:38:51 <otavio> RP__: no ... it wasn't me.
Feb 24 17:39:02 <otavio> RP__: my case was the gitpkgv ;-)
Feb 24 17:40:16 <khem> life would be so simple of we just did not support arm < armv5t :)
Feb 24 17:43:00 <JaMa|Off> khem: :)
Feb 24 17:43:37 <khem> JaMa|Off: can I buy back your armv4t device
Feb 24 17:44:56 <JaMa|Off> khem: no but you can hope that everyone who still has om-gta0[12] will swap board for om-gta04 with armv7a
Feb 24 17:45:27 <khem> ok, I will add that line to my daily prayers
Feb 24 17:46:06 <halstead> RP__ , sgw , So I've done my research and the software from reviewboard.org requires review requests to be made via the webUI or via a command line python tool. Adding any sort of e-mail gateway would be a huge project.
Feb 24 17:47:56 <sgw> halstead: thanks for looking into this, I guess we stick with same process we have right now.
Feb 24 17:50:14 <otavio> Good ... this error happens even with a build from scratch
Feb 24 17:50:40 <otavio> RP__: any guess what might have broken this? I am using oe-core and bitbake tip's
Feb 24 17:50:45 <halstead> sgw, Okay. If I could get some volunteer time with a process engineer would it be worth setting up a conference call to outline minimum viable product?
Feb 24 17:56:52 <JaMa|Off> otavio: my guess is something from today.. because yesterday I did few builds from scratch
Feb 24 17:57:34 <otavio> JaMa|Off: It seems to be on oe-core, not bitbake
Feb 24 17:58:10 <otavio> JaMa|Off: ahhh
Feb 24 20:00:37 <JaMa|Off> RP__: I'm building all combinations of SDKMACHINE/MACHINE/gdb-cross-canadian to be sure, but proposed STAGING_INCDIR doesn't match where my python-nativesdk is staged.. will send those combinations to list when it's ready
Feb 24 21:45:14 <xumbi> if I build "virtual/kernel" it builds "linux-dummy", how do I make it build a kernel recipe I have in my layer?
Feb 24 21:46:17 <autif> tomz2 - during ELC, you showed me how to configure the kernel "bitbake linux-yocto -c menuconfig", I now have a diff of .config in a file (say) config.diff - how do I append the linux-yocto recipe to include this config change? adding it in SRC_URI does not seem to help
Feb 24 21:50:30 <autif> this is for the touchscreen - i think i need evdev - which is not configured for the kernel - I need to patch that
Feb 24 21:51:41 <tomz2> autif: SRC_URI += "file://xxx.cfg" should work.
Feb 24 21:54:12 <autif> trying to rename it
Feb 24 22:00:22 <autif> tomz1 - http://pastebin.com/7ZXyCLeS     I have this now. However, config.cfg is copied to tmp/work/crownbay/linux-yocto/ and it is not applied to tmp/work/crownbay/linux-yocto/linux-corwnbay/.config
Feb 24 22:02:11 <tomz2> autif: is that the contents of the .cfg?
Feb 24 22:03:51 <tomz2> autif: anyway, that looks like a patch, which isn't what you want for a .cfg
Feb 24 22:04:03 <autif> oh
Feb 24 22:04:08 <tomz2> autif: simply list the config items you want to set
Feb 24 22:04:10 <autif> so, just the extra stuff
Feb 24 22:04:13 <autif> ok
Feb 24 22:04:14 <autif> will do
Feb 24 22:04:32 <tomz2> e.g. CONFIG_INPUT_EVDEV=y
Feb 24 22:04:49 <tomz2> autif: one per line, etc, it's just a list of config settings
Feb 24 22:07:23 <autif> wow! it worked - like magic
Feb 24 22:07:24 <autif> thanks!
Feb 24 22:07:30 <autif> thanks tomz2
Feb 24 22:36:43 <halstead> Bugzilla upgrade starts in 30 minutes. Expect 0.5 to 3 hours of downtime.
Feb 24 23:12:44 <ant__> zeddii: ping
Feb 24 23:30:54 <halstead> We have an upsteam delay on changing DNS. So were not quite back up yet. The rest of the bugzilla upgrade has gone well.
Feb 24 23:37:41 <RP__> halstead: good to hear :)
Feb 24 23:38:19 <halstead> RP__, Thanks. I'm testing with an altered host file and it looks good.
Feb 24 23:38:49 <ant__> RP__: I get a strange  grep: Memory exhausted
Feb 24 23:39:02 <ant__> during do_patch of linux-yocto
Feb 24 23:40:07 <ant__> build is finishing ok, just this strange log
Feb 24 23:41:04 <ant__> http://paste.debian.net/157508/
Feb 24 23:41:13 <halstead> Of course the bugzilla project decided to do a major 4.2.0 release on Wednesday. So we might have a step upgrade soon.
Feb 24 23:50:53 <RP__> halstead: typical!
Feb 24 23:51:23 <RP__> ant__: I'd ask zeddii about that
Feb 24 23:51:38 <RP__> ant__: Looks like it happened in the kernel tooling
Feb 24 23:52:48 <ant__> I'm still learning the 'compatibility mode', maybe is my faulty config
Feb 24 23:53:08 <ant__> or the chunk is just too big...
Feb 25 00:12:58 <halstead> DNS change complete. The new server should be visible to everyone within 5 minutes.
Feb 25 00:15:37 <halstead> Outgoing e-mail tested and working.
Feb 25 00:16:01 <JaMa|Off> RP__: I think I still need other way to exclude some dependencies from OEBasicHash :/
Feb 25 00:17:02 <JaMa|Off> RP__: I have this usecase for it.. intone is graphical app for managing songs and movies, it's calling mplayer binary and as long as mplayer CLI is stable then it doesn't care how mplayer was built
Feb 25 00:17:50 <RP__> JaMa|Off: There are some very creative things you can do with that siggen code
Feb 25 00:18:03 <RP__> JaMa|Off: We perhaps need more examples
Feb 25 00:18:10 <JaMa|Off> and because I have patch for mplayer used with nokia900 then after MACHINE switch I'll get not only mplayer rebuilt but also intone
Feb 25 00:18:24 <RP__> JaMa|Off: I have some ideas about prebuilt sstate based toolchains that are probably similar
Feb 25 00:18:59 <RP__> JaMa|Off: If you whitelist mplayer with the existing code, it would work?
Feb 25 00:19:08 <JaMa|Off> I mean in this example I would exclude mplayer because all I care is its CLI
Feb 25 00:19:42 <JaMa|Off> but if for example there is mplayer-foo-module then same dependency on mplayer is now much more strict
Feb 25 00:20:19 <JaMa|Off> RP__: it would work.. but I was looking for way that I want to exclude it from intone but not from mplayer-foo-module
Feb 25 00:20:49 <RP__> JaMa|Off: you have recipename and depname
Feb 25 00:21:25 <JaMa|Off> but generic RDEPENDS_${PN} = "mplayer" ; RDEPENDS_${PN}[excludedep] = "mplayer"
Feb 25 00:21:48 <JaMa|Off> would work for everybody if implemented in OEBasicHash
Feb 25 00:22:07 <RP__> JaMa|Off: datacache won't store that data
Feb 25 00:22:17 <JaMa|Off> but if I create SHRBasicHash then I'll have to ask people to use that if they want to build intone..
Feb 25 00:23:05 <RP__> JaMa|Off: In reality you'd just overwrite OEBasicHash and extend it
Feb 25 00:23:48 <JaMa|Off> with hardcode intone/mplayer combination?
Feb 25 00:24:00 <RP__> JaMa|Off: probably :/
Feb 25 00:24:07 <RP__> JaMa|Off: Its not an easy problem
Feb 25 00:24:13 <JaMa|Off> what if in some other layer someone has different combination and I would like to build his recipe too?
Feb 25 00:24:21 <RP__> JaMa|Off: At least its not one big regexp anymore ;-)
Feb 25 00:24:42 <JaMa|Off> I still think this information needs to be part of recipe metadata, not BasicHash algoritm
Feb 25 00:24:49 <RP__> JaMa|Off: you'd inherit the original OEBasicHash code
Feb 25 00:25:46 <RP__> JaMa|Off: its a hard problem :(
Feb 25 00:25:58 <RP__> JaMa|Off: recipe metadata doesn't make it into the cache
Feb 25 00:26:07 <RP__> well, only a specific subset
Feb 25 00:26:19 <JaMa|Off> I know but you're clever guy so I belive you :)
Feb 25 00:26:55 <RP__> JaMa|Off: The thought we tried to do this with a regexp in bitbake still makes me shudder
Feb 25 00:27:06 <JaMa|Off> If I really have to then I can create recipe wrapper for it, but that's ugly too
Feb 25 00:27:29 <RP__> JaMa|Off: How many cases of things like this do you think we'll have?>
Feb 25 00:27:58 <JaMa|Off> ie mplayer-cli.bb excluded globally, intone RDEPENDing mplayer-cli and small mplayer-cli rebuilt after every MACHINE switch (but intone kept always the same)
Feb 25 00:28:37 <JaMa|Off> RP__: depends on how much we will be throwing in SIGGEN_EXCLUDERECIPES_ABISAFE
Feb 25 00:29:00 <RP__> JaMa|Off: I'm happy to drop some code into OEBasicHash in the core for now, until we get this better figured out
Feb 25 00:30:43 <JaMa|Off> I'll try to add something like SIGGEN_EXCLUDETUPLES_ABISAFE to be able to add "intone:mplayer" in meta-shr/conf/layer.conf
Feb 25 00:31:23 <JaMa|Off> would you accept such patch for OEBasicHash ?
Feb 25 00:32:39 <JaMa|Off> or maybe SIGGEN_EXCLUDETUPLES "intone->mplayer" to be more clear that's not only ABI and direction of dependency intone=recipename, mplayer=depname
Feb 25 00:36:40 <JaMa|Off> and one more idea before going to bed.. can we consider all task-* recipes as SIGGEN_EXCLUDETUPLES_ABISAFE, because e.g. task-x11-server is machine specific but IMHO it shouldn't propagate checksum changes
Feb 25 00:39:51 <kergoth> okay, am i missing something, or is the get_hash in 1c1df03a6c4717bfd5faab144c4f8bbfcbae0b57 in bitbake completely idiotic? yeah, let's *reimplement* another hashing mechanism, which doesn't obey the exclusion variables the siggen stuff has, that makes a lot of sense
Feb 25 00:42:58 <JaMa|Off> RP__: and another good usecase is task-foo->mplayer, we don't expect task-foo to be rebuilt for each mplayer as long as debian.bbclass doesn't start changing runtime name of mplayer
Feb 25 00:50:00 <RP__> kergoth: thinking about it, it probably doesn't make sense :/
Feb 25 00:50:49 <RP__> JaMa|Off: The task packages are cheap to rebuild if nothing else...
Feb 25 01:04:15 <RP__> JaMa|Off: I think we're getting to the bottom of that NATIVESDK issue finally :)
**** ENDING LOGGING AT Sat Feb 25 02:59:59 2012

**** BEGIN LOGGING AT Sat Feb 25 02:59:59 2012
Feb 25 06:35:00 <JaMa|Off> RP__: cheap but if PRSERV is going to bump them with every machine switch then user will be confused how many upgrades he is getting every time
Feb 25 09:38:17 <RP__> JaMa|Off: agreed, we need to fix it
Feb 25 09:39:46 <bluelightning> hi RP__, all
Feb 25 15:02:23 <RP__> hi bluelightning
Feb 25 15:44:14 <RP__> JaMa|Off: the sstatesig patch looks good, thanks
Feb 25 15:44:21 <RP__> JaMa|Off: just replied about the cross-canadian stuff
Feb 25 19:21:35 <JaMa|Off> RP__: I'm testing cross-canadian now..
Feb 25 21:36:42 <pidge> in #oe
Feb 25 21:40:28 <mranostay> er ok
Feb 25 21:48:19 <pidge> gah, typing mid chan window bring up. :) /join #ircfail
**** ENDING LOGGING AT Sun Feb 26 02:59:59 2012

**** BEGIN LOGGING AT Sun Feb 26 02:59:59 2012
Feb 26 06:56:37 <nlogax_> anyone mind taking a look at the following errors I get when doing the quickstart. http://pastebin.com/PfXjNDUd I'm not sure how to resolve.
Feb 26 06:58:28 <nlogax_> err quickstart guide
Feb 26 09:24:36 <RP__> nlogax_: That says what failed but not how. I'd run the command again and show the full error messages
Feb 26 09:28:18 <nlogax_> would there be any logs that I can look at in /var/logs or something?
Feb 26 11:04:39 <bluelightning> nlogax_: the logs are in TMPDIR/work/*/recipename-version-pr/temp/log.*
Feb 26 11:51:49 * RP__ wonders if he should worry about the noises from inside the walls :/
Feb 26 11:56:59 <seebs> I have been told that in most urban areas, noises inside walls are rats making more rats.
Feb 26 12:19:18 <RP__> seebs: its not rats. I'm hoping its just the wall drying out and loose stone falling down it
Feb 26 12:19:47 <seebs> Ahh, television, you've failed me again.
Feb 26 14:22:14 <RP__> seebs: It could well be different with american buildings. Rats tend not to like eating through stonework
Feb 26 19:14:24 <halstead> pidge, We need to start a new nightly.
Feb 26 19:40:23 <halstead> I triggered one.
Feb 26 22:21:25 <JaMa> bluelightning: Hi.. seems like qt patchset went to wrong list...
Feb 26 22:24:37 <Andy44> Hi my name is Andy.  I was wondering if anyone could tell me how to get around my autotools problem.  I was following the ADT guide.  I followed it step by step!  But when I try to compile the default Hellow Word C template file I get a "*** No rule to make target `all'." error.
Feb 26 22:26:22 <Andy44> This error is so vague.  I've never worked with auto tools and I'm getting really frustrated here.  If anyone has see this problem let me know.  I mean - why on earth doesn't the template Hellow World C program not build!  AHHH!
Feb 26 22:27:06 <bluelightning> JaMa: argh whoops
Feb 26 22:27:40 <RP__> Andy44: It means there is no "all" target in your makefile
Feb 26 22:27:40 <Andy44> anyone want to help out a noob here?
Feb 26 22:28:13 <RP__> Andy44: presumably if you're using autotools you have a makefile.am and then run configure to generate the makefile during configure?
Feb 26 22:28:16 <Andy44> haha yeah I get that... but there's no makefile anywhere.  There are Makefile.am files but none of them have "all" in it
Feb 26 22:28:35 <RP__> Andy44: Was the makefile.am turned into a makefile ?
Feb 26 22:28:43 <Andy44> No
Feb 26 22:29:10 <Andy44> I don't think so. There are two Makefile.am files. One is the src folder and one in the root
Feb 26 22:29:25 <RP__> Andy44: I'm not really familiar with the ADT but did you trigger something to run configure?
Feb 26 22:29:26 <kergoth> sounds like a missing 'inherit autotools'. never looked at the adt guide, though
Feb 26 22:29:30 * kergoth yawns
Feb 26 22:29:39 <Andy44> is it supposed to spit out a makefile?
Feb 26 22:29:54 <Andy44> no the ADT guide does not say I need to run a "configure"
Feb 26 22:30:06 <RP__> Andy44: a makefile should get generated
Feb 26 22:30:09 <Andy44> it just says to open the template and build the project
Feb 26 22:30:10 <bluelightning> JaMa: thanks, I would have missed that :)
Feb 26 22:30:19 <Andy44> ok well that's what I'm missing
Feb 26 22:30:23 <JaMa> bluelightning: btw backfill distro featues are in DISTRO_FEATURES after LDISGOLD without space ${LDISGOLD}${@oe.utils.distro_features_backfill(d)}
Feb 26 22:30:25 <RP__> hi kergoth
Feb 26 22:30:36 <Andy44> do you know what triggers making this file exactly?
Feb 26 22:30:47 <JaMa> bluelightning: haven't looked which should add the space.. but looks like it could end badly
Feb 26 22:30:58 <RP__> Andy44: Are you following an example in the ADT user manual?
Feb 26 22:30:58 <bluelightning> JaMa: it's supposed to add a space itself
Feb 26 22:31:07 <JaMa> ah ok
Feb 26 22:31:15 <Andy44> yes.  I've follow the ADT manual example step by step
Feb 26 22:31:37 <Andy44> RP__: I don't have to use the autotools do I
Feb 26 22:31:38 <RP__> Andy44: which example specifically just so I can get some context?
Feb 26 22:31:47 <bluelightning> JaMa: it does: return " %s" % (" ".join(addfeatures))
Feb 26 22:31:57 <Andy44> RP__ one sec.  Let me pull it up
Feb 26 22:32:00 <RP__> Andy44: I'm assuming the manual is the one at http://www.yoctoproject.org/docs/current/adt-manual/adt-manual.html ?
Feb 26 22:32:33 <Andy44> RP__: yes that's the one
Feb 26 22:32:41 <bluelightning> JaMa: I wanted to avoid changing the value when the backfill is empty as it is now
Feb 26 22:32:44 <Andy44> I chose to use the downloadable tarball
Feb 26 22:33:33 <RP__> Andy44: the step that sounds like its not happening is "Select Project -> Reconfigure Project:                    This selection reconfigures the project by running                 autogen.sh in the workspace for your project.                   The script also runs libtoolize, aclocal,                 autoconf, autoheader,                  automake --a, and                  ./configure."
Feb 26 22:33:47 <RP__> Andy44: assuming the example you're looking at is that one...
Feb 26 22:33:58 <Andy44> Yes I your right!
Feb 26 22:34:35 <Andy44> so this is weird when I try to do what it says in that step nothing happens.  I select Project -> Change Yocto Project Settings and no window pops up...
Feb 26 22:35:03 <RP__> Andy44: it sounds to me like the eclipse plugin isn't installed or working properly for some reason
Feb 26 22:35:13 <JaMa> bluelightning: then it's fine.. I just noticed it in -e output while checking something else
Feb 26 22:35:25 <Andy44> RP__ it is installed.
Feb 26 22:35:28 <RP__> Andy44: if things don't work as described in the manual, I'd start from the first step there is a difference
Feb 26 22:36:02 <RP__> Andy44: If Project -> Change Yocto Project Settings doesn't bring up the dialog, there is something wrong
Feb 26 22:36:42 <Andy44> RP__ thanks for the advice.  I do see a problem here on that step like you said.  However why doesn't the window pop up?  Should I just restart with setting up eclipse from scratch?
Feb 26 22:36:54 <RP__> Andy44: this sounds like https://bugzilla.yoctoproject.org/show_bug.cgi?id=1915
Feb 26 22:37:14 <RP__> Andy44: that bug is an incompatibility between the plugin and eclipse version :/
Feb 26 22:37:20 <Andy44> RP__ oh man
Feb 26 22:37:29 <Andy44> amazing. how did you find that so fast?
Feb 26 22:38:11 <RP__> Andy44: I happen to know most of the high/major bugs :/
Feb 26 22:38:31 <bluelightning> JaMa: ok, just as well to check :)
Feb 26 22:38:42 <Andy44> RP__ thank you so much.  So I should just setup eclipse again with an older version?
Feb 26 22:39:00 <RP__> Andy44: that should work, the bug gives some details of the known good versions
Feb 26 22:39:15 <RP__> Andy44: that issue is being worked on as you'll see in the bug and its priority rating
Feb 26 22:39:45 <Andy44> wow thanks RP__
Feb 26 22:40:30 <Andy44> I'll let you know how it goes.  I really appreciate your time.
Feb 26 22:40:47 <RP__> Andy44: no problem, sorry not to have a better fix
Feb 26 22:41:29 <RP__> Andy44: if you're confident about patching eclipse, http://git.yoctoproject.org/cgit/cgit.cgi/eclipse-poky/commit/?id=514c7a653b35a86ea30f0670831e4558e39b5907 might fix things for you
Feb 26 22:41:47 <RP__> (well, patching the plugin)
Feb 26 22:42:01 <Andy44> I've never done it before but I'd be willing to try it out.
Feb 26 22:42:12 <Andy44> RP__ Give me a minute.
Feb 26 22:42:26 <RP__> Andy44: I have little idea where the appropriate files are I'm afraid
Feb 26 22:43:29 <Andy44> RP__ ahh using git wit the source code is a little above my head here.
Feb 26 22:43:45 <Andy44> I'm going to just redo eclipse
Feb 26 22:43:57 <RP__> Andy44: fair enough, I just thought it might be worth mentioning
Feb 26 22:44:30 <Andy44> is there anyway to know what ecplise works?
Feb 26 22:44:58 <Andy44> i started with a download of 3.7.1 then get all the updates from the update manager in ecplise
Feb 26 22:46:30 <RP__> Andy44: you need an older version of the autotools plugin in eclipse
Feb 26 22:46:52 <Andy44> RP__ ahh right that makes sense.
Feb 26 22:49:43 <Andy44> RP__ i've never had to roll back a version of ecplise add ons.  Do I need to go find the url to the older version of Autotools?  How do I get the older version installed exactly.  It seems Ecplise defaults to the newest version.
Feb 26 22:50:09 <RP__> Andy44: I'm not an eclipse user I'm afraid, I don't know :/
Feb 26 22:54:10 <JaMa|Off> RP__: sorry I've missed at least one missing quote in that patchset.. sent it now
Feb 26 22:54:38 <RP__> JaMa|Off: Its ok, we'll get them eventually. I managed to miss rather a lot on my first attempt :/
Feb 26 22:55:07 <RP__> kergoth: do you agree with the parser quoting change?
Feb 26 22:58:20 <JaMa|Off> RP__: for me that was easy as I always get full reparse with latest bitbake as reported in "[bitbake-devel] cache broken in master" thread
Feb 26 22:59:43 <RP__> JaMa|Off: ah, if you have a moment to apply Dongxaio's patch and report back to him that could be useful so we can check which variable is causing the issue
Feb 26 23:00:01 <RP__> JaMa|Off: PRC will be waking up in a few hours and I think that bug is first on their agenda ;-)
Feb 26 23:02:40 <JaMa|Off> I was just replying to that email :)
Feb 26 23:03:18 <ant__> RP__: hi, after a85f283 I'm seeing a glib-2.0-native error :/
Feb 26 23:04:08 <RP__> ant__: what kind of error
Feb 26 23:04:14 <RP__> JaMa|Off: great, thanks :)
Feb 26 23:04:20 <ant__> rmdir: failed to remove `/oe/oe-core/build/tmp-eglibc/work/i686-linux/glib-2.0-native-1_2.30.2-r5/image/oe/oe-core/build/tmp-eglibc/sysroots/i686-linux/usr/lib/gio/modules/': Directory not empty
Feb 26 23:05:01 <RP__> ant__: right, this was mentioned on the mailing list. What files are in there?
Feb 26 23:06:21 <ant__> doh, it's empty
Feb 26 23:06:30 <Andy44> RP__: So I got the older version of Autotools in Ecplise.  And sure enough now the window pops up.  However, doing step 4.3. doesn't fix my problem.
Feb 26 23:07:15 <Andy44> RP__: It still says "*** No rule to make target `all'." when I build.
Feb 26 23:07:30 <RP__> Andy44: ok, is there a autogen.sh script?
Feb 26 23:07:36 <Andy44> yes
Feb 26 23:07:43 <RP__> Andy44: what happens if you manually run that?
Feb 26 23:07:45 <Andy44> I've tried running it from shell
Feb 26 23:07:52 <Andy44> nothing seems to happen
Feb 26 23:08:12 <Andy44> I mean bash doesn't give me anything back.
Feb 26 23:08:22 <RP__> does the file have things in it?
Feb 26 23:08:29 <Andy44> yes
Feb 26 23:08:40 <RP__> it should show output...
Feb 26 23:08:42 <Andy44> it has what the manual says it's supposed to do
Feb 26 23:08:55 <Andy44> "runs libtoolize, aclocal, autoconf, autoheader, automake --a, and ./configure."
Feb 26 23:09:07 <RP__> I would be very surprised if those were totally slient
Feb 26 23:09:22 <Andy44> ok I get that.  So I tried putting a dummy file in that folder called test.sh
Feb 26 23:09:59 <Andy44> all it does is add a dummy folder to $PATH and for some reason when I run that from the shell the folder doesn't end up getting added to $PATH
Feb 26 23:10:52 <Andy44> so something messed up here.  Also I had to run the contents of /opt/poky/1.1/environment-setup-x86_64-poky-linux one line at a time by hand because I couldn't get the script to run for me
Feb 26 23:11:21 <RP__> Andy44: This sounds like there is something wrong with your shell :/
Feb 26 23:11:27 <RP__> are you using bash?
Feb 26 23:11:32 <Andy44> yes
Feb 26 23:11:37 <Andy44> is that wrong?
Feb 26 23:11:45 <RP__> Andy44: no, bash should be fine
Feb 26 23:11:52 <Andy44> When I do $SHELL it says \bin\bash
Feb 26 23:12:16 <ant__> RP__: usr/lib/gio/modules   libgiofam.la  libgiofam.so  (from my /image dir in workdir)
Feb 26 23:13:03 <ant__> but /usr/lib/gio/modules is not in sysroot
Feb 26 23:13:06 <RP__> ant__: Add --disable-fan to EXTRA_OECONF
Feb 26 23:13:18 <Andy44> hmm, the problem really is that I can't run the autogen.sh by hand.
Feb 26 23:13:21 <RP__> er, --disable-fam
Feb 26 23:13:35 <RP__> Andy44: yes, it looks like that isn't running either by hand or by the system
Feb 26 23:13:53 <RP__> Andy44: does "bash autogen.sh" work any better?
Feb 26 23:14:13 <Andy44> RP__: let me see
Feb 26 23:16:43 <ant__> RP__: native is ok with EXTRA_OECONF_virtclass-native = "--disable-dtrace --disable-systemtap --disable-fam"
Feb 26 23:16:53 <RP__> ant__: yes
Feb 26 23:17:03 <RP__> ant__: we should add it to both cases
Feb 26 23:17:13 <RP__> ant__: and check if there is anything else we should be disabling
Feb 26 23:17:45 <ant__> I'm rebuilding glib-2.0 now
Feb 26 23:18:15 <Andy44> RP__: now where getting somewhere thanks man - when I run "bash autogen.sh" it says it cant find the programs - ie I get "aclocal: not found" back (and a line for every other call in the scripe
Feb 26 23:18:30 <Andy44> so where is aclocal supposed to reside?
Feb 26 23:18:52 <Andy44> that's an ADT tool right?
Feb 26 23:19:26 <RP__> Andy44: it depends which version of the adt you have. In modern versions it comes with the toolchain tarball
Feb 26 23:19:42 <RP__> by modern I mean cutting edge development
Feb 26 23:19:56 <Andy44> yeah but that new version has the big right?
Feb 26 23:19:59 <Andy44> bug*
Feb 26 23:20:04 <RP__> Andy44: I'm guessing with the last release you need autoconf and automake installed on the system
Feb 26 23:20:49 <RP__> Andy44: "apt-get install automake autoconf" or whatever your distro's command is
Feb 26 23:23:27 <Andy44> ok got both of those installed.  Now I run "bash autogen.sh" and it runs correctly.
Feb 26 23:23:47 <Andy44> Now my project has all sorts of new files in it...
Feb 26 23:25:09 <RP__> Andy44: sounds much more healthy! :)
Feb 26 23:25:35 <Andy44> haha thanks!  Still doesn't build though when I do "build project"
Feb 26 23:25:55 <RP__> Andy44: Dare I ask what it says now?
Feb 26 23:26:17 * RP__ assumes you now have a Makefile at least?
Feb 26 23:27:40 <Andy44> RP__: I really appreciate your help so far.  I feel like I'm close but I'm still getting the same error.
Feb 26 23:27:55 <Andy44> "*** No rule to make target `all'."
Feb 26 23:29:03 <RP__> Andy44: sounds like there is still no Makefile?
Feb 26 23:29:14 <Andy44> RP__: my src folder has a makefile.in and a makefile.am in it now... seems wrong.  Isn't the "in" older?
Feb 26 23:29:32 <RP__> Andy44: configure didn't run
Feb 26 23:29:55 <Andy44> Your expecting a file simply called Makefile to be there somewhere right?
Feb 26 23:30:02 <RP__> Andy44: automake turns makefile.am -> makefile.in, then configure turns makefile.in -> makefile
Feb 26 23:30:04 <RP__> Andy44: yes
Feb 26 23:34:21 <Andy44> RP__: ahh you're right configure throws an error.  I was just looking through config.log and it's not clear what's wrong.
Feb 26 23:34:43 <RP__> Andy44: pastebin the config.log
Feb 26 23:35:10 <Andy44> I've heard someone say that before.  What's pastebin?
Feb 26 23:35:22 <RP__> Andy44: pastebin.com
Feb 26 23:35:26 <Andy44> got it
Feb 26 23:35:27 <Andy44> one sec
Feb 26 23:38:59 <Andy44> RP__: pastebin.com/22b1DTe7
Feb 26 23:39:38 <ant__> RP__: glib-2.0 built fine, though I have now to retest after the drop-dbus patch
Feb 26 23:43:26 <RP__> Andy44: /home/lasx/workspace/try6/configure:  line 3137:  /opt/poky/1.1/sysroots/x86_64-pokysdk-linux/usr/bin/i586-poky-linux/i586-poky-linux-gcc:  cannot execute binary file
Feb 26 23:43:39 <RP__> Andy44: have you selinux running or something?
Feb 26 23:43:42 <Andy44> ok I see it too
Feb 26 23:43:50 <Andy44> um no
Feb 26 23:43:59 <Andy44> It's Ubuntu in a VM
Feb 26 23:44:15 <RP__> Andy44: there is something really odd going on with your machine like there are security settings or something
Feb 26 23:44:38 <Andy44> i made a root user
Feb 26 23:44:40 <Andy44> sudo -i
Feb 26 23:44:45 <Andy44> but that's about it
Feb 26 23:45:11 <RP__> Andy44: you need to figure out why it can't execute those files. Could be a permissions issue or some kind of some kind of security policy
Feb 26 23:46:17 <RP__> Andy44: if you run "cat /selinux/enforce" does that show anything?
Feb 26 23:47:12 <Andy44> says no such file or directory
Feb 26 23:47:46 <Andy44> I think I did a chmod -R 777 /opt
Feb 26 23:48:02 <Andy44> would that be owning me?
Feb 26 23:48:56 <RP__> Andy44: What does "ls -la /opt/poky/1.1/sysroots/x86_64-pokysdk-linux/usr/bin/i586-poky-linux/i586-poky-linux-gcc" say?
Feb 26 23:49:47 <Andy44> -rwxrwxrwx 1 root root 367759 2011-10-05 17:27 /opt/poky/1.1/sysroots/x86_64-pokysdk-linux/usr/bin/i586-poky-linux/i586-poky-linux-gcc
Feb 26 23:50:09 <RP__> Andy44: so its not a file persmissions issue
Feb 26 23:50:21 <Andy44> apparently not
Feb 26 23:50:22 <RP__> Andy44: something else on the system is blocking access to execute that file
Feb 26 23:50:58 <Andy44> I just have no idea what that would be.  It's a virtual machine.  Let me try to restart it again
Feb 26 23:52:14 <RP__> Andy44: you did pick the right toolchain? This is a 64 bit VM you're running in, right?
Feb 26 23:52:47 <Andy44> oh dammit
Feb 26 23:52:47 <nlogax_> anyone mind taking a look at this I'm getting  http://pastebin.com/Rwp4xwq8 . Thanks.
Feb 26 23:52:56 <Andy44> no i don't think this VM is 64 bit...
Feb 26 23:53:09 <RP__> Andy44: grab the other toolchain, the 32 bit one ;-)
Feb 26 23:53:13 <Andy44> :)
Feb 26 23:53:28 <Andy44> jeez thanks RP__
Feb 26 23:53:34 <Andy44> let me try that out
Feb 26 23:54:12 <RP__> notespace1: build from scratch?
Feb 26 23:55:34 <RP__> nlogax_: try installing libxml-parser-perl on your machine
Feb 26 23:56:00 <RP__> nlogax_: or whatever the similarly named package is on your distro
Feb 26 23:56:20 <nlogax_> ok
Feb 26 23:57:01 * RP__ thought we'd fixed those issues but this is probably the easiest way around it
Feb 27 00:07:43 * RP__ -> Zzzz
Feb 27 00:08:30 * mranostay waves
Feb 27 00:09:32 <Andy44> RP__: Yay!  I have a Makefile in my src directory!  But it still wont build!
Feb 27 00:09:45 <Andy44> I get a make:***[all] Error 2
Feb 27 00:10:00 <Andy44> looking online to see what that's about now...
Feb 27 00:16:45 <Andy44> RP__: Can't open ../-libtool
Feb 27 00:16:56 <Andy44> god I'm such a noob
Feb 27 00:21:53 <Andy44> RP__: yahtzee!  did a clean and another configure and bam it builds!!!!
Feb 27 00:22:36 <Andy44> RP__: thank you so much for your help man.  I really apreciate it.  This has been a great learning exerience.
**** ENDING LOGGING AT Mon Feb 27 02:59:58 2012

**** BEGIN LOGGING AT Mon Feb 27 02:59:58 2012
Feb 27 09:10:47 <JaMa|Wrk> RP__: I have one more question about sstate, I've seen a lot of do_package reexecutions with OEBasic, now with sstate hashes almost consistent I'm sure it was happening only when sstate hash was different for do_package
Feb 27 09:11:57 <JaMa|Wrk> RP__: but with OEBasic I would expect do_package stamp to exist without hash in it so it would be enough to consider this task as covered, but for some reason do_package stamps end with MACHINE, e.g. ecore-2_1.1.0+svnr68448-r1.1.do_package.om-gta02
Feb 27 09:13:12 <JaMa|Wrk> RP__: which is understandable for do_populate_sysroot.om-gta02 tasks, but why do_package too?
Feb 27 09:15:50 <JaMa|Wrk> it's also there with OEBasicHash bash-4.2-r1.do_package.a5ac1820a19b7bf2612d4978641a2461.qemuarm, but in this case it's OK, because if there is a5ac1820a19b7bf2612d4978641a2461 from different machine in sstate-cache then it's reused
Feb 27 09:30:24 <RP__> JaMa|Wrk: On my system here, bash do_package does not have a machine specific stamp
Feb 27 09:37:46 <JaMa|Wrk> hmm interesting
Feb 27 09:37:54 <JaMa|Wrk> I have it also with distroless oe-core only
Feb 27 09:39:20 <JaMa|Wrk> RP__: and I mean MACHINE in stamp filename (hash could be the same for different machines)
Feb 27 09:51:40 <RP__> JaMa|Wrk: you're right, that are machine specific
Feb 27 09:52:25 <ant_work> RP__: once fixed glib/fam issue the build from scratch broke on libtool/ I'll check this evening
Feb 27 09:55:13 <JaMa|Wrk> RP__: and do they have to be? it causes OEBasic behave sort of like OEBasicHash after switching MACHINEs and I guess causing rm_work unusable with sstate (because rm_work keeps only package* directories but that's not enough to reexecute do_package)
Feb 27 09:55:41 <RP__> JaMa|Wrk: Its down to SHLIBSDIR which is in the machine specific sysroot
Feb 27 09:56:05 <JaMa|Wrk> RP__: we can keep /image dir too with rm_work, but keeping do_package stamp the same between machines would be more effective)
Feb 27 09:56:08 <JaMa|Wrk> ah ;/
Feb 27 09:56:13 <RP__> JaMa|Wrk: rm_work was taught not to remove do_package's output files
Feb 27 09:56:44 <RP__> JaMa|Wrk: The question is why is it changing between machines
Feb 27 09:57:45 <JaMa|Wrk> I'm still adding few excludes, so it's in not so many cases now .. but still expected different behavior for OEBasic
Feb 27 09:58:06 <ant_work> RP__: this weekend oe-core was broken like oe-classic in its brightest days :p
Feb 27 09:58:15 <JaMa|Wrk> we keep output of do_package, but to execute do_package again we need do_install stamp don't we?
Feb 27 09:58:43 <RP__> ant_work: There has been a lot of change going in :/
Feb 27 09:58:59 <ant_work> yes, and it's a good thing(tm)
Feb 27 09:59:25 <ant_work> the check for unquoted vars is very nice ;)
Feb 27 09:59:41 <RP__> JaMa|Wrk: ah, I see what you mean, yes
Feb 27 09:59:48 <RP__> JaMa|Wrk: its been assumed the stamps would be the same
Feb 27 10:00:09 <JaMa|Wrk> yup so it behaves sort of like OEBasicHash
Feb 27 10:01:15 <JaMa|Wrk> without rm_work it's not big issue, do_package is realatively fast for smaller packages
Feb 27 10:01:39 <JaMa|Wrk> but with rm_work it starts with populate_lic and repeats configure/compile/install too
Feb 27 10:20:49 <RP__> JaMa|Wrk: have you tried bitbake-diffsigs to see what is changing?
Feb 27 10:24:05 <JaMa|Wrk> yup still excluding more and more stuff
Feb 27 10:25:05 <JaMa|Wrk> for example palmpre has patch for tslib support and that causes whole dependency of efl and sdl to be different then rest of armv7a machines I have
Feb 27 10:29:03 <JaMa|Wrk> and e.g. do_install in netbase is also machine specific due to:
Feb 27 10:29:04 <JaMa|Wrk>         # Disable network manager on machines that commonly do NFS booting
Feb 27 10:29:05 <JaMa|Wrk>         case "${MACHINE}" in
Feb 27 10:49:40 <RP__> JaMa|Wrk: hmm, right. We could change the netbase ones into do_install_append_qemuxxx which should stop the general case depending on MACHINE
Feb 27 10:49:51 <RP__> JaMa|Wrk: or whitelist the dependency on machine
Feb 27 10:50:30 <Zagor> is the absolute build path included in the sstate hash?
Feb 27 10:50:49 <Zagor> where can I peek at the hash generator?
Feb 27 10:52:28 <RP__> Zagor: you can see what's in there with bitbake-diffsigs <siginfo/sigdata file>
Feb 27 10:53:15 <RP__> Zagor: the code is bitbake/lib/bb/siggen.py
Feb 27 10:53:35 <RP__> Zagor: summary is that no, the absolute paths shouldn't go in
Feb 27 10:57:47 <Zagor> RP__: looks like the task dependencies have full path: Tasks this task depends on: ['/opt/demo/poky/meta/recipes-devtools/quilt/quilt-native_0.48.bb.do_install']
Feb 27 11:03:15 <Zagor> in the siginfo file, that is
Feb 27 11:19:35 <johnt> hello all, does anyone know if its possible to have yocto not rebuild the toolchain each time i build something and just use an existing toolchain?
Feb 27 11:20:45 <Zagor> johnt: the recommended solution is to reuse the sstate-cache
Feb 27 11:21:36 <johnt> Zagor: ok, how does that work? what is in the sstate-cache?
Feb 27 11:22:42 <Zagor> it contains the finished packages, hashed with the configuration that built it.
Feb 27 11:23:34 <Zagor> so as long as you use the same configuration, your build can use the previously built packages rather than build new
Feb 27 11:23:59 <johnt> would it be possible to grnerate the sstate-cache and distribute it?
Feb 27 11:24:31 <Zagor> yes, you can set up an sstate-cache mirror and set the SSTATE_MIRROR variable to point to it.
Feb 27 11:25:13 <johnt> Zagor: ok, cool. thanks for your help - ill take a look at that now!
Feb 27 11:25:44 <Zagor> however I have found what seems like an issue with the hashes sometimes include the build path
Feb 27 11:26:26 <Zagor> for me it only works when I build with the same path as the mirror was built
Feb 27 11:29:30 <johnt> Zagor: i suppose my real question is - can i use the toolchain which i created with meta-toolchain to build packates in yocto rather than having it rebuild the toolcahin each time? i dont know if that makes sense - i get the impression that im trying to make the system do something it was never intended to do...
Feb 27 11:32:13 <johnt> what do you think?
Feb 27 11:33:29 <Zagor> it does make sense, and you are not alone. there's a bugzilla entry about this containing some remarks by RP__ on why sstate-cache is the recommended solution: https://bugzilla.yoctoproject.org/show_bug.cgi?id=1681
Feb 27 11:34:32 <Zagor> I'm not a yocto expert, just relaying what I've learned
Feb 27 11:35:23 <Zagor> and now I'm off to lunch :-) back in a bit.
Feb 27 11:40:50 <johnt> ok - thanks for the info!
Feb 27 11:42:58 <RP__> Zagor: Whilst you see those paths, they aren't used in the hash and are for debug only
Feb 27 11:43:31 <RP__> Zagor: best thing to do would be to take two hashes you think should be the same and run bitbake-diffsigs between them
Feb 27 11:43:49 <RP__> (bitbake-diffsigs <sigdata1> <sigdata2>(
Feb 27 12:25:17 <Zagor> RP__: what causes this? List of dependencies for variable CCACHE_DIR changed from set(['MULTIMACH_HOST_SYS', 'PN', 'TMPDIR']) to set(['HOST_SYS', 'PN', 'TMPDIR'])
Feb 27 12:26:14 <RP__> Zagor: Hmm, that does look strange
Feb 27 12:26:23 <Zagor> I haven't fiddled knowingly with ccache settings in either place
Feb 27 12:27:01 <RP__> Zagor: bitbake.conf clearly says export CCACHE_DIR = "${TMPDIR}/ccache/${MULTIMACH_HOST_SYS}/${PN}"
Feb 27 12:28:00 <RP__> Zagor: What does bitbake-diffsigs say about the value itself?
Feb 27 12:28:08 <RP__> Zagor: was that the only change?
Feb 27 12:28:15 <Zagor> changed items: set(['HOST_SYS', 'MULTIMACH_HOST_SYS'])
Feb 27 12:28:34 <RP__> Zagor: Could you share the full output please (pastebin?)
Feb 27 12:28:35 <Zagor> no, other items were changed too. such as: changed items: set(['USERNAME']) (in basewhitelist)
Feb 27 12:28:43 <Zagor> sure
Feb 27 12:29:15 <Zagor> http://pastebin.com/TtvV98Li
Feb 27 12:30:17 <RP__> Zagor: Is that from two different versions of poky?
Feb 27 12:30:46 <Zagor> shouldn't be. checking...
Feb 27 12:31:30 <Zagor> gah, yes it is. well spotted.
Feb 27 12:31:44 <RP__> Zagor: before and after http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/conf/bitbake.conf?id=82785064ac9059da83aa657b9ed8f8ff4a488ef8 ? :)
Feb 27 12:32:36 <Zagor> no, one is from Nov 23 2011 and the other Feb 08 2012
Feb 27 12:33:09 <RP__> Zagor: right, but your first didn't have that change, the second build did :)
Feb 27 12:33:14 <RP__> Zagor: amongst others
Feb 27 12:33:54 <Zagor> was that not merged into edison until aftern nov23 then?
Feb 27 12:34:19 <RP__> Zagor: no, we only recently made a number of changes to edison in preparation for 1.1.1
Feb 27 12:35:00 <Zagor> ok
Feb 27 12:35:09 <Zagor> well, this explains a lot...
Feb 27 12:35:53 <RP__> Zagor: http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/conf/bitbake.conf?h=edison&id=d63678cdfab81919949e6ae60b89d782e23b511b has the right date
Feb 27 12:36:09 <Zagor> right
Feb 27 14:35:59 <johnt> does anyone know if there is supposed to be a .bb file for gdbserver?
Feb 27 14:43:42 <johnt> anyone alive out there?
Feb 27 14:44:02 <Zagor> alive? yes. knows the answer? no.
Feb 27 14:44:26 <JaMa|Wrk> bluelightning: "set -x" patch, yay! thanks
Feb 27 14:44:30 <johnt> :(
Feb 27 14:44:52 <bluelightning> JaMa|Wrk: well, it has to be accepted first, but you're welcome :)
Feb 27 14:44:55 <johnt> i wonder if gdb includes gdbserver
Feb 27 14:45:12 <bluelightning> johnt: I believe it would be built as part of the gdb recipe yes
Feb 27 14:45:43 <JaMa|Wrk> bluelightning: it's step in right direction, so I guess it will be :)
Feb 27 14:47:26 <johnt> bluelightning: thanks - that helps! gdb seems to depend on elfutils which looks like its broken because im using uclibc - does that sound plausible?
Feb 27 14:48:02 <bluelightning> johnt: I don't have a lot of experience with uclibc, I guess it's possible, but elfutils is kind of fundamental so it is surprising
Feb 27 15:04:11 <Zagor> RP__: here's a diffsigs that says all that changed is a bunch of dependency paths: http://pastebin.com/1Fng9S6E
Feb 27 15:05:54 <Zagor> are those paths used in the hash? if not, why did the hash change?
Feb 27 15:12:55 <johnt> any chance anyone knows what gdb-cross is all about?
Feb 27 15:36:29 <errno85> Hello everyone
Feb 27 15:43:58 <RP__> Zagor: There have been improvements in diffsigs recently to try and trim down these kinds of warnings. Could you retry that with bitbake-diffsigs from bitbake in master?
Feb 27 15:45:50 <RP__> johnt: Its a gdb designed to run on the build machine but target the target architecture?
Feb 27 15:46:25 <RP__> and yes, gdb builds a gdbserver package iirc
Feb 27 15:47:02 <d4ny> Hi All, when generating the rootfs from .ipks, who runs the postistall hooks. Is it always generated in runtime with the "run-postinst" package ?
Feb 27 15:47:43 <RP__> d4ny: we attempt them at do_rootfs time and only the ones that error out are run on the target
Feb 27 15:48:57 <RP__> Zagor: FWIW, I think somewhere in that message is a change in a hash this task depends on. The older comparison logic is failing to get to the bottom of it though
Feb 27 15:49:04 <RP__> Zagor: The paths won't matter
Feb 27 15:50:55 <Zagor> right, diffsigs from master gives me 14 changed hashes
Feb 27 15:51:20 <Zagor> now the question is, which was the first to change, and why :)
Feb 27 15:59:02 <d4ny> RP__: thanks, I'm experimenting with pseudo-nativesdk, and I get PSEUDO_UNLOAD=1 behaviour no matter if its unset or not, wierd
Feb 27 16:33:47 <JaMa|Wrk> what can cause this: ERROR: Bitbake's cached basehash does not match the one we just generated ?
Feb 27 16:34:20 <JaMa|Wrk> I've seen it before with images (assuming it's caused because they depend on DATE/TIME), but now I got it for more recipes
Feb 27 16:35:20 <kergoth> I've seen it once or twice too, the error isn't exactly informative
Feb 27 16:35:34 <msm> seen it too
Feb 27 16:35:39 <msm> not sure what it's from
Feb 27 16:35:56 <JaMa|Wrk> both while running bitbake -S ?
Feb 27 16:36:12 <msm> JaMa|Wrk: actually, that's where I see it if I recall correctly
Feb 27 16:36:15 <kergoth> yep
Feb 27 16:36:42 <kergoth> tried it once or twice, saw it didn't work, and moved on to other mechanisms, no time to dig
Feb 27 16:37:18 <JaMa|Wrk> it's maybe 15th execution of bitbake -S for all machines here today, but first with this errors in many recipes not just rootfs :/
Feb 27 16:39:06 <kergoth> still hitting some bad lack of sstate reuse across machines here :| need to spend this work digging into it
Feb 27 16:39:16 <kergoth> s/work/week/
Feb 27 16:39:44 * JaMa|Wrk is down to only one recipe changing checksums after machine switch
Feb 27 16:44:59 <JaMa|Wrk> this 2 commands are very handy hunting diffs:
Feb 27 16:45:01 <JaMa|Wrk> for MACHINE in om-gta01 om-gta02 om-gta04 nokia900 palmpre palmpre2 crespo; do export MACHINE; find tmp-eglibc/stamps/ -name \*sigdata\* | xargs rm -f; bitbake task-shr task-shr-minimal task-shr-feed -S;  cp -ra tmp-eglibc/stamps/ stamps.dir.${MACHINE}; find tmp-eglibc/stamps/ -name \*sigdata* | sort > stamps.all.${MACHINE}; grep -v "${MACHINE/-/_}" stamps.all.${MACHINE} > stamps.${MACHINE}; done
Feb 27 16:45:37 <JaMa|Wrk> for MACHINE in om-gta04 nokia900 palmpre palmpre2 crespo; do export M1=nokia900; export M2=${MACHINE}; diff stamps.${M1} stamps.${M2} | grep -v .do_build.sigdata. | grep -v "\---" | grep -v "^[[:digit:]]" | sed 's/^[\<\>] //g; s#t
Feb 27 16:45:41 <JaMa|Wrk> mp-eglibc/stamps/##g' | sort > stamps.diff.${M1}.${M2}; done
Feb 27 18:06:38 <mranostay> so does MACHINE_FEATURES actually pull in packages to the rootfs? i assume this depends on what image type you use?
Feb 27 18:07:48 <bluelightning> mranostay: some of the features will do that, yes... see meta/recipes-core/tasks/task-base.bb
Feb 27 18:07:59 <kergoth> don't forget to clean and rebuild task-base after changing it
Feb 27 18:10:51 <mranostay> does task-base get included in every image recipe?
Feb 27 18:15:41 <kergoth> nope. in particular, core-image-minimal does *not*. grep for it
Feb 27 18:17:38 <mranostay> ah an example of a image that does?
Feb 27 18:20:34 <mranostay> ah i think i see it now
Feb 27 18:22:47 <bluelightning> mranostay: anything that inherits the core-image bbclass will include task-base-extended
Feb 27 18:51:12 <autif> After looking at what a mess HTML5 is (http://en.wikipedia.org/wiki/HTML5_video), I thought i might as here - I have added webkit and web2 to my image (based on core-image-sato). I can get audio from the browser, however, I am not sure what video format is supported. I have not whitelisted any specific video format
Feb 27 19:13:31 <mranostay> kergoth: so i see task-base-ext2 gets built but not included in the image. i assume i'm missing some magic? :)
Feb 27 19:25:06 <dvhart> zeddii, poke
Feb 27 19:25:28 <dvhart> zeddii, are you actively working Bug 2032
Feb 27 19:25:29 <dvhart> ?
Feb 27 19:25:48 <dvhart> didn't want to duplicate effort, but need to get this resolved ASAP
Feb 27 19:26:36 <zeddii> already fixed here.
Feb 27 19:27:05 <dvhart> zeddii, great, patch to arrive shortly?
Feb 27 19:27:22 <mranostay> kergoth: or did i forget to -c clean something?
Feb 27 19:27:41 <zeddii> yep. it's on my zedd/kernel contrib branch now. I just need to ammend the commit and add the bug number and push it out.
Feb 27 19:28:02 <dvhart> excellent, I have a team blocked on this right now
Feb 27 20:59:25 <autif> I am on crownbay machine and glxgears is giving me 250 frames per second. This means that the emgd driver is well integrated and functioning. However, when I play a movie, I am not getting the hardware acceleration I expect. I am usin gst-launch playbin2 uri=file:///path/to/movie.avi - the movie decodes fine - but I am gettng like 0.5-1.0 frames per second. Do I need to do something else? I am somewhere between M2 and master
Feb 27 21:10:57 <autif> also, its seems like the video player has been taken out of core-image-sato
Feb 27 21:14:27 <RP__> autif: I suspect it was classified as a test-app and is only installed if you set the appropriate IMAGE_FEATURES
Feb 27 21:18:59 <autif> I see
Feb 27 21:22:32 <autif> In general - if I have hardware acceleration for H.264 (crownbay), I should also have hardware acceleration for other formats - like mp4, Theora and Xvid - is this statement accurate?
Feb 27 22:02:33 <sgw> msm: ping regarding your recent patch, are you reworking 3/4?
Feb 27 22:05:16 <msm> sgw: i think so, or another incremental patch
Feb 27 22:05:25 <msm> sgw: it doesn't break anything though
Feb 27 22:05:47 <msm> sgw: it just needs to be updated either in that patch or in an incremental patch...
Feb 27 22:06:01 <msm> sgw: im rambling, probably just wait for an update
Feb 27 22:06:52 <RP__> autif: I'm not sure
Feb 27 22:11:37 <sgw> msm: Ok waiting will you have a whole patch set in a repo that I can rebase from, that would be helpful on this end.
Feb 27 22:15:48 <msm> sgw: hmm, i guess it's about time for that =)
Feb 27 22:42:34 <ant__> sgw: ping
Feb 27 22:44:53 <sgw> ant__: what's up?
Feb 27 22:45:13 <ant__> hm.. I think I had a race building libtool
Feb 27 22:45:16 <ant__> http://paste.debian.net/157876/
Feb 27 22:45:33 <ant__> and btw help2man is installed on my host
Feb 27 22:45:53 <ant__> now, libtool built on second run...
Feb 27 22:46:23 <sgw> ant__: reviewing
Feb 27 23:10:27 <sgw> ant__: I will test some DEPENDS changes for libtool-native
Feb 27 23:19:46 <ant__> ok, thx
Feb 27 23:26:10 <ant__> sgw: this may be of help: http://paste.debian.net/157881/
Feb 27 23:26:45 <ant__> this is the log of second run
Feb 27 23:30:09 <sgw> ant__: what would be more interesting I think would be the do_configure and do_compile logs between run 1 and run 2 (maybe even the config.log files)
Feb 27 23:48:43 <ant__> sgw: http://www.2shared.com/file/aV7ZN6JP/libtool-242-r20tar.html
Feb 27 23:49:09 <ant__> blue download
Feb 27 23:50:56 <sgw> ant__: thanks
Feb 27 23:51:09 <ant__> yw
Feb 27 23:54:54 <ant__> btw # which help2man -> /usr/bin/help2man
Feb 28 01:22:51 <mebrown> I have a conundrum:
Feb 28 01:22:52 <mebrown> ERROR: Function 'Network access disabled through BB_NO_NETWORK but access rquested with command git clone --bare --mirror file:///home/autobuild/TEST/stdbuild/build-yocto-sh4/../meta-drac/recipes-avct/avct-trace/git /home/autobuild/TEST/stdbuild/build-yocto-sh4/downloads/git2/.home.autobuild.TEST.stdbuild.build-yocto-sh4....meta-drac.recipes-avct.avct-trace.git (for url None)' failed
Feb 28 01:23:19 <mebrown> as you can plainly see in the git clone, it is trying to clone a file:// URL
Feb 28 01:23:45 <mebrown> and I have:
Feb 28 01:23:47 <mebrown> BB_NO_NETWORK = "0"
Feb 28 01:23:47 <mebrown> BB_FETCH_PREMIRRORONLY = "1"
Feb 28 01:28:55 <sgw> mebrown: are you using a tag for your git pull or a full git hash?
Feb 28 01:29:08 <mebrown> tag
Feb 28 01:29:25 <mebrown> it's sort of complicated.
Feb 28 01:29:26 <sgw> That might be it, the git fetch likes to look that up and convert it to a hash, try putting a hash
Feb 28 01:29:37 <mebrown> I can't put a hash
Feb 28 01:29:44 <mebrown> that would defeat the purpose of what I'm trying to do
Feb 28 01:31:02 <sgw> mebrown: Not sure what you are trying to do, but it sounds like you move the tag around to different hashes?
Feb 28 01:31:14 <mebrown> well, it is sort of complicated... sec.
Feb 28 01:31:17 <mebrown> http://pastebin.com/E1LthNMH
Feb 28 01:31:30 <mebrown> ^--- is called localsource.bbclass
Feb 28 01:31:46 <mebrown> and I'm using the android "repo" tool to stitch together some repos
Feb 28 01:31:56 <mebrown> it is working pretty well so far, just trying to sort odds and ends
Feb 28 01:32:06 <mebrown> I have a 'meta-drac' layer
Feb 28 01:32:18 <sgw> I know that RP__ is working on a variant of this for the kernel (not sure if it is git based or not).
Feb 28 01:32:32 <mebrown> with stuff like: "meta-drac/recipes-dell/recipefoo/foo_1.0.bb"
Feb 28 01:32:44 <mebrown> and there is a "git/" subdir in meta-drac/recipes-dell/recipefoo
Feb 28 01:33:09 <mebrown> which then becomes what is cloned to build
Feb 28 01:33:53 <mebrown> and it it working well, just this issue came up where I want to set PREMIRRORONLY = "1", but I can't
Feb 28 01:34:34 <sgw> you might have to dive into the bitbake fetcher2 code to untangle this, you have a pretty specific corner case.
Feb 28 01:37:56 <sgw> mebrown: We might have to check protocol of file in either git.py before it does the check_network_access() or in check_network_access() itself, clearly protocol of file:// should be local access only.
Feb 28 01:40:12 <sgw> mebrown: there's 3 places in bitbake/lib/bb/fetcher2/git.py that would need a check of protocol != "file" then check_network_access(), if you want to give that a try, that might be a good patch to send to the bitbake-devel alias.
Feb 28 01:41:23 <mebrown> I'll check it out
Feb 28 01:42:18 <mebrown> I'm trying to run with no patches on top of yocto edison, but this one breaks me, unfortunately, so I'll need to patch it
Feb 28 01:45:39 <sgw> mebrown: we are doing our best!  that's the only solution I can think of, If you want to file a bug against 1.1 we might be able to add it to edison v1.1.2
Feb 28 01:47:41 <mebrown> I know. you all are doing a fairly decent job of it. :)
Feb 28 01:49:23 <mebrown> Another unrelated question:
Feb 28 01:49:39 <mebrown> I have some recipes where the source may or may not be available depending on who is building it.
Feb 28 01:50:22 <mebrown> Is it feasible to use previously-built IPKs depending on some variable in local.conf?
**** ENDING LOGGING AT Tue Feb 28 02:59:59 2012

**** BEGIN LOGGING AT Tue Feb 28 02:59:59 2012
Feb 28 09:53:32 <JaMa> khem: while looking at thumb issue with binutils-2.22 from oe-core, this patch is not applied http://sourceware.org/bugzilla/show_bug.cgi?id=13320
Feb 28 10:09:20 <bluelightning> morning all
Feb 28 10:24:24 <Zagor> heh. the bitbake-diffsigs outout "Task dependencies changed from <9717-character line> to <10127-character line>" could probably be made more helpful
Feb 28 10:26:05 <Zagor> I have to cut, paste, split, sort & diff to see what actually differs
Feb 28 10:29:05 <bluelightning> indeed, the utility could fairly easily do that itself
Feb 28 10:42:10 <JaMa> weird I see it with line breaks IIRC and also "Task dependency added: something" maybe this is from different "if"
Feb 28 10:43:16 <Zagor> JaMa: http://pastebin.com/4Gu49eMn
Feb 28 10:45:18 <JaMa> and "Dependency on Variable .* was removed" is what you get if you cut, paste, split, sort & diff it?
Feb 28 10:45:45 <JaMa> or is this with some new patch from you?
Feb 28 10:47:11 <Zagor> no this is from my adventures in trying to find out why the same poky branch built in two places doesn't produce the same sstate-cache hashes
Feb 28 10:47:22 <Zagor> s/branch/checkout/
Feb 28 10:48:02 <Zagor> the difference is a number of *_eglibc-utils lines that exist in one but not the other
Feb 28 10:48:39 <JaMa> but this and that's what's shown clearly in your pastebin after "Task dependencies changed from <9717-character line> to <10127-character line>"
Feb 28 10:48:52 <JaMa> so IMHO it does what it should
Feb 28 10:49:17 <Zagor> perhaps, but it's not very useful for a human
Feb 28 10:49:36 <Zagor> it's near-impossible to see what changed
Feb 28 10:50:43 <JaMa> next line shows that ${PN}-utils was added to PACKAGE variable
Feb 28 10:50:56 <JaMa> to that's probably difference between your two checkouts
Feb 28 10:53:01 <Zagor> again, it doesn't say that explicitly. it says "variable X was changed from "this long list" to "this long list".
Feb 28 10:54:08 <Zagor> anyway, one of the runs was a full distro build, the other was "bitbake eglibc" to minimize the waiting. I didn't think it would cause different build results.
Feb 28 10:55:25 <JaMa> and it looks like you have older bitbake without http://git.openembedded.org/bitbake/commit/?id=ca52bf32b479811bd7fed41648bedcc06b00430b
Feb 28 10:55:47 <Zagor> yes, this is poky from nov23
Feb 28 10:55:51 <Zagor> I mean edison
Feb 28 10:56:21 <Zagor> except the diffsigs program, which I run from master
Feb 28 10:56:30 <JaMa> there were a lot of fixes wrt sstate this weekend
Feb 28 10:57:03 <Zagor> that does indeed look like an interesting commit
Feb 28 11:15:24 <johnt> hello all - does anyone know what might cause "ERROR: Nothing RPROVIDES '"gdb"' "?
Feb 28 11:15:39 <johnt> when "bitbake gdb" works fine...
Feb 28 11:16:16 <bluelightning> johnt: looks like an extra set of quotes there? is that correct?
Feb 28 11:16:36 <johnt> sorry - that was just me adding them in
Feb 28 11:17:34 <johnt> i suppose a better way to word the question would be - why does "bitbake core-image-blah" fail to find gdb when "bitbake gdb" works fine...?
Feb 28 11:18:53 <bluelightning> johnt: it's complaining about a missing RPROVIDES
Feb 28 11:19:06 <bluelightning> i.e. a runtime dependency as opposed to build time
Feb 28 11:19:18 <bluelightning> so something is expecting a package called "gdb" and nothing provides that
Feb 28 11:19:32 <bluelightning> did you make any edits or is this a pristine clone?
Feb 28 11:20:10 <johnt> im sure there are a few edits at this point....
Feb 28 11:20:44 <bluelightning> well, "git diff" will show any changes
Feb 28 11:21:15 <bluelightning> I'd recommend that any customisations that you don't intend sending upstream be done as a separate layer
Feb 28 11:22:18 <johnt> yeah, i have a separate layer for changes. my understanding of how this system works isnt the best and its a bit of a steep learning curve..
Feb 28 11:23:02 <johnt> im getting the same error for valgrind - where should these RPROVIDES be defined?
Feb 28 11:23:17 <bluelightning> something is wrong
Feb 28 11:23:26 <bluelightning> there should definitely be a valgrind package
Feb 28 11:23:32 <johnt> oh there is
Feb 28 11:23:43 <johnt> and i can "bigbake valgrind" without a problem
Feb 28 11:23:56 <johnt> bitbake*
Feb 28 11:24:36 <bluelightning> right, target you specify to bitbake is a build time target though, so it's worth noting that it works but it's not a determining factor in whether an actual runtime provider of "valgrind" can be found
Feb 28 11:26:00 <johnt> ah ok
Feb 28 11:26:22 <bluelightning> I am a bit puzzled though
Feb 28 11:27:45 <johnt> so - i have valgrind and gdb included with IMAGE_INSTALL += "gdb" / "valgrind" in my core-image-[blah].bb - is this the correct way to include packages?
Feb 28 11:30:57 <johnt> bluelightning: what do you think?
Feb 28 11:32:02 <bluelightning> johnt: what does the slash indicate? you have two lines?
Feb 28 11:32:37 <johnt> yeah - the / was just for irc - its in two seperate lines
Feb 28 11:32:48 <bluelightning> ok, that is correct syntax and should work
Feb 28 11:33:36 <johnt> so - where does it go looking for an RPROVIDES to satisfy these?
Feb 28 11:34:09 <bluelightning> a recipe PROVIDES everything in its PACKAGES
Feb 28 11:34:24 <bluelightning> er, I mean  a recipe RPROVIDES everything in its PACKAGES
Feb 28 11:36:15 <bluelightning> so, as a proof I just added IMAGE_INSTALL += "gdb valgrind" to my core-image-minimal recipe and it's doing a dry-run with no issues
Feb 28 11:37:38 <bluelightning> johnt: which release are you using btw?
Feb 28 11:38:21 <johnt> oh, er... does 1.1 sound correct?
Feb 28 11:38:36 <bluelightning> right, yes, that's what I was after
Feb 28 11:41:17 <bluelightning> yep, just did the same thing with the 1.1 release, also worked
Feb 28 11:41:58 <bluelightning> so something else is going wrong... can you tell me about any other changes you might have made?
Feb 28 11:42:56 <johnt> i dont think so - there are a good few and most of them were made before i inherited this repo...
Feb 28 11:43:34 <johnt> strange - gdb seems to be working now even though it wasnt a second ago and i havnt changed anything....
Feb 28 11:48:57 <bluelightning> ??
Feb 28 11:49:52 <bluelightning> that's certainly not behaviour I would expect nor have observed...
Feb 28 13:45:00 <johnt> bluelightning: still there?
Feb 28 13:58:27 <bluelightning> johnt: yep
Feb 28 13:59:09 <bluelightning> there is definitely a gdbserver package btw
Feb 28 14:02:59 <johnt> oh, ok
Feb 28 14:03:03 <otavio> sgw: your syslinux change 868a81e869a6193aada2073ae533d937a1c0baf4 has missed a PR bump and this broke my autobuilder :-(
Feb 28 14:03:25 <otavio> sgw: is it possible for you to bump PR of it?
Feb 28 14:03:32 <johnt> bluelightning: should there be a gdbserver,bb somewhere for that?
Feb 28 14:03:52 <bluelightning> johnt: no, it's a part of the gdb recipe
Feb 28 14:04:12 <bluelightning> johnt: in recipes-devtools/gdb/gdb.inc you can see it gets added to PACKAGES
Feb 28 14:04:14 <johnt> bluelightning: so should i be able to "bitbake gdbserver"?
Feb 28 14:04:35 <bluelightning> johnt: no, when you "bitbake gdb" it's one of the packages that gets produced
Feb 28 14:05:01 <bluelightning> but you should be able to add gdbserver to IMAGE_INSTALL, if you cannot you have some other issue
Feb 28 14:05:23 <johnt> bluelightning: ok cool - ill try that now!
Feb 28 14:05:32 <bluelightning> I wonder if this has something to do with x11 not being in DISTRO_FEATURES?
Feb 28 14:06:17 <johnt> im not sure - not having X11 seems to be causing all sorts of problems, using uclibc seems to cause yet more problems...
Feb 28 14:06:51 <bluelightning> well removing x11 from DISTRO_FEATURES was not well-tested... we have fixed a few issues with that in master
Feb 28 14:07:29 <bluelightning> I'm about to check to see how it behaves here
Feb 28 14:07:34 <bluelightning> (with 1.1)
Feb 28 14:19:45 <otavio> sgw: RP__ I just sent the change to bump PR to syslinux; if you can, please commit it so our autobuilder takes it :-)
Feb 28 14:25:03 <johnt> bluelightning: gdbserver has suddenly started working again, cant figure out why :S
Feb 28 14:26:22 <bluelightning> johnt: I don't mean to be difficult but generally things don't just suddenly start working, there must have been some kind of change in between
Feb 28 14:28:07 <bluelightning> I'd love to help diagnose what's happening but right now I'm not operating with much information about your setup
Feb 28 14:31:29 <johnt> bluelightning: no problem - thank you for your help so far, its greatly appreciated.
Feb 28 14:32:20 <johnt> i cleared out my build directory and started from scratch which seems to help a lot when something breaks
Feb 28 14:43:31 <bluelightning> just verified, adding gdbserver to core-image-minimal without x11 in DISTRO_FEATURES works in 1.1
Feb 28 15:04:18 <otavio> RP__: I just sent a fix to licenses.conf fixing a quote error
Feb 28 15:41:23 <Zagor> this is odd. after everything is installed from my sstate mirror, gcc, module-init-tools, dtc and u-boot sources are fetched and unpacked, but never configured or compiled!
Feb 28 15:44:10 <Zagor> http://pastebin.com/sXpKjL5y
Feb 28 16:05:00 <michael_e_brown> is there any way to tell bitbake to *not* cache a git repository? especially if said git repository is a file:// url (local).
Feb 28 16:05:38 <michael_e_brown> I've read through Git.py, but don't see anything relevant, and I'm hoping I missed something.
Feb 28 16:30:44 <RP__> michael_e_brown: You might be better off with externalsrc.bbclass if that is what you really wan
Feb 28 16:30:45 <RP__> want
Feb 28 16:34:51 <michael_e_brown> thanks, let me take a look
Feb 28 16:35:52 <michael_e_brown> RP__, which version is that in? I'm in edison and don't see it.
Feb 28 16:36:25 <RP__> michael_e_brown: look for a patch on the mailing list. Its not merged anywhere yet
Feb 28 16:37:18 <JaMa> RP__: any idea about that PACKAGECONFIG issue? I can try to fix it if you confirm that's issue not feature and maybe hint about how would you like to see it fixed
Feb 28 16:38:24 <RP__> JaMa: The -native one? Its a bug. I think we might have to teach PKGCONFIG about the class extentions
Feb 28 16:39:06 <JaMa> so move that logic from handler to some function and call it on PKGCONFIG deps too, right?
Feb 28 17:02:21 <khem> JaMa: it solves a different problem.
Feb 28 17:05:07 <JaMa> khem: ok, and what about this http://repo.or.cz/w/binutils.git/commit/6b261118d38d8c4cc19c52892708f81b7ce65b0c ? interestingly may_use_v4t_interworking is used only once there..
Feb 28 17:13:35 <khem> JaMa: that was the patch I was trying to suggest other day but its already part of 2.22 gold we have
Feb 28 17:14:16 <JaMa> I
Feb 28 17:17:09 <JaMa> I was grepping sources unpacked by bitbake and haven't seen it there, now I do.. weird.. sorry for noise
Feb 28 18:07:12 <otavio> Ok
Feb 28 18:07:23 <otavio> I found two issues in bitbake ...
Feb 28 18:07:24 <otavio>    >            self.rqexe.finish_now()
Feb 28 18:07:24 <otavio>              else:
Feb 28 18:07:24 <otavio> AttributeError: RunQueue instance has no attribute 'rqexe'
Feb 28 18:07:38 <otavio>   File "/home/otavio/hacking/ossystems/embedded-linux/bitbake/lib/bb/runqueue.py", line 1000, in RunQueue.finish_runqueue(now=True):
Feb 28 18:08:47 <bluelightning> when does that happen?
Feb 28 18:09:22 <otavio>  bluelightning Ctrl+C
Feb 28 18:10:38 <otavio> bluelightning: and the quotting fixed in https://github.com/OSSystems/meta-chicken/commit/f67fb8611a994e5f3ccc6872afaa95df8e6f10b9 did not raise a parsing error even thought they were not used and broken the chicken build; fixing quotting fixed the building
Feb 28 18:11:13 <bluelightning> otavio: ah yes you're right, multiple ctrl+c does trip that
Feb 28 18:11:49 <bluelightning> otavio: would you mind filing bugs for both of those?
Feb 28 18:12:20 <otavio> bluelightning: at this moment, i do ... i am trying to fix autobuilder after last changes and i am having a hard time with them
Feb 28 18:13:08 <bluelightning> that's unfortunately the price of staying on the bleeding edge...
Feb 28 18:13:40 <bluelightning> I can file a bug for the ctrl+c issue
Feb 28 18:18:47 <bluelightning> argh now I can't reproduce it :/
Feb 28 18:21:51 <bluelightning> nope, just tried about 10 times, can't make it crash like the first time
Feb 28 18:21:59 <kergoth> that shouldn't be happening -- the server uses signal() to block SIGINT. I suspect its a timing thing -- that signal handling change might not be happening early enough in the server initialization
Feb 28 18:22:06 <JaMa>  also see it only sometimes
Feb 28 18:22:11 <kergoth> it's the UI that should be getting SIGINT, not the server
Feb 28 18:22:23 <bluelightning> kergoth: this is way past server initialisation though
Feb 28 18:22:30 <JaMa> but sometimes it refuses to die completely on ^C and calling killall bitbake from 2nd shell is faster
Feb 28 18:23:21 <JaMa> iirc git status from buildhistory doesn't die on ^C in bitbake
Feb 28 18:24:18 <bluelightning> hmm, we should probably try to fix that
Feb 28 18:27:39 <kergoth> is this poky? i know the Process server blocks interruption, but I know nothing about the xml/rpc server
Feb 28 18:29:40 * JaMa has it with bitbake master
Feb 28 18:29:50 <otavio> bluelightning: sure; i just wanted to let you guys know the issue ...
Feb 28 18:29:56 <otavio> kergoth: bitbake's tip
Feb 28 18:30:19 <otavio> bluelightning: but the parsing error is much worse imo as it is quite difficult to gasp
Feb 28 18:30:29 <otavio> bluelightning: it just ignored the export completely
Feb 28 18:47:01 * bluelightning -> home
Feb 28 18:57:25 <msm1> anyone know how to get (multilib) libgcc installed on the rootfs?
Feb 28 18:57:33 <msm1> im having a package renaming issue
Feb 28 18:58:08 <msm1> i can't just IMAGE_INSTALL_append = " lib64-libgcc" because the actual package names are libgcc-s and libgcc-s1
Feb 28 18:58:18 <msm1> i can install them just fine
Feb 28 18:58:27 <msm1> the package renaming isn't getting hit for this case
Feb 28 19:12:24 <kergoth> iirc there's a MULTILIB_IMAGE_INSTALL or somesuch? *shrug*
Feb 28 19:13:10 <msm1> kergoth: yep, ive got normal packages installing just fine
Feb 28 19:13:20 <msm1> kergoth: lib64-gcc lib64-binutils
Feb 28 19:13:24 <msm1> its just the package renaming
Feb 28 19:14:47 <kergoth> ah
Feb 28 19:29:41 <khem> these quotin fixes are nagging
Feb 28 19:31:46 <JaMa> it's not so bad and definetly worth it as they help to find few bugs too
Feb 28 19:32:11 <khem> yeah
Feb 28 19:32:37 <khem> an automation could have helped
Feb 28 19:33:59 <JaMa> I haven't liked to reparse all 20 times.. but I think now it's only some other layers and in smaller amounts
Feb 28 19:34:32 <JaMa> and for new recipes it's easy to fix them before sending patch so it shouldn't repeat again now with that patch in for everybody
Feb 28 19:34:34 <khem> Do u have meta-ti in your project ?
Feb 28 19:34:45 <JaMa> no
Feb 28 19:35:06 <khem> well then you are lucky that its only 20 times
Feb 28 19:38:50 <JaMa> actually it was more like 80 times if I sum up oe-core/meta-oe/meta-smartphone layers :)
Feb 28 20:03:58 <khem> it takes 10+ mins to parse angstrom on my box. We are back to where oe.dev use to be :)
Feb 28 20:05:50 * zeddii just suffered through his own quoting-fest
Feb 28 20:06:55 <kergoth> khem: yikes
Feb 28 20:16:38 <kergoth> I wonder how esben's PLY-based parser performs
Feb 28 20:45:54 <kergoth> RP__: is there a simple mechanism to disable shared state usage for a particular recipe, or do I need to hijack/remove the task(s)?
Feb 28 20:46:05 <kergoth> In particular I'm thinking about the external toolchain recipes
Feb 28 20:46:14 <kergoth> not really gaining us much
Feb 28 20:46:16 <kergoth> hm
Feb 28 21:09:42 <kergoth> I don't think I've ever actually seen bitbake -S work
Feb 28 21:09:47 <kergoth> always with the basehash mismatch crap
Feb 28 21:15:51 <kergoth> So, locally, I'm adding the build machine distro/version (using lsb_release) to the native/cross signatures, to resolve issues where a native binary is built on a newer system and therefore won't run on an older one. any opposition to something like that going upstream into yocto?
Feb 28 21:17:53 <kergoth> it's in a separate .inc, so wouldn't impact any distros that don't opt-in
Feb 28 21:19:25 <msm> hollisb: well, it's a starting point
Feb 28 21:19:33 <msm> hollisb: did you bump the PR on the image recipe?
Feb 28 21:21:57 <hollisb> not the image recipe; the task recipe
Feb 28 21:23:07 <hollisb> msm: interestingly, IMAGE_INSTALL_append caused the package to be built this time, but still not included in the rootfs
Feb 28 21:29:44 <msm> look at the RPMs created
Feb 28 21:29:55 <msm> rpm -qlp tmp/deploy/rpms/$ARCH
Feb 28 21:30:07 <msm> and see if the pkg pkg-dev pkg-dbg contains what you want
Feb 28 21:30:14 <msm> you may be looking for a different package
Feb 28 21:30:25 <msm> a recipe can create multiple packages fyi
Feb 28 21:33:10 <autif> is unionfs supported by the kernel? It seems like it is a separate module. Is there already a recipe for it?
Feb 28 21:33:30 <msm> hollisb: ^
Feb 28 21:37:22 <khem> IMAGE_INSTALL should have staged it and also added it to your image if you did IMAGE_INSTALL_append-pn-<your_image_name> = " <package_name>"
Feb 28 21:38:57 <khem> hmm IMAGE_INSTALL_append_pn-<imagename>
Feb 28 21:39:57 <hollisb> khem: well, I didn't do that, but again that's just a local hack. my real problem is that http://pastie.org/3483112 didn't do what I expected
Feb 28 21:40:08 <hollisb> khem: any ideas about that?
Feb 28 21:43:24 <khem> is usbinit a module ?
Feb 28 21:44:37 <hollisb> no, it's a package
Feb 28 21:44:57 <hollisb> khem: meta/recipes-bsp/usbinit
Feb 28 21:46:29 <khem> ok and you added it to RRECOMMENDS of task-base
Feb 28 21:46:38 <khem> what happens if you add it to RDEPENDS ?
Feb 28 21:49:56 <hollisb> ahh, let's find out
Feb 28 21:52:31 <hollisb> khem: no joy (and yes I incremented task-base.bb PR). would I need to explicitly clean core-image-minimal?
Feb 28 21:52:38 <ant__> sgw: heh, I could not reproduce the libtool build error
Feb 28 21:53:22 <ant__> though, this time help2man was correctly found
Feb 28 21:55:18 <ant__> sgw: sorry, I was looking at libtool-native. The help2man warning is still there, nothing changed then
Feb 28 21:58:11 <msm> hollisb: did you look at the individual packages created by usbinit?
Feb 28 22:00:43 <hollisb> msm: adding to RDEPENDS_task-base or RRECOMMENDS_task-base doesn't build any usbinit packages at all
Feb 28 22:01:11 <msm> does the usbinit have a proper make install step?
Feb 28 22:01:23 <msm> can you look at the sysroot for that particular package?
Feb 28 22:02:13 <hollisb> msm: meta/recipes-bsp/usbinit/usbinit.bb does have a do_install() step
Feb 28 22:03:04 <hollisb> msm: the package is not being built, so  what would create a sysroot?
Feb 28 22:03:47 <msm> there is no tmp/work/${ARCH}/usbinit/ ?
Feb 28 22:04:42 <hollisb> msm: nope
Feb 28 22:05:09 <hollisb> msm: (this is with the task-base.bb patch, not IMAGE_INSTALL*)
Feb 28 22:06:08 <msm> hollisb: is usbinit under bitbake -s output?
Feb 28 22:06:18 <msm> also, is there a COMPATIBLE_MACHINE bit on that recipe?
Feb 28 22:07:47 <hollisb> bitbake -s does list usbinit
Feb 28 22:08:21 <hollisb> COMPATIBLE_MACHINE is not mentioned in the recipe, but it's used indirectly in task-base.bb
Feb 28 22:09:25 <hollisb> bitbake -e says: COMBINED_FEATURES="alsa       usbgadget usbhost"
Feb 28 22:10:46 <hollisb> and I'm adding to RDEPENDS_task-base-usbgadget in task-base.bb
Feb 28 22:11:14 <hollisb> well, you saw the diff -- I changed from RRECOMMENDS to RDEPENDS, without apparent effect
Feb 28 22:11:33 <khem> well usbinit is a common recipe for all arches
Feb 28 22:11:51 <khem> so putting it under something COMPATIBLE_MACHINE might be wrong thing
Feb 28 22:12:27 <hollisb> khem: I don't see any COMPATIBLE_MACHINE around (I misspoke earlier -- I was actually looking at COMPATIBLE_FEATURES)
Feb 28 22:12:52 <hollisb> khem: so if I want usbinit to be included whenever usbgadget is present/enabled, isn't this how I should do it?
Feb 28 22:12:52 <khem> ok bitbake -g <yourimage>
Feb 28 22:13:02 <khem> and then inspect the resulting .dot files
Feb 28 22:13:18 <khem> do they list usbinit.bb in dep order
Feb 28 22:13:24 <hollisb> ok
Feb 28 22:13:50 <hollisb> khem: usbinit does not appear in task-depends.dot
Feb 28 22:14:13 <khem> look in pn-depends
Feb 28 22:15:16 <hollisb> khem: usbinit does not appear in *.dot
Feb 28 22:16:21 <hollisb> (using RRECOMMENDS)
Feb 28 22:18:23 <msm> hollisb: are any of the other usbgadget packages getting built?
Feb 28 22:19:56 <hollisb> msm: doesn't look like it
Feb 28 22:20:13 <hollisb> hmmm, I have a tmp/work/all-poky-linux/usbinit-1.0-r2 now
Feb 28 22:20:32 <hollisb> oh, just contains run.sstate_cleanall.16254
Feb 28 22:20:40 <hollisb> from an explicit -c clean earlier, I guess
Feb 28 22:22:14 <msm> hollisb: ya, i wonder if task-base is getting cached
Feb 28 22:22:52 <msm> try bitbake -c cleanall task-base
Feb 28 22:23:10 <msm> i never liked tasks myslf
Feb 28 22:23:17 <msm> i just make an image and modify IMAGE_INSTALL
Feb 28 22:23:20 <hollisb> :)
Feb 28 22:23:28 <hollisb> cleanall, never heard of that one. I'll give it a shot
Feb 28 22:23:31 <msm> since if I want something, the DEPENDS should be correct and I can get what I need
Feb 28 22:23:33 <khem> well they are really not tasks they are actually featuresets
Feb 28 22:23:37 <otavio> is just me or bitbake has been completely broken?
Feb 28 22:23:54 <mranostay> otavio: it is you
Feb 28 22:24:00 <otavio> hhehh
Feb 28 22:24:03 <khem> otavio: since I dont know anything is broken in bitbake
Feb 28 22:24:18 <otavio> You guys are using current tip?
Feb 28 22:24:29 <otavio> it seems exporting of vars in recipes are broken
Feb 28 22:24:38 <otavio> if not properly quoted
Feb 28 22:24:52 <mranostay> quote your VARS!!
Feb 28 22:25:07 <otavio> mranostay: yes but it doesn't raise a parse error
Feb 28 22:25:14 <otavio> mranostay: that's the problem
Feb 28 22:25:19 <otavio> mranostay: it just go ahead
Feb 28 22:25:23 * ant__ is quoting opie one by one just to finish a build...
Feb 28 22:25:26 <otavio> mranostay: non shell exports, works
Feb 28 22:25:36 <hollisb> khem: could this be related to building core-image-*minimal*? AFAICS, -minimal should still respect task-base-usbgadget, but...
Feb 28 22:25:39 <khem> ant__: care to check  patchwork ?
Feb 28 22:25:43 <otavio> ant__: but i mean shell export
Feb 28 22:25:53 <khem> ant__: I posted patches for quoting issue to different layers
Feb 28 22:26:13 <khem> hollisb: is taks-base appearing in dot files ?
Feb 28 22:27:30 * mranostay waves to hollisb 
Feb 28 22:28:06 <hollisb> khem: it is not
Feb 28 22:28:09 <hollisb> mranostay: hey! :)
Feb 28 22:29:12 <mranostay> hollisb: can't escape you guys i noticed :)
Feb 28 22:30:08 <khem> hollisb: so you have been barking up the wrong tree
Feb 28 22:30:18 <msm> are you sure task-base is getting pulled into core-image-min?
Feb 28 22:31:02 <hollisb> well that's what I asked a while ago :)
Feb 28 22:31:16 <msm> it says its the DEFAULT_TASK_PROVIDER
Feb 28 22:31:17 <khem> lets start over
Feb 28 22:31:21 <khem> whats your image ?
Feb 28 22:31:26 <hollisb> core-image-minimal
Feb 28 22:31:27 <msm> whatever that means
Feb 28 22:31:36 <khem> ok. core-image-minimal
Feb 28 22:31:49 <khem> now you want what to go in there in addition to what it has ?
Feb 28 22:32:19 <hollisb> I want the usbinit package, when the usbgadget feature is present
Feb 28 22:32:57 <khem> ok and usbgadget is a MACHINE_FEATURE
Feb 28 22:33:02 <hollisb> yup
Feb 28 22:33:44 <otavio> you might use a bbappend to task-base for it, in your layer
Feb 28 22:34:12 <hollisb> otavio: I think this change should be present in the stock layers
Feb 28 22:34:29 <hollisb> and would like to send a patch, after I get it working ...
Feb 28 22:34:34 <ant__> zeddii: ping
Feb 28 22:36:55 <hollisb> khem: so meta/recipes-core/images/core-image-minimal.bb inherits core-image
Feb 28 22:37:18 <hollisb> and meta/classes/core-image.bbclass contains this: CORE_IMAGE_BASE_INSTALL = "[...] task-base-extended [...]"
Feb 28 22:38:04 <hollisb> should that be enough to pull in meta/recipes-core/tasks/task-base.bb and RRECOMMENDS_task-base-usbgadget ?
Feb 28 22:39:16 <khem> yes adding it to RRECOMMENDS_task-base-usbgadget in task-base.bb should be ok
Feb 28 22:40:41 <hollisb> khem: ok, then I still don't know what I'm doing wrong :)
Feb 28 22:41:04 <khem> ok and thats what you did right ?
Feb 28 22:41:20 <hollisb> khem: yes: http://pastie.org/3483112
Feb 28 22:41:30 <khem> now do bitbake -g core-image-minimal and paste those .dot files for me please
Feb 28 22:42:00 <khem> and also your local.conf
Feb 28 22:42:28 <khem> heh I want to read https://lwn.net/Articles/483921/
Feb 28 22:43:03 <khem> we had been trying to preserve / and most seem to move to /usr
Feb 28 22:43:38 <hollisb> khem: not an LWN subscriber?
Feb 28 22:44:05 <khem> hollisb: no, I am not
Feb 28 22:44:22 <otavio> khem: just sent to your mail a pdf
Feb 28 22:44:28 <otavio> khem: ;-)
Feb 28 22:44:37 <khem> k thx
Feb 28 22:44:39 <hollisb> they have web links too: http://lwn.net/SubscriberLink/483921/b6cd4e86041e402d/
Feb 28 22:45:34 <hollisb> khem: I'm not sure how to send you the .dot files. copy/paste into a pastebin?
Feb 28 22:46:12 <hollisb> ah I can just email
Feb 28 22:49:53 <msm> pastebin is better
Feb 28 22:50:02 <msm> but either way =)
Feb 28 22:50:16 <ant__> khem: I've liked 'the epic gentoo-dev thread on the topic'
Feb 28 22:52:04 <khem> yeah sending huge mails to inbox is kind of bad :)
Feb 28 22:52:27 <khem> hollisb: anyway I see that task-base is ignored in your dep tree
Feb 28 22:52:40 <khem> only task-core-boot is honoured
Feb 28 22:52:44 <khem> lets see
Feb 28 22:52:58 <hollisb> CORE_IMAGE_BASE_INSTALL = '\
Feb 28 22:52:58 <hollisb>     task-core-boot \
Feb 28 22:52:58 <hollisb>     task-base-extended \
Feb 28 22:53:01 <hollisb> in meta/classes/core-image.bbclass
Feb 28 22:53:42 <khem> ok so what happened to task-base-extended ?
Feb 28 22:54:20 <khem> hmm
Feb 28 22:54:44 <khem> lsls
Feb 28 22:56:08 <msm> ls!
Feb 28 22:57:01 <khem> slow connections :)
Feb 28 22:57:23 <khem> interesting task-base never gets pulled in
Feb 28 22:58:25 <khem> hollisb: ok so if you try bitbake task-base does it include your desired package ?
Feb 28 22:59:38 <hollisb> trying
Feb 28 23:00:55 <hollisb> khem: yes, I see a bunch of usbinit success messages (do_package_write_ipk_setscene: Succeeded, do_package_setscene: Succeeded, etc)
Feb 28 23:01:02 <khem> ok
Feb 28 23:01:08 <khem> so what you did is right !
Feb 28 23:01:18 <hollisb> don't know how that happened ;)
Feb 28 23:01:21 <khem> somewhere the upper deps are getting borked
Feb 28 23:01:48 <khem> ok now try bitbake -g task-base-extended
Feb 28 23:02:00 <khem> and see if task-base appears to be in depchain
Feb 28 23:04:08 <hollisb> ok
Feb 28 23:04:49 <hollisb> I will add that I'm using the meta-ti layer, along with BBMASK = ".*/meta-ti/recipes-misc/"
Feb 28 23:04:58 <khem> thats ok
Feb 28 23:05:46 <hollisb> after that bitbake -g task-base-extended, "task-base.do_package_write_ipk" does appear in task-depends.dot
Feb 28 23:06:02 <hollisb> and task-base.do_install, etc
Feb 28 23:07:53 <khem> ok
Feb 28 23:10:14 <khem> hollisb: ok you see IMAGE_INSTALL = "task-core-boot ${ROOTFS_PKGMANAGE_BOOTSTRAP} ${CORE_IMAGE_EXTRA_INSTALL}" in core-image-minimal.bb ?
Feb 28 23:10:27 <khem> which means the image you used is not right one for you
Feb 28 23:11:09 <hollisb> ok, I see it
Feb 28 23:11:27 <khem> core-image-minimal does not want task-base
Feb 28 23:11:37 <khem> its happy with task-core-boot
Feb 28 23:11:37 <hollisb> hmmmmm, I see
Feb 28 23:12:22 <khem> hollisb: you want core-image-base
Feb 28 23:12:30 <hollisb> well that was an anti-climactic ending
Feb 28 23:12:37 <khem> LOL
Feb 28 23:12:49 <hollisb> khem: I'll give it a shot. thanks very much
Feb 28 23:12:51 <khem> it will be nonimated for academy awards
Feb 28 23:13:00 <hollisb> :)
Feb 28 23:14:04 <hollisb> ahh, so core-image.bbclass ordinarily sets IMAGE_INSTALL, but in this case core-image-minimal.bb overrides it
Feb 28 23:14:06 <hollisb> I get it now
Feb 28 23:14:20 <khem> yes
Feb 28 23:14:32 <khem> since its minimal it wants to strip out defaults
Feb 28 23:14:47 <hollisb> well at least I learned something :)
Feb 28 23:14:50 <khem> so rule of thumb is use core-image-base for something normal
Feb 28 23:15:06 <khem> and if you prefer x11 a bit use core-image-core
Feb 28 23:15:19 <khem> and if you like WMs then go for core-image-sato
Feb 28 23:15:40 <khem> and I learned nothing but chased my own tail number of times
Feb 28 23:15:46 <hollisb> hehe sorry
Feb 28 23:16:05 <khem> nothing to be sorry about it. We created this system this way
Feb 28 23:39:08 <otavio> I am building from scratch with current bitbake and oe-core to be sure it works or not
Feb 28 23:39:12 <otavio> :)
**** ENDING LOGGING AT Wed Feb 29 02:59:58 2012

**** BEGIN LOGGING AT Wed Feb 29 02:59:58 2012
Feb 29 04:26:26 <mebrown> RP__, thanks for the externalsrc.bbclass pointer. Found lots of useful stuff that looks exactly like what I want.
Feb 29 04:54:02 <mebrown> question on bitbake debugging: I've made a couple mods to some bbclasses that I locally have, and now bitbake hangs forever with no debug output. How to debug? bitbake -DDD -vvv doesnt seem to show anything helpful
Feb 29 05:11:32 <kergoth> mebrown: what bitbake version?
Feb 29 05:11:46 <mebrown> edison, let me check
Feb 29 05:12:11 <mebrown> BitBake Build Tool Core version 1.13.3, bitbake version 1.13.3
Feb 29 05:12:33 <mebrown> I ended up commenting out stuff until it started barfing on itself instead of hanging
Feb 29 05:12:38 <mebrown> still would like a better way to do that
Feb 29 05:15:02 <mebrown> tried dropping in externalsrc.bbclass from here: http://patches.openembedded.org/patch/21919/  and it hangs when I add an inherit statement to pull it into my existing code.
Feb 29 05:23:14 <mebrown> ok, great... it's hanging again...
Feb 29 05:29:01 <kergoth> grab the latest bitbake, master branch, its git repository
Feb 29 05:29:13 <kergoth> the hang issues hsould be resolved there, as far as i know
Feb 29 05:31:00 <mebrown> stupid question: if I grab latest bitbake, what is the non-intrusive way to integrate it into my existing build? (ie. I currently run:  . ../yocto/oe-init-build-env .
Feb 29 05:31:33 <mebrown> or do I just move the current yocto/bitbake/ dir and make a symlink to the new one?
Feb 29 05:43:30 <fray> replace the bitbake dir.. but be aware the yocto bitbake has a few patches that are not yet in the upstream bitbake.  I don't believe these will cause any functional issues though...
Feb 29 06:01:32 <mebrown> thx
Feb 29 06:29:08 <mebrown> so, of course, it turns out that my code was throwing an exception at a moment that crashes bitbake without any diagnostics. I've now learned to wrap all my code with try/except and traceback.print_exc()
Feb 29 06:36:34 <bluelightning> mebrown: that shouldn't happen... is this with edison or master?
Feb 29 06:36:43 <mebrown> edison
Feb 29 06:37:04 <bluelightning> is it easy to reproduce? I'd like to try here
Feb 29 06:37:32 <mebrown> Let me see if I can quickly do a minimal test case... should be easy
Feb 29 06:40:07 <bluelightning> thanks
Feb 29 06:42:58 <mebrown> create crasher.bbclass containing:
Feb 29 06:42:59 <mebrown> python () {
Feb 29 06:42:59 <mebrown>     print "foo %s with %s" % ("bar",)
Feb 29 06:42:59 <mebrown> }
Feb 29 06:43:20 <mebrown> then inherit it somewhere and bitbake basically hangs with no diagnostics
Feb 29 06:44:29 <mebrown> bluelightning, --^
Feb 29 06:44:37 * bluelightning tries
Feb 29 06:47:09 <bluelightning> I guess I also need to inherit this class somewhere
Feb 29 06:47:44 <mebrown> yes
Feb 29 06:47:58 <mebrown> --> "then inherit it somewhere and bitbake basically hangs with no diagnostics"
Feb 29 06:48:42 <bluelightning> ah, sorry, mentally skipped that line...
Feb 29 06:49:03 <bluelightning> ok, in master you get a moderately sensible backtrace and it exits as you would expect
Feb 29 06:49:42 <mebrown> that's all I'm asking for, I'll keep master handy for future debugging. In edison, it took me literally hours of wasted time today to figure out what was going on.
Feb 29 06:49:55 <bluelightning> mebrown: sorry about that :(
Feb 29 06:49:59 <mebrown> From now on in edison, I'll just wrap everything in a try/except at the top level.
Feb 29 06:50:46 <bluelightning> mebrown: are you using the edison-6.0 release or the edison branch?
Feb 29 06:50:50 <mebrown> no worries! the rest of yocto/bitbake is awesome and has saved me oodles of time
Feb 29 06:50:55 <mebrown> 6.0 release
Feb 29 06:51:02 <bluelightning> ok
Feb 29 06:51:09 <mebrown> after I have something stable, I'll switch over to the branch
Feb 29 06:51:19 <mebrown> but for now, I need as few things changing as possible
Feb 29 06:51:30 <bluelightning> sure, of course
Feb 29 06:51:43 <mebrown> this is our first yocto implementation, replacing an aging homebrew system
Feb 29 06:51:44 <bluelightning> we try not to be another "just use bleeding edge" project :)
Feb 29 06:52:01 <mebrown> and that's the only way I'm able to sell it here. --^
Feb 29 06:52:15 <mebrown> so I commend you all
Feb 29 06:52:30 <bluelightning> it's possible we could backport the fix for the 1.1.2 release if it hasn't already hit in 1.1.1
Feb 29 06:52:41 <mebrown> ok. appreciated.
Feb 29 06:53:15 <mebrown> I'm just now getting nicely integrated externalsource.bbclass and some nice git versioning.
Feb 29 06:53:48 <mebrown> question: I'm trying my meta layer together with the android 'git-repo' tool. Is this something unique or interesting that others would like a writeup on?
Feb 29 06:54:07 <mebrown> each recipe directory has a git/ subdir where repo checks out that recipes source
Feb 29 06:54:11 <bluelightning> mebrown: sure, I know I'd be interested
Feb 29 06:54:19 <mebrown> then a hacked-up externalclass that redirects everything there
Feb 29 06:54:47 <mebrown> I'll get something written up and posted when I get this all stable.
Feb 29 06:54:58 <bluelightning> great stuff, will look forward to reading it :)
Feb 29 06:55:45 <mebrown> One thing I could use some help on, which is somewhat unrelated, but my next step:
Feb 29 06:55:57 <mebrown> I have some embargoed source that not everybody can check out
Feb 29 06:56:34 <mebrown> I'd like to build on my autobuilder and let devs that don't have access use pre-built IPKs, if possible, or something else that has only the headers/binaries
Feb 29 06:56:58 <mebrown> it seems to me like I need to hack up do_populate_sysroot, but I'm at a loss as to where to start
Feb 29 06:57:38 <mebrown> basically, the recipe will detect the git/ subdir and use it, if available, or use prebuilt stuff if it isnt there.
Feb 29 07:00:49 <bluelightning> mebrown: I would have thought the simplest way to handle that would be two separate recipes, and those who do have access to the embargoed version (which would have DEFAULT_PREFERENCE = "-1") would be able to select it with PREFERRED_VERSION_xx = "embargoed_version"
Feb 29 07:01:19 <bluelightning> obviously that's not automatic if that's what you need
Feb 29 07:01:20 <mebrown> that sounds reasonable. How do I set up the embargoed_version?
Feb 29 07:01:27 <mebrown> it is automatic enough, i think
Feb 29 07:02:26 <bluelightning> just take a copy of the recipe with a different "version" (filename portion after the _), set SRC_URI as appropriate, and add DEFAULT_PREFERENCE = "-1"
Feb 29 07:02:55 <bluelightning> you could even "require" the other recipe and then just add the above so as not to duplicate the content
Feb 29 07:03:16 <mebrown> Are you saying I have to manually set up another src_uri with only the headers and pre-built binaries?
Feb 29 07:04:18 <bluelightning> perhaps I misunderstand how you have these two versions available but are they not effectively different URLs already?
Feb 29 07:04:31 <mebrown> misunderstanding, let me clarify
Feb 29 07:05:28 <mebrown> lets say, for example, I have a git repo embargoed.git. This repo contains source I cannot release to one of the vendors that is helping on the project. But it does build to embargoed_1.0.sh4.ipk and embargoed-dev_1.0.sh4.ipk
Feb 29 07:05:40 <mebrown> and I can release those IPKs to the vendor (they have no source)
Feb 29 07:07:15 <mebrown> I need a way for the vendor who doesn't have access to embargoed.git to be able to do a full build.
Feb 29 07:10:38 <bluelightning> you mention headers, is this something that other things need to link to at build time?
Feb 29 07:10:57 <mebrown> yes
Feb 29 07:11:33 <bluelightning> hmm, I have to admit I've not had to deal with this specific situation before
Feb 29 07:11:44 <bluelightning> as you say populate_sysroot is the tricky piece
Feb 29 07:17:05 <bluelightning> mebrown: actually I think the simplest way to handle this will be to use a separate recipe; treat the ipks as archives which you can extract in do_unpack and then install in do_install
Feb 29 07:17:30 <mebrown> That seems promising. thanks
Feb 29 07:17:52 <bluelightning> is this a situation you expect to need to handle a lot?
Feb 29 07:18:12 <mebrown> I have about 5-10 packages like this
Feb 29 07:18:36 <bluelightning> could be that a class would be in order...
Feb 29 07:19:02 <mebrown> that was what I was thinking
Feb 29 07:19:20 <bluelightning> I wonder if others have had to deal with this as well
Feb 29 07:19:32 <bluelightning> although there's no guarantee they would be using ipk
Feb 29 07:19:35 <mebrown> I've asked a couple times on irc
Feb 29 07:19:54 <mebrown> I tried to use rpm at the beginning, but I ran into some problems with rpm
Feb 29 07:20:00 <mebrown> that switching to ipk fixed
Feb 29 07:20:25 <mebrown> no time to look into that further, but the 'embargoed' concept should be similar no matter what packaging system is in use
Feb 29 07:21:57 <mebrown> New question: is there any way to tell bitbake to force rebuild a specific package and all packages which depend on it?
Feb 29 07:23:10 <bluelightning> no; we do have something to handle that automatically but it's not really available in edison
Feb 29 07:23:27 <mebrown> ? only in newer?
Feb 29 07:23:53 <bluelightning> it relies upon us tracking recipe dependencies, and by that I mean every variable the recipe refers to
Feb 29 07:25:14 <bluelightning> the traditional model has been simple stamp files with a check on the version
Feb 29 07:25:54 <mebrown> I'm running into a situation where some things aren't being rebuilt when things they depend on change and failing
Feb 29 07:26:04 <bluelightning> in future it will be stamp files containing a hash based on variable values, and if that changes then the recipe gets rebuilt and the checksum affects recipes that depend on it, so they also get rebuilt
Feb 29 07:26:08 <bluelightning> yes
Feb 29 07:26:13 <mebrown> not sure if that's just me or if other devs will hit it too
Feb 29 07:26:28 <mebrown> what is the easiest way to get out of that situation (so I can document it)
Feb 29 07:26:29 <bluelightning> in the traditional system you are expected to bump PR on each of the dependents
Feb 29 07:26:51 <bluelightning> when you know that the ABI has changed
Feb 29 07:27:05 <mebrown> ok. I'm trying to implement automatic PR based on how many git commits there have been, so that may be taken care of in the next couple days
Feb 29 07:28:09 <mebrown> Ok, I'm trying to drop in richard purdie's externalsource.bbclass: http://comments.gmane.org/gmane.comp.handhelds.openembedded.core/16028
Feb 29 07:28:14 <mebrown> but I got this:
Feb 29 07:28:20 <mebrown>   File "__anon_56__home_michael_e_brown_build_dev_build_yocto_sh4____meta_drac_classes_externalsrc_bbclass", line 12, in __anon_56__home_michael_e_brown_build_dev_build_yocto_sh4____meta_drac_classes_externalsrc_bbclass
Feb 29 07:28:21 <mebrown> AttributeError: 'DataSmart' object has no attribute 'appendVarFlag'
Feb 29 07:28:48 <mebrown> is there a backwards-compatible way to implement that?
Feb 29 07:28:55 <mebrown> the line in question is:
Feb 29 07:28:57 <mebrown> d.appendVarFlag(task, "lockfiles", "${S}/singletask.lock")
Feb 29 07:32:17 <bluelightning> mebrown: that's really just an optimisation shortcut, you can just replace it with getVarFlag and setVarFlag
Feb 29 07:32:26 <mebrown> that's what I thought
Feb 29 07:32:39 <mebrown> I was looking at the code trying to see about fixing it
Feb 29 07:32:58 <mebrown> this stuff is deeper in to bitbake than I've needed to go thus far
Feb 29 09:40:31 <RP__> mebrown: either paste in the definition of appendVar from data_smart.py or just use a getVarFlag and setVarFlag
Feb 29 09:54:19 <mckoan> good morning
Feb 29 10:35:57 <Zagor> how do I find more info than "Hash for dependent task virtual:nativepseudo_1.2.bb.do_install changed from 29851d995fc3d09df8cfa7a6549e6a9e to 6d1f03c55fb07ddf4b968ef04dbcd44a"? I don't have .siginfo files for that virtual task to compare
Feb 29 10:46:01 <JaMa> Zagor: try bitbake -S pseudo-native and compare stamps dirs
Feb 29 10:47:47 <Zagor> what/where are stamps dirs?
Feb 29 10:47:59 <JaMa> TMPDIR
Feb 29 10:48:13 <Zagor> ah
Feb 29 10:48:27 <JaMa> read "[OE-core] Machine dependencies validation with sstate"
Feb 29 11:01:38 <Zagor> this is so weird. one build used sqlitenative 3.7.10, the other used 3.7.9. these are builds using the *same* unmodified poky directory.
Feb 29 11:02:59 <Zagor> sqlite 3.7.9 isn't even specified in the layers I'm including. only in the openembedded-core dir I have checked out.
Feb 29 11:03:55 <Zagor> is bitbake looking for recipes outside the layers I'm listing in bblayers.conf?
Feb 29 13:14:14 <RP__1> otavio: I found the export issue you mentioned
Feb 29 13:14:34 <RP__1> otavio: I've pushed a fix into bitbake so it will now raise parse errors over the invalid syntax
Feb 29 13:26:30 <Zagor> RP__: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=126f634207cd11f8e4b0324b90613b76193ca8d2 removed IMAGE_CMD_ext2.gz, which meta/classes/image_types_uboot.bbclass uses. i suppose it should be updated to the new generic solution?
Feb 29 13:29:12 <RP__> Zagor: I'd not realised that code was there. Yes, its going to need to be updated :/
Feb 29 13:39:38 <JaMa> RP__: ok, your patch for toolchain-scripts.bbclass looks better
Feb 29 13:46:15 <otavio> RP__: awesome and thanks :-)
Feb 29 13:49:28 <RP__> Zagor: Try something like http://pastebin.com/csDhr6FB
Feb 29 13:49:48 <Zagor> thanks, will do
Feb 29 14:04:05 <Zagor> RP__: hmm, with that I get "exception ValueError: 'ext2.gz.u-boot' is not in list".
Feb 29 14:04:45 <Zagor> should I just add ext2* entries to match?
Feb 29 14:06:45 <Zagor> my distro has IMAGE_FSTYPES = "ext2.gz.u-boot tar.gz"
Feb 29 15:12:43 <Zagor> can I somehow add "printf debugging" to a script, to display variables at runtime?
Feb 29 15:12:50 <Zagor> s/script/recipe/
Feb 29 15:20:03 <kergoth> bitbake -e recipename will dump all the variables for recipename
Feb 29 15:20:12 <kergoth> *extremely* helpful to make sure your assumptions match reality :)
Feb 29 15:24:05 <autif> I am trying to patch dropbear's init script - here are my bbappend and diff file. http://pastebin.com/bxZhEKJD - I get an error - can't find file to patch - I am guessing that the diff file does not have the right header. I am not sure what the right way to generate the patch it. Or does it mean that I *can not* patch a source file and need to overwrite it?
Feb 29 15:24:30 <autif> other parts of the recipe seem to work fine - just patching of init is busted
Feb 29 15:27:35 <kenws> autif: I'm not sure whether bitbake looks at the file extension but I had success whith using .patch
Feb 29 15:27:43 <Zagor> kergoth: thanks
Feb 29 15:28:45 <kergoth> np
Feb 29 15:28:47 <autif> kenws - somewhere I read that patch was "old way", diff is "new way". Cant recall where - will give it a try
Feb 29 15:29:33 <kergoth> Zagor: from python in the metadata you can also use bb.warn, bb.error, bb.note (though you won't see note to the console, just the logs), but of course that's only helpful in a python task, event handler, or anonymous python function, you can't just put it on a line in the metadata the way you can with $(warning) in make :)
Feb 29 15:29:36 <kergoth> hence, bitbake -e
Feb 29 15:29:51 <Zagor> right
Feb 29 15:30:14 <autif> kenws - same error
Feb 29 15:31:42 <kenws> autif: what's the error and where did you place the patch?
Feb 29 15:33:18 <Zagor> I get this parse error after applying RP__'s patch: http://pastebin.com/UKWcFSNA
Feb 29 15:33:54 <Zagor> I'm a bit confused about who/where is expanding do_rootfs and what list it he referring to
Feb 29 15:34:24 <autif> I am guessing it is a problem with the header in the diff file - I am not sure what it should look like - init file ends up in work/arch/dropbear-2011.54-r1, not in work/arch/dropbear-2011.54-r1/dropbear-2011.54 - where is where it is looking for init - I am not sure how init ended up in 1  instead of 2
Feb 29 15:35:07 <Zagor> *what list it is referring to
Feb 29 15:36:02 <kenws> Hm, I'm certainly not a bitbake expert but I'd guess as long as the diff applies using patch it should be fine.
Feb 29 15:36:05 <autif> both init and init.diff end up in the same directory - that must be good
Feb 29 15:37:25 <autif> yup - I copied the file manually to dropbear-2011.54-r1/dropbear-2011.54 and the patch applied fine - after a little tweak - have to change the header - a/init, b/init - style
Feb 29 15:37:57 <autif> what I am having problem with is that init is not in dropbear-2011.54-r1/dropbear-2011.54, it is in dropbear-2011.54-r1
Feb 29 15:41:46 <mranostay> so how would i go about building a module out of tree with a recipe?
Feb 29 15:42:27 <kergoth> inherit module. there are examples in the layers, grep for that
Feb 29 16:03:50 <kergoth> RP__: why does -S output .sigdata. and a normal build emits .siginfo, and to two different locations? the format is the same, giving them entirely different names and locations seems a bit odd.
Feb 29 16:09:08 <kergoth> I can see an argument for different locations, *maybe*, but the sigdata vs siginfo thing just seems like just needless inconsistency
Feb 29 16:10:31 <RP__> kergoth: There was some significance originally (maybe whether it was just the basehash or included the taskhash data too?)
Feb 29 16:10:45 <RP__> kergoth: I don't entirely remember though
Feb 29 16:11:47 <kergoth> that'd make a certain amount of sense, but i dont' think this naming implies anything of the sort :)
Feb 29 16:15:14 <kergoth> RP__: any objection to adding a bitbake-dumpsig or similar which just does a pickle.load() and pprint() on the loaded data?
Feb 29 16:15:24 <kergoth> not everyone will want to use an interactive python session to load and inspect their contents
Feb 29 16:18:36 <RP__> kergoth: you're seen bitbake-diffsigs?
Feb 29 16:18:50 <kergoth> yes, that's insufficient
Feb 29 16:19:02 <RP__> kergoth: we could add a symlink to that from bitbake-dumpsig
Feb 29 16:19:03 <kergoth> seeing the differences doesn't tell me *how* a variable got sucked in
Feb 29 16:19:12 <RP__> kergoth: that command can take a single file
Feb 29 16:19:36 <kergoth> thats an extremely odd and unintuitive behavior, given the name of the tool :P
Feb 29 16:20:37 <RP__> kergoth: like I said, lets add a symlink...
Feb 29 16:20:49 <RP__> kergoth: the functionality is there at least
Feb 29 16:21:28 <kergoth> i'd just split out a separate script, it's 5 lines of python at most. especially since we should avoid symlinks in git repositories due to filesystem limitations for portability reasons
Feb 29 16:21:47 <kergoth> but either way, i think we should do something
Feb 29 16:22:08 <kergoth> thanks, was wondering, didn't know about the diffsigs one arg functionality
Feb 29 16:23:12 <mranostay> kergoth: thanks
Feb 29 16:24:52 <kergoth> oh, i see, the one argument diffsigs option is prettier than pprint, so more than 5 lines :)
Feb 29 16:28:07 <RP__> kergoth: right :)
Feb 29 16:28:31 <RP__> kergoth: I think this got implemented when I as debugging things and then I forgot to make the command names match
Feb 29 16:28:47 <RP__> kergoth: Since then the command names don't really register with me...
Feb 29 16:29:04 <kergoth> if there isn't much code duplication, i'd split it out, otherwise we can make a small wrapper script to avoid the symlink
Feb 29 16:29:42 <RP__> kergoth: it is a trivial file basically bb.siggen.dump_sigfile(sys.argv[1])
Feb 29 16:29:56 <kergoth> ah
Feb 29 16:30:00 <kergoth> okay then
Feb 29 16:30:16 * kergoth adds to todo for another time
Feb 29 16:31:42 <kergoth> thanks again for the info
Feb 29 16:31:45 * kergoth dives back into sstate bits
Feb 29 16:32:02 <kergoth> RP__: oh, any objection to adding EXTERNAL_TOOLCHAIN to the basehash whitelist? the path is getting sucked into TOOLCHAIN_OPTIONS & friends
Feb 29 16:32:07 <kergoth> though, hmm
Feb 29 16:33:33 <kergoth> yeah, i think thats worth doing. the other thing we're doing that isn't yet upstream in this area is including the external toolchain version in the target recipe signatures via vardeps in CC or similar
Feb 29 16:34:12 <kergoth> ah, no, i added it to TOOLCHAIN_OPTIONS.. hmm, maybe thats how external toolchain is getting sucked in.. oops, maybe this is all due to that
Feb 29 16:34:25 <kergoth> feel free to ignore me for now, but i'll probably try to get these bits pushed at some point in the future :)
Feb 29 16:35:56 <kergoth> oh wait, no, EXTERNAL_TOOLCHAIN also gets sucked into TARGET_CPPFLAGS. so we do need to look into excluding that regardless :)
Feb 29 16:36:10 * kergoth wanders off for a walk and mutters
Feb 29 18:20:43 <RP__> kergoth: Its probably fine to add it
Feb 29 20:16:54 <mranostay> so is there a way to have a local git tree in the SRC_URI?
Feb 29 20:17:09 <mranostay> one that is one the local filesystem only
Feb 29 20:17:38 <kergoth> mranostay: you probably want to use the externalsrc class
Feb 29 20:17:43 <kergoth> but yes, you can, if you really want to
Feb 29 20:18:24 <mranostay> ew that looks ugly :)
Feb 29 20:18:42 <kergoth> externalsrc is nice because it builds directly in the local tree, no "unpacking" and all
Feb 29 20:18:44 <mranostay> probably better to just "share" it with http
Feb 29 21:05:14 <xumbi> I'm trying to port an older recipe to my layer, it has a postinst script which I put inside 'if [ x"$D" = "x" ]; then' so it won't run at image creation time, but it doesn't seem to run at boot
Feb 29 21:05:34 <xumbi> I do see /var/lib/opkg/info/<package>.postinst, and if I run it manually it works
Feb 29 21:05:47 <xumbi> but I can't figure out why it doesn't run at first boot
Feb 29 21:09:24 <ant__> zeddii: may I ask you smhg about linux-yocto-korg?
Feb 29 21:11:36 <ant__> I'm still figuring out the steps to move from classic korg/kernel.bbclass to linux yocto for unsupported machines
Feb 29 21:12:01 <zeddii> ant__: I have to head out shortly, but I can answer something quickly. either that or drop me an email and I can answer tonight.
Feb 29 21:12:07 <ant__> for now I'm customizing linux-yocto-tiny
Feb 29 21:12:19 <zeddii> FWIW. there's a pending patch to unbreak it at the moment.
Feb 29 21:12:38 <ant__> I can compile the kernel, np
Feb 29 21:12:59 <ant__> just I have to supply an empty machine.scc and add patches + defconfig to SRC_URI
Feb 29 21:13:23 <ant__> now, in the logs I see I would lack a mysterious yocto.scc .. ?
Feb 29 21:13:37 <ant__> whats' that for?
Feb 29 21:13:51 <zeddii> hmm. could be a bug. can you pastebin the log ?
Feb 29 21:14:13 <ant__> sure, later on, I'm rebuilding from scratch right now
Feb 29 21:14:40 <zeddii> ant__, I'm modifying that code right now. so if there's a bug, we can have a good turn around time :)
Feb 29 21:14:52 <ant__> what about the hybrid solution of -korg recipe? both kernel.bbclass and linux-yocto.inc ?
Feb 29 21:17:43 <zeddii> that should largely already be the case, all the linux-yocto recipes inherit it, and linux-yocto
Feb 29 21:19:16 <ant__> hm.. why was the initramfs cpio.gz not found then..hmm
Feb 29 21:19:23 <ant__> I'll tell you later on
Feb 29 21:19:41 <zeddii> I'll be back in about 5 hours. have some kids to go pickup right now!
Feb 29 21:21:16 <ant__> np, we'll get in touch tomorrow then
**** ENDING LOGGING AT Thu Mar 01 02:59:59 2012

**** BEGIN LOGGING AT Thu Mar 01 02:59:59 2012
Mar 01 05:23:11 <mebrown> hopefully this is a stupid question. I need to know the best way to "fix" the following (yes, I already know one way, looking to see if there is a better way):
Mar 01 05:23:27 <mebrown> |  * satisfy_dependencies_for: Cannot satisfy the following dependencies for redownloader:
Mar 01 05:23:27 <mebrown> |  * 	libuefilinux1 (>= 1.0+git1+5a63ed5b10d0f32665977fc9ec90c618a16ee8d0) *
Mar 01 05:23:27 <mebrown> |  * opkg_install_cmd: Cannot install package redownloader.
Mar 01 05:23:53 <mebrown> the reason for this is that I rebuilt libuefilinux1 as just 1.0 as part of some testing.
Mar 01 05:24:07 <mebrown> and I know that if I force rebuild redownloader, it will fix it
Mar 01 05:24:19 <mebrown> Is there any other/better way to fix this?
Mar 01 05:57:13 <khem> mebrown: http://sakrah.homelinux.org/blog/2011/06/downgrading-package-versions-in-openembedded/
Mar 01 05:57:55 <mebrown> crap
Mar 01 05:58:32 <mebrown> that doesn't look scriptable easily.
Mar 01 05:58:57 <mebrown> or easily explainable to <nice mode on>our wonderful development team</nice>
Mar 01 06:00:11 <mebrown> thanks for the link, khem.  looking closer, maybe scriptable.
Mar 01 06:00:40 <mebrown> Q: if I blow away tmp/ in this situation and rebuild, will the bad data be resurrected by sstate-cache?
Mar 01 06:01:33 <khem> thats my blog btw. :)
Mar 01 06:01:42 <mebrown> ah. cool.
Mar 01 06:01:53 <mebrown> q: is there a bigger hammer I can use?
Mar 01 06:02:34 <mebrown> something that doesn't make them suffer through a full rebuild for an hour and half, but forces rebuild?
Mar 01 06:03:36 <mebrown> I see two problems with the solution in the blog:  1) no easy way to "collect" the errors in a way easily parseable by a 'recovery script', and 2) possibly hard to tell from an IPK which recipe to clean and rebuild.
Mar 01 06:05:24 <khem> well you could use info under pkgdata to map packages to recipes
Mar 01 06:06:16 <mebrown> ok. let me poke. It's an issue I've run into several times while monkeying with versions, and I'm sure it will be something my devs will start hitting.
Mar 01 06:06:23 <khem> why is it not parsable ?
Mar 01 06:06:34 <khem> you ignore the lines staritng with Depends
Mar 01 06:06:47 <mebrown> No, the original error output
Mar 01 06:07:14 <khem> look for 1 line after satisfy_dependencies_for
Mar 01 06:07:57 <mebrown> ok, I'll take a stab
Mar 01 06:08:40 <khem> that said may be you want to enable BB_SIGNATURE_HANDLER = "OEBasicHash"
Mar 01 06:08:49 <mebrown> now that I know the actual root cause, it's making more sense
Mar 01 06:08:57 <khem> that should track the build deps better
Mar 01 06:09:19 <mebrown> where is that documented?
Mar 01 06:09:35 <khem> read oe-core mailing lists
Mar 01 06:09:37 <mebrown> all kinds of great info I find on irc that doesn't seem to be documented.
Mar 01 06:09:50 <khem> its called tribal knowledge
Mar 01 06:09:52 <khem> :)
Mar 01 06:09:56 <khem> become part of tribe
Mar 01 06:09:58 <mebrown> I could spend all day trying to keep up with oe-core mailing list, or I could get this product shipping
Mar 01 06:10:17 <mebrown> I'm trying, but I am incredibly stressed now
Mar 01 06:11:23 <mebrown> we are moving the Dell iDRAC build over to yocto from a bizarre homegrown system, and I've personally did about 99% of the work over the past two months. The rest of the dev team is expecting to start using the new yocto build starting in, oh, a week.
Mar 01 06:21:17 <khem> mebrown: good, hope you end up with good experience
Mar 01 06:21:26 <mebrown> so far, so good
Mar 01 08:18:05 <mckoan> good morning
Mar 01 08:34:34 <mebrown> dont remind me. :/
Mar 01 14:34:20 <Zagor> help! I get "Failure expanding variable do_rootfs, expression was [the image.bbclass do_rootfs function] which triggered exception ValueError: 'ext2.gz.u-boot' is not in list"
Mar 01 14:35:05 <Zagor> which list is this referring to? how do I see this?
Mar 01 15:13:56 <bluelightning> Zagor: is this in master?
Mar 01 15:14:03 <bluelightning> (sorry to keep asking)
Mar 01 15:15:31 <Zagor> bluelightning: master + http://pastebin.com/csDhr6FB
Mar 01 15:15:43 <Zagor> or, yesterdays master :)
Mar 01 15:16:25 <Zagor> RP__'s image_types rework didn't take uboot images into account, and I'm trying to fix that as a learning experience
Mar 01 15:16:42 <bluelightning> oh ok
Mar 01 15:16:47 <RP__> Zagor: I pushed some fixes for that
Mar 01 15:17:31 <RP__> Zagor: The problem is in get_imagecmds()
Mar 01 15:17:51 <RP__> Zagor: The line resulting in that list error was types[types.index(type)] = basetype
Mar 01 15:18:07 <RP__> Zagor: The error reporting sucks and we need to improve it
Mar 01 15:18:14 <Zagor> :)
Mar 01 15:18:48 <RP__> Zagor: I found several errors, you'll see a commit against image_types which addresses the various issues discovered
Mar 01 15:19:34 <Zagor> right, I'll look at the diffs. thanks.
Mar 01 15:20:52 <Zagor> is there a push feed of any kind that lets me follow changes?
Mar 01 15:21:05 <Zagor> other than reloading cgit :)
Mar 01 15:26:05 <bluelightning> Zagor: hmm, interesting question... we do have the oe-commits list: http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-commits
Mar 01 15:26:25 <bluelightning> that will catch oe-core + meta-oe
Mar 01 15:26:40 <bluelightning> as to a poky-specific one I don't think we have anything
Mar 01 15:27:27 <RP__> Zagor: I can't remember if we setup a commits list or not :/
Mar 01 15:27:45 <RP__> halstead: Do we have a commits list? If not, we might want to consider one...
Mar 01 15:29:13 <bluelightning> there's not one listed on lists.yoctoproject.org FWIW
Mar 01 16:02:37 <ignus> hello all - does anyone know if there is some Yocto/qemu documentation? i need to boot a disk image with qemu and cant use the yocto scripts...
Mar 01 16:04:14 <Zagor> ignus: here's a start: http://www.yoctoproject.org/documentation
Mar 01 16:04:29 <Zagor> or do you mean specifically qemu docs?
Mar 01 16:05:31 <Zagor> is this enough? http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#building-and-booting-the-default-qemu-kernel-image
Mar 01 16:07:21 <ignus> Zagor: the problem is that i cant use that runqemu script because it requires you to have root on the machine you are using and i dont have root on the build server (frustratingly)
Mar 01 16:11:16 <RP__> ignus: you only need root to setup the tap/tun devices
Mar 01 16:11:31 <RP__> ignus: If you pre setup the devices, it can run without root
Mar 01 16:12:47 <ignus> RP__: you require root to to the pre setup though, right?
Mar 01 16:13:52 <ignus> to do the*
Mar 01 16:18:46 <RP__> ignus: yes, but its a one off
Mar 01 16:25:24 <ignus> RP__: is there anyway to just disable that functionality?
Mar 01 16:25:49 <RP__> ignus: disable networking
Mar 01 16:26:01 <ignus> in the kernel config?
Mar 01 16:26:09 <RP__> ignus: qemu commandline
Mar 01 16:26:24 <ignus> hmm...
Mar 01 16:27:10 <RP__> ignus: The setup we use is by far the nicest way to network qemu. There are other ways, some of which don't need root but are suboptimal in other ways
Mar 01 16:29:05 <ignus> RP__: what does the setup involve?
Mar 01 16:29:10 <kergoth> types[types.index(type)] = basetype reeks of an iteration where you could have just used enumerate() -- that said having not looked at the surrounding code at all, just that line, though :)
Mar 01 16:30:54 <RP__> ignus: I don't have any more info off the top of my head I'm afraid
Mar 01 16:32:02 <ignus> RP__: ok cool... any idea where it might be documented?
Mar 01 16:33:02 <RP__> ignus: Its a qemu issue, not a yocto one. I don't think we have any alternative setups documented
Mar 01 16:34:13 <bluelightning> ignus: this may be helpful although it's a couple of years old: http://hub.opensolaris.org/bin/view/Project+qemu/Qemu_Networking
Mar 01 16:34:23 <bluelightning> explains the issues
Mar 01 16:34:48 <ignus> i only have ssh access to the server will that prevent me from using qemu?
Mar 01 16:35:03 <ignus> bluelightning: thanks!
Mar 01 16:38:18 <RP__> ignus: you have X forwarding?
Mar 01 16:39:39 <ignus> RP__: one way to find out! :D
Mar 01 16:42:36 <xumbi> greetings! I'm seeing a problem where /var/lib/opkg/info/<mypackage>.postinst doesn't run at first boot, what actually picks up the postinst scripts at first boot and runs them?
Mar 01 16:46:55 <d4ny> xumbi: The run-postinsts package runs every postinst hook that failed during rootfs generation.
Mar 01 16:47:30 <xumbi> d4ny: ok I'll check if that package is in my rootfs, thanks!
Mar 01 16:47:46 <halstead> RP__, Shall I create yocto-commits@yoctoproject.org and have gitolite post it after commits to any public repo?
Mar 01 16:48:17 <RP__> halstead: Yes please
Mar 01 16:48:29 * halstead nods.
Mar 01 16:48:35 <RP__> halstead: its not urgent but we should do it at some point
Mar 01 16:48:57 <halstead> RP__, Are there any public repos that should be excluded? Like the experimental ones?
Mar 01 16:49:20 <RP__> halstead: I'd make it the same set as those on the website
Mar 01 16:49:32 <RP__> halstead: experimental should be fine being included
Mar 01 17:51:05 <xumbi> d4ny: hmmm, run-postinsts appears to be installed, I wonder what I'm missing
Mar 01 17:52:26 <xumbi> if I run /etc/init.d/run-postinsts by hand I get "No package system found", I'm guessing I need to install opkg dependencies (I'm using ipk packages)
Mar 01 18:11:01 <khem> xumbi: using core-image-minimal ?
Mar 01 18:11:16 <xumbi> khem: core-image-base
Mar 01 18:12:25 <xumbi> I forget which is smaller...
Mar 01 18:13:16 <khem> minimal :)
Mar 01 18:13:29 <khem> but it does have run-postinsts in it
Mar 01 18:14:45 <xumbi> looks like run-postinsts is in core-image-base, but 'opkg' isn't, so the init script doesn't do anything
Mar 01 18:16:03 <xumbi> so I added 'opkg' to POKY_EXTRA_INSTALL, I can see other postinst scripts running, but not mine :(
Mar 01 18:18:15 <xumbi> actually I'm still not sure any postinst scripts are running, time for more digging...
Mar 01 18:52:24 <xumbi> shouldn't this file be looking at /var/lib/opkg instead of /usr/lib/opkg? http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/dpkg/run-postinsts/run-postinsts
Mar 01 18:52:59 <xumbi> although, even if I change it myself before first boot it still doesn't run postinst scripts
Mar 01 19:23:59 <zenlinux> xumbi, any progress?
Mar 01 19:25:07 <xumbi> I'm building with PACKAGE_CLASSES ?= "package_deb" to see if it changes anything
Mar 01 19:25:24 <xumbi> since I think run-postinsts is broken for package_ipk, as far as I can tell
Mar 01 19:26:49 <zenlinux> xumbi, which release of poky are you using?
Mar 01 19:27:04 <xumbi> zenlinux: edison
Mar 01 19:27:34 <zenlinux> hmmm
Mar 01 19:27:58 <zenlinux> I know we do most of our QA testing with RPM, not sure if we're putting ipk through QA
Mar 01 19:29:12 <xumbi> as long as debian packages don't add a lot of space I'd actually prefer that over ipk
Mar 01 19:29:49 <zenlinux> well, I hate to admit it xumbi, but debian packaging definitely gets no testing from us, and incandescant is aware of some bugs with it
Mar 01 19:30:06 <xumbi> oh damn ;)
Mar 01 19:30:20 <zenlinux> incandescant, what were the issues you've been looking into with deb packaging?
Mar 01 19:30:45 <xumbi> maybe we'll be going with rpm then!
Mar 01 19:31:24 <zenlinux> if you're ambivalent about the packaging format, rpm is the best way to go for reliability
Mar 01 19:31:30 <incandescant> last I tried Debian packaging only worked on Debian-based host OS's - so some host intrusion occurring
Mar 01 19:31:41 <zenlinux> oh, that's it?
Mar 01 19:31:52 <zenlinux> xumbi is having issues with postinstall scripts not working with ipk
Mar 01 19:32:22 <Jay7> btw, I've got fetch and patch errors in oe-core when tried to bitbake dpkg
Mar 01 19:32:44 <Jay7> about some hours ago :)
Mar 01 19:32:50 <incandescant> I don't have time to look at dpkg right now, sadly - I have a partial series to fix some issues but there are plenty more
Mar 01 19:33:06 <incandescant> I'll try and fix up and submit that series but you'll still need to be building on a Debian host
Mar 01 19:33:14 <incandescant> post-installs sound broken too :-/
Mar 01 21:41:44 <hollisb> is there an intelligent way to figure out what images include a package? for example, I know I want a VNC server; now what do I need to build?
Mar 01 21:46:46 <khem> hollisb: we need a "do what I mean" switch :)
Mar 01 21:47:01 <kergoth> just pick an appropriate image and add what you want to it
Mar 01 21:47:04 <khem> and OE will take over the world
Mar 01 21:47:11 <kergoth> finding an image that includes a given package jsut doesn't make a great deal of sense to me
Mar 01 21:51:25 <hollisb> kergoth: I don't know everything I want; I only know this one thing. in this example, it wouldn't satisfy me to create a custom image that includes a VNC server, only to find it had no window manager or X client apps
Mar 01 21:51:41 <hollisb> I'd rather find an image someone else has taken the time to tweak, and just use that
Mar 01 21:52:21 <hollisb> maybe a related background question: are there a significant number of packages that aren't included in any of the pre-defined images?
Mar 01 21:53:13 <khem> hollisb: I guess yes
Mar 01 21:53:57 <hollisb> khem: so maybe the answer to my question is "none", and I have to go create a custom image
Mar 01 21:54:12 <khem> hollisb: as kergoth suggested
Mar 01 21:54:18 <hollisb> yeah, I got that
Mar 01 21:54:20 <khem> inherit an existing image
Mar 01 21:54:23 <khem> and build on top
Mar 01 21:54:38 <khem> thats the power of OE
Mar 01 21:54:43 <hollisb> khem: btw, I don't think telepathy is required. yum or apt-get can tell you things about dependency trees...
Mar 01 21:55:24 <khem> bitbake does that too if you play fair with it
Mar 01 21:55:36 <khem> bitbake -g <target?
Mar 01 21:55:42 <khem> err <target>
Mar 01 21:56:03 <khem> but DWIM switch is good in general for many reasons I reckon
Mar 01 21:56:42 <khem> :)
Mar 01 21:56:50 * khem is in lighter vein 
Mar 01 21:56:55 <khem> havent had enough sleep
Mar 01 21:57:42 <hollisb> khem: I'm thinking more like "bitbake findpackagenamed '*vnc*'" -> x11vnc
Mar 01 21:57:54 <hollisb> khem: "bitbake whatincludes x11vnc"
Mar 01 21:58:37 <khem> what is x11vnc
Mar 01 21:58:58 <hollisb> it'a a package name
Mar 01 21:59:47 <hollisb> right now I do this: find meta* -iname \*vnc\*. of course, that can only match recipe names, not package names...
Mar 01 22:00:10 <hollisb> and also that finds recipes in layers that aren't enabled in bblayers.conf
Mar 01 22:00:21 <khem> well I think bitbake -g -u depexp x11vnc
Mar 01 22:00:24 <khem> should help you then
Mar 01 22:01:01 <khem> it parses the tree sure but deps are only created for given target
Mar 01 22:01:43 <hollisb> so after I run my 'find' to hopefully figure out the package name
Mar 01 22:03:01 <hollisb> I'll have to try it after I figure out what python module provides gobject, because depexp doesn't work without it
Mar 01 22:04:00 <hollisb> doesn't look like it's available for my build host...
Mar 01 22:13:01 <kergoth> -g -u depexp x11vnc won't help, he wants the other way around. not what x11vnc deps on, but the things that dep on it
Mar 01 22:14:45 <khem> hmmm
Mar 02 01:20:37 <otavio> NOTE: package perl-5.14.2-r3: task do_patch: Started
Mar 02 01:20:37 <otavio> ERROR: [Errno 22] Invalid argument: '/home/otavio/hacking/ossystems/embedded-linux/tmp-eglibc-eglibc/work/i586-oe-linux/perl-5.14.2-r3/perl-5.14.2/patches/h2ph-multiarch.diff'
Mar 02 01:20:40 <otavio> ERROR: Function failed: patch_do_patch
Mar 02 01:20:41 <otavio> Known error?
Mar 02 01:21:52 <hollisb> otavio: I've noticed that diff actually gets patched during build, somehow
Mar 02 01:22:09 <hollisb> the changes show up in git diff (so this is probably not what was intended)
Mar 02 01:24:03 <hollisb> http://dpaste.org/jj5C5/
Mar 02 01:30:39 <otavio> anyone knows how i can use the PR service?
Mar 02 01:30:46 <otavio> auto-pr
Mar 02 01:57:35 <vmeson> The bitbake site: http://developer.berlios.de/projects/bitbake appears to be webdead, can ping, traceroute but
Mar 02 01:57:44 <vmeson> http connections are timeing out .
Mar 02 01:57:50 <vmeson> *timing
Mar 02 01:58:28 <vmeson> does anyone hear know the folks who maintain bitbake's httpd?
**** ENDING LOGGING AT Fri Mar 02 02:59:58 2012

**** BEGIN LOGGING AT Fri Mar 02 02:59:58 2012
Mar 02 11:19:34 <ignus> hello all
Mar 02 11:20:40 <bluelightning> hi ignus
Mar 02 11:21:50 <ignus> hey, hows it going?
Mar 02 11:23:10 <bluelightning> ignus: not too bad, and yourself?
Mar 02 11:24:00 <ignus> great! just discovered how much faster this sstate_cache thing makes my build if i use it.. very cool.
Mar 02 11:26:25 <bluelightning> yeah it definitely makes a difference against a from-scratch build
Mar 02 11:28:55 <ignus> bluelightning: how are you supposed to use all the rpm/deb/ipks produced by a build? is there a package manager on the target system by default?
Mar 02 11:29:11 <bluelightning> ignus: it depends on the image you build
Mar 02 11:29:25 <bluelightning> ignus: core-image-minimal strips out the packaging data files and does not install the package manager
Mar 02 11:29:29 <ignus> core-image-minimal i think
Mar 02 11:29:37 <bluelightning> ignus: so they aren't of any use with that, by default at least
Mar 02 11:30:05 <bluelightning> ignus: in order to have package management in the image, IMAGE_FEATURES needs to include "package-management"
Mar 02 11:30:07 <ignus> it there an easy way to get the package manager included or is a bit more complex than that?
Mar 02 11:30:18 <ignus> ah ok, cool!
Mar 02 11:31:03 <bluelightning> there's a slight caveat with core-image-minimal in that it manually adds a line to remove the package data files which it really ought not to do (since not having package-management in IMAGE_FEATURES does the same thing)
Mar 02 11:33:10 <ignus> bluelightning: what is the package manager it uses? something yocto specific?
Mar 02 11:36:19 <bluelightning> ignus: the default is RPM, but it's selectable by package type
Mar 02 11:36:48 <ignus> oh, ok - it actually uses a full version of RPM?
Mar 02 11:36:53 <bluelightning> yes
Mar 02 11:37:01 <bluelightning> rpm5 that is (one of the two variants of RPM)
Mar 02 11:37:08 <ignus> does using IPK save much space on the root fs?
Mar 02 11:37:35 <bluelightning> ignus: I've not analysed it... it'll be measurable but not huge I'm guessing
Mar 02 11:38:05 <bluelightning> opkg (the package manager we use for ipk) is perfectly capable, it's just not as full-featured as RPM
Mar 02 11:39:01 <ignus> its interesting because a distribution is often defined by its package manager...
Mar 02 11:40:53 <bluelightning> yes :)
Mar 02 11:41:03 <bluelightning> I guess in embedded you have to be extremely flexible
Mar 02 11:50:26 <ignus> bluelightning: what are core-image-core and core-image-base, any idea?
Mar 02 11:53:21 <bluelightning> ignus: they are poorly named, but core-image-base is a console-only image that includes a little more than minimal (including stuff from MACHINE_EXTRA_R(DEPENDS|RECOMMENDS) that minimal doesn't)
Mar 02 11:53:53 <ignus> but still no x?
Mar 02 11:54:02 <ignus> X11*
Mar 02 11:54:03 <bluelightning> ignus: core-image-core is the same as core-image-base but with X
Mar 02 11:54:11 <bluelightning> plus a few basic X apps
Mar 02 11:54:28 <bluelightning> we really ought to tidy up the naming
Mar 02 11:56:11 <ignus> i suppose it doesnt really matter if its clearly documented somewhere....... ?
Mar 02 11:56:42 <bluelightning> well, we do list all of them in an appendix in the reference manual I think
Mar 02 11:56:55 <bluelightning> but still, better naming would help
Mar 02 11:57:21 <bluelightning> we have at least set the DESCRIPTION variable for all of them for the next version
Mar 02 11:57:53 <ignus> describing what each of them includes and is for?
Mar 02 11:58:03 <bluelightning> briefly, yes
Mar 02 12:06:08 <ignus> does core-image-core include a package manager?
Mar 02 12:06:33 <ignus> s/-core/-base/
Mar 02 12:15:04 <bluelightning> yes, since the default value of IMAGE_FEATURES includes package-management
Mar 02 12:57:02 <kenws> Is there an easy way to clean(sstate) everything but keep the native stuff around?
Mar 02 13:16:45 <RP__> kenws: Just remove the non-native files from the sstate cache directory
Mar 02 13:18:26 <otavio> RP__: The pam commit has a V2 on the log; bitbake also had a V5 (or something) on the log ...
Mar 02 13:18:57 <kenws> RP__: Thanks, and probably remove the x86_64-linux subdir from the working directory, right?
Mar 02 13:19:04 <otavio> RP__: a small details but would be nice to talk to the person to talk about the prefix use in the [] patch header
Mar 02 13:21:16 <RP__> otavio: agreed, I'd noticed the v5 too late to correct it :/
Mar 02 13:22:02 <RP__> kenws: If you're building from sstate, you're likely wiping out the whole of tmp anyway
Mar 02 13:28:26 <otavio> RP__: How does the PRServ works? Does it bump the PR automatically?
Mar 02 13:28:43 <RP__> otavio: based on when the sstate hash changes, yes
Mar 02 13:47:48 <otavio> RP__: I did set it locally to test but I didn't see it bumping PR
Mar 02 13:48:43 <RP__> otavio: in the generated packages?
Mar 02 13:51:35 <otavio> RP__: in  bitbake output ... didn't check the generated ones
Mar 02 13:56:09 <RP__> otavio: it changes the generated output
Mar 02 13:58:12 <otavio> RP__: oh right ... i will take a look. Thanks
Mar 02 15:00:43 <ignus> does anyone know if there is a way of doing automated (nightly?) builds in yocto for testing?
Mar 02 15:08:30 <bluelightning> ignus: we have an autobuilder setup which we use, the code can be found here: http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder/
Mar 02 15:08:52 <bluelightning> ignus: it's based on buildbot, the instance is at http://autobuilder.yoctoproject.org
Mar 02 15:33:25 <MWelchUK_work_> I'm having problems compiling perl when building core-image-minimal on the master branch.
Mar 02 15:33:41 <MWelchUK_work_> I'm running Ubuntu 10.04, anyone else seeing this problem?
Mar 02 15:54:09 <kergoth> ignus: "its interesting because a distribution is often defined by its package manager" -- remember that yocto isn't a distribution. there are many distributions built out of the same metadata
Mar 02 16:43:33 <kergoth> RP__, pidge: out of curiosity, how do you have your build machines set up, for oe/yocto build performance? e.g. separate partition for build dirs, mount options, filesystems used, ssd vs regular..
Mar 02 16:44:28 <RP__> kergoth: I use ext4, noatime and large commit values. RAM makes  the biggest difference to build speed
Mar 02 16:44:52 <RP__> kergoth: I usually have an OS/data drive and keep the build disk separate since they tend to fail earlier
Mar 02 16:45:37 <RP__> kergoth: extents stuff in ext4 is particularly useful
Mar 02 16:47:45 <kergoth> okay, that's helpful, thanks. looking to get a nice fast build setup going for my testing at some point here
Mar 02 16:49:24 <otavio> RP__: extents?
Mar 02 16:53:21 <RP__> otavio: try googling "extents ext4"
Mar 02 16:53:34 <RP__> otavio: wikipedia will put it better than I can here ;-)
Mar 02 17:08:25 <ant_work> RP__: hey there, quick friday question: can you remember why/when the console in cmdline for zaurus was changed to tty1 ? It seems tty0 is ok and is the standard fb console, isn't?
Mar 02 17:09:04 <RP__> ant_work: no idea. Does the commit log say?
Mar 02 17:09:19 <ant_work> oh, main svn is away...was it maybe to get vc1 with the keys?
Mar 02 18:24:51 <kb> Hi,
Mar 02 18:25:55 <kb> If i have 5 SRC_URI links in my recipe, do I need to have 5 SRC_URI[md5sum] and SRC_URI[sha256sum] for each of them?
Mar 02 18:27:52 <otavio> RP__: using PRServ has a broken behaviour when using SRCPV
Mar 02 18:28:08 <otavio> RP__: it changes the SRCPV multiple times
Mar 02 18:29:30 <otavio> RP__: I applied this http://paste.debian.net/158330/ to make it build at my account since i have updated patches for new connman and old ones conflicts
Mar 02 18:29:41 <kb> I specified all the 5 SRC_URI[md5sum] and SRC_URI[sha256sum] for all the links I have, but it keeps complainining back and forth saying md5sum mismatch and sha256sum mismatch.
Mar 02 18:30:07 <otavio> kb: you need to name them all
Mar 02 18:30:49 <kb> otavio: how do we name all of them?
Mar 02 18:30:53 <kergoth> kb: you're defining the same variable over an over again. each time overwriting the previous value :P
Mar 02 18:31:04 <otavio> kb: look at openembedded-core/meta/recipes-bsp/apmd/apmd_3.2.2-14.bb
Mar 02 18:31:07 <kergoth> set name= on the url params and define SRC_URI[<the name>.md5sum]
Mar 02 18:35:31 <kb> kergoth: otavio: Looking into the openembedded-core recipe. Will try it out.  Thank You for pointing out an example.
Mar 02 21:41:41 <kb> WARNING: QA Issue: No GNU_HASH in the elf binary:   what does this warning about?  can we ignore this warning safely?
Mar 02 21:42:08 <kergoth> your build didn't obey the LDFLAGS from the metadata
Mar 02 21:42:12 <kergoth> best to fix that
Mar 02 21:44:27 <kb> kergoth: do we need to add any LDFLAGS ?
Mar 02 21:45:18 <kergoth> hm?
Mar 02 21:45:32 <kergoth> the metadata defines LDFLAGS, with some important things, yes. you should be passing them in
Mar 02 21:45:38 <kergoth> just as it needs to obey CFLAGS
Mar 02 21:49:23 <mranostay> kergoth: is there a way to disable stripping of binaries on a per package basis?
Mar 02 21:49:49 <kergoth> mranostay: the answer is usually dont do that.
Mar 02 21:49:54 <kergoth> the symbols are still available in the -dbg packages
Mar 02 21:49:57 <kergoth> just split out, not removed
Mar 02 21:50:14 <kergoth> just install the -dbg packages and gdb, etc know to use their files
Mar 02 21:51:04 <mranostay> kergoth: what if kernel modules are getting stripped? :)
Mar 02 21:51:13 <kergoth> if they are, something is broken
Mar 02 21:51:17 <kergoth> because the classes handle that specifically
Mar 02 21:51:32 <mranostay> heh ok
Mar 02 21:51:35 * mranostay digs around
Mar 02 21:51:46 <kergoth> there is a variable to do it, but it's almost always the wrong thing
Mar 02 21:51:56 <kergoth> read package.bbclass for details
Mar 02 22:08:06 <mranostay> heh "# This file does not exist. Please do not ask the debian maintainer about it."
Mar 02 22:08:36 <kergoth> nice
Mar 02 23:30:21 <kb> kergoth:  I am not compiling my packages to specify the LDFLAGS.  I am only doing do_install to make the rpms into the image.  Not sure why I am getting WARNING: QA Issue: No GNU_HASH in the elf binary: still?
Mar 02 23:33:01 <kb> kergoth: I have a recipe for a bunch of rpms to make it install into the final target image.
Mar 02 23:34:38 <hollisb> kb: maybe you should pastebin your recipe
Mar 02 23:34:59 <kb> hollisb: sure. will do that.
Mar 02 23:42:18 <kb> hollisb:  http://pastebin.com/D1QfXpTC
Mar 02 23:43:44 <hollisb> kb: ah, so you're not building anything, you're just repackaging some binaries
Mar 02 23:44:12 <hollisb> kb: so that explains why you get the warning: you really didn't build the ELF files with Poky's LDFLAGS
Mar 02 23:45:04 <hollisb> and I don't know more than that :)
Mar 02 23:45:41 <kb> yeah, I am not building anything.
Mar 03 00:06:13 <kergoth> look at INSANE_SKIP and read insane.bbclass
Mar 03 00:06:19 <kergoth> you can disable individual QA checks on apckages
Mar 03 00:08:23 <kb> ok
Mar 03 01:52:16 <mranostay> kergoth: around?
**** ENDING LOGGING AT Sat Mar 03 02:59:58 2012

**** BEGIN LOGGING AT Sat Mar 03 02:59:59 2012
**** ENDING LOGGING AT Sun Mar 04 02:59:58 2012

**** BEGIN LOGGING AT Sun Mar 04 02:59:59 2012
Mar 04 21:07:10 <mranostay> anguiano: heh didn't notice you in here till now
**** ENDING LOGGING AT Mon Mar 05 02:59:58 2012

**** BEGIN LOGGING AT Mon Mar 05 02:59:58 2012
Mar 05 08:27:33 <mckoan> good morning
Mar 05 09:41:10 <MWelchUK_work_> Any idea why I'd need to do this to get Perl building on Ubuntu 10.04? http://hpaste.org/64785
Mar 05 09:41:43 <MWelchUK_work_> It's like the ARCH variable is being overriden on the command line, but I can't see anything doing it.
Mar 05 11:13:47 <jjardon> Hi, Is there any reason why the all the .bb recipes are not in a separate repo, but in he poky/bitbake one instead?
Mar 05 11:47:13 <d4ny> Hi, what tools are the yocto project using when editing the poky/documentation/.. ?
Mar 05 14:57:28 <kergoth> jjardon: you seem to be confused. poky is an integration of content from a variety of places. bitbake has its own repository, as does oe-core (which is where the 'meta' directory in poky comes from)
Mar 05 14:57:57 <kergoth> jjardon: poky integrates into a single repository the way it does for ease of use for the user, as they don't have to fuss with git-submodules, repo, or any similar tool
Mar 05 14:58:15 <denisATeukrea> hmmm strange strange
Mar 05 14:58:21 <kergoth> jjardon: see the scripts/combo-layer tool in the repository
Mar 05 14:58:21 <denisATeukrea> hi
Mar 05 14:58:38 <denisATeukrea> I bitbake gtk+-native and it says that it takes that:
Mar 05 14:58:48 <denisATeukrea> virtual:native:/home/denis/embedded/oe-core/angstrom-bleeding/sources/openembedded-core/meta/recipes-gnome/gtk+/gtk+_2.24.8.bb
Mar 05 14:59:00 <denisATeukrea> still I see no -native and no BBCLASS_EXTENDS
Mar 05 14:59:34 <kergoth> virtual:native:.*gtk_2.24.8.bb *is* gtk+-native.
Mar 05 14:59:40 <kergoth> the PN of that recipe is gtk+-native
Mar 05 14:59:44 <denisATeukrea> ok
Mar 05 14:59:56 <kergoth> if you look at the other messages emitted, you'll see gtk+-native tasks executing
Mar 05 15:00:20 <kergoth> the virtual:native: bit is the 'virtual' recipe emitted by the BBCLASSEXTEND usage
Mar 05 15:00:43 <denisATeukrea> but a grep of BBCLASSEXTEND didn't show anything
Mar 05 15:00:50 <jjardon> kergoth: I see, so if I use bitbake + poky meta repos I can get the same?
Mar 05 15:01:33 <jjardon> kergoth: Or does poky project modify bitbake in any incompatible way?
Mar 05 15:01:40 <kergoth> jjardon: no. once again, poky includes a variety of content, not just bitbake. there's bitbake, oe-core, the meta-yocto layer which is one which does not have its own repository, and other bits
Mar 05 15:01:54 <kergoth> it's not incompatible, but it does have some small differences which haven't been pushed to the bitbake repository yet
Mar 05 15:04:01 <fray> as kergoth aludes to.. there are changes, and they will be pushed back upstream
Mar 05 15:04:12 <fray> there is no intention to keep them "local" to poky (the bitbake changes that is)
Mar 05 15:07:00 <jjardon> kergoth: fray: sure, I just wanted to understand why have a local copy of bibake and oe-core instead use bitbake and oe-core directly and have the poky repo for the yocto-specific meta layers
Mar 05 15:07:24 <jjardon> but as you said easy of use seems to be the reason, rigth?
Mar 05 15:10:27 <denisATeukrea> kergoth, I'll refrase: I see no -native and no BBCLASSEXTENDS in the recipe or in the inc file
Mar 05 15:13:20 <kergoth> denisATeukrea: well, clearly the bbclassextend exists, because the virtual:native: version wasp roduced. grep is your friend :)
Mar 05 15:15:00 <denisATeukrea> yes I already grepped
Mar 05 15:15:14 <denisATeukrea> I'll reread once more the recipes
Mar 05 15:27:18 <denisATeukrea> ok I finally found it
Mar 05 15:27:20 <denisATeukrea> in a bbappend
Mar 05 15:27:24 <denisATeukrea> in meta-gnome
Mar 05 15:28:58 <denisATeukrea> thanks
Mar 05 17:11:13 <Crofton> slacker
Mar 05 17:11:37 <Crofton> davest, is there an ab meeting now?
Mar 05 18:48:26 <autif> I am building an image using master and seems like something in iptables does not compile - unknown type name '__aligned_u64' - known issue or a new issue?
Mar 05 18:52:38 <autif> It is in tmp/sysroots/crownbay/usr/include/linux/if_packet.h
Mar 05 18:52:41 <autif> line 176
Mar 05 19:20:36 <khem> autif: so you are including <linux/if_packet.h> in offending sourcecode I assume ?
Mar 05 19:27:27 <autif> khem - iptables is including it in one of the source files
Mar 05 19:32:42 <khem> is it the _same_ file thats failing to compile
Mar 05 19:32:49 <khem> if not then add it there
Mar 05 19:33:10 <autif> yes - it is the same file that is failing to cimpile
Mar 05 19:34:31 <autif> libxt_pkttype.c:10 includes linux/if_packet
Mar 05 19:34:51 <autif> the former is an iptables file under the extensions directory
Mar 05 19:38:26 <khem> do you have it defined in linux/types.h
Mar 05 19:39:52 <autif> No, it does not look like "aligned" appears in tmp/sysroots/crownbay/usr/include/sys/types/h
Mar 05 19:39:59 <autif> types.h
Mar 05 19:40:14 <khem> tmp/sysroots/crownbay/usr/include/linux/types.h is what you should look into
Mar 05 19:40:35 <autif> sorry, I misread
Mar 05 19:40:40 <khem> if its not there then you have a problem with kernel headers
Mar 05 19:40:50 <autif> #define __aligned_u64 __u64 __attribute__((aligned(8)))
Mar 05 19:41:02 <autif> yes - that line does exist in linux/types.h
Mar 05 19:41:23 <khem> ok so now make sure this is really being included
Mar 05 19:41:36 <khem> add -E switch to compiler commandline for this file
Mar 05 19:49:53 <autif> The GNUmakefile in extensions suppresses the command to compile - I am trying to figure out where that may be
Mar 05 19:50:03 <autif> so that I can add a -E to it
Mar 05 20:00:03 <seebs> A lot of things magically talk more if you export V=1 to them.
Mar 05 20:11:01 <autif> seebs - that worked - except that I had to set V=1 in Makefile, V=1 bitbake iptables did not seem to work - I guess I should have done that in the recipe
Mar 05 20:11:09 <autif> not on the bitbake command line
Mar 05 20:11:22 <khem> EXTRA_OEMAKE +=
Mar 05 20:11:45 <khem> "V=1"
Mar 05 20:11:49 <khem> will work to
Mar 05 20:12:48 <autif> khem - it does not look like linux/types.h is _actually_ included - the first occurrence of __aligned_u64 is when it is used
Mar 05 20:13:06 <khem> ok thats your problem then
Mar 05 20:13:11 <khem> see why its not included
Mar 05 20:13:59 <khem> since #include <linux/types.h> is there in linux/if_packet.h
Mar 05 20:14:06 <khem> so it should have included it
Mar 05 20:15:42 <autif> yup - working on it - I can't imagine it could be anything I am doing - I am just doing "bitbake core-image-sato" for crownbay
Mar 05 20:16:18 <autif> will notify when I do find out the root cause
Mar 05 20:16:18 <khem> yes its package itself
Mar 05 20:16:26 <khem> can you pastebin the .i file ?
Mar 05 20:16:36 <khem> IOW the preprocessed file
Mar 05 20:16:43 <autif> the output of -E
Mar 05 20:16:45 <autif> ?
Mar 05 20:16:49 <autif> is that what you mean?
Mar 05 20:16:49 <khem> yes
Mar 05 20:16:57 <autif> on its way
Mar 05 20:18:45 <autif> http://pastebin.com/77t4TnEk
Mar 05 20:18:49 <autif> khem
Mar 05 20:21:33 <khem> autif: is there a types.h file in this package sources ?
Mar 05 20:25:27 <autif> not just a types.h, but a linux/types.h
Mar 05 20:25:34 <autif> now what do I do?
Mar 05 20:26:02 <autif> thats what it is
Mar 05 20:26:32 <autif> should this not be a problem for every one on master?
Mar 05 20:27:31 <autif> i am sure iptables is used even by core-image-minimal
Mar 05 20:32:18 <autif> and it is not dependent on MACHINE - all machines should compile iptables
Mar 05 20:44:22 <autif> The logs show that iptables was upgraded from 1.4.12.1 to 1.4.12.2 after M2
Mar 05 20:44:34 <autif> I just switched from M2 to master
Mar 05 20:44:50 <autif> I reviewed those changes - they seem fine
Mar 05 20:45:18 <autif> I was hoping to see the order of include directories change in CFLAGS or soemthing
Mar 05 20:45:21 <autif> nothing like it
Mar 05 20:47:14 <autif> There is a patch to GNUmakefile - target check is removed - I wonder what it does
Mar 05 20:49:53 <autif> It looks like his s deliberate - I will post on the mailing list
Mar 05 23:00:41 <mranostay> really no tcpdump recipe in meta-yocto or meta?
Mar 05 23:25:49 <Crofton> not in met-oe?
Mar 05 23:25:58 <Crofton> mranostay, not in meta-oe?
Mar 05 23:26:15 <Crofton> if not, we should add it
**** ENDING LOGGING AT Tue Mar 06 02:59:58 2012

**** BEGIN LOGGING AT Tue Mar 06 02:59:58 2012
Mar 06 05:58:13 <Andy44> hey got a quick question - I just downloaded the java package from yacto's git.
Mar 06 05:59:00 <Andy44> the readme has 1 line in it about adding the package.  it says to add LICENSE_FLAGS_WHITELIST += "oracle_java" to my layer.conf file and it should build.
Mar 06 05:59:32 <Andy44> did that, didn't build it.  the build completed sucessfully but I didn't have java suport when I booted the image.
Mar 06 05:59:55 <Andy44> any ideas?
Mar 06 06:02:35 <Andy44> i also added the path to the downloaded files my bblayers.conf file...
Mar 06 13:36:49 <Zagor> RP__: I'd like to make something that gives me more control over the config/hash of packages. I'm considering a command-line option to warn or abort when the local hash is different from the mirror hash. thoughts?
Mar 06 13:38:19 <Zagor> the use case is when a dev wants to reconfigure one package (such as the kernel) but absolutely wants everything else to be the same.
Mar 06 13:40:54 <Zagor> but since bitbake is complex, it is easy to make a mistake and change parameters that affect other packages. a warning about this would be useful, I think.
Mar 06 14:21:51 <RP__> Zagor: I agree we need better ways to expose this kind of thing. I'm open to ideas on how to do that
Mar 06 14:23:04 <RP__> Zagor: Maybe we should enhance dry-run to report how many things it would do (from scratch and reuse)?
Mar 06 14:53:48 <Zagor> RP__: I'm currently toying with an option to make pstaging_fetch() fail if no cached object is found
Mar 06 14:54:56 <Zagor> the idea being, you run without the option when building your conciously-modified package and the with this option when you build the full image
Mar 06 15:38:44 <RP__> Zagor: I can understand how
Mar 06 15:38:49 <RP__> that would be useful...
Mar 06 17:15:08 * kergoth realizes that setting PKGV_${PN} breaks the RDEPENDS_${PN}-dev
Mar 06 17:39:38 <otavio> sgw: the patch you sent without the 1/4 is useless
Mar 06 17:39:59 <otavio> sgw: and the others I think I improved the commit log as per RP__ request.
Mar 06 17:40:23 <otavio> sgw: the rootfs postinst 2/4 really depends on 1/4.
Mar 06 18:40:12 <kenws> Hi there, Is it possible to have a layer bbappend to the linux-yocto_3.2 recipe in order to build the kernel using a given defconfig?
Mar 06 18:40:24 <kenws> Adding the defconfig to the SRC_URI doesn't seem to work in this case.
Mar 06 18:41:25 <zeddii> kenws. that should work out of the box. it's supported. I did one of those builds just yesterday.
Mar 06 18:41:35 <zeddii> what in particular looked to be missing ?
Mar 06 18:42:23 <kenws> zeddii: I'm using SRC_URI_append = "file://defconfig"
Mar 06 18:42:34 <zeddii> yep. that's all that you need to do.
Mar 06 18:42:38 <kenws> and it seems it's not even parsable
Mar 06 18:42:45 <kenws> hm, ok - i'll check again
Mar 06 18:42:46 <kenws> thank you
Mar 06 18:43:00 <zeddii> and it shows up in your WORKDIR ? i.e. bitbake found and migrated it over ?
Mar 06 18:43:52 <zeddii> let me know either way. I may not be on irc, but you can email me (bruce.ashfield@windriver or gmail.com) .. if it doesn't work, it's a bug and I'll fix it with malice ! :)
Mar 06 18:44:07 <kenws> give me a few seconds to get to the error again - araif the initial bitbake parsing stage didn't succeed
Mar 06 18:44:37 <kenws> alright - thanks for your help!
Mar 06 18:44:39 <zeddii> ok. so that should be even more solvable. since it's nothing specific to the kernel recipe(s).
Mar 06 18:47:54 <kenws> zeddii: maybe I'm lacking a proper seperator? http://paste.ubuntu.com/871904/
Mar 06 18:49:07 <kenws> This is how my bbappend file looks: http://paste.ubuntu.com/871906/
Mar 06 18:50:22 * zeddii looks
Mar 06 18:52:50 <zeddii> odd. where do you have the defconfig on disk ?
Mar 06 18:54:06 <kenws> currently under linux-yocto since I commented out the FILESDIR
Mar 06 18:54:22 <zeddii> file://defconfig is the correct syntax. it's what I have here
Mar 06 18:54:36 <kenws> What would be an appropriate location for the defconfig?
Mar 06 18:54:46 <zeddii> SRC_URI += "file://defconfig"
Mar 06 18:54:52 <kenws> Do you have a layer publicly available where its working?
Mar 06 18:54:57 <zeddii> where you put is is up to how you've configured things.
Mar 06 18:55:51 <zeddii> kenws the linux-yocto based recipes typically use config frags vs full defconfigs. but I use them with the korg recipe in meta-kernel-dev, and we have one in the linux-tiny recipe temporarily at the moment.
Mar 06 18:57:25 <kenws> I didn't manage to create a config fragment for the vexpress. Currently I'm using a non oe/yocto source tree to build an ARM vexpress kernel and adding the defconfig to the SRC_URI works just fine. But I'd like to use the yocto sources instead
Mar 06 18:57:46 <Andy44> hi there everyone.  This Yocto stuff is pretty sweet so far.  I'm working on a state of the art laser controller for may company LasX Industries Inc.  We think Yocto will be the perfect relapcement for our expensive vxWorks we're currently using
Mar 06 18:58:49 <zeddii> kenws.  all sounds good. switching the base tree isn't what's tripping up here. which is the strange thing.
Mar 06 18:58:55 <Andy44> I was trying to remote debug one of my images I built for a sugarbay computer and I found that it would be nice to use the Ecplise Target Managment (RSE)
Mar 06 18:59:28 <Andy44> The service you're supposed to run on your target is dStore and it requires java.
Mar 06 19:00:01 <Andy44> So I set out to add this layer to my build: http://git.yoctoproject.org/cgit/cgit.cgi/meta-oracle-java/
Mar 06 19:00:45 <Andy44> I havn't had any luck though.  The README says I should simply add one line to my local.conf file and it should build.  I do it and it just doesn't work.
Mar 06 19:01:19 <Andy44> The build completes but there's no java!  Clearly I didn't add the package correctly.
Mar 06 19:01:56 <Andy44> Has anyone here gotten this layer to work for them?
Mar 06 19:02:16 <zeddii> kenws. I'll grab a build system eye on this, I'm not sure why bitbake/poky is complaining about SRCPV expansion here. I just fired off my build and it just worked. I'm going to try the defconfig not in a linux-yocto subdir and see if I see that.
Mar 06 19:02:37 <zeddii> my build machine is bogged at the moment, so I'm having  "issues"
Mar 06 19:04:49 * zeddii has brutal lag at the moment.
Mar 06 19:05:11 <kenws> zeddii: I ran the cleansstate task on linux-yocto and try it again now
Mar 06 19:05:33 <kenws> aha! "ERROR: Function failed: Fetcher failure for URL: 'file://defconfig'. Unable to fetch URL from any source."
Mar 06 19:05:55 <zeddii> aha.
Mar 06 19:06:02 <kenws> so it looks like I'm putting th defconfig in the wrong place
Mar 06 19:06:03 <zeddii> so that's bitbake not finding it.
Mar 06 19:06:07 <kenws> yep
Mar 06 19:06:08 <zeddii> yup.
Mar 06 19:08:39 <kenws> zeddii: does the MACHINE influence where bitbake searches the files?
Mar 06 19:09:07 <kenws> I've created a new MACHINE called "qemuarmv7a" that targets ARMv7 (the machine confi simply requires qemu.inc and arm/arch-armv7a.inc)
Mar 06 19:10:21 <zeddii> kenws, it shouldn't have any impact. RP__ is near me right now. maybe he'll notice this :
Mar 06 19:10:58 <kenws> : )
Mar 06 19:16:44 <zeddii> kenws, if you dump your bitbake env,and check FILESPATH, is the spot you have your defconfig covered ?
Mar 06 19:17:31 <RP__> kenws: bitbake linux-yocto -e | grep FILESPATH
Mar 06 19:17:44 <RP__> kenws: that will tell you where its looking
Mar 06 19:18:17 <kenws> thanks, give me a sec : )
Mar 06 19:18:32 <kenws> I was playing with: FILESDIR = "${@os.path.dirname(bb.data.getVar('FILE',d,1))}/linux-yocto-3.2/${MACHINE}"
Mar 06 19:19:13 <kenws> but the resulting FILESDIR was pointing into the oe-core not my meta layer
Mar 06 19:19:37 <kenws> I'll remove this line and check FILESPATH and FILESDIR
Mar 06 19:26:59 <kenws> the two git hashes of linux-yocto makes it a bit unreadable for human eyes : )
Mar 06 19:27:47 <RP__> kenws: it is a bit unwieldy
Mar 06 19:27:47 <kenws> but it doesn't look into my meta layer
Mar 06 19:28:07 <RP__> kenws: if you have a layer, you need to tell it to look in your layer
Mar 06 19:28:26 <kenws> RP__: using FILESDIR?
Mar 06 19:29:08 <zeddii> FWIW. we can toss one of the git hashes, but you get a "polluted" BSP history. I'm still deciding what to do with my patches for that :)
Mar 06 19:29:18 <RP__> kenws: Use something like FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
Mar 06 19:30:15 <kenws> RP__: ok
Mar 06 19:35:45 <kenws> *yay*
Mar 06 19:35:48 <kenws>  FILESEXTRAPATHS_prepend works!
Mar 06 19:37:13 <RP__> kenws: great :)
Mar 06 19:59:37 <kenws> interesting, SRC_URI += "file://defconfig" works but SRC_URI_append = "file://defconfig" doesn't
Mar 06 19:59:46 <kenws> the latter fails with: ERROR: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher failure for URL: 'git://git.yoctoproject.org/linux-yocto-3.2;protocol=git;nocheckout=1;branch=standard/default/arm-versatile-926ejs,meta;name=machine,metafile://defconfig'. Please set SRCREV to a valid value
Mar 06 20:02:34 <kenws> whoops, that's probably my fault. I think need to set SRCREV_machine_qemuarmv7a
Mar 06 20:03:59 <otavio> kenws: put SRC_URI_machine_qemuarmv7a += "foo"
Mar 06 20:06:24 <kenws> otavio: why "foo"? I'd have thought a proper git sha is required to tell bitbake what code do checkout
Mar 06 20:06:32 <kenws> something like: SRCREV_machine_qemuarmv7a ?= "c2028a144fe035719af7c5e9989fedc62ccf3c2c"
Mar 06 20:06:56 <kenws> hm, but still the same error
Mar 06 20:07:20 <kenws> strange that it works when using SRC_URI += instead of SRC_URI_append =
Mar 06 20:07:25 <otavio> sorry
Mar 06 20:07:28 <otavio> myfault
Mar 06 20:07:53 <otavio> SRC_URI_machine += "foo"
Mar 06 20:08:07 <otavio> _append do not add an space before your string
Mar 06 20:09:40 <otavio> or use _append = " foo "
Mar 06 20:10:52 <kenws> otavio: aah, I see. You are right..
Mar 06 20:11:36 * kenws looks at the oe usermanual again
Mar 06 20:14:25 <otavio> heh
Mar 06 21:01:50 <msm> how do I know if i'm using OEBasicHash?
Mar 06 21:03:09 <msm> err
Mar 06 21:03:17 <msm> will the PR numbers go away?
Mar 06 21:16:28 <khem> msm: no PR numbers wont go away
Mar 06 21:16:44 <khem> msm: you can touch your build box during rebuilds it should be hotter than before :)
Mar 06 21:17:00 <khem> msm: but for results you might be a happier rebuilder
Mar 06 21:48:55 <msm> khem: does it not depend on PR though?
Mar 06 21:49:05 <msm> khem: as in a rebuild can get trigger for lots of reasons?
Mar 06 21:49:31 <khem> its a hash of things
Mar 06 21:49:45 <khem> PR is one of them but not everything
Mar 06 21:55:50 <msm> I though PR would equal the "hash of things"
Mar 06 22:08:27 <kergoth> msm: no. PR could in theory go away in favor of PKGR, but some sort of revision is required for packaging. what will likely change in the long term is the removal of the need to *manually* increment it, instead it'll do so automatically
Mar 06 22:08:32 <kergoth> afaik anyway
Mar 06 23:18:39 <msm> kergoth: the pkgr is in the file names?
Mar 06 23:18:41 <msm> for rpm?
Mar 06 23:22:09 <kergoth> msm: most of the time I think it's just part of the version component in the package manager's metadata, not separated, but yes, it generally ends up in the filename. see the packaging classes for the details
Mar 07 02:59:02 <rabryn> can anyone help me with a custom kernel?
**** ENDING LOGGING AT Wed Mar 07 02:59:58 2012

**** BEGIN LOGGING AT Wed Mar 07 02:59:58 2012
Mar 07 03:01:18 <rabryn> i believe i have the machine setup correctly, lpc3250 (arm9 (armv5te) 926ejs core with vfp), but can't seem to get bitbake to accept my 2.6.34 kernel recipe.
Mar 07 03:17:00 <rabryn> i'm getting a 'do_validate_branches' error when i bitbake my kernel recipe... i'm 99% sure it's because i have an issue with my local kernel git repo.
Mar 07 03:19:01 <rabryn> i don't need much flexibility, i simply have one board and need u-boot, a kernel (with one patch), and an rfs.  yocto looks perfect, but might be overkill for my one board.  having said that, i'd really like to use yocto...
Mar 07 03:21:03 <rabryn> i'll be on irc tomorrow all day (central time), if anyone wants to help me out i'd appreciate it!
Mar 07 06:26:11 <mebrown> http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=84d4af1f411742d321311066067e1384779fa700
Mar 07 06:26:22 <mebrown> I am running edison yocto and appear to be hitting this
Mar 07 06:26:45 <mebrown> setting BB_NO_NETWORK in my build results in failure to build update-rc.d due to network
Mar 07 06:27:06 <mebrown> I've verified that the patch at the end of this bug is indeed applied to the source I have
Mar 07 06:30:43 <mebrown> trying to do a build on a machine with no internet connectivity whatsoever
Mar 07 06:55:49 <mebrown> ok, I think I figured it out. I was prepopulating downloads/, but I found "own-mirror" and am using that and moved my pre-populated dir out of the source tree.
Mar 07 08:48:07 <yd_> hi there
Mar 07 08:48:20 <yd_> anyone tried to get yocto running on a tegra2 platform?
Mar 07 10:01:16 <mrAlmond> Hi everyone
Mar 07 10:01:50 <mrAlmond> I'm trying to compile gst-plugins-ugly but I get this error : ERROR: gst-plugins-ugly was skipped: because it may require a commercial license to ship in a product (listed in COMMERCIAL_LICENSE)
Mar 07 10:01:58 <mrAlmond> how can I compile it?
Mar 07 10:14:55 <ant_work> http://cgit.openembedded.org/openembedded-core/commit/?id=64e1db588bcb7b66b08097c0ea443bd4406422d3
Mar 07 10:14:59 <ant_work> mrAlmond:
Mar 07 10:18:03 <ant_work> look in meta/conf/distro/include/default-distrovars.inc
Mar 07 10:21:52 <ant_work> so finally you need LICENSE_FLAGS_WHITELIST += "commercial-gst-plugins-ugly"
Mar 07 10:22:26 <ant_work> mrAlmond: check the comments in this patch  http://cgit.openembedded.org/openembedded-core/commit/?id=a2760661b8c7a4a1b6f2e556853b3a9ae38cbcb5
Mar 07 10:55:50 <mrAlmond> ant_work : Thank you!!
Mar 07 11:28:14 <ignus> hello all
Mar 07 12:18:58 <mrAlmond> guys, I'm using yocto poky-edison-6.0, I need to compile libmms, where can I find it?
Mar 07 12:19:11 <mrAlmond> I need it for gstreamer libgstmms
Mar 07 12:19:42 <mrAlmond> that should be included in gst-plugins-bad
Mar 07 13:01:15 <rabryn> can anyone help me with building a kernel using yocto?  i'm implementing a new bsp for an NXP LPC3250.  i believe i have the machine setup correctly and have a kernel recipe, however, it fails when executing 'do_validate_branches'.
Mar 07 13:12:56 <zeddii> rabryn, can you pastbin the error  ? is this out of master ?
Mar 07 13:13:00 <jackmitch> If I have compiled meta-toolchain and sourced it using the script in bitbake/build/tmp, I now want to compile a program which includes kernel header files, how does it know where to find the source files in the tmp directory?
Mar 07 13:13:43 <jackmitch> because I wouldn't want it using my systems kernel headers right?
Mar 07 13:15:19 <CcSsNET> jackmitch: this is the whole point of a cross compile toolchain. your learning.
Mar 07 13:15:22 <CcSsNET> ;)
Mar 07 13:16:17 <rabryn> zeddii, thanks for responding, what do you mean "pastbin the error"?  i cloned yocto's 2.6.34 kernel and branched to arm_versatile_926ejs-standard, then created a local repo.
Mar 07 13:16:48 <jackmitch> I know I can use -I to specify includes so would it just be a matter of pointing it a the kernel sources and job done?
Mar 07 13:16:57 <CcSsNET> rabryn: i will be soon building for the exact same hardware :)
Mar 07 13:17:50 <rabryn> CcSsNet: NICE!  I could really use someone to bounce ideas off of... i'm new to yocto but have had some experience with oe.
Mar 07 13:18:15 <CcSsNET> jackmitch: youll have to get a response from someone else on that question. i havent actually used yocto for anything yet. just here to observe atm. (i use sourcemage for most things, openwrt for others, debian for the rest)
Mar 07 13:19:20 <zeddii> rabryn, aha. the 2.6.34 kernel has been dropped in the most recent releases. so are you using a correspondingly old branch of the yocto project ?
Mar 07 13:19:53 <rabryn> CcSsNET: i created a 'machine' that incorporates the 926ejs core with support for the vfp, i'm happy to share any of my work to anyone interested... i think it's a little early to be submitting anyting to yocto.
Mar 07 13:21:03 <CcSsNET> rabryn: interesting. the first device i got that had 926ejs was a mini mp4/mp5 handheld tablet like device from china (3.4" screen) on ebay
Mar 07 13:21:48 <CcSsNET> but im fairly sure that 2 other devices i have now are compatable with that build
Mar 07 13:22:41 <CcSsNET> rabryn: atccss.net if u want to contact me in the future and im not responding on irc.
Mar 07 13:23:34 <rabryn> zeddii: not sure (forgive my ignorance), i followed these instructions and replaced 3.0.1-1 with 2.6.34... http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#local-kernel-files
Mar 07 13:25:38 <rabryn> CcSsNET: awesome, i'll be sure to keep in touch... i've been struggling with this stuff for a while now, need all the help i can get!
Mar 07 13:26:44 <CcSsNET> website was hosted on mipsel arch for about a year and a half. its now hosted on an armel tablet (temporary its so damn slow)
Mar 07 13:27:19 <CcSsNET> mipsel is so much more responsive then armel
Mar 07 13:27:26 <CcSsNET> similar clocks and bogomips
Mar 07 13:28:02 <zeddii> rabryn. no worries, you likely did follow the instructions properly, but it probably isn't documented that the kernels cycle and the oldest one is dropped from a given release (there are typically 3 at any time). The 2.6.34 was from the 0.9 days of yocto, and as such it has a different structure from the newer kernels that an up to date recipe from master wouldn't understand.
Mar 07 13:28:49 <ant_work> zeddii: hi, exactly because of that I'm playing with 3.2.9
Mar 07 13:28:54 <zeddii> are the changes really tied to 2.6.34 .. or if there aren't any changes, I'd suggest the 3.0 or 3.2 kernel options for something that will 'just work'. we could probably get 2.6.34 working, but I'd have to set something up and see what's breaking.
Mar 07 13:29:28 <rabryn> zeddii: ah... i see.  well, ultimately i'm simply trying to build a kernel, doesn't have to be a yocto kernel.  the lpc3250 community has a patch for 2.6.34, so that's why i'm trying to build that version.  any ideas on how to build a non-yocto kernel?
Mar 07 13:29:38 <CcSsNET> thats an old kernel ^ i dont personally see a point to working on it.
Mar 07 13:30:05 <ant_work> zeddii: I'm still a bit confused about how to 'yoctize' a simple kernel
Mar 07 13:30:16 <CcSsNET> rabryn: the patch may work on versions up to around 2.6.37 or 2.6.38
Mar 07 13:30:23 <ant_work> now I've seen the Yocto-Tools, seems great stuff
Mar 07 13:30:30 <zeddii> rabryn, sure. you can build any kernel/kernel version that you really want, even with the tools.
Mar 07 13:31:17 <zeddii> ant_work, this is something that is changing to (a) be clearer and (b) be documented clearly .. and if it is clearer, the documentation should be REALLY small
Mar 07 13:31:36 <CcSsNET> http://www.gnuarm.com/
Mar 07 13:31:47 <rabryn> i'm not opposed to a more recent kernel, however, my goal was to get something "known" working first, then upgrade.  i've used eldk 5.1 to compile the kernel and it works great, but i'd like to have more control over the production of the rfs.
Mar 07 13:32:59 <zeddii> ant_work, so you just have a kernel git repo and you want to build it / yoctoize it and then put some changes in it ? If I know what it is .. I can absolutely help you out, and I'll find out about which parts are not easy/right/simple enough.
Mar 07 13:33:04 <CcSsNET> just bookmarked eldk
Mar 07 13:33:45 <ant_work> zeddii: the point is I seem to see two different approaches in linux-yocto and linux-yocto-tiny, the latter providing own config bits
Mar 07 13:34:29 <rabryn> zeddii: should i ditch the yocto kernel layers to do this?  i mean, in my kernel recipe for my own kernel, should i 'require' poky/meta/recipes-kernel/linux/linux-yocto_2.6.34.bb?  i have a feeling i should ditch the yocto stuff (because i'm not using a yocto kernel), however, i'm sure i can leverage some recipe to compile the kernel, just not sure where it's at...
Mar 07 13:35:48 <ant_work> zeddii: I provide a minimal defconfig (shrunk with make_savedefconfig) to http://cgit.openembedded.org/meta-openembedded/tree/meta-initramfs/recipes-kernel/linux
Mar 07 13:35:54 <zeddii> rabryn, there are examples in meta-oe, and other meta layers where if you just want to build a kernel, then absolutely, grab them and drop it into your layer. if you want config fragments or other management utilities, the yocto tools can wrap it for you as well.
Mar 07 13:36:19 <ant_work> now, the mangling done in the .inc file can be appended with .cfg pieces I think
Mar 07 13:36:47 <zeddii> ant_work, linux-yocto-tiny temporarily has it's own baseline config, but we'll be driving it down to a common location, and the standard, preempt-rt and other kernels will use it.
Mar 07 13:37:35 <ant_work> what's confusing is that I'm building for armv5te and all the arm config I found in Yocto are for armv7/beagle
Mar 07 13:37:43 <CcSsNET> rabryn: the main devices i am currently working on: (eken m002 tablet"has debian armel installed atm", open pandora(cortex a8 armel)"stock firmware for now", asus rt-n16 router(mipsel)"openwrt, dd-wrt, tomato,(testing still)", dir-827 dlink router "ubicom32 arch, highly unsupported for now"
Mar 07 13:38:03 <zeddii> rabryn, just do something like this: https://github.com/Freescale/meta-fsl-arm/blob/master/recipes-kernel/linux/linux-imx_2.6.35.3.bb
Mar 07 13:39:35 <zeddii> and if you need fragments, and tooling, you can migrate. FWIW, you could do the same thing with the yocto recipes (i.e. don't start with the linux-yocto upstream), but starting simple is best. and we are about to unifty the "linux-korg" and "linux-yocto" recipes so there's a single place to do this just as simply with the fragments, etc, going forward.
Mar 07 13:40:03 <rabryn> zeddii: awesome, thanks! i'll get right on it... are you available on #yocto frequently?
Mar 07 13:41:13 <zeddii> rabryn, I'm always here (I'm actually travelling this week, so not as much), but you can ping me as required. it helps me find out what isn't working for the new users .. which is valuable
Mar 07 13:41:19 <zeddii> (ok, I'm off my soap box now :)
Mar 07 13:42:03 <CcSsNET> speaking of soap boxs... the open pandora is basically that size
Mar 07 13:42:11 <CcSsNET> :)
Mar 07 13:42:38 <CcSsNET> or slightly smaller then a 3.5" internal hard drive
Mar 07 13:43:52 * zeddii could stand on that too.
Mar 07 13:43:55 <zeddii> and fall
Mar 07 13:45:36 <CcSsNET>  armv5tejl is what is working on the eken m002. i guess not the same target as you afterall rabryn
Mar 07 13:46:10 <CcSsNET> unless thats just highly inefecient use of the cpu (possibly considering its standard debian armel installed)
Mar 07 13:47:06 <CcSsNET> ARM926EJ-S rev 5 (v5l)
Mar 07 13:47:11 <CcSsNET> in cpuinfo ^
Mar 07 13:47:43 <CcSsNET> yea just inefecient i guess
Mar 07 13:48:09 <ant_work> zeddii: omg, you're in LA timezone
Mar 07 13:48:46 <rabryn> zeddii:  thanks for your help!
Mar 07 13:49:03 <zeddii> ant_work, not normally .. but his week yest.
Mar 07 13:49:05 <zeddii> yes
Mar 07 13:49:22 <zeddii> it's a bit early here :)
Mar 07 13:49:30 <ant_work> ^_^
Mar 07 13:51:22 <rabryn> CcSsNET: i used debootstrap to create a debian armel distro and mounted over nfs, worked great, but too big for my nand.  i also investigated emdebian, oe, and cross linux from scratch, but came to the conclusion yocto is the best fit... now if i can only get it working... :-)
Mar 07 13:53:09 <zeddii> rabryn, it'll work ! :) just getting a feel for it, and the swiss army knife that it is can be .. fun!
Mar 07 13:55:47 <CcSsNET> hmm ill check out emdebian
Mar 07 13:56:32 <CcSsNET> its 2012 and this is the first week ive ever used wifi
Mar 07 13:56:53 <CcSsNET> just got the open pandora
Mar 07 13:57:08 <CcSsNET> ;]
Mar 07 13:58:04 <CcSsNET> stock os  on it is not horrible but its not ideal
Mar 07 13:58:20 <CcSsNET> still nicer then stock android
Mar 07 14:01:30 <CcSsNET> specificly the wifi config is all cli only on stock firmware, fairly painfull considering all the options for gui methods
Mar 07 14:02:11 <CcSsNET> soon il replace it though
Mar 07 14:56:26 <kergoth> hey challinan :)
Mar 07 14:57:08 <challinan> hey kergoth: what a surprise ;)
Mar 07 15:02:34 <challinan> anyone here have any suggestions on a workaround for this issue I ran into trying external toolchain?
Mar 07 15:02:41 <challinan> http://pastebin.com/SCMkzEm7
Mar 07 15:03:32 <kergoth> hmm, wonder
Mar 07 15:09:13 <kergoth> there is a legitimize_package_name(), but no equivalent for version/revision :)
Mar 07 15:10:40 <kergoth> oh, wait.. hmm
Mar 07 15:19:09 <kergoth> challinan: trying to repro now
Mar 07 15:19:32 <kergoth> but hopefully one of the folks with rpm-fu will know more about the restrictions
Mar 07 15:21:29 <msm> what's the best way to ensure one package gets rebuilt if another package changes?
Mar 07 15:22:14 <kergoth> if you're using basichash, that'll always automatically be the case based on task dependencies
Mar 07 15:22:17 <kergoth> if not, there isn't one
Mar 07 15:22:54 <msm> so even if I add a DEPENDS for the other recipe and it's SRCREV changes it won't get rebuilt?
Mar 07 15:23:18 <kergoth> i assume you mean the dependency's srcrev changes. that won't rebuild you unless you're using basichash
Mar 07 15:23:36 <kergoth> originally we had dependencies changes not forcing rebuilds of the things that depend on it by design
Mar 07 15:23:51 <msm> ok
Mar 07 15:23:58 <msm> so i need a recent version then
Mar 07 15:24:02 <msm> or bump the PR
Mar 07 15:24:07 <kergoth> yep
Mar 07 15:24:32 <kergoth> this is why in the past tehre's occasionally been commits that just bump a bunch of PRs due to dependency changes
Mar 07 15:24:32 <msm> i'd assume I could make a linux-ver.inc and put SHA's there? then include that in all dependent recipes?
Mar 07 15:24:47 <kergoth> assuming you include whatever var from there in your pv/pr, sure
Mar 07 15:24:51 <msm> kergoth: right, got it
Mar 07 15:25:42 <msm> thanks
Mar 07 18:36:54 <xumbi> greetings!  I just setup a new debian squeeze chroot for my yocto builds, I get this error when trying to bitbake anything:
Mar 07 18:36:54 <xumbi> http://pastebin.com/pUf13Qh6
Mar 07 18:38:38 <xumbi> I wonder if the version of bitbake I'm using has an incompatibility with python in squeeze
Mar 07 18:51:49 <autif> xumbi - i am not sure if yocto is setup to use host's bitbake - you need to source poky/oe-init-build-env - that scripts sets up the path etc so that the bitbake that came with yocto is set up
Mar 07 18:52:32 <xumbi> autif: sorry that wasn't my pastebin, I found it from a google search on my error, my environment is using the bitbake from poky-edison-6.0
Mar 07 18:53:28 <autif> well, in that case - happy building
Mar 07 18:54:11 <xumbi> I'd be happy if I could build something :)
Mar 07 18:54:35 <xumbi> it's strange, I just upgraded another squeeze chroot I had been using and I don't see this error
Mar 07 18:54:44 <xumbi> so I don't think it's related to squeeze
Mar 07 19:02:37 <msm> i'm trying to get libgcc-s-dev installed on my rootfs
Mar 07 19:02:46 <msm> i've added RDEPENDS += "libgcc-dev"
Mar 07 19:02:53 <msm> but the libgcc-s-dev package is not getting adding
Mar 07 19:02:55 <msm> added*
Mar 07 19:03:13 <msm> i can rpm -ivh libgcc-s-dev myself and everything is installed
Mar 07 19:15:00 <xumbi> autif: I figured it out, /dev/shm and /run/shm weren't bind mounting in my chroot, apparently bitbake needs access to them
Mar 07 19:15:53 <autif> cool
Mar 07 19:50:13 <msm> and why is libgcc-dev getting renamed to libgcc-s-dev
Mar 07 23:37:11 <kergoth> hmmmm
Mar 08 02:09:50 <mebrown> Any idea why a build of edison on tmpfs would fail? It exits without any error message after building the first set of packages (pseudo?)
Mar 08 02:10:32 <mebrown> http://pastebin.com/gmDMLpDq
Mar 08 02:10:41 <mebrown> that is the error when I try to run it again
Mar 08 02:12:03 <mebrown> Ah. looks like it is a problem with 'set_device()' in buildstats.bbclass
Mar 08 02:12:14 <mebrown> How can I disable build stats?
Mar 08 02:13:29 <mranostay> mebrown: out of memory?
Mar 08 02:13:42 <mebrown> I have 192GB
Mar 08 02:13:47 <mebrown> not possible
Mar 08 02:14:11 <mebrown> the file not found is not the root cause
Mar 08 02:14:21 <mebrown> the 'rdev' referenced before assignment is
Mar 08 02:14:30 <mebrown> http://patches.openembedded.org/patch/14191/
Mar 08 02:14:35 <mebrown> ah, this looks promising
Mar 08 02:18:01 <mebrown> any idea how to find that patch since the branches mentioned in the bug no longer exist?
Mar 08 02:26:28 <mranostay> mebrown: get merged into a release branch
Mar 08 02:35:15 <mebrown> I'll troll through and pick up the latest. Can I override the buildstats.bbclass in base by dropping an updated version in my later?
Mar 08 02:35:19 <mebrown> s/later/layer/
Mar 08 02:35:39 <mebrown> For now, I commented out the 'inherit buildstats' from base.bbclass, and it is building.
Mar 08 02:36:02 <mebrown> 24cpu system with 192GB RAM. It seems to be going pretty fast.
**** ENDING LOGGING AT Thu Mar 08 02:59:58 2012

**** BEGIN LOGGING AT Thu Mar 08 02:59:59 2012
Mar 08 07:10:36 <mranostay> mebrown: nice
Mar 08 08:31:35 <Samuel1979> Hi, I have a binary that I put in a folder yocto/meta-radiosw/tools/xlf-gen/my-binary which I would like to run. The binary takes a kernel image and some other stuff to generate one image. How do I tell poky/yocto about the tools directory? I would like to run xlf-gen in a recipe to generate the image. Or maybe there is a better way to do it?
Mar 08 08:32:17 <Samuel1979> the binary is precompiled and I don't have the source to it.
Mar 08 08:34:37 <Samuel1979> Basically I just want it to be a part of the environment or buildsystem, but I want to keep it in meta-<my recipes>/tools directory.
Mar 08 10:04:23 <ignus> hello all - does anyone know if there is a simple way to get a list of packages which is included in one of the core-image-* recipes?
Mar 08 10:06:16 <Zagor> ignus: "bitbake -u depexp <image>" gives you a little gui explorer
Mar 08 10:06:54 <ignus> Zagor: im stuck with ssh, is there any other way to do it?
Mar 08 10:08:22 <Zagor> ignus: "bitbake -g <image>" produces dependency graph .dot files, from which you can grep the package list
Mar 08 10:09:01 <ignus> oh cool, i think thats what i need... does it give a dep graph or just a list?
Mar 08 10:09:29 <Zagor> it creates three .dot files
Mar 08 10:15:05 <Zagor> hmm, what is pseudo doing that's taking up so much cpu time? shouldn't it just be rewriting paths and redirecting calls?
Mar 08 13:42:02 <Zagor> wowza, pigz is a nice gzip alternative
Mar 08 13:42:22 <Zagor> cuts down the time to run do_rootfs by a fair amount
Mar 08 14:03:56 <Zagor> heh, quite. gzipping goes from 96 seconds to 2...
Mar 08 14:08:25 <ant_work> Zagor: it all depends on how many cores
Mar 08 14:08:33 <Zagor> of course
Mar 08 14:08:46 <ant_work> still impressive
Mar 08 14:54:03 <kergoth> Zagor: wow, nice
Mar 08 15:36:25 <Zagor> argh, how do I tell bitbake to use my pigz recipe for gzip-native? PREFFERED_PROVIDER_gzip-native = "pigz-native" in my distro.conf is clearly not enough
Mar 08 15:37:07 <kergoth> that wouldn't be enough anyway, unless pigz provides gzip and zcat commands
Mar 08 15:37:50 <kergoth> PREFERRED_PROVIDER tells bitbake which provider of a common piece of functionality you want. it doesn't force the recipe to provide that functionality, that's what PROVIDES in the recipe does
Mar 08 15:38:02 <kergoth> in a way, anyway
Mar 08 15:39:04 <Zagor> I do provide a gzip in the pigz recipe.
Mar 08 15:39:35 <Zagor> but bitbake doesn't even run it, it always selets gzip_1.4.bb
Mar 08 15:40:49 <kergoth> you didn't add gzip-native to pigz's PROVIDES
Mar 08 15:40:51 <kergoth> as i mentioned above
Mar 08 15:41:29 <Zagor> right, but the gzip recipe doesn't have a PROVIDES either. so why is it selected over pigz?
Mar 08 15:41:40 <kergoth> read bitbake.conf
Mar 08 15:41:44 <kergoth> there's always a default PROVIDES
Mar 08 15:41:48 <kergoth> a recipe always provides itself
Mar 08 15:42:05 <kergoth> the default provides includes  ${PN}, ${PN}-${PV}, and ${PN}-${PV}-${PR}
Mar 08 15:42:07 <Zagor> oh, PROVIDES="gzip-native". I misread.
Mar 08 15:42:10 <kergoth> also, learn to use bitbake -e
Mar 08 15:42:14 <kergoth> no, you'll want +=
Mar 08 15:42:26 <Zagor> right
Mar 08 15:47:00 <Zagor> where is PREFERRED_PROVIDER supposed to go? I get "multiple providers are available for gzip-native, consider defining a PREFERRED_PROVIDER entry" even with it in my distro.conf
Mar 08 15:48:11 <kergoth> doesn't matter where its defined
Mar 08 15:48:16 <kergoth> bitbake doesn't distinguish between .conf files
Mar 08 15:48:24 <kergoth> use bitabke -e to check its value
Mar 08 15:54:30 <Zagor> I get both the warning "consider defining a PREFERRED_PROVIDER" and then further down I get PREFFERED_PROVIDER_gzip-native="pigz-native"
Mar 08 15:54:47 <Zagor> and in the end gzip_1.4 is built :)
Mar 08 15:56:57 <kergoth> i hope you typoed it on irc, not in the metadatas )
Mar 08 15:57:07 <kergoth> (preferred, that is)
Mar 08 15:58:12 <Zagor> oops! no it was in my metadata.
Mar 08 15:58:24 <kergoth> hehe
Mar 08 15:58:45 <ignus> does anyone know what package ping and traceroute would be in?
Mar 08 15:58:52 <Zagor> and magically, it works :-) thanks kergoth!
Mar 08 15:58:54 <kergoth> np
Mar 08 16:04:56 <ignus> anyone?
Mar 08 16:08:31 <Zagor> ignus: iputils?
Mar 08 16:12:05 <ignus> Zagor: thanks!!
Mar 08 16:20:41 <jzhang> jzhang
Mar 08 16:28:25 <ignus> does anyone know if its possible to use multiple build servers for poky/yocto?
Mar 08 16:31:56 <kergoth> you can easily run independent builds, one on each server, but bitbake doesn't support distributing individual tasks or recipes across multiple machines at this time
Mar 08 16:56:41 <kenws> Hi, is there a rule of thumb for the BB_NUMBER_THREADS and PARALLEL_MAKE values?
Mar 08 16:57:52 <kenws> maybe something like this:
Mar 08 16:58:08 <kenws>   PNUM=`getconf _NPROCESSORS_ONLN`
Mar 08 16:58:08 <kenws>   BB_NUMBER_THREADS="$([ ${PNUM} -gt 2 ] && echo "$((${PNUM} / 2))" || echo ${PNUM})"
Mar 08 16:58:08 <kenws>   PARALLEL_MAKE="$((${PNUM} + 1))"
Mar 08 17:17:58 <autif> kenws - I have experimented a little with BB_NUMBER_THREADS and PARALLEL_MAKE and seen that if both are about 2X the number of pipelines - I get optimal results - so on a six core processor with hyperthreading - I user 24 as the value - when it is fewer than that - inevitably something at the tail end does not end up using all the resources available.
Mar 08 17:18:53 <fray> thats what i use on my larger machines (lots of ram, fast disks)..
Mar 08 17:19:15 <fray> machines with less ram, or less disk speed.. I usually do 2x actual cores..
Mar 08 17:19:28 <fray> sometimes 1x cores if ram is really limited..
Mar 08 17:19:30 <autif> yup - I have 32 GB on this and if it was 64 GBs, I would consider ramdisk instead of an SSD
Mar 08 17:20:18 <autif> I can get core-image-minimal for qemux86 to build in about 34 minutes
Mar 08 17:20:25 <fray> I have a machine w/ 72 GB of RAM and 16 cores..  that one I've done builds with 32/32 with a ramdisk for the tmp, and SAS for the downloads directory..  never pegs the machine....
Mar 08 17:20:36 <fray> that sounds about like what I've seen..
Mar 08 17:20:43 <Crofton> do not get me started about building a gnome image on a vm .....
Mar 08 17:21:15 <fray> I stay far away from VM images..  Vmware is horribly slow when used on a windows amchine (compared to native Linux performance).. it's all due to the horrendous memory and cache management of Windows
Mar 08 17:25:07 <kenws> autif:  setting both to 24 while /proc/cpuunfo shows 12 sounds like quite high values to me.  Is that because not all of the packages are utilizing -j or is the max amount of bitbake threads not reached because it's waiting on dependant packages?
Mar 08 17:26:29 <kenws> if everything gets parallized you would have 24*24 GCCs compiling stuff on a machine with 12 pipelines
Mar 08 17:26:52 <fray> kenws during compilation and other activites there is a lot of blocking on system resources..  in many cases 2x will get you more system utilization as the blocked process will yiled to one that starts doing actual compilation work..
Mar 08 17:27:11 <fray> (blocking is usually on disk read/write or simply file locks)
Mar 08 17:28:36 <kenws> hm, but why x2 for both the amount of bitbake tasks and the -j?
Mar 08 17:28:59 <kergoth> i usually find 1.5x is good for bitbake threads and 2x for make jobs, myself
Mar 08 17:29:05 <kergoth> from experimentation
Mar 08 17:29:07 <kergoth> but resutls vary
Mar 08 17:29:13 <kergoth> depends on the capabilities of your machine
Mar 08 17:29:21 <fray> yup, every machine and usage case is different..
Mar 08 17:29:26 <fray> you just have to experiement..
Mar 08 17:30:10 <kenws> on my build system /proc/cpuinfo shows 24x "E5649  @ 2.53GHz" with 32GB of RAM
Mar 08 17:30:54 <kenws> I just switched from building on the hdd to building on tmpfs which saves me half an hour when building the sato+qt4e images
Mar 08 17:31:12 <fray> start with 24/24..  if you run out of memory drop the make -j side down a bit.. if the memory is adequate then tune for performance.. you'll find a good number based on your system resources
Mar 08 17:32:39 <kenws> But in theory this means 24 by 24 GCCs running in parallel or am missing something?
Mar 08 17:36:23 <kenws> (which probably only rarely happens because of missing dependencies for both - make and bitbake)
Mar 08 17:36:52 <kergoth> that does not mean 24 x 24 gccs in parallel
Mar 08 17:37:00 <kergoth> do_compile is only one of many tasks to be run
Mar 08 17:37:10 <kergoth> even not considering dependency bottlenecks and i/o
Mar 08 17:37:30 <autif> yes, in theory 24x24 is the max that can hit - with a lots of RAM - this should be a non issue - it is still a small number as far as context switch for example goes. - However, in reality, I do not see that load most of the time
Mar 08 17:37:37 <kenws> ah, true. unpack for example won't utilize the -j24
Mar 08 17:38:18 <autif> it is just enough to make sure that all 6 cores are running at full utilization including the two pipelines per core
Mar 08 17:38:24 <kergoth> hmm, are richard's bits for generating that bootchart type view of the task executions available anywhere?
Mar 08 17:39:01 <autif> https://wiki.yoctoproject.org/wiki/Build_Performance
Mar 08 17:39:06 <kenws> sounds like having a high amount of parallel bitbake tasks is preferrable over a high -j value when building on tmpfs
Mar 08 17:39:07 <autif> is that what you meant?
Mar 08 17:40:13 <fray> kenws, again.. it's machine specific.. what works for someone is a good starting point, but you need to profile your own builds on your own machine..
Mar 08 17:40:15 <kenws> interesting chart : )
Mar 08 17:40:17 <kergoth> not that one, no
Mar 08 17:40:39 <kenws> fray: I see
Mar 08 17:41:00 <kergoth> autif: http://comments.gmane.org/gmane.linux.embedded.poky/3646, http://tim.rpsys.net/bootchart.png
Mar 08 17:42:25 <kergoth> the matrix script is interseting though, will have to looka t that
Mar 08 17:43:30 <autif> kergoth - very interesting - ncurses take for ever and a lot of things depend on it - if that can be improved - build time goes down - dont have a clue as to why/how. I am sure someone is working on it
Mar 08 17:43:37 * kergoth nods
Mar 08 17:44:35 <kenws> kergoth: this seems to be only for the native part of a build. wow, it looks like the configure task of m4 and the compile task of ncurses do block other tasks
Mar 08 17:44:46 <autif> bootchart2 is pretty smooth though
Mar 08 17:44:56 <kergoth> it's quite interesting, and would be nice to run some more nowadays to check the state of things
Mar 08 17:46:52 * kenws wonders what "buildstats" does when enabled at the USER_CLASSES
Mar 08 17:47:28 <kenws> it creates a buildstats dir but...
Mar 08 17:47:30 <kergoth> it records task execution times, per task cpu usage, etc
Mar 08 17:47:33 <kergoth> quite useful
Mar 08 17:49:39 <kenws> ah, I see - nice. Is there anything that visualizes these numbers?
Mar 08 17:50:33 <kergoth> good question
Mar 08 19:02:17 <autif> poky git repository has not seen any checkin in the last 3 days - is there a reason for this?
Mar 08 19:06:17 <msm> autif: they cancled a meeting today too - maybe they are busy?
Mar 08 19:06:51 <autif> RP__ is not online either
Mar 08 19:07:23 <autif> sgw may know?
Mar 08 19:12:18 <sgw> autif: we are busy at an event, expect the flow to start next week
Mar 08 19:12:42 <autif> thanks sgw
Mar 08 21:05:17 <kergoth> hmm, wonder if any upstream layers (e.g. oe-core, meta-oe, meta-yocto) would want this nano-tiny recipe. just builds with a configure arg that enables tiny mode, disabling many extra features. considering how many folks don't know vi, it could be a useful thing to include in some images
Mar 08 21:08:06 <autif> this looks like an invitation for vi vs. some other editor flamewars :P
Mar 08 21:09:09 <kergoth> I don't think so. this isn't about the editor of your choice
Mar 08 21:09:22 <kergoth> it's about the default, mostly useless editors for modifying config files
Mar 08 21:09:27 <kergoth> that's a fair bit different
Mar 08 21:09:39 <kergoth> for example, vim is awesome, but busybox and nvi pretty much suck for anything but the occasional config file
Mar 08 21:09:48 <kergoth> so i don't see personal feelings coming into it as much
Mar 08 21:10:07 <autif> is the recipe is contrib?
Mar 08 21:10:08 <kergoth> the main thing is reducing initial pain and potential confusion, and even vi fans admit it isn't intuitive for an initial user
Mar 08 21:10:21 <kergoth> not yet, it's one we have internally at mentor, was thinking aboutpushing it
Mar 08 21:10:38 <autif> will keep an eye out
Mar 08 21:10:40 <seebs> Okay, busybox I can see, but... I like nvi way better than vim.  :)
Mar 08 21:11:15 <seebs> vim's infinite undo is in theory more powerful, but nvi's is less likely to leave me confused and unsure where my changes went.
Mar 08 21:11:22 <autif> see what I mean 8-)
Mar 08 21:12:19 <seebs> I would totally back either of them over classic Berkeley vi.
Mar 08 21:12:52 <seebs> But if I had to choose which one I wanted to use, it'd be nvi pretty much every time.  I have 30 years of reflexes for how u and . work.  nvi is compatible with those habits, vim isn't.
Mar 08 21:14:52 <kergoth> what i love, love, love about vim 7.3
Mar 08 21:14:54 <kergoth> persistent undo
Mar 08 21:15:04 <kergoth> edit a file, change something, save, exit, edit it again, undo what you did last time
Mar 08 21:16:03 <kergoth> at any rate, I think if someone were constructing, say, a rootfs for an ap/router, nano would be more useful for quickly editing config files than any vi
Mar 08 21:18:02 <phdeswer> kergoth, execpt if you have some interesting shell that does not like ctrl+ commands...
Mar 08 21:18:31 <kergoth> that's not very likely
Mar 08 21:19:19 <phdeswer> Lived through it. Very fun in the shell too. No job control and CTRL+C kills your shell...
Mar 08 21:19:39 <kergoth> the answer in that case is to fix your shell/tty, imo
Mar 08 21:19:49 <phdeswer> And otherwise you have those nice touchscreen keyboards with out ctrl key...
Mar 08 21:20:01 <kergoth> that's what ssh is for
Mar 08 21:20:15 <kergoth> but i'm not arguing that busybox vi be disabled, just to have a more user friendly alternative available to be added to images
Mar 08 21:20:34 <phdeswer> Well it is true that nano is more straightforward for a novice
Mar 08 21:51:56 <seebs> My memory may be wrong, but it was either nano or pico that autowrapped config files.
Mar 08 21:52:05 <seebs> Which was a very-recurring support call.  :)
Mar 08 21:52:38 <kergoth> haha
Mar 08 21:52:43 <kergoth> ah pico, memories..
Mar 08 21:52:53 <kergoth> i knew a software engineer once that did all of his coding in nano
Mar 08 21:52:58 <kergoth> it was rather disturbing..
Mar 08 21:53:33 <hollisb> heh
Mar 08 21:54:09 <kergoth> seebs: hmm, do you play Rift, by chance?
Mar 08 21:54:25 <seebs> ... mayyyyybe
Mar 08 21:54:36 * kergoth remembered seeing the nick on riftui.com
Mar 08 21:54:44 <seebs> Which is to say, I am pretty sure one of their staff has more posts than me on their forums.  :P
Mar 08 21:54:49 <seebs> yup.
Mar 08 21:54:57 <seebs> Note the #riftuidev channel on this very IRC server.  :)
Mar 08 21:55:13 <seebs> For reference:  If you program recreationally, I highly reccomend their addon API.  It is a TON of fun.
Mar 08 21:55:18 <kergoth> I haven't done any ui dev for rift, but i used to for wow. I wrote the object model used by the "Ace" framework
Mar 08 21:55:20 * kergoth nods
Mar 08 21:55:24 <seebs> I have done MMO addons before, and it was like pulling teeth.
Mar 08 21:55:25 <kergoth> I'll have to play around, brush the dust off the lua skills
Mar 08 21:55:42 <seebs> Oh!  Well, thank you a bazillion, back when I played WoW I got a lot of use out of that, indirectly.
Mar 08 21:56:05 <seebs> Trion hired ZorbaTHut to do their addon API, so the API exists, not because it's the bare minimum to let their devs write a UI, but with intent that it be used to write addons.
Mar 08 21:56:11 <seebs> It's beautiful.
Mar 08 21:56:14 <kergoth> nice
Mar 08 21:56:40 <seebs> I've been doing mostly library-level stuff for it, although I did a couple of utility things.
Mar 08 21:57:00 <seebs> Had a week of vacation.  Spent it all programming.  Came back relaxed and ready to work.  :)
Mar 08 21:57:29 <seebs> I have actually sort of toyed with an idea of making an addon named pseudo.
Mar 08 21:57:31 <kergoth> hah. know how that goes. at least, I used to. got burned out a while back, had to slowly rebuild the desire to do OSS work on the side
Mar 08 21:57:47 <seebs> Which would provide a shell-like UI for access to all sorts of API functionality.  :P
Mar 08 21:58:54 <seebs> It doesn't hurt that Lua is one of my top three languages by "fun to program in".  (Lua, Ruby, C.)
Mar 08 21:59:28 <kergoth> my main languages are python, lua, c, in about that order. though 'Go' is intreguing, haven't found a project to use it for yet
Mar 08 21:59:42 <kergoth> i don't think i've ever met anyone good at both python and ruby.. they're so similar, once you know one, there's little motivation to learn the other
Mar 08 21:59:47 <kergoth> heh
Mar 08 22:01:04 <seebs> I love ruby and strongly dislike python.  I think it's a philosophy thing.  I learned a bit of Python first, but it never clicked for me.
Mar 08 22:01:39 <seebs> I had just learned PHP when someone told me maybe I'd like Ruby, so my impression of it was like coming out of a damp cave into a warm spring day.
Mar 08 22:02:11 <seebs> PHP, as a programming tool, ranks a little below cleaning catboxes on my personal preference list.
Mar 08 22:03:30 <kergoth> php is way too much like perl
Mar 08 22:04:04 <seebs> It's very much like a half-baked cross between perl, C, and every programmer's first attempt to write a programming language.  Only without the elegance.
Mar 08 22:04:34 <seebs> <-- not a big fan  :)
**** ENDING LOGGING AT Fri Mar 09 02:59:58 2012

**** BEGIN LOGGING AT Fri Mar 09 02:59:58 2012
Mar 09 07:21:40 <Zagor> now do I specify shell commands to run in the background in a bbclass? the normal & syntax gives me parse errors.
Mar 09 08:15:50 <Zagor> why is package_tar_install() running "zcat %s | tar -xf -" instead of just "tar -xf %s" ? are we expecting native tar without gzip support?
Mar 09 08:34:09 <seebs> Probably not, but it's not as though relying on tar to spawn gzip makes it significantly more robust.  :)
Mar 09 08:41:09 <mckoan> good morning
Mar 09 08:46:42 <Zagor> seebs: no, I'm just curious if there is a technical reason. it seems to be the only place we use zcat.
Mar 09 10:35:41 <ignus> hello all - anyone know what recipe would contain an ftp client?
Mar 09 10:46:33 <Zagor> ignus: wget?
Mar 09 11:03:20 <ignus> Zagor: thats not a bad idea, thanks!
Mar 09 13:11:40 <daiane> I've been trying to set up yocto to create a nfs exportable directory but I could find the right way for that
Mar 09 13:12:23 <daiane> I built the minimal image. And I can boot if using SDCard image.
Mar 09 13:12:45 <daiane> I have 2 main questions:
Mar 09 13:13:00 <daiane> 1- how to configure yocto to create a nfs exportable dir
Mar 09 13:13:37 <daiane> 2- is there anything missing on minimal image to allow nfs to boot?
Mar 09 13:31:05 <Zagor> if anyone else wants to play with pigz in the build, here's a recipe patch: http://pastebin.com/AMeD2m00
Mar 09 13:35:55 <ant_work> Zagor: it's interesting stuff, pls send patch with git to the mailing list
Mar 09 13:36:06 <Zagor> yes, I will
Mar 09 13:36:11 <ant_work> thx
Mar 09 13:36:56 <ant_work> intriguing even, some happy people are building with >96 cores iirc
Mar 09 13:38:08 <ant_work> how much time do you save using pigz-native?
Mar 09 13:39:33 <Zagor> I haven't done much measuring yet, but the rootfs compression I mentioned yesterday went from 96 seconds to 2.
Mar 09 13:39:55 <Zagor> I have 64 cores
Mar 09 13:40:11 <ynezz> heh
Mar 09 13:40:18 <ynezz> bastards
Mar 09 13:41:43 <Zagor> currently, bitbake doesn't scale very well though. I hope to be able to improve this.
Mar 09 13:42:24 <ynezz> what monster is that? 64 cores?
Mar 09 13:43:16 <Zagor> ynezz: 4 amd opteron 6272
Mar 09 13:43:38 <ynezz> ah
Mar 09 13:56:46 <Zagor> did someone change PREMIRRORS handling lately? I just pulled from head, and now https is not translated to http as per my PREMIRRORS_prepend variable.
Mar 09 13:58:33 <Zagor> I have "https://.*/.* http://linux.enea.com/sources/" but it still tries to wget https://linux.enea.com/sources/elfutils-0.148.tar.bz2
Mar 09 14:07:14 <Zagor> perl builds with plain "make". one file at a time.
Mar 09 14:25:42 <Zagor> python gurus: what is the most elegant way of splitting a for loop into X threads?
Mar 09 17:45:02 <msm> anyone see:
Mar 09 17:45:02 <msm> ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded: ignored.
Mar 09 17:45:10 <msm> im running 32-bit chroot from a 64-bit machine
Mar 09 18:39:47 <msm> nevermind - this was from a poluted rootfs
Mar 09 18:40:00 <msm> 32-bit and 64-bit libraries on a 32bit machine
Mar 09 18:47:40 <mranostay> that will do it
Mar 09 19:01:12 <rabryn> zeddii: i've come a long ways in the last day and half, thanks for your help!
Mar 09 19:07:09 <zeddii> good to hear. I'm back in Eastern Time now .. so I'm a bit tired, but good to hear.
Mar 09 19:16:19 <rabryn> zeddii: i've built my kernel, u-boot, and created my own recipe to build zeromq.  next i'm trying to extend the 'core-image-base' to include that package... 2 questions...
Mar 09 19:17:07 <rabryn> the first, is tried to use 'hob' but i get this error when i try to launch it from my build dir: 'AttributeError: 'NoneType' object has no attribute 'get_width''
Mar 09 19:17:10 <rabryn> any ideas?
Mar 09 19:18:41 <zeddii> hmm. I'm not 100% sure. I'm looking and don't see many hob folks in the channel right now.
Mar 09 19:19:48 <rabryn> eh, it's no problem, i just figured out my second problem... so i guess i'm square.  thanks.
Mar 09 19:20:02 <zeddii> heh.
Mar 09 19:20:09 <zeddii> 50% solved!
Mar 09 19:21:56 <rabryn> do you recommend inheriting an existing image or requiring one?  i.e.: require core-image-base or inherit core-image-base? and what's the difference?
Mar 09 19:22:07 <rabryn> got to eat lunch... brb.
Mar 09 20:13:50 <rabryn> zeddii: hate to bother you again, but any ideas on those questions?
Mar 09 20:21:42 <zeddii> rabryn, I was trying to raise someone about the hob question.  I didn't hear anything yet. All the work is happening on hob2 at the moment, or on master. are you on those branches ?
Mar 09 20:22:42 <zeddii> as for the other, there were discussions about inherit vs require on the lists just recently .. while not exactly your question, they were close (IIRC)
Mar 09 20:27:01 <rabryn> thanks.  i'm using the git repo for poky/edison.  i'm not an irc guru, how would i search the history to understand the benefits of require over inherit or vice versay?
Mar 09 20:27:09 <rabryn> versa*?
Mar 09 20:27:40 <mranostay> google?
Mar 09 20:29:57 <zeddii> rabryn, I have everything archived here. I'll try a quick search. the difference is subtle.
Mar 09 20:30:00 <rabryn> mranostay: i'm looking it up now... didn't mean to come off lazy...
Mar 09 20:30:13 <zeddii> so I don't want to answer off the top of my head and steer you wrong.
Mar 09 20:31:14 <rabryn> excellent, thanks.
Mar 09 20:31:49 <mranostay> i think inherit doesn't fail if doesn't find a class
Mar 09 20:37:37 <zeddii> right. require blows up if it can't find the file.
Mar 09 20:38:17 <zeddii> and that's the biggest difference. I was thinking evaluation order, but I'm crossing the conversation about += with _append, _prepend, etc.
Mar 09 20:39:43 <rabryn> gotcha
Mar 09 21:20:39 <rabryn> does anyone know where all the different methods you can override are for a recipe?  i'm looking at the boost recipe and i don't see it require/inherit anything but i need to copy in boost_log before building it... not sure what method to override.  is there like a "recipe base class" that provides all the "virtual functions" for a recipe?  (yes, i'm more of a c/c++ person than python).
Mar 09 21:25:35 <khem> rabryn: you can override pretty much any function
Mar 09 21:25:43 <khem> rabryn: just define it in your recipe
Mar 09 21:26:04 <khem> and you can also register _append and _prepend functions for pre and port talk activities
Mar 09 21:26:36 <khem> so from what you wrote it seems you need that file before boost is configured ?
Mar 09 21:26:56 <khem> then you can add a functions called do_configure_prepend() {}
Mar 09 21:27:03 <khem> and do copying in there
Mar 09 21:27:05 <rabryn> khem: ah... i think i'm just figuring that out now... is this what the "addtask do_boostconfig after do_patch before do_configure" means?  where "do_boostconfig" is a new function?
Mar 09 21:27:14 <khem> yes pretty much
Mar 09 21:27:30 <rabryn> nice, thanks!
Mar 09 21:27:41 <khem> yes bitbake does not care what the tasks are as long as there are
Mar 09 21:28:25 <khem> its pretty flexible that way
Mar 09 21:29:06 <rabryn> i see
Mar 09 22:11:46 <bizhanMona> HI is there any BSP support for Sandybridge + Patsburg (X79) chipset ?
Mar 09 22:37:07 <rabryn> yet another (potentially dumb) question... so, i'm writing a recipe for boost that includes support for boost_log.  i have to use boost version 1.45.0.  i've named my recipe boost-foo_1.45.0.bb, but everytime i bitbake boost-foo it chooses 1.49.0 (which is what is available in meta/recipe-support/boost.  why is yocto using 1.49.0 instead of 1.45.0?
Mar 09 22:38:45 <rabryn> to clarify, i see that yocto is downloading 1.49.0 when i bitbake... instead of 1.45.0.
Mar 09 23:35:44 <dvhart> zeddii, the iptables failure you were hitting earlier... what was the workaround?
Mar 10 00:59:33 <dvhart> rabryn, check the SRC_URI,does it use PV?
**** ENDING LOGGING AT Sat Mar 10 02:59:58 2012

**** BEGIN LOGGING AT Sat Mar 10 02:59:58 2012
Mar 10 16:05:12 <rabryn> can anyone here help me with a package version issue?
Mar 10 17:42:43 <bizhanMona> HI I am new to yocto, I would like to know whether yocto supports BSP for SandyBridge and Patsburg chipset?
Mar 10 19:29:38 <15SABAJFR> bizhanMona: see the meta-romley BSP in meta-intel
Mar 10 22:54:35 <bizhanMona> HI would yocto supports glibc?
**** ENDING LOGGING AT Sun Mar 11 02:59:58 2012

**** BEGIN LOGGING AT Sun Mar 11 02:59:58 2012
Mar 11 05:56:00 <mranostay> bizhanMona: not sure i follow your question
Mar 11 12:49:44 <RP__> bizhanMona: We have eglibc
Mar 11 14:44:01 <RP__> khem: I'm hoping the patches on bitbake-devel help your memory issues
Mar 11 18:56:07 <waynr> hello folks
Mar 11 18:57:00 <waynr> i am attempting to create a new BSP layer but get two errors "ERROR: Nothing RPROVIDES 'perf'"
Mar 11 18:57:40 <waynr> well maybe i should put this in a pastebin
Mar 11 18:59:48 <waynr> http://pastebin.ca/2126933
Mar 11 19:01:51 <waynr> i am still pretty new to oe so i'm not sure where to start on this one
Mar 11 19:02:03 <waynr> i looked for recipes named "perf" in poky/meta/
Mar 11 19:02:15 <waynr> i found something called "gperf"
Mar 11 19:02:45 <waynr> but it doesn't "RPROVIDE" perf
Mar 11 19:05:16 <waynr> i see in poky/meta/classes/kernel.bbclass line 528 a comment that says "perf must be enabled in individual kernel recipes"
Mar 11 19:05:41 <waynr> srry, line 526
Mar 11 19:06:08 <waynr> does this mean i need to select a kernel or something?
Mar 11 19:08:53 <waynr> the only layers i specify in this BSP are the BSP itself and poky/meta
Mar 11 19:10:56 <waynr> i checked the BSP mailing list, looks fairly inactive
Mar 11 19:17:03 <waynr> it looks like if all i have is my BSP and the poky/meta layer nothing provides a kernel
Mar 11 19:17:07 <waynr> possibly?
Mar 11 19:17:53 <waynr> maybe i will try copying conf/distro/defaultsetup.conf and adding some kind of variabl or something that would indicate the use of some kernel or other
Mar 11 19:46:41 <waynr> maybe i will post my question anyway
Mar 11 19:46:52 <waynr> (on the mailing list)
Mar 11 20:18:15 <ESI> Hi there, I searched the WEB but did not find documentation (besides the installation) of yocto on routerstation pro. Is there any documentation or quick start for routerstation pro?
Mar 11 20:20:07 <bluelightning> ESI: have a look in README.hardware
Mar 11 20:20:29 <bluelightning> that contains some basic info specific to the rspro
Mar 11 20:21:46 <ESI> Thank you for the answer. In README.hardware, there is the installation described, but I am looking for some kind of quick start after installation.
Mar 11 20:23:48 <bluelightning> ESI: what kind of information are you after?
Mar 11 20:24:10 <ESI> For example, a short notice, how to setup the router, wireless, WPA2 and so on. Maybe advice to install some webserver for configuration or so.
Mar 11 20:25:16 <bluelightning> ESI: that's probably beyond the scope of what we currently provide
Mar 11 20:25:52 <ESI> I am using Poky on Zaurus, there it is quite obvious, you boot it and the rest is graphical.
Mar 11 20:26:19 <bluelightning> ESI: the rspro is mostly a hardware test platform for the MIPS architecture for us
Mar 11 20:26:37 <bluelightning> that's not to say you can't do more with it
Mar 11 20:27:04 <ESI> Is anybody using yocto on rspro? Some experience report would be enough, I guess
Mar 11 20:27:40 <bluelightning> well, I've booted it many times, but I've not set it up as a proper router
Mar 11 20:28:29 <ESI> Ok, thank you. I guess then it would be up to me to provide such a report... if I get there ...
Mar 11 20:28:36 <bluelightning> sure
Mar 11 20:28:56 <bluelightning> you'd need to be familiar with standard linux bridging / routing from the command line
Mar 11 20:29:45 <bluelightning> we don't have a standard router web interface... you could use the one from openwrt but then, you might as well be using openwrt itself I suspect if that's what you want
Mar 11 20:31:15 <ESI> I am using openwrt now. I would have like the idea of taking yocto, because I know the build process.
Mar 11 20:35:59 <ESI> bluelightning: Thank you for the answers, I will try out yocto, if I find the time.. first I stick to openwrt.
Mar 11 20:36:27 <bluelightning> ESI: ok... please feel free to ask questions if you do, I'll be happy to help :)
Mar 11 20:38:37 <khem> RP__: I am testing them as I speak :)
Mar 11 20:46:49 <ESI> bluelightning: Thank you.
Mar 12 00:52:58 <rabryn> can anyone help me with a simple recipe question?
Mar 12 00:54:21 <rabryn> i'm writing a custom recipe to package a static library.  the library compiles fine, i just can't see to get the recipe to build a dev package with headers and a standard package with the binary...
**** ENDING LOGGING AT Mon Mar 12 02:59:58 2012

**** BEGIN LOGGING AT Mon Mar 12 02:59:58 2012
Mar 12 08:59:12 <JaMa> RP__: any idea why after building everything except gcc-cross-canadian (failed because of cross compile badness) and doing "bitbake -c unpack -f gcc-cross-canadian" it rebuilds all *gcc* recipes (e.g. gcc-cross, libgcc, gcc)? Maybe it removes more stamps then it should?
Mar 12 09:24:32 <JaMa> ah and now gcc-cross-canadian failed because of LDFLAGS value change, http://paste.pocoo.org/show/564518/
Mar 12 09:30:38 <mckoan> good morning
Mar 12 09:41:10 <likewise> gm
Mar 12 10:13:11 <bluelightning> morning all
Mar 12 10:23:28 <RP__> JaMa: gcc has the shared work directory and I guess the missing stamps confuse it
Mar 12 10:24:01 <RP__> morning all
Mar 12 10:24:35 <JaMa> and how to "restart" clean build for gcc-cross-canadian?
Mar 12 10:25:01 <JaMa> because this config.cache happens after each MACHINE switch :/
Mar 12 10:25:34 <JaMa> and sometimes it happens with target gcc too
Mar 12 10:28:03 <RP__> JaMa: which directory is the config.cache in? ${B} ?
Mar 12 10:29:24 <JaMa> RP__: http://paste.pocoo.org/show/564533/
Mar 12 10:31:00 <RP__> JaMa: Does a "bitbake cross-canadian -c clean" and then building again work better?
Mar 12 10:31:59 <JaMa> gcc-cross-canadian right?
Mar 12 10:32:06 <JaMa> and now it will rebuild everything too
Mar 12 10:32:33 <JaMa> that's why I tried to use -c unpack -f instead of clean
Mar 12 10:35:50 <RP__> JaMa: yes
Mar 12 10:36:32 <RP__> JaMa: I'm puzzled why it wouldn't use the sstate cache for the other gcc variants
Mar 12 12:38:22 <JaMa> RP__: after building meta-toolchain-gmae successfully and -e meta-toolchain-gmae I've saved stamps directory to stamps.before then called that -c unpack -f and here is diff of stamps:
Mar 12 12:38:26 <JaMa> OE qemux86-64@ ~/oe-core/tmp-eglibc $ diff -rq stamps.before/ stamps.after.unpack
Mar 12 12:38:27 <JaMa> Only in stamps.after.unpack/i686-nativesdk-oesdk-linux: gcc-cross-canadian-x86-64-4.6.3+svnr184847-r23.do_unpack.sigdata.14644ee6d8321eaf01e5b6466c9da43b
Mar 12 12:39:58 <JaMa> and now I've started "bitbake meta-toolchain-gmae" again and it failed again in gcc-cross-canadian-x86-64: /OE/oe-core/tmp-eglibc/sysroots/x86_64-linux/usr/libexec/i686-oesdk-linux/gcc/i686-oesdk-linux/4.6.4/ld: warning: library search path "/usr/lib/cmplrs/cc2.11" is unsafe for cross-compilation
Mar 12 12:40:14 <JaMa> no MACHINE switch involved now
Mar 12 12:42:46 <JaMa> and another diff between stamps dirs shows: http://pastebin.ca/2127301
Mar 12 12:48:53 <RP__> JaMa: so you're saying re-executing "bitbake meta-toolchain-gmae" caused it to rebuild cross-canadian?
Mar 12 12:50:36 <JaMa> re-executing it after -c unpack rebuilds every *gcc* and as bonus gcc-cross-canadian fails like this this time
Mar 12 12:52:23 <Crofton|work> bonus fetures, I like that
Mar 12 12:52:56 <JaMa> RP__: here is cooker log from that 2nd run http://pastebin.ca/2127303
Mar 12 12:53:01 <RP__> JaMa: rm_work or no rm_work?
Mar 12 12:53:17 <JaMa> no rm_work
Mar 12 12:53:26 <JaMa> oe-core + qemux86-64 only
Mar 12 12:53:47 <JaMa> rebuilt from scratch today
Mar 12 12:53:58 <JaMa> but this issue is there for few months
Mar 12 12:54:06 <RP__> JaMa: it does the same thing here. I'd guess that something in setscene isn't being as aggressive as it should and populating from sstate
Mar 12 12:54:35 <RP__> JaMa: I can see how it reaches the conclusion it does :/
Mar 12 12:54:38 <JaMa> could it be caused by meta-environment-x86-64-1.0-r7 ? see those stamps they look a bit weird
Mar 12 12:56:57 <RP__> JaMa: I just reproduced this without meta-environment at all
Mar 12 12:57:21 <RP__> JaMa: The trouble is the unpack stamp is shared by all gccs due to the shared-workdir
Mar 12 12:57:35 <RP__> JaMa: You touch it for one, it triggers them all to rebuild
Mar 12 12:58:02 <RP__> JaMa: What you might expect is that it would reuse sstate for the others
Mar 12 13:00:51 <JaMa> gtg
Mar 12 13:03:58 <RP__> JaMa: I'm seeing things like Stamp for underlying task 158(/media/data1/build1/poky/meta/recipes-devtools/gcc/gcc-runtime_4.6.bb, do_populate_sysroot) is current, so skipping setscene variant in the logs which blatantly isn't true
Mar 12 13:50:22 <bluelightning> otavio: hi, are you around?
Mar 12 13:50:49 <otavio> bluelightning: yes but leaving for 2hs
Mar 12 13:50:55 <otavio> bluelightning: i have phisiotherapie now
Mar 12 13:51:08 <bluelightning> otavio: ok, will talk to you when you get back
Mar 12 13:51:17 <otavio> bluelightning: ok, i ping you
Mar 12 13:51:22 <bluelightning> thanks
Mar 12 14:19:08 <RP__> JaMa: http://pastebin.com/pM7Pkg7p might help your issue
Mar 12 14:20:44 <JaMa> RP__: OK, thanks, will try
Mar 12 14:31:33 * JaMa just got another kind of build error :/ this time from gcc-crosssdk-initial gcc/as: line 87: exec: --: invalid option config.log http://pastebin.ca/2127338
Mar 12 14:43:36 <RP__> JaMa: sounds like as is somehow corrupted (which comes from binutils-cross) :/
Mar 12 14:44:25 <denisATeukrea> hi, in what lib can I find arm_memset16 and arm_memset32?
Mar 12 14:44:42 <denisATeukrea> I've looked in all the libs I have in sysroot with nm and none had it
Mar 12 14:45:27 <RP__> denisATeukrea: can't you use memset()? Those sound like internal stubs for particular optimised cases within libc
Mar 12 14:46:20 <denisATeukrea> I'm making a recipe for chromium and it uses theses, I'll look
Mar 12 14:50:20 <denisATeukrea> ah I found them
Mar 12 14:50:36 <denisATeukrea> it was in a dep of chromium in chromium sources
Mar 12 14:50:51 <RP__> JaMa: btw, the cross compile badness issue looks like we should set gcc_cv_collect2_libs to something to disable that
Mar 12 14:52:23 <JaMa> RP__: with your bitbake patch it didn't rebuild anything after "bitbake -c unpack -f gcc-cross-canadian-x86-64" http://paste.pocoo.org/show/564605/
Mar 12 14:53:31 <JaMa> RP__: and the LDCONFIG changed issue? is it possible that config.cache from armv4t build survived for armv7a build and it complains as it should?
Mar 12 14:54:01 <RP__> JaMa: It likley used cross-candian from sstate. Try bitbake -c cleansstate gcc-cross-canadian-x86-64
Mar 12 14:55:51 <JaMa> and that would be bug right? as gcc-cross-canadian-arm whould build after MACHINE switch too without manuall -c cleansstate
Mar 12 14:56:45 <RP__> JaMa: I suspect you either have sstate files or preexisting builds for these so no, I'm not seeing a bug with that unless I'm misunderstanding the situation
Mar 12 14:59:50 <JaMa> I'll try to reproduce on some simplified case to be more clear about situation
Mar 12 15:01:16 <RP__> JaMa: sounds good, thanks.
Mar 12 15:02:34 <JaMa> MACHINE=om-gta02; bitbake -k meta-toolchain-gmae; MACHINE=nokia900; bitbake -k meta-toolchain-gmae; # both build gcc-cross-canadian-arm now (maybe that's fixed by your last bitbake patch)
Mar 12 15:03:24 <JaMa> and if 2nd run (from nokia900) reuses sstate cached gcc-cross-canadian-arm (which is now invalid for nokia900) then it's bad
Mar 12 15:28:52 <otavio> bluelightning: ping
Mar 12 15:29:09 <bluelightning> otavio: hi, I think I got my answer already
Mar 12 15:29:48 <otavio> bluelightning: really? My mind is more powerful then I thought ;)
Mar 12 15:30:30 <otavio> bluelightning: was it about the udev?
Mar 12 15:30:41 <bluelightning> otavio: I'm fixing lzma not being available when the kernel config requests it for compressing the kernel image
Mar 12 15:30:51 <bluelightning> otavio: I was going to ask where you got the patches for lzma which you committed to OE-Classic a few years ago, but actually it turns out I can use xz rather than bringing in lzma from meta-oe into oe-core
Mar 12 15:31:14 <otavio> bluelightning: oh yeah; xz is way better for this now
Mar 12 15:31:24 <otavio> bluelightning: and it can generate lzma if need
Mar 12 15:38:54 <fray> FYI the hob issue was that a person in the class selected core-image-basic.  I then had them go back and select core-image-minimal and hit bake..  and it started to bake a bunch of things that were in core-image-basic
Mar 12 15:39:35 <fray> we canceled the bake, and went back to the edit screen and it said "core-image-minimal" and nothing obvious had been selected above and beyond core-image-minimal in the quick look I had..
Mar 12 15:50:48 <RP__> fray: hob is basically totally changed now in master...
Mar 12 15:53:01 <Zagor> whee, my first patch submitted. this calls for a cup of coffee! ;-)
Mar 12 15:55:17 <RP__> Zagor: pigz?
Mar 12 15:55:23 <Zagor> yes
Mar 12 15:56:05 <RP__> Zagor: need to go to the oe-core mailing list and needs an Upstream-Status: field in the patch
Mar 12 15:56:06 <bluelightning> RP__: fray: I think that issue may still be there... basically reselecting the base image does not clear the selections
Mar 12 15:56:08 <RP__> Zagor: looks good though :)
Mar 12 15:56:27 <RP__> bluelightning: if it is we should open a bug...
Mar 12 15:57:22 <Zagor> RP__: oh, ok. the dev-manual says meta/ patches should go to the poky list. maybe that needs a patch too? :)
Mar 12 15:57:25 <bluelightning> RP__: true; it's on a list I wrote down during the hob lab last week, I wanted to check with Belen if it was already discussed during the design review
Mar 12 15:57:55 <Zagor> http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#how-to-submit-a-change
Mar 12 15:59:13 <RP__> Zagor: quite likely, that was written before oe-core existed
Mar 12 16:23:58 <d4ny> Hi All, is there any way of having -nativesdk packages use x11 without x11 in DISTRO_FEATURES ? How is the separation done between target and native in this regard ?
Mar 12 16:31:03 <bluelightning> d4ny: currently I think we don't handle that very well; it'll probably need modifications to all nativesdk recipes that have a conditional on x11 such that nativesdk is unaffected
Mar 12 16:32:17 <d4ny> bluelightning: Thanks
Mar 12 16:42:50 <sgw> msm: Morning, do you keep your updated patches on a branch someplace accessible?
Mar 12 17:37:22 <RP__> d4ny: It should be possible to make that work but certainly currently it won't
Mar 12 17:48:33 <msm> sgw: hmm
Mar 12 17:48:39 <msm> sgw: which patches do I have pending?
Mar 12 17:50:16 <sgw> msm: I think you have an arch-ppc.inc (v2) and packagedata.py (v3)
Mar 12 17:50:18 <sgw> correct?
Mar 12 17:54:29 <RP__> I'm afraid I got nervous about the packagedata one. Sending three patches in short succession relegated that one to look at "later" :/
Mar 12 18:05:13 <msm> RP__: yea, that one was fun
Mar 12 18:05:42 <msm> v2 fixed the w/o multilib case
Mar 12 18:06:00 <msm> v3 fixed the fact that sometimes we replace '-' with '_'
Mar 12 18:06:12 <msm> other than that im not even sure if it's the exact right fix
Mar 12 18:06:33 <msm> but it's a pretty major fix - as far as being able to specify multlilib libraries
Mar 12 18:06:45 <msm> to be included in the install
Mar 12 18:13:32 <msm> sgw: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mattsm/misc_fixes
Mar 12 18:18:17 <fray> sgw: just got this: WARNING: QA Issue: non -staticdev package contains static .a library: python-distutils path '/work/i586-poky-linux/python-2.7.2-r0.7/packages-split/python-distutils/usr/lib/python2.7/config/libpython2.7.a'
Mar 12 18:18:35 <fray> did something change recently in python, I don't remember seeing that a week ago when I last built
Mar 12 18:22:27 <sgw> msm: thanks
Mar 12 18:23:36 <sgw> fray: we added the warning recently, maybe you did not notice it before.
Mar 12 18:29:06 <fray> no I've seen the warning on other things before (or so I thought?)  it's the message from python spcifically that seems to be new.. I thought libpython2.x.a was properly packaged before
Mar 12 18:29:35 <sgw> fray: I thought it was also
Mar 12 18:29:52 <fray> I'm building on a slightly different machine then I normally do..  so maybe thats the difference?
Mar 12 18:30:08 <fray> (we're in the process of moving offices, so my normal build machine is in a box somewhere)  ;)
Mar 12 18:30:23 <fray> ...hopefully to be unpacked on the 21st or 22nd.. ;)
Mar 12 18:30:35 <sgw> we should not have packaging difference on different machines.
Mar 12 18:30:40 <fray> agreed
Mar 12 18:31:06 <fray> but python has shown issues in the past for me on different hosts, and someone reported problems to the oe-core list last week?
Mar 12 18:31:27 <sgw> fray: checkout the package class change on email, wonder if that' related also!
Mar 12 18:31:46 <fray> I missed those....
Mar 12 18:33:00 <fray> FYI, the package_rpm.bbclass changes look fine..
Mar 12 18:33:23 <fray> about halfway through the archiver..  it's hard for me to speak about the python parts of this (i.e. style over function).. but so far it looks fine..
Mar 12 18:55:12 <fray> ya..  second half of the archiver I did have comments...
Mar 12 20:41:11 <zenlinux> I need to be able to create a relative symlink, but need to support allowing the base directories to be based on variables. Do we have any helper functions to help do this processing?
Mar 12 20:41:43 <zenlinux> e.g, I need to create a symlink from ${libdir} into ${base_libdir} and have the link work between our sysroot and target installations
Mar 12 20:42:45 <zenlinux> For example, I want to create a .so file in libdir as a symlink to the soname library in base_libdir
Mar 12 20:45:26 <RP__> zenlinux: I seem to remember we have such a function somewhere
Mar 12 20:45:50 <zenlinux> I was looking in relocatable.bbclass but don't think what I need is in there.
Mar 12 20:46:05 <RP__> zenlinux: sstate:     def make_relative_symlink(path, outputpath, d):
Mar 12 20:46:10 <RP__> sstate.bbclass
Mar 12 20:46:15 <zenlinux> RP__, nice, thanks!
Mar 12 20:46:33 <RP__> zenlinux: we might need to move that into lib/oe/
Mar 12 20:46:35 <kergoth> might be worth adding that to oe.path, next to relative()
Mar 12 20:46:39 <kergoth> :)
Mar 12 20:47:09 <zenlinux> I can probably include that in my eventual pull request
Mar 12 20:47:58 <RP__> zenlinux: there are some assumptions going on there about tmpdir but it should be adaptable to your needs :)
Mar 12 20:56:19 <zenlinux> basic hash is making iterative development more challenging - each time I make a change to ncurses, for example, it's rebuilding everything else that depends on ncurses automatically (as it was intended to do)
Mar 12 20:57:02 <zenlinux> thing is, I don't care to wait while the other packages get rebuilt over and over again...
Mar 12 20:57:38 <fray> if you do bitbake ncurses, it should -only- build ncurses..
Mar 12 20:57:50 <fray> if you do bitbake <image> then yes, it's going to keep rebuilding everything else
Mar 12 20:58:31 <zenlinux> that's not what I'm seeing, let me double check
Mar 12 20:59:32 <zenlinux> maybe the fact that ncurses-native is also changing is causing this - I'm seeing lots of native recipes being updated
Mar 12 20:59:42 <zenlinux> yeah, it's all natives
Mar 12 21:01:40 <zenlinux> rpm, libxml2, python....lots 'o rebuilds
Mar 12 21:07:18 <RP__> zenlinux: bitbake -b can help
Mar 12 21:08:24 <zenlinux> RP__, you're saving me boatloads of time - thank you
Mar 12 21:09:06 <RP__> zenlinux: np :)
Mar 12 21:09:44 <RP__> zenlinux: just be careful with -b, it will do no dependency resolution outside the recipe. In this case that is exactly what you want but in others it might not be
Mar 12 21:09:58 <zenlinux> right
Mar 12 21:13:36 <zenlinux> ok, now how do I invoke a python function within a shell step? I thought I could do some trickery with ${@func_name}, but this isn't parsing: ${@make_relative_symlink(${D}${libdir}/libtinfo.so, d)}
Mar 12 21:14:20 <RP__> zenlinux: the problem is that will get expanded before the shell runs
Mar 12 21:14:33 <RP__> zenlinux: once into shell context there is no way to get back to the python one :(
Mar 12 21:14:49 <zenlinux> uh-oh
Mar 12 21:15:35 <zenlinux> but I see what looks like python functions for populate_packages_prepend()?
Mar 12 21:15:46 <zenlinux> can I add a hook function after do_install?
Mar 12 21:16:03 <RP__> zenlinux: populate_packages is a python function
Mar 12 21:16:11 <RP__> zenlinux: which do_install is this?
Mar 12 21:16:27 <zenlinux> this is the do_install in ncurses.inc
Mar 12 21:16:37 <zenlinux> let me push my WIP, one sec
Mar 12 21:17:41 <zenlinux> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=sgarman/python-ncurses-fix
Mar 12 21:18:00 <RP__> zenlinux: I'd do something like:
Mar 12 21:18:00 <RP__> python do_install () {
Mar 12 21:18:00 <RP__>     bb.build.exec_func("shell_install", d)
Mar 12 21:18:00 <RP__>    my python bit
Mar 12 21:18:00 <RP__> }
Mar 12 21:18:29 <RP__> (renaming do_install to shell_install)
Mar 12 21:18:34 <zenlinux> ah
Mar 12 21:18:38 <zenlinux> seems like a lot of hackery
Mar 12 21:18:57 <zenlinux> but if I get it to work, I'll take feedback on it later
Mar 12 21:19:13 <RP__> zenlinux: well, I can't think of much that is simpler offhand
Mar 12 21:19:31 <zenlinux> and I don't want to reimplement that python function in bash/dash
Mar 12 21:20:56 <RP__> zenlinux: You could make it a separate script in scripts/
Mar 12 21:21:28 <zenlinux> that would probably be The Right Thing to Do, wouldn't it?
Mar 12 21:21:44 <RP__> zenlinux: I'm ok with either
Mar 12 21:22:13 * RP__ doesn't find the above function that scary but I've been staring at bitbake code too long
Mar 12 21:23:55 <zenlinux> ooh, there's a symlinks utility which actually does this
Mar 12 21:24:31 <zenlinux> it's not on my host system by default, though
Mar 12 21:24:34 <zenlinux> and it's a C utlity
Mar 12 21:25:02 <zenlinux> I'll go the python route, and if people complain, I'll suggest we make symlinks one of our build dependencies
Mar 12 21:25:10 <zenlinux> then we can do things easily in shell
Mar 12 21:30:40 <zenlinux> RP__, now I'm noticing the python install function isn't obeying the correct order. "addtask install after do_compile" makes no difference
Mar 12 21:31:51 <RP__> zenlinux: you shouldn't need to add any addtask
Mar 12 21:32:29 <zenlinux> also, defining a python do_install () function cases a parse error, so I named it install () instead
Mar 12 21:32:39 <kergoth> that would by why it isn't running
Mar 12 21:32:44 <kergoth> be, even
Mar 12 21:33:08 <RP__> zenlinux: tasks have a think about the do_ prefix
Mar 12 21:33:14 <zenlinux> but it is running, it's just the first task
Mar 12 21:33:15 <RP__> s/think/thing/
Mar 12 21:33:34 <zenlinux> could the -b option to bitbake be missing some of this logic?
Mar 12 21:33:42 <kergoth> RP__: i hate that inconsistency, the fact that hte first addtask arg implicitly adds do_.. too bad it's too late to improve it
Mar 12 21:33:45 <kergoth> heh
Mar 12 21:34:01 <RP__> kergoth: I know, I'm biting my tongue ;-)
Mar 12 21:34:07 <kergoth> :)
Mar 12 21:34:10 <RP__> zenlinux: I'd guess bitbake isn't figuring out the shell became python
Mar 12 21:35:25 <RP__> zenlinux: It shouldn't be -b related
Mar 12 21:35:56 <zenlinux> | NOTE: make -j 24 DESTDIR=/srv/home/sgarman/poky/build/tmp/work/x86_64-linux/ncurses-native-5.9-r5.1/image install
Mar 12 21:36:06 <zenlinux> it's running that before do_unpack is even run
Mar 12 21:36:37 <RP__> zenlinux: call it do_xxx all bets are off unless you do
Mar 12 21:37:21 <zenlinux> NOTE: Error expanding variable do_install
Mar 12 21:37:35 <RP__> zenlinux: ok, is that all the info?
Mar 12 21:37:53 <zenlinux> then it just says unable to parse the ncurses recipe filename
Mar 12 21:38:28 <RP__> zenlinux: can you paste the task definition somewhere?
Mar 12 21:39:20 <zenlinux> http://pastebin.com/z9gLRz5S
Mar 12 21:40:09 <RP__> zenlinux: make_relative_symlink(${D}${libdir}/libtinfo.so, d) is not going to work
Mar 12 21:40:19 <RP__> zenlinux: just remove that line for a minute and get that to work
Mar 12 21:40:53 <zenlinux> yeah, that was what caused the parsing error :-/
Mar 12 21:41:18 <RP__> zenlinux: you want something like make_relative_symlink(d.expand("${D}${libdir}/libtinfo.so"), d)
Mar 12 21:42:00 <zenlinux> so the parser won't make a first susbsitution pass on the python function?
Mar 12 21:42:05 <RP__> zenlinux: no
Mar 12 21:42:30 * zenlinux makes a note of that
Mar 12 21:42:30 <RP__> zenlinux: python functions have d available to them directly
Mar 12 21:43:06 <zenlinux> ok, now I'm back in business
Mar 12 22:13:52 <bkk> Hi, I have a recipe and trying to put some .so libraries into the image through FILES_${PN}, but I don't see them as part of image after I boot, and I even don't get warnings at the time of build about not shipped.  Any suggestions please?
Mar 12 22:16:44 <RP__> bkk: are you sure you added the package in question to the image?
Mar 12 22:19:04 <bkk> RP__:  FILES_${PN} += "${libdir}/xorg/modules/drivers/pvr_drv.so  and also have install -m 0755 -d ${D}${libdir}/xorg/modules/drivers
Mar 12 22:19:23 <bkk> I have those two lines, but it is not getting into the image.
Mar 12 22:19:57 <RP__> bkk: those ensure the files make in into the package. The question is whether that package is being installed into the image
Mar 12 22:20:41 <bkk> RP__: How do I make sure that package is being installed into the image?
Mar 12 22:21:13 <RP__> bkk: you could look at the do_rootfs logs from when it built, or examine the list of installed packages and see if its listed?
Mar 12 22:26:24 <ant__> RP__: look at this bb ascii-art ;)  http://imgbin.org/index.php?page=image&id=7114
Mar 12 22:26:48 <ant__> could not yet reproduce it (happily)
Mar 12 22:29:48 <RP__> ant__: nice :/
Mar 12 22:31:48 <bkk> RP__: I could see in ${WORKDIR}/package/ all the files.  Are you referring to this packages dir?  where are the do_rootfs logs located?
Mar 12 22:35:16 <RP__> bkk: tmp/work/*/*-image-*/temp/log.do_rootfs*
Mar 12 22:35:41 <RP__> bkk: I was not referring to the package dir, no
Mar 12 22:45:26 <bkk> RP__: log.do_rootfs does not list any of my .so libraries.
Mar 12 22:56:54 <sd__> Hello everybody.
Mar 12 22:57:29 <sd__> fast question: Is there an easy way to create a read only filesystem without modifying manually: udev, ssh....
Mar 12 22:57:33 <sd__> ?
Mar 12 22:57:37 <kergoth> bkk: nor should it. it'll show what *packages* are being installed, not the files
Mar 12 23:00:38 <bkk> kergoth:  Yeah, I don't see my packages being installed. How could make sure my packages go into the image?
Mar 12 23:00:59 <kergoth> that's what IMAGE_INSTALL is for. grep is your friend, or just read an image
Mar 12 23:01:03 <kergoth> recipe, that is
Mar 12 23:13:24 <bkk> kergoth:  Is it that even though the recipe gets built by bitbake, it may not be part of the final image if we do not add IMAGE_INSTALL for that recipe?
Mar 12 23:13:52 <kergoth> building an image doesn't mean what you built goes into an image
Mar 12 23:13:57 <kergoth> they're entirely separate
Mar 12 23:15:59 <bkk> Yeah, my recipe is being built, but only part of my files made into the  final image but not all of them which I needed.
Mar 12 23:17:09 <bkk> kergoth: There are few .so libraries which made it to the image and few .so libraries which did not go into the image.
Mar 13 00:32:34 <mranostay> kergoth: going to LC Summit?
**** ENDING LOGGING AT Tue Mar 13 02:59:58 2012

**** BEGIN LOGGING AT Tue Mar 13 02:59:58 2012
**** BEGIN LOGGING AT Tue Mar 13 09:48:19 2012
Mar 13 10:49:00 <sd__> hello
Mar 13 10:54:19 <sd__> I need to create a readonly filesystem. Is there any way to do it without hacking every recepie (ie, ssh...)
Mar 13 11:02:12 <RP__> sd__: We try and run as many of the postinstalls at rootfs generation time but some things like the ssh keys can't be done then
Mar 13 11:02:23 <RP__> sd__: You could always preboot the image under qemu?
Mar 13 11:02:59 <RP__> sd__: In general our readonly fs aren't too bad, there are just a handful of recipes which do write to the fs at first boot
Mar 13 11:07:42 <sd__> RP__: The preboot sounds like a very good idea.... but I am trying to squeeze out every cycle of my cpu and I have compiled everything for a set of instruction that it is not yet on qemu
Mar 13 11:09:13 <sd__> RP__: But to be honest, I havent tried it... so I could have a surprise :)
Mar 13 11:10:05 <sd__> Also.... do you know any recipe for the fglrx driver? (ATI/AMD cards)
Mar 13 11:35:11 <RP__> sd__: I'm not aware of one but I've never looked at whether OE-classic has anything
Mar 13 13:24:59 <JaMa> any vote for TUNEPKG_ARCH/PACKAGE_ARCH in SDK_NAME? we're 1:1 with msm on ML :)
Mar 13 14:35:53 <Zagor> is "Upstream-status: Pending" the proper tag for a patch that is not submitted?
Mar 13 14:37:04 <RP__> Zagor: yes, assuming it stands some change of being accepted
Mar 13 14:38:30 <Zagor> this concerns my $(LDFLAGS) patch in pigz. I'm not even sure if that's the proper solution.
Mar 13 14:38:51 <Zagor> it's a somewhat odd thing for upstream to add to his Makefile
Mar 13 14:41:24 <RP__> Zagor: It does look reasonable to me
Mar 13 14:41:43 <RP__> Zagor: Difficult to say whether upstream will take things like that or not
Mar 13 15:22:16 <dvhart> https://wiki.yoctoproject.org/wiki/Janitors
Mar 13 15:28:00 <halstead> dvhart I'll contact you to go over solutions shortly. ok?
Mar 13 15:28:30 <dvhart> halstead, yup, I'm free 9-10
Mar 13 15:45:39 <dvhart> halstead+++++
Mar 13 15:48:27 <sgw> bluelightning: you around?
Mar 13 15:48:37 <bluelightning> sgw: yes I'm on the call atm
Mar 13 15:48:45 <bluelightning> joined about 10mins in
Mar 13 15:49:50 <sgw> bluelightning: you heard RP__ on warnings, there seems to be a number of RPATH related warnings in the qt and directfb code, can you take those on?
Mar 13 15:50:04 <bluelightning> sgw: sure thing
Mar 13 15:51:05 <sgw> bluelightning: thanks
Mar 13 16:02:24 <dvhart> http://www.mediawiki.org/wiki/Extension:Bugzilla_Reports
Mar 13 16:02:27 <dvhart> halstead, ^
Mar 13 16:06:09 <Zagor> did I miss the technical team meeting? or is it in one hour?
Mar 13 16:06:17 <Zagor> dst is confusing :)
Mar 13 16:06:33 <halstead> Zagor, It just ended.
Mar 13 16:07:05 <Zagor> aw, bugger
Mar 13 16:10:48 <RP__> Zagor: Its horribly confusing
Mar 13 16:20:03 * incandescant spends the DST period every year being late for meetings
Mar 13 16:20:12 <incandescant> most software doesn't cope, either
Mar 13 16:44:27 * RP__ just ignores his electronic calender and goes from memory
Mar 13 17:02:49 <d4ny> RP__: Has anyone attempted to integrate paralell(https://savannah.gnu.org/projects/parallel/) with bitbake ?
Mar 13 17:03:55 <RP__> d4ny: no. Its the state required for a given command that is more of a problem than the remote execution
Mar 13 17:04:15 <RP__> d4ny: it if was just remote execution we'd have done it years ago
Mar 13 17:05:43 <d4ny> RP__: I'm not talking about remote, I'm talking about paralells ability to fork locally.
Mar 13 17:06:27 <RP__> d4ny: what benefit would it be locally?
Mar 13 17:07:46 <RP__> d4ny: Our multiple processes already gives as much parallelism as the metadata lets us
Mar 13 17:09:12 <d4ny> But only on a recipe/make level, no ?. making the bash more concurrent perhaps could be of use.
Mar 13 17:09:25 <d4ny> *bash scipts
Mar 13 17:09:39 <d4ny> aargh *scripts :)
Mar 13 17:10:29 <kergoth> no, bitbake schedules parallel on a task level
Mar 13 17:11:33 <RP__> d4ny: I'm not aware of any part of the build where we could run bash scripts in parallel
Mar 13 17:11:46 <RP__> not for any meaningful performance gain anyway
Mar 13 17:12:23 <d4ny> ok, point taken :)
Mar 13 17:18:01 <bluelightning> dvhart: ping
Mar 13 18:05:16 <dvhart> bluelightning, pong
Mar 13 18:06:07 <bluelightning> dvhart: hi, re bug 1728, which patches were you referring to in meta-oe?
Mar 13 18:06:13 <bluelightning> https://bugzilla.yoctoproject.org/show_bug.cgi?id=1728
Mar 13 18:06:50 <dvhart> good question...
Mar 13 18:06:53 * dvhart checks
Mar 13 18:07:27 <bluelightning> in any case, I looked into the mechanics of it, the tricky bit seems to be determining when it should be needed since we need to look at the kernel config for that, is that correct?
Mar 13 18:08:25 <dvhart> bluelightning, yes
Mar 13 18:08:34 <dvhart> I think we should just make linux-yocto-tiny depend on lzma
Mar 13 18:09:00 <bluelightning> it would be xz-native, but yes that would be simpler
Mar 13 18:09:07 <dvhart> bluelightning, I believe I was referring to oe/recipes/lzma/lzma_4.65.bb
Mar 13 18:09:17 <bluelightning> ah, I thought so
Mar 13 18:09:18 <dvhart> but perhaps that wasn't the right thing
Mar 13 18:09:46 <bluelightning> xz-native can do lzma compression, it even provides an "lzma" command symlink
Mar 13 18:09:56 <bluelightning> and we already have it in oe-core :)
Mar 13 18:10:11 <dvhart> perfect
Mar 13 18:10:32 <bluelightning> ok, I'll put together a patch
Mar 13 18:21:19 <otavio> is there any known problem in using runqemu-export-rootfs to export the rootfs to be used by a real hw?
Mar 13 18:25:42 <fray> you should be able to export the the rootfs via NFS to real hardware (when using the Yocto Project kernel)
Mar 13 18:25:53 <fray> there are NFS patches that allow for RPC operations on non-privileged ports
Mar 13 18:26:55 <otavio> ahhhhhhhhhh
Mar 13 18:27:18 <fray> you also need to pass the right options into the kernel to tell it what ports to use....
Mar 13 18:27:48 <otavio> yes yes
Mar 13 18:28:12 <otavio> fray: do you know the patch that allows it? I'd be willing to port it to my imx board
Mar 13 18:29:04 <fray> it'd be a single commit, but I don't know it off hand..
Mar 13 18:30:13 <fray> zeddii, do you know the patch for the Yocto kernel that enables support for the unprivileged NFS/RPC ports (nfs booting)?
Mar 13 18:30:39 <zeddii> it's in the tree :)
Mar 13 18:30:51 <zeddii> but it isn't even required for the latest kernels.
Mar 13 18:30:52 <fray> ya, but where.. :P  otavio is interesting in it by itself..
Mar 13 18:30:58 <fray> "how recent"?
Mar 13 18:31:12 <zeddii> like I said. it's in the tree. that's a git whatchanged hint :P
Mar 13 18:31:13 <otavio> zeddii: i need it to 2.6.35 (yes, that old)
Mar 13 18:31:30 <fray> zeddii, I'm searching and can't find the commit.. so far
Mar 13 18:31:33 <zeddii> I can track it down.
Mar 13 18:31:59 <otavio> zeddii: if you can point it to me, it will be awesome
Mar 13 18:32:11 <zeddii> I'm just in the middle of something. give me a couple of minutes to extract myself.
Mar 13 18:32:39 <zeddii> http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.0/tree/meta/cfg/kernel-cache/patches/boot/NFS-allow-nfs-root-mount-to-use-alternate-rpc-ports.patch?h=meta
Mar 13 18:33:53 <otavio> zeddii: thanks a lot :)
Mar 13 18:34:33 <zeddii> if you have any yocto kernel clone handy, just dump it from the standard/base branch
Mar 13 18:34:38 <zeddii> if that's your thing :)
Mar 13 18:34:41 <zeddii> back to debugging
Mar 13 18:35:47 <fray> thanx
Mar 13 19:03:12 <fray> ....it's still building....
Mar 13 19:23:29 <bluelightning> dvhart: does ncurses build for you with poky-tiny? I'm getting a failure at do_install
Mar 13 19:39:31 <dvhart> bluelightning, it does
Mar 13 19:39:46 <dvhart> bluelightning, I had to disable ENABLE_WCHAR, but that change is in poky
Mar 13 19:39:52 <dvhart> bluelightning, how is it failing for you?
Mar 13 20:42:13 <JaMa> any vote for TUNEPKG_ARCH/PACKAGE_ARCH in SDK_NAME? we're 1:1 with msm on ML :)
Mar 13 20:42:27 <fray> I'm not opposed to it..
Mar 13 20:42:36 <fray> but I havn't used the SDK enough to have a clear opinion..
Mar 13 20:43:37 <JaMa> we need to change it for sure, but which of those two do you prefer?
Mar 13 20:44:55 <JaMa> msm wanted TUNEPKG_ARCH but wasn't sure if it's right in generic case and I don't care which one from those 2
Mar 13 20:46:52 <msm> TUNEPKG_ARCH!!
Mar 13 20:47:01 <msm> hehe, im not really sure what the right choice is either
Mar 13 20:49:01 <fray> I'm looking.. still don't have an opinion.. just a sec
Mar 13 20:50:55 <fray> Hmm.. ok, I'm confusing myself..
Mar 13 20:51:18 <fray> the SDK is for an optimized target, not a generic target..  so you want to list the "most optimized" member in the name -- (my assumption) that would then be the machine
Mar 13 20:51:57 <fray> so MACHINE_ARCH is the most optimized.. PACKAGE_ARCH is the standard package architecture type fo rthe machine.. and TUNE_PKGARCH is the tuning currently in member..
Mar 13 20:52:12 <fray> PACKAGE_EXTRA_ARCHS is all extra "compatible" archs..
Mar 13 20:52:25 <fray> and PACKAGE_ARCHS is all of the architectures supported (including all, any and noarch)
Mar 13 20:52:52 <fray> by default PACKAGE_ARCH and TUNE_PKGARCH are teh same BTW..
Mar 13 20:53:19 <fray> I believe it was done this way to allow for a machine to change the default setitng of PACKAGE_ARCH (or maybe it was for a recipe to do so)
Mar 13 20:54:19 <fray> but anyway.. MACHINE_ARCH/PACKAGE_ARCH/TUNE_PKGARCH in that order is most specific to least..
Mar 13 20:54:32 <JaMa> MACHINE_ARCH is most accurate, but those changes are usually only in stuff which is not important for SDK users (like fstab from base-files)
Mar 13 20:54:47 <fray> correct...
Mar 13 20:55:08 <JaMa> and having 5 SDK images ie for (palmpre palmpre2 crespo nokia900 om-gta04) where all 5 are just armv7a machines
Mar 13 20:55:14 <fray> so the tradeoff then is you are getting and SDK with machine specific components but it's not identified as such.. I'm not sure if thats good or not
Mar 13 20:55:32 <JaMa> will confuse people which are downloading SDK image just to get toolchain for building armv7a
Mar 13 20:55:49 <fray> toolchain is different though then a traditional SDK
Mar 13 20:56:01 <JaMa> now you don't even see if it's from armv7a or armv4t
Mar 13 20:56:19 <fray> if we back up a sec and I talk simply about Wind River Linux (not OE based) our naming is generic and it's up to the end use to use a unique name for their particular organization..
Mar 13 20:56:28 <fray> that way they can name it after a specific machine, or SOC, or....
Mar 13 20:56:45 <fray> we did that intentionally because no one answer was right for everyone (in our case)
Mar 13 20:57:37 <JaMa> here you can see diff between SDK image for 2 typical armv7a machines http://build.shr-project.org/shr-core/sdk/diff
Mar 13 20:58:50 <kb> Hi,  Can we compile any kernel driver on the target that is booted with sdk Image?
Mar 13 20:58:50 <JaMa> so 99% is just not important diff from package manager
Mar 13 20:59:17 <fray> I suspect if I was to create an SDK that worked across multiple machines, I'd probably generate a "meta" machine to encapsulate the generic bits..
Mar 13 20:59:22 <JaMa> and if there is MACHINE_ARCH in SDK name, then user would expect to find SDK image for his concrete machine (in sdk directory)
Mar 13 20:59:24 <fray> distribute it based on the meta machine..
Mar 13 20:59:43 <JaMa> and I would hate to spend 4 hours of buildtime just to recreate 99% the same images
Mar 13 20:59:57 <fray> well, with the sstate cache, you shouldn't have to.. ;)
Mar 13 21:00:23 <JaMa> it takes almost 4 hours just for package-indexes..
Mar 13 21:00:31 <kb> Does the sdk Image has the configured kernel sources so that any kernel module can be compiled on that booted sdk Image?
Mar 13 21:00:38 <JaMa> with all sysroots already populated..
Mar 13 21:00:51 <fray> (fundamentally though I think this points out a flaw in the machine naming...  for machines with a common architecture, etc..  having a way to build for that common architecture as an SDK/ADT is really the right answer.. then when you construct the machine you add the simple bits..
Mar 13 21:01:02 <fray> kb, not yet.. it's something being discussed..
Mar 13 21:01:59 <fray> for a single lib system, the PACKAGE_ARCH is probably the right name.. but for a multilib config.. I'm not sure it is.. since there are multiple package architectures avaialble..
Mar 13 21:02:45 * JaMa has no experience with multilib+oe
Mar 13 21:03:19 <fray> in my mind -- an SDK/ADT for a SOC/architecture is usually single ABI..
Mar 13 21:03:23 <kb> thanks fray.
Mar 13 21:03:31 <fray> an SDK/ADT for a "machine" may be multiple ABI..
Mar 13 21:03:46 <fray> difference being one is generic (at some level) and one is very specific..
Mar 13 21:04:00 <fray> we don't have any way to capture or document this today.. and that might be the real underlying issue
Mar 13 21:04:53 <fray> (I know this doesn't directly answer the question... point I'm trying to make is, I'm not against making the name more specific to the contents.. but I'm still not sure what contents to refer to..)
Mar 13 21:06:07 <JaMa> from my POV those machine specific bits are there just because it's more difficult to provide some "generic" base-files/.. for given PACKAGE_ARCH/TUNE_PKGARCH
Mar 13 21:06:48 <fray> with a common "meta" machine (SOC/archicture configuration).. it would be possible to provide them in a more generic fashion..
Mar 13 21:07:07 <JaMa> and question for msm is: are there TUNE_PKGARCH specific bits you have to mark in SDK image name?
Mar 13 21:07:08 <fray> as you can already tell, the files, in general, are textual and won't be used by compiling/linking anwyay..
Mar 13 21:08:23 <JaMa> yes but who would maintain such "meta" machines, is it worth it to maintain them in oe-core?
Mar 13 21:08:37 <msm> our TUNEPKG_ARCH is more specific than PACKAGE_ARCH
Mar 13 21:08:44 <fray> the only thing I can think of is to make these meta machines a part of the existing tuning infrastructure..
Mar 13 21:08:52 <fray> so you can say my machine is an arm7a for instance..
Mar 13 21:09:04 <fray> (it would know not to produce a bootable kernel for example)
Mar 13 21:09:08 <JaMa> msm: do those ppc variants have different toolchain for instance?
Mar 13 21:09:10 <msm> JaMa: Other than the name? I'm not sure what the actual differences are
Mar 13 21:09:13 <fray> as of right now.. this is all theoretical of course..
Mar 13 21:09:29 <fray> are there any cases where PACKAGE_ARCH and TUNE_PKGARCH are different?
Mar 13 21:09:36 <fray> if not, then my vote is on PACKAGE_ARCH
Mar 13 21:09:36 <JaMa> msm: try to build 2 sdk images like me and diff them :)
Mar 13 21:09:41 <msm> JaMa: I believe so - ppce5500 would not be the same as ppce500mc
Mar 13 21:10:07 <msm> you *could* compile one TUNEPKG_ARCH with different patches
Mar 13 21:10:22 <msm> so its feasibly that it's explictly dependent on that
Mar 13 21:10:37 <msm> this becomes less important if we can generate a multilib SDK toolchain
Mar 13 21:10:40 <JaMa> msm: so it has own "cross" bindir like e.g. sysroots/x86_64-linux/usr/bin/armv4t-oe-linux-gnueabi ?
Mar 13 21:12:21 <msm> yes
Mar 13 21:12:25 <msm> sysroot/ppce500v2
Mar 13 21:12:30 <msm> sysroot/ppce5500
Mar 13 21:12:33 <msm> sysroot/ppce500mc
Mar 13 21:12:43 <msm> with slightly tweaked compiler settings
Mar 13 21:12:48 <msm> so the libraries included could be incompatible
Mar 13 21:12:57 <msm> however, the compiler could theoretically generate code
Mar 13 21:12:58 <JaMa> not own sysroot which is MACHINE, I mean that dir in native sysroot
Mar 13 21:13:02 <bluelightning> dvhart: it fails because some code in do_install is trying to find libncursesw.so and can't
Mar 13 21:13:53 <JaMa> msm: do you have sysroots/x86_64-linux/usr/bin/ppce500v2-oe-linux-gnueabi and sysroots/x86_64-linux/usr/bin/ppce500mc-oe-linux-gnueabi ?
Mar 13 21:14:05 <dvhart> bluelightning, sounds like it is ignore the ENABLE_WIDEC="false" to me
Mar 13 21:16:03 <bluelightning> dvhart: there's a line "mv ${D}${libdir}/libncursesw.so.* ${D}${base_libdir}" that appears not to be conditional upon ENABLE_WIDEC
Mar 13 21:16:10 <msm> JaMa: yes
Mar 13 21:16:13 <bluelightning> dvhart: unless I've misunderstood the script
Mar 13 21:16:16 <dvhart> bluelightning, is that new?
Mar 13 21:16:55 <bluelightning> dvhart: march 9, so yes
Mar 13 21:17:06 <bluelightning> so I guess it's recent breakage
Mar 13 21:17:06 <dvhart> yup, that's the problem then
Mar 13 21:17:20 <bluelightning> ok, I'll see if I can fix that as well
Mar 13 21:17:28 <dvhart> that should be conditional on ENABLE_WIDEC - or just ignore the mv failure if it doesn't exist
Mar 13 21:17:35 <dvhart> the former is probably better
Mar 13 21:17:39 <dvhart> IMHO
Mar 13 21:17:53 <bluelightning> yes, I'll do the former
Mar 13 21:22:31 <msm> how does one add an existing patch with quilt?
Mar 13 21:22:52 <RP__> msm: quilt import ?
Mar 13 21:23:44 <msm> ah
Mar 13 21:28:11 <dvhart> I think I'm seeing a race between trying to mount the rootfs and trying to load firmware for a kernel driver
Mar 13 21:28:28 <dvhart> I'm not seeing where we mount the FS though in relation to the connman script
Mar 13 21:28:32 <dvhart> anyone know off hand?
Mar 13 21:30:17 <msm> how can you know to load the FW driver if you have not mounted the rfs?
Mar 13 21:30:27 <msm> or is the FW built into the kernel?
Mar 13 21:30:36 <dvhart> the driver is built into the kernel
Mar 13 21:30:39 <dvhart> but... hrm
Mar 13 21:30:46 <dvhart> yeah, that doesn't make sense
Mar 13 21:30:58 <dvhart> so for some reason it isn't finding the firmware files, despite them being there
Mar 13 21:31:34 <JaMa> msm: ok I'll send v2 :)
**** BEGIN LOGGING AT Tue Mar 13 22:04:38 2012
Mar 13 23:12:54 <kb> Hi, what does this xz-native do ? DEPENDS = "xz-native"
Mar 13 23:21:51 <RP__> kb: its a compression utility
Mar 13 23:24:34 <kb> RP__:  Is it doing the similar, when compared to tar, zip, rpm?
Mar 13 23:25:23 <RP__> kb: kind of, those things are a mixture. Its like zip, gz, bzip2
**** BEGIN LOGGING AT Wed Mar 14 00:54:06 2012
Mar 14 01:16:21 <andy1234> hi!  Is anyone there?
Mar 14 01:16:49 <andy1234> Boy I don't come in here much because it's a pretty slow chat room
Mar 14 01:18:14 <andy1234> but I'm strugglen!  I FINALLY got my image to build with java added in.  So now i've got it booted but for the life of me I can't get the OS to think "java" is an available executable! ahhH!
Mar 14 01:20:12 <andy1234> I've been trying to get my image to think java is there for the past 3 hours!  the image has the folders /usr/java AND /usr/jdk1.7.0_02 but I just simply can't get "java -version" to give me anything! AHH!!!
Mar 14 01:20:14 <andy1234> hahaha...
Mar 14 01:22:03 <andy1234> god I'm a noob... why is this soooo hard?  maybe cuz i'm only 25 and don't have the l33t git hax required to work with Yocto
Mar 14 01:23:26 <andy1234> seriously you all are my last hope
Mar 14 01:25:12 <andy1234> lol I can even do "tab tab" on my embedded system and "java" and "javac" show up as available programs.  but "java -version" does nothing.
Mar 14 01:26:36 <andy1234> i keep getting "-sh: /usr/jdk1.7.0_02/bin/java: No such file or directory"  but it's there!
Mar 14 01:28:03 <andy1234> k well i'm going to go play soccer for a while and blow off some steam.  If anyone wanted to give me some advice it would be just so great :)
Mar 14 02:04:43 <msm1> oprofile is failing because of libz.la being missing
Mar 14 02:05:00 <msm1> seems like this issue was addressed
Mar 14 02:05:07 <msm1> this is occuring in a from scratch build too
**** ENDING LOGGING AT Wed Mar 14 02:59:58 2012

**** BEGIN LOGGING AT Wed Mar 14 02:59:58 2012
Mar 14 08:28:03 <bluelightning> morning all
Mar 14 08:29:03 <Zagor> morning!
Mar 14 08:42:21 <JaMa> sgw1: ping
Mar 14 08:45:09 <JaMa> nvm I've replied on list
Mar 14 09:11:15 <mckoan> good morning
Mar 14 16:18:21 <zenlinux> Regarding the ncurses PR bump, PR is set to ${INC_PR}.1 in ncurses_5.9.bb, and I had updated INC_PR in ncurses.inc. Was this incorrect?
Mar 14 16:19:37 <zenlinux> Or maybe koen thought there was no PR bump because Paul's change got into master overnight and I need to increment INC_PR again before the commit gets in
Mar 14 16:19:38 <JaMa> should be fined if you've increased INC_PR
Mar 14 16:19:53 <zenlinux> ok, just making sure
Mar 14 16:20:05 <JaMa> yes every change should have own PR bump
Mar 14 16:39:24 <JaMa> zenlinux: ah now when reading his reply I guess he meant, that it's missing PR bump in other recipes which are influenced by this ncurses change
Mar 14 16:40:26 <zenlinux> JaMa, that would be several dozen recipes, I'm sure. I thought the basic_hash change to bitbake would fix this? Or are we only doing that in Poky?
Mar 14 16:41:36 <JaMa> zenlinux: no, apps built without this fix will have ncurses in runtime depends and without PR bump in those apps they won't pull e.g libncursesw to target if user does "opkg upgrade" or equivalent
Mar 14 16:42:35 <JaMa> and basichash won't fix stuff on target device.. it will only rebuild it in your build directory as long as PRSERV is not used (which isn't now)
Mar 14 16:42:48 <zenlinux> JaMa, ouch. So should finding all recipes which DEPEND on ncurses and give them PR bumps be sufficient?
Mar 14 16:43:36 <JaMa> yes
Mar 14 16:43:43 <zenlinux> ok, I'm on that
Mar 14 16:44:55 <JaMa> well in this case it wasn't broken for long time, so it's problem only for people who git pulled and e.g. built from scratch
Mar 14 16:45:16 <JaMa> but still that's very likely what he meant
Mar 14 16:49:55 <JaMa> zenlinux: and you haven't replied on my comment about do_split_packages
Mar 14 16:50:17 <zenlinux> JaMa, just sent out the mail on that seconds ago! :)
Mar 14 16:50:18 <JaMa> ah now you did :)
Mar 14 16:51:38 <JaMa> hmm I think you misunderstood me.. do_split_packages should work with base_libdir if you call it with base_libdir (now it's called only for libdir)
Mar 14 16:53:24 <zenlinux> oh, I see it's actually getting explicitly called in some recipes - I thought it was only used in the logic of a bitbake packaging class
Mar 14 16:53:28 <JaMa> so you can add just 1 line to .inc instead of 18
Mar 14 16:53:52 <zenlinux> JaMa, thanks for your patience in pointing these things out to me. I will give this a try.
Mar 14 16:54:15 <JaMa> e.g. kernel.bbclass does it for you.. but in most cases it's explicit in recipe
Mar 14 17:21:44 <GNUtoo> hi khem
Mar 14 17:21:48 <GNUtoo> I've that:
Mar 14 17:22:14 <GNUtoo> NOTE: package eglibc-initial-2.12-r28: task do_configure: Failed which is caused by that: | configure: error: compiler support for __thread is required which seem to be caused by that: | checking for ARM TLS support... no
Mar 14 17:22:45 <JaMa> check config.log if it's really the cause
Mar 14 17:22:55 <GNUtoo> I've rmed the tmpdir + sstate 3 times and it still doesn't fix it and my BBTHREADS are -j9 + 1 BBTHREAD
Mar 14 17:23:00 <GNUtoo> ok
Mar 14 17:23:13 <JaMa> sometimes there is error about missing lib or something which just makes this check failing like this
Mar 14 17:25:47 <GNUtoo> hmmm yes you're right I should have checked that
Mar 14 17:25:48 <GNUtoo> Fatal error: Invalid -march= option: `armv7-a'
Mar 14 17:26:18 <fray> I believe it's -mcpu=
Mar 14 17:26:21 <fray> or -mtune=
Mar 14 17:26:40 <GNUtoo> yes I must look from where that comes from
Mar 14 17:27:59 <GNUtoo> it's with angstrom
Mar 14 17:28:31 <JaMa> -march=armv7-a is valid so something is wrong with gcc it's using
Mar 14 17:28:45 <fray> ahh.... 'k
Mar 14 17:29:20 <GNUtoo> indeed
Mar 14 17:29:27 <GNUtoo> man gcc says it's valid
Mar 14 17:30:03 <GNUtoo> ahh I remember something vaguely
Mar 14 17:30:08 <GNUtoo> maybe my sourcedir is unclean
Mar 14 17:30:13 <GNUtoo> I'll clean that too
Mar 14 19:06:08 <dvhart> halstead, poke
Mar 14 19:06:29 <dvhart> halstead, any thoughts on creating a "Yocto Janitors" user that we can assign all "janitors" bugs to?
Mar 14 19:06:57 <dvhart> halstead, is there a mechanism whereby we can automatically update the assignee for bugs as they enter severity==janitors?
Mar 14 19:09:29 <fray> whee.. someone at the local phone company "did the wrong thing" and took the internet down for the whole town for about 15 minutes.. :P
Mar 14 19:25:16 <ka6sox> "oops, what does this plug do?"
Mar 14 19:27:04 <dvhart> fray, can you say "fired"
Mar 14 19:27:30 <fray> it was some outside tech..  the owner of the phone company was not amused
Mar 14 19:27:48 <fray> (small town -- we call up the phone company, and the owner answers)  ;)
Mar 14 19:33:59 <khem> GNUtoo: that error means gcc-initial did not find binutils-cross
Mar 14 19:34:24 <khem> GNUtoo: see if symlinks are ok
Mar 14 19:37:03 <khem> gcc-cross-initial creates some symlinks to binutils
Mar 14 19:37:19 <khem> they should be intact for it to work
Mar 14 19:38:07 <JaMa> khem: any new hint about that binutils+gold+armv4t issue? FWIW I've tried to revert last thumb related patch in binutils and it didn't change anything
Mar 14 19:38:47 <JaMa> khem: but as I cannot confirm that armv4t ever worked with gold I didn't downgrade any further to bisect that
Mar 14 19:42:16 <khem> JaMa: havent had a change to look at it sorry so far
Mar 14 19:42:31 <khem> you can for now disable gold for armv4 and armv4t
Mar 14 19:42:41 <khem> as a workaround
Mar 14 19:45:01 <JaMa> I did 23 Feb already :)
Mar 14 19:49:51 <GNUtoo> ok
Mar 14 19:49:54 <GNUtoo> Fatal error: Invalid -march= option: `armv7-a' still
Mar 14 19:49:57 <GNUtoo> I'll look
Mar 14 19:51:14 <JaMa> GNUtoo: there was patch about gcc symlinks which was reverted later today, do you have latest master?
Mar 14 19:51:22 <GNUtoo> yes
Mar 14 19:51:27 <GNUtoo> I do have lastest master
Mar 14 19:57:32 <GNUtoo> what files should I look for exactly?
Mar 14 20:12:21 <GNUtoo> in sysroots/x86_64-linux/usr/libexec/armv7a-angstrom-linux-gnueabi.gcc-cross-initial/gcc/arm-angstrom-linux-gnueabi/4.5.4 I've no symlinks
Mar 14 20:29:11 <halstead> dvhart, I can add a Yocto Janitors user and I bet it wouldn't be too complex to auto assign new bugs with that severity to the user.
Mar 14 20:30:58 <GNUtoo> khem, where should the symlink be located?
Mar 14 20:31:30 <msm> what's the best way to handle a inproper lib.la  file?
Mar 14 20:31:39 <msm> just use sed to fixup hard coded paths?
Mar 14 20:31:44 <msm> or just delete it?
Mar 14 20:31:45 <msm> or what?
Mar 14 20:37:22 <GNUtoo> msm, I think you should ship it in ${PN}-dev
Mar 14 20:37:48 <GNUtoo> but to be sure loop in bitbake.conf for FILES_${PN}-dev definition
Mar 14 20:38:07 <GNUtoo> .la is libtool archive
Mar 14 20:38:26 <GNUtoo> it also needs to go in sysroot
Mar 14 20:38:31 <kergoth> .la's are pretty worhtless nowadays
Mar 14 20:38:40 <kergoth> we've often discussed potentially removing htem all
Mar 14 20:38:45 <GNUtoo> ah?
Mar 14 20:38:55 <GNUtoo> on target or in sysroot?
Mar 14 20:39:19 <kergoth> khem would know the state of this concept
Mar 14 20:39:24 <GNUtoo> ok
Mar 14 20:39:27 <kergoth> they aren't needed in either, really
Mar 14 20:39:34 <GNUtoo> ok
Mar 14 20:39:43 <GNUtoo> because of stuff like pkgconfig and such?
Mar 14 20:39:52 <msm> ok
Mar 14 20:39:59 <msm> let's go with am rm -rf for a quick solution
Mar 14 21:04:22 <dvhart> halstead, great. halstead, also, a way to watch all janitors bugs would be nice. I think we use special users which users watch for this. So this same user could be used for both I would think.
Mar 14 21:04:56 <dvhart> I've used bugzillas with more advanced watchlist functionality - any chance something like that came with the recent upgrade?
Mar 14 21:05:43 <halstead> dvhart, Not sure I understand,  special users which users watch for this.
Mar 14 21:06:19 <dvhart> yeah, so if you want to watch a component, you have to watch a particular user which is CC'd on all bugs of that component
Mar 14 21:07:07 <dvhart> yp.kernel.watcher@fake.user for example
Mar 14 21:07:10 <dvhart> to watch all kernel bugs
Mar 14 21:07:30 <halstead> Ok.
Mar 14 21:07:50 <dvhart> (which feels like a horrible hack - but whatever :-)
Mar 14 21:08:01 <halstead> I see how to do that for component but not by severity.
Mar 14 21:08:08 <dvhart> Trying not to boil the ocean with this :-)
Mar 14 21:37:00 <dvhart> halstead, btw, how did the bugzilla-report plugin experiment go?
Mar 14 21:37:35 <halstead> dvhart, Still in progress. Should work fine though.
Mar 14 21:37:43 <dvhart> cool!
Mar 14 21:50:29 <GNUtoo> ah I found the patch
Mar 14 21:50:49 <GNUtoo> I guess it won't work
Mar 14 21:50:58 <GNUtoo> but I'll try the same
Mar 14 22:03:13 * halstead runs to fetch hardware.
Mar 14 22:20:35 <dvhart> halstead++
Mar 14 22:20:59 <dvhart> yocti: karma halstead
Mar 14 22:21:00 <yocti> dvhart: halstead has neutral karma.
Mar 14 22:21:09 <dvhart> yocti: halstead++
Mar 14 22:21:13 <dvhart> yocti: karma halstead
Mar 14 22:21:13 <yocti> dvhart: Karma for "halstead" has been increased 1 time and decreased 0 times for a total karma of 1.
Mar 14 22:21:21 <dvhart> \o/
Mar 14 22:21:49 <dvhart> bots make me smile
Mar 14 22:22:41 <halstead> I suppose you have to address it at the moment. There is a way to make ++ -- recognized without addressing the bot. I'll have to find that.
Mar 14 22:22:55 <dvhart> awesome
Mar 14 22:57:19 <OneKBogomips> I am tring to generate an ext2.gz.u-boot for a freescale machine. All I end up with is a broken link. I added ext2.gz.u-boot to IMAGE_FSTYPES in my local.conf file.
Mar 14 22:58:20 <OneKBogomips> Any tips would be much appriciated. And I am new to Yocto so I am guessing I am just doing something wrong.
Mar 15 00:22:06 <khem> msm: yes delete them you wont regret
Mar 15 00:22:45 <khem> msm: I have some rudimentary work where atleast a given la file will not reference another la file
Mar 15 00:22:56 <khem> thats step 1 in its removal
Mar 15 00:31:54 <msm> khem: removing worked out for me
Mar 15 00:32:21 <msm> khem: i wonder why my toolchain modifications resulted in this new incompatible libbfd.la file? perhaps some local patch I dropped or upstream fix
Mar 15 00:36:33 <khem> msm: hmm
Mar 15 00:36:55 <khem> msm: did u change binutils ?
Mar 15 00:37:47 <khem> since we do not reconfigure toolchains means we dont get libtool 2.4 compatible macros which use sysroot
Mar 15 00:38:02 <khem> so .la from toolchain bits are a bit iffy imo
Mar 15 00:38:13 <khem> that includes libstdc++ and friends too
Mar 15 00:38:29 <khem> .la do more harm in cross env than they help
Mar 15 00:41:11 <msm> khem: we changed the patches
Mar 15 00:41:18 <msm> khem: version should be the same
Mar 15 00:41:33 <khem> I have to look through your changes to see what could have done it
Mar 15 00:41:36 <khem> hard to say
Mar 15 02:01:38 <msm> khem: not im getting issues again
Mar 15 02:01:41 <msm> so much for knowing what im doing
Mar 15 02:02:16 <msm> its trying to link the host libz in now
**** ENDING LOGGING AT Thu Mar 15 02:59:58 2012

**** BEGIN LOGGING AT Thu Mar 15 02:59:58 2012
Mar 15 10:26:17 <bluelightning> morning all
Mar 15 10:27:18 <RP__> hi bluelightning
Mar 15 10:27:38 <Zagor> ehlo
Mar 15 12:41:00 <zenlinux> good morning yocti
Mar 15 12:41:21 <zenlinux> yocti: good morning
Mar 15 12:41:21 <yocti> zenlinux: Error: "good" is not a valid command.
Mar 15 12:41:31 <zenlinux> yocti: make me breakfast
Mar 15 12:41:31 <yocti> zenlinux: Error: "make" is not a valid command.
Mar 15 12:41:36 <zenlinux> yocti: sudo make me breakfast
Mar 15 12:41:36 <yocti> zenlinux: Error: "sudo" is not a valid command.
Mar 15 12:41:45 <zenlinux> damn :(
Mar 15 13:27:30 <RP__> yocti: quotes random
Mar 15 13:27:30 <yocti> RP__: Error: "quotes" is not a valid command.
Mar 15 13:27:50 <RP__> yocti: quote random
Mar 15 13:27:51 <yocti> RP__: Error: "quote" is not a valid command.
Mar 15 13:28:57 * RP__ wonders who yocti belongs to
Mar 15 13:32:30 <JaMa> RP__: hi.. just wanted to confirm that PATCHv3 of sgw's qt4 QA WARNING fix is ok and tested
Mar 15 13:33:01 <RP__> JaMa: ok, cool, thanks. I should merge that
Mar 15 14:26:01 <ag> Hello.
Mar 15 14:26:19 <ag> Can anybody explain me how shadow file is created and included in rootfs?
Mar 15 14:26:29 <ag> I'm talking about poky + core-image-minimal
Mar 15 14:28:55 <fray> ag -- there is a class that handles user/group operations..
Mar 15 14:29:17 <ag> useradd
Mar 15 14:29:19 <ag> ?
Mar 15 14:29:35 <fray> this class uses the shadow-utils useradd/groupadd tools with a --root= parameter.  The user/group files are generated and if shadow support is enabled then the shadow files are created and updated along the way..
Mar 15 14:29:52 <fray> this stuff is all dynamic during the sysroot creation (package compilation) as well as package installation on the target filesyste
Mar 15 14:30:03 <ag> Got it now.
Mar 15 14:30:05 <fray> a default passwd/group file is provided as well
Mar 15 14:30:14 <ag> How am i able to add a password for root user?
Mar 15 14:30:39 <fray> you want to set a global default, or you want to set it on the device or?
Mar 15 14:31:06 <ag> for a specific image
Mar 15 14:32:09 <fray> easiest way.. use a .bbappend on teh base-passwd_3.5.22.bb package and add it to the file via a patch
Mar 15 14:32:24 <fray> so in your custom layer.... (looking up semantics)
Mar 15 14:33:08 <ag> base_passwd contains shadow file as well?
Mar 15 14:33:16 <fray> create a recipes-core/base-passwd/base-passwd_3.5.22.bbappend
Mar 15 14:33:23 <fray> in that, you want:
Mar 15 14:33:42 <fray> FILESEXTRAPATHS_prepend := "${THISDIR}/base-passwd"
Mar 15 14:33:49 <fray> PRINC = "1"
Mar 15 14:33:53 <ag> i know all these
Mar 15 14:33:59 <fray> ok
Mar 15 14:34:20 <fray> ya, just patch the /etc/passwd and add the hash for the password you want in the image..
Mar 15 14:34:29 <fray> thats the "system wide" way of setting a default..
Mar 15 14:34:37 <ag> very good
Mar 15 14:34:45 <ag> but that password will be in shadow?
Mar 15 14:34:52 <ag> after rootfs creation?
Mar 15 14:34:56 <fray> the alternative is to run the passwd program.. but I'm not sure if that was made to work this way.. looking
Mar 15 14:35:07 <fray> during password creation, I believe the passwd file is split into the shadow file..
Mar 15 14:35:17 <ag> This was the answer :)
Mar 15 14:38:16 <ag> fray: thanks a lot
Mar 15 15:11:08 <ag> Very strange
Mar 15 15:11:28 <ag> fray: I did patch the default passwd with the hash.
Mar 15 15:11:38 <ag> --crypt-md5 right?
Mar 15 15:13:34 <ag> but this hash is modified in the rootfs
Mar 15 15:13:47 <ag> I wrote: $1$1DO/lR8M$f8JOOu4W8GBZzdNzCgSW40
Mar 15 15:14:16 <ag> And it ended like this:11DO/lR8M
Mar 15 15:19:01 <autif> missing some back slashes may be?
Mar 15 15:19:15 <autif> or qoutes?
Mar 15 15:21:39 <ag> I realised now that this is done with update-passwd util.
Mar 15 15:35:16 <ag> autif: bingo! thanks
Mar 15 15:35:56 <sblu> I'm new to yocto; I installed the core-image-sato image and running it on qemu.
Mar 15 15:36:35 <sblu> I'm now trying figure out how to get the poky features installed so that I can do some app development
Mar 15 15:37:56 <sblu> The poky features as in the anjuta ide, the gnome mobile platform gcc, etc.
Mar 15 15:38:55 <bluelightning> sblu: we don't officially support the anjuta IDE anymore, although the bits for supporting it are still there
Mar 15 15:39:22 <bluelightning> sblu: if you're happy with eclipse you can use the ADT
Mar 15 15:40:38 <sblu> Ok. So if I were to use eclipse/gtk mobile/gcc etc....do I install it on my host machine and somehow compile it to run on qemu?
Mar 15 15:41:23 <sblu> Or can I build stuff (eclipse, gcc, etc) install it on the target and then compile it there?
Mar 15 15:43:00 <sblu> I did not find the build environment on the target qemu using the 'sato' image instructoins on the quick-install yocto image....is there a different image I need to be using?
Mar 15 15:47:09 <bluelightning> sblu: the ADT cross-builds applications on your host for the target (in this case qemu)
Mar 15 15:47:33 <bluelightning> there's a full manual for the ADT on the website
Mar 15 15:48:05 <bluelightning> sblu: if you want to do development on the target itself that is possible as well - you can build core-image-sato-sdk which will include the compiler and all of the other necessary pieces
Mar 15 15:48:12 <bluelightning> it will be slower however
Mar 15 15:48:17 <bluelightning> and a little harder to interact with
Mar 15 15:50:53 <sblu> Great! That clarifies my confusion with this.  Thanks for the help.  I'm going to try using the cross compiler.
Mar 15 16:24:32 <ag> sgw1: Around?
Mar 15 16:25:22 <ag> Or anybody who was involved in openssh integration?
Mar 15 16:25:40 <ag> Using master poky we have an issue / bug.
Mar 15 16:26:02 <ag> If i add openssh-scp and openssh-sshd in  core image minimal
Mar 15 16:26:19 <ag> i see in do rootfs log some non fatal errors:
Mar 15 16:26:37 <ag> grep: /media/HDD-WRS/yocto/2012-03-13-18-18-imx6-qt-bootchart-graphics/tmp-eglibc-eglibc/work/imx6sabre-oe-linux-gnueabi/demo-image-1.0-r0/rootfs/etc/passwd: No such file or directory
Mar 15 16:26:37 <ag> useradd: user 'sshd' already exists
Mar 15 16:26:51 <ag> This is because base-passwd comes after it....
Mar 15 16:49:47 <sgw> ag: I am around, I will poke zenlinux on this one, as he is most familiar on useradd and openssh
Mar 15 16:50:34 <ag> sgw: I'm into it as well... but still couldn't figure it out
Mar 15 17:03:30 <zenlinux> hi ag
Mar 15 17:03:35 <ag> cheers!
Mar 15 17:03:43 <zenlinux> are you using the latest poky master?
Mar 15 17:03:46 <ag> yes
Mar 15 17:03:59 <zenlinux> we've fixed a number of race conditions
Mar 15 17:04:11 <zenlinux> hmm
Mar 15 17:04:13 <ag> when?
Mar 15 17:04:36 <zenlinux> do a search on our git repo for useradd
Mar 15 17:05:12 <ag> b417983f75e72b69bf85db5fef00a8198d29ceeb?
Mar 15 17:06:58 <ag> and anyway my last change is yesterday
Mar 15 17:07:02 <ag> So it's updated.
Mar 15 17:07:12 <zenlinux> yeah, sounds like you've run across something we don't have a bug for
Mar 15 17:07:24 <ag> yes indeed
Mar 15 17:07:39 <ag> when is passwd dropped in rootfs?
Mar 15 17:08:00 <zenlinux> it would be during the installation of base-passwd
Mar 15 17:08:09 <ag> bindo
Mar 15 17:08:11 <ag> bingo!
Mar 15 17:08:17 <ag> and here is the problem
Mar 15 17:08:30 <ag> why openssh is installed before base-passwd"?
Mar 15 17:08:32 <ag> that is the q
Mar 15 17:08:57 <zenlinux> can you check if the openssh package as a runtime dependency on base-passwd?
Mar 15 17:09:28 <ag> not in bb
Mar 15 17:09:32 <ag> wanna check in classes as well?
Mar 15 17:09:39 <zenlinux> I'm staring at the code in useradd.bbclass that is supposed to inject that dependency into the package
Mar 15 17:09:47 <ag> me too
Mar 15 17:09:50 <ag> but it doesn't
Mar 15 17:10:05 <ag> rdepends += " base-passwd shadow"
Mar 15 17:10:09 <ag> this is not working
Mar 15 17:10:11 <zenlinux> could you have generated the openssh packages from an older version of the repo?
Mar 15 17:10:25 <ag> nope
Mar 15 17:10:26 <ag> clean!
Mar 15 17:10:40 <zenlinux> which package format are you using?
Mar 15 17:10:52 <ag> come again?
Mar 15 17:10:57 <zenlinux> rpm, deb, or ipk?
Mar 15 17:11:00 <ag> rom
Mar 15 17:11:03 <ag> rrm
Mar 15 17:11:05 <ag> rrmrpm
Mar 15 17:11:06 <zenlinux> :)
Mar 15 17:11:07 <ag> damn!
Mar 15 17:11:10 <ag> :p
Mar 15 17:11:36 <zenlinux> ag, let me check a couple of things, brb
Mar 15 17:11:50 <ag> i will check to set rdepends in bb
Mar 15 17:18:21 <zenlinux> ag, go into your tmp/deploy/rpm/<arch> directory and run rpm -qpf --requires on the openssh packages you've got
Mar 15 17:18:31 <zenlinux> mine lists base-passwd as a requirement
Mar 15 17:19:08 <ag> me too
Mar 15 17:19:13 <ag> check that already
Mar 15 17:19:15 <ag> checked
Mar 15 17:19:55 <zenlinux> ok, so that means that installation of the packages during do_rootfs is not using rpm? either that or rpm is not honoring the requirement
Mar 15 17:20:51 <zenlinux> is this fully reproducible? try bitbake -c cleansstate <your image> and then rebuild it.
Mar 15 17:21:57 <ag> wait
Mar 15 17:22:36 <ag> ye sit is...
Mar 15 17:22:41 <ag> yes it is...
Mar 15 17:23:44 <zenlinux> hmm
Mar 15 17:24:33 <ag> ...
Mar 15 17:24:51 <ag> DOn't you have a build with openssh?
Mar 15 17:24:56 <zenlinux> It would be helpful if you could send me some a few files to see if I can reproduce this - your local.conf and the custom image recipe.
Mar 15 17:25:22 <ag> In order to test this again i did this:
Mar 15 17:25:50 <ag> In local.conf i changed threads and -j to 4.
Mar 15 17:25:54 <ag> and machine on arm.
Mar 15 17:25:57 <ag> qemuarm
Mar 15 17:26:10 <ag> and in custom image just added openssh-sshd to image-install
Mar 15 17:26:27 <zenlinux> ok, that keeps things simple
Mar 15 17:26:31 <ag> Nothing else to test this bug. And be sure that is not from my stuff.
Mar 15 17:26:39 <ag> stuff = layers erc
Mar 15 17:27:06 <zenlinux> I'm going to run a build from scratch on a reasonable fast machine, so I should have some data on this in an hour (well, let's say two, given lunchtime)
Mar 15 17:28:00 <ag> I will do it as well.
Mar 15 17:39:49 <ag> zenlinux: Comming back online in one hour and a half. Deal
Mar 15 17:39:50 <ag> deal?
Mar 15 17:39:58 <zenlinux> ag, I'll be here
Mar 15 17:40:17 <ag> In this way you will have time to finish the build
Mar 15 17:41:00 <zenlinux> yeah, I've probably got another 15 minutes or so remaining on my build
Mar 15 17:41:10 <zenlinux> 15-20
Mar 15 17:42:15 <ag> You will have th build ready in 15 minute?
Mar 15 17:42:17 <ag> minutes*
Mar 15 17:42:29 <ag> zenlinux: Seriously?
Mar 15 17:43:21 <zenlinux> yeah, I'm building on a 40-core system
Mar 15 17:43:51 <ag> Ok. I will wait than.
Mar 15 17:43:59 <zenlinux> k
Mar 15 17:44:02 <ag> Ping me! :)
Mar 15 18:13:29 <zenlinux> just a few tasks to go...
Mar 15 18:13:46 <ag> zenlinux: life's not fair
Mar 15 18:15:48 <zenlinux> ag, my build completed successfully. no errors
Mar 15 18:18:12 <zenlinux> whoa, but the openssh server won't start because the sshd user does not exist
Mar 15 18:18:33 <ag> Bingo!
Mar 15 18:18:37 <ag> Wanna know ehy? :))
Mar 15 18:18:39 <ag> why
Mar 15 18:18:47 <ag> Gimme a cat on log for rootfs
Mar 15 18:18:50 <zenlinux> ag, if you have clues, I'm all ears
Mar 15 18:18:58 <zenlinux> I'll pastebin it, one sec
Mar 15 18:19:14 <ag> what machine?
Mar 15 18:21:15 <zenlinux> ag, now I see what you mean. I was thinking your build was failing during do_rootfs.
Mar 15 18:21:33 <zenlinux> It actually succeeds, but this error is in the do_rootfs log
Mar 15 18:21:54 <zenlinux> yep, and base-passwd is installed later in the process
Mar 15 18:22:01 <ag> i know
Mar 15 18:22:01 <zenlinux> fray, you around?
Mar 15 18:22:28 <ag> cat log.do_rootfs | grep useradd
Mar 15 18:22:40 <ag> I there useradd: user 'sshd' already exists in the output?
Mar 15 18:22:51 <ag> I there "useradd: user 'sshd' already exists" in the output?
Mar 15 18:22:58 <zenlinux> ag, yep, I'm able to reproduce this
Mar 15 18:23:21 <ag> Pff...
Mar 15 18:23:37 <zenlinux> I need to discuss this with our resident RPM expert, fray, when he's around
Mar 15 18:23:56 <ag> A temporary workaround would be to add ssh user in base-passwd
Mar 15 18:24:31 <ag> fray is around. I had a talk with him a while ago.
Mar 15 18:25:02 <zenlinux> he could be in a meeting or something. I will discuss this with him as soon as I can
Mar 15 18:25:10 <ag> Thanks a lot.
Mar 15 18:25:27 <ag> I look into it in the meanwhile...
Mar 15 18:25:28 <zenlinux> ag, are you tied to using RPM in the image? I have a feeling that this may not happen if you build with ipk
Mar 15 18:25:31 <ag> i will*
Mar 15 18:25:46 <ag> zenlinux: Yes. Sorry.
Mar 15 18:25:49 <zenlinux> that IMO would be a better workaround than adding the user in base-passwd
Mar 15 18:26:26 <ag> why? a ssh user is always good to have. :)
Mar 15 18:28:01 <zenlinux> ag, just because we designed the useradd system to create users on a per-package basis
Mar 15 18:28:14 <ag> i know
Mar 15 18:38:36 <zenlinux> ok, I know it's no help to you ag, but I have confirmed that using the ipk packager works correctly. I have the feeling something will need to be done to the image generation process when using RPM where it will have to run in two passes...
Mar 15 18:38:54 <zenlinux> The first pass installing the base-passwd package, and then the second pass installing everything else
Mar 15 18:40:04 <ag> There should be the problem...
Mar 15 18:41:12 <ag> But still... the process should follow up the requirements...
Mar 15 18:41:23 <ag> Why isn't doing this in this case?
Mar 15 18:42:44 <zenlinux> ag, this is a bug, I'm filing it right now, then will head to lunch
Mar 15 18:42:59 <ag> Thanks.
Mar 15 18:43:02 <ag> For the support.
Mar 15 18:47:42 <zenlinux> https://bugzilla.yoctoproject.org/show_bug.cgi?id=2127
Mar 15 18:47:45 * zenlinux -> lunch
Mar 15 21:17:54 * RP__ notes a new bug assigned to him :/
Mar 15 21:20:44 <zenlinux> RP__, not sure if that one should go to fray or not
Mar 15 21:20:52 <zenlinux> (assuming that's the one I filed)
Mar 15 21:21:06 <RP__> zenlinux: it is, I saw you discussing it here
Mar 15 21:21:24 <RP__> zenlinux: I'm not sure either. I'm seeing if I can check a couple of things
Mar 15 21:21:36 <zenlinux> I'm guessing RPM dependencies only mean all the packages get installed at once, and don't imply an ordering?
Mar 15 21:21:54 <RP__> zenlinux: well, I thought we had this fixed with him too :/
Mar 15 21:22:04 <RP__> s/him/rpm/
Mar 15 21:22:10 <zenlinux> so did I
Mar 15 21:22:18 * RP__ wonders how his brain is crosswired
Mar 15 21:23:41 <RP__> zenlinux:  I was wondering if some dependency doesn't make it into the package
Mar 15 21:31:54 <zenlinux> RP__, no, I've verified that the RPM package itself has a requires on base-passwd
Mar 15 21:32:36 <zenlinux> also, I need to finally ask this question - what's the point of having a .inc file for a recipe when there is only one version of the recipe in a directory? I'd prefer to merge these into one recipe file when I run into them.
Mar 15 21:33:08 <zenlinux> I have the feeling that some of these .inc files are leftovers from when we kept multiple recipe versions around.
Mar 15 21:33:44 <RP__> zenlinux: If can be helpful if people do need multiple recipe versions...
Mar 15 21:33:57 <zenlinux> besides, isn't it impossible to use .bbappned with .inc files?
Mar 15 21:34:22 <RP__> zenlinux: Its also helpful for things like gcc which have references to the .inc files in other layers
Mar 15 21:34:31 <RP__> zenlinux: you can include a .inc file from another layer
Mar 15 21:34:57 <zenlinux> Well, I guess I shouldn't touch it then since I have no idea what other layers could be expecting.
Mar 15 21:35:12 * zenlinux doesn't need to jump into that mess
Mar 15 21:35:18 <zenlinux> :)
Mar 15 21:35:35 <RP__> zenlinux: there are probably cases where it does make sense to merge
Mar 15 21:35:42 <RP__> zenlinux: I'm just giving the counterargument
Mar 15 21:36:31 <zenlinux> Well, I think the safest policy is probably not to merge the files unless it's been discussed/agreed on the oe-core ML. I'll leave them be for now.
Mar 15 21:43:23 <RP__> zenlinux: a quick hack that springs to mind would be to "process" install_solution.manifest and bubble base-passwd and shadow to the top
Mar 15 21:49:03 <msm2> is there a value to describe the overall "state" of the layers?
Mar 15 21:49:10 <msm2> that I can extract somewhere?
Mar 15 21:49:26 <msm2> i could just combine the SHA's of all the layers
Mar 15 21:49:37 <msm2> wondering if something already exists
Mar 15 21:53:11 <RP__> msm2: you could look at the code which prints the info summary about the build
Mar 15 21:53:59 <RP__> msm2: See base_eventhandler base.bbclass
Mar 15 21:54:14 * RP__ suspects get_layers_branch_rev(e.data)
Mar 15 21:54:34 <msm2> RP__: ok - ill take a look
Mar 15 21:54:41 <RP__> zenlinux: I can confirm this hack to promote the packages works...
Mar 15 21:55:17 <zenlinux> RP__, cool. No word from fray yet today?
Mar 15 21:55:36 <zenlinux> If you think he won't have any objections, it might be worth committing now.
Mar 15 21:55:48 <zenlinux> or sending out to the ML for review
Mar 15 21:56:03 <RP__> zenlinux: well, I suspect he'd like to understand why the dependency resolution isn't working
Mar 15 21:56:24 <RP__> zenlinux: Interestingly this patch shows that there is some resolution going on as it does resolve the /bin/sh dependency
Mar 15 21:56:38 <zenlinux> odd
Mar 15 21:56:51 <RP__> this was partly why I wanted to try it
**** ENDING LOGGING AT Fri Mar 16 02:59:58 2012

**** BEGIN LOGGING AT Fri Mar 16 02:59:58 2012
Mar 16 08:22:48 <JaMa> RP__: moin, can you push your stamps patch for bitbake (gcc rebuilding issue) or are there some unwanted side-effects?
Mar 16 08:24:06 <JaMa> RP__: I've seen some packages failing to do do_split_packages because WORKDIR was empty, is it possible that do_package_setscene was marked incorrectly as covered?
Mar 16 08:26:03 <JaMa> http://paste.pocoo.org/show/566384/
Mar 16 08:38:32 <JaMa> and reverting just your patch doesn't fix it.. I'll try to reproduce do_split_packages issue on something smaller then qt4 :)
Mar 16 09:27:02 <RP__> JaMa: hi, I seem to have lost my copy of that patch :
Mar 16 09:27:04 <RP__> :/
Mar 16 09:41:01 <JaMa> RP__: http://paste.pocoo.org/show/566407/
Mar 16 10:45:09 <RP__> JaMa: thanks :)
Mar 16 10:51:25 <RP__> JaMa: I've merged it
Mar 16 10:51:38 <RP__> JaMa: have you tried the footer patch?
Mar 16 10:53:32 <JaMa> what's footer patch?
Mar 16 10:54:09 * JaMa is still trying to fix qt4 without rebuilding it :)
Mar 16 10:54:52 <JaMa> unpacking sstate-qt4-x11-free-armv7a-vfp-neon-oe-linux-gnueabi-4.8.0-r41.1-armv7a-vfp-neon-2-936c35ad63363a2d9f6e7274db241bc1_package.tgz gets me closer, but do_package task then assumes populated image directory
Mar 16 10:55:42 <JaMa> and even populating that causes split_and_strip_files from package.bbclass fail (because of some symlink does exist)
Mar 16 11:00:40 <RP__> JaMa: the footer patch is a patch on the bitbake mailing list which changes the console output of bitbake
Mar 16 11:48:28 <JaMa> ah haven't seen it
Mar 16 11:54:11 <JaMa> ah it was hidden between HOB patches I'm ignoring
Mar 16 12:10:19 <Crofton|work> the most annoying thing about the HOB is it needs to run an X application
Mar 16 12:27:40 <RP__> Crofton|work: what would you prefer it did?
Mar 16 12:27:54 <RP__> JaMa: I found my local copy of that patch now, typical :)
Mar 16 12:33:02 * RP__ wonders what "fatal: sha1 information is lacking or useless" means coming from git...
Mar 16 12:34:01 <Crofton|work> RP__,  not sure
Mar 16 12:34:10 <Crofton|work> but I can't play with it when I travel :)
Mar 16 12:36:26 <RP__> Crofton|work: Its git being its usual helpful self
Mar 16 12:36:35 <RP__> apparently it means I need to rebase with the -m options
Mar 16 12:49:01 <JaMa> RP__: footer works, but I'm not sure if I like it :)
Mar 16 12:49:25 <RP__> JaMa: Its a tricky one. You can get the old look with bitbake xxx | cat
Mar 16 12:50:20 <JaMa> I have | tee -a log.${MACHINE} there to keep logs for each machine in separate file
Mar 16 12:51:10 <JaMa> I would like the footer if the output above it is still showing finished tasks and scrolls
Mar 16 12:51:36 <JaMa> because many times I just scan if something is already finished or not
Mar 16 12:52:36 <RP__> JaMa: In class InteractConsoleLogFilter(logging.Filter), delete the if statement
Mar 16 12:52:43 <RP__> knotty.py
Mar 16 12:54:23 <JaMa> 6K tasks to go then I'll try :)
Mar 16 13:18:14 <JaMa> RP__: is it possible to have different sstate checksum without bitbake-diffsigs showing any difference?
Mar 16 13:20:03 <JaMa> and when I use bitbake-diffsigs call for each sigdata and then compare output I have a lot of "reorder" changes in variables
Mar 16 13:21:32 <JaMa> diff http://paste.pocoo.org/show/566485/
Mar 16 13:21:33 <JaMa> -List of dependencies for variable USE_PR_SERV is set(['PRSERV_LOCKDOWN', 'PRSERV_HOST', 'PRSERV_PORT'])
Mar 16 13:21:37 <JaMa> +List of dependencies for variable USE_PR_SERV is set(['PRSERV_PORT', 'PRSERV_HOST', 'PRSERV_LOCKDOWN'])
Mar 16 13:23:51 <RP__> JaMa: If the checksums are different, diffsigs should show a difference
Mar 16 13:24:05 <JaMa> IIRC you said that order is not important for sstatesig OEBasic|OEBasicHash, but then why it has different hash in sigdata filename
Mar 16 13:24:05 <RP__> JaMa: ordering shouldn't change anything, we should filter that out
Mar 16 13:24:18 <RP__> JaMa: perhaps there is a bug? :/
Mar 16 13:24:20 <JaMa> sstate-qt4-x11-free-armv7a-vfp-neon-oe-linux-gnueabi-4.8.0-r41.1-armv7a-vfp-neon-2-a6c7fcee97592d440b71afb08a1945e9_package.tgz.siginfo
Mar 16 13:24:23 <JaMa> sstate-qt4-x11-free-armv7a-vfp-neon-oe-linux-gnueabi-4.8.0-r41.1-armv7a-vfp-neon-2-936c35ad63363a2d9f6e7274db241bc1_package.tgz.siginfo
Mar 16 13:24:30 <JaMa> and bitbake-diffsigs doesn't show anything
Mar 16 13:27:28 <RP__> JaMa: something is wrong with bitbake-diffigs then :/
Mar 16 13:27:56 <RP__> JaMa: could you share those two siginfo files please?
Mar 16 13:30:12 <JaMa> yup mmt, I've just compared that long "Tasks this task depends on" line and it's also just reorder of tasks
Mar 16 13:32:17 <JaMa> RP__: http://build.shr-project.org/tests/jama/sstate-qt4/
Mar 16 13:32:57 <RP__> JaMa: thanks. I'll try and take a look at them shortly
Mar 16 13:34:35 <JaMa> you can ignore that 3rd one.. this one is because I've changed split_and_strip_files not to die when symlink exists
Mar 16 13:35:29 <JaMa> but interestingly it makes all package checksums invalid, quite strict for added "try:" :)
Mar 16 13:46:05 <ericben> kernelimage=mod53/uImage
Mar 16 13:46:09 <ericben> oops
Mar 16 13:55:04 <RP__> JaMa: It is rather sensitive to changes like that although technically correct as the code could have changed the packaging :)
Mar 16 13:55:25 * RP__ thinks we're down to about 115 warnings on a world build
Mar 16 14:09:55 <JaMa> does world build include also all -native/nativesdk variants?
Mar 16 14:12:27 <bluelightning> JaMa: no, they are explicitly excluded (see git grep "EXCLUDE_FROM_WORLD")
Mar 16 14:13:16 <bluelightning> well, actually... I wonder if bbclassextended ones are excluded...
Mar 16 14:21:48 <bluelightning> actually they should be as well
Mar 16 14:22:17 <bluelightning> some will get built anyway via dependencies though
Mar 16 14:22:29 <bluelightning> (native ones that is)
Mar 16 15:04:08 <JaMa> bluelightning: I was just asking because there is enough WARNINGs for everybody :)
Mar 16 15:50:36 <RP__> JaMa: you're right, there are more from the meta-toolchain targets :(
Mar 16 15:51:23 <RP__> JaMa: Considering we were above the 700 mark initially and now on 77, we're not doing do badly...
Mar 16 16:24:56 <msm> RP__: what do you think about a patch to trigger a re-compile (maybe configure too) if the build detects source changes for a git project?
Mar 16 16:25:04 <msm> maybe also appending -dirty to PR
Mar 16 16:25:51 <msm> or maybe some things like this have already been considered for the "source is outside of yocto scenario"
Mar 16 16:30:51 <bluelightning> msm: surely if the source changes then the hash changes, and if PV includes SRCPV (you have to do this within the recipe) then that will happen automatically...?
Mar 16 16:31:10 <bluelightning> s/hash/commit/
Mar 16 16:32:18 <vmeson> msm, or are you thinking of a simple script using inotify, like: http://www.yepcorp.com/blogs/pavel-karoukin/automate-build-inotify-tools.html ?
Mar 16 16:33:15 <msm> im talking about trigger a rebuild
Mar 16 16:33:29 <msm> bluelightning: ideally the hash would change
Mar 16 16:33:32 <msm> and you would have a new package
Mar 16 16:34:07 <msm> you would need to add a variable that has some SHA of the changes made to the recipe
Mar 16 16:34:13 <msm> so sstate-cache won't create problems
Mar 16 16:34:22 <msm> or there are nostamp foo you can do for all the tasks
Mar 16 16:34:24 <bluelightning> msm: if PV includes SRCPV then that will occur, I'm not seeing anything missing...
Mar 16 16:35:33 <msm> bluelightning: right, it sort of works i beleive
Mar 16 16:36:06 <msm> bluelightning: http://pastebin.com/DZyKTi9c
Mar 16 16:37:35 <bluelightning> that looks a bit hacky to me...
Mar 16 16:40:20 <RP__> msm: it is indeed rather hacky
Mar 16 16:40:38 <msm> i'll take that as a compliment
Mar 16 16:40:47 <msm> proof of concept ;)
Mar 16 16:40:50 <RP__> why not git:///${COREBASE}/../linux/;protocol=file ?
Mar 16 16:40:54 <RP__> for SRC_URI?
Mar 16 16:41:09 <RP__> and set it to autorev...
Mar 16 16:41:14 <msm> RP__: that...
Mar 16 16:41:26 <msm> RP__: hmmm
Mar 16 16:41:30 <msm> RP__: what about uncommited changes?
Mar 16 16:41:47 <msm> bbiab
Mar 16 16:41:52 <RP__> msm: it wouldn't cover those, true
Mar 16 16:56:52 <otavio> Has someone got a bad var name in today's yocto tip?
Mar 16 16:59:18 <Daiane> I updated my yocto copy this morning
Mar 16 16:59:29 <Daiane> and I'm not able to create a image
Mar 16 16:59:31 <Daiane> local: 1: -Uhv: bad variable name NOTE: package core-image-minimal-1.0-r0: task do_rootfs: Failed
Mar 16 16:59:50 <otavio> Daiane: welcome.
Mar 16 17:00:03 <Daiane> I wonder if there is any missing package on my desktop, since it's my first build on this installation.
Mar 16 17:00:45 <otavio> Daiane: I don't think it is a missing dependency has it seems to be calling rpm binary and this is done using rpm native from native sysroot.
Mar 16 17:01:07 <otavio> s/has/as/
Mar 16 17:01:53 <otavio> Daiane: what's the image you're building?
Mar 16 17:02:03 <Daiane> core-image-minimal
Mar 16 17:03:06 * RP__ wonders if that is a dash/bash issue
Mar 16 17:03:35 <Daiane> I'm using dash
Mar 16 17:03:47 <Daiane> should I choose bash?
Mar 16 17:10:31 <Daiane> You're right. It works is I use bash instead
Mar 16 17:10:31 <Daiane> =P
Mar 16 17:10:59 <otavio> RP__: good catch!
Mar 16 17:11:18 <otavio> :-D
Mar 16 17:11:36 <otavio> Now I am pondering what bashims is there
Mar 16 17:11:50 <RP__> Daiane: dash should work, it looks like something has crept in that shouldn't
Mar 16 17:12:02 <RP__> otavio: I thought we'd fixed them all...
Mar 16 17:12:15 <otavio> RP__: me too
Mar 16 17:12:30 <RP__> Can someone file a bug please?
Mar 16 17:13:00 <RP__> There should probably be a bug filed against the test-suite too
Mar 16 17:14:31 <Daiane> I can file the bug (I have the log error), but I don't know where
Mar 16 17:14:36 <Daiane> can you help me?
Mar 16 17:16:47 <RP__> Daiane: bugzilla.yoctoproject.org
Mar 16 17:17:30 <Daiane> thanks ;)
Mar 16 17:58:45 * mranostay yawns
Mar 16 21:56:58 <kergoth> anyone seeing xserver-xorg compileation failures in hw/xfree86/os-support/linux recently?
Mar 16 23:07:34 <otavio> RP__: http://paste.debian.net/160053/ <= makes sense? I can't test but  will mail Daiane and ask her to give it a try
Mar 16 23:11:45 <RP__> otavio: ah, just remove the "local" keyword
Mar 16 23:14:04 <otavio> RP__: http://paste.debian.net/160054/ < this?
Mar 16 23:14:33 <RP__> otavio: yes, and the local above it
Mar 16 23:15:12 <RP__> otavio: you also added a different typo for rpm_common_comand in the commit message :)
Mar 16 23:15:24 * RP__ keeps meaning to write a patch for the comand typo
Mar 16 23:15:33 <otavio> ah right
Mar 16 23:15:42 <otavio> RP__: but so local is bashims?
Mar 16 23:16:00 <RP__> otavio: I think so
Mar 16 23:16:02 <otavio> when local is allowed and when it is not?
Mar 16 23:16:14 <otavio> never? this class has MANY
Mar 16 23:16:34 <RP__> otavio: https://wiki.ubuntu.com/DashAsBinSh - see local
Mar 16 23:17:35 <RP__> otavio: Although that doesn't explain this case :/
Mar 16 23:18:15 <RP__> otavio: I've seen problems with local and dash :/
Mar 16 23:18:30 * RP__ doesn't know, really needs testing with dash to figure it out
Mar 16 23:18:33 <otavio> ahh I see
Mar 16 23:19:19 <otavio> if it has subshell it fails
Mar 16 23:19:36 <otavio> well, i think my first fix is better since the previous local seems fine
Mar 16 23:20:18 <RP__> otavio: the first case doesn't have a subshell does it?
Mar 16 23:20:34 <otavio> RP__: right; that's why i think it was ok
Mar 16 23:20:49 <RP__> otavio: Sorry, I mean both cases aren't subshells?
Mar 16 23:21:47 <RP__> otavio: I think the local is a false lease, I think its about how $@ gets expanded within the quotes
Mar 16 23:22:17 <otavio> RP__: right; I noticed the other uses of $@ use it without a var
Mar 16 23:22:25 <otavio> RP__: that's why i proposed the first fi
Mar 16 23:22:26 <otavio> fix
Mar 16 23:23:05 <RP__> otavio: ok, lets go with that
Mar 16 23:23:19 <RP__> otavio: sorry, I'm thinking of other problems I've seen with dash before...
Mar 16 23:24:12 <otavio> RP__: did you receive her bug report?
Mar 16 23:24:33 <otavio> RP__: if you did, please give me the number so i can add it to the commit log
Mar 16 23:26:24 <RP__> otavio: I can't see it in the bugzilla
Mar 16 23:26:39 <otavio> RP__: no problem; i ask her on monday
Mar 16 23:26:58 <otavio> RP__: want me to send it or wait her to confirm it works?
Mar 16 23:27:21 <RP__> otavio: may as well send it
Mar 17 00:14:36 <halstead> pidge, Me might drop a few outbound packets on the autobuilder network while I reset the gateway interface.
Mar 17 00:35:43 <sgw> halstead: are you all done reseting?
Mar 17 00:39:33 <halstead> pidge, All done. It was down for about 2 seconds, + or - 1 second. Network between autobuilders wasn't interrupted at all.
Mar 17 00:39:58 <halstead> sgw, pidge: All done. It was down for about 2 seconds, + or - 1 second. Forwarded packets from the internal builders (02-06) to the Internet were dropped for about 15 minutes. Network between autobuilders wasn't interrupted at all.
**** ENDING LOGGING AT Sat Mar 17 02:59:58 2012

**** BEGIN LOGGING AT Sat Mar 17 02:59:59 2012
Mar 18 02:45:33 <kergoth> Would there be any interest in a backing store python module to handle send/receive of files to/from a store of some sort, for things like automatic population of download and shared state mirrors?
**** ENDING LOGGING AT Sun Mar 18 02:59:59 2012

**** BEGIN LOGGING AT Sun Mar 18 02:59:59 2012
Mar 18 08:07:46 <MWelchUK> kergoth, Sounds like it might be very useful to me at work, but it'll be a while before I've found the time to make the OE->Yocto transition well enough to use it!
Mar 18 13:22:15 <RP__> kergoth: I don't see having it available as a module being an issue
Mar 18 16:42:26 <ka6sox> kergoth, I think thats a very good idea.
Mar 18 16:43:46 <ka6sox> nice module to have
Mar 18 18:57:18 <mranostay> kergoth: yeah seems like would uber helpful
**** ENDING LOGGING AT Mon Mar 19 02:59:58 2012

**** BEGIN LOGGING AT Mon Mar 19 02:59:58 2012
Mar 19 09:14:12 <mckoan> good morning
Mar 19 09:29:24 <bluelightning> morning mckoan, all
Mar 19 11:02:31 <RP__> morning all
Mar 19 11:31:27 <Jay7> florian: ping :)
Mar 19 11:32:00 <otavio> morning
Mar 19 11:32:14 <Jay7> florian: is *fusion is down on ltg?
Mar 19 11:32:39 <Jay7> project portal seems broken
Mar 19 12:27:14 <otavio> RP__: Daiane has just tested the package_rpm fix for dash and it does fix her issue
Mar 19 12:28:11 <RP__> otavio: thanks for the confirmation!
Mar 19 12:28:40 <RP__> Jay7: I believe it was taken down due to spam issues a while ago. Not sure if anything has changed
Mar 19 12:29:16 <Jay7> RP__: thanks for info
Mar 19 12:29:59 <Jay7> seems I should remove link to ltg from kexecboot.org then
Mar 19 12:31:02 <RP__> Jay7: I think it should be coming back, just  question of when
Mar 19 12:31:18 <RP__> Jay7: but my information is old
Mar 19 12:31:30 <Jay7> that is what I want to ask florian :)
Mar 19 12:34:27 <florian> Jay7: pong
Mar 19 12:35:32 <florian> Jay7: We had to disable Fusionforge some days ago because of spam problems. Unluckily neither Nils or me has time to get it fixed right now.
Mar 19 12:35:49 <Jay7> florian: any ETA known?
Mar 19 12:38:30 <florian> Jay7: not yet... I need to send a mail to the list as soon as I have a little bit of free time.
Mar 19 12:38:43 <Jay7> ok, thanks for info :)
Mar 19 12:39:02 <florian> yw... sorry that I do not have better news.
Mar 19 12:39:40 <Jay7> np
Mar 19 13:16:14 <ag> Is there any easy way to remove a config argument in a bbapend  from EXTRA_OECONF?
Mar 19 13:46:04 <bluelightning> ag: you could do it with oe_filter_out
Mar 19 14:01:14 <ag> bluelightning: Thanks.
Mar 19 17:30:58 <mranostay> any reason there isn't a LGPLv3_WHITELIST_GPLv3?
Mar 19 18:17:50 <dFence> hey guys! Is there already a workaround for the non-working pseudo?
Mar 19 18:18:04 <dFence> I can't get fix the "ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded: ignored." message
Mar 20 00:24:30 <sgw> kergoth: you around?  Have you had a chance to look at the source archiver patch set?
Mar 20 01:17:32 <mranostay> why does 'meta-toolchain-sdk' need a ton of gtk crap?
Mar 20 01:18:08 <kergoth> sgw: not yet, been busy at work due to an upcoming deadline. will try to squeeze it in sometime in the next couple days
**** ENDING LOGGING AT Tue Mar 20 02:59:58 2012

**** BEGIN LOGGING AT Tue Mar 20 02:59:59 2012
Mar 20 08:00:07 <mckoan> good morning
Mar 20 08:01:14 <bigwatercar> where is the eclipse plugin download page?
Mar 20 10:12:04 <ignus> hello all
Mar 20 10:12:29 <bluelightning> morning ignus, all
Mar 20 10:13:08 <ignus> bluelightning: hey, hows it going?
Mar 20 10:14:24 <bluelightning> ignus: great, and you?
Mar 20 10:15:11 <ignus> not so bad! trying to force myself to read the buildbot docs...
Mar 20 10:17:51 <ignus> any idea if/when the 3.3 kernel will make it in to the yocto git repo?
Mar 20 10:20:02 <bluelightning> ignus: not sure, I think bruce (zeddii) is working on it though
Mar 20 10:20:44 <ignus> cool - i think it has some stuff we would very much like to include...
Mar 20 10:21:55 <B4gder> is there any official guidelines on what a company needs to do to get listed on the http://www.yoctoproject.org/community/participating-organizations page?
Mar 20 10:27:51 <bluelightning> B4gder: I'm not sure, but your best bet is to contact Jeff Osier-Mixon
Mar 20 10:28:43 <B4gder> thanks
Mar 20 10:28:48 <bluelightning> ( jeffrey.osier-mixon at intel.com )
Mar 20 10:50:36 <Zagor> there is talk of a 1.1.1 maintenance release, but I'm having trouble finding a roadmap/schedule for it
Mar 20 10:53:08 <bluelightning> Zagor: it doesn't look like it's been published... most likely an oversight
Mar 20 10:53:22 <Zagor> can you poke the proper person?
Mar 20 10:53:54 <bluelightning> Zagor: sure, if you don't bring it up at the technical meeting today I will :)
Mar 20 10:54:04 <Zagor> deal! :)
Mar 20 10:54:18 <B4gder> Zagor: now sync up on the daylight savings situation =)
Mar 20 10:54:31 <Zagor> hehe, yup
Mar 20 10:54:58 <B4gder> this week "US: yes EU: no" =)
**** BEGIN LOGGING AT Tue Mar 20 12:29:04 2012
Mar 20 14:08:53 <Zagor> time check: technical meeting in 52 minutes?
Mar 20 14:22:09 <kergoth> damnit, damnit, satisfy_dependencies_for: Cannot satisfy the following dependencies for font-util: font-alias
Mar 20 14:22:16 <kergoth> i've seen this one before, but never did nail down the cause
Mar 20 14:22:17 <kergoth> hrm
Mar 20 15:58:13 <seebs> I am looking at hob, and this is my first exposure to PyGTK.  And I am a bit lost.
Mar 20 15:59:28 <seebs> I cannot figure out how the Python code finds the GtkTreeView objects named treeview1 or treeview2.
Mar 20 16:00:44 <seebs> What I would ultimately like to do is change the scroll behavior such that, if the last line was visible, and we add a new line, the last line is still visible -- in the default case, this means autoscrolling to the end.  But to do this I need to find the scrolledwindow and/or treeview objects, I think.
Mar 20 18:07:29 <RP__> seebs: You want to talk to incandescant
Mar 20 18:07:47 <RP__> seebs: I'd also check there isn't someone already making changes like this (see the bugzilla)
Mar 20 18:07:59 <seebs> k
Mar 20 18:08:18 <seebs> I'm currently trying to track down PSEUDO_PREFIX diagnostics that appear when running under hob but not the rest of the time.
Mar 20 18:08:30 <incandescant> seebs/RP: I've raised a similar issue - we need to get buy in from the designers and primary engineers that this is the way to do it
Mar 20 18:08:40 <incandescant> my similar patches/suggestions have been vetoed so far
Mar 20 18:08:44 <incandescant> seebs: please file a bug :-)
Mar 20 18:09:09 <incandescant> seebs: oh, I guess you want to make changes immediately then?
Mar 20 18:09:16 <seebs> I may have chosen a poor place to jump into things, uh.  :P
Mar 20 18:09:42 <seebs> Well, basically.  I would like to make the change locally just because it is annoying to me and fixing it would reduce the level of noise I have to try to sort through for some signal.
Mar 20 18:09:54 <incandescant> I understand
Mar 20 18:09:57 <seebs> I do plan to submit patches for the PSEUDO_PREFIX thing if I can track it down.
Mar 20 18:10:30 <seebs> In an ideal world, I would be happier if hob didn't spew hundreds of lines of GTK or Python (?) diagnostics about things not having particular attributes.
Mar 20 18:10:57 <seebs> But I don't know nearly enough about Python, GTK, or hob to really do much about this.  I'm still at the "gosh, vern, sure are a lot of wires in there" phase.
Mar 20 18:11:13 * incandescant nods
Mar 20 18:11:26 <incandescant> I can probably whip up a patch for you to autoscroll to the end
Mar 20 18:14:02 <seebs> That would be cool.  Especially if you could explain it, because I am deeply bothered by the fact that there appears to be magic here.
Mar 20 18:14:14 <seebs> I am not comfortable with magical things happening in the absence of unicorns.
Mar 20 18:14:38 <incandescant> I'm pretty sure there's no magic
Mar 20 18:15:01 <incandescant> there are a lot of factory things and OO wotsits
Mar 20 18:15:57 <seebs> Yeah.  I just can't figure out how anything in the Python code finds the scrollwindow/treeview things from the glade file.  I don't see any references that explain this.  Unless there's some kind of implicit matching of structures.
Mar 20 18:20:43 <incandescant> there's no glade file
Mar 20 18:20:57 <seebs> Now I'm confused.
Mar 20 18:21:26 <incandescant> where did you find a glade file?
Mar 20 18:21:40 <seebs> poky/bitbake/lib/bb/ui/crumbs/puccho.glade
Mar 20 18:21:53 <seebs> If that's not being used, well, it explains a lot of my confusion.  :P
Mar 20 18:21:56 <incandescant> oh, that's not hob
Mar 20 18:22:02 <seebs> ohhh
Mar 20 18:22:16 <incandescant> there are several gui's in BitBake, puccho is kind of orphan at this point
Mar 20 18:22:18 <seebs> See.  I found that directory by searching for files which contained the strings I was seeing displayed in hob.
Mar 20 18:22:22 <seebs> ahhhhh.
Mar 20 18:22:50 <incandescant> crumbs is a directory containing various GUI, it kind of spun out of control
Mar 20 18:23:07 <seebs> ahhhhh
Mar 20 18:23:21 <seebs> Okay, suddenly this seems a LOT less crazy.
Mar 20 18:23:47 <seebs> I was completely unable to figure out how that file was being used.
Mar 20 18:23:51 <seebs> MYSTERY: SOLVED.
Mar 20 18:24:03 <incandescant> :-)
Mar 20 18:24:53 <incandescant> of course Hob has changed by a few thousand lines since I wrote it so the scroll patch I just wrote doesn't work, may take a few more mins than anticipated
Mar 20 18:24:56 <seebs> This is a new obfuscation technique I don't think I've seen before; "spare unrelated files with suspiciously similar or related-seeming names".
Mar 20 18:24:59 <seebs> heh
Mar 20 18:25:19 <seebs> No hurry on my end, I'm running a build with an instrumented /bin/sh so I can try to figure out what the commands are that are getting the bogus pseudo environment.
Mar 20 18:26:06 <seebs> I figure if I can get a command line for the affected shell commands, plus an environment dump, I may be just about ready to figure out what happened.
Mar 20 18:36:50 <incandescant> seebs: it gets a bit confused when a hidden row is inserted but this mostly does what I think you're asking for
Mar 20 18:36:50 <incandescant> http://pastebin.com/UXJyKLwb
Mar 20 18:37:25 <seebs> Cool!
Mar 20 18:38:30 <seebs> Huh.  I have a mere 98MB of shell command log files.  No problem at all!
Mar 20 18:39:26 <seebs> This may not be hard enough to debug.  Maybe we should replace uses of "sh -c foo" with opening a pipe to a shell and writing commands to it on stdin.
Mar 20 18:39:41 <seebs> Or possibly set up a randomly-changing nest of symlinks to the shell, and invoke them instead of "sh".
Mar 20 19:39:58 <seebs> Interesting.
Mar 20 19:40:16 <seebs> All my PSEUDO_PREFIX failures under hob are of the form "cd /path/to/meta-foo; git branch..."
Mar 20 19:40:33 <seebs> So it looks like those are getting run with pseudo's environment busted somehow but not fully disabled.
Mar 20 19:45:11 <mwelling> Is there a reason why the xf86-input-tslib recipe was left from the project?
Mar 20 19:50:30 <seebs> Okay, so.  If I want to extract information from part of bitbake, can I just print stuff from it, or is there a logger I should be using, or what?
Mar 20 19:50:50 <seebs> Say, hypothetically, if I wanted to dump the value of os.environ['PSEUDO_PREFIX'] right before a call to os.popen.
Mar 20 19:55:42 <jmpdelos> bitbake -e?
Mar 20 19:57:39 <seebs> Unfortunately, this problem appears to only occur under hob.
Mar 20 19:58:07 <seebs> Basically, if I run a build under hob, the os.popen() calls for base_get_metadata_git_branch and one other thing somehow end up with a mangled pseudo environment.
Mar 20 19:59:31 <seebs> Huh.  I should first go look at whether I even catch popen() right now.  I might not.
Mar 20 19:59:49 <seebs> I ignored it because I didn't think I cared, but that was before all the stuff with messing with pseudo environments got added.
Mar 20 20:06:41 <seebs> ugh
Mar 20 20:06:43 <seebs> Yup, popen's broken.
Mar 20 20:07:01 <seebs> And I suspect this could be fixed in hob, but I should probably fix it properly.  Which turns out to be Hard.
Mar 20 20:08:11 <kergoth> hmmm,  | gdk-pixbuf-xlib.c:22:22: fatal error: X11/Xlib.h: No such file or directory
Mar 20 20:08:14 * kergoth digs
Mar 20 20:12:00 <kergoth> ah, crap
Mar 20 20:12:17 <kergoth> it does a conditional 'if x11 is around, then enable x11 support' and has no with/enable arg to manually seti t
Mar 20 20:12:25 * kergoth rolls eyes and goes to add an argument
Mar 20 20:25:28 <ericben> hi, what is the license of the yocto documentation (especially the diagrams available here : http://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs/tree/diagrams/poky-buildprocess ) ?
Mar 20 20:29:37 <seebs> popen/pseudo:  No promises yet, but I managed to generate a reproducer for a failure that my new patch fixes.
Mar 20 21:23:20 <kergoth> msm: ping
Mar 20 21:25:24 <msm> kergoth: hello
Mar 20 21:30:49 <msm> can anyone explain why crosssdk exists? if we have a working toolchain on the host to begin with, and we already use that for buildnig the rootfs why do we need to make another x86 toolchain just for the SDK tarballs?
Mar 20 21:32:27 <kergoth> crosssdk is like canadian
Mar 20 21:32:41 <kergoth> you can build a x86_64->arm meta-toolchain from your i686 host
Mar 20 21:32:44 <kergoth> afaik, anyway
Mar 20 21:33:47 <kergoth> msm: there's some brokenness in meta-fsl-ppc. the TUNE_PKGARCH_tune-* are never used, because arch-powerpc.inc overrides the bitbake.conf TUNE_PKGARCH definition that used it. this results in TUNE_PKGARCH being powerpc-nf rather than ppce500v2 or whatever, which in turn results in TUNE_PKGARCH not being in PACKAGE_EXTRA_ARCHS, and the build blowing up in sanity
Mar 20 21:34:35 <msm> right, but you make an interim x86 -> x86 compiler, that's not needed
Mar 20 21:34:37 <msm> is this master?
Mar 20 21:34:41 <msm> master is very out of date
Mar 20 21:34:51 <kergoth> and the TUNE_ARCH_tune-* aren't used at all either
Mar 20 21:34:52 <msm> meta-fsl-ppc "master" that is
Mar 20 21:34:53 <kergoth> yep
Mar 20 21:35:04 <kergoth> having a broken default branch is probably bad :)
Mar 20 21:35:05 <msm> i've not even built master yocto/oe in a while
Mar 20 21:35:14 <kergoth> you're on edison?
Mar 20 21:35:23 <msm> im trying to do stuff for our "release"
Mar 20 21:35:26 * kergoth nods
Mar 20 21:35:28 <msm> and we don't have resources for much else
Mar 20 21:35:36 <msm> edison ftw
Mar 20 21:36:40 <msm> kergoth: the fixes are problably in the edison branch that you need
Mar 20 21:41:41 <kergoth> ah, right, it's the tune- files for these things in oe-core that are hokey
Mar 20 21:41:46 <kergoth> not so much the fsl layer
Mar 20 21:41:51 * kergoth digs
Mar 20 21:42:02 <kergoth> e.g. tune-ppce500v2.inc
Mar 20 21:42:09 <kergoth> (in master, haven't checked edison)
Mar 20 21:44:23 <msm> that TUNE stuff should be in decent shape in oe-core
Mar 20 21:58:37 <kergoth> aha, got a clean fix for it
Mar 20 21:59:22 <kergoth> right now arch-powerpc.inc sets TUNE_PKGARCH to ${PPCPKGARCH}. instead, it should set TUNE_PKGARCH_powerpc and TUNE_PKGARCH_powerpc-nf to that. that way more specific tunes, like ppce500v2, can override it via TUNE_PKGARCH_<tune>
Mar 20 21:59:34 * kergoth tries a p2020rdb build
Mar 20 22:01:53 <kergoth> other problem: meta-fsl-ppc seems to be confused as to its identity. it has both bsp layer and distro layer components
Mar 20 22:02:14 <kergoth> as a consequence, it's not possible to build for a ppc machine without getting fsl distro changes, some of which aren't bsp bound
Mar 20 22:02:28 <kergoth> further, as a result, you can't build any of those machines distroless, due to the use of ${DISTRO} in the PRs
Mar 20 22:02:44 <msm> kergoth: i've since converted those to use a distro_append
Mar 20 22:02:51 <kergoth> ah, cool
Mar 20 22:02:54 <kergoth> okay then :)
Mar 20 22:03:05 <kergoth> where are those changes?
Mar 20 22:03:10 <msm> well
Mar 20 22:03:14 <msm> some are in edison
Mar 20 22:03:24 <kergoth> edison was what i just tested,a nd which failed miserably ;)
Mar 20 22:03:37 <msm> i guess im lying
Mar 20 22:03:41 <msm> its not all there
Mar 20 22:03:46 <msm> i just did it for recent stuff - with gcc
Mar 20 22:03:57 <kergoth> ah
Mar 20 22:03:59 <msm> you tested with edison on meta-fsl-ppc and master on oe-core?
Mar 20 22:04:09 <msm> that's bound to have problems ;)
Mar 20 22:04:09 <kergoth> i didn't expect it to succeed, but figured what hte hell
Mar 20 22:04:11 <kergoth> yeah
Mar 20 22:04:25 <kergoth> i think it'd be much cleaner to split out a meta-fsl
Mar 20 22:04:29 <msm> did we ever get that bbappend regex matching?
Mar 20 22:04:48 <kergoth> you mean to match more than one recipe iwth a single bbappend? that doesn't exist, no
Mar 20 22:05:18 <msm> yea, i suspect there are some things like that which should be done
Mar 20 22:05:28 <kergoth> k
Mar 20 22:07:39 <kergoth> I'll play around, and submit this oe-core change to the list
Mar 20 22:07:55 <kergoth> this is just preliminary investigation to compare mentor's fsl layers against the fsl one
Mar 20 22:07:59 <kergoth> heh
Mar 20 22:11:22 <kergoth> wonder if the powerpc spe feature should go into oe-core, given it's another mutually exclusive option vs powerpc and powerpc-nf.. course, i don't think it's supported outside the e500, so probably not much of a concern yet
Mar 20 22:11:25 * kergoth scratches head
Mar 20 22:23:26 <msm> yea i was trying to deal with that
Mar 20 22:23:30 <msm> maybe i was
Mar 20 22:23:48 <msm> ppc-efd ppc-efs fpu etc
Mar 20 22:24:24 * kergoth nods
Mar 20 22:30:57 <msm> and altivec coming back soon
Mar 20 22:31:11 <kergoth> fun fun
Mar 20 22:51:02 <msm> kergoth: i'll try to resync with upstream soon
Mar 20 22:51:26 <msm> kergoth: what distro changes are you talking about? it's the bbappends right?
Mar 20 22:51:53 <msm> they need to conditionally modify the oe-core stuff, if our distro is enabled?
Mar 21 01:29:02 <seebs> Well, that's discouraging.  I still get those PSEUDO_PREFIX errors even catching popen.
Mar 21 01:32:27 <seebs> It appears that somehow we're spawning a shell which lacks PSEUDO_PREFIX, but which has LD_PRELOAD.  That's obviously wrong.  Most of the other PSEUDO_* stuff is set, though...  So I am not sure what's happening yet.
**** ENDING LOGGING AT Wed Mar 21 02:59:58 2012

**** BEGIN LOGGING AT Wed Mar 21 02:59:58 2012
Mar 21 08:42:39 <mckoan> good morning
Mar 21 08:54:50 <bluelightning> hi mckoan, all
Mar 21 09:01:46 <mrAlmond> Hi everyone
Mar 21 09:02:33 <mrAlmond> Where do the cross compiler binaries are located in yocto tree?
Mar 21 09:29:33 * bluelightning -> office
Mar 21 10:14:44 <RP__> mrAlmond: you mean in the sysroot? They're in the native sysroot in a subdirectory of usr/bin
Mar 21 10:17:03 <ignus> hello all
Mar 21 10:20:18 <mrAlmond> RP__ : I think I've found it but all the basic eglibc includes are missing. Where can I find the "full" toolchain, for example one like codesourcery one.
Mar 21 10:20:52 <RP__> mrAlmond: We don't build the toolchain in an isolated location like that
Mar 21 10:21:21 <RP__> mrAlmond: The target pieces like headers and libraries are in the target sysroot
Mar 21 10:24:52 <mrAlmond> RP__ : For example poky-edison-6.0/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi ?
Mar 21 10:25:18 <RP__> mrAlmond: yes, headers and libs would be in there for armv7a-vfp-neon
Mar 21 10:26:21 <mrAlmond> RP__ : But in there where should be the sysroot dir? I can see only all the packages directories
Mar 21 10:26:37 <RP__> mrAlmond: sorry, I misread that
Mar 21 10:26:54 <RP__> mrAlmond: You want poky-edison-6.0/build/tmp/sysroots/armv7a-vfp-neon-poky-linux-gnueabi/
Mar 21 10:28:08 <mrAlmond> RP__ : Great! Thank you!
Mar 21 10:45:35 <ag> Hello. How can i see the dependency chain after which a specific package is required?
Mar 21 10:52:26 <RP__> ag: bitbake xxx -g or bitbake xxx -g -u depexp might help you understand it
Mar 21 10:53:35 <ag> RP__: Thank you RP. The problem come after defining a new virtual libgl.
Mar 21 10:53:50 <ag> Multiple .bb files are due to be built which each provide virtual/libgl
Mar 21 10:53:55 <ag> Multiple .bb files are due to be built which each provide virtual/xserver-xf86
Mar 21 10:54:03 <ag> Any ideas?
Mar 21 10:54:46 <RP__> ag: run bitbake with -DDD and pipe it to a file. Somewhere in there it will explain why its confused
Mar 21 10:55:00 <ag> Thank you once again.
Mar 21 10:57:44 <ericben> hi, in meta/recipes-multimedia/speex/speex_1.2rc1.bb, we have : FILES_${PN} = "${libdir}/lib*.so.*" and FILES_${PN}-dev += "${libdir}/lib*.so.*" , what is the expected result here ?
Mar 21 10:58:10 <RP__> ericben: depends on the order of PACKAGES in that case
Mar 21 10:59:08 <ericben> RP__: are both necessary as only the first one will match files ?
Mar 21 10:59:54 <ericben> which means files ends in $PN (which is before $PN-dev in PACKAGES defintion in conf/bitbake.conf
Mar 21 11:01:13 <RP__> ericben: both are not necessary, it looks wrong
Mar 21 11:02:31 <ericben> RP__: ok thanks for the confirmation I'll send a patch
Mar 21 11:36:13 <ag> RP__: Cannot find the problem here...
Mar 21 11:36:25 <ag> RP__: Talking about that virtual define...
Mar 21 11:44:07 <RP__> ag: is the log somewhere I could look at?
Mar 21 13:25:14 <Zagor> 1.1.1 doesn't have the sstate cache fixes, does it?
Mar 21 13:34:07 <Zagor> if it does, I have more :-)
Mar 21 13:34:34 <Zagor> more bugs, that is
Mar 21 14:46:41 <kergoth> why does running bitbake -DD not result in seeing debug messages in the task log files?
Mar 21 14:53:18 <ag> Is there anyway i can get rid of "was already stripped, this will prevent future debugging!"?
Mar 21 14:57:10 * kergoth sighs
Mar 21 14:57:26 <kergoth> bitbake still contacting the remote server and dying horribly even though i have the local git repo in my downloads..
Mar 21 14:57:31 * kergoth stabs fetch2 a few times
Mar 21 15:06:05 <RP__> ag: don't strip the files?
Mar 21 15:06:20 <RP__> Zagor: It had a lot of them but possibly not all :/
Mar 21 15:06:36 <ag> RP__: I integrate some precompiled stuff.
Mar 21 15:07:01 <RP__> ag: you can disable the QA check
Mar 21 15:07:26 <ag> Hmmmm... I skiped all QA and still nothing works...
Mar 21 15:08:01 <RP__> ag: "nothing works"?
Mar 21 15:08:22 <RP__> ag: the above is simply a warning message
Mar 21 15:10:30 <ag> RP__: I know.
Mar 21 15:10:44 <ag> RP__: But a flag to deactivate this would be nice.
Mar 21 15:11:05 <ag> RP__: As much as the developer know the origin of this warning and wants to get over it.
Mar 21 15:13:06 <RP__> ag: It looks like that comes from package.bbclass and doesn't obey the usual INSANE_SKIP mechanism :(
Mar 21 15:13:12 <RP__> patches very welcome
Mar 21 15:13:41 <ag> RP__: I know that too :)
Mar 21 15:14:05 <ag> RP__: As soon as i will finish this work i will upload a patch for this.
Mar 21 15:39:06 <Zagor> RP__: ah, thank you for the pigz fixup
Mar 21 15:39:34 <RP__> Zagor: I've put a few fixes into it if you look at the change history ;-)
Mar 21 15:41:52 <RP__> Zagor: There were underlying issues that needed to get fixed
Mar 21 15:48:00 <Zagor> RP__: right. that would have taken me a while to figure out on my own :)
Mar 21 15:48:27 <kergoth> RP__: how do you get fetch2 to stop failing if it can't ls-remote the remote repository? neitehr having the local git repo in downloads nor having a mirror tarball seems to have any effet, it still insists on choking for no reason
Mar 21 15:48:35 <kergoth> effect, even
Mar 21 15:49:12 <RP__> kergoth: You probably have a recipe with a branch/tag name. Use a specific revision, then it won't have to resolve it
Mar 21 15:50:04 <kergoth> RP__: the branch is resolvable just fine in the local repo. i'd rather it built a slightly older version of taht branch than dying
Mar 21 15:50:49 <RP__> kergoth: Well, there are two ways you can make that behave. Feel free to add an option to make it resolve it locally only
Mar 21 15:51:02 <RP__> kergoth: I don't think it should be on by default though
Mar 21 15:51:19 <kergoth> I don't see why it needs to be an option at all. no one would rather have a failed build. if hte server is down, there's nothing you can do about it
Mar 21 15:51:35 <kergoth> and what good are mirror tarballs if they don't work to deal with servers being down?
Mar 21 15:51:40 <kergoth> pretty useless as far as I can tell
Mar 21 15:51:56 <RP__> kergoth: I never want to see the bug report "I set it to use tag/branch X, and it used the local revision, not the upstream one"
Mar 21 15:52:09 <kergoth> that won't happen if upstream exists.
Mar 21 15:52:32 <RP__> kergoth: So you get two different behaviours depending on the state of your network?
Mar 21 15:52:44 <kergoth> if your network is down, it'll fail in the sanity check long before
Mar 21 15:53:09 <kergoth> fetch failures are teh most common problem with oe/yocto builds, if there's no way to work around a server being down, that's a bug, period
Mar 21 15:53:28 <RP__> kergoth: General policy is to set specific source revisions and say what you mean in recipes
Mar 21 15:53:55 <kergoth> so you're making excuses for the flawed fetch2 code by saying we can't use teh flexiblity we have?
Mar 21 15:53:58 <kergoth> please
Mar 21 15:54:14 <RP__> kergoth: The code is not flawed, its doing it for what I believe is a good reason
Mar 21 15:54:20 <RP__> kergoth: You might disagree with that, fine
Mar 21 15:54:34 <kergoth> Once again, if ther'e sno way to work around a server being down, the code is broken
Mar 21 15:54:44 <kergoth> if you can't see that, it's mind boggling
Mar 21 15:54:47 <RP__> kergoth: Set a specific revision
Mar 21 15:54:57 <kergoth> so you no longer support oe's flexibility?
Mar 21 15:55:05 <kergoth> we're going to specific locked down policies now?
Mar 21 15:55:10 <kergoth> what a joke.
Mar 21 15:55:19 <Zagor> kergoth: how does oe handle this case?
Mar 21 15:56:30 <RP__> kergoth: "locked down policies"? If you can't access the network to definitely resolve a tag/branch name, yes its going to fail. If you didn't want it to use the network, use a file:// url
Mar 21 16:03:46 <kergoth> RP__: that's ridiculous. recipes default to upstream locations. if there's no way to work around an upstream fetch failure without hacking the recipe, that's crap
Mar 21 16:03:57 <kergoth> you might as well throw PREMIRRORS out the window too while you're at it
Mar 21 16:05:24 <RP__> kergoth: Its equally ridiculously getting two builds with different results depending on whether your turn on the network
Mar 21 16:05:52 <RP__> kergoth: please sent the patch allowing the option of enabling the other behaviour. You can then turn it on, I won't and we'll all be happy
Mar 21 16:06:02 <kergoth> that can just as easily happen with the mirroring system.
Mar 21 16:06:13 <kergoth> *any* use of non-hash revs is subject to variance
Mar 21 16:07:08 <RP__> kergoth: I can't see many ways this would happen
Mar 21 16:07:45 <kergoth> nevermind, i should know better. this crap is why i stopped contributing on my own time in the first place
Mar 21 16:08:04 <kergoth> hack around it locally as usual
Mar 21 16:10:03 <bluelightning> kergoth: if you really believe you are right, why do you refuse to patch in an option?
Mar 21 16:54:15 <sgw> seebs: I have a pseudo question for you
Mar 21 16:55:07 <seebs> k?
Mar 21 16:56:51 <sgw> seebs: I am building a "build appliance for the yocto project, basicly Poky build building Poky, so I added target side pseudo, but when I run bitbake with it, I get a sanity test failure saying that "Pseudo is not functioning correctly", any hints or suggestions?
Mar 21 17:07:33 <seebs> Huh, could be nearly anything.  I guess that'd be the point at which we start trying to test out the target pseudo in various ways directly.
Mar 21 17:07:48 <seebs> Like, see if just running that pseudo (on the target) gives you a prompt, etc.
Mar 21 17:25:16 <ag> otavio: Do you now anything about imx-lib?
Mar 21 17:25:53 <ag> I'm trying to compile it and i see that videodev.h is obsolete....
Mar 21 17:26:25 <otavio> ag: please try current tip
Mar 21 17:26:36 <otavio> ag: i just pushed many fixes on the tree; it might help
Mar 21 17:26:47 <otavio> ag: but i didn't try to build it yet
Mar 21 17:26:51 <ag> i'll have a pull
Mar 21 17:27:07 <ag> or do you have it in your branch somewhere
Mar 21 17:29:14 <ag> pushed is a commit of yours from 1 feb
Mar 21 17:29:21 <ag> gimme a link :)
Mar 21 17:32:22 <ag> otavio: it looks like 2.6.35 is the last version with videodev.h...
Mar 21 17:32:36 <ag> I'm trying to compile it with 38 or 2.0
Mar 21 17:32:38 <ag> I'm trying to compile it with 38 or 3.0
Mar 21 17:33:03 <otavio> for imx53?
Mar 21 17:33:12 <otavio> 38 i haven't test; only 35
Mar 21 17:33:26 <otavio> and 3.0 has no recipe (except linaro one) on the bsp as well
Mar 21 17:34:29 <otavio> ag: https://github.com/Freescale/meta-fsl-arm
Mar 21 17:38:21 <ag> otavio: Those are with headers from 35 as i said...
Mar 21 17:41:28 <ericben> ag: actual imx-lib doesn't compile with kernel headers from 2.6.38
Mar 21 17:42:01 <ericben> I expect to get an upgrade from Linaro as they have that in house but there are actually license problems for distribution
Mar 21 17:42:40 <ericben> ag: http://lists.linaro.org/pipermail/linaro-kernel/2012-March/001239.html
Mar 21 17:43:08 <ag> ericben: Thank you very much. I didn't thought so.. but didn't know for surre.
Mar 21 17:43:15 <ericben> ag: if you can ask in reply to this thread, maybe that will help to unlock the situation
Mar 21 17:43:33 <ericben> ag: we need to show there are many peoples interested in this code
Mar 21 17:45:49 <ag> ericben: I will express my interest in this as well.
Mar 21 17:46:09 <ag> ericben: How come imx-lib are now in linaro's "garden"?
Mar 21 18:02:21 <seebs> Okay, I have established to my satisfaction that... I have no clue what's going on.
Mar 21 18:02:35 <seebs> If I run Python under my version of pseudo, it works the way I expect it to.
Mar 21 18:02:44 <seebs> When hob calls os.popen(), it doesn't hit the wrapper.
Mar 21 18:04:43 <seebs> ... oh, I bet I know.
Mar 21 18:05:46 <seebs> Yup.  If pseudo's disabled, we only hit the inner wrapper if there's a hand-rolled wrapper for it.  Like there is for fork and exec.
Mar 21 18:16:33 <ericben> ag: Freescale is an founding member of Linaro and they have enginers working in Linaro for their products (that's what they call a landing team) so what seems actually the best options would be to run their 3.1 or 3.2 freescale landing team kernel together with their modified GPU & VPU codes
Mar 21 18:16:40 <ericben> the kernel actually runs
Mar 21 18:16:46 <ericben> but we are missing the GPU & VPU code
Mar 21 18:17:44 <ag> Clear now.
Mar 21 18:17:59 <ag> I know aer are missing those...
Mar 21 18:18:03 <ag> we*
Mar 21 18:20:44 <seebs> huh, that's... still not it.  I am very confused.  I may have to put extra stuff into Python to debug this.  Eww.
Mar 21 18:32:00 <ericben> once we have run build without rm_work in oe-core, is there an easy way to clean workdirs if I now enable rm_work ?
Mar 21 18:38:12 <bluelightning> I think it recognises it needs to do that by itself
Mar 21 18:52:59 <khem> ericben: just buy a new hard disk and dont use it
Mar 21 18:53:11 <khem> :)
Mar 21 18:53:21 <khem> thats what I did and now I am happy
Mar 21 18:56:02 <ericben> hi khem well I solved the problem by removing the workdirs manually
Mar 21 18:56:49 <ericben> bluelightning: yes but only for one recipe, not for all the dependencies if I understand well
Mar 21 19:25:47 <otavio> RP__: git-native build failure in tip: http://paste.debian.net/160552/
Mar 21 19:25:55 <otavio> known?
Mar 21 20:14:21 <RP__> otavio: its a rebuild problem :/ If you clean and rebuild it, it will work. We should start tracking these in the bugzilla
Mar 21 20:22:40 <flihp> anyone have some advice for building -dev packages?
Mar 21 20:23:06 <flihp> I've got my library building fine using autotools class but my -dev package is empty :(
Mar 21 20:23:24 <denix> RP__: I've seen plenty of such rebuild problems before, but it got better lately
Mar 21 20:23:38 <RP__> denix: We've started fixing them ;-)
Mar 21 20:24:04 <RP__> flihp: Are you seeing any packaging warnings and what is happening to the files you think should be in -dev ?
Mar 21 20:25:14 <flihp> RP__ no packaging warnings, no nothing
Mar 21 20:25:37 <flihp> the files that I want in dev are checked out properly from git
Mar 21 20:25:45 <flihp> they're where they shoudl be for the build
Mar 21 20:26:08 <flihp> is there a specific class I should look at to see the code that builds dev packages?
Mar 21 20:26:20 <flihp> just looking for a hint as to where to start reading
Mar 21 20:26:58 <flihp> wading backwards through bb class dependencies is a bit daunting
Mar 21 20:27:37 <RP__> flihp: Does your do_install install the files into ${D} ?
Mar 21 20:29:48 <flihp> RP__: they're not \o/
Mar 21 20:30:19 <RP__> flihp: if you install them there to the right place it will likely just work
Mar 21 20:30:41 <flihp> I'm assuming "the right place" is somewherein /usr/include?
Mar 21 20:34:20 <ag> Guys, we don't have _append for do_patch? Strangely i get "NOTE: Error expanding variable do_patch" after defining "do_patch_append"...
Mar 21 20:35:15 <JaMa> ERROR: Package version for package lttng-ust went backwards which would break package feeds from (0:1.9.4+git1+eeee05f35f014a8c068e0d29b18629cafbfdfc1d-r0 to 0:0.16-r0)
Mar 21 20:35:18 <JaMa> doesn't look right
Mar 21 20:35:31 <denix> do_patch is not a shell task
Mar 21 20:36:01 <ag> denix: How can i create a task that would be executed after unpack but machine dependent...
Mar 21 20:38:08 <RP__> JaMa: We'll probably have to bump PE for it :/
Mar 21 20:38:27 <RP__> flihp: Install to ${D}/${includedir}/
Mar 21 20:38:43 <RP__> flihp: plenty of examples if you look at other do_install tasks
Mar 21 20:39:59 <denix> ag: addtask my_patch after do_patch
Mar 21 20:40:16 <flihp> ack, thanks RP__.  Wish this package installed their headers to standard location, they go to /usr/share/ currently
Mar 21 20:40:40 <ag> denix: I know this. But how would i do this to be executed just for a specific machine?
Mar 21 20:41:07 <JaMa> RP__: yup looks like it.. but I'm wondering what pulled lttng-ust instead of lttng2-ust and nothing in buildhistory shows dependency on it
Mar 21 20:41:14 <khem> write a python wrapper
Mar 21 20:41:56 <RP__> ag: you can't do that. You'd just put conditional code in
Mar 21 20:42:08 <ag> RP__: Ok.
Mar 21 21:33:11 <Bagder> anyone aware of any Yocto related presence at Design West ESC March 27-29 in San Jose?
Mar 21 22:11:07 <RP__> Bagder: nitink might be there I think?
Mar 21 22:16:59 <Bagder> just curious, as I will be there
Mar 21 22:32:25 <nitink> badger: I will be presenting few sessions there
Mar 21 22:32:51 <nitink> badger: I will be present about yocto project only
Mar 21 22:33:17 <nitink> preseting
Mar 21 23:39:12 <sgw> ericben: not sure why I did not think to ping you here!
Mar 21 23:41:25 <ericben> sgw: hi
Mar 21 23:41:52 <ericben> RP__: what do you mean by manually include python-nativesdk ?
Mar 21 23:42:32 <sgw> ericben: first off thanks for the fast turns on this issue!
Mar 21 23:42:32 <RP__> ericben: I think I was confused, sorry
Mar 21 23:42:55 <RP__> ericben: I was thinking the dependency was autodetected but its explict
Mar 21 23:43:12 <sgw> ericben: can you do a devshell and just strace the link command and let us know which libpython gets opened?
Mar 21 23:43:40 <sgw> ericben: we are thinking there might be some confustion there, and want to double check that.
Mar 21 23:43:49 <RP__> ericben: when you build, is there a toolchain extracted at the target location?
Mar 21 23:44:19 <ericben> RP__: now yes, but not initially
Mar 21 23:44:30 <sgw> As already noted your gdb is linked to the host libpython, not the native version, and nitink has no linkage.
Mar 21 23:47:22 <ericben> sgw: yes. I'm launching a build again as I had cleaned tmp
Mar 21 23:47:58 <ericben> is there a way to limit tmp/ccache size ?
Mar 21 23:52:36 <ericben> sgw: that's strange after linking manually I don't get any reference to python http://pastie.org/3644721
Mar 21 23:53:02 <sgw> ericben: what about the strace?
Mar 21 23:57:55 <ericben> sgw: http://pastie.org/3644751
Mar 21 23:58:32 * RP__ -> Zzzz
Mar 21 23:59:31 <sgw> ericben: interesting it's not finding it at all, did you remove the sdk?
Mar 21 23:59:47 <ericben> sgw: I just removed it
Mar 22 00:00:27 <ericben> I'm rebuilding the sdk, will install it and launch again the devhsell on gdb to see
Mar 22 00:00:39 <sgw> Ok
Mar 22 00:03:06 <ericben> sgw: OK I reproduce nitink 's problem now
Mar 22 00:03:14 <ericben> *** glibc detected *** x86_64-oe-linux-gdb: double free or corruption (out): 0x00007f907df5f030 ***
Mar 22 00:03:15 <nitink> great !
Mar 22 00:03:34 <sgw> woot! and not so woot!
Mar 22 00:03:39 <nitink> what made it reproduce it !
Mar 22 00:03:49 <ericben> nitink: removing the already installed sdk
Mar 22 00:04:15 <nitink> so RP's guess was right
Mar 22 00:06:09 <ericben> nitink: one moment I've installed the sdk and I'm rebuilding to see
Mar 22 00:06:31 <ericben> just to be sure gdb works again
Mar 22 00:06:51 <nitink> yes, confirming would help
Mar 22 00:09:27 <ericben> strange gdb is still broken
Mar 22 00:09:55 <ericben> I did : bitbake gdb-cross-canadian-x86-64 -c cleansstate
Mar 22 00:10:03 <ericben> after installing the sdk
Mar 22 00:10:27 <ericben> then I built again the meta-toolchain (with the sdk installed)
Mar 22 00:10:31 <ericben> and gdb still fails
Mar 22 00:12:31 <ericben> but now when I launch it I see in strace that it loads libpython from the sdk : open("/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/libpython2.7.so.1.0", O_RDONLY) = 7
Mar 22 00:12:52 <nitink> ^^^ I notice same here
Mar 22 00:13:44 <nitink> I think issue comes when it links with the nativesdk libpython
Mar 22 00:14:01 <ericben> could that be a dependency problem
Mar 22 00:14:09 <ericben> I'm running with BBTHREAD=8
Mar 22 00:15:27 <ericben> gdb-cross-canadian.inc DEPENDS on python-nativesdk but are we sure python-nativesdk is stagged before gdb-cross-canadian gets compiled ?
Mar 22 00:17:22 <nitink> DEPENDS should take care of that
Mar 22 00:17:31 <ericben> OK time to sleep, I'm cleaning tmp and launching a build fro scratch to see if I reproduce my initial state
Mar 22 00:17:55 <sgw> ericben: thanks for your help, we can touch base again tomorrow.
Mar 22 00:18:23 <ericben> sgw: no problem I really need python in gdb else we can't get qtcreator to work with gdb
Mar 22 00:18:47 <ericben> so I'm very interested in finding a solution here ;-)
**** ENDING LOGGING AT Thu Mar 22 02:59:58 2012

**** BEGIN LOGGING AT Thu Mar 22 02:59:58 2012
Mar 22 08:21:29 <mckoan> good morning
Mar 22 09:34:10 <ericben> morning
Mar 22 09:35:09 <ericben> I've just tested hob - image creator and I must say : great work to the team who develops the tool. The progress since the previous version is impressing and the user interface now has a very reactive behaviour
Mar 22 11:12:50 <otavio> morning
Mar 22 12:28:07 <bluelightning> otavio: hi, I have a fix (as well as one other minor tweak): http://cgit.openembedded.org/openembedded-core-contrib/log/?h=paule/combo-layer-fixes4
Mar 22 12:58:16 <otavio> ah
Mar 22 12:58:18 <otavio> heheh
Mar 22 15:38:00 <otavio> bluelightning: worked fine
Mar 22 15:38:03 <otavio> bluelightning: :)
Mar 22 15:49:00 <ignus> hello all
Mar 22 16:05:59 * fray is now sitting amidst a pile of boxes -- yet to be unpacked.. (office move yesterday).. at least we got the machiens setup
Mar 22 16:12:19 <bluelightning> hi ignus
Mar 22 16:12:26 <bluelightning> otavio: great!
Mar 22 16:12:31 <bluelightning> hi fray
Mar 22 16:12:35 <fray> morning..
Mar 22 16:12:50 <fray> hopefully I can unbury a desk today enough so I can do some "real" work..
Mar 22 16:14:09 <ignus> bluelightning: hey, hows it going?
Mar 22 16:14:42 <bluelightning> ignus: great, thanks
Mar 22 16:14:45 <bluelightning> ignus: you?
Mar 22 16:15:55 <ignus> im great, yeah. reading all about buildbot and asking many annoying questions on #buildbot :D
Mar 22 16:17:21 <bluelightning> ignus: I had a play around with it briefly when I first started, but haven't come back to it at all
Mar 22 16:17:45 <bluelightning> ignus: pidge (that's beth) should be able to help you with any yocto-specific issues with autobuilder/buildbot
Mar 22 16:20:03 <ignus> fantastic - it will be a great help to have someone who i can throw my questions at... probably a good idea to get my head around b/b before asking anything i think...
Mar 22 16:24:12 <ignus> bluelightning: busy?
Mar 22 16:24:39 <bluelightning> ignus: I'm just in a meeting atm but will be done in about 1/2 hour
Mar 22 16:25:11 <seebs> So, basically.  I still can't figure out what hob is doing.  The popen calls aren't hitting the popen wrapper, but they are happening in a context where LD_PRELOAD is set and PSEUDO_PREFIX isn't.  This is obviously impossible.
Mar 22 16:25:26 <ignus> bluelightning: just curious...
Mar 22 16:30:29 <fray> seebs, could this be a direct syscall or something from python?
Mar 22 16:30:44 <seebs> I don't know!  Thing is, if I write a test program that does os.popen, it works.
Mar 22 16:30:54 <seebs> And I can't find any hint of the command line that's biting me showing up outside an os.popen call.
Mar 22 16:31:13 <fray> odd
Mar 22 16:31:44 <seebs> So.  Next up:  Get X from the fast machine in the office to my desktop, and run a build with pseudo debugging in HAHAHAHA I SPAM FASTER THAN AN SSD WRITES mode.
Mar 22 16:33:05 <seebs> I suppose the other thing would be to try to figure out how I get to that hunk of code, and/or add debugging messages in parts of hob.
Mar 22 16:57:15 <bluelightning> seebs: if it helps at all I think you can trigger a similar misbehaviour (unless I'm mistaken) by just calling the metadata revision code from the bitbake exit event handler
Mar 22 16:57:43 <bluelightning> seebs: i.e. what I was reporting recently with buildhistory
Mar 22 16:58:49 <otavio> bluelightning: please submit those as a pull request; they are important for me to keep combo-layer working :)
Mar 22 16:59:07 <seebs> ooh
Mar 22 16:59:10 <seebs> That might help a lot.
Mar 22 16:59:36 <seebs> If you can get something that invokes the git log/git branch stuff using os.popen to fail and give PSEUDO_PREFIX messages, any reproducer would help.
Mar 22 17:01:12 <bluelightning> seebs: let me see if I can come up with a very simple test case
Mar 22 17:01:34 <bluelightning> otavio: will do that now
Mar 22 17:01:35 <seebs> It doesn't have to be VERY simple to be better than "I can only trigger it at the very end of a complete build in hob".
Mar 22 17:01:50 <bluelightning> yeah, that's what I figured :)
Mar 22 17:01:51 <otavio> bluelightning: thanks
Mar 22 17:01:56 <bluelightning> has to eliminate a lot of code paths
Mar 22 17:07:11 <zenlinux> RP__, you developed a potential fix for bug #2127. Is that good enough for us to commit to?
Mar 22 17:07:50 <RP__> zenlinux: it breaks meta-toolchain
Mar 22 17:07:52 <zenlinux> My fix for a different bug (#1794) will cause do_rootfs to fail without a fix for 2127
Mar 22 17:08:02 <RP__> zenlinux: I'd also like Mark's feedback
Mar 22 17:08:27 <zenlinux> RP__, how did it break meta-toolchain?
Mar 22 17:08:42 <RP__> zenlinux: won't build, fails at populate_sdk
Mar 22 17:09:18 <RP__> zenlinux: I've not looked into why yet, I suspect an empty search result problem
Mar 22 17:09:42 <zenlinux> fray, your insight regarding bug #2127 would be greatly appreciated
Mar 22 17:09:57 * zenlinux wanders off for a few minutes
Mar 22 17:11:00 <fray> zenlinux let me know when you are back.. I'll explain what most distros do
Mar 22 17:11:07 <fray> (RPM based distros)
Mar 22 17:12:23 <RP__> fray: Most rpm based distros install base-passwd first?
Mar 22 17:12:29 <fray> yes
Mar 22 17:12:40 <RP__> fray: I guess my fix to reorder the file effectively does that
Mar 22 17:13:03 <fray> they order the install to be install the /etc/passwd,group first.. then install the filesystem, then "everything else".. it's more then just the reorder fix.. it actually runs them in discrete steps..
Mar 22 17:13:22 <fray> by adding it in the order, it biases it to the top of the install, but the installer can still reorder it arbitrarily
Mar 22 17:13:42 <fray> for WR Linux what we do is manually install the files (outside of RPM), and then use RPM for everything else
Mar 22 17:14:11 <fray> 'er.. use RPM for it and everything else.. (this ensures the files are there, and the rpm install order computed based on deps is preserved)
Mar 22 17:15:05 <fray> (that is the approach I'm currently partial to BTW)
Mar 22 17:19:58 <zenlinux> fray, back
Mar 22 17:20:15 <fray> did you see the above.. thats what I wanted to mention..
Mar 22 17:20:57 <zenlinux> fray, yes, thanks
Mar 22 17:21:19 <fray> I'd like to add typically what also happens is:
Mar 22 17:21:31 <fray> glibc requires filesystem, filesystem requires base-passwd
Mar 22 17:21:42 <fray> this may introduce a small dependency loop between base-passwd and glibc...
Mar 22 17:21:47 <fray> but RPM has a dep loop filter..
Mar 22 17:22:04 <fray> base-passwd>glibc (or filesystem or.. whatever the loop is) is the right answer..
Mar 22 17:22:15 <fray> that tells RPM that base-passwd has to be installed before the other item, in the case of a dep loop
Mar 22 17:22:52 <fray> if that makes more sense, and we can ensure that filesystem or glibc or ... can be installed very early due to the dependency order.. we can exploit that as well..
Mar 22 17:23:11 <fray> (BTW I suspect the filesystem package is installed very early right now)
Mar 22 18:30:40 <seebs> Hmm.
Mar 22 18:31:50 <seebs> All the failures happening under hob occur with PSEUDO_DISABLED=1.  Pseudo is still in LD_PRELOAD, but PSEUDO_PREFIX has been lost.
Mar 22 19:18:07 <bluelightning> seebs: infuriatingly I can't make my previous error condition happen... :/
Mar 22 19:18:29 <bluelightning> at least not in a trivial test... I'm doing a more complete test now
Mar 22 19:22:01 <seebs> Heh.
Mar 22 19:22:20 <seebs> Yeah, this one's being a great deal of fun to track down.  It simply *doesn't happen* except under one highly specialized circumstance.
Mar 22 19:22:59 <bluelightning> oh well, I'll leave this build going and head home, will let you know what the result is
Mar 22 19:23:37 <fray> seebs, could the system (in popen) be calling one of the other pseudo calls and end up in a recursion or something?
Mar 22 19:24:10 <seebs> Maybe, but...  The weird thing is, if I have a popen() wrapper which is called unconditionally and always displays something...
Mar 22 19:24:16 <seebs> I don't see anything right before the error messages.
Mar 22 19:24:35 <fray> so it's forking (somehow) then the error, then the popen?
Mar 22 19:24:41 <seebs> And yet, the only place those command lines exist is os.popen() calls, and os.popen() calls normally reach the wrapper.
Mar 22 19:24:49 <seebs> I don't know.
Mar 22 19:24:53 <fray> odd..
Mar 22 19:25:01 <seebs> I replaced /bin/sh with something that logs these.
Mar 22 19:25:10 <fray> in the earlier (WR) call, they were talking about systemtap..  could that be useful in debugging this at all?
Mar 22 19:25:17 <seebs> If it sees LD_PRELOAD, not PSEUDO_PREFIX, it logs stuff.
Mar 22 19:25:21 <seebs> I don't know yet.
Mar 22 19:25:24 <fray> 'k
Mar 22 19:25:42 <seebs> So what I know is that there's a command line, and I can't find anything that looks like it except for a specific os.popen().
Mar 22 19:25:59 <fray> huh
Mar 22 19:26:03 <seebs> And when that gets reached, it does NOT hit the pseudo wrapper, but the child process gets LD_PRELOAD pointing at pseudo.
Mar 22 19:26:30 <seebs> I guess you could produce this if you manually set LD_PRELOAD without really using pseudo.  But why would anyone be doing that?
Mar 22 19:27:07 <seebs> I mean, if you were in an environment where pseudo had been turned off, and you set LD_PRELOAD, you'd get this.  But I'm not aware of anything that sets LD_PRELOAD without setting other stuff too.
Mar 22 19:27:33 <fray> is someone trying to activate pseudo within HOB?  (i.e. no wrapper for hob to setup pseudo pre-hob?)
Mar 22 19:32:38 <seebs> No clue.
Mar 22 19:42:17 <fray> do a "which hob"
Mar 22 19:42:25 <fray> is it run from the scripts or bitbake/bin directory?
Mar 22 19:45:31 <seebs> scripts/hob
Mar 22 19:45:42 <seebs> Which ... what the heck
Mar 22 19:45:50 <seebs> what the
Mar 22 19:45:55 <seebs> bitbake -u hob
Mar 22 19:45:57 <seebs> ret=$?
Mar 22 19:45:59 <seebs> exit $ret
Mar 22 19:46:02 <seebs> ^-- HUH?
Mar 22 19:46:04 <zenlinux> RP__, I'm trying to dig into that  populate_sdk failure for meta-toolchain with your patch. The logs aren't giving me much info. What do you mean by suspecting the issue is "an empty search result problem"?
Mar 22 19:47:55 <RP__> zenlinux: what happens if base_passwd isn't in the file?
Mar 22 19:48:11 <zenlinux> RP__, which file?
Mar 22 19:48:14 <zenlinux> the manifest?
Mar 22 19:48:25 <RP__> zenlinux: the index we grep in that command I added
Mar 22 19:48:42 <RP__> zenlinux: right, the manifest
Mar 22 19:49:03 * RP__ is worried he tried to tab complete "manifest" :/
Mar 22 19:49:20 <RP__> I should file a bug against the IRC client
Mar 22 19:49:55 <zenlinux> in fact, total_solution.manifest is empty???
Mar 22 19:50:31 <zenlinux> oh, I get it - we don't install base-passwd into the sdk toolchain
Mar 22 19:50:40 <zenlinux> so I just need to account for that case
Mar 22 19:54:38 <seebs> So, can someone explain to me the "ret=$?; exit $ret" at the end of scripts/hob?  It's a no-op, sh will exit with the status of the last command executed when it runs out of script.
Mar 22 19:55:01 <seebs> And I'm wondering whether I'm just missing something clever.
Mar 22 19:55:20 <fray> it's likely a copy/paste thing..
Mar 22 19:55:31 <fray> most of the time you need to capture ret and then process it.. seems they aren't processing it.. ;)
Mar 22 19:56:16 <seebs> See, I'd probably just "exec bitbake -u hob" for this.  And save as much as TWENTY KILOBYTES of resident storage!
Mar 22 20:59:00 <RP__> seebs: I'd send a patch ;-)
Mar 22 21:01:00 <zenlinux> RP__, I'm almost at the bottom of that sdk bug, I think I'll have a fix for it shortly
Mar 22 21:01:18 <RP__> zenlinux: cool, it was the zero length problem then?
Mar 22 21:01:49 <zenlinux> RP__, the grep command was failing, it just needed a || true tacked to the end of it
Mar 22 21:02:05 <RP__> zenlinux: ah, right, yes
Mar 22 21:06:23 * Bagder just released a new curl release with an edited version of the yocto LD_LIBRARY patch merged
Mar 22 21:06:41 <Bagder> LD_LIBRARY_PATH even
Mar 22 21:07:54 <fray> cool!
Mar 22 21:08:02 <Bagder> and in another end, Enea was voted in as a new member company of the Yocto Advisory Board
Mar 22 21:09:02 <fray> nice
Mar 22 21:10:32 <zenlinux> neato
Mar 22 21:11:31 <RP__> Bagder: great, on both counts :)
**** ENDING LOGGING AT Fri Mar 23 02:59:58 2012

**** BEGIN LOGGING AT Fri Mar 23 02:59:58 2012
Mar 23 14:21:36 <ericben> in a oe-core default config I get a tmpdir named tmp-eglibc, then if I launch hob, I see it creates a new tmpdir named tmp-eglibc-eglibc : is that expected or is there a bug somewhere ? Can hob share the same tmpdir as knotty bitbake ?
Mar 23 14:24:22 <bluelightning> ericben: that has to be a bug
Mar 23 14:27:11 <ericben> bluelightning: ok thanks
Mar 23 14:27:41 <bluelightning> ericben: would you mind filing a bug for that?
Mar 23 14:27:59 <ericben> bluelightning: I'm first tryng to understand if I did something wrong
Mar 23 14:28:51 <bluelightning> unless you've actually set TMPDIR to /path/to/tmp-eglibc it shouldn't be behaving like that I think
Mar 23 14:29:27 <ericben> bluelightning: ok that's what I did wrong
Mar 23 14:29:56 <ericben> bluelightning: in fact no my mistake I didn't set it, it's only in sanity.conf
Mar 23 14:42:46 <ericben> bluelightning: https://bugzilla.yoctoproject.org/show_bug.cgi?id=2167
Mar 23 14:43:01 <ericben> in fact it seems hob is reusing the previous TMPDIR but appends again TCLIBCAPPENDS
Mar 23 14:43:15 <bluelightning> ericben: ok, thanks for that
Mar 23 14:43:27 <bluelightning> shane should be able to get it sorted fairly quickly I would think
Mar 23 14:43:35 <bluelightning> (or one of his team)
Mar 23 14:44:00 <ericben> now trying to reproduce my other hob bug to fill an other bug report ;-)
Mar 23 14:44:14 <ericben> this one was discovered by accident
Mar 23 15:22:03 <JaMa> RP__: hi, do you want me to respin "safe" parts of native support merge patchset or will you cherry-pick them yourself?
Mar 23 15:25:15 <RP__> JaMa: I don't know which they are so resending it will help me
Mar 23 15:26:53 <JaMa> RP__: it looks like you didn't like only 04-06/13
Mar 23 15:27:14 <JaMa> the rest is needed for librsvg-native
Mar 23 15:36:32 <RP__> JaMa: does that include pango-native?
Mar 23 15:39:33 <JaMa> yes pango-native is needed by librsvg-native
Mar 23 15:41:09 <RP__> JaMa: mandatory? that sucks :(
Mar 23 15:41:50 <JaMa> I can retry but IIRC yes, otherwise I wouldn't add it in meta-oe :/
Mar 23 16:10:36 <jzhang> fray: ping
Mar 23 16:17:34 <ericben> for hob developers : https://bugzilla.yoctoproject.org/show_bug.cgi?id=2169
Mar 23 16:18:03 <ericben> I never managed to finish a build without getting this error
Mar 23 16:18:29 <JaMa> RP__: just retested and it's still mandatory (pango-ft2 was removed in newer librsvg version then we have) but pango is still needed to provide pangocairo
Mar 23 16:19:19 <RP__> JaMa: ok, I guess I'll just have to accept that :/
Mar 23 16:19:32 <RP__> Who cares about build time anyway
Mar 23 16:19:40 <JaMa> well it's only for people who needs librsvg-native..
Mar 23 16:20:27 <JaMa> the same about gtk+-native it will hurt build time only for people who asks for gtk+-native :)
Mar 23 16:20:55 <RP__> JaMa: I'd prefer to stop people hurting themselves though. This makes it all too easy for the dependencies to creep in
Mar 23 16:27:42 <RP__> sgw: some psuedo rapth warnings just appeared on the autobuilder
Mar 23 16:27:53 <RP__> sgw: might be part of the problem you're having
Mar 23 16:33:35 <sgw> Hmm, what kicked those off?  I saw the fix for /usr/var/pseudo fly by.  I got it working yesterday, now I am just trying to deal with the huge downlowds dir issue, I am trying the newer mkdosfs
Mar 23 16:36:11 <dvhart> halstead, where id yocti go?
Mar 23 16:40:02 <ant_work> RP__, sgw: after release, is there a plan to migrate to systemd in oe-core?
Mar 23 16:41:36 <RP__> ant_work: I'd like to see it abstracted into an optional layer which could then merge
Mar 23 16:41:48 <RP__> ant_work: it needs to be optional
Mar 23 16:41:56 <ant_work> me too, now whole meta-oe seems built around it
Mar 23 16:43:07 <ant_work> sigh, this work should have been started in a separate layer...
Mar 23 16:47:37 <ag> Hello.
Mar 23 16:59:59 <ag> Anybody did any work in tk?
Mar 23 17:00:04 <ag> on*
Mar 23 17:00:32 <ag> I will integrate it in yocto as needed for _tkinter python module.
Mar 23 17:00:40 <ag> https://bugzilla.yoctoproject.org/show_bug.cgi?id=1937
Mar 23 17:00:49 <ag> RP__: Do you know anything about this?
Mar 23 17:01:30 <ag> Anybody?
Mar 23 17:08:58 <RP__> ag: Know about what?
Mar 23 17:11:20 <ag> RP__: About any tk integration.
Mar 23 17:18:12 <ag> RP__: sorry
Mar 23 17:18:25 <ag> My internet died
Mar 23 17:30:44 <RP__> ag: I know nothing about tk
Mar 23 17:32:50 <bluelightning> I guess this would be provided by a separate layer
Mar 23 17:33:58 <ag> RP__: thanks
Mar 23 17:34:27 <ag> bluelightning: This is needed in a python module
Mar 23 17:34:55 <bluelightning> ag: which one?
Mar 23 17:35:13 <ag> Tkinter
Mar 23 17:35:22 <ag> There is a bug on this.
Mar 23 17:37:00 <ag> Saul wanted me to look on it.
Mar 23 17:38:21 <bluelightning> ok, I don't have any specific knowledge about it... interesting, I didn't realise tkinter is supposedly considered to be the default python GUI system
Mar 23 17:38:32 <ag> bluelightning: https://bugzilla.yoctoproject.org/show_bug.cgi?id=1937
Mar 23 17:38:38 <bluelightning> yes, I saw that
Mar 23 17:38:44 <ag> Yeah.
Mar 23 17:38:55 <ag> I will integrate it in yocto then.
Mar 23 17:39:00 <ag> Poky*
Mar 23 18:15:07 <halstead> dvhart, Looking at it now. It's a network bridge issue I think.
Mar 23 18:15:24 <dvhart> thanks
Mar 23 18:15:26 <dvhart> zeddii, poke
Mar 23 18:15:36 <dvhart> zeddii, looking at adding pcnet32 to common-pc
Mar 23 18:16:28 <dvhart> zeddii, I'm surprised to see things like features/intel-e1xxxx/intel-e100.scc which contain exactly 1 CONFIG_ item, and don't even list the dependencies
Mar 23 18:16:34 <dvhart> zeddii, what's the thinking there?
Mar 23 18:16:45 <dvhart> doesn't seem worth it, and certainly doesn't scale
Mar 23 20:43:01 <seebs> Okay, thanks to that excellent reproducer, I'm a lot closer on the pseudo/hob interactions.  Which are now pseudo/bitbake interactions.
Mar 23 20:43:12 <seebs> Unfortunately, I barely know Python and don't know bitbake much at all.
Mar 23 20:43:36 <seebs> So, I am looking at a line:  bb.build.exec_func("breakit_break", e.data)
Mar 23 20:43:40 <seebs> I can't figure out what e is.
Mar 23 20:44:21 <seebs> And this looks like it might matter, because exec_func refers to that (under the equally-informative name "d") several times.  In ways that look like they might explain what's happening.
Mar 23 21:31:03 <fray> seebs, still here?
Mar 23 21:31:08 <seebs> yah
Mar 23 21:31:14 <fray> e is a data set, by the name 'e', I would assume that is the environment
Mar 23 21:31:31 <fray> d is also a data set, but this is the global data set for bitbake..
Mar 23 21:31:38 <fray> (e might be a modified copy of d though)
Mar 23 21:32:39 <fray> exec_func is supposed to fork/spawn a thread/somehow get another process going.. setup the bitbake data to match what was passed in (likely e in this case), and then exec the -python- function mentioned in the first argument
Mar 23 21:32:58 <fray> the catch, if this is the culpret, is how is it being forked/spawned/threaded..
Mar 23 21:34:16 <seebs> it's in exec_func_shell.  The interesting thing is that, apparently by the time I get there, I have LD_PRELOAD set but not PSEUDO_PREFIX.
Mar 23 21:34:45 <fray> exec_func_shell is similar..  in that instead of a python function, it runs a shell function..
Mar 23 21:34:53 <seebs> Oh, wait.  I wonder if this is multitasking screwing me up.
Mar 23 21:35:06 <fray> exec_func_* was rewritten to accomodate pseudo BTW.. :P
Mar 23 21:35:06 <seebs> exec_func() appears to be a general thing which calls one or the other.  Hmm.
Mar 23 21:35:38 <fray> it does things like saving the environment.. munging it with the PSEUDO_DISABLED=0/1, etc.. and then runs the shell sript (it generated)
Mar 23 21:35:46 <seebs> Yeah.
Mar 23 21:35:53 <fray> ya.. exec_func is the generic entry.. the later is the specific based on the type of function
Mar 23 21:36:04 <seebs> But it looks almost as though what's happening is... hang on.
Mar 23 21:36:11 <seebs> Is bitbake multithreaded?
Mar 23 21:36:14 <fray> yes
Mar 23 21:36:19 <seebs> Oh, geeze.
Mar 23 21:36:41 <fray> but the threading model, I think, changes based on the way that python is setup on the machine..
Mar 23 21:36:44 <seebs> I wonder if we're forking in one thread partway through environment setup in another.
Mar 23 21:37:13 <fray> I thought the environment setup happened after the fork, but before the exec..
Mar 23 21:37:20 <seebs> Well, that's the thing.
Mar 23 21:37:31 <fray> i.e. setup "variables", fork (pseudo disabled), enable pseudo, exec
Mar 23 21:37:44 <seebs> Hmm.
Mar 23 21:37:58 <seebs> Well, what's biting us is, we do a fork, and then before the exec we die because the variables are in an invalid state.
Mar 23 21:38:05 <fray> then again in the python case it does setup variables/setup environment, fork, restore environment
Mar 23 21:38:06 <fray> hmm
Mar 23 21:38:09 <seebs> Specifically, we hit a fork() at a time when we have LD_PRELOAD but not PSEUDO_PREFIX.
Mar 23 21:38:23 <fray> thats the thing, that shouldn't be possible..
Mar 23 21:38:28 <fray> the fork itself should be restoring PSEUDO_PREFIX
Mar 23 21:38:35 <seebs> And it looks like what we've got is a shell script which is trying to interpolate a python script which itself calls a shell script.
Mar 23 21:38:40 <fray> -unless- pseudo isn't loaded..  if it's not how is LD_PRELOAD getting enabled?
Mar 23 21:39:27 <fray> pseudo should be in memory for the whole run.. (in bitbake contexts..)  it's only unloaded on a fork (or exec)..  and it's unloaded by the LD_PRELOAD going away..
Mar 23 21:39:35 <seebs> Huh.
Mar 23 21:39:36 <fray> thus it doesn't make sense how LD_PRELOAD could be there and not PSEUDO_PREFIX
Mar 23 21:39:58 <seebs> Well, the top-level bitbak does NOT have pseudo loaded right now, not even disabled, so far as I can tell.
Mar 23 21:40:03 <fray> bitbake should have pseudo in memory.. when bitbake forks... that is when it's unloaded -if- the child doesn't need pseudo
Mar 23 21:40:14 <fray> it is supposed to via the shell wrapper
Mar 23 21:40:18 <seebs> Huh.
Mar 23 21:40:20 <fray> the shell wrapper is what sets up pseudo
Mar 23 21:40:52 <seebs> There is a check for whether pseudo is needed, hmm.
Mar 23 21:41:06 <fray> see line 108 of the wrapper
Mar 23 21:41:22 <fray> when they run through the build of pseudo -- pseudo is well, not avaialble
Mar 23 21:41:32 <fray> when they run through the build the second time.. pseudo is loaded.. (line 108)
Mar 23 21:41:40 <seebs> Hmm, yeah.  Okay, we're apparently running in pseudo.
Mar 23 21:41:45 <fray> not on hob.. if you've never built before.. does it forget to run the first step and not build pseudo?
Mar 23 21:41:53 <seebs> No, that's fine, I think.
Mar 23 21:41:55 <fray> if thats the case, I could see how the system could get confused because pseudo doesn't exist
Mar 23 21:42:10 <seebs> Looks to me like somehow, when we get to our handler that's blowing up, it's run in a sub-bitbake that's running without pseudo.
Mar 23 21:42:44 <fray> if you look at line 4 of the wrapper.. BB_ENV_EXTRAWHITE says don't remember these things from the environment..
Mar 23 21:42:57 <fray> 'er.. sorry other way around.. they get zeroed from the environment of bitbake..
Mar 23 21:43:25 <fray> Hmm, I thought there was something that told bitbake to include certain environment variables and keep them setup
Mar 23 21:43:31 <fray> maybe I'm remembering incorrectly
Mar 23 21:43:40 <seebs> So with the breakit.bbclass that bluelightning sent me, the thing at the tail end is being run in a bitbake that's NOT under pseudo.
Mar 23 21:44:12 <seebs> But which appears to be adding pseudo to LD_PRELOAD.  Somehow.
Mar 23 21:44:47 <fray> just a sec.. I don't think breakit is supposed to be running w/ pseudo..
Mar 23 21:44:48 <halstead> dvhart, yocti is back.
Mar 23 21:44:53 <fray> looking though
Mar 23 21:45:11 <seebs> Wait, maybe it is.  And I'm just not seeing a lot of messages because it's not calling anything that needs them.
Mar 23 21:45:15 <fray> ya.. change the definition of breakit_break() to be "fakeroot breakit_break() {"
Mar 23 21:45:29 <fray> that tells bitbake that it should be run with pseudo enabled..
Mar 23 21:45:35 <fray> otherwise, it should be w/ pseudo -disabled-
Mar 23 21:45:41 <fray> (thats the default)
Mar 23 21:45:59 <seebs> Well, that's the thing.  It's being run with pseudo disabled, but when it spawns a subprocess, LD_PRELOAD still has pseudo.  But PSEUDO_PREFIX is missing.
Mar 23 21:46:04 <fray> ....and on the disabled case, it's unloaded if not set... I think
Mar 23 21:46:21 <seebs> That may be what we're missing.  Hmm.
Mar 23 21:46:35 <fray> change it to say "fakeroot" and see if it starts working, and if pseudo is enabled reliably..
Mar 23 21:46:41 <fray> assuming it is we're good in the pseudo case
Mar 23 21:47:08 <fray> w/o fakeroot it makes sense why PSEUDO_PREFIX is missing... the system doesn't think it's needed, so it's not setting it..
Mar 23 21:47:20 <fray> the LD_PRELOAD though should have been removed by pseudo itself..
Mar 23 21:47:31 <seebs> Oh, interesting.
Mar 23 21:47:40 <fray> there is a mismatch somewhere in the contents of LD_PRELOAD and setting (or not) of PSEUDO_PREFIX
Mar 23 21:47:58 <seebs> Well, that's the thing.  Right now we *don't* set up environment before a fork.
Mar 23 21:48:07 <seebs> So pseudo won't remove or add anything.
Mar 23 21:48:19 <fray> but pseudo is already running right?
Mar 23 21:48:21 <seebs> Okay, this is interesting.
Mar 23 21:48:42 <fray> the fork shouldn't "reload" pseudo.. it should either already be in memory or not..  fork won't change that.. it's the exec that would change that
Mar 23 21:48:46 <seebs> Right before executing code, I dump the environment, and there's no LD_PRELOAD.
Mar 23 21:48:59 <seebs> And there's ... ohh.
Mar 23 21:49:02 <fray> ok, so LD_PRELOAD is being added back in my something..
Mar 23 21:49:05 <seebs> There's no LD_PRELOAD and no PSEUDO_PREFIX.
Mar 23 21:49:25 <seebs> And when we fork, we find that PREFIX is not set in the environment, but is set internally.
Mar 23 21:49:36 <seebs> Wait.  That one's working.
Mar 23 21:49:37 <fray> that is what it should have done, yes
Mar 23 21:49:43 <seebs> There are a lot of forks here and only some fail.
Mar 23 21:49:49 <fray> drat
Mar 23 21:50:04 <seebs> This is weird.
Mar 23 21:50:09 <fray> what happens if you add LD_PRELOAD to BB_ENV_EXTRAWHITE in the bitbake wrapper?
Mar 23 21:50:59 <seebs> I am... right now I just want to know what's happening, because the thing is.  ohhhh.
Mar 23 21:51:00 <fray> in pseudo I used to have debugging that included variable loading and restoration.. (if it's still there) enable it and see if you can figure out where one, but not the other is?
Mar 23 21:51:04 <seebs> Okay, I think I may know what's going on.
Mar 23 21:51:19 <seebs> In the cases that work, there's no Python expression expansion in the script being called.
Mar 23 21:51:39 <seebs> The case that's dying is one where the script that exec_func_shell is supposed to handle has Python stuff that needs to be expanded.
Mar 23 21:52:12 <seebs> Hmm.  I wonder whether that's the problem; the expansion is happening partway through the environment setup/teardown for the script.
Mar 23 21:53:14 <seebs> Huh.
Mar 23 21:53:44 <fray> do you know where the environment stuff is?
Mar 23 21:53:55 <seebs> Yeah.  I'm now pretty sure this is bitbake.
Mar 23 21:54:24 <seebs> The gimmick is a shell function which uses ${@breakit_output(d)} where that's a python function which calls a function that uses os.popen()
Mar 23 21:55:44 <seebs> And a direct call to os.popen() won't do it.  Hmm.
Mar 23 21:57:49 <seebs> So, something in the call path for that expansion is whta's doing the damage.
Mar 23 22:00:56 <seebs> Oh, neat.
Mar 23 22:01:27 <seebs> Okay, before the "possible breakage" message, the calls to git_branch work.  There's no LD_PRELOAD or PSEUDO_PREFIX in the parent's environment, but the fork() somehow ends up with them anyway.
Mar 23 22:01:32 <seebs> Which is what we expect.
Mar 23 22:01:37 <seebs> After it, the fork() doesn't end up with them.
Mar 23 22:04:47 <fray> the expansion of ${@ I think happens before the fork.. but I'm not sure..
Mar 23 22:04:57 <fray> it's possible the environment is being configured in the middle of the popen.. Hmm..
Mar 23 22:05:22 <fray> do you see the code that sets up the nevironment?  if not I can find it.. I helped RP review it
Mar 23 22:06:02 <seebs> I'm not at all sure, but I am starting to have inklings.
Mar 23 22:06:28 <seebs> It seems to me almost as though we are setting the PSEUDO_PREFIX internal value to null, which would be an error, but I don't think it should happen.
Mar 23 22:06:31 <seebs> But it's easy to check.
Mar 23 22:07:28 <fray> look in runqueue.py  "fork_off_task"
Mar 23 22:07:49 <seebs> k
Mar 23 22:07:54 <fray> line 1120 is where the stuff starts for the 'fakeroot' case..
Mar 23 22:08:13 <fray> for the normal (non-fakeroot) 1131
Mar 23 22:08:31 <fray> envvars is the list of things to setup...
Mar 23 22:08:42 <fray> envbackup is initialized with the current environment..
Mar 23 22:08:56 <fray> they then set the os.environ and fakeenv..
Mar 23 22:09:14 <fray> fork.. and then after the fork it's getting restored.. (I think)
Mar 23 22:09:43 <fray> line 1202 is the after the fork, in the parent case..
Mar 23 22:09:56 <fray> it iterates over the environmetn and either restores or removes the added keys..
Mar 23 22:10:07 <fray> if this is multithreaded.. that could be the problem you were thinking of before..
Mar 23 22:10:26 <fray> maybe a lock around the environment setup/restore sections.. that might give you a clue if it is a threading issue
Mar 23 22:10:41 <seebs> Hmm.
Mar 23 22:10:58 <seebs> I was going to say, if it's multthreading, shouldn't it be behaving differently on different runs?
Mar 23 22:11:16 <seebs> But then I noticed that sometimes debugging messages change it so bzip fails because it's not getting a pseudo environment.
Mar 23 22:14:03 <fray> there is a way to add a lock.. if we did.. it would need to be taken in the environment save/setup/fork/restore path.. and not be there for the child side of th fork
Mar 23 22:15:49 <fray> I see lock -files-, but I'm not finding any type of thread locking.. Hmm
Mar 23 22:16:53 <seebs> Well, for starters, I'm just going to add debug notes before and after.
Mar 23 22:17:04 <seebs> If they don't form non-overlapping pairs, problem is explained, probably.
Mar 23 22:18:33 <seebs> This is a pretty awesome way to learn my way around bitbake.  :P
Mar 23 22:23:52 <seebs> Well, I found a thing.  Which is I found a point at which PSEUDO_PREFIX was removed from the environment.  Which should never happen.
Mar 23 22:25:52 <fray> huh
Mar 23 22:26:35 <seebs> So the thing that's weird to me is.
Mar 23 22:26:56 <seebs> I don't see why this can only happen way out here in this one special case.
Mar 23 22:27:11 <seebs> Oh, heh.  There is only one attempt to set up the pseudo environment.
Mar 23 22:27:15 <fray> is something causing a context switch, which causes the other things to execute?
Mar 23 22:27:25 <seebs> I don't know.
Mar 23 22:27:50 <seebs> So part of our problem may be that the exec_func_shell thing isn't using runqueue at all.
Mar 23 22:28:02 <seebs> It's going through its own course of events, so far as I can tell.
Mar 23 22:28:38 <seebs> So part of the issue may be that we're hitting a case where external commands are spawned with no attempt at all to get their environment right.
Mar 23 22:30:20 <fray> yup.... I suspect that is the specific case for this message
Mar 23 22:30:20 <seebs> Sort of strange to me, also, is that PSEUDO_PREFIX isn't set in a lot of cases, but it shows up fine in the child of a fork.  Which I guess makes sense.
Mar 23 22:30:49 <fray> pseudo itself is what sets it up (more then likely) in the child, in the case where fakeroot isn't set..
Mar 23 22:31:03 <fray> if fakeroot is set, then bitbake sets PSEUDO_PREFIX itself to another value.. (I think)
Mar 23 22:31:14 <seebs> So bluelightning's breakit.bbclass is exercising a bug where things get executed without the runqueue stuff.
Mar 23 22:31:27 <fray> the way this thing is setup.. there should be a pseudo DB per package, not a master one
Mar 23 22:31:39 <fray> (there is a master one passed in, just so that pseudo doesn't "break")
Mar 23 22:31:48 <fray> ya, apparently
Mar 23 22:32:20 <seebs> oh, looky looky.  I have a series of "backing up ..." messages from the runqueue stuff.
Mar 23 22:32:26 <seebs> And a fork() call IN BETWEEN them.
Mar 23 22:32:48 <fray> yuck
Mar 23 22:33:40 <seebs> Okay, this is all my brain can take for now.
Mar 23 22:34:10 <seebs> I am going to start fresh on Monday, by undoing all my changes and diagnostics and restarting with a more focused effort looking at this specifically, because right now I am buried in irrelevant debugging output.
Mar 23 22:34:26 <fray> I understand..
Mar 23 22:34:35 <fray> before you go send an email to the list with what you tracked down
Mar 23 22:34:46 <fray> I'll add to it if I see anything missing
Mar 23 22:35:49 <otavio> When will oe-core be branched?
Mar 23 22:36:52 <fray> I believe soon... I've not been able to catch up with RP this week.. but I know there were some fixes earlier that may have pushed things back a few days..
Mar 23 22:43:43 <otavio> fray: so I can assume udev won't be update before the branching
Mar 23 22:44:14 <otavio> i am concerned because i.MX platforms still depends on 164 due the kernel versioning
Mar 23 22:44:51 <otavio> in this case I'll drop the duplicated recipe on the bsp layer and wait for the branching
Mar 23 22:46:09 <ant__> hm.. after updating the headers get    error: unknown type name '__aligned_u64'
Mar 23 22:46:24 <ant__> /usr/include/linux/if_packet.h:176
Mar 23 22:47:19 <ant__> iptables_1.4.12.2.bb, do_compile then fails
Mar 23 22:50:08 <otavio> ant__: i had this compilation problem as well; i am doing a build from scratch now to check if it fixes it or not
Mar 23 22:50:22 <ant__> mine is build from scratch
Mar 23 22:50:53 <otavio> ant__: bad news then heh
Mar 23 22:53:16 <ant__> 've seen a debian bug, let me google a bit
Mar 23 22:55:34 <ant__> ah, now I remember where I first saw it:
Mar 23 22:55:36 <ant__> [klibc] include: [sys/types.h] -> linux/types.h and __aligned_u64
Mar 23 22:55:53 <ant__> When building klibc 1.5.25 against linux/master (ie. post 3.1
Mar 23 23:10:03 <fray> otavio honestly, I'm out of touch this week.. so I don't know
Mar 23 23:17:26 <ant__> otavio, issue was aknowledged on Yocto ML
Mar 23 23:17:39 <ant__>  [yocto] iptables not building on master
**** ENDING LOGGING AT Sat Mar 24 02:59:58 2012

**** BEGIN LOGGING AT Sat Mar 24 02:59:59 2012
Mar 24 16:11:36 <RP__> otavio: I can confirm the udev version won't change for this release
Mar 24 18:21:45 <otavio> RP__: good; I'll cleanup our meta-fsl-arm in this case then
Mar 24 23:36:00 <ag> Hello everybody.
Mar 24 23:36:46 <ag> How can i check in the bb file if build has virtual/libx11
Mar 24 23:37:16 <ag> I want to add a tk (which depends on virtual/libx11) to python but inly conditionally if virtual/libx11 exists.
Mar 24 23:37:33 <ag> to add tk in depends*
Mar 24 23:41:58 <ag> Hmmm... i will use DEPENDS += "${@base_contains('DISTRO_FEATURES', 'x11', 'virtual/libx11', '', d)}"
**** ENDING LOGGING AT Sun Mar 25 02:59:58 2012

**** BEGIN LOGGING AT Sun Mar 25 02:59:58 2012
Mar 25 15:15:17 <ag> otavio: Hello.
Mar 25 15:15:38 <ag> I want to fix a udev warning regarding installed libraries.
Mar 25 15:16:02 <ag> The problem comes with libgudev-1.0.so.0.0.1 and udev-acl.
Mar 25 15:16:19 <ag> both want some libraries from /usr/
Mar 25 15:17:25 <ag> And this is why we have those ugly warnings. :)
Mar 25 15:18:46 <ag> Obviously there are 2 options here: move libgudev-1.0.so.0.0.1 and udev-acl or move the dependencies (libgobject, libffi, libgthread and libglib)
Mar 25 15:19:40 <ag> What do you guys think about this?
Mar 25 15:21:16 <ag> Uh there is another option: deactivate this QA test. :)
Mar 25 16:13:19 <khem> eventually everything will move to /lib its recipe for disater
Mar 25 16:13:49 <khem> using /lib was a mistake and we have been living with it for many many years and here at OE we are just promoting it
Mar 25 16:23:53 <ag> khem: Yeah... seems legit.
Mar 25 20:47:36 <Foray|33> anyone here?
Mar 25 20:48:23 <Foray|33> I was hoping I could ask someone a quick question about java support in Yocto.  Let me know if anyone is around.  Thank you
Mar 25 21:00:57 <seebs> In IRC, don't ask whether people are around, just ask your question.  Then leave yourself logged in for a week or so.  You might get an answer a day later when someone gets to work and checks the IRC logs.
Mar 25 21:36:43 <msm> there is a meta-java layer
Mar 25 22:04:37 <khem> always check layerindex http://www.openembedded.org/wiki/LayerIndex
Mar 25 22:05:03 <khem> on whats available, its not complete list of whats out there but fairly important pieces are there
Mar 25 22:22:57 <Foray|33> cool
Mar 25 22:39:53 <Foray|33> hey so if I get Yocto image built with core-oracle-master added in you get files /usr/java/ and /usr/jdk1.7.0_02/ - both of which have bin directories and a java executable in them.  but for some reason I simply can't execute them.  it's not a premissions thing. i call "root@sugarbay:/usr/java/bin# ./java "  and all I get is "-sh: ./java: No such file or directory"
Mar 25 22:41:12 <Foray|33> I've tried all sorts of other things too.  My quesiton is: where does the java executable reside by default and what should I add to my $PATH to make "java -version" return the version?
Mar 25 22:51:57 <khem> hmm dump the java binary and see what is reports for interpreter you can use readelf -e on build host itself
Mar 25 23:07:41 <Foray|33> thank you khem - let me do that one sec
Mar 25 23:24:15 <Foray|33> what exactly do you mean by "dump" the binary.  I'm copying the folders off the target onto a usb drive so I can use my ubuntu build machine to call "readelf" on the binaries.  Im sure there's a way to get at the binary from the project's build folder on my Ubuntu build machine but I'm not sure where it would be in the folder hierarchy
Mar 25 23:43:23 <Foray|33> hey so I copied it over and "readelf -e java" returns a bunch of info.  I see "Type: EXEC (Executable file)" so why can't I ever call it?
**** ENDING LOGGING AT Mon Mar 26 02:59:58 2012

**** BEGIN LOGGING AT Mon Mar 26 02:59:58 2012
Mar 26 06:01:17 <EBob> Hi All, was just playing with Yocto 1.2M3. Should Hob work for a qemuarm target?
Mar 26 08:07:36 <mckoan> good morning
Mar 26 10:10:12 <ag> Cheers!
Mar 26 10:10:41 <ag> Do we have any mechanism of "building" packages from recompiled rpms?
Mar 26 10:11:07 <ag> For example i want to use rpm-s, machine specific, from a previously finished build.
Mar 26 14:08:10 <autif> This seems like a pleasant surprise - was unionfs merged in the 3.2 kernel? I was using 3.0 and patched the kernel to have unionfs - however, it seems like unionfs is included in the 3.2 kernel. zeddii?
Mar 26 16:36:56 <JaMa> zeddii: I'm trying that ${S}/.scmversion now..
Mar 26 16:38:11 <zeddii> ok. cool. I'm suffering through a toolchain build at the moment :)
Mar 26 16:41:12 * JaMa is rebuilding world on gentoo host to optimize for bulldozer, but still some power left for qemux86-64 build ;)
Mar 26 17:31:29 <autif> This seems like a pleasant surprise - was unionfs merged in the 3.2 kernel? I was using 3.0 and patched the kernel to have unionfs - however, it seems like unionfs is included in the 3.2 kernel. zeddii?
Mar 26 17:34:51 <zeddii> autif, it's in the 3.2 yocto tree. not mainline.
Mar 26 17:34:59 <zeddii> I had more time in 3.2 and did some feature ports.
Mar 26 17:35:21 <autif> v v cool - and thanks!
Mar 26 17:35:51 <autif> I hope is that it will not go away :-)
Mar 26 17:36:11 <zeddii> it won't. or if union mount or something better merges, I'll figure out where to go after that.
Mar 26 17:56:07 <msm> is jefro on irc?
Mar 26 17:56:46 <msm> nvm
Mar 26 19:47:16 <seebs> Progress!  It finally occurred to me to check something I hadn't thought of.  And the answer is, somehow we're getting into popen with an environment partially set up, and the "antimagic" flag set also.  And I hadn't even thought of that code path.
Mar 26 19:48:37 <seebs> So it occurs to me that, even when we're trying to suppress all the fancy pseudo stuff, we need to do some environment setup/removal when calling anything that invokes fork(), such as popen() or fork().  Because otherwise we'll create child processes with invalid states.
Mar 26 19:49:09 <seebs> And this would explain why the LOCALSTATEDIR setting matters!
Mar 26 19:49:21 <seebs> Because a different LOCALSTATEDIR would mean needing to spawn a new server.
Mar 26 19:50:31 <fray> ahh
Mar 26 19:50:53 <seebs> I am still not quite sure what's happening, and that may not be it, but it's at least *plausible*.
Mar 26 19:52:23 <seebs> ohhh whaddya know
Mar 26 19:52:48 <seebs> There is a series of stuff in the client setup, which happens not to have any debug messages, so I wouldn't know I was in it.  And this series of stuff, it turns out, calls localstatedir_path().
Mar 26 19:53:01 <seebs> Which will fail if LOCALSTATEDIR *and* PREFIX are unset.
Mar 26 19:56:22 <seebs> Hmm, that may not be it.  But i have suspicions.
Mar 26 20:09:38 <seebs> ... No, wait, I'm still confused.
Mar 26 20:10:16 <seebs> Okay, in our initial setup, we've got pseudo loaded, but disabled.  That, I think, implies that we *should* be starting out with a value for PSEUDO_PREFIX.
Mar 26 20:10:45 <fray> and we are, it's in the bitbake wrapper..
Mar 26 20:10:53 <seebs> So there's still the question of why the setup/restore path ends up nuking it.  Because I think that's where the failure is coming from, really.
Mar 26 20:11:13 <fray> setup/restore in pseudo ro bb?
Mar 26 20:11:16 <seebs> bb
Mar 26 20:11:40 <seebs> In runqueue, there's a little loop that goes through checking current values, setting useful unes, then restoring the old values.
Mar 26 20:12:03 <seebs> But this ends up restoring None for PSEUDO_PREFIX.  Which means somehow it had gotten set to None previously.
Mar 26 20:12:20 <seebs> And then, when os.popen() bypasses this entirely and skips all the setup, we end up with an invalid state.
Mar 26 20:12:36 <fray> bitbake.conf:FAKEROOTENV = "PSEUDO_PREFIX=${STAGING_DIR_NATIVE}${prefix_native} PSEUDO_LOCALSTATEDIR=${PSEUDO_LOCALSTATEDIR} PSEUDO_PASSWD=${PSEUDO_PASSWD} PSEUDO_NOSYMLINKEXP=1 PSEUDO_DISABLED=0"
Mar 26 20:12:36 <seebs> And fixing the popen wrapper doesn't really help, because runqueue wiped out the prefix setting.
Mar 26 20:12:49 <fray> the FAKEROOTENV that gets set, includes those values
Mar 26 20:12:54 <seebs> Right.  But that's what we are setting (and then later unsetting) in runqueue.
Mar 26 20:13:05 <seebs> What's setting the initial environment *outside* all runqueue tasks?
Mar 26 20:13:31 <seebs> What runqueue is doing is, for each of those values, stashing the current value in a save table, setting the provided value, running something, then restoring the saved values.
Mar 26 20:13:44 <fray> did you add PSEUDO_PREFIX to the BB_ENV_WHITELIST or BB_ENV_EXTRAWHITE to see if it's kept?
Mar 26 20:13:51 <seebs> But if the current value for PSEUDO_PREFIX was None, then we end up setting PSEUDO_PREFIX to None, and that in turn breaks things.
Mar 26 20:13:57 <fray> you could do that and then remove it from the FAKEROOTEVN.. then it shouldn't be modified
Mar 26 20:14:19 <seebs> Which means that, probably, before we ever hit runqueue, we started out with PSEUDO_PREFIX set, and then something somewhere along the way unset it.
Mar 26 20:14:19 <fray> but pseduo (on a fork) is supposed to reload PSEUDO_PREFIX -- always, or so I thought
Mar 26 20:14:26 <fray> it's the localstatedir that can be overriden
Mar 26 20:15:10 <Crofton|work>   /join #zedboard
Mar 26 20:15:10 <seebs> I think there is a path where, if you have set PSEUDO_PREFIX in the environment, pseudo can helpfully realize that you were trying to remove it and remove the internal cached value or something.
Mar 26 20:15:18 <Crofton|work>  /join #zedboard
Mar 26 20:15:20 <fray> over the life of pseudo is there any reason that PSEUDO_PREFIX can change?
Mar 26 20:15:27 <seebs> Well, honestly... No.
Mar 26 20:15:34 <seebs> But I still want to know *how* this happened.
Mar 26 20:15:37 <fray> localstate can, cause that is the DB location
Mar 26 20:15:57 <seebs> So I'm trying to find out how, *before* the runqueue stuff, *outside* FAKEROOTENV/FAKEROOTNOENV, PSEUDO_PREFIX is getting set or unset.
Mar 26 20:16:07 <fray> if it's not in the ENV_WHITELIST, then bitbake whipes it from the environment as a sanitizing thing..
Mar 26 20:16:14 <fray> I would ahve expected pseudo to restore it though
Mar 26 20:16:40 <fray> PSEUDO_PREFIX is initially setup by the bitbake wrapper.. but since I don't remember it in the whitelist.. bitbake starts and clears it from the nevironment.. (I think)
Mar 26 20:16:45 <seebs> I think there's some circumstance we're hitting where it can't be restored.  In fact, that's definitely what's happening.
Mar 26 20:17:30 <seebs> Well, hmm.
Mar 26 20:17:40 <seebs> Maybe we should move that out of FAKEROOTENV to BB_ENV_EXTRAWHITE.
Mar 26 20:18:46 <seebs> Basically, I am not sure why this special rule is triggering this in a way that previous stuff didn't.
Mar 26 20:19:15 <seebs> It looks like it may just be a side-effect of something that isn't being properly saved and restored, and just happend not to get wiped until late in the build, after which we never happened to hit it again.
Mar 26 20:19:28 <seebs> But... I still don't really understand this call path, and I am therefore Very Concerned.
Mar 26 20:20:18 <fray> understand
Mar 26 20:22:15 <seebs> I think I am now pretty convinced that it's an error to be setting and unsetting PSEUDO_PREFIX, though.
Mar 26 20:23:30 <seebs> So it might make sense to move that into the unconditional setup list and see whether that helps.  If it does, I can then put in a bit of cleanup for fork() and popen().
Mar 26 20:24:12 <seebs> Eww
Mar 26 20:24:33 <seebs> That's an interesting new failure.
Mar 26 20:25:26 <seebs> Now pseudo failed to rebuild because x86-64 architecture of existing .o files is incompatible with i386 output.
Mar 26 20:26:02 <fray> sounds like you missed a "clean" in a multilib build
Mar 26 20:26:18 <seebs> Quite possible, but how does that even affect pseudo_native?
Mar 26 20:26:28 <seebs> er, pseudo-native.
Mar 26 20:26:43 <fray> if the system detects you have a multilib (host).. it will build both 32-bit and 64-bit versions of libpseudo..
Mar 26 20:27:05 <fray> on a rebuild, if it doesn't clean the last built.. then you get that wonderful error.. because the last build was say 32-bit, and first built in 64-bit.. bang/clash
Mar 26 20:28:14 <seebs> But how could changing BB_ENV_EXTRAWHITE affect that?
Mar 26 20:28:58 <fray> when you cange that, it triggers an automatic rebuild..
Mar 26 20:29:05 <fray> because the environment CAN affect the build of packages
Mar 26 20:29:32 <fray> BB variables and certain environment items are tracked in the checksums for each recipe's build steps..
Mar 26 20:29:52 <fray> (PSEUDO_PREFIX shouldn't be tracked though.. Hmm)
Mar 26 20:31:35 <seebs> Also, I get a ton of random stuff failing due to permission problems, meaning pseudo's not loaded when it should be.  I can't tell whether that's from my changes or was broken before.
Mar 26 20:31:39 <seebs> I'm gonna investigate more.
Mar 26 20:32:07 <fray> yup.. permissions issues = no pseudo
Mar 26 20:41:47 <seebs> Okay, it suddenly made sense.
Mar 26 20:42:19 <seebs> I found the thing I was missing; the implementation of PSEUDO_DISABLED is that during startup we add an extra layer of pseudo_antimagic().
Mar 26 21:54:55 <kergoth> is combo-layer used for poky, or are the component layers managed manually?
Mar 26 22:12:13 <kergoth> hmm, conftest.c:1:0: error: E500 and FPRs not supported
Mar 26 22:12:16 * kergoth googles
Mar 26 23:02:17 <JaMa> RP__: I've noticed that you've merged some of patches from last patchset, any reason to skip http://patchwork.openembedded.org/patch/24357/ ? this should be safe as it influences TOOLCHAIN_OUTPUTNAME only afaik
Mar 26 23:02:50 <RP__> JaMa: Coming up to release I suspect it will break the scripts :(
Mar 26 23:03:22 <JaMa> ok
Mar 26 23:04:48 <RP__> JaMa: I want to take more of the patches but I don't have the bandwidth to deal with any breakage :(
Mar 26 23:05:09 <RP__> JaMa: any breakage at this point would create a lot of pain :(
Mar 26 23:05:57 <JaMa> I see.. I was just curious as this looked pretty safe to me (but looking only on oe-core scripts)
Mar 26 23:06:12 <RP__> JaMa: I mean for the autobuilder and release management
Mar 26 23:06:18 <JaMa> if it's used in other ways in poky I didn't know
Mar 26 23:51:34 <kergoth> any opposition to adding -mfloat-gprs=double to the e500v2 tuning in oe-core? without this, you get "conftest.c:1:0: error: E500 and FPRs not supported" in configure compiler sanity checking. Note that the -te500v2 argument to the sourcery g++ toolchain turns on -mcpu=8548 -mfloat-gprs=double -mspe=yes -mabi=spe
Mar 26 23:51:44 <kergoth> hmm, msm isn't online, maybe i'll poke him about it tomorrow
Mar 27 00:04:04 <seebs> Hmm.
Mar 27 00:05:33 <seebs> I can confirm that we have the same flags for -te500v2 in ours.
Mar 27 00:07:17 <kergoth> well, either we need to pass -te500v2, or we need to add -mfloat-gprs=double, one of the two :)
Mar 27 00:07:24 <kergoth> cause right now we're missing that one piece
Mar 27 00:07:51 <seebs> Hmm.
Mar 27 00:08:12 * kergoth is spending some quality time in the power arch and e500 and qoriq and.. etc.. wikipedia pages, at the moment
Mar 27 00:08:20 <seebs> If -te500v2 has that meaning everywhere, I'd say use that because then if it needs to change it's more-standard.  Otherwise, use the specific flags so we aren't tied to a specific toolchain.
Mar 27 00:08:24 <seebs> I am very sorry to hear that.  :P
Mar 27 00:08:48 <kergoth> yeah, i'm not sure how portable that one is. it didn't seem to be in the power options list in the gcc docs i was looking at, but i'm uncertain
Mar 27 00:08:49 <seebs> I believe "help, these IEEE tests are failing on e500" is the single question I've been given the most often since I started at WR.
Mar 27 00:09:02 <kergoth> ugh
Mar 27 00:09:09 <seebs> CS does a lot of helpful -tfoo definitions.  They appear to be nearly always right, but not portable elsewhere.
Mar 27 00:09:16 * kergoth nods
Mar 27 00:09:20 <kergoth> thats what i was suspecting
Mar 27 00:09:25 <kergoth> they're convenient indeed
Mar 27 00:09:47 <kergoth> trying to beat meta-fsl-ppc into submission a bit
Mar 27 00:13:44 <kergoth> damn, i need to fix up the multilib section determination in tcmode-external-csl. not all are covered at the moment
Mar 27 00:13:50 <kergoth> e.g. powerpc-nf
Mar 27 00:15:27 <kergoth> should probably go by TUNE_FEATURES rather than TUNE_PKGARCH, but will see
Mar 27 00:15:29 * kergoth wanders off
Mar 27 02:17:14 <msm1> kergoth: that sounds freescale-ish
Mar 27 02:22:19 <kergoth> msm1: hey, didn't see you hop on. thoughts on getting -mfloat-gprs=double into the e500v2 tunings? run into problems without it. need to either pass that or -te500v2 with a csl toolchain, it seems. run into this at all?
Mar 27 02:22:49 <msm1> not really sure about the option
Mar 27 02:22:55 <msm1> kergoth: i can ask the toolchain folks
Mar 27 02:22:58 <msm1> whats not building?
Mar 27 02:23:18 <kergoth> nothing builds, not even libtool-cross. seeing "conftest.c:1:0: error: E500 and FPRs not supported"
Mar 27 02:24:12 <kergoth> seems to be the use of the spe tuning without float-grps set hits this. if you drop spe and add fpu-soft, it builds, or if you set the spe args with float-gprs then it builds
Mar 27 02:24:19 <kergoth> here anyway, note this is using the csl toolchain, not internal
Mar 27 02:24:32 <kergoth> maybe it behaves differently. *shrug*
Mar 27 02:24:38 * kergoth still is a power noob :)
Mar 27 02:24:57 <msm1> we had some issues like this going from CSL toolchain to the yocto one
Mar 27 02:24:59 <msm1> hehe
Mar 27 02:25:14 <msm1> im not even 100% sure what's going on there
Mar 27 02:25:28 <msm1> i think we could conditionally add what you are saying for the CSL toolchain
Mar 27 02:27:08 <msm1> im also not sure what is appropriate
Mar 27 02:27:17 <msm1> we should ask both our toolchain folks
Mar 27 02:27:22 <kergoth> yeah, agreed
Mar 27 02:27:34 <msm1> i can give your our guys email to CC on
Mar 27 02:27:45 <kergoth> that'd work
**** ENDING LOGGING AT Tue Mar 27 02:59:58 2012

**** BEGIN LOGGING AT Tue Mar 27 02:59:58 2012
Mar 27 07:29:33 <mckoan> good morning
Mar 27 07:31:53 <bluelightning> morning all
Mar 27 09:57:19 <Zagor> what license are the recipe files themselves distributed under?
Mar 27 10:10:24 <bluelightning> Zagor: see LICENSE in the root source dir
Mar 27 10:10:26 <ag> Any ideas why if i have virtual/xserver in the rdepends of a package, that package won't make this package end in the rootf?
Mar 27 10:10:40 <ag> Even after defining rdepends in xserver-xorg/
Mar 27 10:10:41 <ag> ?
Mar 27 10:12:13 <ag> sorry rprovides*
Mar 27 10:15:50 <ag> And another strange thing: in the final rpms i got virtual/xserver and virtual/libgl in the REQUIRENAME info...
Mar 27 10:16:01 <ag> So these are not substituted.
Mar 27 10:20:20 <bluelightning> ag: they won't be no... R* variables are not just for rootfs construction time, they are for runtime as well
Mar 27 10:21:36 <ag> bluelightning: Come again please?
Mar 27 10:22:18 <bluelightning> RPROVIDES, RDEPENDS etc. go straight to the packaging system... how they are dealt with them after that is up to the package manager
Mar 27 10:23:06 <bluelightning> s/them//
Mar 27 10:23:45 <ag> Hmm...
Mar 27 10:24:16 <ag> So what you say is that there is no way to rdepends on a virtual?
Mar 27 10:25:33 <bluelightning> typically if you want to make such "virtual" decisions at build time, variables are used
Mar 27 10:25:43 <bluelightning> e.g. grep for VIRTUAL-RUNTIME
Mar 27 10:25:48 <bluelightning> git grep that is
Mar 27 10:29:32 <ag> bluelightning: That makes sense.
Mar 27 10:30:05 <ag> So the basic idea is that virtuals are used only at building stage.
Mar 27 10:47:51 <bluelightning> ag: yes, that's the way we do it at the moment
Mar 27 10:48:11 <ag> bluelightning: Thank you.
Mar 27 11:09:59 <ag> bluelightning: Another way to do it wouldn't be just to add ${PREFERRED_PROVIDER_virtual/XXX} to RPROVIDES? I think this would do the trick.
Mar 27 11:10:22 <ag> Why would i want another variable like VIRTUAL-RUNTIME that'd do the same thing?
Mar 27 11:10:37 <ag> Or maybe there is something i didn't understand.
Mar 27 11:10:59 <bluelightning> ag: except PREFERRED_PROVIDER is for build-time dependencies
Mar 27 11:11:30 <bluelightning> i.e. recipes as opposed to packages
Mar 27 11:14:04 <ag> bluelightning: Ok. Let's make it a little more clear. If i have a package that needs X at runtime but only libgl at build time how would i instruct my image to include X if this package is included.
Mar 27 11:14:17 <ag> ?
Mar 27 11:14:53 <bluelightning> if your package has RDEPENDS on X then it should be included in the rootfs
Mar 27 11:14:58 <bluelightning> if that is not happening it is a bug
Mar 27 11:15:38 <ag> GOod. But what if this X is a virtual to xorg-server-lite or xorg-server
Mar 27 11:15:45 <ag> This is my case.
Mar 27 11:16:19 <ag> An by the way i just tested ${PREFERRED_PROVIDER_virtual/XXX in RDEPENDS and it works.
Mar 27 11:16:32 <ag> It makes xserver-xorg to be in the final rootfs.
Mar 27 11:16:52 <bluelightning> but you should not do that, because it is not guaranteed that build time dependencies will match up with runtime ones
Mar 27 11:17:00 <bluelightning> i.e. it is not good practice
Mar 27 11:17:11 <ag> Yes. But what alternative do i have?
Mar 27 11:18:00 <bluelightning> does this package you are building actually link to the X libraries?
Mar 27 11:18:24 <ag> Only to libgl.
Mar 27 11:18:36 <ag> It needs X server to run on it.
Mar 27 11:19:26 <bluelightning> well, it needs a gl context... but your gl library should be linked to X surely?
Mar 27 11:20:48 <ag> And here is another problem. libgl is precompiled from the vendor. Is is not linked to anything.
Mar 27 11:21:06 <ag> It provides libgl and and nothing more.
Mar 27 11:21:50 <bluelightning> my inclination in this case would be to pull in X from the image itself
Mar 27 11:22:12 <bluelightning> it really isn't your application that needs X...
Mar 27 11:22:17 <ag> Yeah... that is my thought as well..
Mar 27 11:22:18 <bluelightning> not directly anyway
Mar 27 11:22:30 <ag> But hoped for a better solution.
Mar 27 11:22:39 <ag> Yes include it as virtual.
Mar 27 11:22:49 <ag> In a task or something.
Mar 27 11:23:01 <ag> I think this is the only solution.
Mar 27 11:23:22 <bluelightning> well, when we build our own libgl it gets linked to X libraries I think; plus we tend to pull in other things that directly depend on X
Mar 27 11:23:28 <bluelightning> so we don't hit this problem often
Mar 27 11:23:37 <ag> I know.
Mar 27 11:23:50 <ag> Ok. Thank you very much.
Mar 27 11:23:58 <bluelightning> np
Mar 27 12:00:21 <Jay7> RP__: ping
Mar 27 12:00:52 <Jay7> iirc, you was tried to store bitbake tasks log in bootchart-compatible way
Mar 27 12:01:10 * Jay7 is trying to find this bbclass
Mar 27 12:11:04 <RP__> Jay7: buildstats
Mar 27 12:11:23 <RP__> Jay7: It was using a hacked ubootchart as the analysis tool
Mar 27 12:11:30 <RP__> Jay7: the format is different
Mar 27 12:22:52 <Jay7> RP__: is it in oe-core now?
Mar 27 15:57:46 <RP__> Jay7: the ubootchart patches are on the mailing list somewhere
Mar 27 16:36:21 <seebs> fray's helping me sanity-check the pseudo fixes, but with any luck I should have them available for review/checkin/whatever later today.
Mar 27 16:39:56 <bluelightning> seebs: great work, this one was a tricky one to isolate...
Mar 27 16:40:03 <seebs> Well, honestly.
Mar 27 16:40:21 <seebs> The only reason it took me more than the initial twenty minutes was that I spaced off the half-baked PSEUDO_DISABLED implementation.
Mar 27 16:40:45 <fray> but you know have more of an understanding of the run path through bitbake
Mar 27 16:40:51 <seebs> Really, some day, I should fix it so that we use the check against pseudo_disabled *instead of* the crufty antimagic hack, instead of having both in there.
Mar 27 16:41:54 <seebs> The hack of setting antimagic if PSEUDO_DISABLED was set was a quick proof of concept, then we added the streamlined check earlier in the process -- but actually that's good enough and we should just be doing that instead.
Mar 27 17:49:48 <ag> Anybody who can give me some infos about meta-ti?
Mar 27 17:49:56 <ag> Koen or somebody?
Mar 27 17:50:40 <ag> The meta-ti layers seems to have no support for GPU driver for pandaboard SGX540?
Mar 27 17:50:48 <ag> Any ideas n this topic?
Mar 27 17:50:50 <ag> on*
Mar 27 17:52:58 <ag> khem: denix?
Mar 27 18:13:29 <kergoth> hmm, do sstate/rm_work still have bad interactions?
Mar 27 18:46:13 <kergoth> i take it people saw http://www.marketwatch.com/story/mentor-embedded-continues-to-simplify-linux-and-open-source-development-with-support-of-the-yocto-project-2012-03-27 :)
Mar 27 18:48:09 <kergoth> why does gmail always categorize robert p.j. day's email as Bulk? it's only his
Mar 27 18:49:27 <autif> funny - I get his mail just fine.
Mar 27 18:50:01 <kergoth> i get it too, it's not spam, it's categorizing it as bulk -- the auto categorization thing where it categorizes forums/bulk/etc
Mar 27 18:50:27 * kergoth reports miscategorization
Mar 27 18:50:37 <denix> kergoth: I think there is a higher reason... :)
Mar 27 18:50:44 <kergoth> hehe
Mar 27 18:50:51 <kergoth> i wasn't going to say anything..
Mar 27 18:52:34 <seebs> http://imgur.com/5QitJ
Mar 27 19:31:50 <khem> kergoth: I do not use rm_work anymore
Mar 27 19:32:10 <khem> ag: I would not have any idea about meta-ti
Mar 27 19:33:13 <denix> khem: what ideas do you need?
Mar 27 19:42:09 <khem> denix: the idea about the question ag asked
Mar 27 19:42:25 <khem> I do have idea about a lot in the layer but not that
Mar 27 19:42:45 <denix> :)
Mar 27 19:42:50 <denix> share your ideas!
Mar 27 19:42:57 <denix> and what was the question?
Mar 27 19:47:05 <khem> The meta-ti layers seems to have no support for GPU driver for pandaboard SGX540? Any ideas n this topic?
Mar 27 19:47:46 <khem> so I do have ideas about the SGX540 but not in meta-ti context you see my point now
Mar 27 19:52:07 <denix> ah, graphics is not yet enabled for omap4 in meta-ti...
Mar 27 20:26:13 <xumbi> greetings!  does anyone have qt 4.8.0 building successfully for arm?
Mar 27 20:27:18 <JaMa> ye
Mar 27 20:27:19 <JaMa> s
Mar 27 20:39:28 <xumbi> JaMa: any particular combination of poky branch and layers?
Mar 27 20:40:16 <JaMa> I'm using oe-core only or oe-core+meta-oe+lot-more-layers
Mar 27 20:40:23 <JaMa> and it builds in both for me
Mar 27 20:41:03 <xumbi> ok glad to hear it, I'll be going down the road of trying to get it building for an OMAP3 based device soon
Mar 27 21:19:05 <anguiano> mranostay: Howdy (delayed response by almost a month.)
Mar 27 21:21:27 <mranostay> heh
**** ENDING LOGGING AT Wed Mar 28 02:59:58 2012

**** BEGIN LOGGING AT Wed Mar 28 02:59:59 2012
Mar 28 03:53:44 <mebrown> question: I have a BBCLASSEXTEND="native" recipe where I have to conditionally add an "-march=i686" only if the build system is 32-bit. How do I go about it? I currently have:
Mar 28 03:53:47 <mebrown> CXXFLAGS_virtclass-native="-march=i686 -I${STAGING_INCDIR}"
Mar 28 03:54:16 <mebrown> but that busts on 64-bit, so I need a way to conditionalize the -march=i686 part to only appear if build system is 32-bit
Mar 28 04:02:30 <mebrown> to answer my own question, this appears to work: "${@bb.utils.contains("PACKAGE_ARCH", "i686", "-march=i686", "", d)}"
Mar 28 07:06:58 <ag> thank you denix and khem
Mar 28 07:50:59 <mckoan> good morning
Mar 28 12:04:35 <JaMa> any hint why pseudo-native is upgraded in so many parallel threads? http://paste.pocoo.org/show/572491/
Mar 28 12:05:55 <JaMa> nvm it was still parsing
Mar 28 20:03:53 <autif> I have working webkit based browser(s) on my hardware (crownbay). I get graphics acceleration when I run stuff (glxgears, video using gst-launch) outside the browser, however, inside the browser, I do not get any graphics acceleration (tested it with corwnbay and crownbay-noemgd). What is the place to start figuring out why not?
Mar 28 20:04:29 <autif> I have checked the build logs and ensured that webkit links with gstreamer libraries - same libraries used by gst-launch
Mar 28 20:05:37 <autif> I have added a few extra configuration options (--enable-3d-rendering, --enable-animation-api)
Mar 28 20:05:43 <autif> and they do not seem to work
Mar 28 20:06:58 <autif> when I run the same browser (using Ubuntu's libwebkit and libgstreamer) I do get acceleration - so it is definitely something in webkit that needs tweaking
Mar 28 20:11:38 <khem> autif: Can you post the config logs somewhere
Mar 28 20:11:48 <khem> it seems to me as if its a problem in config
Mar 28 20:13:43 <autif> will do
Mar 28 20:17:15 <autif> configure logs for webkit - http://pastebin.com/g0wA3Eg3
Mar 28 20:17:20 <autif> khem
Mar 28 20:21:23 <khem> autif: I will take a look after I grab some food
Mar 28 20:23:56 <autif> thanks khem :0(
Mar 28 20:23:59 <autif> :-)
Mar 28 20:24:12 <autif> stupid typo
Mar 28 20:26:48 <mebrown> clown noses ftw!
Mar 28 21:01:55 <khem> autif: checking whether to enable support for 3D Rendering... no
Mar 28 21:02:03 <khem> that seems an issue here
Mar 28 21:10:13 <autif> hmmmn - I might need to do a clean (overnight) build - let me start that off and I will share what happens tomorrow. Thanks khem
Mar 28 21:13:59 <khem> ok
Mar 28 21:14:13 <khem> you need to check how its doing the test
Mar 28 21:14:30 <khem> to determine 3D enable/disable decision
Mar 28 21:14:54 <khem> it could be a simple braindead configure check which fails when we cross compile
Mar 28 21:15:22 <khem> since they might be poking at the hardware you run on which obviously is a no no in cross build env
Mar 28 21:15:39 <khem> I dont have a webkit-gtk sources handy to look atm
Mar 28 21:19:16 <khem> autif: the configure is not doing much there
Mar 28 21:19:27 <khem> did you pass --enable-3d_rendering to configure ?
Mar 28 21:19:30 <khem> if not then try that
Mar 28 21:20:27 <seebs> Idle question:
Mar 28 21:20:33 <seebs> Does anyone but me EVER use PSEUDO_DEBUG output?
Mar 28 21:21:33 <khem> seebs: pseudo uses everyone. you are the one who uses pseudo :)
Mar 28 21:21:42 <seebs> Heh.
Mar 28 21:22:06 <khem> in other words if it works no one touches it ever
Mar 28 21:22:10 <seebs> I'm thinking about doing a major cleanup pass in which I try to replace "debugging messages I ever needed to debug something are level 2" with some kind of coherent debugging rules.
Mar 28 21:22:25 <khem> sounds sane
Mar 28 21:22:32 <seebs> Because I've had at least a couple of things come to me where the diagnostics actually answered the question, but only I could read them.
Mar 28 21:23:53 <seebs> And for instance, right now you can't get decent logging on function call paths without a ton of information about IPC, and vice versa, and it turns out you basically never care about both at once.
Mar 28 21:24:19 <seebs> Every debugging mechanism I design goes through the same cycle.  I introduce it.  Then I realize it needs debugging levels.  Then I realize it needs non-ordered flags.
Mar 28 21:24:30 <seebs> SOME DAY, I am totally going to do it right out of the box.
Mar 28 21:24:32 <khem> actually a verbose mode where it tells me what call was captured and how it was dispatched would be nice
Mar 28 21:24:40 <khem> since strace wont help with pseudo
Mar 28 21:25:12 <seebs> We SORT of have that.
Mar 28 21:25:31 <seebs> It's in the PSEUDO_DEBUG=4 output, and you just have to only read about every 60th line of the output.
Mar 28 21:26:11 <seebs> I mean, geeze, why are you people so LAZY.
Mar 28 21:26:26 <fray> heh
Mar 28 21:27:31 <seebs> Actually, it's not that bad for some stuff.
Mar 28 21:27:50 <seebs> I mean, you can get thousands of lines of called/completed stuff.
Mar 28 21:27:58 <seebs> All in a row.  With no context.  :P
Mar 28 21:28:18 <kergoth> hey, that sounds like bitbake's debug output :)
Mar 28 21:28:35 <seebs> I still love that I have to use raw errno because there was a system on which strerror() invoked locale stuff and this caused horrible clashes.
Mar 28 21:28:44 <seebs> But hey.  An experienced Unix developer usually recognizes common errno values.
Mar 28 21:29:00 <kergoth> and if they don't, it's not hard to grep the header :)
Mar 28 21:29:04 <seebs> I'm sad that the BSD errno script I wrote doesn't work on most Linuxes.
Mar 28 21:29:10 <seebs> $ errno 9
Mar 28 21:29:10 <seebs> EBADF [9]:             Bad file descriptor
Mar 28 21:29:41 <seebs> A lot of Linuxes have errno values somewhere other than sys/errno.h itself.
Mar 28 21:30:33 <kergoth> cute
Mar 28 21:31:25 <seebs> I keep planning to fix that.  I have only been thinking about fixing it since... uhm... 1998 or so.  So it'll happen Real Soon Now.
Mar 28 21:32:04 <seebs> hmm
Mar 28 21:32:05 <fray> a simple C program.. strerror should also work
Mar 28 21:32:26 <seebs> It's not as easy as it sounds to get the symbolic names, because there's no way to get a list of the symbolic names in C.
Mar 28 21:32:32 <fray> I had written something like that a few years back..
Mar 28 21:32:32 <seebs> It's easy with awk on errno.h.
Mar 28 21:32:44 <kergoth> hmm, having ${PN} in AUTO_LIBNAME_PKGS results in -doc/-dev/etc being renamed too? weird, that doesn't seem correct
Mar 28 21:32:58 <seebs> Huh.  It occurs to me:  I don't think there's any context anywhere where I want to call setupenv and not also call dropenv if UNLOAD is set.
Mar 28 21:32:58 <fray> what I had done is collect all of the "known" linux errno, put them into a table.. then I could reference the table and pull them back out..
Mar 28 21:33:02 <fray> something like:
Mar 28 21:33:11 <fray> #ifdef EBADF
Mar 28 21:33:24 <fray> { "EBADF", EBADF }
Mar 28 21:33:27 <fray> #endif
Mar 28 21:33:44 <fray> (this was in the context of fixing perls completely broken configuration mechanisms)
Mar 28 21:34:33 <khem> seebs: on lnx the errno vals are in /usr/include/asm-generic/errno.h
Mar 28 21:34:44 <fray> khem, not all of them.. just a lot of them
Mar 28 21:34:58 <khem> fray: hmmm really
Mar 28 21:35:02 <khem> where are the rest
Mar 28 21:35:16 <seebs> Also asm-generic/errno-base.h
Mar 28 21:35:19 <fray> ya.. there are some values that vary from machine to machine.. (i.e. MIPS is an odd one)..
Mar 28 21:35:29 <fray> so just awking that won't necessarily work either
Mar 28 21:36:04 <seebs> ooh, nice.
Mar 28 21:36:20 <seebs> If I cat /usr/include/asm-generic/errno*.h into my awk, it's Good Enough.
Mar 28 21:36:41 <seebs> huh, my connection to the office just got super slow.  fray, is that cat downloading kitty porn again?
Mar 28 21:36:43 <khem> seebs: yes that file too
Mar 28 21:36:59 <fray> AFAIK, no current downloads
Mar 28 21:37:08 <khem>  seebs connection usually become slow when uploading :)
Mar 28 21:37:36 <khem> I put some gcc testusite logs on my webserver and I realized it was a bad idea
Mar 28 21:37:56 <fray> at the (new) office.. we have 8 Mbit down/6 Mbit up..
Mar 28 21:38:00 <fray> so speed usually isn't a problem
Mar 28 21:38:55 <khem> 1002 unread threads
Mar 28 21:39:00 <khem> way to go
**** ENDING LOGGING AT Thu Mar 29 02:59:58 2012

**** BEGIN LOGGING AT Thu Mar 29 02:59:58 2012
Mar 29 08:00:45 <mckoan> good morning
Mar 29 12:26:31 <Zagor> how do I add an attribute to CoreRecipeInfo? I tried this http://pastebin.com/y6hRxabE but get "AttributeError: 'CoreRecipeInfo' object has no attribute 'homepage'" on that last line
Mar 29 13:18:42 <JaMa> RP__: ping
Mar 29 13:18:57 <JaMa> I'm fine with cleaning that up but lets continue to use tabs for shell
Mar 29 13:18:57 <JaMa> and spaces for python where at all possible, then we're consistent :)
Mar 29 13:19:08 <JaMa> by that you mean use spaces for shell and tabs for python right?
Mar 29 13:30:01 <JaMa> because 4 spaces in populate_packages_preppend breaks populate_packages parsing..
Mar 29 13:38:12 <bluelightning> JaMa: unfortunately we have python code that uses tabs such as do_populate_packages :/
Mar 29 13:38:41 <JaMa> so what was wrong on my replace of few spaces with tabs?
Mar 29 13:39:25 <bluelightning> well, four spaces should be used for python except where we have "bad" python in the procedure being appended/prepended
Mar 29 13:39:57 <bluelightning> for shell I honestly don't know how we ended up with tabs being the convention but apparently that's the rule we have
Mar 29 13:46:28 <RP__> Its certinaly what I've been telling people for a long time...
Mar 29 13:49:09 <RP__> https://wiki.yoctoproject.org/wiki/Recipe_%26_Patch_Style_Guide#White_Space_Management
Mar 29 14:07:36 <JaMa> ok sending v2
Mar 29 14:31:00 <kergoth> hmm
Mar 29 14:31:01 <kergoth> | Running useradd commands...
Mar 29 14:31:01 <kergoth> | useradd: cannot lock /etc/passwd; try again later.
Mar 29 14:31:01 <kergoth> NOTE: package openssh-5.9p1-r3.3: task do_install: Failed
Mar 29 14:58:48 <RP__> kergoth: do you have the recent patch applied for that?
Mar 29 15:05:15 <kergoth> depends on how recent, our last update from upstream layers was a week ago or so, avoiding any further ones due to imminent release. will take a look at the last week's history
Mar 29 15:05:50 <kergoth> aha, from march 22nd, i see
Mar 29 15:05:55 <kergoth> will pull that in, thanks
Mar 29 15:08:40 <Zagor> gosh, all this head scratching only to find I need to remove tmp/cache/default-eglibc/<machine>/bb_cache.dat for cache.py to accept new attributes
Mar 29 15:09:16 <Zagor> that appears to me like a rather odd location for a global bb cache
Mar 29 15:15:00 <fray> a coworker who is playing with Poky isn't able to login.  I seem to remember there was a configuration option or something that set the root pw to blank..
Mar 29 15:15:09 <fray> is that true, if so anyone remember what/how that is done?
Mar 29 15:25:06 <Crofton|work> root pw might be blank and the dm might nopt accept blank
Mar 29 15:25:14 <Crofton|work> try logging in via serial;
Mar 29 15:32:14 <fray> I found it..
Mar 29 15:32:40 <fray> it's IMAGE_FEATURES += debug-tweaks, which in turn sets ROOTFS_POSTPROCESS_COMMAND += "zap_root_password ; "
Mar 29 15:32:53 <fray> I tried just the ROOTFS_POSTPROCESS_COMMAND, but it didn't seem to take.. but image_features works
Mar 29 15:33:24 <fray> (we're logging in via the console BTW.. checked the image and root entry was: root:x:0:0:root:/home/root:/bin/sh)
Mar 29 15:44:26 <RP__> fray: right, sounds like debug-tweaks was turned off
Mar 29 15:45:37 <fray> yup.. what is odd though is that setting just the ROOTFS_... += didn't work though..
Mar 29 15:45:44 <fray> so something later must be "setting" it vs appending
Mar 29 16:05:47 <autif> khem - ping
Mar 29 16:07:52 <khem> autif: yes
Mar 29 16:10:09 <autif> I did a clean build with the new flags in webkit - here is the log.do_configure http://pastebin.com/s8LtgPxe - still no video acceleration or canvas acceleration
Mar 29 16:17:50 <khem> autif: I left few more messages yesterday about this issue
Mar 29 16:17:53 <khem> did you go through them
Mar 29 16:18:23 <autif> yes, I still need to look at the configure script to see what the script is doing
Mar 29 16:18:23 <khem> ah ok so now you have 3D rendering enabled
Mar 29 16:18:33 <autif> I have not seen that yet
Mar 29 16:18:40 <autif> I will and report back
Mar 29 16:18:42 <khem> I see it in your log
Mar 29 16:20:18 <autif> yes, I appended EXTRA_OECONF to the recipe with --enable-media-stream --enable-3d-rendering --enable-animation-api
Mar 29 16:20:31 <autif> that triggered the "No" to "Yes" I am guessing
Mar 29 16:28:10 <khem> autif: ok. I think this should have helped if the issue was in webkit
Mar 29 16:28:17 <khem> it seems issue is elsewhere
Mar 29 16:28:31 <khem> what are you trying when testing this
Mar 29 16:30:06 <autif> I go to this webpage - http://www.smashcat.org/av/canvas_test/ - I get about 55 fps on Ubuntu (using libwebkit that came with Ubuntu) and get only 2-3 fps on crownbay
Mar 29 16:31:46 <khem> ok so thats a html5 test
Mar 29 16:33:00 <autif> yes it is
Mar 29 16:33:07 <autif> canvas specifically
Mar 29 16:34:03 <autif> status meeting - be back in 45-90 will review your comments - if you leave them here - apologies. Also - thanks for all the help :-)
Mar 29 18:09:27 <kergoth> ugh, what the hell, now it's failing to useradd after 10 attempts
Mar 29 18:09:32 * kergoth checks for bbappends
Mar 29 18:12:42 <kergoth> no bbappends that touch do_install
Mar 29 18:12:45 * kergoth scratches head
Mar 29 18:15:02 * kergoth sighs
Mar 29 18:15:10 <kergoth> anyoen that knows the useradd stuff well?
Mar 29 18:22:50 <seebs> I would say that, if I were to rate my knowledge of useradd on a scale from one to ten, I would probably have a reasonable starting value for epsilon.
Mar 29 18:23:06 <seebs> One of my friends, who is a math geek, once told me a beautiful math joke.
Mar 29 18:23:11 <seebs> "Let epsilon be less than zero..."
Mar 29 19:18:38 <JaMa> kergoth: do you have a sec for python 2to3 question?
Mar 29 19:22:33 <JaMa> opkg-make-index was using "print pkg" and switching sys.stdout to Packages file if requested, with python3 it seems to get close() on stdout sometimes and later prints failing, so I've changed it to "print >>pkgsFile, pkg" and it works fine with python2 and also seems to make it much faster (like oe-classic version was)
Mar 29 19:22:56 <JaMa> but that doesn't work with python3 "TypeError: unsupported operand type(s) for >>: 'builtin_function_or_method' and '_io.TextIOWrapper'"
Mar 29 19:23:03 <JaMa> so I'm looking for way to fix it properly
Mar 29 19:25:03 <kergoth> print is a function in python 3.
Mar 29 19:25:10 <kergoth> it has an argument to specify the file to send it to
Mar 29 19:25:34 <JaMa> I mean, can I use something to be compatible with both 2 and 3?
Mar 29 19:30:24 <seebs> I had sort of gotten the impression that the primary goal of Python language design was to force everyone to use the same version as everyone else by systematically hunting down compatibilities and destroying them.  :P
Mar 29 19:36:54 <kergoth> JaMa: 3 is by design incompatible with 2. that was the point.
Mar 29 19:37:02 <kergoth> thats why it jumped to 3
Mar 29 19:37:19 <kergoth> there are ways to try to retain compatibility, and there's ways to use distutils/setuptools to auto-run 2to3 or 3to2 on systems with the other version
Mar 29 19:41:28 <JaMa> kergoth: yes but at least print('blah') works also with python2.7
Mar 29 19:41:36 <JaMa> so I was hoping for some compromise
Mar 29 19:44:18 <kergoth> JaMa: print() does, but the arg to pass to a different file i'm pretty sure is 3 only. you can avoid the entire issue by just changing to code to write to a file object rather than using print() entirely
Mar 29 19:44:27 <kergoth> foo.write("bar\n")
Mar 29 19:46:09 <JaMa> I've used that for generating Package.filelists, but here it was failing with "TypeError: expected a character buffer object"
Mar 29 19:46:25 <kergoth> then you're doing something else wrong
Mar 29 19:46:54 <kergoth> or there's a unicode issue, might need to encode when writing to a file
Mar 29 19:46:59 <kergoth> i haven't messed iwth python3 much
Mar 29 19:47:15 <JaMa> maybe because it's writing "class Package" >
Mar 29 19:47:16 <JaMa> ?
Mar 29 19:48:19 <kergoth> ?
Mar 29 19:48:23 <JaMa> but I guess I can call __repr__ somehow
Mar 29 19:48:36 <JaMa> pkg is instance of Package
Mar 29 19:48:36 <kergoth> oh, you tried to foo.write(someobject)?
Mar 29 19:48:40 <kergoth> that wouldn't make any sense
Mar 29 19:48:58 <JaMa> that's why it was justing print someobject I guess
Mar 29 19:48:59 <kergoth> you'd have to make sure it implements __str__() and use str(foo) when writing, or something
Mar 29 19:49:09 <kergoth> or just have the method write the lines to a passed file object
Mar 29 19:49:24 <kergoth> object.write(sys.stdout)
Mar 29 19:49:26 <kergoth> or whatever
Mar 29 19:49:35 <kergoth> but i lack sufficient context to give any real advice on that
Mar 29 19:49:53 <JaMa> that's in __repr__ method
Mar 29 19:50:25 <JaMa> it's this script http://git.yoctoproject.org/cgit/cgit.cgi/opkg-utils/tree/opkg-make-index
Mar 29 19:52:21 <kergoth> repr() is supposed to be used to get a representation of the object close to python syntax needed to reconstruct the object
Mar 29 19:52:29 <kergoth> __str__/str is for general string form
Mar 29 19:52:43 <JaMa> and here are some of my fixes on top of that https://github.com/shr-project/opkg-utils/commits/jansa/2to3
Mar 29 19:57:09 <JaMa> kergoth: thanks, works better now :)
Mar 29 19:58:28 <kergoth> np
Mar 29 20:52:14 * kergoth works on some bits to deal with non-target recipe shared state reuse concerns
Mar 29 21:08:59 <RP__> kergoth: what kind of concerns out of interest?
Mar 29 21:26:55 <kergoth> RP__: some of the stuff brought up by matthew in the mailing list thread regarding inclusion of distro/version in the checksums. wanting to be able to define compatible distros / fallback in some way, and the like
Mar 29 21:43:29 <RP__> kergoth: ah, right. Its a hard problem :/
Mar 29 21:44:50 <kergoth> i'm toying around with some code that adds /${BUILD_DISTRO}-${BUILD_DISTRO_VER}/ to SSTATE_DIR, then adds the parent dir to SSTATE_MIRRORS, then sstate_create_package_append which moves the target recipes up to the parent, so only the native/cross/etc remain in the host-bound area
Mar 29 21:45:15 <kergoth> then i iterate over SSTATE_MIRRORS and inject modified mirror uris with BUILD_DISTRO/VER appended, to support that structure on mirrors
Mar 29 21:45:23 <kergoth> then i stop injecting BUILD_DISTRo/BUILD_DISTRO_VER into the checksums
Mar 29 21:45:49 <kergoth> the mirror iteration then supports specification of fallbacks, so you could add a known old host there and know that its safe to use those on all machines
Mar 29 21:45:57 <kergoth> not ideal, but i think it may work
Mar 29 21:47:44 <RP__> kergoth: Could you add those to SSTATE_PKGARCH in the anonymous python at the top of sstate.bbclass ?
Mar 29 21:48:11 <kergoth> true, didn't think about that
Mar 29 21:48:14 <kergoth> hmmmm
Mar 29 21:48:28 <kergoth> the thing is, if the filenames differ, then fallback is very difficult
Mar 29 21:48:49 <kergoth> if the filenames are the same, but structure differs, then you can easily cahnge the structure. slightly less simple to mangle the filename
Mar 29 21:48:54 <kergoth> hmm
Mar 29 21:48:59 <RP__> symlinks?
Mar 29 21:49:12 <RP__> I'm just thinking out loud...
Mar 29 21:49:14 <kergoth> you'd have to mangle the filename to get the symlink destination path
Mar 29 21:50:14 <kergoth> possibly doable. i do think structure makes it easier than filename, though
Mar 29 21:50:15 * kergoth ponders
Mar 29 21:50:29 <kergoth> i'll toy with it after i finish whacking this prototype into shape
Mar 29 21:50:47 <RP__> kergoth: You could append to SSTAGE_DIR in that same anonymous python
Mar 29 21:50:57 <RP__> (in the native/cross cases)
Mar 29 21:51:45 <RP__> then you'd just have to write a suitable mirrors url and the code should work otherwise as is
Mar 29 21:53:53 <kergoth> true, that'd be cleaner than moving things around
Mar 29 21:58:25 * kergoth experiments
Mar 29 22:07:21 * mranostay waves
Mar 29 23:32:17 <kergoth> RP__: thought so. your suggestion doesn't work. it has to be filename not directory to do it that way, because sstate_checkhashes checks the config metadata SSTATE_DIR, and the datacache only holds the filename, not the full path
Mar 29 23:32:31 <kergoth> will have to either do fn mangling or the moving method
Mar 29 23:32:36 * kergoth will try both
Mar 29 23:33:05 * kergoth tested this in the past and it didn't work, but wanted to give you the benefit of the doubt and hoped it'd work
Mar 29 23:35:22 <mranostay> kergoth: going to LC Summit?
Mar 29 23:35:45 <kergoth> nah, not going to be able to this year
Mar 30 01:25:22 <seebs> Is there some obvious way to clean pseudo-native?  "bitbake -c clean pseudo-native" predictably tries to rebuild pseudo first, and that doesn't work, which is my problem.
Mar 30 01:25:36 <seebs> (Seems to me the pseudo recipe is not good at rebuilds, because the 32-bit build chokes on 64-bit files.)
**** ENDING LOGGING AT Fri Mar 30 02:59:58 2012

**** BEGIN LOGGING AT Fri Mar 30 02:59:58 2012
Mar 30 07:18:25 <abustany> Hi there! I think I might have found a bug in meta/classes/package.bbclass ( http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/package.bbclass ), but then I'm not a python guru so if someone can confirm... Basically, needs_lfconfig is first "declared" at line 1363, and then re-assigned to true if needed at line 1283. However, it seems that the scope is different, and the assignment at line 1283 actually has no effect
Mar 30 07:18:45 <abustany> since the function linux_so does not "see" the needs_ldconfig from line 1363
Mar 30 07:18:52 <abustany> the result being that ldconfig is never run from package.bbclass
Mar 30 07:19:03 <abustany> so it's not run at all if the build system of the compiled software does not do it itself
Mar 30 07:19:30 <abustany> and actually, if you try to print needs_ldconfig at line 1283, you get a "variable does not exist" error
Mar 30 08:39:27 <mckoan> good morning
Mar 30 09:16:44 <ag> Any idea why pigs-native has no install log?
Mar 30 09:17:05 <ag> And nobody creates symlinks in /bin or /usr/bin as it should...
Mar 30 09:17:44 <ag> Is this on purpose or it's a bug and i will upload a patch.
Mar 30 09:17:47 <ag> ?
Mar 30 09:19:38 <Zagor> ag: wasn't this fixed in master?
Mar 30 09:19:45 <Zagor> http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-extended/pigz/pigz.inc
Mar 30 09:21:26 <ag> Zagor: Are you talking about using ALTERNATIVE links?
Mar 30 09:23:03 <Zagor> yes. what did you mean?
Mar 30 09:25:52 <ag> the problem
Mar 30 09:25:57 <ag> comes in native.
Mar 30 09:26:23 <ag> We will have to include symlinks in sysroot for gzip
Mar 30 09:28:28 <ag> Zagor: As i know ALTERNATIVE_LINKS are used in postinstal.
Mar 30 09:28:31 <ag> postinatll
Mar 30 09:28:41 <ag> postinstall*
Mar 30 09:28:58 <ag> So we won't have symlinks in sysroot in case of a native build.
Mar 30 09:29:28 <ag> Zagor: Clear now?
Mar 30 09:30:19 <Zagor> richard discussed using a special path for pigz to avoid race issues. I'm afraid I'm not familiar enough with the details to be of much help.
Mar 30 09:31:01 <ag> RP__: Would you help me understanding this?
Mar 30 09:33:35 <RP__> ag: in the native case, update alternatives shouldn't be doing anything and PN != BPN so it should be fine
Mar 30 09:34:23 <RP__> ag: We did add http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=40f95685e6a3b4359d2ab2fea1418fe5e4bd0aa1 which will install them into bindir/PN
Mar 30 09:34:44 <RP__> ag: This means you have to "inherit gzipnative" in anything you wish to use pigz
Mar 30 09:34:55 <RP__> ag: Sadly this is necessary else there are dependency/race issues
Mar 30 09:35:13 <ag> I think it's not working as it should.
Mar 30 09:35:17 <ag> Gimme 2 minutes please.
Mar 30 09:35:25 <ag> I understood now the origin of the problem.
Mar 30 09:37:52 <ag> RP__: Here is the bug: if [ "${PN}" = "${BPN}" ]
Mar 30 09:38:11 <ag> In case of native this goes into: if [ "pigz-native" = "pigz" ]
Mar 30 09:38:17 <ag> :)
Mar 30 09:38:21 <ag> I wil patch this. :)
Mar 30 09:38:24 <ag> will*
Mar 30 09:38:26 <RP__> ag: that is deliberate
Mar 30 09:38:40 <ag> how come?
Mar 30 09:38:57 <ag> I think the whole if thing should be negated
Mar 30 09:39:35 <RP__> ag: The update-alternatives thing happens only in the target case, not the native case
Mar 30 09:39:59 <ag> I know this.
Mar 30 09:40:01 <RP__> ag: Also, in the target case we're installing into base_bindir, not bindir
Mar 30 09:40:11 <ag> But there is an issue in the logic of the install step.
Mar 30 09:40:22 <RP__> ag: What issue?
Mar 30 09:41:00 <ag> if "${PN}" = "${BPN}" if this is true than we have a target build.
Mar 30 09:41:14 <ag> if NOT "${PN}" = "${BPN}" if this is true than we have a native build.
Mar 30 09:41:33 <ag> Am i clear now?
Mar 30 09:41:41 <ag> Or do i miss anything?
Mar 30 09:42:05 <ag> This is the problem.
Mar 30 09:42:18 <ag> Would you please confirm this? :)
Mar 30 09:42:35 <RP__> ag: You are correct above but in the target case we want base_bindir, in the native case, bindir
Mar 30 09:42:53 <RP__> ag: so the code does look correct to me
Mar 30 09:43:53 <ag> Do you have a build at your disposal?
Mar 30 09:44:03 <ag> With pigz-native?
Mar 30 09:44:19 <RP__> ag: Can you explain the problem you're solving? I'm guessing you're puzzled that the pigz binary ends up in usr/bin/pigz/ ?
Mar 30 09:44:29 <ag> yes!
Mar 30 09:44:44 <RP__> ag: so now, please read what I wrote originally above
Mar 30 09:45:15 <RP__> ag: specifically, look at http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=40f95685e6a3b4359d2ab2fea1418fe5e4bd0aa1 which is the change that does this
Mar 30 09:45:26 <ag> Damn! Now i understood the problem.
Mar 30 09:45:43 <ag> It's that inherit gzipnativ
Mar 30 09:45:46 <ag> native
Mar 30 09:45:54 <RP__> yes.
Mar 30 09:46:16 <RP__> gzip-native is a rather nasty dependency since we assume it in many places and it can overlap with the system gzip
Mar 30 09:46:28 <ag> Ok... thank you for having patience with me...
Mar 30 09:46:37 <RP__> What we can't have is a half installed gzip since something might try and use it
Mar 30 09:46:49 <RP__> If its isolated in a specific PATH, we can avoid this
Mar 30 09:46:58 <ag> ok.
Mar 30 09:47:05 <RP__> (I use gzip/pigz interchangeably here)
Mar 30 09:47:59 <ag> Yeah... i understoof this now...
Mar 30 09:48:05 <ag> understood*
Mar 30 09:53:47 <ag> RP__: But his won't solve the problem for packages which want things in specific paths.
Mar 30 09:53:57 <ag> For example i have a package with:
Mar 30 09:54:11 <ag> <------>FIND_PROGRAM(GZIP_TOOL
Mar 30 09:54:11 <ag> <------>             NAMES gzip
Mar 30 09:54:11 <ag> <------>             PATHS /bin
Mar 30 09:54:11 <ag> <------>                   /usr/bin
Mar 30 09:54:11 <ag> <------>                   /usr/local/bin)
Mar 30 09:54:47 <ag> The PATH_prepend won't have any effect. :)
Mar 30 09:56:58 <RP__> ag: It really shouldn't do that...
Mar 30 09:57:05 <RP__> ag: It should just look at PATH
Mar 30 09:57:15 <ag> True true...
Mar 30 09:57:55 <ag> It looks that other programmers don't know. :)
Mar 30 09:58:28 <ag> Anyway. Thanks once again for the whole explanation session.
Mar 30 10:03:01 <RP__> ag: np
Mar 30 15:31:16 <msm> how do you determine what loaded is used by a binary?
Mar 30 15:31:21 <msm> loader*
Mar 30 15:31:24 <msm> ld-linux.so etc
Mar 30 15:34:44 <kergoth> readelf/objdump
Mar 30 15:34:47 <kergoth> oh, he logged off
Mar 30 15:46:17 <kergoth> RP__: Any thoughts on where the lsb_release based distro name/version should go?
Mar 30 15:49:21 <RP__> kergoth: my gut instinct says fn but I realise that gives aliasing problems :/
Mar 30 15:50:39 <RP__> kergoth: I suspect ultimately the siggen handler code is going to have to get involved and manually force things to particular hashes or values for some configurations
Mar 30 15:51:08 <RP__> kergoth: I've been trying to thing about how we'd have a prebuild toolchain in sstate format and force it to be used regardless
Mar 30 16:04:20 <msm> how does one determine the dynamic loader for a binary?
Mar 30 16:06:26 <challinan> msm: readelf -p 1 <elf-file> will reveal it for most Power .elf files that are not shared library objects
Mar 30 16:07:02 <msm> challinan: cool thanks ;)
Mar 30 16:07:24 <challinan> np
Mar 30 16:09:09 <RP__> msm: kergoth did say "readelf/objdump" but you logged off
Mar 30 16:10:05 <msm> RP__: *sigh* sorry
Mar 30 16:10:08 <msm> thanks to chris too
Mar 30 16:10:20 <msm> i need to setup IRC on a desktop box and not my laptop
Mar 30 16:11:36 <kergoth> i keep a 'bip' bouncer/proxy running on a vps
Mar 30 16:11:40 <kergoth> quite helpful
Mar 30 16:11:48 <kergoth> have another one on an intranet machine for work's irc
Mar 30 16:18:24 <msm> bip bouncer
Mar 30 16:18:33 <msm> hmm, i have to admit i've never heard of this
Mar 30 16:18:56 <kergoth> others include ctrlproxy, dircproxy, etc
Mar 30 16:19:06 <kergoth> basically a server process stays connected to irc, you connect to that from your client
Mar 30 16:19:11 <kergoth> it sends you history/context when you connect
Mar 30 16:19:19 <kergoth> and it keeps your logs in one place
Mar 30 16:53:41 <fray> gah, I just noticed the tunings for many of the arm items don't distingish between the optimized and non-optimized version..
Mar 30 16:55:01 <fray> i.e. arm920t... it simply inherits everything from armv4t including the package names..
Mar 30 16:57:28 <ericben> hi RP__ even using PREMIRRORS, download speed from yocto.org is very poor from here which may explain why it takes so long time to dowload the sources using git.
Mar 30 16:57:42 <ericben> if git & www are hosted in the same place
Mar 30 16:58:25 <RP__> ericben: The server should be well connected...
Mar 30 16:58:37 <RP__> halstead, pidge: ^^^ any comment?
Mar 30 16:59:06 <ericben> RP__: wget http://downloads.yoctoproject.org/mirror/sources/git2_git.yoctoproject.org.linux-yocto-3.2.tar.gz 134K/s  eta 74m 41s
Mar 30 17:00:47 <ericben>  wget http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.3.tar.bz2 577K/s  eta 2m 19s
Mar 30 17:00:57 <ericben> fwiw
Mar 30 17:01:22 <pidge> RP__, ericben: Hrmmm. The server the source mirror lives on does have spikes from time to time. But not generally that bad. Pinging halstead.
Mar 30 17:02:15 <RP__> ericben: ironically, kernel.org is in the same place afaik
Mar 30 17:03:14 <ericben> RP__: to many peoples are filling yocto's bandwith with git fetches waiting for their kernel's sources to arrive ;-)
Mar 30 17:06:41 <ericben> I personnally don't care of the fetching speed I have my own mirrors and I'm not using linux-yocto but as I spent some time to test oe-core in its basic configuration (ie qemuarm in my case) I'm reporting feedback when trying to place in the shoes of a new user trying this.
Mar 30 17:11:24 <halstead> ericben, git.yoctoproject.org and www.yoctoproject.org are in the same rack and use the same connection.
Mar 30 17:13:14 <ericben> halstead: OK so that's not suprising to get the same low values in both case
Mar 30 17:13:32 <halstead> ericben, Where are you connecting from?
Mar 30 17:13:53 <ericben> halstead: france
Mar 30 17:15:25 <ericben> halstead: I get (in realtime 300-800KB/s from K.org(average 350 for a kernel) and 50-200KB/s from Yocto (average to come in .... 90 minutes) ... both using wget
Mar 30 17:18:48 <halstead> ericben, We are under quite a bit of load at the moment. Is this all the time?
Mar 30 17:19:01 <halstead> ericben, Bandwidth http://netfoo.nero.net/netviewer?locale=OSUOSL-Linux-Foundation&meta=partner
Mar 30 17:22:26 <ericben> halstead: it's at least slow enough so that I noticed it since I'm playing with qemuarm which means in the last 2-3 weeks (I'm usually playing with my boards)
Mar 30 17:22:55 <halstead> ericben, And are the OE servers the same speed for you?
Mar 30 17:23:27 <ericben> halstead: expand the graph view to month and you will see what I mean ;-
Mar 30 17:24:00 <ericben> halstead: I'm talking of the bandwidth graph view
Mar 30 17:24:08 <ericben> there is clearly a peak since 2 weeks
Mar 30 17:24:16 <ericben> and was one 3 weeks ago
Mar 30 17:24:21 * halstead nods.
Mar 30 17:24:23 <ericben> to much success guys ;)
Mar 30 17:24:49 <halstead> Is OpenEmbedded giving you better download rates?
Mar 30 17:25:31 <ericben> halstead: I'm trying a clone
Mar 30 17:25:37 <ericben> 500KiB/s
Mar 30 17:25:45 <ericben> so yes it's far better
Mar 30 17:26:25 <ericben> this clearly shows the problem : http://netfoo.nero.net/netviewer?locale=OSUOSL-Linux-Foundation&meta=partner&button=Redraw&mib=ifInOctets%3AifOutOctets%3AtransitOctets%3AtransitRate&cfunc=Avg&size=Normal&limit=100000000000&period=month
Mar 30 17:27:12 <ericben> seems you are limitted to something around 120Mb/s on your link as it nealry never goes over this value
Mar 30 17:28:16 <halstead> ericben, I think we have a soft cap of 100Mbps and yes I see it has been maxed for awhile.
Mar 30 17:31:57 <ericben> if peoples are using the yocto's PREMIRROR that's not surprising as in that case they download everything from yocto's server
Mar 30 17:33:18 <halstead> ericben, We've stopped a backup/mirror process that was running. Do you notice any difference?
Mar 30 17:33:43 <ericben> good new from pidge, I now get 300-500 K/s .. ETA 27 min instead of the previous 100 !
Mar 30 17:34:12 <ericben> thanks there was a real problem but I was not searching in the right direction
Mar 30 17:34:29 <pidge> ericben: thank halstead, he figured it out
Mar 30 17:35:18 <fray> I'm blanking.. in a configuration.. how do I do "if it exists and it's not blank, I want that value, otherwise use this value"?
Mar 30 17:35:24 <fray> ${@....}
Mar 30 17:38:50 <ericben> halstead: pidge: thanks to both of you ;)
Mar 30 17:38:57 <fray> Hmm.. figured out another way to do it..
Mar 30 17:39:01 <halstead> ericben, Has it slowed down again?
Mar 30 17:40:12 <ericben> halstead: I stopped the download, now launching it again
Mar 30 17:40:56 <ericben> halstead: yes ~60K/s
Mar 30 17:41:09 <ericben> ETA 2h11m :-(
Mar 30 17:41:25 <ericben> quite a poor first time user experience in that case :-(
Mar 30 17:41:27 <halstead> Thank you. I'm working on a permanent fix now.
Mar 30 17:52:26 <seebs> Purely hypothetically, if I suddenly wanted a qemuarm target with a native compiler, could poky/yocto do that for me easily?
Mar 30 17:52:57 <khem> seebs: you mean you want gcc and friends on target ?
Mar 30 17:52:57 <fray> yes..
Mar 30 17:53:06 <khem> add tools-sdk
Mar 30 17:53:07 <seebs> Not to imply that someone waving a pseudo test failure in front of me would make me suddenly try to fix something that was never supposed to work in the first place.  That would be callow and easily-manipulated.
Mar 30 17:53:28 <fray> ;)
Mar 30 17:54:07 <khem> EXTRA_IMAGE_FEATURES += "tools-sdk"
Mar 30 17:54:17 <seebs> That was going to be my next question.  :)
Mar 30 17:54:49 * khem stares at crystal ball
Mar 30 17:55:11 <seebs> And in an hour or two I'll be asking how I run that qemu session and make files available to it.
Mar 30 17:55:14 <fray> :) yours is working better then mind
Mar 30 17:55:27 <seebs> Apparently pseudo can be built for ARM really easily, but then fails in really weird ways.
Mar 30 17:55:41 <seebs> This is way more interesting than whatever I was going to do today.
Mar 30 17:59:28 <khem> seebs: it reminds me when I tried qemuarm on beagleboard :)
Mar 30 18:10:41 <halstead> ericben, I may have corrected the shaping. Can you test for me now?
Mar 30 18:23:19 <ericben> halstead: seems fine ETA 25m
Mar 30 18:23:52 <halstead> Thank you.
Mar 30 18:30:42 <kergoth> msm: https://github.com/kergoth/oe-core/compare/sstate-structure
Mar 30 18:31:47 <msm> kergoth: cool - ill try to test this out sometime
Mar 30 18:31:51 <msm> soon hopefully
Mar 30 18:32:01 <kergoth> cool, keep me posted
Mar 30 18:32:37 <kergoth> Anyone else have any thoughts on this? I think this achieves the goal without being terribly invasive. not the cleanest, I realize, but also avoids the need to modify bitbake any further
Mar 30 18:33:34 <kergoth> at mentor, we can build on centos5 and its sstates can be safely used on our other hosts like u1004, but not vice versa
Mar 30 18:34:14 <kergoth> if you don't define any additional compatible hosts, native/cross will be kept in the per-distro area, isolated from other build hosts
Mar 30 18:35:11 <kergoth> msm: you'll just need an INHERIT += "sstate-reuse", then a bit more if you want to add compatible hosts
Mar 30 18:35:28 <kergoth> i'll post the section of the mel config using this as an example
Mar 30 18:45:56 <kergoth> msm: https://gist.github.com/2253903
Mar 30 18:49:04 <kergoth> a bit simplistic, in that one can't say "if i'm on RedHatEnterprise-5, then I can also use RedHatEnterprise-4 sstates" or whatever
Mar 30 20:03:16 <msm> kergoth: that function is supposed to live in a local.conf?
Mar 30 20:06:36 <kergoth> see the filename, it's a .inc. currently i pull it in via our distro, but local.conf would work as well
Mar 30 20:06:44 <kergoth> the gist was intended to be an example :)
Mar 30 20:07:08 <kergoth> to test just drop into conf/ next to local.conf, add require conf/sstate.inc to local.conf
Mar 30 20:09:54 <fray> wow.. we currently have 120 defined tunings..
Mar 30 20:10:01 * fray starts building them....
Mar 30 20:10:16 <kergoth> haha, have fun
Mar 30 20:10:25 <fray> I've got machines and all weekend.. ;)
Mar 30 20:10:46 <fray> most of them seem to be arm..
Mar 30 20:11:52 <kergoth> not too surprising
Mar 30 20:13:28 <Tartarus> kergoth: yay for reuse stuff coming out :)
Mar 30 20:16:22 <kergoth> :)
Mar 30 20:16:40 <kergoth> took  while to find something that'd work with sstate, due to SSTATE_DIR not being pulled per-recipe
Mar 30 20:16:54 <kergoth> s/  / a /
Mar 30 20:20:15 * kergoth will send a mail to the list about it shortly
Mar 30 20:26:32 <ericben> kergoth: in the .inc shouldn't LSB_ADJUST_HOOK be  LSB_DISTRO_ADJUST ?
Mar 30 20:42:09 <kergoth> erm, yes, thanks :)
Mar 30 20:42:25 <kergoth> fixed
Mar 30 20:50:53 <ericben> that will avoid you a remark on the mailing list from the doc and comments reviewer :-D
Mar 30 21:24:31 <kergoth> ericben: hehe, thanks
Mar 30 22:15:58 <kergoth> hmm, i should add tmux support to terminal.py & co
Mar 30 22:16:18 <kergoth> would be cool for it to just open a new window in the existing session or so :)
Mar 30 22:22:32 <seebs> Okay, silly newbie question:  How do I start qemu?  Web pages say to run poky-qemu <target>, but in fact this says "command not found" when I try it.
Mar 30 22:22:37 <seebs> So I probably failed to build something?
Mar 30 22:23:26 <seebs> ahh, run-qemu
Mar 30 22:23:31 <seebs> er, runqemu
Mar 30 22:23:38 <seebs> I am totally lucid today and stuff.
Mar 30 22:23:46 <seebs> Except for the excess blood in my caffeinestream.
Mar 30 22:26:50 <RP__> seebs: which webpages? We should fix that
Mar 30 22:27:03 <seebs> I think non-yocto ones from long ago.
Mar 30 22:27:22 <seebs> hmm
Mar 30 22:27:30 <kergoth> GAH, vmware hosed my modifier keys AGAIN
Mar 30 22:27:33 <kergoth> when will they fix this?
Mar 30 22:27:37 <seebs> Right, I have come to the point where I actually have to start learning how this works.
Mar 30 22:28:06 <seebs> Heh.  I just killed my X session rather badly:  I'm using X over ssh, and the "ctrl+alt to end mouse grab" didn't work.  Luckily, ctrl+alt+f3 to get a console still worked.
Mar 30 22:28:42 <seebs> So if I wanted git and stuff in a rootfs, what would I do?  Modify my conf file, or just pick a different target?
Mar 30 22:30:51 <kergoth> up to you. make a custom image, or inject it to an existing one via local.conf
Mar 30 22:30:54 <kergoth> really depends on your goal
Mar 30 22:31:16 <seebs> The key weakness is that right now I don't have a clear enough mental map of how bitbake and images work to evaluate either of those.
Mar 30 22:31:40 <seebs> Right now, I have an EXTRA_IMAGE_FEATURES +=, which I assume is "inject to an existing one".
Mar 30 22:31:53 <seebs> So presumably, if I knew the "feature" name of a thing which would imply a given package, I could add it there.
Mar 30 22:37:16 <kergoth> an image is just a recipe that constructs a filesystem from the packages listed in IMAGE_INSTALL (and a few other sources)
Mar 30 22:37:36 <kergoth> today, the only available image features are via a package grouping mechanism
Mar 30 22:37:49 <kergoth> that is, they're just a convenient way to specify multiple packages at a time
Mar 30 22:37:53 <kergoth> that's all. nothing special
Mar 30 22:38:06 <kergoth> you can look at those as an alternative to tasks
Mar 30 22:38:21 <kergoth> you add feautre names to EXTRA_IMAGE_FEATURES, not apckage names
Mar 30 22:41:55 <fray> BTW that is one thing I'd like to see somewhat changed.. the way images get generated.  I'd like an external mechanism that can generate images from package feeds.. then the existing image recipes can use that mechanism to generate images.. or the mechanism can be put on install media, or simply run externally for people who don't want source builds
Mar 30 22:42:33 <kergoth> agreed
Mar 30 22:42:57 <kergoth> i've often wanted a separate image creation tool. we sor tof wedged it into a recipe because you can do anything in a recipe, but it isn't ideal
Mar 30 22:44:03 <fray> someday......
Mar 30 22:44:41 <fray> well.. I'm done with 10 of 120 builds.. only found 2 minor errors in the tunings so far.. :P
Mar 30 22:46:55 <kergoth> hah
Mar 30 22:47:15 <fray> building core-image-minimal for a made up "qemutune" machine...
Mar 30 22:47:22 <fray> that should build enough to verify the tune is working
Mar 30 23:21:26 <seebs> hmm
Mar 30 23:22:01 <seebs> So if I want to add a package to a filesystem, and that package is not part of a feature, what is the usual approach?  There was stuff on this in the yocto 1.0/1.1 docs, but it's gone in 1.2, apparently.
Mar 30 23:22:08 <seebs> I assume I copy an existing image and modify it?
Mar 30 23:22:18 <fray> or use hob...
Mar 30 23:22:32 <fray> but ya, that way I say is to create a new image (or .bbappend an existing one)
Mar 30 23:23:47 <kergoth> there's a thread on this on the list over teh past couple days
Mar 30 23:23:53 <kergoth> robert day brought this up
Mar 30 23:24:00 <kergoth> i'd suggest looking at the various approaches dsicussed there
Mar 30 23:24:46 <seebs> It's always weird switching systems.  I'm used to qemu using userspace NFS, not a filesystem image, so it was super easy to copy files in and out.  :)
Mar 30 23:26:29 <kergoth> generally you just need to get your packages into an IMAGE_INSTALL in an image. how you go about that depends on the use case
Mar 30 23:26:44 <kergoth> e.g. IMAGE_INSTALL_append in local.conf, new image recipe with IMAGE_INSTALL +=, etc
Mar 30 23:35:33 <fray> seebs, you can still do that.. I forget the arguments off hand though..
Mar 30 23:35:44 <fray> (the scripts will extract the tarball and serve them via NFS)
Mar 30 23:54:19 <khem> seebs: you want to use nfs rfs ?
Mar 30 23:55:01 <khem> EXTRA_IMAGE_FEATURES += "nfs-server"
Mar 30 23:55:04 <seebs> It might simplify my life.  Ahh.
Mar 30 23:55:23 <seebs> Yeah, that would simplify things.
Mar 30 23:55:46 <khem> and also bitbake meta-ide-support
Mar 30 23:55:57 <khem> for supporting bits to extract rfs
Mar 30 23:57:18 <khem> once you have build your image and the above target then run runqemu-extract-sdk <image-tarball> <extract-dir>
Mar 30 23:57:33 <khem> this will setup the nfs rfs which qemu then can boo
Mar 30 23:57:34 <khem> t
Mar 30 23:57:58 <khem> then runqemu <path to kernel> <path to nfs rfs>
Mar 30 23:58:10 <khem> should boot it using nfs rfs
Mar 30 23:58:44 <khem> and all that you have to do it in same shell where you sourced oe-init-build-env
Mar 30 23:58:47 <seebs> Thanks a ton!  I will totally eventually know my way around that.
Mar 30 23:58:51 <seebs> Yup.
Mar 30 23:59:04 <seebs> Hey, am I going to hate my life if I've sourced oe-init-build-env about 10 times in the same shell?
Mar 30 23:59:14 <khem> I dont think so
Mar 30 23:59:33 <khem> unless it mindlessly appends values to variables
Mar 30 23:59:52 <khem> which then can grow fat and fat and shell vars have some limits IIRC
Mar 30 23:59:58 <khem> its like 4K length
Mar 31 00:00:02 <khem> or somesuch
Mar 31 00:00:16 <khem> or may be I am mixing it with freebsd shell
Mar 31 00:01:36 <fray> I almost always start a ne shell and then source it there.. that way I can alwys return to sanity
Mar 31 00:04:34 <kergoth> 90% of the time i use a wrapper of some sort and avoid modifying the environment at all, it's just annoying
Mar 31 00:11:37 <fray> that is likely what we will be doing for our commercial products..
Mar 31 00:44:43 <seebs> d'oh
Mar 31 00:44:48 <seebs> python has no module "datetime".
Mar 31 00:45:45 <seebs> Or glob.
Mar 31 00:47:02 <seebs> Right, I will fake my way around this.
Mar 31 00:55:27 <seebs> ...
Mar 31 00:55:32 <seebs> Well, so much for my tests.
Mar 31 00:55:44 <seebs> Turns out that, even as non-root, I can chown files freely, apparently.
Mar 31 00:56:04 <seebs> This makes it rather harder than I expected to determine whether pseudo is working.
Mar 31 00:56:41 <seebs> I suppose the NFS server is being permissive.
**** ENDING LOGGING AT Sat Mar 31 02:59:58 2012

**** BEGIN LOGGING AT Sat Mar 31 02:59:59 2012
**** ENDING LOGGING AT Sun Apr 01 02:59:58 2012

**** BEGIN LOGGING AT Sun Apr 01 02:59:58 2012
**** ENDING LOGGING AT Mon Apr 02 02:59:58 2012

**** BEGIN LOGGING AT Mon Apr 02 02:59:58 2012
Apr 02 11:59:42 <octoploid> Hi, I'm trying to build a x32 image. I'm running "bitbake core-image-minimal-x32
Apr 02 11:59:48 <octoploid> and get:
Apr 02 11:59:58 <octoploid> ERROR: No recipes available for:
Apr 02 12:00:00 <octoploid>   /var/tmp/poky-edison-6.0.1/meta-x32/eglibc/eglibc_2.15.bbappend
Apr 02 12:00:02 <octoploid>   /var/tmp/poky-edison-6.0.1/meta-x32/eglibc/eglibc-initial_2.15.bbappend
Apr 02 12:00:05 <octoploid> Any ideas?
Apr 02 12:05:25 <octoploid> Ah "git reset --hard 6b96e597d8b" on x32 branch "solved" the problem...
Apr 02 12:09:16 <Zagor> this doesn't look so good: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/files/common-licenses/GPL-3.0?id=edison-6.0.1.release
Apr 02 12:09:38 <Zagor> this looks wrong too: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/files/common-licenses/GPL-2?id=edison-6.0.1.release
Apr 02 12:10:51 <Zagor> and GPL-3 only contains the runtime exception clause: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/files/common-licenses/GPL-3?id=edison-6.0.1.release
Apr 02 12:13:50 <Zagor> RP__, bluelightning: ping ^^
Apr 02 12:34:58 <RP__> Zagor: hmm, not good
Apr 02 12:35:18 <bluelightning> Zagor: I will forward this on to beth
Apr 02 12:35:59 <RP__> Zagor: I'd open a bug against edison with regard to this. I know a lot of stuff got cleaned up in master and it looks like we missed it for edison
Apr 02 12:38:03 <Zagor> RP__: ok, I'll do that
Apr 02 12:46:57 <Zagor> RP__: is product "meta recipes" suitable?
Apr 02 12:54:55 <Zagor> submitted https://bugzilla.yoctoproject.org/show_bug.cgi?id=2230
Apr 02 12:55:54 <RP__> Zagor: thanks, I've assigned it to Beth
Apr 02 15:40:48 <ag> Cheers! Any ideas why we keep this semi-old version of udev? Upstream is on 182 and we are on 164...
Apr 02 15:46:20 <Jefro> Yocto Project BSP Summit backchat channel: #yocto-bsp-summit
Apr 02 16:03:33 * nitink is in Yocto Project BSP summit at Mentor Graphics
Apr 02 16:04:25 <Jefro> Hi all  - Yocto Project BSP Summit backchat channel: #yocto-bsp-summit
Apr 02 16:13:57 * RP__ makes it through the firewall :)
Apr 02 16:15:55 <Jefro> Yocto Project BSP Summit backchat channel: #yocto-bsp-summit
Apr 02 16:32:35 <darknighte> for those who may have been waiting for approval for webex.  I just approved all pending registrations
Apr 02 17:11:46 <autif> halstead - I am trying to push the latest mono recipes to meta-mono - I get the following error - fatal: remote error: access denied or repository not exported: /meta-mono
Apr 02 17:30:29 <Jefro> Yocto Project BSP Summit: phone 800-547-3011 conf# 101, webex at https://mentor.webex.com/mentor/j.php?J=758201571
Apr 02 17:41:45 <bluelightning> pidge: are we short of space on yocto-iab08?
Apr 02 17:42:22 <bluelightning> actually it's not just one machine
Apr 02 17:42:36 <pidge> bluelightning. let me check
Apr 02 17:42:41 <bluelightning> getting gzip I/O errors
Apr 02 17:43:06 <pidge> nas full i bet
Apr 02 17:43:48 <pidge> ding. nas is at 100%
Apr 02 17:45:06 <autif> rm -r /
Apr 02 17:46:34 <pidge> autif: snerk
Apr 02 17:46:44 <autif> :-P
Apr 02 17:47:15 * pidge rm's nightlies for Feb and the beginning of March. Should solve the issue
Apr 02 17:47:36 <pidge> and makes a mental note to fix the backup scripts
Apr 02 17:47:45 <zeddii_> should bison be built and available by default ?
Apr 02 17:48:06 <zeddii_> the 3.4-rc1 kernel is showing this: i586-poky-linux-bison as a requirement for perf .. and it's not present.
Apr 02 17:48:32 * zeddii_ recalls the lkml discussion about generating those on the fly.
Apr 02 17:48:42 * zeddii_ might be a victim.
Apr 02 17:54:49 * zeddii_ hacks perf to not use the cross compile prefix for bison.
Apr 02 18:01:29 <zeddii_> 3.4-rc1 is aging me quickly. fix #2 for perf pending.
Apr 02 19:11:45 <autif> Is there an equivalent of beagleboard for MIPS and PPC? (equivalent means - price < $300, HDMI or VGA out - as opposed to a custom LCD, bootable from flashdrive - no JTAG/ICE debugger required)
Apr 02 19:13:21 <msm> is there a good document describing the licensing foo that's been added to yocto?
Apr 02 19:13:26 <msm> something in the git tree or on a wiki poerhaps?
Apr 02 19:14:28 <kergoth> which foo? :)
Apr 02 19:17:56 <fray> autif, not that i know of..
Apr 02 19:18:19 <fray> we had a hard time finding an inexpensive COTS board for PowerPC when we started the Yocto Project.. and the MIPS board we found (routerstation pro) is no longer made
Apr 02 19:18:45 <msm> kergoth: just how it works for people who have no idea about yocto in general
Apr 02 19:19:56 <msm> let' suppose I have a "legal review team" who could start using them system ;)
Apr 02 19:21:09 <autif> fray - yup - that's what I found - routerstation and router station pro are no longer current and anything PPC is upwards of $3000 or so - makes it somewhat hard for a hobbyist
Apr 02 19:21:37 <fray> unfortunately, that is what I've found.. you can ask on the #mklinux channel and see if they have any other ideas on a PPC board..
Apr 02 19:21:56 <fray> but PPC (and MIPS) seems to have gone very specialized so COTS boards are expensive
Apr 02 19:22:06 <kergoth> msm: well, there are multiple components. there's the bom stuff, there's source archiving, there's license checksumming
Apr 02 19:22:16 <fray> TI has done a great job w/ the beagleboard and similar keeping down costs
Apr 02 19:22:59 <kergoth> i think the only cheap ppc/mips dev board is called 'qemu'
Apr 02 19:23:01 <kergoth> ;)
Apr 02 19:23:43 <fray> Xilinx used to have an FPGA that could be programmed w/ a PPC405 processor.. it was slow, but some of the dev kits were under $1k
Apr 02 19:24:01 <autif> i know freescale is contributing to have a meta-fsl-ppc. msm contributes a lot to that meta layer - care to comment?
Apr 02 19:24:02 <fray> but you had to be non-commerical and usually a college student to get the programming software cheaply
Apr 02 19:24:16 <msm> kergoth: yes, a summary for it all ;)
Apr 02 19:24:37 <msm> kergoth: freescale has some $1000ish rdb boards
Apr 02 19:24:39 <msm> err
Apr 02 19:24:45 <msm> fray: ^
Apr 02 19:24:48 <autif> got it
Apr 02 19:24:53 <autif> can you point osme out?
Apr 02 19:25:02 <fray> inthe past we've tried to get them and they were impossible to get..
Apr 02 19:25:06 <msm> its been brought up that we need cheaper development boards
Apr 02 19:25:14 <fray> the one we did pick we could actually order single quantities from Digikey
Apr 02 19:25:15 <msm> fray: our rdb boards?
Apr 02 19:25:26 <fray> ya..
Apr 02 19:25:41 <fray> but it was around $1500, and only available in the US
Apr 02 19:25:59 <fray> (we had to buy a couple in the US and ship them overseas to be able to add to test labs and such
Apr 02 19:26:19 <fray> it's all because one of the variations -could- have encryption, even though the one we bought (and wanted) didn't)
Apr 02 19:27:21 <kergoth> msm: Not sure if anyone has written up an introduction to the various aspects of the licensing yet.. hmm. maybe beth would know. pidge?
Apr 02 19:32:46 <autif> msm - can you name some $1000ish RDB boards?
Apr 02 19:33:50 <msm> autif: im looking
Apr 02 19:34:03 <autif> cool - thanks
Apr 02 19:34:10 <msm> http://www.freescale.com/webapp/search/MainSERP.jsp?QueryText=p1020rdb&assetIdResult=&fsrch=1&sessionChecker=pl6JP59QkZnnc1gW93y17ppVQSrWnf1fT7lQpRZj2hzpQ6DTynbj%211744414170%211333394768412&attempt=0&showCustomCollateral=false&RELEVANCE=true&fromTrng=false&showAllCategories=false&fromMobile=false&isResult=false&isFromFlex=false&isTree=false&pageSize=25&fromASP=false&isAdvanceSearch=false&getTree=false&fromPSP=false&lastQueryText=p1020rdb&iteration=1&assetLocked=fa
Apr 02 19:34:14 <msm> wow
Apr 02 19:34:16 <msm> can you see that link?
Apr 02 19:34:20 <msm> there is a $500 board
Apr 02 19:34:21 <bluelightning> MPC8315E-RDB wasn't that expensive...
Apr 02 19:34:23 <msm> p1020rdb-pc
Apr 02 19:35:23 <fray> bluelightning it was $1500 when we ordered the first couple of systems
Apr 02 19:35:29 <fray> ($1500 each)
Apr 02 19:35:34 <fray> that included shipping/tax/etc
Apr 02 19:36:04 <bluelightning> well, when I bought one here in the UK about a year ago it wasn't anywhere near that
Apr 02 19:36:07 <fray> msm, but can you actually buy the board?  thats the problem..
Apr 02 19:36:36 <fray> we saw some cheaper systems, but the only way to get them was right from freescale.. we needed smething we could get from a third party
Apr 02 19:36:46 <fray> (availability may have changed since then as well that was 2 years ago)
Apr 02 19:37:04 <bluelightning> ah now I remember
Apr 02 19:37:05 <fray> bluelightning price may have come down then..  I remember being shocked that $1500 each was the cheapest we could find a reference PPC system..
Apr 02 19:37:14 <bluelightning> I had real trouble ordering the MPC8315E-RDB
Apr 02 19:37:31 <bluelightning> once I was able to establish that MPC8315E-RDBA was the same thing I had no trouble
Apr 02 19:37:32 <fray> the MIPS was $200, ARM was cheaper and the Intel boards we more or less "free"
Apr 02 19:37:39 <fray> ahh
Apr 02 19:37:41 <bluelightning> I got it through Farnell IIRC
Apr 02 19:37:49 <bluelightning> (element14)
Apr 02 19:37:50 <fray> cool..
Apr 02 19:38:55 <msm> fray: yes you can buy it
Apr 02 19:39:05 <msm> fray: though ive never done it - you can buy direct from freescale even
Apr 02 19:39:33 <msm> fray: actually ONLY from freesacle the distributors don't have it in stock
Apr 02 19:39:46 <msm> fray: im going through the hoops now to see how far I can get
Apr 02 19:39:49 <ericben> msm: fray: buying eval board from freescale works fine
Apr 02 19:40:03 <ericben> using their website
Apr 02 19:41:28 <msm> that P1020RDB-PC has quite a few features too
Apr 02 19:41:47 <msm> pidge: where is the best place to look for a license summary?
Apr 02 19:42:40 <pidge> msm: As in a manifest?
Apr 02 19:42:53 <pidge> msm: or a summary on all the license-foo
Apr 02 19:43:20 <msm> summary ;)
Apr 02 19:43:27 <msm> for the layman (if it exists)
Apr 02 19:43:32 <kergoth> i think he wants to know what capabilities exist as a whole in the system for licensing and compliance
Apr 02 19:43:39 <ericben> concerning license : any idea if this patch is right ? http://patches.openembedded.org/patch/24943/
Apr 02 19:44:05 <msm> kergoth: yes
Apr 02 19:44:28 <pidge> msm: There isn't one yet. I was hoping the archiver class would be pulled in first. Puts it on the todo to write a license quickstart.
Apr 02 19:44:51 <msm> pidge: ok thanks
Apr 02 19:45:41 <pidge> ericben: Looking
Apr 02 19:46:06 <darknighte> welcome back all, we've just restarted at the BSP Summit with Denys presenting
Apr 02 19:46:07 <ericben> msn: isn't what you are looking for the license.manifest in deploy/licenses/your-image/ ?
Apr 02 19:46:27 <kergoth> ericben: looking
Apr 02 19:47:21 <msm> ericben: well that's the end result
Apr 02 19:47:33 <msm> ericben: i want something say why this should be used / is valid
Apr 02 19:49:45 <autif> msm/bluelightning - thanks for pointing out p1020rdb-pc and mpc8315e-rdba - both looks affordable and seem to be able to boot w/o a JTAG/ICE debugger.
Apr 02 19:49:53 <Jefro> Yocto Project BSP Summit: phone 800-547-3011 conf# 101, webex at https://mentor.webex.com/mentor/j.php?J=758201571
Apr 02 19:50:29 <ericben> msm: I don't understand exactly what you mean
Apr 02 19:51:29 <msm> autif: def. go with the p1020rdb-pc
Apr 02 19:51:38 <msm> autif: it's much more maintained by Freescale
Apr 02 19:51:42 <msm> and newer
Apr 02 19:51:54 <kergoth> ericben: I don't think this is quite right. I think the blacklist needs to be considered as stronger. if *any* blacklisted licenses are in the list, then it should be excluded, even if one of its licenses are included
Apr 02 19:52:09 <kergoth> e.g. you don't want to match when LICENSE = "GPLv2 & CLOSED" or somesuch
Apr 02 19:52:10 <autif> I notice that it is supported by meta-fsl-ppc too
Apr 02 19:53:13 <kergoth> so i think we want to say "if not excluded and included: return True... else: return False. so if there are no explicit blacklisted items, and if any of the remaining items are included, then we include it. so an item neither in the blacklist nor the whitelist will not prevent a LICENSE that includes one whitelisted license from being included
Apr 02 19:53:16 <ericben> kergoth: OK, but in the present case, BSD-4 is not in blacklist but in the end busybox gets rejected. So I think if I reverse the final test this will work
Apr 02 19:53:24 <kergoth> if you see what i mean. i think that meets your needs without weakening the strenght of the blacklist
Apr 02 19:53:27 <kergoth> right
Apr 02 19:53:40 <ericben> ok thansk, I'm going to send a v2
Apr 02 19:53:49 <kergoth> np, thanks for looking at this, appreciate it
Apr 02 19:54:12 <kergoth> can be hard to consider all cases for something like this, should have done alarge set of unit tests :)
Apr 02 19:54:30 <ericben> kergoth: in phase of releasing a product for a customeer so we are at the license compliance stage ;-)
Apr 02 19:54:38 <pidge> ericben: I haven't seen this behavior you describe in the patch. if so, yeah, then this fixes it.
Apr 02 19:55:06 <ericben> pidge: you can test it with busybox, it shows the problem (at least here)
Apr 02 19:55:11 * pidge jumps for joy hearing release and license compliance.
Apr 02 19:55:21 <kergoth> the problem case is when there are no blacklisted licenses, there is at least one whitelisted license, and there are licenses not covered by either
Apr 02 19:55:22 <pidge> ericben: doing just that :).
Apr 02 19:55:24 <kergoth> afaict
Apr 02 19:55:57 * pidge kicks off a build and then goes to grab lunch.
Apr 02 19:56:24 <kergoth> koen made a good point in the sstate reuse thread, that we need a copyleft_complaince/source_archiver type thing but for population of public sstate mirrors
Apr 02 19:56:37 <kergoth> so shared state archives for non-open recipes don't get populated
Apr 02 19:56:48 <fray> ya.. I'd not thought of that before his post
Apr 02 19:58:51 <kergoth> okay, this is an odd one
Apr 02 19:58:52 <kergoth> ./arm-mgc-linux-gnueabi-libtool --tag=CC   --mode=link arm-none-linux-gnueabi-gcc  -march=armv7-a -fno-tree-vectorize      -mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 -mno-unaligned-access --sysroot=/var/jenkins/workspace/sb_mel5/buildhost/sb-centos5/machine/beagleboard/build_beagleboard_release/sysroots/beagleboard  -isystem/var/jenkins/workspace/sb_mel5/buildhost/sb-centos5/machine/beagleboard/Sourcery_G++/arm-mgc-linux-gnueabi/
Apr 02 19:58:59 <kergoth> make[2]: execvp: ./arm-mgc-linux-gnueabi-libtool: Text file busy
Apr 02 19:59:01 <kergoth> make[2]: *** [libltdl/libltdl.la] Error 127
Apr 02 19:59:02 <kergoth> gah, i didn't realize those lines were so long
Apr 02 19:59:04 <kergoth> sorry about that
Apr 02 19:59:23 <kergoth> usually those errors are with writing that file while its' being used, but there are previous exec's of that libtool in this exact same log
Apr 02 19:59:26 <fray> means something was writing out arm-mgc-linux-gnueabi-libtool, while something esle was try to execute it
Apr 02 19:59:28 * kergoth sratches head
Apr 02 19:59:30 * kergoth nods
Apr 02 19:59:45 <kergoth> it's just strange that it would be written in the middle of the do_compile, seemingly after other execs of it
Apr 02 19:59:48 <fray> I've seen that before when there are races in makefiles generating local libtool archives
Apr 02 20:00:09 <kergoth> maybe i'll punt and PARALLEL_MAKE = "" for now
Apr 02 20:00:16 <kergoth> heh
Apr 02 20:09:18 <autif> msm - 12 − 14 week lead time everywhere for p1020rdb-pc - did that just happen after you mentioned it here? digikey, mouser, avnet - all sold out - they are our pre-approved source for hardware
Apr 02 20:09:43 <msm> autif: i doubt it
Apr 02 20:10:07 <msm> autif: i wonder if those guys don't keep stock on handle - and just request one to be built upon order
Apr 02 20:12:00 <ericben> 12-14 is a standard freescale lead time :-(
Apr 02 20:12:06 <ericben> often
Apr 02 20:12:48 <ericben> at least for small customers like us
**** BEGIN LOGGING AT Mon Apr 02 20:24:03 2012
Apr 02 20:38:34 <fray> FYI -- noticed there was an upstream prelinker update.. I've synced teh cross-prelinker and upstream prelinker
Apr 02 20:38:48 <fray>         * src/dwarf2.c (adjust_attributes): For DWARF4+ treat
Apr 02 20:38:48 <fray>         DW_AT_data_member_location with DW_FORM_data[48] as
Apr 02 20:38:48 <fray>         large constant instead of loclistptr.
Apr 02 20:53:05 <khem> hmmm well we dont use dwarf4 yet but still nice to have
Apr 02 21:42:09 <pidge> kergoth: re sstate with closed. I have an AB bug open that would be solved by something to ensure closed source code doesn't make it into the public sstate mirror FWIW
Apr 02 21:48:09 <kergoth> ah
**** ENDING LOGGING AT Tue Apr 03 02:59:58 2012

**** BEGIN LOGGING AT Tue Apr 03 02:59:58 2012
Apr 03 08:33:15 <mckoan> good morning
Apr 03 09:13:13 <ag> Cheers!
Apr 03 09:16:14 <ag> After a fresh Ubuntu install me i get these warnings:
Apr 03 09:16:15 <ag> WARNING: GPL-2.0 for udev could not be copied for some reason. It may not exist. WARN for now.
Apr 03 09:16:25 <ag> And for other packages as well.
Apr 03 09:16:57 <ag> The problem comes from ret = bb.copyfile(os.path.join(license_source, spdx_generic), os.path.join(os.path.join(d.getVar('LICSSTATEDIR', True), pn), "generic_" + license_type))
Apr 03 09:19:22 <ag> The files are copied correctly but the copyfile always returns 0. So this could be a python related problem or so.
Apr 03 09:20:50 <ag> So my proposal is to use "if not os.path.isfile(os.path.join(os.path.join(d.getVar('LICSSTATEDIR', True), pn), "generic_" + license_type)):" to check if copyfile succeeded.
Apr 03 09:23:14 <ag> Or another way is to try / except.
Apr 03 10:18:59 <ag> It seems like try / except doesn't trow an exception is src is not there.
Apr 03 10:19:21 <ag> So So this would be better "if not os.path.isfile(os.path.join(os.path.join(d.getVar('LICSSTATEDIR', True), pn), "generic_" + license_type)):
Apr 03 11:08:56 <ignus> hello all
Apr 03 12:15:36 <bluelightning> hi ignus
Apr 03 12:15:54 <ignus> bluelightning: hey - hows it going?
Apr 03 12:16:01 <bluelightning> ignus: not too bad, and you?
Apr 03 12:16:18 <ignus> great yeah, busy...
Apr 03 12:16:22 <ignus> fighting with udev
Apr 03 12:16:42 <bluelightning> ignus: did you get past the uclibc issue?
Apr 03 12:17:21 <ignus> i had to leave it and work on this udev thing as well as CI with buildbot
Apr 03 12:17:37 <bluelightning> ah ok
Apr 03 12:17:44 <ignus> i get the impression that it might stop being an issue when we upgrade to yocto 1.2, what do you think?
Apr 03 12:18:08 <bluelightning> yes, the required function should be there with the newer uclibc in 1.2
Apr 03 12:19:49 <ignus> bluelightning: so im not sure if its worth putting in the effort to fix it right now. thank you for looking into it though, much appreciated!
Apr 03 12:20:03 <bluelightning> no worries :)
Apr 03 12:20:21 <vmeson> ls
Apr 03 12:20:26 <vmeson> oops.
Apr 03 12:22:07 <ignus> bluelightning: any idea what might cause udev not to be able to create a socket?
Apr 03 12:22:15 <ignus> "1333455287.638996 [50] main: error initializing netlink socket "
Apr 03 12:24:09 <bluelightning> ignus: are the appropriate netlink options enabled in the kernel?
Apr 03 12:26:40 <ignus> im looking now but i cant find "netlink" anywhere
Apr 03 12:26:58 <ignus> any idea where it might be?
Apr 03 12:28:12 <bluelightning> hmm, actually I'm not sure if there is an option in current kernels, grepping through the config here
Apr 03 12:29:20 <bluelightning> ignus: I guess I would suggest checking the README in the udev sources which has a list of the required kernel options
Apr 03 12:30:00 <ignus> yeah - not a bad idea
Apr 03 12:33:26 <ignus> ill see if i can get some help on #udev first :D
Apr 03 12:36:08 <otavio_> I just got: | configure.in:496: warning: macro `AM_GNU_GETTEXT_VERSION' not found in library
Apr 03 12:36:11 <otavio_> | configure.in:497: warning: macro `AM_GNU_GETTEXT' not found in library
Apr 03 12:36:13 <otavio_> in shadow-native
Apr 03 12:36:31 <otavio_> so it seems last changes broken it instead of fixing it
Apr 03 12:36:40 <otavio_> RP__: any clue about it?
Apr 03 12:37:19 <RP__> otavio_: thats with the latest master?
Apr 03 12:37:47 <RP__> The changes in master were meant to fix that
Apr 03 12:38:06 <otavio_> yes
Apr 03 12:38:14 <otavio_> just did a combo-update
Apr 03 12:38:40 <otavio_> i am at 5bcb68a232539cf11a30e3b812b2fbd6d7d76e35
Apr 03 12:38:42 <otavio_> in oe-core
Apr 03 12:39:13 <RP__> otavio_: the theory is that gettext-minimal-native should install the gettext aclocal directory and gettext-native should not
Apr 03 12:39:27 <RP__> otavio: so see which of the two put aclocal files in the sysroot?
Apr 03 12:39:45 <otavio> how i can check it?
Apr 03 12:39:58 <otavio> i'd like to avoid making it unreproducable
Apr 03 12:41:01 <RP__> otavio: well, presumably it just built gettext-minimal-native. If you go into that WORKDIR and look in image/, are there aclocal files there?
Apr 03 12:42:06 <otavio> RP__: yes
Apr 03 12:42:25 <RP__> otavio: does gettext-native have the same files or not?
Apr 03 12:42:37 <otavio> (devel)~/hacking/ossystems/embedded-linux% ls tmp-eglibc-eglibc/work/x86_64-linux/gettext-minimal-native-0.18.1.1-r3/image/home/otavio/hacking/ossystems/embedded-linux/tmp-eglibc-eglibc/sysroots/x86_64-linux/usr/share/aclocal/ | wc -l
Apr 03 12:42:41 <otavio> 7
Apr 03 12:43:19 <RP__> otavio: there should be 31 files in there
Apr 03 12:43:38 <otavio> RP__: gettext-native does not
Apr 03 12:43:58 <RP__> otavio: ok, the problem is you seem to be missing files. Look at the tarball in the gettext-minimal-native recipe
Apr 03 12:44:44 <RP__> otavio: did you run out of space recently in the build directory?
Apr 03 12:45:28 <otavio> RP__: i did not
Apr 03 12:45:29 <otavio> Filesystem            Size  Used Avail Use% Mounted on
Apr 03 12:45:29 <otavio> /dev/disk/by-uuid/5c1bab1a-0bc9-4afc-9b09-ac55ceb79c10 1.4T  625G  681G  48% /home
Apr 03 12:45:35 <otavio> 681G free
Apr 03 12:45:56 <RP__> otavio: I don't understand how you can be missing some of the m4 files. See the recipe and you'll see what I mean
Apr 03 12:45:58 <otavio> RP__: yes, seems the tgz has 31 files
Apr 03 12:46:31 <RP__> otavio: I'd check WORKDIR and see how many got extracted, also check the workdir logs
Apr 03 12:46:40 <RP__> see if anything jumps out
Apr 03 12:47:20 <otavio> in WORKDIR, 31
Apr 03 12:47:43 <otavio> maybe commandline size?
Apr 03 12:48:26 * otavio rebuilds it to confirm it is reproducable
Apr 03 12:49:47 <otavio> good; it is reproducable
Apr 03 12:49:51 * otavio will fix it
Apr 03 12:51:00 * otavio builds it again
Apr 03 12:56:22 <otavio> i am stupid heh
Apr 03 12:56:28 <otavio> i need to call: ls -1
Apr 03 12:56:37 <otavio> otherwise it won't be accurate hehe
Apr 03 12:56:46 <otavio> RP__: it was copying it fine
Apr 03 12:57:13 <RP__> otavio: ah :)
Apr 03 12:57:48 <RP__> otavio: and those files make it into the main sysroot?
Apr 03 12:58:04 <RP__> otavio: If things aren't finding them from there I'm puzzled :/
Apr 03 12:58:26 <otavio> RP__: it happened in my daily builder
Apr 03 12:58:47 <otavio> RP__: after i did a cleansstate and built it again it builds shadow-native
Apr 03 12:58:55 <otavio> but i fail to see why autobuilding failed
Apr 03 12:59:23 <RP__> otavio: which recipe did you cleansstate on?
Apr 03 13:00:13 <otavio> the gettext-minimal-native, only
Apr 03 13:14:17 <ignus> does anyone know where udevd should be launched from on boot?
Apr 03 13:14:36 <otavio> ignus: it has a proper init script for it
Apr 03 13:16:20 <RP__> otavio: I'm puzzled. We bumped the PR for gettext-minimal-native so it should have rebuilt and it should have had those files in it even before the changes anyway
Apr 03 13:16:28 <RP__> otavio: ah, I might understand
Apr 03 13:16:52 <otavio> RP__: really? You are my hero! :-)
Apr 03 13:16:54 <RP__> otavio: I bet when your builder removed gettext-native it removed the files from the sysroot thinking it still owned them
Apr 03 13:16:54 <otavio> lol
Apr 03 13:17:28 <otavio> well but in this case the gettext-minimal-native would put they back
Apr 03 13:18:05 <RP__> otavio: imagine it builds gettext-minimal-native first which puts them there, then starts to build gettext-native which wasn't uninstalled from the sysroot yet
Apr 03 13:19:03 <otavio> oh  right
Apr 03 13:19:20 <ignus> otavio: do you know what that init script is called?
Apr 03 13:19:31 <otavio> the only way to fix this is to have a sysroot by build recipe, no?
Apr 03 13:19:38 <otavio> udev?
Apr 03 13:19:39 <otavio> :)
Apr 03 13:20:09 <RP__> otavio: the fix is to clean gettext-native and gettext-minimal-native
Apr 03 13:20:17 <RP__> otavio: the system will then figure it out
Apr 03 13:20:33 <RP__> otavio: I don't think we can automate it though :(
Apr 03 13:20:40 <otavio> RP__: well but for an autobuilder this is a no-go
Apr 03 13:21:40 <RP__> otavio: depends on the autobuilder setup too. The yocto ab's won't hit this as they start from a new tmp using sstate
Apr 03 13:21:56 <otavio> yes
Apr 03 13:22:04 <otavio> RP__: but if you reuse a tmp it fails
Apr 03 13:22:09 <otavio> RP__: mine re-uses it
Apr 03 13:22:18 <otavio> RP__: but fine. nice we found it
Apr 03 13:22:25 <RP__> otavio: right. As I said, I have no idea how to automate that fix
Apr 03 13:25:07 <otavio> RP__: well, if bitbake raised the removal of all packages to be rebuild, before doing the build, it would work
Apr 03 13:25:16 <otavio> RP__: it would emulate a new tmp
Apr 03 13:25:50 <RP__> otavio: bitbake does not contain such a mechanism though
Apr 03 13:26:06 <RP__> otavio: I understand there are ways of fixing it but nothing I can easily put in the repository right now :(
Apr 03 13:26:25 <otavio> i see
Apr 03 13:26:37 <otavio> RP__: no problem; this is good to have in radar
Apr 03 13:26:53 <otavio> RP__: is any plan to put sysroot per build package?
Apr 03 13:26:53 <RP__> otavio: right
Apr 03 13:27:06 <RP__> otavio: there is a feature request for it in the bugzilla
Apr 03 13:27:11 <otavio> oe-lite has something in this direction iirc
Apr 03 13:27:43 <RP__> oe-lite has some interesting things, its just a shame compatibility was broken to the extend we can't reuse any of it :(
Apr 03 13:27:43 <otavio> and it would allow for reproducable builds (without mangling configure options)
Apr 03 13:28:14 <otavio> RP__: indeed
Apr 03 13:56:57 <chrisw957> python hashlib doesn't seem to work for me.  I've tried with both openssl and dropbear, thinking that was the problem, but no luck. http://pastebin.com/w690DmHf
Apr 03 14:12:34 <bluelightning> chrisw957: you have libcrypto installed right?
Apr 03 14:45:56 <chrisw957> bluelightning: that would be the libgcrypt recipe?
Apr 03 14:46:16 <bluelightning> chrisw957: no, libcrypto is provided by the openssl recipe
Apr 03 14:46:32 <bluelightning> may actually be libssl according to the packaging on my ubuntu machine here
Apr 03 14:46:48 <chrisw957> target doesn't seem to have libcrypto.* in /usr/lib, so I guess not.
Apr 03 14:54:03 <chrisw957> actually, libcrypto is there, just in /lib instead of /usr/lib
Apr 03 14:56:21 <autif> I have CONFIG_DEBUG_KERNEL=y and Kernel command line: initrd=initrd LABEL=boot root=/dev/ram0 debug BOOT_IMAGE=vmlinuz, however, I dont think that I am seeing the messages from dev_vdbg() functions - do I need to do something more?
Apr 03 15:23:09 <chrisw957> libcrypto is built by openssl recipe.
Apr 03 15:23:36 <chrisw957> I don't see a libcrypto-dev, not sure if that would help me or not.
Apr 03 15:24:19 <chrisw957> If I install the openssl-dev ipkg, I get unsatisfied recommendation for libcrypto-dev.
Apr 03 15:24:44 <sgw> bluelightning: Has there been a patch for increasing the size of the self-hosted-image?  I am still catching up.
Apr 03 15:24:58 <bluelightning> sgw: no, not that I've seen
Apr 03 15:25:35 <sgw> bluelightning: thanks, have you started to dig into the qemu issue?
Apr 03 15:26:07 <bluelightning> sgw: I haven't, no - would you like me to?
Apr 03 15:26:59 <fray> AT&T just died here..
Apr 03 15:27:11 <fray> I'll rejoin if I can.. maybe it was sgw's joke
Apr 03 15:27:31 <fray> 3G is still up, but edge is dead.. and my phone is still edge.. :P
Apr 03 15:28:13 <fray> ugh.. edge died.. nice
Apr 03 15:28:37 <sgw> bluelightning: I was just starting a build, depends how far into it you are already
Apr 03 15:29:28 <fray> ...and it's back.. call still on?
Apr 03 15:29:35 <bluelightning> fray: yep
Apr 03 15:30:05 <bluelightning> sgw: I was looking into other failures today; I can run a build overnight with the size up to 40g though
Apr 03 15:30:07 <fray> I'm back
Apr 03 15:30:11 <bluelightning> I'll probably do that anyway
Apr 03 15:30:34 <sgw> bluelightning: Ok, I will make sure to sync up with you at the end of my day.
Apr 03 15:30:53 <sgw> bluelightning: I will build a minimal so it can go faster.
Apr 03 15:31:52 <bluelightning> sgw: btw I did wonder if we should adjust the reserved space for the ext3 image - right now about 2gb is reserved for root which is not really needed
Apr 03 15:32:57 <sgw> bluelightning: are you referring to the IMAGE_ROOTFS_EXTRA_SPACE in self-hosted-image or someplace else?
Apr 03 15:34:09 <bluelightning> sgw: what I mean is, by default when you create an ext3 fs it reserves 5% of the space for root only
Apr 03 15:36:56 <sgw> bluelightning: your talking about the IMAGE_OVERHEAD_FACTOR which is 1.3?
Apr 03 15:37:07 <bluelightning> sgw: no, that's separate again
Apr 03 15:37:14 <bluelightning> man mke2fs
Apr 03 15:37:20 <bluelightning> see the -m option
Apr 03 15:37:29 <fray> mute?
Apr 03 15:38:05 <bluelightning> can be adjusted with tune2fs
Apr 03 15:38:47 <bluelightning> it just means we currently cannot use 5% of the space we allocate as the builder user
Apr 03 15:38:49 <sgw> bluelightning: Ah, now I know what your talking about, sorry for being dense!
Apr 03 15:41:25 <sgw> bluelightning: so for the build app we could reduce this, but I would not reduce it in the general case.
Apr 03 15:41:51 <bluelightning> sgw: I guess it's just a case of adding a variable for it... I'll prepare something
Apr 03 15:42:04 <sgw> bluelightning: Sounds like a plan
Apr 03 15:50:10 <fray> Bug 2234 updated..
Apr 03 16:25:24 <fray> arg.. I'm having problem w/a multilib setup
Apr 03 16:25:54 <fray> I have the following in my local.conf:
Apr 03 16:25:54 <fray> require conf/multilib.conf
Apr 03 16:25:54 <fray> MULTILIBS = "multilib:lib32"
Apr 03 16:25:54 <fray> DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
Apr 03 16:26:09 <fray> when I try to bitbake eglibc-lib32   I get "nothing provides eglibc-lib32"
Apr 03 16:26:12 <fray> what am I doing wrong?
Apr 03 16:30:04 <fray> morning
Apr 03 16:30:09 <chrisw957> On my hashlib python problem, if I examine python, it doesn't seem to show libcrypto as I would expect: http://pastebin.com/MZcEEveH
Apr 03 16:30:19 <chrisw957> (examine with ldd)
Apr 03 16:30:54 <chrisw957> Could this be a build problem with python then?
Apr 03 16:31:28 <fray> I would expect python to load it only if it's needed
Apr 03 16:31:58 <fray> on my CentOS 5.2 system I get a very similar ldd output
Apr 03 16:33:14 <chrisw957> Humm, on my ubuntu, it lists libcrypto along with the others.  Could it be it is listed if openssl is detected at python build time?
Apr 03 16:34:52 <fray> My guess is that on my CentOS system at least, it's loaded dynamically if the crypto (python) module is used
Apr 03 16:37:15 <ant_work> seems so, btw no issues on Gentoo:
Apr 03 16:37:15 <ant_work> [ebuild   R    ] dev-lang/python-3.2.2  USE="gdbm ncurses readline ssl threads (wide-unicode) xml -build -doc -examples -ipv6 -sqlite -tk -wininst" 0 kB
Apr 03 16:38:43 <ant_work> wait, what is that linux-gate.so.1 =>  (0xb7843000)
Apr 03 16:38:43 <ant_work>  in ldd output?
Apr 03 16:39:24 <fray> there is some preloader stuff..
Apr 03 16:39:42 <fray> on CentOS/Fedora/RedHat there is a linux-vdso.so.1, on others it's linux-gate.. etc..
Apr 03 16:39:48 <ant_work> ah, ok, syscalls etc
Apr 03 16:39:50 <fray> it's a small library that helps optimize things
Apr 03 16:40:02 <fray> the libraries are loaded dynamically to preserve compatibility with other machines..
Apr 03 16:47:42 <walters> the vdso is actually mapped by the kernel
Apr 03 16:48:06 <walters> see Documentation/API/stable/vdso
Apr 03 16:48:50 <ant_work> seems mostly x86 stuff
Apr 03 16:49:49 <ant_work> (I'm testing on 32bit host)
Apr 03 16:50:44 <Crofton> jawilson, welcome
Apr 03 16:50:56 <jawilson> Crofton, hola
Apr 03 16:52:58 <Crofton> ok, now I know why davest, Dirk and RP are sitting in the front row
Apr 03 17:03:05 <Crofton> arg
Apr 03 17:03:16 <Crofton> he said "Yocto" without the "Project"
Apr 03 17:03:18 <fray> found a nice bug..
Apr 03 17:03:27 <fray> -march=armv5e is completely valid in gcc..
Apr 03 17:03:32 <fray> but binutils goes "huh?!"
Apr 03 17:03:39 <fray> there is no armv5e defined in binutils
Apr 03 17:03:51 <fray> it defines armv5te and armv5
Apr 03 19:42:32 <rburton> i'm using the edison branch in git, and getting a compile error in syslinux
Apr 03 19:42:44 <rburton> | In file included from ../libinstaller/linuxioctl.h:22:0,
Apr 03 19:42:44 <rburton> |                  from ../libinstaller/syslxcom.c:33:
Apr 03 19:42:44 <rburton> | /usr/include/linux/ext2_fs.h:178:41: error: unknown type name 'umode_t'
Apr 03 19:43:00 <rburton> (on fedora 16, so kernel 3.3)
Apr 03 19:43:24 <rburton> my first thought was kernel churn, but shouldn't syslinux be using the kernel headers built by yocto?
Apr 03 21:15:27 <dvhart> something about syslinux under discussion? (no history to readback)
Apr 03 21:15:36 <dvhart> all sorted or still some open questions
Apr 03 21:16:17 <incandescant> rburton: pasted the following:
Apr 03 21:16:17 <incandescant> (12:42:32) rburton: i'm using the edison branch in git, and getting a compile error in syslinux
Apr 03 21:16:17 <incandescant> (12:42:44) rburton: | In file included from ../libinstaller/linuxioctl.h:22:0,
Apr 03 21:16:17 <incandescant> (12:42:44) rburton: |                  from ../libinstaller/syslxcom.c:33:
Apr 03 21:16:17 <incandescant> (12:42:44) rburton: | /usr/include/linux/ext2_fs.h:178:41: error: unknown type name 'umode_t'
Apr 03 21:16:45 <rburton> hi dvhart
Apr 03 21:16:49 <dvhart> rburton, interesting - which machine are you building for?
Apr 03 21:16:50 <rburton> just found the cause
Apr 03 21:16:56 <rburton> http://comments.gmane.org/gmane.comp.file-systems.ext4/31668
Apr 03 21:16:57 <dvhart> your end our mine?
Apr 03 21:17:04 <rburton> in particular, comment #3
Apr 03 21:17:23 <rburton> (this is the edison branch, so you may have already fixed this in master)
Apr 03 21:18:08 <rburton> building for atom-pc.
Apr 03 21:18:13 <dvhart> hrm
Apr 03 21:18:26 <dvhart> so was this syslinux-native?
Apr 03 21:19:31 <dvhart> rburton, either way, this needs to be fixed in an edison point release as well as master if it isn't already. WOuld you open a bug, add the details of the failure, and ensure I'm on CC?
Apr 03 21:19:36 <rburton> erm
Apr 03 21:19:36 <dvhart> rburton, I'll have a look.
Apr 03 21:19:55 <rburton> yes, native. sorry, didn't notice that
Apr 03 21:20:06 <rburton> that would be why it was using the system headers. :)
Apr 03 21:20:12 <dvhart> ;-)
Apr 03 21:20:15 <incandescant> I'm very surprised we haven't seen this before :-/
Apr 03 21:20:35 <rburton> i do like to break things
Apr 03 21:20:48 <incandescant> I would imagine that requiring the system kernel headers is not something we want to do?
Apr 03 21:20:51 <dvhart> sounds like the fix is to pull in whatever fix hpa puts into syslinux
Apr 03 21:21:05 <rburton> yeah
Apr 03 21:21:12 <dvhart> incandescant, there are situations where that might be required
Apr 03 21:21:42 <dvhart> although they should be rare
Apr 03 21:21:57 <incandescant> dvhart: hmm, OK - I know nothing, but I am surprised by that.
Apr 03 21:21:58 <dvhart> we don't build linux-libc-headers for the host as far as I'm aware
Apr 03 21:22:14 <dvhart> and while we could, the ABI isn't perfectly stable
Apr 03 21:22:20 <incandescant> I'm sure I've written patches for that purpose in the past
Apr 03 21:22:26 <dvhart> hrm
Apr 03 21:22:30 <incandescant> or... maybe not
Apr 03 21:22:37 <rburton> erm, so where would this be filed?
Apr 03 21:22:41 <incandescant> no, that instance was target kernel
Apr 03 21:22:55 <incandescant> bugzilla.yoctoproject.org build system / general
Apr 03 21:22:58 <rburton> thanks
Apr 03 21:23:09 <dvhart> incandescant, beat me to it :)
Apr 03 21:23:19 <incandescant> bug buckets are awesome
Apr 03 21:23:23 <rburton> :)
Apr 03 21:23:28 <rburton> and what version is edison? :)
Apr 03 21:24:53 <incandescant> 1.1.1
Apr 03 21:24:55 <dvhart> 1.1
Apr 03 21:25:02 <dvhart> erm, yeah, what incandescant said
Apr 03 21:26:10 <dvhart> no fix in syslinux yet
Apr 03 21:26:27 <dvhart> rburton, which host/kernel are you building on?
Apr 03 21:26:30 <rburton> you've got mail, but https://bugzilla.yoctoproject.org/show_bug.cgi?id=2236
Apr 03 21:26:39 <rburton> dvhart: amd64, fedora 16, kernel 3.3
Apr 03 21:26:46 <rburton> its the kernel 3.3 bit that makes it break
Apr 03 21:26:48 <dvhart> perfect
Apr 03 21:26:49 <dvhart> thanks
Apr 03 21:27:01 <rburton> fedora 16 with updates as of a week or so ago
Apr 03 21:27:03 <dvhart> well specifically it's the kernel headers
Apr 03 21:27:15 <rburton> yeah
Apr 03 21:27:28 <rburton> i'll leave this in your capable hands and go back to the sofa, where my beer is waiting
Apr 03 21:27:39 <rburton> g'night all
Apr 03 21:29:04 <incandescant> night rburton
Apr 03 21:29:25 <dvhart> night :)
Apr 03 21:31:12 <ant__> hi dvhart
Apr 03 21:31:55 <dvhart> hi ant__
Apr 03 21:37:11 <ant__> dvhart: have you ever seen this ?  http://paste.debian.net/161947/
Apr 03 21:37:46 <dvhart> uh.... no
Apr 03 21:37:54 <dvhart> is that just a clone?
Apr 03 21:38:08 <ant__> it's surely my bad linux-yocto-tiny.bbappend
Apr 03 21:38:17 <ant__> WARNING: Can't find any BSP hardware or required configuration fragments.
Apr 03 21:38:25 <dvhart> that is expected for now
Apr 03 21:38:43 <ant__> before refactoring it was poosible to add the defconfig and the patches
Apr 03 21:39:43 <ant__> now I get a kernel for CONFIG_ARCH_VERSATILE=y
Apr 03 21:39:46 <ant__> heh
Apr 03 21:40:15 <dvhart> There really isn't any value in using linux-yocto-tiny if you replace the config using a defconfig
Apr 03 21:40:19 <dvhart> BUT, it should not fail
Apr 03 21:40:54 <dvhart> is that odd "grep: Memory exhausted" failure repeatable?
Apr 03 21:40:55 <ant__> the big value from my POV is that I gain automatic upgrades (see we have 3.2.14 today...)
Apr 03 21:41:07 <ant__> yes, I've seen that yesterday too
Apr 03 21:41:23 <dvhart> Sure, but you get that with linux-yocto_3.2.bb
Apr 03 21:41:42 <ant__> seems during loop in do_patch () in kernel-yocto.bbclass
Apr 03 21:41:48 <dvhart> linux-yocto-tiny doesn't include linux-tools.inc, so that's a value I guess.
Apr 03 21:41:54 <dvhart> hrm
Apr 03 21:42:14 <dvhart> So... does the build fail?
Apr 03 21:42:29 <dvhart> or does it "succeed" with an incorrect .config?
Apr 03 21:42:52 <ant__> no, kernel is built, but using another defconfig, not mine :)
Apr 03 21:43:09 <dvhart> ok, and your defconfig you add as:
Apr 03 21:43:13 <dvhart> SRC_URI += "defconfig"
Apr 03 21:43:19 <dvhart> and you place that in your filespath?
Apr 03 21:43:40 <dvhart> SRC_URI += "file://defconfig" rather
Apr 03 21:44:08 <ant__> yes, exactly like I did when all was in 'recipe-space'
Apr 03 21:44:41 <dvhart> do me a favor
Apr 03 21:44:41 <ant__> http://paste.debian.net/161951/
Apr 03 21:44:56 <dvhart> add the following to your recipe:
Apr 03 21:45:00 <ant__> finally I did try to play with KMACHINE
Apr 03 21:45:40 <dvhart> KCONFIG_MODE = "--alldefconfig"
Apr 03 21:45:52 <dvhart> and see if anything changes
Apr 03 21:49:03 <ant__> well,  ERROR: Function failed: do_kernel_configme
Apr 03 21:49:23 <dvhart> hrm
Apr 03 21:49:26 <dvhart> crap
Apr 03 21:49:27 <ant__>  mkdir: unrecognized option '--alldefconfig'
Apr 03 21:49:35 <dvhart> weird
Apr 03 21:49:40 <dvhart> ok, set it to ""
Apr 03 21:49:57 <ant__> sure
Apr 03 21:52:03 <ant__> though, the code and comments in kernel-yocto.bbclass refer to  --allnoconfig
Apr 03 21:53:22 <ant__> building with "" now
Apr 03 21:53:40 <ant__> grep: Memory exhausted
Apr 03 21:53:45 <ant__> )fwiw
Apr 03 21:54:01 <dvhart> how much memory are you working with btw?
Apr 03 21:54:09 <ant__> heh, 8GB
Apr 03 21:54:19 <dvhart> ok, just checking :)
Apr 03 21:56:52 <dvhart> but what about the .config now?
Apr 03 21:57:09 <ant__> well, versatile
Apr 03 21:57:14 <ant__> System.map                                                                                                               583/1225K               0%
Apr 03 21:57:14 <ant__> 0000000c A cpu_arm926_suspend_size
Apr 03 21:57:53 <dvhart> and what are you trying to get?
Apr 03 21:58:16 <ant__> so, the defconfig I pass from SRC_URI is in WORKDIR together with patch and logo
Apr 03 21:58:48 <dvhart> right, but the .config in the linux-*build/.config != defconfig ?
Apr 03 21:58:56 <ant__> and gen_._desc.scc is generated and contains that single patch
Apr 03 21:59:13 <kergoth> RP__: TERM is in the hashbase whitelist, yet I just had a recipe's sstate cache not be used to due TERM being added to the dependencies of a shell task. it seems like it might not be caring about the value, but *is* caring about the existance of the variable, even for whitelisted ones. imo this should not be the case
Apr 03 21:59:18 <kergoth> investigating further
Apr 03 21:59:43 <kergoth> s/to due/due to/
Apr 03 22:00:32 <ant__> dvhart: another device, an armv5te
Apr 03 22:00:53 <dvhart> OK, sounds like we need a bug opened
Apr 03 22:00:58 <dvhart> would you mind opening it?
Apr 03 22:01:02 <dvhart> I'll have a look locally
Apr 03 22:01:06 <dvhart> this needs fixing asap
Apr 03 22:03:27 <ant__> I can just say that linux-yocto-tiny_3.0.bbappend did somehow accept that
Apr 03 22:05:44 <dvhart> ant__ got it
Apr 03 22:05:52 <dvhart> zeddii, ^
Apr 03 22:05:56 <ant__> that was fast!
Apr 03 22:05:57 <dvhart> zeddii, just a heads up
Apr 03 22:06:17 <dvhart> ant__, oh not, not fixed, I just "get" what you're saying :-)
Apr 03 22:06:41 <ant__> ;)
Apr 03 22:17:34 <kergoth> damnit, this isn't  making any sense
Apr 03 22:43:16 <kergoth> yeah, this looks like it's a bug in siggen.py, think I have a fix
Apr 03 22:43:47 * kergoth sighs
Apr 03 22:53:58 <mranostay> hey kergoth
Apr 03 22:54:42 <ant__> dvhart: well, my bad, I don't have yocto-kernel-tools on this build :/
Apr 03 22:55:11 <dvhart> but it should pull them automatically
Apr 03 22:55:21 <dvhart> via the yocto-kernel inc or whatever
Apr 03 22:55:43 <ant__> hm.. where are createme and patchme then ?
Apr 03 23:04:31 <ant__> dvhart: ok, thx, I see them in sysroot  (kern-tools-native:do_populate_sysroot)
Apr 03 23:53:09 <Andy44> hello is anyone there?
Apr 03 23:56:31 <Andy44> I have a goofy thing going on here.  I've been trying to get remote debugging working on my sugarbay target.  The tcf-agent is running on my target.  I've installed the ADT toos from a tarball (...i686-x86-64).  I can transfer my hellow world binary to /tmp on the target with RSE in Ecplise - it's pretty slick actually.  However, for the life of me I can't get the binary to execute on the target.
Apr 03 23:58:22 <Andy44> I use "root@sugarbay:/tmp#try8" and get "-sh: try8: command not found" - that's fine I haven't added /tmp to my $PATH
Apr 03 23:58:24 <dvhart> jzhang, looks like one for you :)
Apr 03 23:59:40 <incandescant> Andy44: is that how Eclipse tries to run it? or you're calling it from a terminal?
Apr 03 23:59:46 <Andy44> I use "root@sugarbay:/tmp#./try8" and get "-sh: ./try8: No such file or directory
Apr 04 00:00:30 <Andy44> well right now I'm trying to run directly on my target - I have a monitor and keyboard connected
Apr 04 00:01:14 <incandescant> and the architecture of the binary matches the host?
Apr 04 00:01:16 <Andy44> finall, I use "bash try8" and get "try8: try8: cannot execute binary file.
Apr 04 00:01:39 <Andy44> yeah I've been burned by that before however this time i'm pretty sure it's correct
Apr 04 00:02:49 <incandescant> hmm, I'm out then
Apr 04 00:02:54 <Andy44> interestingly, on my Ubuntu 11.10 build VM I can call "./try8" and it runs
Apr 04 00:02:56 <dvhart> Andy44, you can confirm with "file binary"
Apr 04 00:03:13 <Andy44> what's that? let me look it up hold on
Apr 04 00:03:41 <dvhart> $ file /path/to/target/binary
Apr 04 00:03:59 <dvhart> for example:
Apr 04 00:04:00 <dvhart> $ file /bin/bash
Apr 04 00:04:01 <dvhart> /bin/bash: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, stripped
Apr 04 00:04:33 <Andy44> the "file" command is not in my image - I'm using a sugarbay core-image-minimal
Apr 04 00:06:35 <Andy44> are my tools correct? I downloaded poky-eglibc-i686-x86_64-toolchain-gmae-1.1.tar.bz2.tar.bz2.tar.bz2 and built against that.  my build env is 32bit ubuntu 11.10 and it builds fine. the target is a core i5 and I've built the image with MACHINE=sugarbay
Apr 04 00:08:09 <dvhart> you can run that from your host to wherever that file is in the sysroots
Apr 04 00:08:24 <Andy44> calling "uname -a" on the target gives me "Linux sugarbay 3.0.4-yocto-standard+ #1 SMP PREEMPT Fri Mar 23 09:20:10 PDT 2012 x86-64 GNU/Linux
Apr 04 00:09:45 <Andy44> it's not in my sysroot on the target's files located on my build env because I transfered it over to the target via tcf-agent in ecplise
Apr 04 00:10:42 <Andy44> ahhhhh
Apr 04 00:11:46 <Andy44> I called "file try8" on my build machine and it gave me "ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, not stripped
Apr 04 00:11:47 <Andy44> ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, not stripped"
Apr 04 00:12:19 <Andy44> sooo that means that I'm building a 32 bit binary and it's just not going to work...
Apr 04 00:12:22 <Andy44> right?
Apr 04 00:24:22 <Andy44> if that's the case - the better question is why do my tools spit out 32bit binarys? - i'm using poky-eglibc-i686-x86_64-toolchain-gmae-1.1.tar.bz2.tar.bz2.tar.bz2 from the yocto website - do I need to use a 64bit Ubuntu to build for this target or something?
Apr 04 00:25:48 <Andy44> dvhart, Do you have any idea why my tools would be building a 32bit binary?
Apr 04 00:27:40 <Andy44> incandescant, I think you were right all along but this doesn't make sense.  Why would know why this toolchain - poky-eglibc-i686-x86_64-toolchain-gmae-1.1.tar.bz2.tar.bz2.tar.bz2 - would give me 32bit binarys?
Apr 04 00:28:18 <dvhart> you don't need to change your host
Apr 04 00:28:42 <dvhart> Andy44, is this try8 your own recipe?
Apr 04 00:29:03 <Andy44> no it's the ADT Hellow World template
Apr 04 00:29:20 <dvhart> right
Apr 04 00:29:29 <dvhart> I'd bring that up with jzhang
Apr 04 00:29:41 <Andy44> I'm following the ADT manual and I'm building the hellow world and trying to debug it on my target but I need it to run there first
Apr 04 00:29:52 <Andy44> ok no clues though?
Apr 04 00:30:03 <Andy44> Is that toolchain the right one?
Apr 04 00:30:19 <Andy44> it seems like it should be
Apr 04 00:30:39 <dvhart> Andy44, I believe this to be a bug in the Hello World example
Apr 04 00:30:47 <dvhart> please send jzhang an email describing the issue
Apr 04 00:31:20 <Andy44> ok thanks for your time everyone.  how do I get jzhang's email?
Apr 04 00:31:35 <dvhart> shouldn't be difficult searching the yocto list :-)
Apr 04 00:31:51 <Andy44> haha sorry - thanks again for your time
Apr 04 00:32:12 <dvhart> Andy44, also, see pm
**** ENDING LOGGING AT Wed Apr 04 02:59:58 2012

**** BEGIN LOGGING AT Wed Apr 04 02:59:59 2012
Apr 04 10:31:55 <sophie__> hello
Apr 04 10:32:47 <sophie__> trying to extend the size of the rootfs being used.
Apr 04 11:23:44 <bluelightning> sophie__: there is IMAGE_ROOTFS_SIZE which is the minimum size or IMAGE_ROOTFS_EXTRA_SPACE which will be added to the total used space
Apr 04 11:39:10 <ericben> hi, anyone to review : http://patches.openembedded.org/patch/25089/ & http://patches.openembedded.org/patch/25087/ ?
Apr 04 12:21:09 <sophie__> bluelightning_: I have found the variable IMAGE_ROOTFS_EXTRA_SPACE in meta/conf/bitbake.conf. Where is it best to modify this variable in this file or add it to the local.conf file
Apr 04 13:05:19 <bluelightning> sophie__: I would recommend setting it in local.conf; alternatively you can create a custom image recipe that sets it
Apr 04 15:07:06 <dvhart> rburton, syslinux patch attached to bug 2238, please give it a spin
Apr 04 15:07:21 <dvhart> rburton, erm, bug 2236 even
Apr 04 15:09:04 <ant_work> hi dvhart
Apr 04 15:09:52 <dvhart> hi ant_work - I'm afk for a bit, back after the morning routine
Apr 04 16:13:42 <dvhart> ant_work, I'm back - what's up?
Apr 04 16:14:52 <ant_work> I plan to dig in the kgit-meta code and see why grep is exhausting memory
Apr 04 16:15:20 <dvhart> ok. I'm wrapping up bug 2236, then will be able to look at this as well
Apr 04 16:15:27 <dvhart> I'll be focusing on why your defconfig isn't taking
Apr 04 16:15:46 <zeddii> what's this ?
Apr 04 16:15:46 <dvhart> zeddii, did you see the grep memory exhaustion ant_work posted yesterday?
Apr 04 16:15:51 <zeddii> nope.
Apr 04 16:15:55 <zeddii> I've been working on 3.4
Apr 04 16:16:02 <ant_work> ah, about that,  I'll try the 'brute-force' approach which was presented and nacked on poky ML
Apr 04 16:16:03 <dvhart> ant_work, , do you still have the pastebin?
Apr 04 16:16:06 <ant_work> y
Apr 04 16:16:11 <zeddii> I'd bet it isn't kgit-meta
Apr 04 16:16:16 <ant_work> http://paste.debian.net/161947
Apr 04 16:16:24 <ant_work> after [INFO[ ...
Apr 04 16:16:55 <zeddii> how can I reproduce it ? I've got a radically changed kgit-meta here, but nothing I can put into 1.2.
Apr 04 16:17:03 <ant_work> I'm just following the code from yocto-kernel.bbclass
Apr 04 16:17:04 <dvhart> zeddii, so ant_work added a defconfig in a bbappend to the new linux-yocto-tiny and it isn't applying
Apr 04 16:17:31 <dvhart> zeddii, or rather, the end result .config isn't the same as the defconfig
Apr 04 16:17:33 <ant_work> zeddii: http://paste.debian.net/161951
Apr 04 16:17:34 <zeddii> hmm. defconfigs all apply here.
Apr 04 16:17:45 <dvhart> zeddii, even to linux-yocto-tiny?
Apr 04 16:17:46 <zeddii> what's the delta in the .config ?
Apr 04 16:17:57 <zeddii> dvhart, sure. there's nothing special about linux-yocto-tiny.
Apr 04 16:18:17 <dvhart> wondering if the various variables we force in linux-yocto-tiny cause the tools to behave differently
Apr 04 16:18:33 <ant_work> it happens to produce a kernel for arm versatile and not for my arm device (poodle)
Apr 04 16:19:13 <dvhart> ant_work, can you post an actual diff of the defconfig and the resulting .config ?
Apr 04 16:19:23 <ant_work> well, in a few hours
Apr 04 16:19:32 <dvhart> ant_work, did you create the defconfig from the actual linux-yocto sources?
Apr 04 16:19:34 <zeddii> dvhart, there are big problems with merge_config with multiple configs, it iterates over all the configs, so if you have two defconfigs stacked it takes forever.
Apr 04 16:19:46 <ant_work> I just added mine from SRC_URI
Apr 04 16:19:47 <dvhart> hrm
Apr 04 16:20:21 <zeddii> I have it on my TODO list. it just takes time here, but no memory exhaustion.
Apr 04 16:20:23 <dvhart> ant_work, yes, but where did yours come from?
Apr 04 16:20:50 <ant_work> I create the config file. it was ok with older recipe (linux-yocto-tiny_3.0)
Apr 04 16:21:09 <dvhart> ant_work, ah, that is probably it
Apr 04 16:21:22 <dvhart> you can't assume a 3.0 .config will work out of the box with a 3.2 kernel
Apr 04 16:21:35 <dvhart> especially with tiny which uses --allnoconfig
Apr 04 16:21:38 <ant_work> I mean the *process* was ok
Apr 04 16:21:55 <ant_work> the defconfig is up-to-date and even shrunk by savedefconfig
Apr 04 16:21:58 <dvhart> ok, so same question, did you generate the defconfig from the linux-yocto sources?
Apr 04 16:22:12 <ant_work> no, it's external from vanilla tree
Apr 04 16:22:21 <dvhart> which vanilla tree?
Apr 04 16:22:30 <ant_work> I mean, in oe-core I build 3.2.12 iirc
Apr 04 16:22:35 <ant_work> with one patch
Apr 04 16:23:12 <ant_work> (minor patch, keymap)
Apr 04 16:23:42 <ant_work> something has changed during the linux-yocto-tiny rework
Apr 04 16:23:57 <ant_work> as when it was in recipe-space one could build the kernel
Apr 04 16:24:01 <dvhart> ant_work, part of the rework was moving to 3.2, the other part was meta related
Apr 04 16:24:13 <ant_work> I see
Apr 04 16:24:33 <dvhart> ant_work, please post your recipe, patches, and defconfig
Apr 04 16:24:39 <dvhart> I'll see what I can sort out
Apr 04 16:26:10 <dvhart> one thing you could try though, do a "bitbake linux-yocto-tiny -c kernel-configme", then copy your defconfig over the .config in the linux-*build work dir. Then run "bitbake linux-yocto-tiny -c menuconfig", check the key CONFIGs and save the settings. Then copy the resulting .config to a defconfig and use that int he recipe
Apr 04 16:26:19 <dvhart> I suspect that will resolve your issues
Apr 04 16:26:30 <dvhart> although we need to sort out what's up with the grep memory thing
Apr 04 16:27:21 <zeddii> that is odd. there's lots of grepping that happens (hence why the bigger changes), but unless the machine is really resource contrained, I've never seen a memory failure in 5 years.
Apr 04 16:27:21 <ant_work> see, I'm eager to try the bsp-tools but I prefer to settle with that 'hybrid' kernel with custom defconfig+patches as first step
Apr 04 16:28:22 <dvhart> ant_work, try the above and let me know how it goes. Failing that, please post your bits and we'll work on it locally
Apr 04 16:28:30 <ant_work> sure
Apr 04 16:28:35 <dvhart> zeddii, he has 8GB, so it isn't resource constrained
Apr 04 16:28:41 <dvhart> I checked ;-)
Apr 04 16:28:47 * ant_work noting all, channel seems lacking log bot
Apr 04 16:29:05 <zeddii> ok. so then something must be triggering and infinite loop if it is exhausting memory.
Apr 04 16:29:11 <bluelightning> ant_work: nslu2-log is here
Apr 04 16:29:13 <dvhart> yocti seen logbot
Apr 04 16:29:14 <yocti> dvhart: I have not seen logbot.
Apr 04 16:29:24 <dvhart> yocti++
Apr 04 16:29:41 <ant_work> bluelightning: ah, great! I was loking for CIA
Apr 04 16:30:02 <dvhart> halstead, yocti is awesome, thanks man!
Apr 04 16:30:13 <halstead> dvhart, Glad to hear.
Apr 04 16:30:26 <bluelightning> http://logs.nslu2-linux.org/livelogs/yocto.txt  and  http://logs.nslu2-linux.org/livelogs/yocto/
Apr 04 16:30:45 * dvhart thinks fedora should plan their releases to land at a convenient time for me to upgrade
Apr 04 16:30:48 <halstead> dvhart, I hope I can find time to link yocti into the bug tracking systems and such.
Apr 04 16:30:50 <dvhart> like this week for example
Apr 04 16:31:11 <dvhart> halstead, that would be my top request, bz integration
Apr 04 16:31:18 <dvhart> yocto bug 2236
Apr 04 16:31:28 * bluelightning thinks he should not have upgraded his home machine to ubuntu precise beta - now vmware workstation is broken :/
Apr 04 16:31:47 <incandescant> dvhart: upgrade now, suffer through the stabilisation like a man
Apr 04 16:31:54 <dvhart> dvhart: https://bugzilla.yoctoproject.org/show_bug.cgi?id=2236
Apr 04 16:32:00 <zeddii> 7 bugs and counting fixed on 3.4-rc1 :)
Apr 04 16:32:02 <dvhart> dvhart: syslinux-native fails with linux 3.3
Apr 04 16:32:07 <dvhart> zeddii++
Apr 04 16:32:15 <dvhart> yocti zeddii++
Apr 04 16:32:19 <dvhart> hrm
Apr 04 16:32:25 <dvhart> yocti help
Apr 04 16:32:25 <yocti> dvhart: (help [<plugin>] [<command>]) -- This command gives a useful description of what <command> does. <plugin> is only necessary if the command is in more than one plugin.
Apr 04 16:32:39 <dvhart> halstead, karma seems busted
Apr 04 16:32:48 <dvhart> or kudos
Apr 04 16:33:01 <dvhart> incandescant, hah - no thanks
Apr 04 16:33:02 <halstead> Hrmmm..
Apr 04 16:34:26 <halstead> karma zeddii
Apr 04 16:34:31 * zeddii mumbles that something horrible has happened to mips64 oprofile and hunts for food.
Apr 04 16:34:35 <halstead> yocti, karma zeddii
Apr 04 16:34:36 <yocti> halstead: Karma for "zeddii" has been increased 1 time and decreased 0 times for a total karma of 1.
Apr 04 16:35:39 <halstead> dvhart, It seems yocti only understands ++ and -- when addressed directly.
Apr 04 16:36:34 <dvhart> yocti, karma zeddii
Apr 04 16:36:34 <yocti> dvhart: Karma for "zeddii" has been increased 1 time and decreased 0 times for a total karma of 1.
Apr 04 16:36:48 <dvhart> yocti, zeddii++
Apr 04 16:36:52 <dvhart> yocti, karma zeddii
Apr 04 16:36:52 <yocti> dvhart: Karma for "zeddii" has been increased 2 times and decreased 0 times for a total karma of 2.
Apr 04 16:37:11 <dvhart> a bit overly pedantic methinks
Apr 04 16:37:28 <dvhart> but noted, thanks!
Apr 04 16:39:14 <ant_work> bbl, bye
Apr 04 16:39:58 <Crofton> hob slide up, davest must have been careful to make sure the displayed machine is an atom
Apr 04 16:40:25 <dvhart> Crofton, I suspect the exact opposite is the case
Apr 04 16:40:40 <Crofton> no machine is atom-pc :)
Apr 04 16:41:34 <halstead> icecream++
Apr 04 16:42:00 <halstead> yocti, karma most
Apr 04 16:42:00 <yocti> halstead: (karma most [<channel>] {increased,decreased,active}) -- Returns the most increased, the most decreased, or the most active (the sum of increased and decreased) karma things. <channel> is only necessary if the message isn't sent in the channel itself.
Apr 04 16:42:21 <halstead> yocti, karma most increased
Apr 04 16:42:22 <yocti> halstead: "zeddii": 2, "icecream": 1, and "halstead": 1
Apr 04 16:42:49 <halstead> dvhart, yocti will now recognize ++ and -- without being addressed directly.
Apr 04 16:43:00 <zeddii> woo
Apr 04 16:43:41 <dvhart> halstead++
Apr 04 16:43:46 <dvhart> yocti, karma halstead
Apr 04 16:43:46 <yocti> dvhart: Karma for "halstead" has been increased 2 times and decreased 0 times for a total karma of 2.
Apr 04 16:43:50 <Crofton> RP__, --
Apr 04 16:43:51 <dvhart> nice :)
Apr 04 16:43:53 <Crofton> :)
Apr 04 16:44:01 <dvhart> FAIL
Apr 04 16:44:08 <dvhart> yocti, karma RP__
Apr 04 16:44:08 <yocti> dvhart: RP__ has neutral karma.
Apr 04 16:44:23 <Crofton> he is like two seat sin front of me looking at his laptop I think
Apr 04 16:44:38 * dvhart considers removing the -- op
Apr 04 16:44:41 <RP__> Crofton: I am indeed
Apr 04 16:44:43 <Crofton> rofl
Apr 04 16:45:28 <Crofton> every time dave says "yocto" without "project" we -- him
Apr 04 16:45:50 <dvhart> Crofton, heh, now that's an appropriate usage
Apr 04 16:46:35 <Crofton> Dave needs to say, this is a community project and if you have good contributions we are glad to take them
Apr 04 16:46:43 <halstead> In my other communities -- for people is generally frowned upon. So nicks only get ++, but "kernel panic"-- is acceptable.
Apr 04 16:47:01 <Crofton> some of us are more trollish than others :)
Apr 04 16:47:01 <dvhart> halstead, agreed
Apr 04 16:47:23 <dvhart> save the trolling for #oe please ;-)
Apr 04 16:47:23 <bluelightning> how about automatic -- if you check in something that breaks the autobuilder?
Apr 04 16:47:27 <bluelightning> :)
Apr 04 16:47:34 <dvhart> bluelightning++
Apr 04 16:47:44 <bluelightning> that might be somewhat tricky to set up though...
Apr 04 16:47:47 <Crofton> rofl++
Apr 04 16:52:25 <Crofton> room is basically full for davest's yocto talk
Apr 04 16:53:05 <incandescant> Crofton - you mean Yocto Project talk, surely?
Apr 04 16:53:13 <dvhart> *snigger*
Apr 04 16:53:21 <Crofton> yes
Apr 04 16:53:25 <Crofton> ouch
Apr 04 16:53:28 <Crofton> Crofton, --
Apr 04 16:53:34 <Crofton> Crofton--
Apr 04 16:53:34 <yocti> Crofton: Error: You're not allowed to adjust your own karma.
Apr 04 16:53:40 <dvhart> bwahaha
Apr 04 16:53:43 <Crofton> yocti--
Apr 04 16:53:54 <dvhart> yocti, karma yocti
Apr 04 16:53:55 <yocti> dvhart: Karma for "yocti" has been increased 0 times and decreased 1 time for a total karma of -1.
Apr 04 16:54:13 <Crofton> anyone have a url for one of these self hosts vmware image
Apr 04 16:55:12 <JaMa> | checking for libexpat... no
Apr 04 16:55:12 <JaMa> | configure: error: expat is missing or unusable
Apr 04 16:55:16 <JaMa> someone--
Apr 04 16:57:38 * dvhart really needs to step up his automation-fu across his various test machines, VMs, and relevant distros,bsps,and images
Apr 04 17:07:50 <bluelightning> Crofton: I don't think any have been uploaded anywhere yet
Apr 04 17:08:52 <Crofton> someone was asking
Apr 04 17:09:06 <Crofton> I suspect davest will be all excited about the idea
Apr 04 17:10:16 <pidge> yocti, karma pidge
Apr 04 17:10:16 <yocti> pidge: pidge has neutral karma.
Apr 04 17:10:30 <pidge> nice.
Apr 04 17:10:57 <dvhart> pidge, clean slate!
Apr 04 17:15:00 <RP__> sgw: any example vmware images anywhere online?
Apr 04 17:15:31 <RP__> yocti++
Apr 04 17:15:50 * RP__ likes yocti
Apr 04 17:16:05 <fray> RP__ any change to review the tuning changes?  so far the only feed back have been to the readmes.. I plan to make the requested changes in the next hour (when my current meeting is over)
Apr 04 17:16:48 <RP__> fray: the patches merged
Apr 04 17:16:49 <pidge> dvhart: goes with my chaotic neutral alignment.
Apr 04 17:17:47 <fray> ahh cool
Apr 04 17:19:22 <fray> RP__ the binutils patch, I don't see that one in there..  still TBD?
Apr 04 17:19:45 <fray> (I was very surprised that "armv5e" was broken)
Apr 04 17:19:57 <RP__> fray: I don;t like patches like the tune ones at this point in the cycle
Apr 04 17:20:35 <fray> :) Ya I understand
Apr 04 17:20:50 <fray> I wish someone had realized this was a problem more then a week ago
Apr 04 17:21:12 <fray> (fixing took a couple days, testing took almost 5)
Apr 04 17:22:28 <fray> RP__ BTW there is the "supersparc" defined, but it doesn't follow the tuning guidelines.. any (post freeze) suggestions on how to address this?
Apr 04 17:24:23 <RP__> fray: I'm not surprised about armv5e, I've never really seen that hardware
Apr 04 17:24:47 <RP__> fray: We never went back and tidied up the tune files. I'd just delete superspace
Apr 04 17:24:58 <Crofton> superspace?
Apr 04 17:25:02 <fray> I didn't think there was an armv5e (w/o the t), but someone said they had such a device..  thats why it even exists..
Apr 04 17:25:06 <fray> heh
Apr 04 17:25:18 <fray> gcc says it's "legit" arch.. too bad binutils doesn't
Apr 04 17:25:54 <fray> do you want a commit (prior to release) for the sparc or should I ignore it till after?  (suggsting removal)
Apr 04 17:26:07 <RP__> fray: The hardware exists, its just not common
Apr 04 17:26:18 <RP__> fray: nobody uses it so I'll take a patch
Apr 04 17:26:33 <fray> ok.. with that, then all of the tunings are now consistent
Apr 04 17:26:40 <fray> WOOHOO!
Apr 04 17:30:26 <sgw> RP: check http://autobuilder.yoctoproject.org/pub/scottrif/
Apr 04 17:34:30 <RP__> sgw: Its really for others here
Apr 04 17:34:36 <RP__> sgw: thanks!
Apr 04 17:35:44 <sgw> RP__: yeah, it's just a small example for scott to work with, if you need a full blown 40G image (really 3.5G vmdk) I can post one in a hour or so, I don't have a clean one right now.
Apr 04 17:37:09 <RP__> sgw: its fine, it was just a question asked here for an exmaple
Apr 04 17:39:33 <RP__> Crofton: You saw sgw's link
Apr 04 17:40:08 <Crofton> ah
Apr 04 17:40:19 <Crofton> I think Matthew is looking for it
Apr 04 17:40:33 <Crofton> hang on
Apr 04 17:41:31 <Crofton> ok, link passed
Apr 04 17:42:17 <Crofton> we are wondering how long the download will take :)
Apr 04 17:42:29 <RP__> Crofton: I wondered that too
Apr 04 17:42:41 <Crofton> I am just trying to be helpful
Apr 04 17:42:59 <Crofton> davest, shut up
Apr 04 17:43:15 <Crofton> heh, nothing popped up on his screen
Apr 04 17:43:53 <RP__> Crofton|work: send a private message ;-)
Apr 04 17:44:34 <Crofton> rofl
Apr 04 17:44:39 <dvhart> oi
Apr 04 17:44:47 <kergoth> fray: grats on the tuning consistency :)
Apr 04 17:45:08 <sgw> Crofton: are you trying to cause trouble again!
Apr 04 17:45:14 <RP__> Crofton: shame it doesn't autoselect the new window ;-)
Apr 04 17:45:23 <kergoth> fray: now just need to sit down one of these days and improve them a bit more. powerpc probably shouldn't use the TUNE_PKGARCH_tune approach, heh
Apr 04 17:45:58 <dvhart> yes, fray++
Apr 04 17:46:09 <fray> ya.. I also don't like how ARM does itself stuff..
Apr 04 17:46:23 <fray> right now I'm thinking a combination of ARM and MIPS is the right way to do everything
Apr 04 17:46:45 * kergoth nods
Apr 04 17:47:39 <fray> "arm" general naming is good.. "MIPS" variant handling is a better approach.. combine the two and my issues w/ ARM are resolved -- and PowerPC can likely benefit as well
Apr 04 17:47:53 <fray> (still not sure about ia though -- it may simple stay as it is.. so many less tunings)
Apr 04 17:51:06 <RP__> I'd hope we can keep ia simple, no need to complicate it unecessarily
Apr 04 17:51:20 <fray> yup
Apr 04 17:51:32 <Crofton> sgw, when am I not causing trouble :)
Apr 04 17:51:58 <fray> the only (package feed) inconsistenty on PPC right now is the base is "powerpc" and "powerpc64", but all of the tunings are "ppc<foo>" or "ppc64<foo>"
Apr 04 17:52:15 <fray> easy to sync, but I wasn't going to start renaming stuff this close to the release
Apr 04 18:04:53 * davest1 is showing the IRC channel on the screen in the room
Apr 04 18:05:09 <davest1> ... but were on break now until 11:30pt
Apr 04 18:05:25 <dvhart> hah, bold move
Apr 04 18:27:58 <davest1> break is starting to break down
Apr 04 18:56:55 <msm> is there a preferred method of changing startup programs for a rfs?
Apr 04 18:57:08 <msm> aka how does one configure services?
Apr 04 18:57:28 <Crofton> msm, did the vm download ok?
Apr 04 18:58:14 <msm> yea but i could not get it too boot in virtualbox (easily)
Apr 04 18:58:21 <Crofton> bummer
Apr 04 18:58:21 <msm> i had ubuntu running already so i've since moved on
Apr 04 18:58:29 <Crofton> awesome conference wifi :)
Apr 04 18:59:20 <msm> also is there a preferred method for setting static information for network interfaces?
Apr 04 18:59:58 <Crofton> /etc/network/interfaces
Apr 04 19:00:19 <dvhart> msm, bbappend the network tools and add an interfaces file to files/$MACHINE/interfaces
Apr 04 19:01:34 <msm> dvhart: k thanks - is this documented anywhere currently?
Apr 04 19:01:56 <msm> look at the guides briefly and the wikis
Apr 04 19:02:03 <dvhart> msm, https://bugzilla.yoctoproject.org/show_bug.cgi?id=1962
Apr 04 19:02:12 <dvhart> msm, to be documented imminently :-)
Apr 04 19:02:26 <dvhart> that's why I knew the answer :)
Apr 04 19:03:16 <dvhart> RP__, also suggested we look for a way to do this without bbappends, but for now, that is the best practice
Apr 04 19:05:38 <dvhart> eek, shadow-native fails to configure for me: | configure.in:496: error: possibly undefined macro: AM_GNU_GETTEXT_VERSION
Apr 04 19:09:07 <RP__> dvhart: bitbake gettext-native gettext-minimal-native -c clean
Apr 04 19:09:19 <RP__> dvhart: known issue (there is an open bug)
Apr 04 19:09:29 <dvhart> many thanks
Apr 04 19:09:55 <msm> is it fair to say that adding recipes will also start a daemon / service by default?
Apr 04 19:10:01 <msm> is that the general way the recipes work?
Apr 04 19:10:05 <msm> i know there will be exceptions though
Apr 04 19:10:20 <dvhart> msm, hrm... really depends on the image type too
Apr 04 19:10:29 <dvhart> ie, whether or not they have inittools for example
Apr 04 19:10:33 <dvhart> tiny doesn't at the moment
Apr 04 19:10:48 <dvhart> but if the recipes provide an initscript and set the default runlevel, then yes
Apr 04 19:10:49 <kergoth> further, recipes don't even install the sysvinit compatible links without update-rc.d
Apr 04 19:11:29 <fray> what kergoth said.. only recipes that use the update-rc.d will setup compatible initscripts..
Apr 04 19:11:31 <dvhart> kergoth, that is standard with minimal and sato image correct?
Apr 04 19:11:44 <dvhart> ah, that's a per-recipe thing?
Apr 04 19:11:44 <fray> the long term intent is that one update-rc.d can switch between sysvinit, systemd, or any other future initscript system
Apr 04 19:11:55 <kergoth> dvhart: its a class for recipes to inherit and configure.
Apr 04 19:12:00 <dvhart> ok
Apr 04 19:12:07 <kergoth> whether those links the recipes install are actually *used* is where the image comes in
Apr 04 19:12:09 <dvhart> had forgotten about that I guess
Apr 04 19:12:19 <msm> kergoth: update-rc.d does something in the background?
Apr 04 19:12:38 <msm> im looking at the openssh recipe for example
Apr 04 19:12:39 <fray> it's run at package install time.. and setups the right links
Apr 04 19:12:43 <kergoth> msm: update-rc.d is a script for installing sysv style init links. the update-rc.d class sets up prerm/postinst scripts to install the links
Apr 04 19:12:45 <msm> it has update-alternative foo too
Apr 04 19:13:02 <fray> ya..  to see what it's doing (in the rpm case) rpm -qp <package> --scripts
Apr 04 19:13:19 <msm> ok I see the INITSCRIPTS conf flags now
Apr 04 19:15:47 <msm> does anyone know if update-rc.d is documented anywhere?
Apr 04 19:16:59 <khem> msm: manpages on any debian based system
Apr 04 19:18:57 <msm> khem: nothing oe-core specific?
Apr 04 19:19:24 <dvhart> msm, not that I'm aware of
Apr 04 19:19:33 <dvhart> a document on writing daemons would be useful
Apr 04 19:19:42 <dvhart> but gets complicated as new init systems are integrated
Apr 04 19:20:01 <ant__> hi again dvhart
Apr 04 19:20:06 <dvhart> hey ant__
Apr 04 19:21:11 <fray> hey what is the image that includes on-target toolchain for development?
Apr 04 19:21:23 <khem> tools-sdk
Apr 04 19:21:45 <fray> thanx..
Apr 04 19:22:02 <fray> I need to run some tests that require a target compiler.. :P
Apr 04 19:22:50 <khem> add that to EXTRA_IMAGE_FEATURES
Apr 04 19:23:06 <msm> dvhart: yes, its just one common thing uses will want to do first thing after making an image
Apr 04 19:23:20 <msm> (configuring services)
Apr 04 19:23:45 <dvhart> msm, agreed
Apr 04 19:23:55 <msm> if some recipe is installing a service by default, whats the proper way for a user to turn that service off by default (but still include the e package on the rfs)?
Apr 04 19:27:57 <msm> incandescant: can you make the hob window smaller than the default size?
Apr 04 19:28:04 <msm> incandescant: it won't fit on my screen!! ;)
Apr 04 19:28:15 <incandescant> msm: can I or will I?
Apr 04 19:28:41 <msm> hah i meant that more as feedback
Apr 04 19:28:51 <msm> or "can one"
Apr 04 19:29:41 <incandescant> it's possible, most of the GUI is fixed layout atm which is frustrating - we need to fix that and then it should be possible to make it relayout so that people can make it smaller
Apr 04 19:31:20 <incandescant> though it appears you can't at the moment, it has a fixed minimum size
Apr 04 19:54:01 <rburton> hey
Apr 04 19:54:06 <rburton> dvhart: patch works!
Apr 04 19:54:13 <rburton> but now i'm getting a rootfs generation failure
Apr 04 19:54:27 <rburton> genext2fs: command not found
Apr 04 19:54:27 <dvhart> rburton, nice, and not so nice
Apr 04 19:54:42 <dvhart> rburton, interesting, that should be unrelated
Apr 04 19:54:43 <rburton> is that something i need to install, or yocto doing something wrong?
Apr 04 19:54:49 <rburton> oh yes, probably is
Apr 04 19:55:06 <dvhart> that's odd, we build genext2fs afaik
Apr 04 19:55:14 <rburton> ok i'll check that actually happened
Apr 04 19:55:17 <rburton> this is a minimal image
Apr 04 19:55:34 <rburton> i just wanted to get something to build without having to wait for all of x and co
Apr 04 19:57:40 <rburton> well, bitbake genext2fs-native certainly did stuff
Apr 04 20:00:22 <rburton> yay
Apr 04 20:00:29 <dvhart> hrm
Apr 04 20:00:36 <dvhart> so is there an DEPEND missing?
Apr 04 20:00:38 <rburton> looks like core-image-minimal didn't build genext2fs-native
Apr 04 20:00:48 <dvhart> that's.... very strange
Apr 04 20:00:50 <rburton> i've also got it making a live image
Apr 04 20:00:53 <rburton> which may complicate matters
Apr 04 20:01:00 <dvhart> no, that's what I build every day
Apr 04 20:01:20 <dvhart> hrm
Apr 04 20:01:34 <dvhart> you're building for atom-pc ?
Apr 04 20:01:36 <rburton> yes
Apr 04 20:01:48 <rburton> i could wipe my tmp and see if i can replicate overnight if you'd like
Apr 04 20:01:50 <dvhart> edison atom-pc core-image-minimal ?
Apr 04 20:01:54 <rburton> yes
Apr 04 20:01:59 * dvhart scratches head
Apr 04 20:02:05 <dvhart> we must have built that 100 times
Apr 04 20:02:31 <rburton> maybe it picked it up from the host sometimes?
Apr 04 20:02:43 <rburton> or maybe i just broke something :)
Apr 04 20:02:48 <rburton> (ask josh, i do that)
Apr 04 20:02:55 <dvhart> heh
Apr 04 20:03:32 <dvhart> and you don't have genext2fs on your host I take it?
Apr 04 20:03:45 <dvhart> please try a clean overnight build
Apr 04 20:03:51 <rburton> nope
Apr 04 20:03:57 <dvhart> I'll submit the syslinux patches for inclusion into edison and master for 1.2
Apr 04 20:08:54 <rburton> ok i'll kick off the build now
Apr 04 20:24:02 <ant__> dvhart: zeddii: I could find the diff between the linux-yocto and the standard linux-inc (with custom defconfig)
Apr 04 20:24:08 <ant__> http://paste.debian.net/162098/
Apr 04 20:24:21 <ant__> so it was working :)
Apr 04 20:25:47 <dvhart> what was working?
Apr 04 20:26:00 <ant__> the mechanism to import a defconfig
Apr 04 20:26:55 <dvhart> sorry, I'm not following you
Apr 04 20:28:12 <ant__> I mean I could quickly 'yoctize' a kernel previously built with oe-core and having a static defconfig
Apr 04 20:28:20 <ant__> and some patches
Apr 04 20:28:52 <ant__> and I did boot that kernel
Apr 04 20:29:15 <dvhart> but this breaks with a linux-yocto-tiny bbappend?
Apr 04 20:29:28 <ant__> today, the same procedure leads to a kernel for arm/versatile (the first in the list)
Apr 04 20:29:47 <ant__> not for my pxa25x/xscale
Apr 04 20:30:08 <dvhart> today?
Apr 04 20:30:16 <dvhart> so the diff you posted was from some time back?
Apr 04 20:30:18 <ant__> today = 3.2.x
Apr 04 20:30:25 <ant__> yes
Apr 04 20:30:46 <ant__> it was yocto 3.0.12
Apr 04 20:31:12 <dvhart> you really need to be more clear about what your diffing
Apr 04 20:31:19 <dvhart> and use -Nurp
Apr 04 20:31:31 <ant__> at the time yocto-tiny was 3.0.12
Apr 04 20:32:36 <dvhart> ugh, disk full, services dying - me goes to clean up laptop
Apr 04 20:32:37 <dvhart> sigh
Apr 04 20:33:04 <zeddii> and they parsed. they have trouble with that at times.
Apr 04 20:33:10 <zeddii> ok
Apr 04 20:33:32 <ant__> ok, here the two old configs
Apr 04 20:33:37 <ant__> http://paste.debian.net/162103/  104
Apr 04 20:34:53 <dvhart> ant__, please be specific about what you mean when you say "the two old configs"
Apr 04 20:34:56 <dvhart> from what?
Apr 04 20:35:13 <dvhart> and just post the diff "diff -Nurp conf-a conf-b"
Apr 04 20:35:45 <ant__> at the time we were on 3.1 but linux-yocto-tiny was 3.0.12
Apr 04 20:36:23 <ant__> imho this is not the point
Apr 04 20:36:46 <ant__> the fact is CONFIG_MACH_POODLE=y  was respected
Apr 04 20:38:02 <ant__> rediffed: http://paste.debian.net/162105/
Apr 04 20:38:46 <zeddii> I have to head to pickup some small beasts. if there's a bug to be had, drop me an email.
Apr 04 20:40:14 <dvhart> I see
Apr 04 21:01:13 <fray> wow
Apr 04 21:10:13 <dvhart> fray, wow?
Apr 04 21:10:33 <fray> sorry, wrong channel.. old friend just had a 2nd kid.. ;)
Apr 04 21:10:38 <fray> (thus wow)
Apr 04 21:10:39 <dvhart> "wow"
Apr 04 21:10:41 <dvhart> ;-)
Apr 04 22:32:55 <sgw> msm: ping regarding bug 1535
Apr 04 22:34:02 <msm> that's really old
Apr 04 22:34:08 <msm> and i've not seen this in quite a while
Apr 04 22:34:23 <sgw> Do you think we can close it then?
Apr 04 22:34:59 <msm> i thought it was addressed though?
Apr 04 22:35:24 <msm> its fine to close it by me
Apr 04 22:35:50 <sgw> msm: I like  your thought process!
Apr 04 22:36:21 <msm> lol
Apr 04 22:36:37 <msm> ive been disconnected from master for a while though
Apr 04 22:36:50 <sgw> msm right.
**** ENDING LOGGING AT Thu Apr 05 02:59:58 2012

**** BEGIN LOGGING AT Thu Apr 05 02:59:58 2012
Apr 05 08:02:57 <mckoan> good morning
Apr 05 11:58:58 <RP__> morning all
Apr 05 12:47:05 <sophie_> using n450 trying to change to a 54bit build but failing when making rootfs
Apr 05 12:50:35 <bluelightning> sophie_: you may get a more definitive answer when dvhart and/or tomz come online later, but it seems to me that you might need to create an n450-64 machine configuration
Apr 05 12:51:10 <sophie_> thats what im starting to think too.
Apr 05 12:51:11 <bluelightning> sophie_: in theory should be as easy as copying conf/machine/n450.conf and then making it require the 64-bit base include instead of the 32-bit one
Apr 05 12:52:22 <bluelightning> hmm, actually that's not it...
Apr 05 12:53:40 <bluelightning> sophie_: actually it might be as simple as setting DEFAULTTUNE = "x86-64"
Apr 05 12:54:15 <sophie_> Im going to try it and see if it changes the problem building the rootfs
Apr 05 14:02:52 <sophie_> bluelightning: tried to change the machine.conf file to use x86_64 still building with i686
Apr 05 15:39:00 <xumbi> has anyone built meta-toolchain-qte for qt 4.8.0?
Apr 05 20:56:44 <ant__> zeddii: dvhart: I've seen #2250 :/ let me know if I can be of help wrt grep exhausting memory
Apr 05 22:54:50 <ant__> zeddii: grep: Memory exhausted happens during    wrap_meta_series $meta_dir/meta-series (kgit-meta #1159)
Apr 05 22:58:13 <ant__> seems in ptotal
**** ENDING LOGGING AT Fri Apr 06 03:00:00 2012

**** BEGIN LOGGING AT Fri Apr 06 03:00:00 2012
Apr 06 09:22:01 <ag> Hello all!
Apr 06 09:22:32 <ag> Can anybody help me with a hint in running a package step only for one and just for one package?
Apr 06 09:22:58 <ag> I'm running some debug stuff on package.bbclass. And i want to test those on js.
Apr 06 09:23:14 <ag> everytime i bitbake js -c package -f
Apr 06 09:23:24 <ag> I get a lot of do packages from other packages
Apr 06 09:26:59 <ag> obviously "lot of packages" are libtool, gcc etc.
Apr 06 13:29:56 <scknlnhq> greetings. I downloaded Poky a few days ago (latest git) and there is something diffrent, in a negative sense. I tried to makemenu into a kernel (bitbake somekernel.bb -c menuconfig) but it only says "do_menuconfig" not found. Is this a bug or will this " feature"?
Apr 06 13:30:07 <scknlnhq> be
Apr 06 13:30:23 <scknlnhq> a
Apr 06 13:36:48 <scknlnhq> noone?
Apr 06 13:38:36 <bluelightning> sigh
Apr 06 13:51:22 <autif> patience of a developer is now down to 7 minutes
Apr 06 13:52:45 <Bagder> =)
Apr 06 14:29:25 <jim_> Hello
Apr 06 14:31:59 <jim_> How do i talk to someone?
Apr 06 14:32:40 <denisATeukrea> jim_, hi
Apr 06 14:32:49 <denisATeukrea> you don't, you have to talk in the main channel
Apr 06 18:47:36 <sgw>  fray: you around?  I am looking at 2074 and want to make sure I have the correct setup
Apr 06 21:13:28 <kergoth> hmm, wonder why gdk-pixbuf isn't using PACKAGECONFIG to toggle the build of gdk-pixbuf-xlib based on x11
Apr 06 21:14:02 * kergoth yawns and stretches
Apr 06 21:25:40 <khem> kergoth: probably it should yes
Apr 06 21:26:43 <ant__> zeddii: ping
Apr 06 23:05:16 <davest> Does anybody have the photo that was taken at the BSP Summit on Monday?
Apr 06 23:05:28 <davest> Was thinking maybe denix took it
Apr 06 23:06:02 <davest> Or maybe it was Crofton, really starting to bug me
Apr 06 23:06:19 <Crofton> denix, probably
Apr 06 23:06:25 <Crofton> which photo?
Apr 06 23:07:13 <davest> It was of the folks sitting in the room
Apr 06 23:07:27 <davest> sort of a "expense report proof"
Apr 06 23:07:58 * Crofton looks on his camera
Apr 06 23:08:14 <Crofton> nope
Apr 06 23:08:22 <Crofton> denix, is always taking photos
Apr 06 23:08:41 <Jefro> I'd love to see it as well
Apr 06 23:17:58 <davest> Photo: found. http://tbone.s3.amazonaws.com/conf.png
Apr 06 23:20:25 <Crofton> excellent, I am behind terence
Apr 06 23:26:01 <incandescant> davest: you may want to crop the image in that blog post
Apr 06 23:26:17 <incandescant> scale even, not crop
Apr 06 23:26:30 <davest> incandescant: tried many times, but stupid Drupil not working right
Apr 06 23:26:40 <davest> (Or at least, not for me)
Apr 06 23:26:43 <incandescant> davest: bummer :-/
Apr 06 23:27:16 <incandescant> davest: you could scale locally and upload a smaller version?
Apr 06 23:27:21 <incandescant> or mayhaps halstead can help?
Apr 06 23:27:28 <incandescant> he's all kinds of drupal savvy
Apr 06 23:28:14 <davest> Funny that Wordpress is working fine though: http://software.intel.com/en-us/blogs/2012/04/06/the-yocto-yumminess-of-our-bsps/
Apr 06 23:28:27 <davest> That was just a copy-paste of the HTML source
Apr 06 23:29:18 <incandescant> pretty sure Drupal uses a filtered subset of HTML
Apr 06 23:29:25 <incandescant> by default, at least
Apr 06 23:29:32 <halstead> davest, I can help.
Apr 06 23:29:32 <incandescant> Jefro, halstead ?
Apr 06 23:29:40 <incandescant> thanks Mr halstead
Apr 06 23:29:44 <Jefro> incandescant yo
Apr 06 23:29:58 <Jefro> catching up
Apr 06 23:30:07 <incandescant> Jefro: sorry, was just trying to summon drupal experience. halstead arrived sooner :-)
Apr 06 23:30:22 <Jefro> incandescant much, much better option than me :)
Apr 06 23:31:04 <incandescant> Jefro: you couldn't possibly be a worse option than me
Apr 06 23:31:20 <davest> halstead: can you please scale the photo in http://www.yoctoproject.org/blogs/davest/2012/yocto-yumminess-our-bsps properly?  Thanks...
Apr 06 23:31:59 <halstead> davest, Just found it. Sure.
Apr 06 23:32:23 <davest> halstead: Thanks much!
Apr 06 23:32:38 <Jefro> davest awesome post
Apr 06 23:33:12 <davest> Jefro: thanks, but mearly adequate, not awesome
Apr 06 23:33:14 <halstead> I'm going to copy the image from S3 onto our hardware.
Apr 06 23:33:27 <khem> ah denix shadowed me :)
Apr 06 23:44:11 <halstead> All done. I'll upload a screencast of how I did it.
Apr 07 00:30:40 <halstead> Jefro, Here is a quick (1:19) howto to watch http://www.youtube.com/watch?v=l_pPpS1TqhM
Apr 07 00:31:08 <halstead> (1 minutes 19 seconds)
Apr 07 00:31:20 <Jefro> cool, thanks - looking
**** ENDING LOGGING AT Sat Apr 07 02:59:58 2012

**** BEGIN LOGGING AT Sat Apr 07 02:59:59 2012
Apr 07 17:50:20 <flihp> noob question : I'm having trouble getting my recipe to build flex as a dependency (I link to libfl: -lfl)
Apr 07 17:51:08 <flihp> I've got flex in my DEPENDS
Apr 07 17:51:38 <flihp> bitbake builds the native libs for flex, but not for the target arch
Apr 07 17:51:50 <flihp> my package isn't a native one though
Apr 07 17:58:02 <flihp> also worth noting is that if I build flex manually (bitbake flex) my recipe builds fine ... not sure what that means
**** ENDING LOGGING AT Sun Apr 08 03:00:01 2012

**** BEGIN LOGGING AT Sun Apr 08 03:00:01 2012
**** ENDING LOGGING AT Mon Apr 09 02:59:58 2012

**** BEGIN LOGGING AT Mon Apr 09 02:59:58 2012
Apr 09 15:30:43 <seebs> Huh, this is odd.  pseudo gets built with an RPATH.  This might have to do with bitbake.conf setting BUILD_LDFLAGS to unconditionally specify an RPATH, but that doesn't explain why other native packages don't get it.
Apr 09 15:31:09 <fray> use of chrpath or ignoring of the LDFLAGS is my guess
Apr 09 15:31:12 <seebs> I'm sort of suspecting this to be related in some way to the special way in which pseudo gets built the first time, but I can't see how.
Apr 09 15:31:52 <seebs> I can hardly imagine that EVERY other package did this the same way, but pseudo didn't.  On the other hand, the path that gets pseudo built is unique.  So that's my first suspicion.
Apr 09 15:32:14 <fray> libtool has code to remote rpaths that match the define --libdir
Apr 09 15:32:18 <fray> pseudo isn't use libtool
Apr 09 15:33:12 <seebs> But does *every* other package use it?
Apr 09 15:33:35 <fray> there are not a lot of native packages being built.. I would suspect the majority of them do use configure and libtool
Apr 09 15:34:30 <fray> but that line does look poorly conceived though..
Apr 09 15:34:36 <seebs> hmm
Apr 09 15:34:44 <fray> I would have expected something with $ORIGIN or no rpath line..
Apr 09 15:34:50 <seebs> Well, there is an RPATH thing in the pseudo makefile, although it looks like an attempt to unset it.
Apr 09 15:35:03 <fray> maybe there is code using rpatht hat changes from the fixed to an $ORIGIN based path that isn't running?
Apr 09 15:35:12 <fray> (I know chrpath is required in the system, but I don't know where it's run)
Apr 09 15:35:40 <seebs> Oh, interesting.  RP fixed a thing in September that tried to fix this..
Apr 09 15:36:07 <fray> "relocatable.bbclass"
Apr 09 15:36:11 <seebs> And the bitbake rpath change is about three months newer.
Apr 09 15:36:55 <fray> ya.. relocatable.bblcass does exactly that.. it tkes a fixed path and replaces it with $ORIGIN
Apr 09 15:36:56 <seebs> So in January, Enrico Scholz changed the -Wl,-rpath values.  Hmm.
Apr 09 15:37:07 <seebs> Oh, this is interesting.  There's two of them.
Apr 09 15:37:12 <fray> I assume RP is off tomorrow..
Apr 09 15:37:19 <fray> 'er.. off UNTIL tomorrow
Apr 09 15:37:20 <seebs> I betcha we have something somewhere that, if you set RPATH=, filters out a single -Wl,-rpath
Apr 09 15:37:31 <fray> I suggest a post to oe-core list asking is the best answer until then
Apr 09 15:37:34 <seebs> And doesn't filter them both out.  Because that's new.
Apr 09 15:37:39 <fray> hm
Apr 09 15:40:57 <seebs> Basically, what I note is:  I have two -Wl,-rpath args in bitbake.conf, and only one rpath in pseudo.  So something's eating one of them...
Apr 09 15:41:18 <fray> I'd suggest you grep around in meta/classes
Apr 09 15:41:24 <fray> see if you can figure out where it's getitng munged
Apr 09 15:54:23 <khem> seebs: what are these rpaths pointing to and which one is that pseudo is missin
Apr 09 15:54:51 <seebs> They're pointing into the build tree, and ideally it shouldn't have any.  And it presumably didn't, as of September when that fix went in.
Apr 09 15:55:15 <seebs> So it looks like when an additional rpath got added in bitbake.conf, this resulted in the pseudo binaries ending up with that extra.
Apr 09 15:55:16 <fray> ya, pseudo needs absolutely no rpaths and doesn't do any on it's own..
Apr 09 15:55:32 <fray> but bitbake is passing in rpaths on the ldflags, which get used and embedded.. triggering a QA warning
Apr 09 15:55:36 <fray> so the problem is why is bitbake doing this?
Apr 09 15:59:12 <khem> so this is pseudo-native right ?
Apr 09 16:01:44 <seebs> Yeah.
Apr 09 16:02:09 <seebs> Well, bitbake's had that all along, then it got updated to add an extra one.  It may be that pseudo's attempt to remove rpaths is simply not firm enough.
Apr 09 16:03:16 <khem> rpath should point into native sysroot
Apr 09 16:03:24 <khem> which should be fine I guess
Apr 09 16:03:34 <khem> time to hitch a ride
Apr 09 16:03:36 <khem> ttyl
Apr 09 16:28:31 <seebs> This could be one of those obvious newbie questions, but...  If I've built pseudo-native, is there a log file somewhere containing the logs for the pseudo-native build, neatly separated out so I can look at them?
Apr 09 16:28:35 <seebs> Or even not separated out?
Apr 09 16:29:24 <seebs> Ahh, nevermind.
Apr 09 16:29:26 <seebs> Found it!
Apr 09 16:47:47 <seebs> D'oh.  That was all a red herring.  Turns out pseudo helpfully sets a default rpath if you specify with-sqlite.
Apr 09 16:49:16 <sgw> seebs: nice!
Apr 09 16:49:23 <seebs> I have ensmartened this to not do that if you specify --without-rpath or --enable-static-sqlite.
Apr 09 16:49:37 <seebs> I cannot imagine how this ever didn't trigger this bug, pseudo's had that helpful behavior since 2010.
Apr 09 16:52:35 <khem> seebs: btw. you have to ensmarten pseudo a bit more where it just things x86
Apr 09 16:52:46 <khem> use of -m32 and -m64 options
Apr 09 16:53:07 <khem> unconditionally means it cant be compiled for non x86 arches
Apr 09 16:53:11 <seebs> Yeah.  On my list, I just haven't figured out what to do to check for that.
Apr 09 16:53:23 <seebs> It's been verified to apparently work on ARM if that line is just removed.
Apr 09 16:53:26 <khem> seebs: you need autoconf :)
Apr 09 16:53:50 <seebs> Definitely.  I mean, what if someone tried to build pseudo on Ultrix, without even knowing whether they had an f77 compiler?  :P
Apr 09 16:53:51 <fray> ha-ha
Apr 09 16:53:54 <khem> or you can add an option called ARCH or some such
Apr 09 16:54:25 <khem> seebs: make
Apr 09 16:54:28 <khem> errrr
Apr 09 16:54:49 <khem> make ARCH=mips all
Apr 09 16:55:08 <fray> part of the issue is we're fighting the host compiler options
Apr 09 16:55:32 <fray> we need to be able to do stuff that normal bitbake can't.. i.e. target multiple ABIs on compilers we didn't build.. :P
Apr 09 16:55:34 <seebs> Huh.  Turns out the existing --without-rpath would probably do what we want.  I still want to fix the logic.
Apr 09 16:55:53 <khem> yes once you know what your host is with ARCH option you can fix it
Apr 09 16:56:10 <fray> I'm tempted though to suggest that we simply patch and remove -m* from pseudo for OE.. and then pass those values ourselves in the recipes
Apr 09 16:56:18 <khem> ARCH indicated host btw. not target
Apr 09 16:56:19 <fray> (not sure if thats a good generic change though, perhaps it is?)
Apr 09 16:56:42 <fray> well on IA we have potentially three settings, on mips three, on arm (currently) one..
Apr 09 16:56:45 <fray> ppc - two
Apr 09 16:56:55 <khem> yeah thats possible too but then what if pseudo is used outside OE
Apr 09 16:57:01 <fray> the problem is (besides -m) we also need a mapping of the right set of LD_LIBRARY_PATH settings
Apr 09 16:57:23 <khem> thats multilib case ?
Apr 09 16:57:48 <fray> perhaps the right answer is simply make this stuff more explicit in the configuration, don't assume anything and make the "user" (recipe) provide the full config?
Apr 09 16:58:02 <fray> the recipe right now is determining if it thinks we need a 32-bit version as well as a 64-bit
Apr 09 16:58:16 <khem> you still need to provides open knobs that are then handled by pseudo make system
Apr 09 16:58:18 <fray> ya, multilib is a significant case for pseudo on IA
Apr 09 16:58:22 <khem> so choose your battles
Apr 09 16:58:51 <fray> force the user to configure the LD_LIBRARY_PATH components available on a system, and define the correct -m* ABI setting for a particular build..
Apr 09 16:58:56 <fray> likely very doable and fairly simple
Apr 09 16:59:22 <fray> (this is going to likely matter on that new debian multiarch thing as well.. since we have to setup the library path to their whacky lib names)
Apr 09 16:59:35 <fray> [if they deviate from LSB names that is]
Apr 09 16:59:54 <khem> multilib is a loaded gun
Apr 09 17:00:08 <khem> debian seems to be pointing it to their foot
Apr 09 17:03:23 <seebs> I am currently looking at --arch=arm, --arch=x86, with the assumed-default being x86.
Apr 09 17:03:53 <seebs> And then instead of -m$(BITS), I use compile_${arch}_${bits}, which are set only for x86_32 and x86_64 right now.
Apr 09 17:05:09 <seebs> So basically if you don't change anything, it'll end up doing what it does now.  But if you add a --arch=arm, it'll work on arm, and if you add --arch=x86, it'll keep working on x86.
Apr 09 17:05:52 <khem> seebs: as long as interface is usable and does what it says it does we are fine
Apr 09 17:06:19 <fray> I'm just worried pseudo is trying to hard to get it right for a "dummy" user.. instread just make sure the user isn't a dummy.. and move the responsibility elsewhere.. (in the case of OE, into the recipe)
Apr 09 17:06:49 <fray> back in a bit.. need food
Apr 09 17:07:10 <seebs> Hmm.
Apr 09 17:07:40 <khem> fray: I differ a bit
Apr 09 17:08:08 <khem> I consider package should try to help build systems by being cross compilable
Apr 09 17:08:33 <seebs> Well, we definitely want to be POSSIBLE to configure for arm.
Apr 09 17:08:44 <seebs> But I also want to DTRT where possible with --bits=.
Apr 09 17:09:02 <khem> yes so you have arch and multilib
Apr 09 17:09:03 <seebs> Right now, if arch isn't one of '', x86, or arm, I emit a warning that it is untested.
Apr 09 17:09:13 <khem> thats all fine
Apr 09 17:10:09 <seebs> And if you specify x86 and 32 or 64 bits, we emit -m$foo, and if you don't specify bits, we don't emit a -m at all.
Apr 09 17:10:23 <seebs> Because we assume the compiler matches your intent anyway.
Apr 09 17:10:43 <seebs> So basically, if you change nothing, it keeps doing what it's done, but it has the hooks for being educated about target compile options.
Apr 09 17:10:53 <khem> seebs: yep thats better
Apr 09 17:11:07 <khem> assume default multilib
Apr 09 17:11:24 <khem> and if someone asks different then chose it
Apr 09 17:11:31 <seebs> So I'm assuming the person who got bitten on arm was still using --bits=32.
Apr 09 17:11:48 <khem> seebs: its how its specified in OE
Apr 09 17:11:53 <khem> I got bitten too
Apr 09 17:12:03 <seebs> k
Apr 09 17:12:04 <khem> in OE --bits is always set
Apr 09 17:12:23 <seebs> Yeah, I think it is in our build system too.  So adding the --arch option should help.  Although.
Apr 09 17:12:38 <seebs> Is OE such that --arch would end up "x86" if specified?
Apr 09 17:12:40 <khem> yes arch will help
Apr 09 17:13:07 <khem> you have to say --arch=${TARGET_ARCH}
Apr 09 17:13:16 <khem> then peices will fall into places
Apr 09 17:13:23 <khem> in OE that is
Apr 09 17:14:07 <khem> but I think as we move into future 64bit will be common across all arches we support
Apr 09 17:14:19 <khem> arm is only one which does not have it as of now
Apr 09 17:14:41 <khem> and they are getting to it soon (with v8)
Apr 09 17:18:53 <fray> seebs, what about x86 - x32 and the LD_LIBRARY_PATH?
Apr 09 17:26:24 <seebs> I don't know about x32 yet.
Apr 09 17:28:04 <fray> libx32 is the location, -mx32 is the switch
Apr 09 17:29:11 <fray> (BTW not against preemptively adding libx32 to the pseudo ld-library-path settings
Apr 09 17:32:19 <seebs> hmm
Apr 09 17:32:33 <seebs> I would like to hold off until we have a test case.  :)
Apr 09 17:39:28 <fray> there are folks talking about x32 already -- and we do have x32 images (inside yocto) where pseudo doesn't work today..
Apr 09 17:39:54 <fray> (i.e. self-hosting doesn't work)
Apr 09 17:41:35 <seebs> I can totally test stuff and fix it if someone gives me a test case I can play with.  :)
Apr 09 20:36:51 <cps> hi
Apr 09 20:37:58 <cps> I am getting /usr/include/linux/ext2_fs.h:178:41: error: unknown type name 'umode_t' while builing romley BSP
Apr 09 20:38:48 <cps> FC16 kernel 3.3.0-4.fc16.x86_64
Apr 09 20:40:00 <cps> poky-1.2_M2.final
Apr 09 20:40:46 <fray> unless you are building on the target, it appears that teh wrong header is being used..
Apr 09 20:41:04 <fray> it should -never- use host system headers, unless you are building a "native" app.. even then it may be sketchy..
Apr 09 20:41:09 <fray> what was being attempted to be built?
Apr 09 20:41:19 <cps> and meta-intel-1.2_M2.final BSP
Apr 09 20:41:33 <cps> romley BSP
Apr 09 20:42:05 <fray> no, what was bitbake building when the error occured?
Apr 09 20:42:59 <cps> | ../libinstaller/fat.c:45:9: warning: variable 'veryold' set but not used [-Wunused-but-set-variable]
Apr 09 20:43:13 <cps> sorry, wrong one
Apr 09 20:43:47 <cps> | In file included from ../libinstaller/linuxioctl.h:22:0,
Apr 09 20:44:05 <incandescant> there's a pending patch on the mailing list for this: http://lists.linuxtogo.org/pipermail/openembedded-core/2012-April/020594.html
Apr 09 20:44:43 <cps> yes, thats my question. i downloaded the patch poky-contrib-182c2cbd67d4e79e8d1c6a50a1dac4790315553a.tar.bz2
Apr 09 20:45:13 <cps> is this to sub the poky-1.2M2?
Apr 09 20:46:05 <cps> ERROR: No recipes available for:because then i got
Apr 09 20:47:51 <dvhart> cps, sorry, I wasn't logged in and don't have a log of the chat re syslinux
Apr 09 20:48:00 <dvhart> care to pm me the details to catch me up to speed?
Apr 09 20:48:03 <dvhart> I may be able to help
Apr 09 20:48:10 <cps> ok. how do i get the 020594?
Apr 09 20:48:50 <cps> i was in http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=dvhart/syslinux&id=182c2cbd67d4e79e8d1c6a50a1dac4790315553a
Apr 09 20:49:45 <dvhart> cps, what do you mean by 020594?
Apr 09 20:49:47 <cps> i don't know how to use git, i get the zip or bz2
Apr 09 20:50:04 <cps> http://lists.linuxtogo.org/pipermail/openembedded-core/2012-April/020594.html
Apr 09 20:50:24 <cps> is this one to go with poky1.2M2 final tree?
Apr 09 20:50:52 <dvhart> This patch will be applied (soon) to oe-core and poky for the Yocto 1.2 release
Apr 09 20:51:05 <dvhart> you can apply this patch directly to your 1.2 pre-release tree
Apr 09 20:51:13 <cps> now i am trying to build romley bsp
Apr 09 20:51:24 <dvhart> you can either save the email off and apply it as a patch or you can use git to generate the patch
Apr 09 20:51:49 <dvhart> or download the patch from the git web:
Apr 09 20:51:51 <dvhart> http://git.yoctoproject.org/cgit.cgi/poky-contrib/patch/?id=182c2cbd67d4e79e8d1c6a50a1dac4790315553a
Apr 09 20:51:59 <dvhart> then use "patch" to apply it
Apr 09 20:52:40 <cps> i downloaded the poky-contrib-182c2cbd67d4e79e8d1c6a50a1dac4790315553a.tar.bz2
Apr 09 20:52:57 <cps> that looks like the whole tree
Apr 09 20:53:34 <cps> how do i apply this to the poky1.2M2.final tree?
Apr 09 20:53:56 <dvhart> cps, I tried to describe the process above
Apr 09 20:54:02 <dvhart> is there some part of that which is not clear?
Apr 09 20:55:29 <cps> oh, sorry, did not click on the patch link. i got it now. thanks
Apr 09 20:56:34 <dvhart> you bet
Apr 09 21:14:08 <sgw> fray: I am still not able to reproduce the 2074 issue, you around to chat?
Apr 09 21:21:25 <fray> sgw -- ya I'm here..
Apr 09 21:22:38 <sgw> fray: I am still getting a good psplash build when I try the 2074 issue, and yes, I followed the reproduction listed in but 2082 (I did not know about that until this morning, but its the same thing I have been doing).
Apr 09 21:23:34 <fray> as user #2, if you do "ls <path to usr1>/tmp/sysroot/..../usr/include" what error do you get?
Apr 09 21:23:47 <fray> if your kernel or glibc isn't sending the same error.. then that would be why
Apr 09 21:24:17 <sgw> ls: cannot access /home/builder1/poky/build/tmp/sysroots/: Permission denied
Apr 09 21:24:32 <fray> ya, that is EPERM.. so it should be the same here
Apr 09 21:24:51 <fray> I'll setup another reproducer here.. but it's going to take much of the afternoon for me to do so..
Apr 09 21:25:00 <fray> (hmm and afternoon is almost over)
Apr 09 21:25:03 <sgw> Can you run a strace -s 8192 -f -o out of your bitbake
Apr 09 21:25:15 <fray> BTW have you followed the MIPS discussion on the oe-core list?
Apr 09 21:25:25 <fray> I'm looking for external opinions on the MIPS32 vs MIPS pacakge naming debate
Apr 09 21:25:29 <sgw> fray: just of the psplash build
Apr 09 21:25:53 <khem> fray: we should just use mips and mipsel for 32bit
Apr 09 21:26:06 <khem> fray: what adv do u see by appending 32
Apr 09 21:26:09 <fray> but mips32 - tune - may not run on mips
Apr 09 21:26:12 <sgw> fray: I am the wrong one to ask here, I have not been following since I have up to my ears in release stuff.
Apr 09 21:26:15 <khem> why ?
Apr 09 21:26:20 <fray> "mips" is mips one by default according to gcc..
Apr 09 21:26:30 <khem> mips n32 may not
Apr 09 21:26:34 <fray> "mips32" enabled 4Kc instructions and tunings..  along witht the optimizations..
Apr 09 21:26:39 <fray> mips n32 is mips64_n32
Apr 09 21:26:48 <khem> ok
Apr 09 21:27:07 <khem> and mips uses which mtune flags ?
Apr 09 21:27:16 <fray> right now we have two mips tunings that produce different binaries -- and before the "fix" didn't differentiate the pacakges
Apr 09 21:27:44 <fray> the configure - GNU canonical arch -is- "mips" or "mipsel"..  The OVERRIDE is "mips" or "mipsel"..  the -only- thing that has changed is the package arch..
Apr 09 21:27:52 <khem> i get that but I want to know whats our tuning for mips and mipsel
Apr 09 21:27:56 <fray> "mips" uses the default GCC arch/tune settings
Apr 09 21:28:03 <khem> ok
Apr 09 21:28:07 <fray> gcc by DEFAULT (I verified this) is r3000 & mips1
Apr 09 21:28:17 <fray> mips32 adds to the ccfalg  -march=mips32
Apr 09 21:28:32 <fray> this enabled the 4Kc instructions/tunings & MIPS32 & some branch prediction hinting
Apr 09 21:28:33 <khem> ok yes -march=mips32 will make it different
Apr 09 21:28:44 <khem> yes familiar with  that bit
Apr 09 21:28:58 <khem> r3000 & mips1 I need to check that
Apr 09 21:29:14 <fray> so my problem is -- if we name them both "mips" then we have a problem as they are different binaries and you can't differentiate in a package feed
Apr 09 21:29:32 <fray> so it should be "mips" (default gcc) & "mips32" (-march=mips32)
Apr 09 21:29:43 <khem> yes thats fine
Apr 09 21:29:51 <fray> khem i verified it about an hour ago.. see my last email to the oe-core list for how I verified it
Apr 09 21:29:56 <khem> but default being mips shouldnt tuning be mips too for that
Apr 09 21:30:03 <khem> why mips32 started appearing ?
Apr 09 21:30:34 <khem> IMO if I chose mips32 tuning then only I should get mips32 package arches
Apr 09 21:30:55 <fray> because whoever implemented and checked in "tune-mips32" never set the value properly.  they didn't understand the one setting..
Apr 09 21:31:06 <fray> I fixed it about a week ago, when I fixed all o fthe other other inconsistencies..
Apr 09 21:31:27 <fray> so people are using the "tune-mips32.inc" file, and are suddenly getting packages tagged with "mips32" in the -package name- only..
Apr 09 21:31:33 <fray> -everything else- is exactly the same as before
Apr 09 21:31:36 <khem> ok.
Apr 09 21:31:38 <fray> I verified this now multiple times
Apr 09 21:31:42 <khem> thats fine then
Apr 09 21:31:45 <fray> GNU canonical arch is "mips-oe-linux-gnu", etc..
Apr 09 21:31:50 <khem> we dont need to revert
Apr 09 21:32:04 <khem> instead users should adjust machine tunes
Apr 09 21:32:08 <fray> nothing that I found within OE uses the package arch, except for the feed and image generation.. image generation is working properly.. I verified that as well
Apr 09 21:32:16 <fray> I have no easy was to verify the feeds though
Apr 09 21:32:21 <khem> yes that canonical arch remains same but it can generate incompatible code
Apr 09 21:32:35 <khem> -mabi=n32 or -mabi=eabi e.g.
Apr 09 21:32:39 <fray> AFAIK gnu doesn't have "mips32" defined as a canonical arch
Apr 09 21:32:48 <khem> no
Apr 09 21:32:50 <fray> any time n32 is enabled, "_n32" is added to the package arch
Apr 09 21:33:02 <fray> is there an mabi=eabi on MIPS?
Apr 09 21:33:08 <khem> but it does use mips*-*-* sometimes for covering both mips and mips64
Apr 09 21:33:14 <khem> yes there is :)
Apr 09 21:33:20 <fray> each architecture has a different set of defined rules for naming schemes..
Apr 09 21:33:25 <khem> there are I think 6 abis on mips
Apr 09 21:33:26 <fray> these are in the various ARCH readme files..
Apr 09 21:33:33 <fray> on MIPS the defined -package- naming is:
Apr 09 21:33:38 <khem> o32,o64,n32,n64,eabi
Apr 09 21:33:53 <khem> and one more coming up which is like x32 abi
Apr 09 21:34:01 <khem> of x86
Apr 09 21:34:15 <fray> MIPS_VARIANT[_fpu][_n32]
Apr 09 21:34:25 <fray> MIPS_VARIANT is defined by each tune..
Apr 09 21:34:31 <khem> thankfully fpu is always same
Apr 09 21:34:39 <fray> the gnu canonical arch is defined as:
Apr 09 21:34:50 <fray> mips[64][el]
Apr 09 21:35:06 <fray> 64 is only defined in the mips64 instructions are enabled, and el if little endian is enabled
Apr 09 21:35:33 <fray> so we have:  mips-oe... mipsel-oe... mips64-oe... and mips64el-oe... defined for the configure target
Apr 09 21:35:42 <khem> right
Apr 09 21:35:58 <fray> if there are additional variants coming, we will need to define for those
Apr 09 21:36:21 <khem> fray: its in discussion
Apr 09 21:36:24 <seebs> Additional variants of MIPS?  Even in the subjunctive I find that terrifying.
Apr 09 21:36:36 <khem> fray fwiw we should only care for o32 n32 and n64
Apr 09 21:36:39 <khem> as of now
Apr 09 21:37:49 <seebs> In the interests of greater generality, we're now offering 10-byte words with an arbitrary selection of byte orders, resulting in 10! possible byte orders.  Obviously, we need multilibs for all possible byte ordering.  Also each processor will have a serial number, and issuing an instruction the opcode of which matches the serial number will cause the embedded C4 charge to detonate.
Apr 09 21:38:44 <khem> heh
Apr 09 21:40:15 <khem> fray: I wonder if mips1 is a really  we should care
Apr 09 21:40:22 <fray> khem, currently only o32, n32 and n64 are defined -- using the variant method above..
Apr 09 21:40:22 <khem> I would start with mips3
Apr 09 21:40:30 <khem> yes thats sufficient
Apr 09 21:40:50 <khem> mips3, mips4 mips32 mips64r2
Apr 09 21:40:55 <fray> thats fine -- I don't care either way..  But the tuning policy has been (since these new style tunes were enabled) that a default architecture tuning be defined..
Apr 09 21:41:02 <khem> are what realistically make sense
Apr 09 21:41:16 <fray> so I would suggest "mips", "mips3", "mips4", mips32, mips32r2, and mips64(r2?)
Apr 09 21:41:32 <fray> the mips and mips3 could be combined by changing the internal default of GCC to mips3
Apr 09 21:42:10 <khem> yeah if we can drop mips1 then we can drop o32
Apr 09 21:42:27 <khem> since thats one ISA that wont work with n32 or n64 for that matter
Apr 09 21:42:56 <khem> I think most basic machine we target is malta anyway
Apr 09 21:43:12 <khem> so dropping mips1 wont initiate a nuclear attack
Apr 09 21:44:35 <fray> mips32 won't work with n32 either..
Apr 09 21:45:00 <fray> you need a mips64 processor to do n32.. even if you only compile with mips32 tunings..
Apr 09 21:45:39 <khem> thats right
Apr 09 21:45:46 <fray> What I suggest to our customers is.. o32 for MIPS(32) systems.. (they don't have a choice)..  n32 for MIPS64 systems, with o32 available for compatibility and n64 for large memory systems
Apr 09 21:46:03 <fray> Cavium systems are configured that way, as are sibyte and some of the other bigger names..
Apr 09 21:46:25 <khem> thats a good fit
Apr 09 21:46:26 <fray> xlr (can't remember the name of the company) though insisted their customers wanted o32 and n64.. with no need for n32 binaries.. so they are an outlyer
Apr 09 21:46:41 <khem> RMI -> netlogic -> broadcom :)
Apr 09 21:46:56 <fray> ya.. thats it.. they didn't want n32
Apr 09 21:47:13 <fray> (whereas cavium said they didn't want o32.. but we enabled it anyway since it was virtually a no-op)
Apr 09 21:47:35 <khem> which is fine since most of xlr cpus go into networking gears dealing with large forwarding tables
Apr 09 21:48:05 <fray> ya.. n64 makes sense.. but why o32 for base system commands.. that seems stpid
Apr 09 21:48:33 <khem> we shoudl jusr use -march=from-abi for mipsen
Apr 09 21:48:58 <khem> o32 for legacy stuff I believe
Apr 09 21:49:00 <fray> (BTW our minimum mips system is a mips32 - 4kc.. we have a couple of custom one-offs for other mips.. but they're per customer and not generic)
Apr 09 21:55:25 <fray> khem, my suggestion then.. for -this- freeze.. leave the package arch as "mips" and "mips32"
Apr 09 21:55:59 <fray> after this freeze.. add definitions for mips3, mips4, ... etc.. to the base "mips" architecture file.. and define "mips, mips4, mips32, mips32r2, mips64(r2?)"
Apr 09 21:56:05 <fray> and associated tunings for each of them..
Apr 09 21:56:12 <fray> "mips" would be equal to "mips2"
Apr 09 21:56:14 <fray> 'er.. mips3
Apr 09 22:03:48 <fray> khem -- mind responding to the MIPS thread with something about mips vs mips32 and if we should keep it as-is, revert, or...  (for the current release)
Apr 09 22:04:08 <fray> I'm going to sync w/ RP in the morning... I think in the end he needs to decide based on the risks of the change..
Apr 09 22:04:17 <fray> but right now there are only two opinions..
Apr 09 22:05:05 <khem> yes will do
**** ENDING LOGGING AT Tue Apr 10 03:00:00 2012

**** BEGIN LOGGING AT Tue Apr 10 03:00:00 2012
Apr 10 07:48:29 <mckoan> good morning
Apr 10 07:55:01 <mranostay>  crap it is
Apr 10 07:58:08 <bluelightning> morning all
Apr 10 12:35:25 <jawilson> is there a GNU Radio layer out there somewhere?
Apr 10 12:36:12 <florian> That's a question for Crofton
Apr 10 12:36:29 <jawilson> figured as much
Apr 10 12:38:22 <bluelightning> jawilson: there's a gnuradio recipe in meta-oe
Apr 10 12:38:36 <bluelightning> I wonder if there's a better place for it, but for now it's there
Apr 10 12:39:17 <jawilson> bluelightning, ah, thanks. I'm new to the whole Yocto Project/OE-core thing, used to oe
Apr 10 12:39:24 <jawilson> oe-classic*
Apr 10 12:39:36 <jawilson> I'll go take a look though
Apr 10 13:14:18 <holgerwrs> anyone knows about a presentation about the Yocto project under a share-alike license?  those at http://www.yoctoproject.org/documentation/presentations seems to be a little old
Apr 10 13:17:38 <bluelightning> I did one at FOSDEM: http://fosdem.org/2012/schedule/event/openembedded_yocto_common_core
Apr 10 13:18:13 <bluelightning> more about OE and the Yocto Project working together than the Yocto Project specifically, plus the format was a little unconventional
Apr 10 13:18:26 <bluelightning> so it might not be quite waht you're after
Apr 10 13:18:34 <bluelightning> s/waht/what/
Apr 10 13:22:02 <holgerwrs> bluelightning: it helps - thanks
Apr 10 14:48:20 <sgw> fray: you around?  Any update on the sstate compilation issues?
Apr 10 15:55:20 <halstead> I see two bugs that are old enough to cause problems with the stats, number 35 and number 61
Apr 10 15:55:40 <sgw> halstead: why would they do that?
Apr 10 15:56:12 <halstead> They were opened before bugzilla kept enough data to determine status and they are still unresolved.
Apr 10 15:56:28 <sgw> bluelightning: do you know if there are other distro's that ship qt-mobility?
Apr 10 15:56:51 <sgw> halstead: can we add data to them or do we need to refile them?
Apr 10 15:57:22 <sgw> fray: re-ping
Apr 10 15:57:57 <fray> hey.. just got in.. sick kid at home
Apr 10 15:58:06 <halstead> 35 is an enhancement so I can ignore it for bug trends. Right?
Apr 10 15:58:12 <sgw> right
Apr 10 15:58:52 <bluelightning> sgw: it's in most major distros AFAICT, some not officially though
Apr 10 15:58:53 <sgw> fray: sorry to hear that.  Can we sync up on the sstate issue we started with yesterday at quitting time
Apr 10 15:59:18 <sgw> bluelightning: Ok, I need to add distro tracking info for our process.
Apr 10 15:59:39 <halstead> So I'll just work around number 61 until it's resolved.
Apr 10 16:01:32 <fray> sgw -- got an oe-tsc meeting right now.. then after I have to run something back home for the kid.. I should be able to sync after that
Apr 10 16:01:54 <fray> (BTW I got the initial build done, but not the second user one.. I should have that within 20-30 minutes and verify if the bug is still there or not)
Apr 10 16:02:20 <sgw> fray: Ok, yeah that second build goes pretty fast!
Apr 10 16:02:31 <fray> yup.. just have to add the user and run the build
Apr 10 16:02:55 <sgw> fray: I wanted to sync on what step I might have been missing, but let's see if you can reporoduce it.
Apr 10 16:21:16 <Crofton> heh
Apr 10 16:28:29 <sgw> Crofton: Good Morning
Apr 10 16:29:00 <Crofton> gm
Apr 10 19:33:56 <fray> is there a branch tag decoder ring?  I'm trying to figure out what the code name to Yocto project release numbering is -- and also when approx these branches were released..
Apr 10 19:46:42 <incandescant> fray: the release notes include version number and release name
Apr 10 19:47:17 <fray> but I'm having a hard time finding anything w/ a date
Apr 10 19:48:01 <fray> My list right now -- Laverne is 0.9, approx 2010-10, Bernard 1.0 - 2011-04, Edison 1.1 - 2011-10, and next release sometime thing month
Apr 10 19:48:04 <fray> that sound right?
Apr 10 19:48:30 <incandescant> yes
Apr 10 19:48:34 <fray> thanx
Apr 10 19:48:36 <incandescant> np
Apr 10 19:48:46 <incandescant> this was raised recently and is on Song & Jefro's radar
Apr 10 19:49:54 <Jefro> That does sound right - I'd like to also capture the interim releases like 1.1.1, but they correspond directly with the major Poky release associated (Edison in the case of 1.1.1)
Apr 10 19:50:15 <fray> for what I'm doing, the interim releases don't matter.. but yes, in the grand scheme of things they do
Apr 10 20:11:19 * kergoth thinks release branches named after an actual version number in an actual sane versioning scheme make a great deal more sense than going by 'release name'
Apr 10 20:23:00 <RP__> kergoth: This was discussed at collab and is likely going to change
Apr 10 20:24:45 * ant__ was blown in the past... Blinky, Pinky, Inky, Clyde
Apr 10 20:39:49 <fray> sgw -- ok, I've gone through the steps on my CentOS machine.  I was NOT able to replicate the failure..
Apr 10 20:40:11 <fray> so either it's been fixed somewhere along the line in various changes within the toolchain -- or CentOS is masking it.. (it's newer then the OS I originally tested this on)
Apr 10 20:45:36 <sgw> fray: great, that's what I was seeing also, so maybe somekind of host contamination issue?  I am trying it on an OpenSuse machine
Apr 10 20:45:57 <sgw> fray: 11.4
Apr 10 20:46:14 <fray> I reproduced this both on RHEL 5.x and FC13 machines..
Apr 10 20:46:19 <fray> (before)
Apr 10 20:46:27 <fray> I no longer have the RHEL 5.x, only CentOS 6
Apr 10 20:46:34 <sgw> Of which I have neither
Apr 10 20:46:43 <fray> the FC13 isn't on right now, but I can go and power it up and see if I can get it to come back (as a problem)
Apr 10 20:46:59 <fray> in fact thats what I'll do right now..
Apr 10 20:47:00 <sgw> fray: at this point that would be helpful
Apr 10 20:47:19 <sgw> incandescant: what level CentOS do you have?
Apr 10 20:47:55 <incandescant> sgw: I have a 5.7 VM
Apr 10 21:00:33 <fray> (BTW I did my test on CentOS on a mips target..  I'm doing x86_64 on my FC13 machine)
Apr 10 21:16:57 <sgw> seebs: any progress on the pseudo rpath issue?
Apr 10 21:38:55 <fray> hehhehheh
Apr 10 21:46:03 <fray> ok  FC13 usr1 image built.. now on to configure and test user 2
Apr 10 22:02:22 <seebs> sgw:  the rpath issue is fixed in upstream pseudo now, the problem is that pseudo shoves in an rpath for sqlite even if it's got --enable-static-sqlite.  A quick local fix would be to --without-rpath pseudo's configure line.
Apr 10 22:02:51 <fray> ok.. I'll sync it over to the yocto project git then
Apr 10 22:03:20 <fray> sgw -- failed on FC13
Apr 10 22:03:27 <fray> FC13 & x86_64
Apr 10 22:04:09 <sgw> fray yeah!, can you do a strace of the bitbake psplash
Apr 10 22:04:16 <fray> onfigure:3038: ccache x86_64-oe-linux-gcc    -m64 --sysroot=/home/usr2/oe-core/build-ia32-2/tmp-eglibc/sysroots/qemux86-64 -c -O2 -pipe -g -feliminate-unused-debug-types  conftest.c >&5
Apr 10 22:04:16 <fray> cc1: error: /home/usr1/oe-core/build-ia32/tmp-eglibc/sysroots/qemux86-64/home/usr1/oe-core/build-ia32/tmp-eglibc/sysroots/qemux86-64/usr/include: Permission denied
Apr 10 22:04:17 <fray> cc1: error: /home/usr1/oe-core/build-ia32/tmp-eglibc/sysroots/qemux86-64/usr/include: Permission denied
Apr 10 22:04:17 <fray> configure:3042: $? = 1
Apr 10 22:04:24 <fray> which strace command do you want me to run?
Apr 10 22:05:10 <sgw> strace -s 8192 -f -o out bitbake psplash (after a cleansstate)
Apr 10 22:06:41 <RP__> fray: could you also see whether changing the umask has any effect on that?
Apr 10 22:06:57 <fray> my current umask is 0002
Apr 10 22:07:17 <fray> that is the same on the other machine (CentOS 6)
Apr 10 22:07:25 <fray> I wonder if the problem is x86_64 vs mips
Apr 10 22:07:26 <RP__> fray: ok, fair enough
Apr 10 22:08:27 <fray> wow.. there is a lot of stuff in the small little build attempting to use the "usr1" paths..
Apr 10 22:08:31 <fray> things like 'git'
Apr 10 22:09:15 <fray> 7728  open("/home/usr1/oe-core/build-ia32/tmp-eglibc/sysroots/x86_64-linux/etc/gitattributes", O_RDONLY) = -1 EACCES (Permission denied)
Apr 10 22:09:15 <fray> 7728  access("/home/usr1/oe-core/build-ia32/tmp-eglibc/sysroots/x86_64-linux/etc/gitconfig", R_OK) = -1 EACCES (Permission denied)
Apr 10 22:09:42 <fray> interesting:
Apr 10 22:09:42 <fray> 8384  access("/home/usr2/oe-core/build-ia32-2/tmp-eglibc/sysroots/x86_64-linux/u
Apr 10 22:09:42 <fray> sr/bin/x86_64-oe-linux/../../lib/x86_64-oe-linux/gcc/x86_64-oe-linux/4.6.4/../..
Apr 10 22:09:42 <fray> ry)
Apr 10 22:09:42 <fray> 8384  write(2, "Using built-in specs.\n", 22) = 22
Apr 10 22:11:14 <fray> sgw -- I'll attach my "out" file
Apr 10 22:12:18 <sgw> fray: might have to email it.
Apr 10 22:14:19 <fray> 8 MB bziped
Apr 10 22:23:58 <fray> yup, 1 MB is the limit
Apr 10 22:26:26 <fray> sgw -- ok updated 2074 w/ the URL of the logs
Apr 10 22:26:54 <fray> yocto project "pseudo" repository is also current w/ the github version now..
Apr 10 22:27:16 <fray> I'd recommend for the rpath thing we just pull the commit(s) and patch it for right now.. as there isn't a new tagged release of pseudo yet..
Apr 10 22:27:56 <sgw> fray: send that patch, I will look at the logs
Apr 10 22:28:10 <sgw> fray did you see anything in the strace that gave any hints?
Apr 10 22:28:36 <fray> nothing that I didn't expect -- except for the specs not being readable..
Apr 10 22:28:45 <fray> (and the git* files)
Apr 10 22:29:14 <fray> I've got to prepare for a meeting right now.. but I want to run the same test on CentOS 6 and see if I get the same failure.. if I do or don't it should give us additional insight
Apr 10 22:30:09 <sgw> fray thanks for the followup
Apr 10 22:31:11 <fray> looking, briefly, at pseudo git repo.. looks like there are three patches since the 1.3 release..
Apr 10 22:31:27 <seebs> Yeah.  One quick cleanup patch, then fixes for the RPATH thing and a cleanup for the arch thing.
Apr 10 22:31:45 <fray> the first two, cleanup and fixes and improve RPATH logic are likely needed "now"..  the third (and most recent) are needed only for non IA support for pseudo (I'd say we push that until after the 1.2 release)
Apr 10 22:32:33 <fray> actually I take that back.. I don't think the cleanup is needed either.. except the system.c fix maybe?
Apr 10 22:32:39 <seebs> The cleanup's pretty optional, although it may fix weird behavior... yeah.
Apr 10 22:32:40 <fray> seebs, suggestions?
Apr 10 22:33:03 <seebs> Well, the cleanup other than the system thing is harmless, and the arch thing should have no effect at all if we don't add a --arch= to our recipe.
Apr 10 22:52:17 <khem> its a commendable thing that OE-Core builds fine with gcc 4.5 4.6 and 4.7
Apr 10 22:52:41 <khem> and also swapping C libraries (eglibc or uclibc)
Apr 10 23:03:36 <RP__> khem: that is nice :)
Apr 10 23:04:46 <khem> RP__: indeed
Apr 10 23:05:25 <khem> RP__: there are lot of config related patched in gcc we are carrying that arent needed anymore I have cleaned them up in 4.7
Apr 10 23:05:42 <RP__> khem: cool! :)
Apr 10 23:05:42 <khem> I am not interested in changing those for 4.6 or 4.5
Apr 10 23:05:53 <RP__> khem: no, that seems reasonable
Apr 10 23:06:38 <khem> but I have made sure that gcc 4.6 works well still and they both can reside together
Apr 10 23:06:46 <khem> since thats going to be the case for some time
Apr 10 23:08:08 <RP__> khem: right :/
Apr 10 23:09:27 <khem> patches like this http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-4.7&id=4d6bf3ee829fbf4cd2d442dd8186171ada29e4ed
Apr 10 23:09:36 <khem> are needed for meta-linato to gel well
Apr 10 23:12:44 <ant__> hm..| ERROR: autoreconf execution failed.
Apr 10 23:12:44 <ant__> NOTE: package shadow-native-4.1.4.3-r4: task do_configure: Failed
Apr 10 23:15:50 <RP__> ant__: gettext macros?
Apr 10 23:16:37 <ant__> yes, some warnings about that
Apr 10 23:16:49 <RP__> If so, "bitbake gettext-native gettext-minimal-native -c clean"
Apr 10 23:17:14 <RP__> ant__: there is an open bug but cleaning both at once turns out to be tricky to arrange :/
Apr 10 23:18:42 <ant__> ok, thx
Apr 10 23:18:56 <ant__> this is on screen: http://paste.debian.net/162817/
Apr 10 23:20:40 <ant__> RP__: that worked indeed
Apr 10 23:46:44 <zenlinux> Is there a debug mode bitbake can be put into where a non-zero exit status from a shell command bitbake is executing does *not* cause bitbake to immediately stop running?
Apr 10 23:53:16 <khem> zenlinux: bitbake -k ?
Apr 10 23:54:05 <zenlinux> khem, not sure if that will work, let me check the docs on that
Apr 10 23:55:08 <zenlinux> I don't think that's what I'm looking for
Apr 10 23:55:26 <zenlinux> What I want to be able to do within a task is something like:
Apr 10 23:55:40 <zenlinux> shell command x y z
Apr 10 23:55:47 <zenlinux> retval=$?
Apr 10 23:56:02 <zenlinux> echo "shell cmd failed with $retval"
Apr 10 23:56:23 <zenlinux> currently, bitbake stops executing the task as soon as shell command exits with a nonzero status
Apr 10 23:56:34 <kergoth> that's because bitbake calls sh with set -e
Apr 10 23:56:39 <zenlinux> kergoth, yes, exactly
Apr 10 23:56:42 <kergoth> just set +e to revert hte behavior
Apr 10 23:56:43 <zenlinux> can I disable that?
Apr 10 23:56:47 <kergoth> trivial
Apr 10 23:56:52 <kergoth> same way you do outside of oe :)
Apr 10 23:57:05 <zenlinux> kergoth, thanks! I didn't think it was that simple.
Apr 10 23:57:09 <kergoth> alternaitvely, set -e doesn't exit when the failure works with boolean operation
Apr 10 23:57:14 <zenlinux> I also didn't know if set -e was a bashism
Apr 10 23:57:16 <kergoth> e.g. some shell command || retval=$?
Apr 10 23:57:29 <kergoth> so that works too
Apr 10 23:57:29 <zenlinux> aaahh
Apr 10 23:57:34 <zenlinux> yes! thanks!
Apr 10 23:57:43 <kergoth> np
Apr 10 23:58:05 <kergoth> also, bashism or not isn't relevant, as we require bash right now
Apr 10 23:58:12 <kergoth> so all tasks by definition run in bash
Apr 10 23:58:23 <kergoth> but pretty sure set -e/+e works equally well in any posix compliant shell :)
Apr 10 23:58:46 <fray> kergoth, no I thought that was dropped early in this release cycle..
Apr 10 23:58:55 <fray> the sanity check for bash vs dash was removed (or at least disabled)
Apr 10 23:59:25 <fray> a user just found an issue w/ the rootfs_rpm.bbclass that when run w/ dash it fails...
Apr 11 00:00:08 <kergoth> ah, i didn't realize it was disabled. how did you verify that it doesnt' break anything? the whole point of that check was because the build didn't fail with dash, it'd just act differently, so the problems were extremely difficiult to idenitfy
Apr 11 00:00:57 <fray> you'll have to ask RP.. I thought he was the one that did that
Apr 11 00:01:09 <kergoth> k
Apr 11 00:01:54 <fray> I know in many cases, (where shell scripts are written out and executed) they're invoking /bin/bash directly now..
Apr 11 00:02:49 <fray> ya.. just verified the check is gone from sanity.bbclass
Apr 11 00:03:41 <fray> I'm not sure of an easy way to find what made the change
Apr 11 00:05:42 <fray> 07ded02ffd37b4fe60a6210dbf56490ea306f0b6
Apr 11 00:06:07 <RP__> kergoth: most of the autotools stuff prefers bash internally so that takes a large chunk of the problem out our hands
Apr 11 00:06:46 <RP__> kergoth: It leaves us with our scripts since most of the other build stuff was cleaned up by ubuntu by now
Apr 11 00:07:26 <RP__> kergoth: so the remaining failures from our scripts were fixed and some comparisons were made between builds - it all seemed to be ok
Apr 11 00:08:36 <seebs> set -e is posixy but usually sorta risky -- a lot of scripts will blow up in unexpected ways because people don't even think about return statuses of most commands
Apr 11 00:15:58 <kergoth> set -e won't propogate to child processes, so i don't see set -e being an issue, unless the user is sourcing external scripts from a task, or make assumptions in writing their tasks
Apr 11 00:16:02 <kergoth> RP__: ah, fair enough
Apr 11 01:56:09 <Crofton> whats the oe-core magic to make the root passwd empty
Apr 11 01:56:13 <Crofton> or what is it?
Apr 11 02:05:27 <kergoth> add debug-tweaks to IMAGE_FEATURES to disable the add of 'zap_root_password' to the rootfs postprocess
Apr 11 02:05:29 <kergoth> iirc anyway
Apr 11 02:06:11 <Crofton> that sounds about right
Apr 11 02:06:19 <Crofton> I started from an initrafs image
Apr 11 02:06:31 <Crofton> and it cleared IMAGE_FEATURES
Apr 11 02:06:41 * kergoth nods
Apr 11 02:06:49 <Crofton> working from first principles can be a bit trying
Apr 11 02:09:16 <Crofton> damn it
Apr 11 02:09:39 <Crofton> I should quit
Apr 11 02:09:47 <Crofton> and start again in the morning
Apr 11 02:09:49 <Crofton> so close though
Apr 11 02:14:57 <Crofton> ok
Apr 11 02:15:12 <Crofton> i had added shadow, which broke the zap passwd thing
Apr 11 02:15:51 <Andy44> i added shadow once too and it broke my root login with no password
Apr 11 02:16:10 <Andy44> i couldn't log in
Apr 11 02:20:14 <Crofton> odd
Apr 11 02:20:32 <Andy44> ya
Apr 11 02:21:10 <Crofton> who is supposed to make dev nodes for mmcblk0p?
Apr 11 02:21:28 <Andy44> no idea
Apr 11 02:21:31 <Andy44> sry
Apr 11 02:23:28 <Crofton> I think I need more udev rules
Apr 11 02:25:07 <Crofton> no
**** ENDING LOGGING AT Wed Apr 11 02:59:58 2012

**** BEGIN LOGGING AT Wed Apr 11 02:59:58 2012
Apr 11 09:16:51 <Zagor> I just noticed the pale blue dot in the yocto logo. does it have an expressed meaning? I suppose it's not to make us feel small and insignificant ;-) http://en.wikipedia.org/wiki/Pale_Blue_Dot
Apr 11 09:24:17 <bluelightning> Zagor: it's the "elementary particle" I think
Apr 11 09:25:42 <Zagor> ah
Apr 11 12:14:15 <ag> Hello everybody!
Apr 11 12:14:34 <ag> What is the easiest way to find why a specific rpm is installed in a image.
Apr 11 12:14:36 <ag> ?
Apr 11 12:14:44 <ag> Who requires it?
Apr 11 12:16:12 <RP__> ag: I can tell you how to do this with opkg, not so sure with rpm :/
Apr 11 12:16:36 <ag> RP__: Thanks. opkg won't work for me. Thanks anyway.
Apr 11 12:17:09 <RP__> ag: if you have the build, a grep over the pkgdata directory might give you a clue
Apr 11 12:17:59 <ag> RP__: I will try.
Apr 11 12:34:38 <bluelightning> ag: you can also use buildhistory, that generates dependency graphs just for the image
Apr 11 12:35:13 <ag> i did the hard way: query on rpms. :)
Apr 11 12:38:41 <bluelightning> ah ok... basically that's what the buildhistory class does internally
Apr 11 12:38:54 <ag> bluelightning: But there will be a time for me to understand that  buildhistory
Apr 11 12:38:59 <ag> bluelightning: but not today. :)
Apr 11 12:39:05 <bluelightning> fair enough :)
Apr 11 14:58:09 <seebs> So, someone waved an issue at me involving pseudo on 64-bit hosts, which is that pseudo assumes pretty thoroughly that sqlite's libraries are in $something/lib, not lib64.
Apr 11 14:58:41 <seebs> And it occurs to me that OE and Yocto are built on a much wider range of hosts than wrlinux is, I think.  So has anyone seen anything like that, possibly involving recentish OpenSuSE?
Apr 11 15:03:38 <fray> debian is the one I know of that is moving to a weird format..  I thought SuSE was using either /lib or /lib64 for their 64-bit libraries
Apr 11 16:07:15 <RP__> fray: can you check your email about the useradd thing for a previous email from me
Apr 11 16:07:59 <RP__> seebs: we build sqlite and tell pseudo where it is
Apr 11 16:08:08 <fray> I only see the one I responded too and the one from Scott Garman earlier
Apr 11 16:08:14 <seebs> Do we put the libraries in something/lib?
Apr 11 16:08:26 <RP__> fray: you didn't see my reply with the four solutions?
Apr 11 16:08:30 <seebs> Because if I've understood pseudo's config correctly, it presupposes a foo/lib directory.
Apr 11 16:08:33 <fray> yes, thats the one I responded to
Apr 11 16:09:18 <fray> ya, it's even in my sent box.. ;)  I responded about an hour ago
Apr 11 16:09:48 <fray> b and d I read as the same, and best solution..  c is reasonable, but not sure how that works with the debian approach of passwd/group management
Apr 11 16:09:57 <fray> and I don't think a solves the issue
Apr 11 16:12:38 <RP__> fray: found it, sorry, my email didn't seem to want to update :/
Apr 11 16:12:55 <RP__> fray: having read the rpm install code fairly recently, a will address the issue
Apr 11 16:13:31 <fray> no problem.. :)
Apr 11 16:13:34 <RP__> seebs: we do use something/lib, yes
Apr 11 16:14:02 <fray> ya, but there is nothing to guarenty that it will..  RPM really can reorder everything arbitrarily.. at once time (a testing/verification only patch) went in that did exactly that
Apr 11 16:14:04 <RP__> seebs: it is configurable through the libdir variable though so you probably can't install a multilib pseudo on a target
Apr 11 16:14:07 <fray> relying on manifest order is a bad idea
Apr 11 16:14:26 <seebs> The libdir argument doesn't affect how/where we look for sqlite, though.
Apr 11 16:14:35 <RP__> fray: there is no code that will do that in there assuming no circular dependencies
Apr 11 16:14:41 <RP__> fray: that I saw anyway...
Apr 11 16:14:58 <RP__> seebs: we pass in that as an option though don't we?
Apr 11 16:15:24 <fray> correct, the code was only temporary.. but the point is the behavior can change, and the authors have said as much in the past..
Apr 11 16:15:31 <seebs> The problem reported to me is that, in another environment, sqlite is in foo/lib64, and pseudo's configuration doesn't handle that; you specify --with-sqlite=foo, and it infers foo/lib./
Apr 11 16:15:32 <fray> relying on manifest order isn't a good idea
Apr 11 16:23:47 <RP__> fray: I think we might have to for this release. I don't really want to rewrite the rpm package installation code at -rc3
Apr 11 16:24:31 <fray> RP__ not going to disagree with you there.. :)
Apr 11 16:24:45 <fray> I'm still trying to understand from the other post set why dbus goes in before base-passwd..
Apr 11 16:25:00 <fray> thread from Donxiao Xu
Apr 11 16:25:33 <RP__> fray: I suspect there is more to that log
Apr 11 16:25:44 <fray> bingo.. I think I know what is happening..
Apr 11 16:25:52 <fray> base-passwd required /bin/sh
Apr 11 16:25:54 <fray> as does dbus-1
Apr 11 16:25:57 <RP__> right
Apr 11 16:26:08 <RP__> and it hasn't found those in the manifest yet
Apr 11 16:26:19 <fray>  /bin/sh is provided by another package that uses the alternatives methods.. which are also required by the useradd stuff (I thought)
Apr 11 16:26:27 <fray> so there is a long circular dependency chain, I think
Apr 11 16:26:34 <fray> (haven't verified that)
Apr 11 16:28:06 * fray switches a build from ipk to rpm to check if that may be happening
Apr 11 16:29:01 <RP__> fray: it doesn't need to be circular
Apr 11 16:29:05 <fray> RP -- it just occurded to me.. there is a switch for rpm that will prevent it from evaluating dependencies
Apr 11 16:29:22 <fray> so if the manifest is already in order (or adjusted order) we can force that as the install order as well.. I think
Apr 11 16:29:57 * fray checks if that option still exists
Apr 11 16:31:17 <fray> it's --noorder
Apr 11 16:31:29 <fray> add that to the install line, and the order specified in the manifest will be used exactly
Apr 11 16:31:53 <fray> there, that solves my concern of the order being changed even if we manipulate the install manifest
Apr 11 16:31:57 <RP__> fray: it won't help, it won't execute the post install until all dependencies are installed
Apr 11 16:32:20 <fray> yes, that is correct
Apr 11 16:32:52 <fray> but I thought the order was already determined?
Apr 11 16:33:28 <RP__> fray: we put shadow and base-passwd at the start, not their dependencies
Apr 11 16:33:38 <RP__> if we do the latter, I think the problem won't occur
Apr 11 16:33:49 <RP__> I'm trying to figure out magic shell commands to test this theory
Apr 11 16:35:50 <fray> base-passwd requires /bin/sh -- /bin/sh is provided by either bash or busybox -> both require glibc components.... but I don't see glibc reuqiring anything magic
Apr 11 16:36:51 <fray> BTW you can do a forced install --and-- run the post-install scripts.. you just have to make sure you have the infrastructure in place to run them
Apr 11 16:37:13 <fray> installing base-passwd and shadow with --nodeps should do exactly that
Apr 11 16:38:27 <fray> BTW we don't have this problem w/ the base-passwd package at least in WR Linux because we don't use shell scripts for the post-install options..  we use a built-in lua interpreter..
Apr 11 16:38:36 <fray> here is another possibility..
Apr 11 16:38:57 <fray> you can tell RPM what dependencies are already provided by the system.. we could put /bin/sh in there (as I believe that is the culpret in this)
Apr 11 16:39:19 <fray> that would allow the /bin/sh dep to be satisfied right away, triggering the post install.. (but the /bin/sh providers would still be installed later)
Apr 11 16:39:30 <RP__> fray: and have /bin/sh effectively go missing from some images?
Apr 11 16:39:36 <fray> no, it won't
Apr 11 16:39:43 <fray> you generate the manifest w/o the provide
Apr 11 16:39:58 <fray> you only add the manual provide during the install step.. changing the scriptlet triggering order..
Apr 11 16:40:01 <RP__> fray: we'd still need to ensure libc is at the top
Apr 11 16:40:05 <fray> (then remove it as well)
Apr 11 16:40:17 <fray> why libc?  it only nees to be on top to allow /bin/sh to run right?
Apr 11 16:40:27 <RP__> fray: check out shadow's depends
Apr 11 16:40:38 <RP__> fray: we need shadow *and* base-passwd
Apr 11 16:42:49 <fray> ya, I see shadow requires libc
Apr 11 16:43:34 <fray> it's the pwconv and grpconv as well.. Hmm
Apr 11 16:44:25 <fray> well, the other option is go back to what we were doing in 1.1.. delay all of the post install operations until after the packages are installed..
Apr 11 16:44:31 <fray> then only pre-installs are run during the build..
Apr 11 16:46:40 <fray> back in 15.. need to grab food before my next meeting
Apr 11 16:48:02 <dvhart> nitink, nice work on 2259
Apr 11 16:48:09 <dvhart> yocti, nitink++
Apr 11 16:48:25 <nitink> dvhart :)
Apr 11 16:48:51 <RP__> changing package_install_internal_rpm triggers all the package_write_rpm tasks to rerun? That is seriously screwed up:/
Apr 11 16:55:44 <RP__> fray: sadly not an option due to the requirement to setup users before installing files
Apr 11 16:58:42 <fray> I thought the usersetup was "pre-install" not post
Apr 11 16:59:16 <fray> really, package_install_internal_rpm shouldn't change anything except image generation.. how odd
Apr 11 17:02:12 <RP__> fray: our problem is preinstall
Apr 11 17:02:26 <RP__> fray: the pre installs also wait on dependencies
Apr 11 17:02:30 <fray> Hmm.. I thought post install was part of it..
Apr 11 17:02:32 <fray> Hmm
Apr 11 17:04:18 <RP__> fray, zenlinux: http://pastebin.com/D96uDwQg is what I'm trying to test
Apr 11 17:04:31 <RP__> I have it applied to the test case on ab05 but I'm out of time :(
Apr 11 17:04:49 <RP__> build is running but not finished
Apr 11 17:05:26 <fray> libc assumes the debian rename has happened.. turn that off and hte package name is glibc
Apr 11 17:05:33 <fray> otherwise looks reasonable
Apr 11 19:36:33 <RP__> fray: around?
Apr 11 19:36:59 <fray> my day of meetings seems to be coming to an end.. I have time to work on "real" problems
Apr 11 19:37:18 <RP__> fray: I tried adding /bin/sh to Providename as suggested
Apr 11 19:37:27 <RP__> fray: rpm appears to be ignoring me
Apr 11 19:37:36 <RP__> fray: strace confirms it does look at the file :/
Apr 11 19:38:03 <fray> I'm trying to remeber if that is the right file
Apr 11 19:38:08 <fray> (there are a number of them)
Apr 11 19:38:17 <RP__> fray: its the one we use in the other case we do this
Apr 11 19:38:32 <RP__> but in that case we do this earlier
Apr 11 19:38:39 <fray> well the way to check is try to install -only- base-passwd with it set..
Apr 11 19:38:46 <fray> if it fails, then it's not looking there like it should  ;)
Apr 11 19:44:39 <RP__> fray: that does appear to work :/
Apr 11 19:44:57 <fray> then it must be a precidence thing with package deps over manually set ones.. :(
Apr 11 19:46:34 <RP__> fray: right :(
Apr 11 19:47:52 <fray> does glibc have a base-passwd requirement?  if it did we could trigger a circular dependency, one that we could break..
Apr 11 19:48:01 <fray> (I'm not sure its a good idea though cause of ipkg and deb behaviors)
Apr 11 19:49:18 <fray> BTW that sstate compiler problem.. it happens on FC13, but not CentOS.. I verified that with identical configurations.. :P
Apr 11 19:49:28 <fray> so we have a host / host contamination issue (maybe)
Apr 11 19:50:24 <RP__> fray: interesting :/
Apr 11 19:50:31 <fray> ya, thats one word for it
Apr 11 19:50:43 <fray> my first reaction was a four letter word...
Apr 11 19:53:05 <RP__> fray: I'm trying not to type words like that in connection with rpm atm ;-)
Apr 11 19:53:15 <fray> I can tell
Apr 11 19:55:56 <fray> BTW we don't actually need the shadow utilities installed for adduser/group to work do we?  (on the host install, only for self-hosted work right?)
Apr 11 19:56:28 <fray> does shadow have a dependency on passwd?
Apr 11 19:57:29 <msm> ahh useradd my favorite ;)
Apr 11 19:57:30 <fray> Hmm it does not..
Apr 11 19:57:39 <fray> would this work?  shadow requries base-passwd (which is reasonable)
Apr 11 19:57:52 <fray> everything that users adduser/addgroup require "adduser/addgroup".. which is then provided by shadow?
Apr 11 19:58:14 <fray> that should force shadow and base-passwd to be "installed" before adduser/group is executed
Apr 11 19:59:05 <fray> I think the /bin/sh dependency in base-passwd is one thing screwing us up, but I don't know a way around that....
Apr 11 20:01:13 <fray> (btw there used to be some hard coded package names in rpm... if the code is still there, maybe we have to use it to force base-passwd early...)
Apr 11 20:05:53 <fray> RP, sorry to change subjects.. any feeling on the direction of the MIPS/MIPS32 thing?
Apr 11 20:06:01 <fray> Andreas was the only one to respond
Apr 11 20:18:18 <fray> FYI.. centos dependencies..  "setup" provides the passwd/group files..  filesystem, basesystem, shadow-utils requires setup
Apr 11 20:18:46 <fray> filesystem requires basesystem
Apr 11 20:19:10 <fray> sorry, basesystem requires filesystem
Apr 11 20:19:28 <fray> can't figure out what requires basesystem though.. Hmm..
Apr 11 20:19:47 <fray> point is though shadow-utils requireing the passwd/group file package is reasonable.. and it's definitely the post install script that is screwing us
Apr 11 20:22:29 <kergoth> is there a summary of the locale situation in oe somewhere? e.g. the eglibc-locale bits, what vars do what.. in particular, I'm wondering if locale files from the external toolchain belong in usr/lib64/locale or usr/lib/locale. the csl toolchain has it in the latter, even though that's not relative to ${libdir} (base_libdir == lib64 in this case)
Apr 11 20:23:10 <fray> locale files need to be wherever glibc is looking for them, I assume at least
Apr 11 20:24:03 * fray breifly looks at eglibc
Apr 11 20:24:13 <kergoth> i couldn't recall if it was glibc looking for them. if it is, i presume in this case they need to be in usr/lib/locale, which mean i might need to hack the eglibc-locale recipe
Apr 11 20:24:17 <kergoth> hrm
Apr 11 20:24:53 <fray> ya.. it's the value of --localedir when compiled
Apr 11 20:24:56 <fray> 'er.. configured
Apr 11 20:25:08 <fray> localedir is by default datarootdir/locale..
Apr 11 20:25:13 <fray> so usr/share/locale?
Apr 11 20:25:45 <kergoth> ah, right, intl is in eglibc, but not in uclibc, need gettext's libintl for that
Apr 11 20:25:52 <kergoth> ah, hmm
Apr 11 20:25:55 <fray> datarootdir is prefix/share.. so ya.. usr/share or just /share
Apr 11 20:26:02 <kergoth> okay, thanks, i'll poke around some more
Apr 11 20:26:05 <fray> np
Apr 11 20:26:29 <kergoth> we have a mips64 setup we need to play with using an external csl toolchain, heh
Apr 11 20:26:40 <kergoth> blah, the locale generation options table doesn't have that arch :)
Apr 11 20:30:06 <fray> easy to add  ;)
Apr 11 20:30:17 <fray> tell me the arch and I'll tell you the settings..
Apr 11 20:30:25 <fray> (big endian/little endian -- n32 or n64)
Apr 11 20:31:24 <fray> where is the locale table?  I thought it was in meta/recipes-core/eglibc.. is it in a class?
Apr 11 20:31:39 <fray> libc-package.bbclass?
Apr 11 20:31:55 <kergoth> yep, it's in libc-package.bbclass
Apr 11 20:32:24 <kergoth> think this is n64/le, but i'm not the expert, i'm integrating a bsp layer someone else threw together, and it's exploding in my face :)
Apr 11 20:32:49 * kergoth rolls eyes
Apr 11 20:33:30 <fray> I'm looking.. hopefully won't take much longer
Apr 11 20:35:06 <fray> there are only two valid settings AFAIK:
Apr 11 20:35:07 <fray> glibc_localedef_OPT_little4      = --little-endian --uint32-align=4
Apr 11 20:35:07 <fray> glibc_localedef_OPT_big4         = --big-endian --uint32-align=4
Apr 11 20:35:17 <kergoth> no worries, appreciate the assistance, i've always worked hard to ignore locales and gettext and..
Apr 11 20:35:21 <fray> so for mips and mips64 it's the same
Apr 11 20:35:22 <kergoth> k, thanks
Apr 11 20:35:27 <fray> for mipsel and mips64el it's the same
Apr 11 20:35:31 * kergoth nods
Apr 11 20:36:34 <kergoth> should make the class use the big-endian/little-endian tunings in TUNE_FEATURES control that argument at some point :)
Apr 11 20:37:27 <fray> ya, I would agree with you..
Apr 11 20:37:38 <fray> hard coding it in the libc-package is likely a bad idea
Apr 11 20:38:26 <fray> and afaik, all of the architectures we currently, and are likely to support all have the same alignment.. so it's just a big vs little endian thing
Apr 11 20:38:31 <kergoth> at a minimum that should have gone based on siteinfo, at least consolidate that sort of knowledge in one place
Apr 11 20:38:35 <kergoth> ah, cool
Apr 11 20:39:00 <fray> (You'd have the ask the former CS side of the house if there are any architectures where the alignment isn't 4..)
Apr 11 20:39:16 <fray> ...but there aren't in arm, ppc, ia and mips...
Apr 11 20:41:15 * kergoth nods
Apr 11 20:47:31 <fray> thinking about it, I wouldn't be surprised if S390 had a different alignment
Apr 11 20:56:40 <kergoth> fray: looks like binary localedata ends up in ${libdir}/locale, non-binary in ${datadir}/i18n/locales
Apr 11 20:56:43 * kergoth pokes further
Apr 11 20:56:55 <fray> Ahh ok...
Apr 11 20:57:13 <fray> it should be all based on the configure settings at least
Apr 11 20:58:15 <kergoth> hmm, i never thought about potential interactions between external-csl-toolchain and host permissions. i have files in the ipk with my build machine's uid :) oops
Apr 11 20:58:20 <kergoth> guess i need a chown in there
Apr 11 20:58:39 <darknighte> kergoth: probably
Apr 11 20:58:45 <fray> sounds like a missing do_install to correct those
Apr 11 21:31:34 <RP__> fray: I've just mailed a patch out
Apr 11 21:36:07 <fray> (I agree it's currently horrible)
Apr 11 21:38:10 <fray> what does the initial_solution manifest look like, how many pages ended up in it?
Apr 11 21:38:34 <RP__> fray: seven packages
Apr 11 21:38:45 <RP__> all on one page :)
Apr 11 21:38:52 <fray> those three plus glibc and?
Apr 11 21:40:46 <RP__> Sorry, libc6, shadow-securetty, base-files, busybox-udhcpc, busybox, busybox-syslog, libgcc1, base-passwd, shadow, update-rc.d
Apr 11 21:41:00 <RP__> so 10, I can't count
Apr 11 21:41:14 <fray> ahh forgot.. busybox provides the /bin/sh
Apr 11 21:41:25 <fray> (and that in turn requires the busybox-udhcpc and update-rc.d)
Apr 11 21:41:31 <fray> ok.. that list makes sense to me..
Apr 11 21:41:51 <RP__> yes, it was the one I came up with manually and tried reordering the list with :/
Apr 11 21:41:52 <fray> I've reviewed it and don't see any issues..  want a reviewed-by email sent?
Apr 11 21:41:58 <RP__> fray: sure :)
Apr 11 21:42:12 <RP__> fray: I'm just testing out a couple of things
Apr 11 21:42:42 <fray> yup.. figured you'd ned to
Apr 11 21:43:06 <fray> I hope we can eventually move to a model of external image generation.. so this crap can all be moved outside of the class structure..
Apr 11 21:43:17 <fray> (it'll likely be just as painful there..)
Apr 11 21:43:27 <RP__> I doubt that will make much difference
Apr 11 21:43:39 <RP__> that class would be way more readable with some sensible functions...
Apr 11 21:44:06 <fray> first versions were not so good, and it's gotten progressively worse I'm afraid..
Apr 11 21:44:23 <RP__> Its not that what its doing is hard, its just all the options to pass to rpm...
Apr 11 21:44:44 <RP__> I spent 10 mins wondering why it wasn't working with a base_arch vs ml_arch typo
Apr 11 21:44:59 <fray> ya, the multilib stuff is a huge mess..
Apr 11 21:45:16 <fray> I'd really really like to re do this using zypper, yum, smart or whatever else.. instead of having to do the dependency resolution ourselves..
Apr 11 21:47:26 <RP__> fray: is this patch going to break with multilibs?
Apr 11 21:47:44 <fray> I don't think so.. I looked for an obvious failure there and I don't see one
Apr 11 21:47:54 <RP__> fray: There is no -D "`cat ${confbase}-ml_archs.macro`"
Apr 11 21:48:11 <fray> the only other obvious failure would be the debian rename class.. but none of things selected fall into that category
Apr 11 21:48:14 <RP__> fray: Could I pass in both the ml_archs and the base_archs ?
Apr 11 21:48:19 <Crofton> what about multi-arch , trolls Crofton
Apr 11 21:48:39 * RP__ can't hear Crofton
Apr 11 21:49:00 * Crofton sees RP__ saying la la la la la
Apr 11 21:49:05 <fray> looking at the code, I don't see any removed multilib functionality -- so it should be fine
Apr 11 21:49:14 <fray> you can't compile the two macro sets because they would overlap each other
Apr 11 21:49:20 <RP__> fray: think about the case its installing lib32-base-passwd
Apr 11 21:49:30 <RP__> or lib32-shadow
Apr 11 21:49:47 <fray> I doubt that would have worked before
Apr 11 21:50:36 <fray> I'm trying to think here..
Apr 11 21:50:54 <RP__> fray: it does work and I know QA test this
Apr 11 21:51:06 <fray> I'm surprised actually..
Apr 11 21:51:18 <fray> did they check if it was using only lib32 items, or did it suck in the regurlar as well?
Apr 11 21:51:32 <fray> what is the arch type of base-passwd?  noarch/all or target arch?
Apr 11 21:52:48 <fray> hmm target arch
Apr 11 21:53:07 <fray> is there any way we can tell what the arch type is of the to-be-installed arch?
Apr 11 21:53:21 <fray> we could adjust the check for that, but the check really should only be on the primary arch being installed
Apr 11 21:53:31 <fray> (second arch's should fall back to the regular code path)
Apr 11 22:00:54 <RP__> This patch also breaks the toolchain build
Apr 11 22:04:47 <fray> because no packages are selected?
Apr 11 22:04:53 <RP__> fray: no, false alarm
Apr 11 22:05:03 <fray> if those things aren't there, then the initial list goes to nothing.. and ya.. that could fail
Apr 11 22:05:12 * RP__ left some debug code in disabling index recreation ;-)
Apr 11 22:05:24 <RP__> fray: This is why I was testing that
Apr 11 22:05:38 <fray> is there a check for an empty manifest anywhere?
Apr 11 22:06:13 <fray> I thought there used to be, but I don't see it in the patch fragment.. (and I need to leave..  I'm the only one currently allowed to drive in the family... kid has no license, mom is on painkillers)
Apr 11 22:06:40 <RP__> fray: np. I think empty manifests work
Apr 11 22:07:56 <fray> please verify that..  I know RPM won't like them.. infact a manifest smaller then I believe 20 characters is considered invalid as well..
Apr 11 22:08:01 <fray> (due to a historical problem)
Apr 11 22:08:14 <fray> which is why most manifest files start with an initial comment line.. just to pad them out
Apr 11 22:08:25 <fray> but an empty one should trigger a failure message about nothing to install
Apr 11 22:08:33 <fray> (thus why i thought there was a checkf or that)
Apr 11 22:08:57 <kergoth> RP__: had a chance to take a look at either the sstate reuse rfc or the bitbake patch for the siggen whitelist problem?
Apr 11 22:09:07 <fray> later..
Apr 11 22:10:17 <RP__> kergoth: I did read through both. The bitbake siggen code one is something I know has gone backwards and forwards as the code was developed. I can't remember why it ended up the way it did. Part of me wants to teach pysh what unset means...
Apr 11 22:10:40 <RP__> kergoth: Regardless, I concluded it was better looked at after release. I've then got swapped with release stuff :(
Apr 11 22:11:14 <kergoth> k, np. no rush, we worked around it via manually ensuring the problematic env vars are always set in our setup scripts, and we keep the sstate-reuse bbclass in our layer for now
Apr 11 22:11:48 <RP__> kergoth: Its something I really want to spent some time and think about rather than rush into...
Apr 11 22:12:13 <kergoth> the siggen one is clearly a bug. you treat tasks differently than functions. TERM is explicitly removed from the deps list for tasks, but not functions
Apr 11 22:12:32 <kergoth> the other, i agree, which is why it's self contained and opt-in
Apr 11 22:20:44 <kergoth>  | bison -y -d ./parse.y | conflicts: 1 shift/reduce | make: *** [y.tab.c] Broken pipe | ERROR: oe_runmake failed
Apr 11 22:20:53 <kergoth> anyone come across this one in bash's build?
Apr 11 22:39:17 <RP__> kergoth: never seen it before
Apr 11 22:56:53 <kergoth> strange
Apr 11 23:29:02 <RP__> fray: fwiw, multilibs look saner with both solverdb sets involved. I've therefore pushed that version since it seems to work ok in other configurations too
Apr 11 23:36:18 <kergoth> RP__: gzip-native's write to sysroot can race with sstate_archive :( another issue with non-atomic write of a binary to the sysroot bindir
Apr 11 23:36:50 * kergoth 'll open a bug for tracking purposes
Apr 11 23:36:58 <RP__> kergoth: do you have the changes in master related to that?
Apr 11 23:37:10 <kergoth> ah, perhaps not. will check that, thanks
Apr 11 23:38:19 <RP__> kergoth: those should resolve that one. Can't say I like the solution but it at least removes the race
Apr 11 23:38:40 <kergoth> k
Apr 12 01:03:04 <nitink> khem: ping
Apr 12 01:37:44 <khem> nitink: whats up
Apr 12 01:38:17 <nitink> khem: wondering if you have seen this with gcc 4.7: https://bugzilla.yoctoproject.org/show_bug.cgi?id=2278
Apr 12 01:38:53 <nitink> khem: as it is a native recipe you may not see it
Apr 12 01:44:40 <khem> nitink: its a scope problem
Apr 12 01:44:57 <khem> see some of my recent fixes in OE-Core
Apr 12 01:45:03 <nitink> khm: we found fix, saul posted it on the bug
Apr 12 01:45:05 <khem> to zypper
Apr 12 01:45:25 <nitink> khem: ok will see your fixes too
Apr 12 01:46:23 <khem> you need to include unistd.h in that file
Apr 12 01:46:44 <nitink> khen: yes zypper has the same fix
Apr 12 01:47:38 <khem> yes I have fixed some of issues I have encountered
**** ENDING LOGGING AT Thu Apr 12 02:59:58 2012

**** BEGIN LOGGING AT Thu Apr 12 02:59:58 2012
Apr 12 12:29:38 <gizero> A bug I submitted looks fixed in master after one of recent commits... what's best practice? should I change its state to RESOLVED or is it done automatically as documented on the project's wiki? just to know what's best
Apr 12 12:32:11 <Zagor> I don't know what is preferred, but I would add a comment on the bug saying it appears to be fixed
Apr 12 12:35:33 <gizero> Thanks Zagor! this is done ;-) Wanted to know if I should go any further
Apr 12 12:47:17 <RP__> gizero: which bug is this out of interest?
Apr 12 12:47:51 <gizero> #2244
Apr 12 12:47:53 <RP__> gizero: If you were the submitter and you think its fixed, I'd add a comment, the mark it as resolved fixed. If you were not the submitter, I'd just add a comment
Apr 12 12:48:39 <gizero> ok! I'll do so... sounds reasonable, thanks!
Apr 12 12:48:42 <RP__> gizero: so since you were the submitter I'd mark it as resolved fixed if you're happy its now been resolved
Apr 12 13:34:36 <RP__> fray: ping?
Apr 12 15:27:27 <autif1> nick autif
Apr 12 15:55:56 <sgw> fray ping
Apr 12 15:56:32 <fray> hey
Apr 12 15:56:47 <fray> BTW if it comes down to it, I can likely get an FC13 outside of our VPN..
Apr 12 15:56:56 <fray> (I just can't guarenty a static IP)
Apr 12 15:58:00 <sgw> fray: could you run just the configure scripts (from the temp dir) on those 2 machines with strace to remove alot of the noise?
Apr 12 15:59:00 <fray> ya.. I should be able to
Apr 12 15:59:12 <fray> I'll run the do_configure step
Apr 12 16:00:11 <sgw> fray, not via bitbake, just run the script directly (you could even edit it to have the strace on the configure process itself
Apr 12 16:00:46 <fray> ok.. I can do that
Apr 12 16:01:10 <RP__> fray: just the run.do_configure.* script in WORKDIR/temp
Apr 12 16:01:30 <fray> RP__ will it setup the environment as well?
Apr 12 16:03:02 <kergoth> the run scripts always contain the environment, yes
Apr 12 16:03:11 <fray> ok
Apr 12 16:04:16 <fray> 30 MB uncompressed
Apr 12 16:06:06 <fray> 4.1 MB compressed..
Apr 12 16:06:17 <sgw> Bigger?
Apr 12 16:08:03 <fray> it'll take me a few minuts to rerun it on centos..
Apr 12 16:08:11 <fray> (Id rmeoved my "usr2" directory)
Apr 12 16:23:01 <fray> centos version uncompressed.. 36 MB
Apr 12 16:23:44 <fray> 4.5 MB compressed
Apr 12 16:24:54 <fray> https://gate.crashing.org/~fray/yocto/fc13-configure-out.bz2
Apr 12 16:25:02 <fray> https://gate.crashing.org/~fray/yocto/centos-configure-out.bz2
Apr 12 16:25:09 <fray> 'er.. no 's'
Apr 12 16:25:23 * fray is adding to the bug
Apr 12 16:32:44 <fray> comparing the strace files.. the compilers are simply working differently when they get to that code path
Apr 12 16:34:09 <fray> - stat("/home/usr1/oe-core/build-ia32/tmp-eglibc/sysroots/qemux86-64/home/usr1/oe-core/build-ia32/tmp-eglibc/sysroots/qemux86-64/usr/include", 0x7fff6f506ab0) = -1 EACCES (Permission denied)
Apr 12 16:34:14 <fray> + stat("/home/usr2/oe-core/build-ia32-2/tmp-eglibc/sysroots/qemux86-64/home/usr1/oe-core/build-ia32/tmp-eglibc/sysroots/qemux86-64/usr/include", 0x7fffcc96cf70) = -1 ENOENT (No such file or directory)
Apr 12 16:34:45 <fray> notice the difference?  the first one looks in /home/usr1/.../home/usr1/...  while the second looks in   /home/usr2/.../home/usr2/...
Apr 12 16:34:54 <fray> they are simply behaving differently here..
Apr 12 16:48:20 <RP__> fray: the centos url doesn't work?
Apr 12 16:53:26 * fray checks for typos
Apr 12 16:53:43 <fray> it's centos62
Apr 12 17:01:18 <sgw> fray: what's up with the pseudo patch?
Apr 12 17:02:16 <fray> peter suggested something in the bug.. I'm trying it now.. and I can submit it shortly
Apr 12 17:02:28 <sgw> fray: thanks for the update
Apr 12 17:04:24 <RP__> fray: on fc13 can you disable ccache ?
Apr 12 17:04:47 <RP__> CCACHE="" in local.conf should do it
Apr 12 17:04:57 <fray> sure
Apr 12 17:05:09 <RP__> fray: a kind of long shot but its made me wonder...
Apr 12 17:05:10 <fray> do I need to rebuild it all?
Apr 12 17:05:34 <RP__> fray: I'd be interested even just taking ccache out the run.do_configure
Apr 12 17:05:37 <fray> ok
Apr 12 17:06:17 <fray> same error
Apr 12 17:06:22 <fray> CCACHE="" tmp-eglibc/work/x86_64-oe-linux/psplash-0.1+git1+e05374aae945bcfc6d962ed0d7b2774b77987e1d-r1/temp/run.do_configure.7971
Apr 12 17:06:24 <fray> that is what I ran
Apr 12 17:06:49 <kergoth> it's unlikely that that would work. the urn script almost certainly *sets* CCACHE, overriding your env var
Apr 12 17:07:02 <kergoth> but thats coming inot this discussion without any context :)
Apr 12 17:07:07 <RP__> fray: sorry, for the script you'll have to edit it and remove the ccache references
Apr 12 17:07:48 <fray> (I'm really glad we set F77 in the environment..) <sarcasm>
Apr 12 17:08:42 <fray> that worked
Apr 12 17:09:09 <RP__> fray: worked as in the build succeeded?
Apr 12 17:09:16 <fray> configure succeeded yes..
Apr 12 17:09:26 <kergoth> can we drop the default use of ccache after the release, please? :)
Apr 12 17:09:26 <fray> I removed references to "ccache" and "CCACHE_DIR" from the run file
Apr 12 17:09:48 <RP__> fray: The ccache changes the location the compiler objects are placed into which I think changes the compiler behaviour
Apr 12 17:09:58 <RP__> kergoth: yes, I really want to too
Apr 12 17:14:13 <RP__> fray: question is what next. Is the issue in ccache or gcc?
Apr 12 17:14:22 <RP__> we have a workaround I guess...
Apr 12 17:14:55 <fray> these are two seperate users..  but it does appear to be using the system ccache (as far as I can tell)
Apr 12 17:15:09 <fray> so the data files are local, but the cacche binary is global?
Apr 12 17:15:25 <fray> the centos machine I have doesn't have ccache
Apr 12 17:17:09 <RP__> fray: ccache-native wasn't built, right? so yes, data files are local, the ccache binary is from the system
Apr 12 17:17:19 <RP__> you'd have to "bitbake ccache" to get ours
Apr 12 17:17:26 <RP__> er, bitbake ccache-native
Apr 12 17:17:36 <fray> the ccache_dir was local to the user
Apr 12 17:18:07 <RP__> fray: right, I can see that from the log. There is still something odd going on here...
Apr 12 17:19:37 <fray> export CCACHE_DIR="/home/usr2/oe-core/build-ia32-2/tmp-eglibc/ccache/x86_64-oe-linux/psplash"
Apr 12 17:19:54 <fray> no global ccache config for the user either
Apr 12 17:22:14 <fray> RP__, fyi I'm trying Sakoman's image type to reproduce the image generation issue..
Apr 12 17:22:25 <fray> (munged to remove deps outside of oe-core)
Apr 12 17:22:27 <RP__> fray: ah ok, cool
Apr 12 17:22:47 <fray> (I"m wondering if someone broke bash in meta-oe or something)
Apr 12 17:23:20 <fray> ugh.. too many windows
Apr 12 17:24:18 <RP__> fray: sakoman mentioned that his bash.spec does contain the Provides: /bin/sh
Apr 12 17:24:27 <fray> ya.. I saw..
Apr 12 17:24:30 <fray> that should be enough
Apr 12 17:24:47 <RP__> fray: right, this confuses things. Next would be to check the rpm I guess
Apr 12 17:25:35 <fray> ya.. once I reproduce, I'll start looking at it on the package level..
Apr 12 17:25:40 <fray> but the code you checked in should be working fine
Apr 12 17:25:52 <fray> so at this point it has to be dependency resolution based.. either RPM or bad packages
Apr 12 17:34:58 <sakoman> fray: I don't see any bash overrides is meta-oe
Apr 12 17:35:09 <fray> I didn't know of any either..
Apr 12 17:35:22 <fray> I'm about 15 minutes from reproducing it (or not)
Apr 12 17:42:33 <fray> it worked here.. but it picked up busybox for the /bin/sh..
Apr 12 17:42:39 <fray> I'm going to clean that out and retry
Apr 12 17:44:26 <fray> ok.. failure has been reproduced here..
Apr 12 17:44:30 <fray> time to start digging into it
Apr 12 17:46:14 <sakoman> fray: thanks for looking into this!
Apr 12 17:46:56 <fray> the dependency resolution failed.. (this was before the install even)
Apr 12 17:49:35 <sakoman> fray: have you noticed the python package_do_filedeps_append  function in the busybox recipe?
Apr 12 17:49:52 <sakoman> seems that might be why busybox is working
Apr 12 17:50:20 <fray> ya, I wrote that.. ;)
Apr 12 17:50:29 <fray> but not that isn't the reason it's working.. (or well shouldn't be)
Apr 12 17:50:44 <fray> the filedeps and package deps all get fed back into the .spec file generation..
Apr 12 17:50:55 <fray> rpm -qp <package> --provides shows what is being used for the resolution..
Apr 12 17:50:58 <fray> I see /bin/sh in the bash
Apr 12 17:51:19 <fray> bash = 4.2-r2
Apr 12 18:01:44 <kergoth> msm: ping
Apr 12 18:17:48 <msm> kergoth: hello
Apr 12 18:17:57 <kergoth> now i have to remember what i wanted
Apr 12 18:18:00 * kergoth scratches head
Apr 12 18:18:09 <msm> probably something wrong with meta-fsl-ppc
Apr 12 18:18:10 <msm> ;)
Apr 12 18:18:28 <kergoth> hehe, no. oh, i wanted to ask if you'd had a chance to read my rfc emai about sstate reuse
Apr 12 18:28:08 <msm> i've read it
Apr 12 18:28:11 <msm> but not tested it out
Apr 12 18:28:26 <msm> i suspect it looks good to go - and it's much better than what we have now
Apr 12 18:28:32 <msm> looks = is
Apr 12 18:30:08 <kergoth> okay, thanks, that helps, was looking to make sure i'm not completely insane.. in this, anyway ;)
Apr 12 18:31:12 <fray> I need to blacklist a package from the build.. I thought there was an easy way tos pecify the PN
Apr 12 18:31:28 <fray> (I'm failing to find an example)
Apr 12 18:31:44 <kergoth> fray: iirc there's the blacklist class, and the corresponding BLACKLIST var or similar. not sure if its in oe-core or meta-oe though
Apr 12 18:31:48 * kergoth has never actually used it
Apr 12 18:32:00 <kergoth> i just bbmask things out that cause problems usually
Apr 12 18:32:05 <fray> drat, I thought there was a variable that was honored by bitbake..
Apr 12 18:32:10 <fray> I need to stop busybox from being built
Apr 12 18:32:21 <fray> any examples of bbmask then?
Apr 12 18:32:30 <fray> (I'd rather no just rm busybox either)
Apr 12 18:32:37 <kergoth> well, any recipe can choose to make itself not buildable by raising SkipPackage exception from anonymous python. that's how COMPATIBLE_MACHINE is implemented
Apr 12 18:32:41 <kergoth> so you could always do that from a bbappend
Apr 12 18:33:05 <kergoth> bbmask is just a regex. BBMASK = "/recipes-core/busybox/" or so
Apr 12 18:33:14 <fray> will that stop busybox then?
Apr 12 18:33:43 <kergoth> it'll keep it from even being parsed, which could cause other issues, it's rather brute force :)
Apr 12 18:33:53 <fray> that works for me in this instance
Apr 12 18:33:57 * kergoth nods
Apr 12 18:34:13 <kergoth> at the moment i'm using it to stop the meta-oe bbappends which inheirt systemd from sucking systemd into my builds
Apr 12 18:34:16 <kergoth> heh
Apr 12 18:45:48 <fray> sakoman still working on it.. the bash entry is in the solver db.. but rpm is deciding it's not there..
Apr 12 18:55:09 <RP__> fray: progress on the fc13 issue, I reproduced on ubuntu 10.11. I updated the bug
Apr 12 18:58:45 <fray> ok.. so it's not just FC13 then
Apr 12 19:02:36 <RP__> fray: no, it seems ccache messes up the compiler search paths somehow
Apr 12 19:02:45 <fray> I think this might be a bug in RPM.. its only looking up the dependencies in the FILEPATHS cache, and not the overall dependency set
Apr 12 19:02:47 <fray> ugh
Apr 12 19:02:49 <RP__> fray: just need to figure out if its ccache or our compiler at fault
Apr 12 19:03:35 <RP__> fray: what worries me is that ccache has no knowledge of this path so it must be coming from some hidden corner in gcc
Apr 12 19:04:09 <fray> if --sysroot= isn't passed to gcc, I suspect it will return the original path set..
Apr 12 19:04:19 <fray> my guess is ccache doesn't know that --sysroot= is a critical variable..
Apr 12 19:04:34 <fray> in WR Linux we embed the --sysroot= into a wrapper, and ccache calls the wrapper (it doesn't even know that exists)
Apr 12 19:04:40 <fray> I suspect ccache is trying to be smart
Apr 12 19:06:19 <RP__> fray: --sysroot is passed through
Apr 12 19:06:54 <fray> but when ccache does it's magic does it pass it?  I assume ccache is trying to identify include paths and such from gcc so it's sure they haven't changed from one run to the other
Apr 12 19:07:35 <Crofton_> udhcpc is stupid
Apr 12 19:11:23 <fray> ok.. if I play with the values I can make this work.. now to figure out the real fix.. (and I still have no idea why busybox is working and bash not)
Apr 12 19:14:27 <RP__> fray: the exec call has the --sysroot option passed through
Apr 12 19:15:06 <RP__> fray: toolchains just failed again on the rebuild of rc3 :(
Apr 12 19:15:20 <fray> no idea then...
Apr 12 19:17:07 <fray> verified the bug appears to be present in the latest rpm5 as well.. drat
Apr 12 19:17:37 <fray> I think the real problem is that we're using a file name provide/require -- instead of a virtual one..
Apr 12 19:17:53 <fray> ther eis a check, if the thing starts w/ a "/" it assumes it's only a filename and just checks one location..
Apr 12 19:17:56 <fray> which is wrong
Apr 12 19:18:05 <fray> I need to figure out how to get it to check both
Apr 12 19:20:32 <fray> the normal command line lookup simply does a check of the dependency list, then falls through to the file list...
Apr 12 19:20:38 <fray> we're not doing the equivalent... Hmm
Apr 12 19:21:39 <fray> stupid python.. I'm forgetting how to program in C... ;)
Apr 12 19:25:53 <sakoman> fray: I really appreciate you working on that rpm issue!
Apr 12 19:26:02 <zeddii> fray is now half-dead to me
Apr 12 19:26:23 <fray> hey I'm slowly remembering how to write C..  reading isn't the problem
Apr 12 19:27:04 <RP__> fray: now getting somewhere. It happens when you supply preprocessed source
Apr 12 20:01:00 * fray is now compiling a slightly modified rpm5 to see if it'll resolve the issue
Apr 12 20:01:13 <fray> (I'm trying to force it to lookup the deps in both packages and file indexs
Apr 12 20:01:31 <RP__> fray: we have another small issue. We can't run preinsts before we install base-files
Apr 12 20:02:06 <RP__> since I have a suspicion that a preinst triggers the creation of /var/tmp
Apr 12 20:02:19 <RP__> fray: can we override the path rpm uses for /var/tmp ?
Apr 12 20:02:45 <fray> ya, the path is _tmpdir if I remember correctly..
Apr 12 20:02:48 <fray> why does that cause a problem?
Apr 12 20:03:02 <fray> is var/tmp a symlink?
Apr 12 20:03:35 <RP__> fray: yes
Apr 12 20:04:03 <RP__> fray: see the autobuilder for the fallout. There is actually really old code in there to handle a previous version of this issue dating all the way back to yum!
Apr 12 20:04:51 <fray> -D "_tmpdir /tmp" is likely what you want..  the key thing is to remember the specified dir is INSIDE of the chroot
Apr 12 20:05:01 <fray> ok.. I ahve a patch that deals w/ Steve's rootfs image problem..
Apr 12 20:05:58 <RP__> fray: great!
Apr 12 20:06:09 <RP__> fray: I might have a fix for the ab failures...
Apr 12 20:06:14 <fray> I really dislike this:
Apr 12 20:06:21 <fray> +-      rpmtag = (*keyp == '/' ? RPMTAG_FILEPATHS : RPMTAG_PROVIDENAME);
Apr 12 20:06:21 <fray> ++      rpmtag = RPMTAG_PROVIDENAME;
Apr 12 20:06:21 <fray> ++       do {
Apr 12 20:06:25 <fray> ... function ...
Apr 12 20:06:29 <fray> ++      if (bh == NULL && *keyp == '/' && rpmtag == RPMTAG_PROVIDENAME) {
Apr 12 20:06:30 <fray> ++         rpmtag = RPMTAG_FILEPATHS;
Apr 12 20:06:30 <fray> ++         continue;
Apr 12 20:06:30 <fray> ++        }
Apr 12 20:06:30 <fray> ++
Apr 12 20:06:30 <fray> ++        break;
Apr 12 20:06:30 <fray> ++      } while (1);
Apr 12 20:06:51 <fray> but I couldn't think of another way to match the behavior but simply add a RPMTAG_PROVIDENAME -and- RPMTAG_FILEPATHS step
Apr 12 20:07:21 <fray> (anyone has suggestions, I'm open to it..)  my headache is not helping me think
Apr 12 20:08:11 <RP__> fray: hmm, tricky :/
Apr 12 20:10:02 <fray> sakoman: (or anyone who cares) see the top commit on poky-contrib  mhatle/fixes branch
Apr 12 20:10:13 <fray> (that also has the pseudo RPATH fix in it)
Apr 12 20:10:23 <sakoman> fray: I will try it now
Apr 12 20:10:37 <fray> thanx..
Apr 12 20:10:50 <fray> (this is an oe-core repo BTW.. so if you are using poky, you'll have to cherry-pick)
Apr 12 20:19:43 <RP__> fray: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t2&id=b3ce5edb9b48b8e4813a0422eac3417ad997dcec is a no-brainer fix, right?
Apr 12 20:22:28 <fray> (looking)
Apr 12 20:22:42 <fray> yes, that should work fine
Apr 12 20:22:53 <fray> you'll want to put that anywhere that could be before the fbase-files
Apr 12 20:23:11 <fray> initial for sure.. but it might make sense to do it on the full install as well (it won't hurt)
Apr 12 20:23:24 <RP__> fray: thankfully they all use that function so it covers them all
Apr 12 20:23:36 <fray> yup, then we're good
Apr 12 20:23:48 <fray> (I thought it was _tmpdir.. but if you've verified it.. we're good)
Apr 12 20:24:50 <fray> (ugh.. one of my coworkers found what I think is a bug)
Apr 12 20:25:04 <fray> ...packages like coreutils don't "provide" /usr/bin/env, even though they can set an alternative for it
Apr 12 20:25:17 <fray> tar as well..
Apr 12 20:25:28 <fray> I tought the alternatives class set provides, but I'm not seeing it anywehere
Apr 12 20:27:14 <RP__> fray: hmm, we're we going to fix the alternatives class?
Apr 12 20:27:20 <RP__> we'ren't we
Apr 12 20:27:38 <fray> I thought we had fixed the class.. :(
Apr 12 20:27:40 * RP__ needs new fingers (typed as figures)
Apr 12 20:28:03 <fray> I wonder if I fixed it and lost the patch and forgot about it..
Apr 12 20:28:17 <fray> (busybox works as does bash.. but those are manually added provides)
Apr 12 20:28:24 <RP__> fray: would it be on contrib somewhere?
Apr 12 20:28:35 <fray> if I did it, no.. I've cleaned that up multiple times.. :(
Apr 12 20:28:46 <RP__> fray: :(
Apr 12 20:28:56 <RP__> fray: I don't remember seeing a patch for it, just the busybox workaround
Apr 12 20:29:08 <RP__> fray: file a bug on the issue while you remember?
Apr 12 20:29:33 <fray> I'll do that right now
Apr 12 20:29:40 <sakoman> fray: I ran into that /usr/bin/env issue a while back, did a quick hack because I had a customer deadline and then forgot about it :-(
Apr 12 20:29:47 <fray> I suspect busybox's "package_do_filedeps_append" would be a good model
Apr 12 20:29:49 <sakoman> http://www.sakoman.com/cgi-bin/gitweb.cgi?p=meta-sakoman.git;a=blob;f=recipes-core/coreutils/coreutils_8.14.bbappend;h=86ac8aee9f1e4500da24ed306aa3eb59b240647c;hb=HEAD
Apr 12 20:30:18 <fray> yup.. and with the RPM fix, adding an RPROVIDES will work as well.. :P
Apr 12 20:31:04 <sakoman> fray: I remeber trying RPROVIDES at the time and it didn't work
Apr 12 20:32:19 <fray> ya, thats due to the RPM bug you found.. ;)
Apr 12 20:32:36 <fray> I honestly have no idea why busybox worked...  as far as I can tell, it shouldn't have
Apr 12 20:32:53 <sakoman> yeah, we could have found it weeks ago if  not for pesky customer deadlines :-)
Apr 12 20:33:57 <fray> damned customers
Apr 12 20:34:16 * RP__ mutters about pesky release deadlines
Apr 12 20:34:21 <fray> RP  2289
Apr 12 20:34:41 <fray> I'll see what I can do about it in the update-alternatives.bbclass at least
Apr 12 20:34:57 <sakoman> RP:  I won't say anything about the number of packages that still break on rebuild . . .
Apr 12 20:35:08 <sakoman> oops, I guess I did
Apr 12 20:35:16 <RP__> fray: Can I assign it to you? :)
Apr 12 20:35:31 <RP__> sakoman: Those are on the "to fix before release" list
Apr 12 20:35:51 <RP__> sakoman: I was hoping we'd get some help with that but the patches aren't appearing as I'd like
Apr 12 20:36:05 <fray> yes you may
Apr 12 20:37:03 <fray> good lord.. I'm having problems reading package_do_filedeps_append
Apr 12 20:37:50 <fray> is package_do_filedeps_append a reasonable way to implement this in the update-alternates.bbclass?
Apr 12 20:39:21 <fray> ugh.. just noticed.. the package_do_filedeps always sets.. it doesn't ammend if a recipe trys to set the values manually
Apr 12 20:40:14 <fray> or way.. maybe it does..
Apr 12 20:40:19 <fray> my brain isn't working today
Apr 12 20:41:22 <Crofton_> hmm, an image I made from task-core-boot can't get an address from a dhcp server
Apr 12 20:41:39 <RP__> fray: I'd have to look at the code...
Apr 12 20:42:21 <fray> what I'd -like- to implement is:
Apr 12 20:42:37 <fray> FILERPROVIDES_<file>_<package> += "alternative"
Apr 12 20:42:45 <fray> in the recipe.. but the package.bbclass seems to always override it
Apr 12 20:43:51 <fray> I could probably add a couple of lines in package.bbclass that would load an existing value, and then join it to the new values, before storing it.. Hmm..
Apr 12 20:43:57 <fray> any way to easily remove duplicates?
Apr 12 20:44:12 <fray> (looking at lines 1202 and 1207)
Apr 12 20:46:29 <fray> ok.. wait now.. ALTERNATIVES_LINk is the only place "/bin/sh" shows up in the bash recipe.. and it's ending up as a provide in the package..
Apr 12 20:46:32 <fray> so how.. Hmm..
Apr 12 20:47:21 <fray> found it..
Apr 12 20:47:24 <fray> package_rpm.bbclass!
Apr 12 20:47:37 <fray> it's manually processing the ALTERNATIVE_LINK and ALTERNATIVES_LINKS values!
Apr 12 20:47:50 * fray updates 2289 with that info
Apr 12 20:49:03 <RP__> fray: ah, so we did add something :)
Apr 12 20:49:45 <fray> ok..  so post 1.3, we'll want to change this to work like the busybox.. but we don't need to now..
Apr 12 20:49:55 <fray> so let me look at coreutils.. does it NOT use the update-alternatives class?
Apr 12 20:50:34 <fray> bingo.. that is the exact problem..
Apr 12 20:50:39 <fray> class works, package is brokne!
Apr 12 20:51:28 <fray> ok.. should be a much safer fix then for 1.2
Apr 12 20:56:29 <fray> sakoman were you able to verify the image constructs?  I'd like to send this patch up
Apr 12 20:56:47 <sakoman> fray: building right now
Apr 12 20:56:55 <fray> ok..
Apr 12 20:56:56 <sakoman> should be done shortly
Apr 12 20:58:01 <fray> looks like 15 broken packages in oe-core...
Apr 12 20:58:24 <fray> When I fix these, I'll have to make a note to the other distros and meta-oe that they need to see if they have a similar problem
Apr 12 21:01:54 <sakoman> fray: what sort of breakage in those packages?
Apr 12 21:01:55 <fray> BTW I have to leave in an hour..
Apr 12 21:02:16 <fray> they won't provide the alternatives.. i.e. coreutils doesn't provide /usr/bin/env.. so fi something needs it, you'll get a missing dependency
Apr 12 21:02:30 <fray> sysvinit doesn't provide "wall"... that kidn of thing
Apr 12 21:02:31 <sakoman> ok, understood
Apr 12 21:02:48 <sakoman> jeeze, task do_rootfs is taking forever
Apr 12 21:03:01 <sakoman> I wonder what the heck it is doing!
Apr 12 21:03:24 <fray> coreutils has a list of all of the alternatives in a couple of internal variables..  I'll need to write something to translate those and shove them into the RPROVIDES automagically
Apr 12 21:03:38 <fray> the others look easier for the most part
Apr 12 21:03:55 <fray> (I wouldn't be surprised if the others could actually use update-alternatives the class)
Apr 12 21:05:12 <fray> could someone remind me of the difference between ${BPN} and ${PN}?
Apr 12 21:07:37 <incandescant> BPN doesn't include -native or other modifiers from a BBCLASSEXTEND
Apr 12 21:07:38 <sakoman> fray: the image build finally finished successfully
Apr 12 21:08:02 <sakoman> fray: so send the patch, I'll add my tested-by
Apr 12 21:08:10 <sakoman> fray: thanks!
Apr 12 21:08:32 <Crofton_> RP__, Do you mean to keep the Copyright (C) 2007 OpenedHand Ltd in some of the OE Core metadata?
Apr 12 21:08:34 <fray> incandescant interesting..  wonder how that works multilibs and alternatives
Apr 12 21:09:09 <RP__> Crofton_: Those probably need a s/OpenedHand/Intel/
Apr 12 21:09:31 <Crofton_> I do not care one way or another, I was just copying and editing from such a file
Apr 12 21:10:02 <fray> I'll get working on sending that and the pseudo one up
Apr 12 21:10:28 <RP__> fray: BPN avoids multilibs too
Apr 12 21:11:07 <fray> a few things are manually using BPN for setting up alternatives..
Apr 12 21:11:11 <fray> I suspect that is broken..
Apr 12 21:11:19 <fray> (the class uses PN though so it should be fine)
Apr 12 21:14:38 <RP__> fray: BPN should be fine, why is that an issue?
Apr 12 21:14:57 <RP__> fray: oh, I see
Apr 12 21:15:17 <RP__> hmm, that could be interesting
Apr 12 21:15:24 <fray> w/ multilibs you end up with two files of the same name..  (not a problem for RPM since it has a resolver code), but it may not actually be what someone wants..
Apr 12 21:15:35 <Crofton_> perf is unbuildable
Apr 12 21:15:42 <fray> plus it's inconsistent w/ ${PN} usage of the class
Apr 12 21:15:59 <fray> it looks to me like many of the things manually doing alternatives really should be using the class..
Apr 12 21:16:02 <Crofton_> I included task-core-tools-profile
Apr 12 21:16:54 <fray> sakoman / sgw / RP -- patches for pseudo and rpm sent
Apr 12 21:19:53 <RP__> fray: we are meant to be converting them
Apr 12 21:20:03 <RP__> fray: just one of the cleanups that hasn't happened yet
Apr 12 21:20:31 <fray> yup.. I'll do what I can tomorrow to get through the ones I identified..
Apr 12 21:20:58 <sakoman> fray: is the pseudo patch intended to fix my "run on arm" issue?
Apr 12 21:21:14 <sakoman> or is that something else?
Apr 12 21:21:42 <fray> for 1.3 though we really need to work on getting filepaths rolled up where possible, and also make alternatives work like busybox and load the per-file deps
Apr 12 21:22:06 <fray> sakoman no, pseudo was leaking in rpaths... this prevents that..
Apr 12 21:22:20 <fray> you should be able to use the pseudo_git, and the current head of pseudo tree to work on ARM
Apr 12 21:22:30 <fray> (pseudo_git hasn't been updated though to point ot head of tree)
Apr 12 21:23:07 <sakoman> I'll wait for the official update, I have a local patch that fixes it for arm
Apr 12 21:23:39 <fray> also on the post freeze list.. :)
Apr 12 21:23:41 <sakoman> I'll chuck that patch when I see the official srcrev update for pseudo
Apr 12 21:23:53 <ant__> zeddii: ping
Apr 12 21:52:59 <fray> anyone know, off hand, the smallest "reasonable" filesystem we can build w/ oe-core/yocto?  (i.e. small busybox based system)
Apr 12 21:53:04 <fray> something like 12 MB or so?
Apr 12 21:53:13 <fray> (accounting for eglibc and busybox)
Apr 12 21:54:24 <sgw> fray: as small as about 8M, I think that was our target for core-image-minimal, it might be around 9 or so now
Apr 12 21:55:24 <fray> Hmm.. I thought core-image-minimal was around 24 these days
Apr 12 21:55:35 <fray> I could very well be wrong, I can't say I've looked recently
Apr 12 21:56:58 <Crofton_> I have one here made from task-boot
Apr 12 21:57:10 <Crofton_> compressed it is 2.4M
Apr 12 21:57:30 <Crofton_> boots, bu udhcp is pissing me off
Apr 12 21:58:32 <fray> how big uncompressed?
Apr 12 21:59:01 <Crofton_> heh
Apr 12 21:59:06 <Crofton_> not sure
Apr 12 21:59:11 <fray> 6, 8, 12?
Apr 12 21:59:20 <Crofton_> I supposed you would like me to uncompress it
Apr 12 21:59:24 <fray> I know there is a lot of redudency..
Apr 12 21:59:29 <fray> if you can great, if not.. don't worry..
Apr 12 21:59:42 <fray> just trying to answer a question posed to me..
Apr 12 21:59:51 <fray> I told them I've seen less then 8 MB.. :)
Apr 12 22:00:51 <Crofton_> 5.4M
Apr 12 22:01:04 <Crofton_> I wasnt trying to amke it small
Apr 12 22:01:39 <Crofton_> now, anyone have advice sorting out udhcp
Apr 12 22:01:46 <fray> cool.. thanx
Apr 12 22:03:04 <fray> gotta go.. later
Apr 12 22:58:57 <sakoman> Crofton_: what is your udhcp issue?
Apr 12 22:59:13 <Crofton_> stupidity
Apr 12 22:59:33 <Crofton_> I was chaning the image and not removing the ramdisk from the kernel
Apr 12 22:59:43 <Crofton_> now I can't log in
Apr 12 23:00:41 <Crofton_> writing the image again, incase of more stupidity :)
Apr 12 23:01:52 <Crofton_> seems like I am having a shadow issue
Apr 12 23:02:06 <sakoman> I'm fighting with Samsung 16GB "extreme speed" microSD cards
Apr 12 23:02:22 <sakoman> they give timeout errors in Linux :-)
Apr 12 23:02:26 <Crofton_> urg
Apr 12 23:02:34 <sakoman> and yes, dto = 14
Apr 12 23:02:35 <Crofton_> even with max timeout
Apr 12 23:03:46 <sakoman> its quite strange they just seem to freeze up -- can't do a warm restart, need to power cycle them to get them working again
Apr 12 23:05:06 <sakoman> that explains the timeout
Apr 12 23:06:14 <Crofton_> so it is not really a timeout
Apr 12 23:06:18 <Crofton_> rather they crash
Apr 12 23:06:37 <sakoman> yeah, and then Linux mmc driver times out on the transaction
Apr 12 23:07:15 <sakoman> interesting -- using latest u-boot seems to fix the issue
Apr 12 23:07:28 <sakoman> now that is strange!
Apr 12 23:08:03 <Crofton_> different controller setup?
Apr 12 23:08:21 <sakoman> yeah, a bunch of mmc changes went in recently
Apr 12 23:09:16 <sakoman> the timeout happens when linux first mounts the mmc, so it could well be that u-boot leaves the mmc controller in a weird state that linux driver doesn't fix
Apr 12 23:09:51 <Crofton_> are they really extremely speedy?
Apr 13 00:10:02 <sakoman> Crofton_:  haven't tested speed yet
Apr 13 00:10:06 <sakoman> maybe tomorrow morning
Apr 13 00:10:17 <Crofton_> it sounds fast
Apr 13 00:10:28 <sakoman> marketing :-)
Apr 13 00:29:04 <Crofton_> sakoman,
Apr 13 00:29:05 <Crofton_> networking[965]: Sending select for 192.168.1.144...
Apr 13 00:29:05 <Crofton_> networking[965]: Received DHCP NAK
Apr 13 00:29:05 <Crofton_> networking[965]: Sending discover...
Apr 13 00:29:05 <Crofton_> networking[965]: Sending sele
Apr 13 00:29:07 <Crofton_> also
Apr 13 00:29:12 <Crofton_> securetty is not your friend
Apr 13 01:07:04 <CcSsNET> sakoman: i have an issue with super talent 32gb class 10 cards. i bought 2 new ones and both randomly remount read only in an openpandora.org handheld device. the only cards ive had good luck with are sandisk 16gb class 6, and pny 2gb class 4.
Apr 13 01:07:26 <CcSsNET> sd cards are volatile to begin with. but not all are the same quality
Apr 13 01:08:08 <CcSsNET> i guess the higher the class rating, it should be expected for it not to last as long
Apr 13 01:08:09 <CcSsNET> ;)
Apr 13 01:08:17 <CcSsNET> crazy technology... hehe
Apr 13 01:38:47 <bcochran> Hello.  Are there Intel embedded chipsets / development boards that are headless (no graphics unit, not just disabled)?  I went to an Intel presentation a few months back and the sales guy said there was nothing active, but I find that hard to believe.
Apr 13 01:39:41 <bcochran> Obviously, I'm thinking about Yocto on a headless Intel platform.
**** ENDING LOGGING AT Fri Apr 13 02:59:58 2012

**** BEGIN LOGGING AT Fri Apr 13 02:59:59 2012
Apr 13 04:04:47 <CcSsNET> bcochran: i was at ESC DesignCon East 2011, fairly sure they have _something_ check adverts from the event site
Apr 13 07:25:28 <snkt> hello I m building an Android OS 2.3 .... can I able to knew... how we can select our own apps.... while building Android FS?
Apr 13 09:35:12 <Zagor> RP__: do you have any suggestion/keyword how to find your posts about build threading? you post a lot... :-)
Apr 13 09:36:25 <RP__> Zagor: Good question.
Apr 13 09:38:02 <RP__> Zagor: I'd imagine "performance" is in the dubject
Apr 13 09:38:52 <RP__> Zagor: e.g. http://lists.linuxtogo.org/pipermail/openembedded-core/2011-September/010179.html
Apr 13 09:41:25 <Zagor> have you perhaps also done some build logging patch/option to log what tasks started/finished when and how much user/sys cpu they used?
Apr 13 09:41:40 <Zagor> my "ps xf" method is rather crude :)
Apr 13 09:41:43 <RP__> Zagor: look in your build in tmp/buildstats
Apr 13 09:43:12 <RP__> Zagor: ah, it looks like this might not be enabled by default. INHERIT += "buildstats"
Apr 13 09:43:21 <Zagor> aha
Apr 13 09:43:31 <RP__> It used to be the default...
Apr 13 09:43:42 <RP__> or perhaps I just always had it in local.conf :/
Apr 13 09:44:05 <RP__> Zagor: I also had a nice way of graphing this using a hacked up ubootchart
Apr 13 09:44:14 <bluelightning> it's funny, I thought it was on by default and then the other day I noticed it was off
Apr 13 09:44:55 <Zagor> RP__: is that chart hack available?
Apr 13 09:45:00 <bluelightning> ah right, USER_CLASSES... maybe I have an old config here
Apr 13 09:45:52 <RP__> Zagor: I did post it, I'm trying to find the emails
Apr 13 09:48:50 <RP__> Zagor: https://lists.yoctoproject.org/pipermail/poky/2011-February/003740.html
Apr 13 09:49:19 <RP__> Zagor: In return for me finding these pieces, could you write something on the Build_Performance wiki page with the links? :)
Apr 13 09:49:45 <Zagor> RP__: sure!
Apr 13 09:49:45 <mckoan> good morning
Apr 13 09:49:59 <RP__> Zagor: thanks :)
Apr 13 09:50:06 <RP__> hi mckoan
Apr 13 12:06:41 <Zagor> RP__: yay! I was just debugging that gcc sstate issue
Apr 13 12:07:13 <Zagor> at least I hope it's that issue :-)
Apr 13 12:18:25 <RP__> Zagor: It was a major pain to root cause. I don't think its done yet either as I still am seeing c++ issues
Apr 13 12:26:26 * RP__ hopes its the same fix just for c++ for .ii files
Apr 13 12:36:57 <RP__> Zagor: I'm curious whether it is the same issue...
Apr 13 12:37:18 <Zagor> it's not. I read (and spoke) too quickly.
Apr 13 12:37:49 <RP__> Zagor: hmm, so we potentially have another issue?
Apr 13 12:37:58 <Zagor> bad part: problem remains. good part: I still have a fun challenge ;)
Apr 13 12:38:05 <RP__> Zagor: you are passing --sysroot flags into the compiler?
Apr 13 12:38:56 <Zagor> no, I'm hunting for a strange "cached sstate not matching" issue. I misread it as relevant, but it's not.
Apr 13 12:39:26 <RP__> Zagor: ah, right. Those issues worry me less
Apr 13 12:42:54 <Zagor> they're quite annoying though, since they break what would otherwise be a 5-minute build
Apr 13 12:58:43 <Zagor> RP__: can I somehow get more detail about "Hash for dependent task X changed from Y to Z" ?
Apr 13 13:00:00 <RP__> Zagor: you need to examine that tasks sigdata/siginfo files
Apr 13 13:11:35 <Zagor> RP__: well, I do. all I see is that, indeed, the tasks have different hashes. but how do I find what actually changed?
Apr 13 13:12:03 <RP__> Zagor: compare the two sigdata files with the different hashes?
Apr 13 13:14:47 <Zagor> what I have is two sstate-linux-yocto-qemux86_64-poky-linux-3.2.11*package.tgz.siginfo. one cached from a previous build, and one build new. when I run bitbake-diffsigs against them it says "Hash for dependent task linux-yocto_3.2.bb.do_install changed from X to Y"
Apr 13 13:15:16 <Zagor> I don't get siginfo files for the tasks. or are they somewhere else?
Apr 13 13:22:38 <RP__> Zagor: look in tmp/stamps/
Apr 13 13:25:24 <Zagor> aha!
Apr 13 13:26:46 <Zagor> "Dependency on Variable PARALLEL_MAKE was removed"
Apr 13 13:26:53 <Zagor> should that really be included in the hash?
Apr 13 13:50:14 <RP__> Zagor: no, certainly not
Apr 13 14:02:03 <Zagor> RP__: can packages/tasks affect what is included in the hash? in this case linux-yocto_3.2.bb.do_compile_kernelmodule includes PARALLEL_MAKE, while tons of other tasks happily ignore it
Apr 13 14:04:24 <RP__> Zagor: hmm, that seems odd
Apr 13 14:24:01 <Zagor> RP__: might it be related to: ./meta/classes/kernel.bbclass:		oe_runmake ${PARALLEL_MAKE} modules  CC="${KERNEL_CC}" LD="${KERNEL_LD}"
Apr 13 14:35:24 <RP__> Zagor: in the other cases this gets applied by task override
Apr 13 14:35:41 <RP__> Zagor: I'm guessing bitbake doesn't account for the task overrides in the variable dependency scanning
Apr 13 14:36:56 <Zagor> I'm not familiar with what "task override" means
Apr 13 14:39:23 <RP__> Zagor: XXXX_task-compile = "yyy"
Apr 13 14:39:33 <Zagor> ok
Apr 13 14:40:28 <fray> morning
Apr 13 14:40:32 <RP__> Zagor: we should add PARALLEL_MAKE to BB_HASHBASE_WHITELIST
Apr 13 14:40:37 <RP__> morning fray
Apr 13 14:40:54 <RP__> fray: there is a bug I could use your input on, you were cc'd
Apr 13 14:41:05 <fray> ok.. loading up email now
Apr 13 14:41:10 <RP__> fray: related to mips tune changes I suspect
Apr 13 14:41:26 <fray> ok
Apr 13 14:41:35 <fray> was there ever a consensus to the mips vs mips32?
Apr 13 14:43:18 <RP__> fray: we never made a decision, no. That discussion slipped off my radar with the bug work :/
Apr 13 14:43:38 <fray> I understand..
Apr 13 14:44:06 <fray> RP__ re - 2074, I noticed in my strace logs that sometimes the spec file was being loaded other times it was looking in the original location.. I suspect that might be .i related as well
Apr 13 14:44:22 <fray> if it can't load the spec file, and the internal version doesn't have the %I.. it'll still fail.. I think
Apr 13 14:45:01 <fray> wow.. someone is spamming the wind river security alert list with a resume..
Apr 13 14:45:13 <fray> I think they get added to the never hire in a million years list
Apr 13 14:46:18 <RP__> fray: I've noticed the spec file issue in my builds too, it doesn't seem to break them though
Apr 13 14:46:33 <RP__> fray: we don't have a spec file on disk, just the internal values
Apr 13 14:47:00 <fray> ahh, ok.. then not a problem
Apr 13 14:47:20 <fray> it's been a while since i looked at the compiler at that level.. (that compiler did have a spec file)  ;)
Apr 13 14:48:18 <fray> RP__ fyi, I am investigating the mips / 2292 issue now..
Apr 13 14:48:49 <RP__> fray: ours probably can use them but we just use the internal values, at least the way we configure it. I'm therefore not worried about that path right now
Apr 13 14:49:10 <fray> sounds fine to me
Apr 13 14:49:10 <RP__> fray: thanks, you agree it looks suspicious after the mips change?
Apr 13 14:49:35 <fray> it does.. but I'm not sure why it matters..  the WR compilers we use are set to mips32 by default..
Apr 13 14:49:49 <fray> (we just don't manually pass the -march=mips32, it's set as the default in the compiler itself)
Apr 13 14:52:06 <fray> actually wait a second.. the rc2 kernel -was- using mips32r2.. while the rc3 kernel isn't?!  WTH
Apr 13 15:06:14 * fray lets his RSP build go, and looks at the alternatives thing some more
Apr 13 15:34:46 <khem> RP__: it does a stat on specs file though
Apr 13 15:35:19 <RP__> khem: right, but if its not there it just ignores that
Apr 13 15:35:34 <khem> yes
Apr 13 15:35:40 <khem> thats what I figured
Apr 13 15:38:02 <khem> compiling with integrated-cpp i.e. .c->.s and .c->.i->.s does have quite a few differences in process
Apr 13 15:38:57 <RP__> khem: yes, I don't like having ccache involved
Apr 13 15:39:33 <khem> RP__: building nativesdk packages for meta-toolchain for arm first and then x86 I see some of nativesdk packages being rebuilt
Apr 13 15:39:38 <RP__> khem: I couldn't really exactly figure out what gcc was going internally, that code for commandline options is scary and complex
Apr 13 15:39:39 <khem> I think that should not happen
Apr 13 15:39:51 <RP__> khem: correct, it shouldn't
Apr 13 15:40:25 <khem> RP__: sysroot is auxiliary and its included with hooks when needed
Apr 13 15:40:53 <khem> %I is the hook for spec file
Apr 13 15:41:10 <khem> if you see there is separate processing of paths when sysroot is wanted
Apr 13 15:41:44 <khem> I think sysroot should have been default but thats not the case
Apr 13 15:42:07 <khem> not many in gcc community cared for cross compilation back them
Apr 13 15:43:30 <khem> I think your fix should go in upstream gcc too
Apr 13 15:45:04 <RP__> khem: quite likely although I don't know if they'll like the fix or want to fix it differently
Apr 13 15:45:30 <RP__> khem: I've closed that bug, I think the specs issue warrants its own bug (different severity/priority)
Apr 13 15:47:04 <khem> makes sense
Apr 13 15:47:30 <khem> moreover if we are not hitting it then we should not worry too much
Apr 13 15:53:42 <halstead> sgw, Did you work out the stalled upload issue?
Apr 13 15:56:09 <sgw> halstead: mostly, I have a slow modem, but paying for "fast" service, I can get a faster modem!
Apr 13 15:59:40 <halstead> sgw, I hope that solves it. I wondered if there was a large buffer somewhere between you and the Internet since you were seeing stalled and I was seeing traffic as expected.
Apr 13 16:00:55 <fray> RP__ after basic investigation, I'm very skeptical the tuning had anything to do with the rsp kernel
Apr 13 16:01:07 <fray> I see none of the tune elements being used during compliation of the kernel..
Apr 13 16:01:15 <fray> I'm going to back off prior to my change.. re verify that..
Apr 13 16:01:40 <RP__> fray: hmm, ok. So how did it break? :/
Apr 13 16:01:49 <fray> dunno.. I suspect a compiler or kernel change
Apr 13 16:02:50 <zeddii> there's been no kernel changes.
Apr 13 16:03:01 <zeddii> but I'm still waiting to hear when they did the last good boot.
Apr 13 16:03:48 <fray> I suspect it may have been a M2..
Apr 13 16:03:56 <fray> there were a lot fo changes in the middle
Apr 13 16:04:53 <zeddii> not many for the kernel, only -stable updates. routerstation is back on 3.0 .. hence nearly not touched. I'll wait to hear from the QA guys.
Apr 13 16:07:07 <fray> ok.. I have reverted the tuning changes locally.. everything else is curent.. and I'll check the kernel again
Apr 13 16:16:04 <Crofton_> davest, Bill does have a much better title than you
Apr 13 16:16:48 <davest> Crofton_: indeed. I sometimes invent new titles for myself when I get my business card translated.
Apr 13 16:23:35 <fray> does anyone know why in coreutils  "df" and "mktemp" aren't in the regular lists?  I see a comment why '[' isn't
Apr 13 16:25:57 <fray> looks like hostname and uptime are also in the list.. Hmm
Apr 13 16:59:49 <fray> if anyone else wants to verify the rsp before and after the tune changes, I can give you the commits to revert
Apr 13 17:02:11 <khem> fray: what are we looking at ?
Apr 13 17:02:14 <zeddii> yshi is having a look. since we'll be Monday before I hear from the reporters. Normal debug shall ensue from this point.
Apr 13 17:02:34 * khem is missing context
Apr 13 17:04:14 <fray> routerstationpro kernel is no longer booting..
Apr 13 17:04:25 <fray> it's unclear the last time it was tested, initial debug pointed that it may be tune related..
Apr 13 17:04:26 <khem> ugh
Apr 13 17:04:31 <fray> but it's not related to my patches at least..
Apr 13 17:04:41 <fray> yocto project bug 2292
Apr 13 17:04:45 <khem> what is the last snapshot when it booted
Apr 13 17:04:59 <fray> m2 for sure.. beyond that, not sure
Apr 13 17:05:13 <khem> should be simple to verify. Use 4.5 toolchain and see if that boots it
Apr 13 17:05:18 <fray> the initial debug points out the load address and optimizations have changes.. it used to be tagged as mips32r2.. now it's tagged mips3
Apr 13 17:05:25 <khem> then we can see there is some compiler interaction issue
Apr 13 17:05:33 <khem> otherwise its a kernel problem
Apr 13 17:05:52 <khem> hmm
Apr 13 17:06:01 <khem> Did compiler cmdline change ?
Apr 13 17:06:24 <khem> -mtune -mcpu ?
Apr 13 17:07:20 <zeddii> shouldn't. that error is so early that the ELF looks to just be junk.
Apr 13 17:12:05 <khem> oh
Apr 13 17:12:37 <khem> I would also consider any post processing tools that get involved after linker links the kernel
Apr 13 17:23:31 <fray> Ugh.. I think the alternatives class might have a slight bug.. the following leaked into the coreutils rpm:
Apr 13 17:23:32 <fray>  /usr/bin/${ALTERNATIVE_NAME}
Apr 13 17:26:24 <kergoth> heh, oops
Apr 13 17:26:31 <kergoth> that's rather amusing
Apr 13 17:27:06 <fray> it's cause alternative_link is hard coded, even if ALTERNATIVE_NAME wasn't set
Apr 13 17:28:45 <fray> ALTERNATIVE_LINK = "${@[d.getVar('bindir', True) + '/' + d.getVar('ALTERNATIVE_NAME', True), ''][d.getVar('ALTERNATIVE_NAME', True) != '']}"
Apr 13 17:28:51 <fray> that should work right?
Apr 13 17:29:02 <fray> it's blank if ALTNERATIVENAME isn't set, otherwise it gets bindir/alternative_name
Apr 13 17:31:22 <kergoth> ${@['${bindir}/${ALTERNATIVE_NAME}', ''][d.getVar('ALTERNATIVE_NAME', True)]} should do as wel
Apr 13 17:31:46 <fray> Hmm.. that didn't work when I tried it before.. wonder if I had a missing brace
Apr 13 17:31:49 <fray> will try again
Apr 13 17:31:59 <kergoth> erm, would have to swap the beginning bit to do it that way, or do 'not d.getVar'
Apr 13 17:32:08 <kergoth> but you get the point :)
Apr 13 17:32:48 <fray> ohh ya, this works because it doesn't need to be immediately expanded..
Apr 13 17:32:51 <kergoth> oh, doh, i forgot about that behavior.. iirc you can get that weird ass error about something being unterminated if you use ${} of an unset variable inside of ${@}
Apr 13 17:33:11 <fray> Hmm..
Apr 13 17:33:14 <kergoth> i always forget that the xpansion code expands the ${}'s inside of ${@} right away, rather than leaving it as is
Apr 13 17:33:20 <kergoth> iirc, anyway :)
Apr 13 17:33:26 <kergoth> but yeah, your original one would work fine too
Apr 13 17:33:33 <fray> Failure expanding variable ALTERNATIVE_LINK, expression was ${@['/usr/bin/which'][d.getVar('ALTERNATIVE_NAME', True)]} which triggered exception TypeError: list indices must be integers, not str
Apr 13 17:33:59 <kergoth> ah, right
Apr 13 17:34:03 <fray> anyway to prevent the expansion?
Apr 13 17:34:11 <kergoth> bool(d.getVar()) would do, but isn't any prettier than what you had originally
Apr 13 17:34:21 <kergoth> was hoping to avoid all that ugly inline python, but guess we're probably stuck with it :)
Apr 13 17:34:39 <kergoth> oh, fyi, python 2.6+, which we require, supports an inline if statement as an alternative to [][]
Apr 13 17:34:47 <kergoth> ${@'foo' if 'bar' else 'baz'}
Apr 13 17:34:58 <kergoth> worth knowing about, though i'm not sure if that's any clearer :)
Apr 13 17:35:49 <fray> ERROR: Failure expanding variable ALTERNATIVE_LINK, expression was ${@['/usr/bin/${ALTERNATIVE_NAME}'][d.getVar('ALTERNATIVE_NAME', True) == ""]} which triggered exception SyntaxError: EOL while scanning string literal (ALTERNATIVE_LINK, line 1)
Apr 13 17:36:01 <fray> ya.. how do I get it to try to not expand the original ${ALTERNATIVE_NAME}?
Apr 13 17:36:16 <fray> just have to use the d.getVar?
Apr 13 17:36:56 <kergoth> either that or define an empty value instead of unset
Apr 13 17:37:02 <kergoth> ALTERNATIVE_NAME ??= ''
Apr 13 17:37:04 <kergoth> or whatever
Apr 13 17:37:26 <fray> there are other checks to see if alternative_name is empty of not..
Apr 13 17:37:27 <fray> Hmm
Apr 13 17:37:31 <kergoth> that EOL while scanning thing is the worst, most unintuitive response to that i could imagine
Apr 13 17:37:45 <kergoth> any 'if alternative_name:' orsimilar will behave the same whether its None or ''
Apr 13 17:38:10 <kergoth> definitely worth considering as a potential problem, of course. your call :)
Apr 13 17:38:36 <fray> RP -- I think update-alternatives is broken for multilibs:
Apr 13 17:38:40 <fray> update_alternatives_batch_doinstall() {
Apr 13 17:38:40 <fray> if [ "${PN}" = "${BPN}" ] ; then
Apr 13 17:38:40 <fray>         for link in ${ALTERNATIVE_LINKS}
Apr 13 17:38:40 <fray>         do
Apr 13 17:38:40 <fray>                 mv ${D}${link} ${D}${link}.${PN}
Apr 13 17:38:41 <fray>         done
Apr 13 17:38:41 <fray> fi
Apr 13 17:38:42 <fray> }
Apr 13 17:38:45 <fray> crap
Apr 13 17:40:26 * fray thinks one bug at a time....
Apr 13 17:40:35 <kergoth> hehe
Apr 13 17:41:54 <khem> unfs-server-nativesdk starts to rebuild for x86 whereas its already in sstate that it should have reused
Apr 13 17:42:05 <fray> ok.. this is what I ended up with:
Apr 13 17:42:05 <fray> ALTERNATIVE_LINK = "${@['${bindir}/' + (d.getVar('ALTERNATIVE_NAME') or ""), ''][d.getVar('ALTERNATIVE_NAME') != None]}"
Apr 13 17:42:14 <khem> bitbake-diffsigs is my friend I guess
Apr 13 17:42:24 <fray> anything else and I get an error of some kind
Apr 13 17:44:25 <khem> even with what kergoth suggested ?
Apr 13 17:45:23 <fray> I couldn't find an alternative that didn't fail..
Apr 13 17:45:31 <fray> if I put in ${ALTERNATIVE_NAME} and it wasn't set.. it blew..
Apr 13 17:45:41 <fray> I didn't try the if.. since that doesn't match the format of other parts of the code..
Apr 13 17:56:17 <kergoth> hmm, anyone else tried building for mips64 before? hitting some compile failures
Apr 13 17:56:17 <kergoth> hrm
Apr 13 17:56:31 <fray> nope, OE compiler doesn't support it
Apr 13 17:56:42 <fray> completely untested
Apr 13 17:56:55 <fray> (I think zedd probably tested building the kernel, but thats it)
Apr 13 17:58:18 <kergoth> k, figured
Apr 13 17:58:25 * kergoth kicks xserver-xorg
Apr 13 18:02:59 <Crofton_> I feel like this test is fialing when SERIAL_CONSOLE is set i the machine file
Apr 13 18:03:01 <Crofton_>         if [ ! -z "${SERIAL_CONSOLE}" ]; then
Apr 13 18:03:22 <Crofton_> why wouldn't you use
Apr 13 18:03:43 <Crofton_> if [ -n "${SERIAL_CONSOLE}" ];?
Apr 13 18:03:50 <kergoth> there's nothing wrong with ! -z
Apr 13 18:03:55 <kergoth> it'll have the same ffect as -n
Apr 13 18:03:57 <Crofton_> sure
Apr 13 18:04:11 <Crofton_> that was just me wondering why the double negative :)
Apr 13 18:04:31 <Crofton_> basically, I ahve a machine with a "new" serial console
Apr 13 18:04:35 <kergoth> doesn't read as a double negative to me. 'is this not empty'
Apr 13 18:04:55 <Crofton_> and the code in shadow-securetty does not add it to securetty
Apr 13 18:05:40 <Crofton_> I checked the echo to extract coneole from SERIAL_CONSOLE and it looks ok
Apr 13 18:06:54 <Crofton_> given that people keep adding their special consoles to the securetty file, makes me think something is broken
Apr 13 18:07:35 <fray> is shadow-securetty a seperate binary or is it a split package?
Apr 13 18:07:52 <fray> if it's a seperate recipe, this it should be paying attention to the machine config.. if not.. then that is likely the problem
Apr 13 18:07:58 <fray> that file is machine/configurate specific
Apr 13 18:09:00 <Crofton_> it is a seperate recipe
Apr 13 18:09:47 <Crofton_> I can't see what is wrong with it, I just know it fails
Apr 13 18:09:59 <Crofton_> and I suspect not many people actually test this case :)
Apr 13 18:10:37 <Crofton_> and since "quality is job 1" for oe-core, i thought I should be annoying :)
Apr 13 18:12:41 * Crofton_ wonders why task-core-basic includes rpm
Apr 13 18:13:32 <khem> hmmm interesting Hash for dependent task virtual:nativesdkunfs-server_2.1+2.2beta47.bb.do_install changed from c8c03b57749fd764e0278a1320c9a0e3 to d3ce52dad51d55e8967a6cb912eab420
Apr 13 18:14:04 <khem> how do I compare task sigs
Apr 13 18:23:39 <fray> ugh, stupid arm
Apr 13 18:25:13 <fray> pkg_postinst_${PN} () {
Apr 13 18:25:14 <fray>         # Special cases. uptime and hostname is broken, prefer busybox's version. [ needs to be treated separately.
Apr 13 18:25:14 <fray>         update-alternatives --install ${bindir}/uptime uptime uptime.${PN} 10
Apr 13 18:25:14 <fray>         update-alternatives --install ${base_bindir}/hostname hostname hostname.${PN} 10
Apr 13 18:25:24 <fray> wouldn't that suggest that uptime and hostname be -removed- since it's broken?1
Apr 13 18:28:06 <fray> how do I force a specific version of a package to build?
Apr 13 18:52:11 <khem> fray: bitbake -b <recipe>.bb
Apr 13 19:49:52 <khem> oh now I see the problem with difference signatures
Apr 13 19:50:14 <khem> hmm I have LDISGOLD variable which are override based on ARCH
Apr 13 19:52:30 <khem> hmm and that gets into eglibc-nativesdk and gcc-crossdk inturn
Apr 13 19:52:36 <khem> and so on so forth
Apr 13 21:07:39 <RP__> fray: I'm really not sure I want to try an unravel that mess for 1.2 at this point
Apr 13 21:08:06 <fray> which mess?  ;)
Apr 13 21:08:09 <fray> alternatives?
Apr 13 21:08:17 <fray> I'm already unraveling it to fix the missing coreutils and such..
Apr 13 21:08:27 <fray> I'll leave it up to you if any or all of the patches can be merged..
Apr 13 21:08:32 <fray> (I'm not fixing the multilib though)
Apr 13 21:08:37 <fray> thats way beyond my ability to test
Apr 13 21:09:25 <fray> (more or less, I'm adding a function to update-alternatives.bbclass to see the per-file provides.. and then anything that manually adds links has to do MANUAL_ALTERNATIVE_LINKS = "<target>[:<source>]"
Apr 13 21:09:50 <fray> i.e. ${bindir}/[:${bindir}/lbracket.coreutils
Apr 13 21:10:28 <fray> (if source isn't specified, it's assumed to be target.${pn}
Apr 13 21:11:34 <RP__> fray: ok, I'll make the final call based on patches. I'm just saying I'm getting worried at this point
Apr 13 21:11:43 <fray> ya, i understand
Apr 13 21:11:53 <RP__> particularly as patches coming in don't appear to be getting well tested and the build is broken
Apr 13 21:12:11 * mranostay yawns
Apr 13 21:12:29 <fray> (thats what is taking so long with these patches.. the testing sucks.. have to test deb adn ipk as well to make sure nothing accidently breaks)
Apr 13 21:13:16 <fray> but I do understand, at some point you cut off the patches and delay them..
Apr 13 21:13:42 <fray> only ones I'm tracking at the mips vs mips32..  (on the background until I'm told to do something)
Apr 13 21:13:46 <fray> and this alternatives one...
Apr 13 21:52:35 <fray> ha.. update-alternatives doesn't work on sub packages either..  (again, not fixing that now)
**** ENDING LOGGING AT Sat Apr 14 02:59:58 2012

**** BEGIN LOGGING AT Sat Apr 14 02:59:58 2012
Apr 14 12:31:35 <RP__> fray: I just hope you're keeping good notes of the things we need to fix
Apr 14 12:31:49 * RP__ fires off the autobuilder again
**** ENDING LOGGING AT Sun Apr 15 02:59:59 2012

**** BEGIN LOGGING AT Sun Apr 15 03:00:00 2012
Apr 15 14:40:32 <guyvdb_> I am trying to build core-image-minimal for the first time in oe-core. I am on the master branch of git://git.openembedded.org/openembedded-core.  I get a download error for git://git.yoctoproject.org/linux-yocto-3.2;protocol=git;bareclone=1;branch=standard/default/common-pc/base,meta;name=machine,meta. Any ideas?
Apr 15 23:33:08 <JDuke128> hello , can i use yocto project on gumstix boards ?
Apr 16 00:36:01 <mranostay> heh
**** ENDING LOGGING AT Mon Apr 16 02:59:58 2012

**** BEGIN LOGGING AT Mon Apr 16 02:59:59 2012
Apr 16 07:23:28 <mckoan> good morning
Apr 16 08:33:12 <RP__> morning all
Apr 16 08:34:33 <dongxiao1> RP__: morning
Apr 16 08:34:39 <dongxiao1> RP__: ping
Apr 16 12:01:04 <RP__> dongxiao1: sorry, missed the message in here :(
Apr 16 12:12:41 <dongxiao1> RP__: are you still around?
Apr 16 12:12:46 <Zagor> RP__: did you want me to file a patch adding PARALLEL_MAKE to BB_HASHBASE_WHITELIST?
Apr 16 12:12:50 <RP__> dongxiao1: yes
Apr 16 12:12:58 <RP__> Zagor: yes please
Apr 16 12:13:09 <RP__> Zagor: or I can do it but it would be a good thing to fix
Apr 16 12:13:46 <Zagor> yeah I figured perhaps for such a small change the patch management overhead is overkill
Apr 16 12:13:59 <dongxiao1> RP__: About the BBINCLUDED, do we just fix the order of BBINCLUDED? Or we also need to fix __depends and __base_depends?
Apr 16 12:14:07 <Zagor> RP__: I can send one if you prefer it that way
Apr 16 12:14:37 <RP__> Zagor: I'll still have to send the patch to the list for review but I can take care of it
Apr 16 12:14:51 <RP__> dongxiao1: I think we should fix __depends and __base_depends
Apr 16 12:14:52 <Zagor> RP__: ok, thanks
Apr 16 12:16:55 <dongxiao1> RP__: So the idea is, while setting values to __depends,  __base_depends, and BBINCLUDED, we need to sort them, right?
Apr 16 12:19:19 <RP__> Zagor: posted it for review
Apr 16 12:19:33 <RP__> dongxiao1: we need to retain order, yes
Apr 16 12:20:26 <RP__> dongxiao1: previously the two uses of those variables were to tell if something had already been included and whether the timestamps of files had changed, neither of which is order significant
Apr 16 15:00:52 <fray> morning
Apr 16 15:01:41 <RP__> hi fray
Apr 16 15:02:15 <RP__> fray: I ended up fixing some of the update-alternatives multilib issues since there was an open 1.2 bug related to it
Apr 16 15:07:59 <fray> Ahh ok..  I have local changes for related items (but not multilibs..)  I'll sync up and hopefully submit today..
Apr 16 15:08:05 <fray> (again, if it doesn't get accepted, I can live w/ that)  ;)
Apr 16 15:08:32 <fray> I'm 50% of the way through the list of packages I found that were not using update alternatives.. most, but not all could have.. so those were easy fixes..
Apr 16 15:08:51 <fray> but update alternatives (post 1.2) needs to be fixed to work with split packages, like useradd does..
Apr 16 15:08:58 <fray> then they can all of it except for maybe coreutils
Apr 16 15:17:14 <fray> cool.. may update-alternatives and yours didn't clash at all
Apr 16 15:48:42 <RP__> fray: cool, I tried to keep my change simple :)
Apr 16 15:49:19 <fray> yup..
Apr 16 15:57:00 <kergoth> should libsndfile1 be supporting alsa or no? right now we pass --disable-external-libs, but that only disables flac, vorbis, etc, not alsa. either it needs to depend on alsa-lib, or it needs --disable-alsa also
Apr 16 15:57:14 <kergoth> just had it choke and die due to having libasound on my build machine
Apr 16 15:57:30 <fray> I thought alsa was a distro flag...
Apr 16 15:57:41 <fray> (or am I remembering wrong?)
Apr 16 15:57:46 <kergoth> good point, should probably be another PACKAGECONFIG
Apr 16 16:08:58 <fray> RP I think the gzip package is moving files around only if it's not being used as a "native".  using ${PN} = ${BPN} as the check.  this isn't multilib safe right?  Is there an alternative?
Apr 16 16:09:35 <fray> Hmm.. only one of the two versions of gzip is going that.. odd
Apr 16 16:12:56 <fray> pigz is doing the same thing...
Apr 16 16:14:06 <kergoth> https://github.com/kergoth/oe-core/commit/42af43c might be of use
Apr 16 16:15:01 <fray> ya..  it would be nice to know if something is running as a target or !
Apr 16 16:15:11 <fray> do_install () {
Apr 16 16:15:11 <fray>         if [ "${PN}" = "${BPN}" ] ; then
Apr 16 16:15:14 <fray> that is just a bad test
Apr 16 16:38:13 <RP__> fray: agreed. I think khem has a proposal for some overrides in 1.3 which might make this easier
Apr 16 17:07:17 <dvhart> fray, ping - have you seen the libzypp failure on the AB this morning?
Apr 16 17:07:26 <dvhart> fray, mail in your inbox re http://autobuilder.yoctoproject.org:8010/builders/nightly-x86-64/builds/387/steps/shell_62/logs/stdio
Apr 16 17:07:28 <fray> no.. have a pointer, I'll look
Apr 16 17:07:46 <dvhart> thanks!
Apr 16 17:08:16 <kergoth> so.. SUMMARY_${PN}-dev references SUMMARY, set package_write_ipk adds the pkgname to overrides and finalizes, making it self referential. am I missing something here?
Apr 16 17:08:21 <kergoth> s/set/yet/
Apr 16 17:10:10 <fray> it litterly looks like a glitch..
Apr 16 17:10:35 <fray> | make[2]: *** No rule to make target `/srv/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86-64/build/build/tmp/sysroots/qemux86-64/usr/include/proxy.h', needed by `zypp/CMakeFiles/zypp.dir/media/MediaCurl.cc.o'.  Stop.
Apr 16 17:10:49 <fray> that tells me it was going to use curl, but usr/include/proxy.h wasn't there..
Apr 16 17:10:53 <fray> has someone changed curl recently?
Apr 16 17:11:06 <dvhart> maybe a missing dependency?
Apr 16 17:11:09 <fray> either that, or curl was being installed while it was trying to use it?
Apr 16 17:11:12 <fray> could be
Apr 16 17:11:41 <fray> curl is a DEPENDS of libzypp
Apr 16 17:11:43 <dvhart> curl hasn't changes since Mar 14
Apr 16 17:12:54 <fray> well pkg-write of curl is occuring after that (but that should be ok)
Apr 16 17:14:47 <dvhart> we should just need populate_sysroot right?
Apr 16 17:14:54 <fray> yes..
Apr 16 17:15:02 <fray> I see it there, and it does appear to have been run prior to libzypp..
Apr 16 17:15:07 <fray> but the header seems to not be there?
Apr 16 17:15:18 <fray> is the path referenced above the -right- path for this autobuilder session?
Apr 16 17:15:36 <dvhart> yes
Apr 16 17:15:53 <fray> then no idea... if possible inspecting the build filesystem/sysroot would be useful..
Apr 16 17:16:09 <dvhart> fray, ok, I'll open a bug
Apr 16 17:16:17 <fray> either the check for the file glitched, the file never was written (or was written after the check) or the package is broken for some reason
Apr 16 17:16:26 <fray> thats all I can think of.. but it doesn't look libzypp related
Apr 16 17:16:35 * dvhart nods, thanks fray
Apr 16 17:58:38 <guyvdb_> Hi, I am trying to get started on oe-core. There meta dir has a recipe that point to linux-yocto-3.2 in the yocto git repos. I have not been able to fetch it for a few days now. Could the oe recipe be wrong or might there be a problem with the yocto git repos?
Apr 16 17:59:52 <otavio> docbook-utils-native has re-execution of tasks bugs too
Apr 16 18:00:00 <fray> do you have any proxies or anything you need to go through?
Apr 16 18:00:14 <fray> I fetched linux-yocto-3.2 on Friday and it worked fine.. (havent had to today)
Apr 16 18:00:23 <bluelightning> otavio: yes, Richard has sent a fix for that one already
Apr 16 18:00:36 <otavio> bluelightning: oh cool
Apr 16 18:00:37 <guyvdb_> No proxies. I have not been able to get it for about 3 days
Apr 16 18:00:45 <otavio> bluelightning: it failed in my autobuilder ;)
Apr 16 18:01:00 <bluelightning> otavio: ok... the patch has not yet been merged afaik
Apr 16 18:01:11 <otavio> bluelightning: np
Apr 16 18:01:12 <fray> [lmhatle@msp-lpggp1 git]$ git clone git://git.yoctoproject.org/linux-yocto-3.2
Apr 16 18:01:12 <fray> Initialized empty Git repository in /msp-lpggp1/mhatle/git/linux-yocto-3.2/.git/
Apr 16 18:01:14 <fray> remote: Counting objects: 294855
Apr 16 18:01:17 <fray> it's working here
Apr 16 18:01:48 <bluelightning> guyvdb_: if you try a git clone as above does it work, or fail as well?
Apr 16 18:01:57 <fray> what URL are you using?
Apr 16 18:02:01 <guyvdb_> one min checking
Apr 16 18:03:18 <guyvdb_> hmm yea it is cloning from git://git.yoctoproject.org/linux-yocto-3.2 . Will pastie the output of the recipe that is failing to fetch it
Apr 16 18:03:47 <fray> try cloning it outside of the build system first
Apr 16 18:03:57 <fray> see if it starts working.. if it does it's not a connection issue but something else
Apr 16 18:04:09 <guyvdb_> the url is :git://git.yoctoproject.org/linux-yocto-3.2;protocol=git;bareclone=1;branch=standard/default/common-pc-64/base,meta;name=machine,meta
Apr 16 18:04:31 <guyvdb_> log output is http://pastie.org/3799496
Apr 16 18:05:18 <guyvdb_> command that is failing is :       git remote add --mirror=fetch origin git://git.yoctoproject.org/linux-yocto-3.2
Apr 16 18:05:20 <fray> while I'm looking at pastebin.. see if you can pull it down on your own.. (if it gets to receiving objects.. you can kill it)
Apr 16 18:05:48 <guyvdb_> yea i did pull a git clone git://git.yoctoproject.org/linux-yocto-3.2 which started getting objects
Apr 16 18:06:16 <fray> Something with the fetcher or mirror stuff.. Hmm
Apr 16 18:07:07 <fray> I don't know.. maybe RP or Zedd might have an idea then..
Apr 16 18:07:13 <fray> it sure seems to be fetcher related..
Apr 16 18:07:16 <guyvdb_> how can i do it manually and cache it in my download folder so the script does not try
Apr 16 18:07:38 <fray> I'm not sure.. I normally let te build system do the fetch to cache it..
Apr 16 18:07:52 <guyvdb_> yea... me too
Apr 16 18:08:27 <guyvdb_> this recipe comes from the oe-core meta dir ... i assume that is a common piece between oe and yocto
Apr 16 18:09:03 <fray> try: PREMIRRORS += "\
Apr 16 18:09:27 <guyvdb_> where would i set that?
Apr 16 18:09:32 <khem> yes. it is however mirror settings are different with oe-core and yocto
Apr 16 18:09:35 <fray> git://git.yoctoproject.org/linux-yocto-3.2  file://<path to your download>/ \n"
Apr 16 18:10:31 <guyvdb_> would file://<path to download> be the location where I did a git clone git://git.yoctoproject.org/linux-yocto-3.2 ?
Apr 16 18:11:44 <fray> yes..
Apr 16 18:12:02 <fray> lets assume you did /home/guyvdb_/git/linux-yocto-3.2
Apr 16 18:12:10 <fray> file:///home/guyvdb_/git/linux-yocto-3.2/
Apr 16 18:12:14 <fray> is what youwould use..
Apr 16 18:12:23 <fray> (note the three "/" and the final "/")
Apr 16 18:12:46 <fray> BTW this is a guess, I haven't done this in a while.. so I might be wrong..
Apr 16 18:12:49 <guyvdb_> k and where should PREMIRRORS be added to (defined)...
Apr 16 18:12:59 <fray> you can do it in your local.conf
Apr 16 18:13:06 <guyvdb_> ok
Apr 16 18:13:28 <fray> I use premirrors a lot.. but it's usually pointing to local mirros.. I don't normally do it like this
Apr 16 18:13:32 <fray> (but I know it can be done)
Apr 16 18:13:40 <guyvdb_> let me try but I must first clone linux-yocto which might take a while on my slow connection
Apr 16 18:14:05 <guyvdb_> But it sound reasonable that it would work to me
Apr 16 18:15:04 <dvhart> note you need a "mirror", not just a clone, of linux-yocto-3.2 if you want to use a local repo
Apr 16 18:15:06 <fray> ya.. it's a big repo to clone
Apr 16 18:15:19 <fray> dvhart, ahh I thought a clone could be enough
Apr 16 18:15:59 <guyvdb_> ok thanks for the heads up dvhart
Apr 16 18:16:26 <dvhart> fray, guyvdb_ we need all the branches to be local, and you get that with mirror
Apr 16 18:16:39 <dvhart> what I suggest doing is mirroring the entire thing to a bare repository
Apr 16 18:16:45 <dvhart> use that for the builds
Apr 16 18:16:56 <dvhart> when you want to modify something, clone from your local mirror
Apr 16 18:17:05 <dvhart> then push back to it at the right branch
Apr 16 18:18:07 <dvhart> linux-yocto-3.2 is "special"
Apr 16 18:18:11 <dvhart> :)
Apr 16 18:18:38 <guyvdb_> :)
Apr 16 18:19:48 <guyvdb_> I was chatting in #oe with khem and he says he did a  bitbake -ccleanall virtual/kernel;bitbake -cfetch virtual/kernel   and it fetched ok so I am trying again
Apr 16 18:21:22 <kergoth> Hmm, odd, getting some locale packages in PACKAGES twice but only when using 'precompiled' locales. 'ondevice' doesn't see the behavior
Apr 16 18:21:33 * kergoth wades into libc-package.bbclass
Apr 16 18:21:45 <dvhart> kergoth, be careful in there ;-)
Apr 16 18:21:58 <kergoth> heh
Apr 16 18:22:06 <kergoth> trying to get eglibc-locale + external-csl-toolchain happy
Apr 16 18:23:54 <guyvdb_> hmm it seems to be fetching correctly now. I think the bitbake -c cleanall sorted it
Apr 16 18:24:19 <fray> ahh.. repo probably went nuts and git couldn't correct it..
Apr 16 18:24:32 <fray> that hapepend to me last week on a non-yocto repository.. took me a while to figure out what was wrong too
Apr 16 18:24:42 <guyvdb_> Thanks for the help all
Apr 16 18:25:01 <dvhart> guyvdb_, you fetched the entire thing already?
Apr 16 18:25:10 <dvhart> if so... that's not a slow connection!
Apr 16 18:25:40 <kergoth> so, where are the docs on using the linux-yocto branch/meta management tools?
Apr 16 18:25:52 <kergoth> the kernel doc didn't cover them at all, i was pretty surprised
Apr 16 18:28:02 <guyvdb_> No... but it is now fetching... which it was not doing before
Apr 16 18:28:31 <guyvdb_> I mean from the bitbake -c fetch command
Apr 16 18:29:08 <guyvdb_> be back later.. thx for help
Apr 16 18:33:39 <dvhart> kergoth, we're working on improving the situation. Have you read the Kernel Architecture and Use manual?
Apr 16 18:33:48 <dvhart> kergoth, anything specific you're looking for?
Apr 16 18:33:52 <dvhart> zeddii, ^ heads up
Apr 16 18:33:56 <kergoth> yes, that gives a big picture, but says absolutely nothing about any of hte scripts in meta or anything
Apr 16 18:34:00 <kergoth> not one line about any of them
Apr 16 18:34:26 <dvhart> kergoth, ok, the kern-tools docs. That is a major gap that needs fixing.
Apr 16 18:34:43 <kergoth> I want to add support for a different bsp to a linux-yocto repository, and as far as I can tell, there's no useful documentation on next steps or how I validate the files i add to meta or anything
Apr 16 18:35:12 <kergoth> (specifically, qemumips64 and qemumips64el. I'm sure it's trivial once you know what you're doing, but..)
Apr 16 18:36:10 <dvhart> kergoth, I suggest starting with tomz's (Guest33591) yocto-bsp tool
Apr 16 18:36:20 <dvhart> it will allow you to do all the validation and setup in recipe-space
Apr 16 18:36:44 <dvhart> once it's working as you want it to, the files you generate can be applied very easily to the linux-yocto repository meta branch
Apr 16 18:36:48 <zeddii> the BSP developer guide should cover all that. what does what is in the architecture manual.
Apr 16 18:36:52 <dvhart> this will greatly reduce the logistics
Apr 16 18:37:00 <dvhart> and... right, the BSP guide
Apr 16 18:37:01 * zeddii has mips64 qemu prep'd for 1.3 already. FWIW.
Apr 16 18:37:03 * dvhart grabs the link
Apr 16 18:37:09 <fray> anyone know why lrzsz in under recipes-bsp?
Apr 16 18:37:15 <fray> is it only includef or bootloader support
Apr 16 18:37:22 <dvhart> kergoth, http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html
Apr 16 18:37:42 <kergoth> already read it in about 5 minutes
Apr 16 18:37:43 <fray> zeddii, nice.. synced w/ khem on the toolchain support
Apr 16 18:37:45 <fray> ?
Apr 16 18:37:46 <kergoth> it's uselss for what i'm looking for
Apr 16 18:37:55 <kergoth> recipes are trivial, i don't care about that, i can do that in 10 minutes
Apr 16 18:38:02 <kergoth> there's no useful info about dealing with the git repository there
Apr 16 18:38:09 <zeddii> fray. not yet, I've only got  the kernel part done with an existing rootfs.
Apr 16 18:39:14 <dvhart> kergoth, right, I think I have another doc for you... looking
Apr 16 18:39:18 <kergoth> k
Apr 16 18:39:43 <kergoth> zeddii: where can i find the mips64 qemu bits?
Apr 16 18:39:53 <fray> zedii, ok.. Khem was mentioned ot me last week that once this freeze is over eh was going to start looking at mips64 support
Apr 16 18:40:04 <zeddii> aha.
Apr 16 18:40:21 <dvhart> kergoth, https://wiki.yoctoproject.org/wiki/BKM:_starting_a_new_BSP
Apr 16 18:40:29 <dvhart> kergoth, and that links to many other references
Apr 16 18:40:34 <zeddii> http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-dev/log/?h=standard/mti-malta64
Apr 16 18:40:40 <kergoth> dvhart: aha, thanks
Apr 16 18:40:43 <dvhart> kergoth, FYI, we have been working at simplifying the process
Apr 16 18:41:00 <zeddii> http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-dev/tree/meta/cfg/kernel-cache/bsp/mti-malta64?h=meta
Apr 16 18:41:15 <dvhart> kergoth, and whilst doing that, we haven't been documenting the existing or older as much as people might like, as we will have to replace it continually
Apr 16 18:41:20 * kergoth nods
Apr 16 18:41:22 <dvhart> kergoth, however, the above should help
Apr 16 18:41:28 <dvhart> kergoth, feedback would be welcome
Apr 16 18:41:32 <kergoth> I like the concepts with the linux-yocto stuff, but was missing the practical info on getting up to speed with it
Apr 16 18:41:35 <dvhart> kergoth, where you found gaps, etc.
Apr 16 18:41:36 <kergoth> this seems to cover that
Apr 16 18:41:37 <kergoth> will do
Apr 16 18:41:45 <dvhart> thanks
Apr 16 18:41:48 <kergoth> I'd love to see more of this flowing into the bsp guide
Apr 16 18:41:58 <kergoth> i presume it's on the roadmap somewhere :
Apr 16 18:42:28 <dvhart> it's definitely well understood as a gap and something tomz, zeddii, and I are actively working on.
Apr 16 18:42:57 <kergoth> zeddii: cool, thanks. have you started on any of the metadata aspects yet? I have some of the basics locally, adding preliminary site files, adding the arch to various mappings in various classes, blah blah. trivial stuff, but needed doing. working on openssl now. heh
Apr 16 18:43:11 <kergoth> dvhart: okay, thanks again
Apr 16 18:43:18 <kergoth> will dive in sometime today
Apr 16 18:43:25 <dvhart> great
Apr 16 18:43:29 * dvhart handles SIGFOOD
Apr 16 18:44:32 <fray> HAHAHA lrzsz recipe is broken any nobody has noticed.. sz, sx and sb don't even work
Apr 16 18:44:57 * kergoth acts surprised :)
Apr 16 18:45:01 <fray> (they're linked to the receive not send)
Apr 16 18:45:14 * fray fixes it as part of the update-alternatives crap
Apr 16 18:48:27 <zeddii> kergoth. I grabbed the old oe stuff and started from there, but that's still outstanding for me.
Apr 16 18:48:38 <zeddii> sounds like we can combine it all and call it done :P
Apr 16 18:49:00 <zeddii> but that description has been booted and tested from the kernel point of view anyway.
Apr 16 18:49:14 <kergoth> nice, that's great progress
Apr 16 18:49:32 <kergoth> have you looked at qemumips64el yet, or just qemumips64?
Apr 16 18:50:20 <zeddii> I have an el description as well. got distracted, on testing it though. but it isn't far away.
Apr 16 18:50:33 <kergoth> cool, thanks for the info
Apr 16 18:54:17 <zeddii> the most fearsome error possible. random rpm packaging error.
Apr 16 18:54:18 * zeddii weeps
Apr 16 18:54:49 * kergoth chuckles
Apr 16 18:54:52 <kergoth> good luck
Apr 16 19:00:01 <zeddii> fray. two recipes. different names. they shouldn't stage to the same place .. right ?
Apr 16 19:01:38 <fray> correct..
Apr 16 19:01:53 <zeddii> @#$
Apr 16 19:02:09 <zeddii> I have an error on the 3.2 kernel. but in the log file, it's messing with the -dev one.
Apr 16 19:34:16 <seebs> I am looking into questions relating to blacklisting of packages.  There's BBMASK, but I'm not sure that's what I want.  Anyone have pointers to good starting points for research?
Apr 16 19:34:53 <fray> (I asked this last week as well in a different context).. but what we're looking for is a way to say I don't want such and such package to be built..
Apr 16 19:35:07 <fray> but like the license or version stuff, I want a message to pop-up and explain that it's been blacklisted..
Apr 16 19:35:17 <fray> (I was told BBMASK prevents bitbake from even loading the recipe that was masked)
Apr 16 19:35:51 * fray wonders if we might need an inherited class or something to do the matching and complain
Apr 16 19:40:26 <dvhart> zeddii, what does "bitbake linux-yocto -e | grep COMPATIBLE_MACHINE=" return?
Apr 16 19:41:23 <kergoth> fray: https://github.com/openembedded/meta-oe/blob/master/meta-oe/classes/blacklist.bbclass
Apr 16 19:41:33 <kergoth> fray: s/ANGSTROM_//g
Apr 16 19:41:55 <fray> there we go.. perfect
Apr 16 19:42:46 <seebs> Thanks, that simplifies my life substantially.
Apr 16 19:43:03 <fray> it'd be nice to make that OE vs angstrom.. but otherwisse that is exactly what we're looking fo
Apr 16 19:43:44 <kergoth> yeah, i'd say make it obey BLACKLIST or RECIPE_BLACKLIST, and add it to oe-core
Apr 16 19:44:23 <fray> yup.... with a simple default message of the item being in the blacklist if no tailored message exists
Apr 16 19:45:58 <kergoth> good idea
Apr 16 19:46:56 <fray> (BTW I prefer the variable BLACKLIST to recipe_blacklist myself.. not sure if anyoen else has any opinions)
Apr 16 19:47:32 * zeddii has some less pc suggestions.
Apr 16 19:48:00 <fray> hah
Apr 16 19:48:54 <seebs> We could have a large selection of them and code them according to widely-recognized racial stereotypes.  I am all in favor of a system where a WHITELIST is a set of packages which cannot dance.
Apr 16 19:49:26 <fray> ouch
Apr 16 19:49:30 <fray> I resemble that
Apr 16 19:49:39 <zeddii> :)
Apr 16 19:51:42 <fray> If anyone has time, could you look at:
Apr 16 19:51:43 <fray> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mhatle/upd-alt
Apr 16 19:51:59 <fray> especially the update-alternatives.bbclass change and let me know if you have any comments..
Apr 16 19:52:07 <fray> I'm currently running final tests and I'm goign to send it up..
Apr 16 19:53:33 <fray> hmm.. upon thinking about it.. I think RECIPE_BLACKLIST is probably better then just BLACKLIST
Apr 16 19:53:36 <fray> we already have a LICENSE_BLACKLIST (don't we?)
Apr 16 19:57:56 <kergoth> yeah, i think RECIPE_BLACKLIST would be more clear and obvious
Apr 16 19:59:11 <msm> does anyone know if busybox supports "mount -n"?
Apr 16 20:42:21 <kergoth> is master frozen at the moment for the release, or is it open for post-release changes?
Apr 16 20:44:31 <fray> I believe there is a "next" branch in oe
Apr 16 20:56:26 <fray> kergoth, re the CSL toolchain patchset:
Apr 16 20:56:26 <fray> NEAS Cheer Practice
Apr 16 20:56:27 <fray> scheduled June 11, 2012 from 6:00 PM to 8:30 PM
Apr 16 20:56:30 <fray> crap wrong paste
Apr 16 20:56:34 <fray> +for usr_element in bin include libexec sbin share ${base_libdir}; do
Apr 16 20:56:35 <fray> +usr_path=$sysroot/usr/$usr_element
Apr 16 20:56:35 <fray> +cp -a $usr_path ${D}/usr/
Apr 16 20:56:35 <fray> +done
Apr 16 20:56:37 <fray> there we go..
Apr 16 20:56:55 <fray> this looks to be limited to requiring a "/usr" path on the target with these toolchains..
Apr 16 20:57:00 <kergoth> it's already required.
Apr 16 20:57:04 <fray> If that is a hard requirement it should be documented
Apr 16 20:57:09 <kergoth> if the filesystem layout doesn't match up, glibc won't be able to find the locales
Apr 16 20:57:26 <kergoth> for similar reasons, you can't use an external toolchain with the micro distro due to the different prefix
Apr 16 20:57:42 <fray> ok..  just wanted to make sure that was intentional
Apr 16 20:57:51 <kergoth> and you'd also have to have matching multilib setup, otherwise it wouldn't be able to find the dynamic linker at runtime
Apr 16 20:58:33 <kergoth> so, yeah, it's something i've thought about. it just isn't viable to use a different layout than the toolchain is without rebuilding the c library
Apr 16 20:58:38 <kergoth> afaict anyway
Apr 16 20:59:18 <kergoth> i was talking to seebs about this earlier. i think tcmode-external-csl.inc should require multilib.conf to ensure that the base_libdir is correct, and it should either force prefix to usr or should error if it's something other than usr
Apr 16 20:59:25 <kergoth> thoughts?
Apr 16 20:59:38 <fray> I wouldn't disagree with that.. :)
Apr 16 20:59:51 <fray> it's a pirce you pay for compatibility
Apr 16 21:00:09 <seebs> Waffling back and forth.  My preference is either force-but-warn, or error out.
Apr 16 21:00:55 <seebs> Basically, it's a dev time tradeoff.  We could spend weeks supporting all possible ways someone could configure a filesystem and faking stuff up and handling errors, or we could just say "well, actually, prebuilt libcs get to say where stuff goes, deal with it or rebuild your own".
Apr 16 21:01:58 <fray> ya, that seems reasonable..
Apr 16 21:02:15 <kergoth> i think there are a *lot* of cases where a user *could* change a given variable, but in reality we neither test or support it. some of the individual filesystem layout variables come to mind
Apr 16 21:02:25 <seebs> YAGNI.  I'm totally willing to think about this when someone provides a use case where there's a need to be able to move stuff.
Apr 16 21:02:36 <kergoth> i think we should do a better job of deliniating what variables are things the user can/should be able to twiddle and what aren't, instead are internal
Apr 16 21:03:10 <kergoth> another example would be various tmpdir path variables, i suspect there are hardcoded assumptions for some of them
Apr 16 21:03:12 <kergoth> heh
Apr 16 21:03:33 <kergoth> hell, the fact that it used to be impossible to move the pstaging dir outside of tmpdir was a great example of being bitten by that
Apr 16 21:04:02 <fray> I've been tempted, more then once, to completely screw with all of the path variables and see what happens..
Apr 16 21:04:11 * kergoth nods
Apr 16 21:04:13 <fray> last time I did that I was surprised there was no unexpected breakage during hte build
Apr 16 21:04:19 <fray> (that was about 8 months ago)
Apr 16 21:04:31 <kergoth> it'd be fun to just fondle bindir alone, or make libdir /foo, or so..
Apr 16 21:05:03 <fray> I'm tempted to implement the Ubuntu/Debian multilib naming and see how far off the rails the system goes
Apr 16 21:05:04 * kergoth ponders
Apr 16 21:05:23 <fray> I -know- there are a lot of hard coded assumptions for things like /bin/sh...
Apr 16 21:06:05 <kergoth> i'm sure most of the time those sorts of failures would be few, and probably easy to fix, but there's a certain amount of maintenance load if we try to support or care about every combination of settings, so the boundaries should be clear and defined
Apr 16 21:06:06 <fray> (and I'm pretty sure it's NOT worth out time to fix them so someone can do /myrandomdir/sh
Apr 16 21:06:45 <fray> ya.. I'm ok with removing "/usr"..  and even with trying to support the Debian braindramage..  but not changing /bin is a good idea.. ;)
Apr 16 21:07:58 * kergoth nods
Apr 16 21:08:39 <kergoth> is there a layer with a linux-yocto-dev recipe, or should i just tweak one of the existing 3.0/3.2 recipes? i realize it's trivial, was curious though
Apr 16 21:09:01 <fray> I don't think there is a special layer for it...
Apr 16 21:09:07 * fray looks at zeddii
Apr 16 21:13:12 <seebs> I seem to recall that POSIX went out of its way to specify something crazy like /usr/posix/bin/sh as The Posix Shell.
Apr 16 21:13:31 <fray> No, I think that was Sun.. ;)
Apr 16 21:18:39 <kergoth> gah, damnit, forgot something in that external csl series, install_locale chokes if there's no SUPPORTED< even though we don't need the thing
Apr 16 21:18:41 * kergoth rolls eyes
Apr 16 21:18:43 * kergoth tweaks
Apr 16 21:19:58 <RP__> kergoth: I think there is a layer but the name escapes me atm
Apr 16 21:21:00 <RP__> kergoth: http://git.yoctoproject.org/cgit.cgi/poky-extras/tree/meta-kernel-dev/recipes-kernel/linux
Apr 16 21:21:23 <RP__> kergoth: there was talk of moving this into a proper layer, not sure if it happened yet or not
Apr 16 21:21:36 <kergoth> ah! i thought i remembered there being one, but i didn't think to look under extras
Apr 16 21:21:37 <kergoth> thanks
Apr 16 21:56:24 <fray> this is really annoying from bitbake-layers:
Apr 16 21:56:24 <fray> <string>:1: DeprecationWarning: Call to deprecated function bb.which: Please use bb.utils.which instead.
Apr 16 21:56:24 <fray> <string>:1: DeprecationWarning: Call to deprecated function bb.which: Please use bb.utils.which instead.
Apr 16 21:56:25 <fray> <string>:1: DeprecationWarning: Call to deprecated function bb.which: Please use bb.utils.which instead.
Apr 16 21:56:29 <fray> (I get about a page of those)
Apr 16 21:56:41 <bluelightning> fray: yes I know... :/
Apr 16 21:56:54 <bluelightning> fray: only shows up on certain slightly older python versions
Apr 16 21:57:04 <fray> CentOS 6.2 ... up to date
Apr 16 21:57:14 <bluelightning> I guess if I had experienced it during testing I would have fixed it sooner
Apr 16 21:57:39 <fray> I looked into it before and couldn't find the "bb.which" call it was referring to
Apr 16 21:58:01 <bluelightning> it's in bitbake code, not bitbake-layers
Apr 16 21:58:15 <bluelightning> these just don't get printed during bitbake execution itself
Apr 16 21:58:18 <fray> ahh.. thats why I couldn't find it
Apr 16 21:58:47 <bluelightning> I'm not entirely sure why we get them in bitbake-layers but I have some idea of how to disable them
Apr 16 21:59:09 <khem> old python
Apr 16 21:59:24 <fray> like I said, current CentOS.. I expect we will have lots of folks using it..
Apr 16 21:59:31 <kergoth> no, that doesn't ahve anything to do with old python
Apr 16 21:59:34 <fray> so it needs to work well there.. bitbake-layers is hte only thing I seem to have problems there..
Apr 16 21:59:39 <kergoth> that deprecation is tirggered by bitbake itself, not python
Apr 16 21:59:40 <bluelightning> in Python 2.7+ this class of warnings is off by default
Apr 16 21:59:42 <fray> [lmhatle@msp-lpggp1 build-ia32]$ python --version
Apr 16 21:59:42 <fray> Python 2.6.6
Apr 16 21:59:46 <kergoth> bin/bitbake hides those warnings explicitly
Apr 16 21:59:53 <kergoth> bitbake-layers does not
Apr 16 22:00:11 <bluelightning> kergoth: can you point me to where this gets turned off?
Apr 16 22:00:21 <kergoth> bluelightning: are you sure you aren't mixing up DeprecationWarning with PendingDeprecationWarning? the former shoudl be hidden
Apr 16 22:00:39 <bluelightning> kergoth: not sure, I looked it up some weeks ago
Apr 16 22:00:39 <kergoth> line 91 of bin/bitbake
Apr 16 22:00:47 <kergoth> warnings.filterwarnings("ignore", category=DeprecationWarning, module="<string>$")
Apr 16 22:01:10 <kergoth> i'd suggest grabbing that whole block, or moving it somewhere common to boths cripts
Apr 16 22:01:27 <kergoth> (though we should fix the metadata to use the bits in their new locations -- which lives in bb.utils nowadays)
Apr 16 22:02:28 <fray> for the current OE freeze, lets filter them.. and soon after can we fix it?
Apr 16 22:02:37 <bluelightning> kergoth: ideally I would do that yes, right now I only want the bare minimum to get rid of the warnings
Apr 16 22:06:56 <kergoth> bluelightning: k, that one line should do it, afaict
Apr 16 22:08:17 <khem> so the problem still is old python :)
Apr 16 22:10:13 <kergoth> bluelightning: you could also, of course just make it ignore all deprecationwarnings the way you say 2.7 does. iirc you'd just not pass module=, so it'd apply to all modules
Apr 16 22:10:19 <kergoth> warnings.filterwarning() is quite flexible
Apr 16 22:12:23 <bluelightning> kergoth: ok
Apr 16 22:21:33 <bluelightning> fray: can you just double-check with poky-contrib branch paule/bitbake-layers-warn that the warnings go away for you?
Apr 16 22:21:48 <bluelightning> I have tested them on a Debian system but at this late stage I want to be doubly sure
Apr 16 22:22:00 <bluelightning> s/them/the fix/
Apr 16 22:22:34 <fray> I'll do that in about 5 minutes..
Apr 16 22:22:39 <bluelightning> thanks
Apr 16 22:27:35 * fray tries to send the update-alternatives changes and git-send email seems to have frozen..
Apr 16 22:31:19 <fray> confirmed.. that fixes it here
Apr 16 22:31:29 <bluelightning> fray: ok great, thanks
Apr 16 23:17:18 <dongxiao> RP__: ping
Apr 16 23:52:22 <Andy44> hi
Apr 17 00:20:51 <kergoth> hmm, my do_validate_branches failed, with no error messages at all, not even in the log. just says the function failed
Apr 17 00:20:55 <kergoth> that's not very useful
Apr 17 00:26:08 <dongxiao> fray: ping?
Apr 17 00:30:03 <dvhart> kergoth, are you building from a local mirror or are you fetching from upstream? Assuming a local mirror?
Apr 17 00:30:18 <kergoth> local, yeah, with KSRC and meta-kernel-dev
Apr 17 00:30:34 <dvhart> kergoth, is it a bare mirror? (not just a clone?)
Apr 17 00:31:07 <kergoth> ah, right, KSRC is supposed to point at the bare mirror, not the clone of the bare mirror
Apr 17 00:31:09 * kergoth slaps forehead
Apr 17 00:31:09 <kergoth> thanks
Apr 17 00:31:14 <dvhart> np
Apr 17 00:31:24 <dvhart> apparently some better errors are still required
Apr 17 00:31:33 <dvhart> can you include that in your feedback notes please?
Apr 17 01:27:35 <dongxiao> It seems that I could not receive mail from yocto@yoctoproject.org since this morning, but the archive shows that the mails are there.
**** ENDING LOGGING AT Tue Apr 17 02:59:59 2012

**** BEGIN LOGGING AT Tue Apr 17 03:00:00 2012
Apr 17 07:34:45 <RP__> morning all
Apr 17 07:48:46 <Zagor> morning
Apr 17 08:01:45 <Zagor> RP__: will a Tested-by: email from me be helpful re BB_HASHBASE_WHITELIST & PARALLEL_MAKE? I am not familiar with the procedures yet
Apr 17 08:02:52 <RP__> Zagor: They help in that they record who was interested in and tested the change. I did merge that one already though (and we tend just to store the review/tested tags in the archives since adding them to the commits can be a pain)
Apr 17 08:03:36 <Zagor> ok
Apr 17 08:29:53 <mckoan> good morning
Apr 17 10:16:32 <ag> Hello everybody!
Apr 17 10:16:54 <ag> RP__: Do you have one minute?
Apr 17 10:25:24 <ag> libgcc gcc-runtime are GPLv3
Apr 17 10:26:39 <ag> but in a non gplv3 build (of my own = with some custom layers) i get libgcc1-4.6.2+svnr181430-r22.armv7a.rpm and libstdc++6-4.6.2+svnr181430-r22.armv7a.rpm in the final fs... and i don't know why isn't this reported as error.
Apr 17 10:27:08 <ag> Actually i know. Because they are whitelisted. But still. Should these be excluded from the final fs?
Apr 17 10:27:58 <ag> shouldn't
Apr 17 10:50:10 <RP__> ag: libgcc has a license exception for GPLv3
Apr 17 10:50:36 <RP__> ag: You can't build any kind of working image without libgcc. You'd have to build an old gcc version
Apr 17 10:51:09 <ag> RP__: Yes i know. But still, isn't this a problem while including this GPLv3 package in the final fs?
Apr 17 10:51:37 <RP__> ag: a problem in what sense? As I said, libgcc has an exception to allow this
Apr 17 10:52:21 <RP__> ag: If you or your legal department don't believe in the exception, take it out the whitelist
Apr 17 10:52:33 <ag> Ok i will check the licence's exception.
Apr 17 10:52:37 <ag> THank you.
Apr 17 14:54:21 <sgw> bluelightning: How is that distro sanity check coming along, will you have a real pull request today?
Apr 17 14:59:06 <bluelightning> sgw: struggling to confirm fedora 17 ID; in the mean time I have updated the patch in the contrib branch
Apr 17 14:59:31 <sgw> bluelightning: do you need the Build App ID or do you have that?
Apr 17 14:59:55 <bluelightning> sgw: I do still need that yes
Apr 17 15:00:05 <bluelightning> the question is does it report anything?
Apr 17 15:01:44 <sgw> I will let you know shortly!
Apr 17 15:52:26 <chrisw957> Is there not a recipe for hostap-daemon?
Apr 17 15:56:20 <bluelightning> chrisw957: there is in OE-classic, doesn't look like anyone has migrated it over to OE-Core yet
Apr 17 15:56:47 <chrisw957> Ok, thanks.  That is what I thought I was seeing as well.
Apr 17 16:18:27 <bluelightning> sgw: any word on the build appliance distro ID?
Apr 17 16:18:48 <bluelightning> I'd check myself but unfortunately I had to delete my self-hosted-image because my laptop is sort of space :(
Apr 17 16:20:09 <sgw> bluelightning: will have that shortly
Apr 17 16:20:37 <bluelightning> s/sort/short/
Apr 17 16:21:00 <ant_work> sgw: time to send him a new laptop
Apr 17 16:21:14 <sgw> or a bigger disk!
Apr 17 16:21:36 <zeddii> wow. I misread that completely.
Apr 17 16:21:40 <zeddii> time for more coffee :P
Apr 17 16:21:58 * ant_work is already at beer-time
Apr 17 16:23:20 <sgw> bluelightning:  I think you found another package we need to add to self-hosted image!
Apr 17 16:23:32 <ant_work> zeddii: I'm playing with the fragments. Still some doubts about KERNEL_FEATURES  'appended' after parsing the .scc
Apr 17 16:23:54 <bluelightning> sgw: well not really, the lsb-release utility isn't required, but the file is
Apr 17 16:24:26 <sgw> bluelightning: I don't have lsb_relelase installed, nor do we have an /etc/lsb-release since this image is not "lsb"!
Apr 17 16:24:42 <bluelightning> sgw: right, but without it we have no way of detecting the distro
Apr 17 16:24:48 <sgw> exactly!
Apr 17 16:25:14 <bluelightning> so the lsb-release *package* is how we get the file in /etc deployed?
Apr 17 16:26:30 <sgw> bluelightning: I think so, I would have to verify (looking now)
Apr 17 16:26:52 <bluelightning> sgw: I'd suggest perhaps just creating an /etc/lsb-release for the self-hosted image as part of the postprocessing, I don't think we want all of this
Apr 17 16:27:15 <sgw> lsb_1.4 provides the /etc/lsb-release file currently
Apr 17 16:28:10 <bluelightning> right
Apr 17 16:29:16 <bluelightning> I guess you could add the lsb package, it doesn't look too intrusive
Apr 17 16:30:03 <bluelightning> sgw: even if we did deploy it though would it report a sensible value?
Apr 17 16:30:04 <sgw> we do have the DISTRO_NAME in /etc/issue
Apr 17 16:30:19 <bluelightning> sgw: I discounted reading that because it's freeform
Apr 17 16:30:42 <sgw> /etc/issue contains $DISTRO_NAME $DISTRO_VERSION which contains a date stamp also
Apr 17 16:31:22 <bluelightning> yes, that would be a bit of a problem
Apr 17 16:31:38 <sgw> not sure about what's in /etc/lsb-release in lsb_1.4 your right about it being a sane value
Apr 17 17:36:40 <fray> need a python clue..
Apr 17 17:36:49 <fray> os.path.join doesn't seem to be working the way I would expect
Apr 17 17:36:55 <fray> bb.note('%s: Looking for %s (%s/%s/%s)' % (link, os.path.join(pkgdest, pkg, link), pkgdest, pkg, link))
Apr 17 17:36:57 <fray> that results in:
Apr 17 17:37:02 <fray> notespace: /usr/bin/ssh.openssh: Looking for /usr/bin/ssh.openssh (/home/mhatle/git/oss/oe-core/build-ia32/tmp-eglibc/work/i586-oe-linux/openssh-5.9p1-r4/packages-split/openssh-keygen//usr/bin/ssh.openssh)
Apr 17 17:37:10 <fray> why doesn't the stuff outside and inside the () match?
Apr 17 17:39:08 <fray> looks like the additional items should be "." + ...
Apr 17 17:39:15 <fray> otherwise the beginning slash just keeps killing it
Apr 17 17:39:42 <incandescant> fray: "Join one or more path components intelligently.  If any component is an absolute path, all previous components (on Windows, including the previous drive letter, if there was one) are thrown away, and joining continues."
Apr 17 17:39:42 <incandescant> http://docs.python.org/library/os.path.html
Apr 17 17:39:48 <seebs> Huh, that's interesting.  I suspect that's it -- the system is helpfully notici... yeah that.
Apr 17 17:40:12 <fray> the problem is the documentation talks about windows..
Apr 17 17:40:18 <fray> I'm much more interested in unix behavior.. :P
Apr 17 17:40:40 <fray>  /home/mhatle/git/oss/oe-core/build-ia32/tmp-eglibc/work/i586-oe-linux/openssh-5.9p1-r4/packages-split/.openssh-keygen/./usr/bin/ssh.openssh
Apr 17 17:40:45 <incandescant> I think it's pretty clear, here "Join one or more path components intelligently.  If any component is an absolute path, all previous components are thrown away, and joining continues."
Apr 17 17:40:48 <fray> if I manually add the '.' in the joining..
Apr 17 17:41:02 <fray> still doesn't seem very intelligent
Apr 17 17:41:21 <incandescant> well, that word does get abused
Apr 17 17:41:27 <incandescant> but it's functioning as documented ...
Apr 17 17:41:37 <incandescant> join doesn't buy you much anyway for our use
Apr 17 17:41:57 <fray> I see that....
Apr 17 17:42:16 <seebs> Basically, what it's doing is, if you're in this directory, and you provide this path, what does it turn into?  Since the path starts with a /, the logical current directory doesn't matter much.
Apr 17 17:42:45 <fray> ya, I see.. it just seems "odd" to me..
Apr 17 17:42:58 <fray> I expected "intelligent" concantenation.. i.e. handle .. and . and such
Apr 17 17:44:55 <seebs> It might do that, but it does make sense for it to assume that absolute paths are intended to be absolute.  Because it's not thinking in sysrooty terms.
Apr 17 17:57:46 <nitink1> quiestion: when a.bb includes b.bb , and b.bb is extended in another layer, then does the extension gets applied to a.bb ?
Apr 17 17:58:27 <kergoth> no
Apr 17 17:58:33 <kergoth> a.bbappend only applies to a.bb
Apr 17 17:58:45 <kergoth> and b.bbappend only applies to b.bb
Apr 17 17:59:01 <nitink1> then it is an issue
Apr 17 17:59:11 <kergoth> ?
Apr 17 17:59:19 <kergoth> it does exactly what it's supposed to do
Apr 17 17:59:19 <nitink1> a.bb & b.bb both need extention
Apr 17 17:59:25 <kergoth> then create two bbappends
Apr 17 17:59:26 <nitink1> and a.bb includes b.bb
Apr 17 17:59:40 <nitink1> will it get extend a.bb twice ?
Apr 17 18:00:15 <kergoth> require includes a particular file only, period
Apr 17 18:00:28 <kergoth> and a bbappend only applies to the recipe named that way, not to files tha tinclude that recipe
Apr 17 18:00:32 <kergoth> it's not that complecated
Apr 17 18:00:48 <kergoth> put another way, 'require a.bb' does not require a.bbappend, only a.bb
Apr 17 18:00:59 <nitink1> so require/include tag inside bb files don't care about bbappend files, right ?
Apr 17 18:01:03 <kergoth> yes
Apr 17 18:01:13 <kergoth> you can append recipes, not arbitrary metadata files
Apr 17 18:01:37 <nitink1> is there a way to extend .inc file (no .bb)
Apr 17 18:01:57 <fray> you do that by creating a new custom .inc file, and then a .bbappend to include that one
Apr 17 18:02:08 <nitink1> I see
Apr 17 18:02:17 <fray> (that will work in almost all cases I know of)
Apr 17 18:02:28 <nitink1> thanks for clarifications kergoth & fray
Apr 17 18:03:09 <bluelightning> sgw: am heading home now but will be online later if we still want to go ahead with the host distro sanity test
Apr 17 18:05:05 <sgw> bluelightning: ok thanks
Apr 17 18:08:57 <nitink1> kergoth: about include/require and .bbapend, I see different results on two different build systems
Apr 17 18:09:29 <nitink1> and it is consistent behavior
Apr 17 18:09:49 <nitink1> do some env var affect this ?
Apr 17 18:12:24 <kergoth> nitink1: no
Apr 17 18:12:48 <nitink1> kergoth: I am trying to reproduce the issue now
Apr 17 18:12:59 <nitink1> but it is very system specific
Apr 17 18:14:11 <kergoth> that's highly unlikely. it's far more likely that your test is incorrect. bitbake's recipe handling doesn't change from machine to machine
Apr 17 18:16:07 <nitink1> kergoth: I also expected same. possible some differences on the systems, I will get real data on this
Apr 17 18:16:25 * kergoth nods
Apr 17 18:30:18 <nitink1> kergoth: http://paste.ubuntu.com/934358/
Apr 17 18:30:30 <nitink1> notice PR is extended by .x32 twice
Apr 17 18:31:31 <nitink1> kergoth: here are bbapends to oecore master: http://git.yoctoproject.org/cgit/cgit.cgi/experimental/meta-x32/tree/gcc?h=master%2bwork
Apr 17 18:31:49 <nitink1> this happens only on 1 system
Apr 17 18:32:52 <nitink1> and bitbake is part of yocto git tree
Apr 17 19:27:23 <autif> I pulled the latest source of master (git pull) and my patches to the kernel are no longer applied - I was working with 1.2 M2 or 1.2 M3 or something in between earlier. After getting the latest sources - my recipe to patch the kernel stopped working - the kernel is built - the diff file is copied to the tmp/work/<arch>-linux/linux-yocto-3.2.11+git… directory, but the patch is not applied
Apr 17 19:28:32 <autif> the recipe is very simple - FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
Apr 17 19:28:34 <autif> SRC_URI =+ " file://hid_ignore.diff "
Apr 17 19:28:53 <autif> hid_ignore.diff is copied correctly - but it is not applied
Apr 17 19:29:09 <autif> it worked just fine a few/several checkins ago
Apr 17 19:29:35 <autif> the name of the recipe is linux-yocto_3.2.bbappend
Apr 17 19:29:49 <zeddii> autif. I can try and help. there were changes in this area.
Apr 17 19:29:56 <autif> cool
Apr 17 19:30:00 <autif> want logs?
Apr 17 19:30:16 <zeddii> yes. patches work here, so I'm curious to know what the difference could be.
Apr 17 19:32:27 <autif> Here is the patch file that I use - did the header format change? http://pastebin.com/ETnfKLkp
Apr 17 19:33:14 <zeddii> they really should always have kernel style headers, since they are being applied to a git tree. but that wasn't the big part of the changes.
Apr 17 19:33:16 <autif> patch applies fine if I "patch -p1 < ../hid_ignore.diff" in the linux directory
Apr 17 19:34:02 <zeddii> can you save me re-creating your setup and send me your bbappend and machine configuration ?  I'll just do a build here to see.
Apr 17 19:34:51 <autif> of course - machine configuration? Will local.conf and bblayers.conf be enough?
Apr 17 19:35:07 <zeddii> and your bbappend. that should be fine.
Apr 17 19:35:10 <autif> yes
Apr 17 19:35:23 <autif> they are on their way - ETA ~10 minutes
Apr 17 19:35:26 <autif> will pi ng
Apr 17 19:35:28 <zeddii> sounds good.
Apr 17 19:48:30 <davest> sgw: ping
Apr 17 19:50:32 <autif> zeddii - you have 2 emails - gmail and windriver
Apr 17 19:51:40 <zeddii> yep. either will work. I see your email. give me an hour or so to poke at it. I need to prep a rc4 fix, but will look at this soon in case something is broken.
Apr 17 19:52:13 <autif> take your time - I am on east coast - and it is 80 degrees - I will likely leave early and enjoy this beautiful day
Apr 17 19:52:16 <autif> thanks again
Apr 17 20:16:58 <zeddii> autif. aha.I have a fix. it's easy enough, I'll test and send it out later tonight.
Apr 17 20:24:12 <autif> zeddii - great - thanks - will keep an eye on patches on the mailing list
Apr 17 20:26:20 <msm> what's the best way to get bitbake to substitute a var with something I executed?
Apr 17 20:26:29 <msm> seems like there should be a good example somewhere ;)
Apr 17 20:27:21 <bluelightning> msm: what do you mean exactly?
Apr 17 20:27:37 <msm> REICPE_VAR  = `date`
Apr 17 20:28:02 <bluelightning> I think the "easiest" way to do that is in a python function
Apr 17 20:28:30 <msm> bluelightning: ok
Apr 17 20:29:17 <kergoth> ${@oe.process.run(d, "echo foo")} or somesuch might work, but that'll likely raise an exception on failure
Apr 17 20:36:40 * fray thinks matchbox-wm-2.0 's alternative provides are broken.. :P
Apr 17 20:37:13 <fray> it references a file that doesn't exist
Apr 17 20:38:33 <msm> kergoth: would that command get run before running any steps? i.e. could I modify PR in that command?
Apr 17 20:38:46 * msm is trying this now so will know soon
Apr 17 20:40:49 <kergoth> huh?
Apr 17 20:41:00 <kergoth> ${@} is in a variable reference, its expanded when the var is expanded
Apr 17 20:41:06 <kergoth> it doesn't "modify" anything
Apr 17 20:41:23 <kergoth> if you want to use python to modify variables from outside the variable, you'd use an anonymous python function or event handler instead
Apr 17 20:43:47 <msm> kergoth: hmm
Apr 17 20:48:22 <bluelightning> msm: is this not something you would just want to do as part of a task?
Apr 17 20:51:29 <khem> msm: do you want to inject date or something else ?
Apr 17 20:51:47 <khem> for date you could use some python e.g. ${@time.strftime('%Y.%m',time.gmtime())}
Apr 17 20:51:54 <kergoth> or ${DATE} :P
Apr 17 20:52:34 <khem> kergoth: true if you dont want formatting
Apr 17 20:53:29 <bluelightning> er, is that not a format string there?
Apr 17 20:54:33 <khem> in ${DATE} ? where do u see it
Apr 17 20:55:12 <msm> im trying to inject something similiar to a date
Apr 17 20:55:50 <khem> msm: what I wrote above will give YYYY.MM
Apr 17 20:56:20 <khem> you can add DD and HH.MM.SS too if thats what you need
Apr 17 20:56:22 <bluelightning> khem: yes, I mean there's a format string in the example you posted which can be customised to produce whatever date format you want
Apr 17 20:56:44 <khem> yes so what was your question ?
Apr 17 20:56:51 <kergoth> bluelightning: which was his point. that ${DATE} exists, but using that var doesn't give you the c ontrol over the format string
Apr 17 20:56:57 <kergoth> whereas his version does
Apr 17 20:57:26 <bluelightning> yes I know DATE doesn't
Apr 17 20:57:55 <bluelightning> but with a python line such as the above surely you have all the control you could want, no need to shell out to some external program...
Apr 17 20:58:16 <kergoth> msm didn't say he wants a date, he said he wants something similar to a date
Apr 17 21:00:15 <bluelightning> I'm not quite sure what that means...
Apr 17 21:01:03 <msm> im doing random stuff
Apr 17 21:01:29 <msm> we can assume im trying to make PR  equal to the date
Apr 17 21:02:08 <bluelightning> if you really are setting PR I think you probably want to do that within an anonymous python function
Apr 17 21:33:03 <msm> i can't seem to update PR or PV from an anonymous python function
Apr 17 21:33:08 <msm> or there is a sstate issue it seems
Apr 17 21:33:44 <msm> i think i just need to disable sstate for this recipe ;)
Apr 17 21:35:24 <bluelightning> hmm
Apr 17 21:38:15 <msm> ERROR: Command execution failed: Exited with 1
Apr 17 21:38:15 <msm> NOTE: Error expanding variable sstate_installpkg
Apr 17 21:44:01 <msm> i can't seem to find a way to turn off sstate
Apr 17 21:44:42 <kergoth> pretty sure there's no provided mechanism to disable it. you could hack it, potentially, remove elements from SSTATETASKS or something
Apr 17 21:47:11 <msm> seems like the python function is not getting run *before* reading the PR the first time
Apr 17 21:47:50 <msm> as in it seems PR must be a static value
Apr 17 21:48:45 <RP__> turning off the package creation bits of sstate is fine but you really want it to control what is going on in the sysroots directory
Apr 17 21:49:56 <msm> well it seems like PR is changing mid parsing
Apr 17 21:50:02 <msm> which is the main problem ;)
Apr 17 21:50:17 <msm> i need something that runs sooner
Apr 17 21:51:15 <RP__> changing PV/PR is painful. Years of pain with SRCREV AUTOINC have shown that :(
Apr 17 21:53:30 <walters> the real bug is packages =)  they conflate "version number mostly for human consumption" with "number that needs to go up so i know to download and install this blob"
Apr 17 21:55:12 <walters> my last build system which output rpms i had a lookaside "build serial" database that was used for Release
Apr 17 21:55:47 <RP__> walters: we have such a thing in development...
Apr 17 21:55:49 <walters> it does mean if you want to reproduce the rpms with the same versions, you'd need to download the lookaside build serial db
Apr 17 21:56:21 <fray> thats the auto-remote PR/PV/PE cache right?
Apr 17 21:56:24 <walters> however i ended up concluding rpm was totally broken and went off to make a new sane meta-build/deploy system, and that's where i am now
Apr 17 21:56:31 <RP__> fray: the prserver
Apr 17 21:56:33 <fray> we have a cache server and such to help make this persistent..
Apr 17 21:56:35 <fray> thanks.. prserver
Apr 17 21:56:59 <RP__> walters: I think we share some opinions on rpm ;-)
Apr 17 21:57:34 <RP__> walters: I want to tie it into our sstate checksums and also some kind of binary diff utility ultimately
Apr 17 21:57:41 <walters> RP__, ostree is coming along, i've kind of gotten probably too sidetracked writing a version control system, but it's fun =)
Apr 17 21:57:49 <RP__> so even when the checksums change, we diff the packages and only update if there was a real difference
Apr 17 21:58:13 <RP__> walters: another version control system? :)
Apr 17 21:58:22 <walters> RP__, well, one designed for binaries
Apr 17 21:58:40 <walters> e.g. it records uid/gid and most imporatantly, extended attributes
Apr 17 21:58:57 <RP__> walters: hmm, interesting
Apr 17 22:00:25 <walters> in my yocto scripts i use it to record the deploy/images/foo.tar.gz filesystems
Apr 17 22:00:41 <msm> RP__: how does SRCREV work?
Apr 17 22:00:48 <walters> gotta run!
Apr 17 22:01:53 <msm> RP__: quick now ;) haha
Apr 17 22:02:00 <msm> RP__: just kidding
Apr 17 22:02:03 <bluelightning> sgw: libzypp -> libproxy DEPENDS addition has indirectly broken non-X image builds that pull in zypper...
Apr 17 22:02:39 <bluelightning> since libproxy -> gconf -> gtk -> [failure]
Apr 17 22:02:56 <bluelightning> I'll file a bug
Apr 17 22:02:58 <fray> ugh -- what I don't get is why libproxy was suddenly needed..
Apr 17 22:03:01 <fray> since this worked before
Apr 17 22:03:29 <RP__> msm: SRCREV is easy, its the revision of the scm to checkout ;-)
Apr 17 22:03:34 <sgw> bluelightning: /me is unhappy with that breakage
Apr 17 22:05:21 <sgw> fray libzypp uses proxy.h
Apr 17 22:06:00 <v0n> hi
Apr 17 22:06:24 <fray> but it worked before on a non X image
Apr 17 22:06:28 <fray> what changed?
Apr 17 22:06:59 <bluelightning> bug 2320 filed
Apr 17 22:07:10 * fray suspects ther eis a --with-libproxy somewhere that should likely be a --without.. :P
Apr 17 22:07:25 <bluelightning> fray: note this is with x11 removed from DISTRO_FEATURES
Apr 17 22:07:25 <fray> (or it's not specified by searching and sometime guesses wrong)
Apr 17 22:07:47 <fray> bluelightning hmm, I don't know if I've done a build like that in a while.. Hmm
Apr 17 22:07:54 <fray> I'm pretty sure it worked ebfore though
Apr 17 22:08:11 <bluelightning> given that this is a configuration more people are using we should probably be explicitly testing it
Apr 17 22:08:14 <fray> (gtk should be able to build w/o X as well.. is that the real bug?)
Apr 17 22:08:18 <fray> I agree
Apr 17 22:08:30 <bluelightning> which shouldn't be too onerous since baryon uses this config (hence how I just found this issue)
Apr 17 22:09:16 <RP__> bluelightning: we probably need to stop libproxy depending on  gconf if x11 isn't enabled
Apr 17 22:11:15 <bluelightning> I'll test that now
Apr 17 22:12:00 <RP__> bluelightning: the trouble is it uses cmake and that means enhancing PACKAGECONFIG to deal with cmake better
Apr 17 22:12:17 <RP__> bluelightning: I guess you could hack the conditional I added
Apr 17 22:12:50 * RP__ decided doing it properly was out of scope for release at this point
Apr 17 22:18:52 <bluelightning> right
Apr 17 22:19:04 <bluelightning> I'm changing both to use base_contains() btw
Apr 17 22:19:38 <v0n> I'm on OpenSuSE and actually trying Yocto using the Quick Start guide, but I fail when running `runqemu qemux86`. It cannot find the libpng12.so.0 shared library. I installed the libpng12-0-32bit package (which provides this lib) but it still can't find it. Any clue?
Apr 17 22:20:57 <fray> you need the 64-bit version
Apr 17 22:21:00 <fray> (most likely)
Apr 17 22:22:10 <RP__> v0n: is this using a build you built yourself or the sdk?
Apr 17 22:23:27 <bluelightning> sgw: so with your patches just posted is there now a reliable distro identification string?
Apr 17 22:31:55 <v0n> fray, you were right, zypper is a bit stupid... `zypper install libpng12.so.0` has installed the 32bit version :-/
Apr 17 22:32:32 <v0n> qemu did run, *but* my screen was frozen
Apr 17 22:32:41 <v0n> (that's why I was disconnected ^^)
Apr 17 22:33:16 <v0n> Black screen, non-blinking cursor on top-left, but mouse cursor working
Apr 17 22:34:33 <v0n> any advise before I make a second try? :-)
Apr 17 22:45:06 <sgw> bluelightning: yes, sorry was on the phone
Apr 17 22:45:58 <bluelightning> sgw: so, what is it? :)
Apr 17 22:46:26 <sgw> bluelightning: that's for me to know and you to figure out ;-)
Apr 17 22:46:43 <bluelightning> well, if you want this patch you'll need to provide it ;)
Apr 17 22:46:43 <sgw> bluelightning: Yocto (Built by Poky 7.0) 1.2
Apr 17 22:46:53 <bluelightning> ok thanks
Apr 17 23:15:33 <bluelightning> sgw: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=paule/sanity-distros&id=b77c409da1c51f9172ae1978fb8ced90ed8398f7
Apr 17 23:15:36 <bluelightning> does that look sensible?
Apr 17 23:16:50 <sgw> yeah, does it patch the space at the end or is that just readability?
Apr 17 23:16:54 <v0n> still no luck running `runqemu qemux86`
Apr 17 23:19:19 <bluelightning> sgw: just readability, it gets trimmed before it is compared
Apr 17 23:19:44 <bluelightning> v0n: are you running under X?
Apr 17 23:19:52 <v0n> bluelightning, yep
Apr 17 23:20:03 <bluelightning> v0n: using the nvidia binary drivers at all?
Apr 17 23:23:52 <v0n> bluelightning, I'm using the nouveau driver
Apr 17 23:24:20 <bluelightning> hmm ok
Apr 17 23:24:44 <bluelightning> v0n: so does it lock up your desktop?
Apr 17 23:28:32 <v0n> bluelightning,
Apr 17 23:28:33 <v0n> yep
Apr 17 23:28:47 <v0n> even ctrl+AltX doesn't have any effect
Apr 17 23:28:50 <sgw> fray does that mean that the mini-x-session ALTERNATIVE is wrong also?
Apr 17 23:29:00 <bluelightning> v0n: it sounds a lot like a driver issue, in which case there's not a lot we can do unfortunately :(
Apr 17 23:29:31 <v0n> I'm trying to follow the guide, skipping this test :-/
Apr 17 23:29:54 <bluelightning> v0n: it may help to disable gl in the qemu command line, not sure if you can do that without hacking the script though
Apr 17 23:30:31 <bluelightning> v0n: no application should be able to cause a lockup like that without there being a bug in the driver
Apr 17 23:31:16 <bluelightning> sgw: hmm the sanity distros patch is broken, just fixing
Apr 17 23:39:09 <bluelightning> ok, fixed... I'll send the patch out now
Apr 17 23:39:11 <incandescant> zenlinux++
Apr 17 23:39:23 <incandescant> yocti: karma zenlinux
Apr 17 23:39:23 <yocti> incandescant: Karma for "zenlinux" has been increased 1 time and decreased 0 times for a total karma of 1.
Apr 17 23:41:07 <zenlinux> thanks yocti
Apr 17 23:41:20 <dvhart> yocti, zenlinux++
Apr 17 23:41:41 <incandescant> zenlinux: hey, he just keeps score - we award :-p
Apr 17 23:41:51 <zenlinux> ah, well thanks incandescant
Apr 17 23:42:39 <sgw> what's yocti?
Apr 17 23:42:49 <zenlinux> that bugfix was due to RP__'s hints as well as intimate knowledge I now have with rpm's install ordering issues :-/
Apr 17 23:43:29 <incandescant> rpm--
Apr 17 23:43:35 <incandescant> yocti: karma rpm
Apr 17 23:43:35 <yocti> incandescant: Karma for "rpm" has been increased 0 times and decreased 1 time for a total karma of -1.
Apr 17 23:43:45 <incandescant> go nuts folks :-)
Apr 17 23:44:17 <dvhart> sgw, yocti is the bot I asked halstead for :-)
Apr 17 23:44:28 <dvhart> sgw, soon it should do bz queries and bug info and such as well
Apr 17 23:44:48 <incandescant> right now it keeps count of karma
Apr 17 23:45:05 <incandescant> yocti: seen davest
Apr 17 23:45:05 <yocti> incandescant: davest was last seen in #yocto 3 hours, 56 minutes, and 34 seconds ago: <davest> sgw: ping
Apr 17 23:45:11 <incandescant> and seen tracking
Apr 17 23:45:27 <sgw> is there a yocto yelp?
Apr 17 23:45:33 <sgw> yocti: help
Apr 17 23:45:34 <yocti> sgw: (help [<plugin>] [<command>]) -- This command gives a useful description of what <command> does. <plugin> is only necessary if the command is in more than one plugin.
Apr 17 23:45:34 <dvhart> yes
Apr 17 23:45:43 <sgw> we should add a yelp!
Apr 17 23:45:47 <dvhart> heh
Apr 17 23:45:51 <dvhart> open a bug ;-)
Apr 17 23:46:01 <incandescant> yocti: commands
Apr 17 23:46:01 <yocti> incandescant: Error: "commands" is not a valid command.
Apr 17 23:46:02 <zenlinux> I want the "sudo make me a sandwich" feature
Apr 17 23:46:02 <sgw> need a bug category!
Apr 17 23:46:10 <incandescant> yocti: make me a sandwich
Apr 17 23:46:11 <yocti> incandescant: Error: "make" is not a valid command.
Apr 17 23:46:14 <incandescant> YOU SUCK
**** ENDING LOGGING AT Tue Apr 17 23:46:14 2012

**** BEGIN LOGGING AT Tue Apr 17 23:48:17 2012
Apr 17 23:48:17 * incandescant goes back to bugzilla
Apr 17 23:56:08 <bluelightning> hmm, our mailing lists are a bit slow this evening :/
Apr 18 00:43:40 <v0n> has the yocto-bsp script been removed?
Apr 18 00:49:01 <v0n> The poky-edison-6.0.1/scripts folder doesn't contain any yocto-bsp script
Apr 18 00:53:58 <incandescant> that script is newer than the 6.0.x/edison release
Apr 18 00:59:11 <v0n> incandescant, ho ok, so I should get yocto for its git repo
Apr 18 01:02:48 <Crofton|work> I am somewhat annoyed the getting started with oe-core is a link to the yocto wiki
Apr 18 01:03:06 <Crofton|work> inconsistent branding
Apr 18 01:11:23 <v0n> what machine branch should I use to  base my BSP on, if my target hardware is a AMD Elan SC520 (x86)?
Apr 18 01:19:26 <v0n> hmm... I cannot use the yocto-bsp tool for my machine :(
Apr 18 01:50:36 <v0n> adding the new bsp path to the bblayers.conf file doesn't affect yocto-kernel, the https://wiki.yoctoproject.org/wiki/Yocto_BSP_Tools_Documentation doc is wrong with the different paths, and the -D option doesn't print any useful information...
Apr 18 01:55:46 <v0n> I do want to give Yocto a try, but I have to say that it is not easy at all for the moment. I start missing buildroot...
Apr 18 02:33:30 <v0n> I give up. I hope it becomes a great project.
Apr 18 02:52:27 <msm> you should try back during california hours
Apr 18 02:52:38 <msm> lots more folks responding
Apr 18 02:52:44 <msm> v0n: ^
**** ENDING LOGGING AT Wed Apr 18 02:59:58 2012

**** BEGIN LOGGING AT Wed Apr 18 02:59:59 2012
Apr 18 07:30:07 <mckoan> good morning
Apr 18 11:57:09 <Zagor> oops. "msgfmt: Command not found" on eglibc install. but next time it worked. race condition?
Apr 18 11:57:33 <Zagor> BB threads = 16
Apr 18 12:01:17 <RP__> Zagor: sounds like a makefile race, yes
Apr 18 13:49:41 <Crofton|work> this business with clonig bitbake into the oe-core directory is really annoying
Apr 18 13:54:32 <bluelightning> Crofton|work: which business?
Apr 18 13:54:44 <Crofton|work> oe-core/bitbake
Apr 18 13:54:50 <Crofton|work> messes up git status
Apr 18 13:55:04 <Crofton|work> so I run them at the same level
Apr 18 13:55:53 * Crofton|work is trying to setup a minimal oe-core, bsp, meta-oe to make sure it works
Apr 18 13:56:18 * Crofton|work is already annoyed the setting up oe-core link led to an offsite wiki
Apr 18 13:56:50 <florian> Crofton|work: one point for the agenda
Apr 18 13:57:01 * florian needs to run
Apr 18 13:57:06 <Crofton|work> ok
Apr 18 13:58:17 <Crofton|work> need to get this sorted out
Apr 18 13:58:38 <bluelightning> Crofton|work: I always intended to bring it over, just it was already over there to begin with
Apr 18 13:58:42 <Crofton|work> basically, the scripts in oe-core assume a git repo layout that is annoying
Apr 18 13:58:50 <Crofton|work> I suspect it is derived from the combo layer
Apr 18 13:58:51 <xumbi> greetings! I'm using poky 6.0.1, trying to add some Qt packages to my image by adding them to POKY_EXTRA_INSTALL (libqtteste4, libqtxmle4, etc.), but I get Nothing RPROVIDES 'libqtteste' ...
Apr 18 13:59:13 <Crofton|work> bluelightning, do you think anyone will get annoyed if I move it over?
Apr 18 13:59:41 <xumbi> the Qt bitbake recipes and classes don't seem to reference RPROVIDES anywhere
Apr 18 13:59:45 <bluelightning> Crofton|work: don't think it should be a problem, I certainly approve...
Apr 18 13:59:51 <Crofton|work> excellent
Apr 18 14:00:00 <Crofton|work> if anyone gets annoyed, i will blame you :)
Apr 18 14:00:07 <bluelightning> Crofton|work: feel free :)
Apr 18 14:00:46 <Crofton|work> :)
Apr 18 14:00:52 <Crofton|work> OK, I need to run some errands
Apr 18 14:28:23 <v0n> <msm> you should try back during california hours
Apr 18 14:28:39 <v0n> msm, I was there, that's where I eared about Yocto
Apr 18 15:12:01 <msm> v0n: i just meant there are more people on IRC to help out ;)
Apr 18 15:26:27 <RP__> v0n: for yocto-bsp scripts issues, tomz1 might be able to help and should be awake now
Apr 18 15:28:58 <tomz1> v0n: yocto-bsp problem>
Apr 18 15:29:04 <tomz1> v0n: ?
Apr 18 15:32:02 <v0n> tomz1, first, yocto-bsp asked for an optimization (atom/core2 for X86), but I don't want either of them
Apr 18 15:32:30 <v0n> I tried to create a BSP for the AMD Elan SC520 (x86)-based board
Apr 18 15:34:45 <v0n> I've seen (according to documentations), that the script didn't asked for that optimization before. Maybe it could allow a third choice like "none".
Apr 18 15:38:38 <v0n> and second yocto-kernel didn't find my bsp even after adding the path to the bblayers.conf.
Apr 18 15:44:21 <tomz1> v0n: ah, ok, i think I know what the problem is, it's a meta-intel bsp, so you need to add meta-intel to the BBLAYERS
Apr 18 15:46:09 <tomz1> v0n: there's a note at the end of the help for yocto-bsp create specifically for that
Apr 18 15:47:05 <tomz1> v0n: 'yocto-bsp help create'
Apr 18 15:52:49 <tomz4> v0n: sorry, dropped off
Apr 18 15:56:56 <v0n> tomz4, still "Unable to find the BSP layer for machine X"
Apr 18 15:58:29 <tomz4> v0n: so you have the path to both meta-intel and meta-X in your BBLAYERS?
Apr 18 16:00:26 <v0n> tomz4, hum, paths are good, but I don't have a meta-intel directory in the poky tree
Apr 18 16:01:11 <tomz4> v0n: hm, so what is the meta-intel path pointing to?
Apr 18 16:02:13 <fray> meta-intel isn't part of Poky, but it's on the git.yoctoproject.org website
Apr 18 16:02:20 <fray> it's a separate layers
Apr 18 16:02:35 <fray> ugh.. it's ONE of the seperate layers you can download
Apr 18 16:02:39 <fray> (brain faster then fingers)
Apr 18 16:03:42 <tomz4> v0n: yeah, you should clone the meta-intel repo and point to that, i guess that's implied in the help, but probably should be more explicit
Apr 18 16:07:04 <RP__> tomz4: we probably need to make this clearer in the documentation and maybe error if it isn't the case
Apr 18 16:07:55 <tomz4> RP__: yeah, makes sense
Apr 18 16:32:58 <tomz4> RP__: filed bug 2230 for that
Apr 18 16:35:29 <v0n> hum, strange, I've checked out the meta-intel repo, added it to the bblayers.conf, but yocto-kernel still can't find my bsp
Apr 18 16:40:08 <tomz4> v0n: can you tell me where your bblayers.conf file is located?
Apr 18 16:42:31 <v0n> tomz4, on my system, in /home/vivien/Sandbox/yocto/build/conf/ (while the poky source is in /home/vivien/Sandbox/yocto/poky)
Apr 18 16:46:59 <tomz4> v0n: sounds like you're running into bug 2219, basically yocto-kernel expects to find bblayers in /home/vivien/Sandbox/yocto/poky/scripts/build/conf/bb
Apr 18 16:47:29 <tomz4> v0n: sorry, the end should be bblayers.conf, not bb
Apr 18 16:48:57 <tomz4> v0n: i guess for now, you'd have to set things up that way, until i can fix that
Apr 18 16:51:07 <tomz4> v0n: again, sorry, that's scripts/../build/conf/bblayers.conf
Apr 18 16:52:04 <tomz4> v0n: so basically as the default setup with build in the poky src at the same level as scripts
Apr 18 16:56:15 <v0n> so, the `source poky/oe-init-build-env` puts me in a "build" dir, which contains my newly created bsp, but I should add its path to the poky source tree?
Apr 18 17:00:26 <tomz4> v0n: yeah, yocto-kernel is looking for the bblayers in ../build/conf/bblayers.conf from where you run the script
Apr 18 17:01:21 <tomz4> v0n: I mean from where the script is located, which is in poky/scripts
Apr 18 17:03:34 <tomz4> v0n: so if you cd into the poky dir and 'source oe-init-build-env', you end up in build
Apr 18 17:04:09 <tomz4> v0n: if you run yocto-bsp from there, it will create build/meta-X
Apr 18 17:07:19 <v0n> tomz4, ok, so the problem is that `source /whatever/oe-init-build-env` will create /whatever/build which isn't handle correctly by the yocto-* scripts.
Apr 18 17:07:48 <tomz4> v0n: and if you run yocto-kernel, it should find build/conf/bblayers.conf, where build/ is at the same level as scripts/ in the poky src tree.  basically having build somewhere else confuses it for now, which stupid of course
Apr 18 17:08:09 <tomz4> v0n: right, that whatever is the problem
Apr 18 17:08:22 <v0n> I guess either they should handle that, or the oe-init-build-env should be smarted to figure out a better path for the build dir (if not provided) and at least advice you
Apr 18 17:08:57 <tomz4> v0n: right, definitely yocto-kernel needs to handle that correctly
Apr 18 17:10:51 <v0n> and I really think the oe-init-build-env script should consider the poky/build dir as default if its not explicitly asked on command line
Apr 18 17:12:12 <v0n> s/its/it's
Apr 18 17:12:57 <darknighte> does anyone know if there are active ARM PREEMPT_RT folks?
Apr 18 17:13:14 <darknighte> I took a peek at Linaro and didn't seem to find any.
Apr 18 17:16:26 <v0n> tomz4, btw, the Quick Start guide is a bit confusing because of its `source poky-edison-6.0.1/oe-init-build-env edison-6.0.1-build` command. I should better be `cd poky-edison-6.0.1; source oe-init-build-env` for the future release I think
Apr 18 17:19:11 <tomz4> v0n: yeah, i think the latter is what most people do by default, not sure why the Quickstart uses that
Apr 18 17:20:25 <v0n> the problem is "Quick Start guide" sounds great to quickly get into Yocto and see how its works
Apr 18 17:22:02 <Crofton|work> darknighte, I have made arm kernels with it turned on
Apr 18 17:24:18 <tomz4> v0n: yeah, and i guess people normally don't run into problems with what's in there but you did because there's a bug in yocto-kernel.  yocto-kernel is new so you're hitting something that wasn't there before
Apr 18 17:52:28 <autif> Do Eric or Denis from Eukrea hang out here?
Apr 18 17:53:08 <Crofton|work> Eric is normally in #oe, not sure about here
Apr 18 17:54:33 <autif> Do you know his nick?
Apr 18 18:02:56 <autif> meanwhile - how do I conditionally include a file. Specifically - I want to include "include.gypi" only for ARMv7 - for all others, I just want the tar.bz2 from google. Here is the recipe in question: https://github.com/eukrea/meta-chromium/blob/master/recipes-browser/chromium/chromium_19.0.1049.3.bb - line 7
Apr 18 18:07:40 <v0n> tomz4, cd poky; source oe-init-build-env; yocto-bsp ...; vim conf/bblayers.conf; yocto-kernel ...; work fine.
Apr 18 18:08:12 <v0n> tomz4, now it remains the problem to build a bsp for an x86-based board which isn't an atom or core2
Apr 18 18:20:18 <tomz4> v0n: if you want something different, you'll have to look at the machine config and replace the tune-core2.inc or what's in there with something else - for instance, tune-i586.inc, see meta/conf/machine/include for other tuning files
Apr 18 18:21:19 <tomz4> v0n: the yocto-bsp templates for any give arch can be changed to list more options, possibly more are needed
Apr 18 18:44:43 <halstead> Level3 network maintenance is currently causing packet loss between itself and NERO. Users may notice low bandwidth and packet loss to Yocto Project servers until traffic and be rerouted.
Apr 18 18:45:41 <halstead> OSl staff is working to route traffic through redundant facilities.
Apr 18 18:49:36 <darknighte> Crofton|work: I thought you might be working with RT.  Is there any community that is currently actively working on the PREEMPT_RT patches specifically for ARM that you know of?
Apr 18 18:50:42 <Crofton|work> not that I know of
Apr 18 18:50:52 <Crofton|work> I ahver turned on PREEMPT
Apr 18 18:51:00 <Crofton|work> and had issues rebooting :)
Apr 18 18:51:48 <darknighte> Crofton: your fingers have outpaced your brain.
Apr 18 18:52:04 <darknighte> "I ahver" ?
Apr 18 18:52:14 <darknighte> I never?
Apr 18 18:52:23 <darknighte> I have?
Apr 18 18:58:48 <Crofton|work> rofl
Apr 18 18:59:01 <Crofton|work> I have turned on PREEMPT
Apr 18 18:59:07 <Crofton|work> without applying the rt patch
Apr 18 18:59:28 <Crofton|work> to many active threads
Apr 18 18:59:37 <darknighte> heh
Apr 18 19:07:17 <dvhart> darknighte, have you asked on #linux-rt on OFTC?
Apr 18 19:07:33 <dvhart> I believe Uwe has worked some on that
Apr 18 19:07:47 <darknighte> dvhart: I have not, yet.
Apr 18 19:08:03 <dvhart> darknighte, you can also try the linux-rt-users list on vger
Apr 18 19:08:05 <darknighte> figured I'd ask in my usual channels first.
Apr 18 19:08:26 <dvhart> a bit out of date (as the korg wiki logins aren't up yet) but you can try: rt.wiki.kernel.org
Apr 18 19:26:38 <darknighte> dvhart: I looked at that one, but I'm not seeing much that would indicate a current community.
Apr 18 19:51:32 <halstead> The rerouting is complete. Packet loss should be normal again.
Apr 18 20:23:30 <kergoth> hmm, boo, getting bit size mismatch (32 vs 64) on the 64 bit malta kernel from linux-yocto-dev. /me checks his setup
Apr 18 20:58:15 <RP__> khem: any ideas on https://bugzilla.yoctoproject.org/show_bug.cgi?id=1906 offhand? (looks like a x86_64 compiler optimisation issue)
Apr 18 21:00:14 <RP__> darknighte: You could try asking dvhart and zeddii
Apr 18 21:01:25 <darknighte> RP__: thx, dvhart already weighed in.  I also asked on #linux-rt.
Apr 18 21:01:55 <RP__> darknighte: ah, yes, I somehow didn't see that
Apr 18 21:02:03 <darknighte> no worries.
Apr 18 21:03:54 <zeddii> darknighte, heading out, but I've already got the 3.4-rt patch merged into linux-yoct-dev (which will be at -rc3 in a few hours).
Apr 18 21:04:19 * zeddii has to head out now. late AGAIN.
Apr 18 21:04:34 <darknighte> zeddii: l8r, take care
Apr 18 21:22:08 <ant__> zeddii: smthg wrong with sed   http://paste.debian.net/163741/
Apr 18 22:30:42 * mranostay yawns
Apr 18 22:57:38 <pidge> ping
Apr 18 22:57:58 <pidge> I need a port opened on ab01 locally for a few minutes
Apr 18 22:58:00 <pidge> 12345
Apr 18 23:09:24 <seebs> So, I'm looking at some bits and pieces, and some of them use a bb.utils.contains(...), to which the last argument is "d".
Apr 18 23:09:50 <seebs> And I thought "that looks convenient, I shall use it".  And I copied it into some code for a class.  Whereupon it fails, because it has no idea what d is.  Which is a shame, because I don't know either.
Apr 18 23:10:03 <kergoth> d is always available in ${@} context, as well as in classes
Apr 18 23:10:09 <kergoth> but *not* in def'd python functions, unless you pass it in
Apr 18 23:10:13 <seebs> Ahh.
Apr 18 23:10:36 <kergoth> d is a variable referring to the metadata as of that point in time. see bitbake/lib/bb/data_smart.py for the class definition
Apr 18 23:11:00 <seebs> Hmm.  I am trying to do a thing with a handler, similar to the existing sanity check.
Apr 18 23:11:23 <kergoth> event handlers get the metadata as the data field of the 'e' object they get
Apr 18 23:11:28 <kergoth> e is the event which was fired
Apr 18 23:11:30 <seebs> Ahhh.
Apr 18 23:11:32 <kergoth> e.data is generally the metadata
Apr 18 23:11:38 <kergoth> same type of object as 'd' typically is in other contexts
Apr 18 23:12:02 <kergoth> events often have other pieces of information appropriate for the event. e.g. the task name for task start / completion
Apr 18 23:13:02 <seebs> Huh.
Apr 18 23:13:36 <seebs> Thanks, very helpful.  Now I can verify that TUNE_FEATURES is the value "${TUNE_FEATURES_tune-${DEFAULTTUNE}}", which is oddly free of feature values.  :P
Apr 18 23:15:27 <kergoth> see bb.event for the various event classes which get fired, if you end up wanting to know what's available in any given one
Apr 18 23:15:28 <kergoth> np
Apr 18 23:16:24 <seebs> So next up, what is the obvious way I have missed to get a value expanded, so I can see the value that would be gotten if using TUNE_FEATURES, rather than the literal spelling of it?
Apr 18 23:27:31 <kergoth> i don't understand the question
Apr 18 23:27:58 <seebs> Right now, if I call e.data.getVar("TUNE_FEATURES"), I get the literal string "${TUNE_FEATURES_tune-${DEFAULTTUNE}}".
Apr 18 23:28:24 <seebs> When actually used elsewhere, this gets expanded, such that ${DEFAULTTUNE} is filled in, giving the name of one of the specific TUNE_FEATURES_tune-foo variables, which is then expanded.
Apr 18 23:29:00 <seebs> So for instance, in other tune files there's stuff like TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppce500mc", "-mcpu=3500mc", "", d)}"
Apr 18 23:29:07 <kergoth> you didn't pass ', True' to getVar
Apr 18 23:29:12 <seebs> Ohhhh.
Apr 18 23:29:14 <kergoth> like every other use of getVar anywher ein the metadata.
Apr 18 23:29:32 <seebs> This is what I get for not reading the source of bb.utils.contains carefully enough.  :)
Apr 18 23:29:34 <kergoth> the second argument is 'expand', telling it whether you want the unexpanded or expanded value
Apr 18 23:29:54 <kergoth> in retrospect defaulting to unexpanded was stupid
Apr 18 23:29:58 <kergoth> it's almost never used that way
Apr 18 23:30:02 <kergoth> but it's a bit late to change that :)
Apr 18 23:30:23 <seebs> Huh.  Depending on how many usages there are, it might not be super hard to fix.
Apr 18 23:31:10 <kergoth> thats assuming you want to break compatibility with all the layers out there that you don't know about.
Apr 18 23:31:21 <kergoth> you don't control all the layers that exist :)
Apr 18 23:31:30 <seebs> Well, yeah.  I mean, I don't know about them.  Clearly they are Someone Else's Problem.
Apr 18 23:31:36 <kergoth> worse, break compatibility in who knows what ways. it won't error, it'll just behave differently
Apr 18 23:31:45 <kergoth> which will be nearly impossible to check for
Apr 18 23:33:32 <seebs> Yeah.  Drat.
Apr 18 23:34:04 <kergoth> if it'd error, i could see doing it, because then at least others will see the change right away and recognize they need to adjust th eir code..
Apr 18 23:34:17 <kergoth> otherwise, it needs to be postponed until a theoreticla change to a new file format, imo
Apr 18 23:34:51 <seebs> I suppose the brute force solution exists:  Change the name and make .contains throw an error.  :P
Apr 18 23:35:25 <seebs> I have discovered an interesting thing, which is that conf/machine/* files in my local layer are ignored if the poky/meta layer has the same files, but used if it doesn't.
Apr 18 23:35:37 <kergoth> your layer order in BBLAYERS is incorrect
Apr 18 23:35:41 <seebs> Ahh.
Apr 18 23:35:47 <kergoth> needs to be in order of highest priority to lowest
Apr 18 23:35:59 <kergoth> (assuming the layer is appending ot bbpath, not prepending -- most append)
Apr 18 23:36:11 <seebs> Ah-hah.
Apr 18 23:36:20 <kergoth> unfortunately recipe priority is controlled by BBFILE_PRIORITY_, whereas conf/class priority is controlled by bbpath, which is controlled by layer.conf parse order
Apr 18 23:36:52 <seebs> eww
**** ENDING LOGGING AT Thu Apr 19 02:59:59 2012

**** BEGIN LOGGING AT Thu Apr 19 02:59:59 2012
Apr 19 08:58:11 <ericben> bluelightning: hi, did you recently tried to use a meta-toolchain-qte ? It seems there a user rights problems on some diretories (ex : $ ls -al /usr/local/oecore-x86_64/sysroots/armv5te-oe-linux-gnueabi/usr/share/ |grep qtopia leads to : drwx------  3 root root   4096 19 avril 10:38 qtopia so a user can't reand the mkspecs)
Apr 19 08:59:36 <ericben> bluelightning:  that's with oe-core + meta-oe (but oe-core is at 1a82989345fb98becb487d270fd93a5e6dffeb47 which was the 5 april so maybe the problem was fixed since that comit, I have to pull the sources)
Apr 19 09:00:05 <bluelightning> ericben: I haven't tried recently, but that does seem a little strange :/
Apr 19 09:01:18 <ericben> bluelightning: in fact all the directories under qtopia are 700. I have a build crash during do-install of qt4e because the drive was full, maybe that's the reason of my problem.
Apr 19 09:03:06 <RP__> ericben: from what I remember we force the user to root:root during the toolchain tarball creation
Apr 19 09:03:56 <RP__> ericben: http://git.openembedded.org/openembedded-core/tree/meta/classes/populate_sdk.bbclass - "tar --owner=root --group=root "
Apr 19 09:05:09 <RP__> ah, sorry, I though you meant owned by qtopia. The permissions likely get preserved
Apr 19 09:05:20 <ericben> RP__: ok forcing the user root is not really a problem but having the dir 700 is a problem espacially for the mkspecs as qmake need to acess these files. I'm launching a clean build with enough disk on an other build host to see if I repdouce it or if that was a consequence of the disk full
Apr 19 09:05:51 <RP__> ericben: agreed, 700 permissions are an issue
Apr 19 09:40:30 <ericben> RP__: I had a strange thing. I updated oe-core (git pull) and started to rebuild meta-toolchain-qte, then I get this error : echo: /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libc.so.6: version `GLIBC_2.14' not found (required by echo) and | echo: /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libc.so.6: version `GLIBC_2.14' not found (required by /home/ebenard/OE-CORE/build/tmp-eglibc/sysroots/x86_64-linux/usr/bi
Apr 19 09:40:48 <ericben> RP__: removing the installed SDK from /usr/local/oecore-x86_64 solved the problem
Apr 19 09:41:00 <ericben> so it seems the build system is impacted but the SDK installed on the same host
Apr 19 09:41:06 <ericben> impacted by
Apr 19 09:41:51 <ericben> these error were during : NOTE: package pseudo-nativesdk-1.3-r9: task do_install: Failed
Apr 19 09:45:20 <RP__> ericben: hmm, just pseudo-nativesdk failing or other issues too?
Apr 19 09:46:01 * RP__ wonders what pseudo install is doing :/
Apr 19 09:46:03 <ericben> RP__: well I removed the sdk so for the moment the build is still running
Apr 19 09:47:32 <ericben> RP__: gdb-cross-canadian also failed (not detecting python but python & python-nativesdk are still building)
Apr 19 09:47:51 <RP__> ericben: I suspect there might be an environment variable clash if you build pseudo whilst running under pseudo!
Apr 19 09:48:20 <ericben> what do you mean " whilst running under pseudo" ?
Apr 19 09:48:39 <RP__> ericben: pseudo-nativesdk do_install runs with pseudo-native in memory as an LD_PRELOAD
Apr 19 09:49:14 <RP__> seebs: I think I have a fun bug for you ;-)
Apr 19 09:49:17 <ericben> ok, the only thing I can tell is that this was working fine previously
Apr 19 09:49:28 <ericben> git pull on oe-core triggered the problem
Apr 19 09:49:55 <RP__> ericben: it will be the version update of eglibc-nativesdk, it became more recent than the system you're building on
Apr 19 09:51:40 <RP__> ericben: have you the full error log for that?
Apr 19 09:53:05 <ericben> I didn't cleansstate on pseud-nativesdk so I think I lost the log
Apr 19 09:53:25 <ericben> I did a cleansstate, sorry, I should sleep more to type better ;-)
Apr 19 09:53:58 <RP__> ericben: ok :/. We need to try and reproduce this and file a bug
Apr 19 09:54:39 <ericben> RP__: what I did : I have oe-core fetched on the 5 april. I built a meta-toolchain-qte for armv5 and installed the SDK on the host
Apr 19 09:55:03 <ericben> then git pull in openembedded-core and launched again bitbake meta-toolchain-qte triggered the problem
Apr 19 09:55:12 <ericben> the host PC is a fedora 16 64 bits
Apr 19 10:08:01 <ericben> ok and now gdb-cross-canadian-arm doesn't build anymore (failing on python detection with : conftest.c:95:20: fatal error: Python.h: No such file or directory) ... a cleansstate on python-nativesdk solved the problem.
Apr 19 12:08:30 <gizero> hi! is it possible for a recipe to ship a file in more than one of its packages? ...or is it a nonsense by-design?
Apr 19 12:13:49 <Crofton|work> gizero, you have to deal with more than one of these packages being installed at once
Apr 19 12:14:19 <lizhan> hello,all!  When creating and building a hello world project, i was puzzled by such an error:"configure: error: C compiler cannot create executables"  who can help me? thank you!
Apr 19 12:18:48 <gizero> Crofton, looking at populate_packages () in package.bbclass I see a list of "seen" files is maintained... and if a file is in this list, it is not considered any more for packaging. My question was to confirm this
Apr 19 12:20:22 <gizero> my concern comes from trying to import a recipe from meta-openembedded which implicitly lists a file in two different packages: this is python-twisted recipe
Apr 19 12:21:08 <gizero> since the package that ends up being empty is in a RDEPENDS for twisted, I end up with an error while building my image
Apr 19 12:22:42 <gizero> I know this specific recipe is not part of Yocto itself... maybe I can suggest a fix in meta-oe
Apr 19 12:30:20 <Zagor> RP__: we need a generic way to run command loops (like the latest runstrip) on PARALLEL_MAKE cores.
Apr 19 12:36:09 <Zagor> cursory googling suggests multiprocessing Pool.map is one way
Apr 19 13:09:54 <RP__> Zagor: hmm, that is worth thinking about, yes
Apr 19 13:09:59 <RP__> zeddii: around?
Apr 19 13:20:53 <Crofton|work> how about the next release is codenamed A, and the one after that B?
Apr 19 13:23:04 <RP__> zeddii: sorted now...
Apr 19 13:23:12 <RP__> Crofton|work: crazy talk
Apr 19 13:24:21 <Crofton|work> it sorts, you do not have the 2.0 problem
Apr 19 13:24:29 <Crofton|work> until you get to Z at least
Apr 19 13:25:32 <RP__> Crofton|work: then the AA takes you to court?
Apr 19 13:26:15 <jawilson|remote> where can I find the available options for "GUI_MACHINE_CLASS"?
Apr 19 13:28:21 <Zagor> I think we should have a triple-word codename. you know, break some new ground.
Apr 19 13:29:46 <bluelightning> super-beefy-miracle ?
Apr 19 13:29:47 <bluelightning> ;)
Apr 19 13:30:15 <Zagor> yay!
Apr 19 13:30:51 <Zagor> everybody knows more is better
Apr 19 13:31:55 * zeddii reads. 
Apr 19 13:32:18 <zeddii> ok. back to my other stuff. was dropping my car off for servicing.
Apr 19 13:38:22 <ag> Guys,
Apr 19 13:38:46 <ag> When checking for dependencies at rootfs, where does the build systemd check for rpm requirements?
Apr 19 13:38:50 <ag> In sysroot?
Apr 19 13:39:00 <ag> system*
Apr 19 13:54:22 <Crofton|work> crap, I need to get a leaky tire fixed
Apr 19 13:54:32 <Crofton|work> zeddii, thanks for the reminder :)
Apr 19 13:54:59 <zeddii> np :P
Apr 19 14:59:21 <msm> is anonymous python run in the other it's encountered in a file?
Apr 19 14:59:39 <kergoth> they're registered in the order they're seen, and run in that order, yeah
Apr 19 14:59:43 <kergoth> afaicr anyway
Apr 19 15:00:12 <fray> they are run in order and not concantenated like the _append()  right?
Apr 19 15:00:37 <fray> but there is no official order, it could litterly be any order -- or is something defined?
Apr 19 15:01:45 <kergoth> yeah, run in definition order but not concatenated
Apr 19 15:26:40 <ixak1> hello
Apr 19 15:28:38 <ixak1> I am trying to build a discovery-image and I have some problem fetching the systemd
Apr 19 15:28:51 <ixak1> do someone has been working with this feature?
Apr 19 15:37:50 <msm> kergoth: fray: trying to determine why I can't change my PR
Apr 19 15:38:15 <msm> or I can but I think certain things get processed as if the anonymous python was not run
Apr 19 15:38:19 <msm> and it fails
Apr 19 15:54:48 <kergoth> can someone explain why task-core-sys-services includes two different rpc port mapping servers?
Apr 19 15:54:53 <kergoth> (portmap and rpcbind)
Apr 19 16:05:09 <seebs> I would guess it's because each of them was added by someone who knew that name for the service and needed the service.  :P
Apr 19 16:07:32 <kergoth> heh
Apr 19 16:07:39 <kergoth> i guess so, i'll prep a patch
Apr 19 16:08:09 <kergoth> rpcbind is the newer, better one, afaik, but its recipe doesn't provide a startup script
Apr 19 16:08:12 * kergoth will investigate
Apr 19 16:39:58 <wmat> Jefro: ping
Apr 19 16:40:14 <Jefro> wmat hey! hows things
Apr 19 18:35:22 <kergoth> damnit, keep getting 'no init found' on my runqemu attempts, even though init is in the image
Apr 19 18:35:26 <kergoth> hmm
Apr 19 18:36:01 <seebs> The worst part, for me, about that message?  All the things I've seen cause it in the past are usually impossible.
Apr 19 18:36:19 <seebs> The chances that you're accidentally generating an ELF init on an a.out-only kernel, for instance?  Low.
Apr 19 18:37:21 * kergoth tries with 'poky' instead of 'poky-tiny' to check sanity
Apr 19 18:59:27 <RP__> seebs: did you see the interesting pseudo build issue earlier?
Apr 19 19:01:29 <seebs> No.
Apr 19 19:02:39 <RP__> seebs: the summary, if you build and untar meta-toolchain's tarball, then try and build pseudo-nativesdk on a system with (e)glibc2.13 it will break during do_install
Apr 19 19:03:18 <RP__> seebs: I think something in the build variables must clash with pseudo's makefile
Apr 19 19:03:27 <seebs> That is totally possible.
Apr 19 19:03:41 <RP__> er, pseudo's environmental variables clash with the build and makefile variables
Apr 19 19:04:12 <RP__> pseudo-native would be running whilst executing the pseudo-nativesdk do_install
Apr 19 19:05:15 <RP__> seebs: Sadly the person who hit this did a cleansstate but I noted it to attempt to reproduce and file a bug
Apr 19 19:06:32 <seebs> Hmm.
Apr 19 19:07:21 <seebs> That's odd.  I don't immediately see anything there that should be faililng.
Apr 19 19:07:24 <seebs> agggh
Apr 19 19:07:33 <seebs> Okay, so apparently there is nation-wide tornado siren drill today.
Apr 19 19:08:18 <seebs> This produced all sorts of hilarious hijinx as tornado sirens went off during heavy rain at a time when there are not normally drills, five minutes before someone had to leave to drive to an appointment.
Apr 19 19:08:19 <khem> seebs: which nation ?
Apr 19 19:08:26 <seebs> I dunno, some stupid one.
Apr 19 19:08:48 <seebs> I'm used to our regional drills, which happen at predictable times at least.
Apr 19 19:09:06 <RP__> khem: thanks for the qemu patch tip :)
Apr 19 19:09:44 * RP__ is used to fog horns...
Apr 19 19:13:15 <khem> RP__: cool it fixed stuff
Apr 19 19:13:50 <khem> RP__: I kind of was lucky with that since you did most of work by pinpointing it to a function
Apr 19 19:14:06 <khem> its a bit easier than
Apr 19 19:14:45 <RP__> khem: Getting it to a reproducible issue certainly helped a lot, my brain was just about fried by that point though :)
Apr 19 19:14:55 <khem> I imagine :)
Apr 19 19:15:09 <khem> from the length of printf strings hehe
Apr 19 19:15:22 <RP__> khem: yes, those were horrible :)
Apr 19 19:15:40 <khem> when is 1.2 coming out
Apr 19 19:15:41 <RP__> khem: it was interesting to see the bits of the UI that broke - very subtle
Apr 19 19:16:05 <khem> yes indeed when it comes to SSE and stuff I immediately doubt qemu
Apr 19 19:16:10 <khem> or even hardware
Apr 19 19:16:14 <RP__> khem: -rc4 will have a full test report by mid next week, it would then have a week to mirror and release in theory
Apr 19 19:16:24 <RP__> khem: if we go to a -rc5 it will take longer
Apr 19 19:16:33 <khem> I have found bugs in intel's WMMX coprocessor in past
Apr 19 19:16:58 <RP__> khem: bugs known as "features"? :)
Apr 19 19:17:00 <khem> ok end of April is what then we are looking at
Apr 19 19:17:09 <RP__> khem: sometime around then I think, yes
Apr 19 19:17:24 <khem> SIGFOOD bbl
Apr 19 19:26:16 <RP__> seebs: Sadly my test here didn't reproduce :(
Apr 19 19:27:17 <seebs> Did you make sure it was in season, and that there was nothing nearby that sounded like a predator?  Because I think that's the problem they had with pandas.
Apr 19 19:28:00 <seebs> Anyway, off the top of my head, I can't think of anything pseudo sets in its environment that ought to break anything.  Unless, hmm.
Apr 19 19:28:11 <seebs> Well, the test cases might act up, if someone tried to run them.
Apr 19 19:28:59 <RP__> The error quoted earlier was "I had a strange thing. I updated oe-core (git pull) and started to rebuild meta-toolchain-qte, then I get this error : echo: /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libc.so.6: version `GLIBC_2.14' not found (required by echo) and | echo: /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/libc.so.6: version `GLIBC_2.14' not found (required by /home/ebenard/OE-CORE/build/tmp-eglibc/sysroots/x86_64-linux/usr/bi"
Apr 19 19:30:23 <seebs> heyyy
Apr 19 19:30:31 <seebs> I have... Someone totally mentioned a bug like that to me recently.
Apr 19 19:31:07 <seebs> Wait, is this... This sounds exactly like bug 2299 to me.
Apr 19 19:32:28 <RP__> seebs: kind of related but very different
Apr 19 19:32:49 <RP__> seebs: both are caused with a system libc older than the nativesdk one
Apr 19 19:33:06 <seebs> Yeah.  Hmm.
Apr 19 19:33:26 <RP__> The pseudo recipe is also filled with bashisms
Apr 19 19:33:32 <fray> that sounds about right.. pseudo should be linked to the -system- glibc, not the native one...
Apr 19 19:33:49 <fray> RP__, well bash was required when teh recipe was constructed  :P
Apr 19 19:33:52 <seebs> I seem to recall that there is talk of building pseudo against a new libc we build for our host tools and such.
Apr 19 19:34:10 <fray> problem with building for the new libc is that the system binaries are not going to be using this new libc
Apr 19 19:34:28 <fray> what you really want is a pseudo that works for both the new and old libcs..  which isn't really what the original design was
Apr 19 19:34:46 <fray> the pseudo -binary- vs wrapper library could run w/ either libc..
Apr 19 19:34:51 <seebs> I am not even sure we CAN do that, although it's an interesting thought.
Apr 19 19:34:58 <fray> the wrapper itself shouldn't depend on a libc, but needs to work with whatever is loaded
Apr 19 19:35:04 <seebs> We'd have to do some runtime checksagainst libc.
Apr 19 19:35:16 <seebs> I guess it depends on how far apart they are.
Apr 19 19:35:19 <fray> seebs, ya.. but do we actually use versioned symbols?  I thought symbol resolution was manual
Apr 19 19:35:39 <seebs> Hmm.
Apr 19 19:36:30 <seebs> I think...We do have one check for that.
Apr 19 19:36:35 <RP__> well, we have this basically working fine
Apr 19 19:36:51 <seebs> wrapfuncs.in tries to get GLIBC_2.3 realpath.
Apr 19 19:36:54 <RP__> I just don't understand how do_install could break with an installed nativesdk recipe
Apr 19 19:37:10 <seebs> I have no idea why.
Apr 19 19:39:03 <seebs> Ahh, here we go.  pseudo commit c2f7c5ad, from June of last year.
Apr 19 19:39:07 <RP__> seebs: I thought I could see a reason, I'm failing to reproduce. I guess we see if anyone else reports it with a better reproducer
Apr 19 19:39:47 <seebs> The rationale was that we found some system on which dlsym("realpath", RTLD_NEXT) gave a version of realpath where realpath(name, NULL) failed and yielded EINVAL, and requesting GLIBC_2.3 of it worked.
Apr 19 19:40:08 <seebs> So we have a hook for preferring a version, and one case using it.  Which probably only ever had any effect on RHEL4 or something.
Apr 19 19:47:11 <RP__> seebs: ok, an strace -f of "bitbake pseudo-nativesdk -c install -f" is revealing
Apr 19 19:47:23 <RP__> seebs: somehow, it tried to load libpseido from /opt/
Apr 19 19:47:43 <seebs> that's interesting.  something changing library path?
Apr 19 19:49:05 <fray> once libpseudo is loaded it should preserve and set the LD_LIBRARY_PATH at least...
Apr 19 19:49:32 <fray> if it's getting changed thens omething fishy is happening.. but that also has the side effect that if you use a common directory for the pseudo componnets (with other libraries) they get added to the list..
Apr 19 19:49:40 <fray> that is the reason why we use .../lib/pseudo/lib
Apr 19 20:35:08 <sgw> RP you still around?  I have a question about quiltrc getting installed in /usr/bin - see quilt-0.51.inc, this is getting installed on the target side, this does not sound correct anymore.
Apr 19 20:59:14 <ant__> zeddii: ping
Apr 19 21:35:21 <RP__> sgw: hi
Apr 19 21:36:30 <sgw> Hi RP: I have been looking at the quiltrc thing, I think that's meant to be for the native, not target side?
Apr 19 21:40:31 <RP__> sgw: yes
Apr 19 21:40:59 <sgw> Ok, I will make the fix
Apr 19 21:42:39 <RP__> seebs: figured this out. "	create_wrapper ${D}${bindir}/pseudo LD_LIBRARY_PATH=${base_libdir}:${libdir}"
Apr 19 21:43:01 <seebs> oooh
Apr 19 21:43:06 <RP__> seebs: create_wrapper then does    "env $@ echo "Generating wrapper script for $cmd""
Apr 19 21:43:15 <RP__>    # run echo via env to test syntactic validity of the variable arguments
Apr 19 21:43:35 <RP__> so if you have an *old* toolchain installed in /opt, you lose
Apr 19 21:43:51 <seebs> eww
Apr 19 21:44:15 <seebs> Yeah, that's... I mean, it's an interesting way to check validity, but it's certainly vulnerable to unintended side-effects.
Apr 19 21:46:01 <seebs> Heh.  create_cmdline_wrapper has the same comment but doesn't actually do the env.
Apr 19 21:46:35 <RP__> I think we need to remove this "sanity" check
Apr 19 21:48:14 <seebs> I am inclined to think so, although there are very few variables that would have that effect, there are some and they're exactly the sort of thing you might want in a wrapper.
Apr 19 22:15:15 <seebs> Heh, RP__, when you mentioned the bashisms I went and stared at the pseudo recipe for a bit, but didn't spot those.
Apr 19 22:15:23 <seebs> I know to write =, but I'm so used to == that I don't see it.
Apr 19 22:15:59 <RP__> seebs: I have the same issue. I've changed the shell on my systems to dash to try and find more of these...
Apr 19 22:16:13 <RP__> I hate having /bin/sh as dash though :(
Apr 19 22:16:30 <seebs> I mostly use ksh as my native shell.  Unfortunately, wrlinux really needs bash, because a lot of things depend on it and we haven't had time to go fix them all.
Apr 19 22:16:41 <seebs> I actually prefer it as a /bin/sh, because it is less likely to do Stupid Stuff.
Apr 19 22:17:00 <seebs> Say, ! history, which is maybe not an awful idea, but having it expand even in single quotes is a dreadful idea.
Apr 19 22:19:36 <RP__> seebs: life is certainly easier that way
Apr 19 22:20:05 <kergoth> i like /bin/sh as dash, but you just can't trust people to use #!/bin/bash :(
Apr 19 22:20:07 <kergoth> makes me sad
Apr 19 22:20:39 <seebs> I have a long-term plan involving teams of assassins in cryogenic sleep who are woken only when a script using #!/bin/sh uses a bashism, but it's hard to get funding.
Apr 19 22:21:02 <seebs> The National Endowment for the Arts are basically cowards, is what I say.
Apr 19 22:22:56 <kergoth> you'd think we could use pysh or something to identify them, but i'm sure it'd be nontrivial
Apr 19 22:24:15 <RP__> kergoth: its an interesting thought...
Apr 19 22:25:29 <seebs> I suppose in theory you could make a bash that logged things whenever it hit a bashism, so stuff would work but you'd get a diagnostic log.
Apr 19 22:27:05 <kergoth> hmm, apparently there' s a checkbashisms script
Apr 19 22:27:07 <kergoth> wonder if it actually works
Apr 19 22:27:17 <kergoth> http://sourceforge.net/projects/checkbaskisms/
Apr 19 22:28:09 <kergoth> huh, i didnt' realize https://wiki.ubuntu.com/DashAsBinSh actually listed many of the particular bashisms
Apr 19 22:28:12 <kergoth> that's handy
Apr 19 22:31:08 <RP__> kergoth: yes, I've been using that :)
Apr 19 22:32:52 <seebs> I suspect my portable shell scripting book lists a fair number, though probably not all -- I mostly focused on what was portable rather than what wasn't.
Apr 19 22:33:18 <seebs> Biggest surprise:  Outside of embedded stuff, there are basically no systems to be found that don't have printf(1), even including some fairly old Sun and Digital stuff.
Apr 19 22:33:38 <seebs> So it turns out the most portable "echo -n" is "printf '%s'"
Apr 19 22:35:35 <kergoth> yeah, can't you run into echo -n hiccups if you pass it arguments that start with a -? since it doesn't support --?
Apr 19 22:35:41 <kergoth> printf is nice
Apr 19 22:36:07 <seebs> And some variants don't do -n, or do do -e, or use \c, or don't use \c, and so on.
Apr 19 22:36:26 <seebs> My one complaint is %c, which is interpreted as %.1s.  Which is useless.  %c should have been number->character.
Apr 19 22:36:43 * kergoth nods
Apr 19 22:37:36 <kergoth> it's occasionally amusing reading landley's blog posts complaining about utility portability while he works on toybox
Apr 20 02:50:57 <zoumpis> hello everybody
**** ENDING LOGGING AT Fri Apr 20 02:59:58 2012

**** BEGIN LOGGING AT Fri Apr 20 02:59:58 2012
Apr 20 08:51:51 <mckoan> good morning
Apr 20 08:55:43 <ixak> hello
Apr 20 08:55:45 <ixak> do so know how to get the target kernel linux version?
Apr 20 14:17:56 <ag> Cheers! is there any way to fetch a package from git with user and password?
Apr 20 14:35:52 <abustany> netrc file maybe?
Apr 20 14:37:21 <B4gder> if http is used, then netrc could work
Apr 20 14:37:32 <B4gder> otherwise you use the config/env variables
Apr 20 17:26:36 <seebs> Okay, I'm looking at 2351/2299.  And I am wondering about this.  It seems to me that we are building our own libc, then invoking the host's native tools that were not built against that libc, and this is crashing.
Apr 20 17:27:17 <seebs> Comment #5 on 2351 shows that LD_LIBRARY_PATH=/opt/poky/... and running pwd crashes, and so far as I can tell that's without pseudo even involved.
Apr 20 17:27:47 <seebs> So basically, if we have our own libc, and it's in LD_LIBRARY_PATH, we must not ever invoke anything that's not built against that libc.
Apr 20 17:27:59 <seebs> And the reason this worries me is that /bin/sh is normally not built against our libc.
Apr 20 17:28:42 <seebs> So if you have an otherwise perfectly good binary linked against our libc, and it calls system(), we are almost certainly invoking an sh not aware of our libc.
Apr 20 17:32:26 <fray> it's also possible that executing binaries is loading the system's ld.so instead of our custom one.. (depends on RPATH settings and such).. I've never used the nativesdk mode before
Apr 20 17:32:37 <fray> I'm in the process of locally setting up some type of a reproducer machine
Apr 20 18:02:00 <khem> seebs: usually its not a problem if thhost libc is older than what we compile with nativesdk but since we have 2.13 and most of distros moved past it we can start to see these issues
Apr 20 18:02:44 <khem> that said ldso path is encoded in the elf itself
Apr 20 18:03:04 <khem> if not than we should do that and not rely on LD_* vars
Apr 20 18:08:55 <seebs> I'm actually not sure.  I thought that you could override the ld.so.  Huh.  Come to think of it.
Apr 20 18:09:18 <seebs> Am I confused, or does "ld.so <cmd> <args>" work?  I seem to recall running into that once.
Apr 20 18:09:28 <khem> it should work
Apr 20 18:09:53 <seebs> Because if there's a way to do that, we can force the use of the ld.so that we want.  Although it's expensiveish.  Hmm.
Apr 20 18:10:27 <khem> there is ORIGIN which is used to do it as well
Apr 20 18:10:52 <seebs> Well, okay, what if we had a static binary (thus bypassing ld.so issues) which assembled an argv[] that was like its own, but prefixed with /path/to/ld.so, and did an execv of that, and symlinked this all over the place?
Apr 20 18:12:12 <seebs> Hmm.  What we really want is an ld.so that is "smart" (I use the term loosely) enough to pick the right libc.  :P
Apr 20 18:13:13 <khem> yes but plethora of distros out there with older and newer versions
Apr 20 18:13:18 <khem> its a hard thing
Apr 20 18:15:00 <seebs> Hmm.  Okay, this may be a stupid idea, but.  If we're going to be doing host tools with their own libc, how painful would it be to just link them against it statically and not *need* ld.so?
Apr 20 18:15:49 <khem> seebs: quite painful. 1. glibc static linking is not sound
Apr 20 18:15:56 <khem> 2. binaries will bloat
Apr 20 18:16:35 <seebs> Hmm.
Apr 20 18:17:19 <khem> seebs: but its a worthwhile thing
Apr 20 18:17:37 <seebs> What if we only built our own libc when it was newer than host libc?  We assume binaries will still run on a newer libc, and presumably we'll be less afraid of bugs on a libc that's pretty new.
Apr 20 18:17:43 <khem> I have generated fully static cross toolchain which then worked on almost everything
Apr 20 18:18:10 <khem> seebs: the problem is we distribute the sdk
Apr 20 18:18:14 <seebs> Yeah, I am still stunned by the idea that someone would make a libc that couldn't reliably be linked statically.  That seems sort of crazy.  :P
Apr 20 18:18:24 <khem> and we dont know what sdkhost distro will be
Apr 20 18:18:37 <seebs> Do we have an installer that could quietly rename our libc.so out of the way if we think it's too old?  :)
Apr 20 18:19:26 <khem> heh now the same installer will need a bug reporting tool which will inform about the smartness when someone reports a bug
Apr 20 18:20:19 <khem> I think containing the environment it a good thing for bug reproducability
Apr 20 18:20:38 <khem> seebs: so what is the problem that lead us to discuss all this :)
Apr 20 18:21:19 <seebs> 2351/2299, which are reported as pseudo things, but I think pseudo is merely a symptom.
Apr 20 18:21:36 <seebs> Basically, on the affected systems, if you have /opt/poky/mumble in LD_LIBRARY_PATH, host system binaries coredump.
Apr 20 18:21:44 <khem> yocto bug# these are
Apr 20 18:21:47 <seebs> Yeah.
Apr 20 18:21:55 <khem> oh
Apr 20 18:22:03 <seebs> And the thing is, we have to have that in LD_LIBRARY_PATH for our binaries to run.
Apr 20 18:22:09 <khem> because we have a libc in /opt/blah/blah ?
Apr 20 18:22:13 <seebs> Yup.
Apr 20 18:22:31 <khem> hmmm
Apr 20 18:22:31 <seebs> I guess we could make pseudo fix it by having pseudo be aware enough to modify LD_LIBRARY_PATH for things other than itself.
Apr 20 18:23:06 <seebs> Something like LD_LIBRARY_WHITELIST=/opt/poky;/opt/poky:/opt/poky;/path/to/project
**** ENDING LOGGING AT Fri Apr 20 18:23:12 2012

**** BEGIN LOGGING AT Fri Apr 20 18:24:16 2012
Apr 20 18:24:21 <khem> LD_LIBRARY_PATH use is bad in general
Apr 20 18:24:24 <seebs> so you can specity the paths containing executables which can be run with /opt/poky in LD_LIBRARY_PATH.
Apr 20 18:24:25 <seebs> Yeah.
Apr 20 18:24:27 <khem> it was meant for debugging only
Apr 20 18:24:35 <khem> debugging libc that is
Apr 20 18:24:48 <seebs> Well, we could also just not use LD_LIBRARY_PATH for our executables, and use RUNPATH/RPATH.
**** ENDING LOGGING AT Fri Apr 20 18:25:00 2012

**** BEGIN LOGGING AT Fri Apr 20 18:26:19 2012
Apr 20 18:26:25 <seebs> I think that's only processed *after* ld.so has already been picked, though.
Apr 20 18:26:40 <seebs> My next idea was to have a static wrapper which does something to the effect of /opt/poky/lib/ld.so $*
Apr 20 18:27:09 <seebs> But that actually doesn't work either because you have to change the binary name to point to the "real" binary, and I don't think ld.so's command-line usage lets you use an artificial argv[0]
Apr 20 18:27:27 <khem> ld.so path is also encoded in ELF
Apr 20 18:27:54 <khem> so if we use right --dynamic-linker /path/to/ldso during link it should point to our ldso
Apr 20 18:27:56 <seebs> Hmm.  So then we'd just statically set that to /opt/poky or whatever, and not use LD_LIBRARY_PATH.  That would probably work.
Apr 20 18:28:23 <khem> let me think about it during lunch
Apr 20 18:28:39 <seebs> Oh, how dare you put your own survival above my personal convenience!  :P
Apr 20 18:28:47 <khem> heh heh
Apr 20 18:28:49 <seebs> (I hang out on MMO forums sometimes.  It's starting to affect the way I think.)
Apr 20 18:29:08 <khem> I like that cat like attitude :)
Apr 20 18:29:34 <khem> dogs have masters cats have staff
Apr 20 18:31:39 <khem> 0x000000000000000f (RPATH)              Library rpath: [$ORIGIN/../usr/lib:$ORIGIN/../lib]
Apr 20 18:32:11 <khem> hmmm ORIGIN is the directory where binary is so it will mean ld.so loads libraries relative to path of binary
Apr 20 18:33:58 <seebs> Yeah.  Which is actually very often what we want.
Apr 20 18:34:08 * _darknighte_ notes that khem is like a cat
Apr 20 18:34:09 <seebs> And a side note:  $ORIGIN is resolved AFTER expanding symlinks.
Apr 20 18:34:40 <seebs> Not that this has ever caused me to spend a week or so chasing an extremely erratically-reproduced bug involving our "linkdir" shadowing of host tools.
Apr 20 18:35:35 <khem> _darknighte_: hah
Apr 20 18:35:55 <khem> _darknighte_: I am just a dog
Apr 20 18:36:13 <_darknighte_> heh. a dog with a cat attitude.  sounds confusing.
Apr 20 18:37:34 <seebs> We have a cat with a dog attitude.
Apr 20 18:37:51 <seebs> It follows me around, and obeys some commands.
Apr 20 18:38:05 <khem> _some_ thats the problem
Apr 20 19:06:01 <vmeson> what code generates the file for "Export report" on http://packages.yoctoproject.org/ ?
Apr 20 19:06:15 <vmeson> Webpy. Version 1.3 ?
Apr 20 19:13:33 <vmeson> webpy is  the webserver - looks like meta/classes/distrodata.bbclass is useful...
Apr 20 21:18:02 <_darknighte_> Crofton: Crofton|work: you around?
**** ENDING LOGGING AT Sat Apr 21 02:59:59 2012

**** BEGIN LOGGING AT Sat Apr 21 03:00:00 2012
**** ENDING LOGGING AT Sun Apr 22 03:00:00 2012

**** BEGIN LOGGING AT Sun Apr 22 03:00:01 2012
Apr 22 14:27:20 <RP__> fray, seebs: Don't suppose you're around?
Apr 22 15:44:48 <seebs> Nope.
**** ENDING LOGGING AT Mon Apr 23 02:59:58 2012

**** BEGIN LOGGING AT Mon Apr 23 02:59:58 2012
Apr 23 07:21:36 <mckoan> good morning
Apr 23 08:46:20 <bluelightning> morning all
Apr 23 09:12:24 <Zagor> RP__, bluelightning: has there been any work/thought done on trying to remove the use of run-postinsts.awk?
Apr 23 09:12:47 <RP__> Zagor: Remove as in no postinsts on the target?
Apr 23 09:12:52 <Zagor> RP__: yes
Apr 23 09:13:38 <Zagor> I've been looking at it a little but figured I should sync with any existing ideas before spending more time
Apr 23 09:15:04 <RP__> Zagor: We've slowly been moving more of them to rootfs time
Apr 23 09:15:29 <RP__> Zagor: The next big win is likely to batch all the icon cache stuff into one operation. There were some patches in relation to this on the mailing list
Apr 23 09:16:00 <RP__> Zagor: That would still run on the target but would be faster. I'd love someone to look and see if we could figure out a way to generate these files at rootfs generation time
Apr 23 09:19:46 <Zagor> RP__: right, that's what I'm trying to do. I'll keep tinkering and see what I can come up with.
Apr 23 09:20:38 <RP__> Zagor: We're way better than we used to be, not that it probably helps much :)
Apr 23 09:20:47 <RP__> Zagor: The useradd stuff has been painful
Apr 23 09:21:00 <Zagor> it's good that we are better. it would be better if we were good. ;-)
Apr 23 09:21:00 <RP__> we have cross-prelink, and cross ldconfig
Apr 23 09:21:36 <RP__> Zagor: Batching them into a single operation would likely make us "good"
Apr 23 09:21:52 <RP__> with further room for improvement
Apr 23 09:23:48 <Zagor> I have a pretty small system for testing (only root, no graphics) so I'll focus on low hanging fruit first.
Apr 23 09:26:18 <RP__> Zagor: there shouldn't be much getting deferred in that case...
Apr 23 09:28:46 <Zagor> I have 18 *.postinst. 17 ldconfig calls + bash.
Apr 23 09:39:44 <Zagor> oh right, this is actually pure poky core-image-minimal.
Apr 23 09:42:12 <RP__> Zagor: The ldconfig calls should be at rootfs time not on target
Apr 23 09:49:02 <Zagor> ehm, right you are. too little coffee...
Apr 23 10:43:10 <RP__> Zagor: you had me worried as ldconfig not working would be the last thing I need right now coming up to release ;-)
Apr 23 11:48:16 <GNUtoo-desktop> hi, what's the best way to handle that problem:
Apr 23 11:48:40 <GNUtoo-desktop> while compiling my bug20 kernel it does a compile perf function
Apr 23 11:48:58 <GNUtoo-desktop> but tools/perf/Makefile has -Werror
Apr 23 11:49:00 <GNUtoo-desktop> and that fails
Apr 23 11:49:21 <GNUtoo-desktop> so I tried CC += "-Wno-error=foo" with foo beeing the reason of the error
Apr 23 11:49:25 <GNUtoo-desktop> but it didn't fix it
Apr 23 11:49:34 <GNUtoo-desktop> so I wonder if I should disable perf
Apr 23 11:49:39 <GNUtoo-desktop> or remove the -Werror
Apr 23 11:49:41 <GNUtoo-desktop> or fix the errors
Apr 23 11:53:03 <GNUtoo-desktop> ah there is a WERROR thing in the Makefile that govern the use of it
Apr 23 11:53:11 <GNUtoo-desktop> I'll try WERROR=9
Apr 23 11:53:12 <GNUtoo-desktop> oops
Apr 23 11:53:15 <GNUtoo-desktop> I'll try WERROR=0
Apr 23 12:48:39 <likewise> galak: hi there
Apr 23 15:24:19 <seebs> d'oh
Apr 23 15:24:44 <seebs> Just a followup to something I said a few days ago:  It just occurred to me that, obviously, we can't use statically linked code for everything, because pseudo can't handle static linking.
Apr 23 15:31:44 <fray> yup.. painful
Apr 23 15:32:02 <fray> I was just mentioning to seebs that I had to do something similar to this a long time ago..
Apr 23 15:32:13 <fray> what I came up with was a wrapper system and an automated script to setup the wrapper..
Apr 23 15:32:27 <fray> we would build the tree as normal..  /bin, /sbin, /usr/bin, /usr/sbin, etc..
Apr 23 15:32:43 <fray> then the wrapper script would come in and move the bin and sbin (in each) to bin.real, sbin.real
Apr 23 15:33:21 <fray> then for every item in those directories either hard (or sym) link was generated for scripts, and a wrapper was added for executables.. (Determined via file magic).. executables were then invoked using the local ld.so
Apr 23 15:34:00 <fray> i.e.  $path_0/../lib/ld.so $path_0/../bin.real/$base_0 "$@"
Apr 23 15:34:19 <fray> simple and fairly easy to automate for something like an SDK
Apr 23 16:23:05 <onoffon> fray: I have worked out a layer called meta-qemuextra where right now I am having qemu machines for sh4, mips64 and armv7
Apr 23 16:23:15 <onoffon> err
Apr 23 16:23:45 * khem 's alias is onoffon
Apr 23 16:24:12 <khem> I have quite a few patches for mips64 support for oe-core
Apr 23 16:24:39 * khem is waiting for the release to happen 
Apr 23 16:28:50 <bluelightning> khem: sounds good :)
Apr 23 16:36:28 * zedd_ has a 64 bit malta booting on linux-yocto-dev as well  :P
Apr 23 16:36:43 <zedd_> hmm. my nic is gone
Apr 23 16:36:55 <zedd_> hmm. my nic is gone
Apr 23 16:36:57 <zedd_> argh
Apr 23 16:56:16 <likewise> khem: hi khem, so your new alias is an alias of 'powercycle'? :)
Apr 23 16:56:54 <likewise> khem: that doesn't give much confidence ;-)
Apr 23 18:44:20 <msm> im having some issues with gpsd
Apr 23 18:44:26 <msm> its cache some sysroot that points at the build machine
Apr 23 18:44:38 <msm> its some weird libtool / sstate-cache issue
Apr 23 18:44:44 <msm> has anyone seen something similiar?
Apr 23 18:49:50 <seebs> Well, "similar" meaning "some app built for an embedded target has host paths embedded somewhere"?  Only a few hundred times.
Apr 23 18:50:12 <seebs> I'd guess I haven't seen more than a hundred or so distinct causes, though.
Apr 23 18:50:38 <seebs> Eerily, the most common by far is "you mistakenly ran the build while the guy who could debug it wasn't around and then deleted the files and now it won't reproduce".
Apr 23 18:51:15 <fray> msm check if gpsd gets embedded paths from configure..  a simple "strings" or "grep" on the binary should help you.. if it does, you'll have to go back to the sources and find them..
Apr 23 18:51:29 <fray> (note run this on a stripped version, otherwise you'll get a ton of hits from the debug info)
Apr 23 18:56:25 <msm> fray: did that already
Apr 23 18:56:45 <msm> grep '${OLD_PATH}' -r gpsd/
Apr 23 18:56:58 <msm> its not even gpsd its something else that gpsd is pulling in
Apr 23 18:57:17 <msm> I can clean gpsd - and then turn off my SSTATE_CACHE mirror and rm -rf my sstate-cache folder
Apr 23 18:57:21 <msm> and the issue is still present
Apr 23 18:58:06 <fray> are you using ccache?
Apr 23 18:58:17 <fray> if so -turn it off- it's a known failure with sstate_cache
Apr 23 18:58:24 <fray> you get errors about incorrect include paths and such
Apr 23 18:58:52 <msm> fray: since when is this a known error?
Apr 23 18:58:59 <msm> fray: yes sstate-cache is causing this
Apr 23 18:59:02 <fray> about a week and a half ago or so?
Apr 23 18:59:09 <msm> fray: no this is old branches
Apr 23 18:59:11 <fray> bug was filed a lot longer then that..
Apr 23 18:59:14 <fray> this is all branches..
Apr 23 18:59:44 <fray> when ccache is running it presents precompiled sources to gcc..  gcc ignores the --sysroot and then can't find the headers..
Apr 23 18:59:56 <fray> the fix was to the compiler (about a week or so ago) to add a magic %i if I remember right to the spec..
Apr 23 18:59:58 <msm> oh
Apr 23 18:59:59 <msm> wait
Apr 23 19:00:02 <msm> not sstate-cache
Apr 23 19:00:04 <msm> just ccache?
Apr 23 19:00:10 <fray> ccache when used with sstate-cache
Apr 23 19:00:29 <fray> since teh sstate-cache stuff caused "different" paths to show up..  ccache used them and gcc never corrected them
Apr 23 19:00:49 <fray> the error was specifically around header locations..
Apr 23 19:00:56 <fray> failures in configure...
Apr 23 19:01:08 <msm> fray: ok thanks - let me experiment some more
Apr 23 19:01:22 <msm> mine is in compile
Apr 23 19:01:29 <msm> its literally an invalid sytroot
Apr 23 19:01:32 <msm> you can see it printed out
Apr 23 19:01:33 <fray> could be related, but different symptoms then
Apr 23 19:01:51 <msm> I'm really confused how it's even deciding those args
Apr 23 19:01:55 <fray> I'd still suggest turning off ccache and retry the experiment..
Apr 23 19:02:02 <msm> LIBTOOL and/or LIBTOOLFLAGS
Apr 23 19:02:07 <msm> was my first though
Apr 23 19:02:20 <msm> its just on the link step… most gcc args have the right flags
Apr 23 19:02:30 <msm> im going to turn off ccache first and look again
Apr 23 19:02:31 <fray> dunno..
Apr 23 21:09:10 <ant__> khem: ping
**** ENDING LOGGING AT Tue Apr 24 02:59:58 2012

**** BEGIN LOGGING AT Tue Apr 24 02:59:58 2012
Apr 24 03:28:04 <Andy44> Hi everyone!  Is anyone around to chit chat for a few minuts?
Apr 24 03:40:37 <seebs> Nope.
Apr 24 03:40:44 <seebs> :)
Apr 24 04:06:31 <khem> Andy44: do u have questions re yocto then just ask
Apr 24 04:06:42 <Andy44> cool
Apr 24 04:09:55 <Andy44> Hey so I'm wondering about some specifics regarding where to point for your ADT toolchain's sysroot.  Specifically, I have the following questions (please keep in mind I'm learning all of this on my own with virtually no help or guidence other than this channel and the mailing list):
Apr 24 04:13:30 <khem> hmm where is toolchain installed ?
Apr 24 04:13:39 <khem> SDK that is
Apr 24 04:13:45 <Andy44> hold on
Apr 24 04:13:53 <Andy44> let me type this question out first :)
Apr 24 04:16:17 <Andy44> 1.  I'm trying to make a very small linux os to run my specific embedded application.  I really don't need much from the OS.  Also, a requirement is that I can read and write a custom PCIe FPGA design.  I've been able to build and remote debug some simple CPU TSC timing applications on my target core i7 sugarbay yocto core-image-minimal build...
Apr 24 04:17:09 <Andy44> Now I've been reading about how you don't necessarily need to use a kernal module to access PCIe devices in linux - you can use UIO.
Apr 24 04:19:03 <Andy44> I've been trying to work with this UIO concept and with building kernel modules.  However, it seems my toochain and sysroot are missing things.  For example, I've written a program that a book told me should reference "/linux/module.h" and that file is not under my /usr/include folder.
Apr 24 04:19:24 <Andy44> If I look at the core-image-sato-sdk sysroot i can find that file.
Apr 24 04:19:48 <khem> it seems you are building external kernel module
Apr 24 04:19:51 <Andy44> So I guess my question is - what's the best practice for setting up your toolchain?
Apr 24 04:20:12 <Andy44> well I haven't decided that yet.
Apr 24 04:21:10 <Andy44> all I know is I keep running into points where I need header files that arn't there because my sysroot was downloaded from the yocto website and extracted into the /opt/poky/1.1.1/ folder.
Apr 24 04:22:02 <Andy44> do people normally just build their toolchain against their yacto-derrived target sysroot?  Is there a better way to do it?
Apr 24 04:22:58 <Andy44> khem - is there a better way to do it?  Or should I start by decideing if I need to write a kernel module vs. a user space UIO "driver"
Apr 24 04:25:03 <Andy44> I find it's easy to bomb through manuals to get simple things done but questions like this simply require experience to answer correctly.  a lot like most software arch questions...
Apr 24 04:25:15 <khem> ok the SDK is mainly good for app development
Apr 24 04:25:30 <Andy44> sure
Apr 24 04:25:35 <khem> for kernel modules you need to have kernel headers which are not sanitized
Apr 24 04:25:43 <khem> in other words you need kernel src tree
Apr 24 04:25:53 <Andy44> oh. that's a new idea -what does that mean?
Apr 24 04:26:04 <Andy44> sanitized?
Apr 24 04:26:06 <khem> thats why I asked
Apr 24 04:26:12 <Andy44> ok
Apr 24 04:26:15 <khem> are you doing an application or a kernel mod
Apr 24 04:26:37 <khem> for kernel mod there a different ways
Apr 24 04:26:41 <Andy44> I'd like to do everything in app space to avoid GLP lic conflics
Apr 24 04:26:56 <khem> ok, so you want to write an app
Apr 24 04:27:15 <Andy44> I currently use VXWorks and my app can access the PCIe directly by base addresses
Apr 24 04:27:18 <khem> then it should be simple to use SDK
Apr 24 04:27:25 <Andy44> yes, I guess so.
Apr 24 04:27:44 <khem> VxWorks and Linux arent particularly same
Apr 24 04:27:57 <Andy44> right, that's why this is so new to me.
Apr 24 04:27:58 <khem> an app that runs on vxworks will need some surgery to work on linux
Apr 24 04:28:02 <seebs> They're both software, they both have x's, that's PRETTY similar.  :P
Apr 24 04:28:42 <Andy44> well really we're porting a large software design.  It's all C++ and it all works around this FPGA design.
Apr 24 04:28:49 <khem> seebs: yeah right didnt think of X
Apr 24 04:29:04 <seebs> I just meant in the names.  :P
Apr 24 04:29:06 <khem> Andy44: so you can use --sysroot option
Apr 24 04:29:15 <autif> seeba++
Apr 24 04:29:21 <autif> seebs++
Apr 24 04:29:24 <Andy44> ha
Apr 24 04:29:38 <khem> Andy44: what does your SDK install tree looks like ? there should be a target sysroot inthere
Apr 24 04:29:41 <Andy44> khem: in what context do you mean?
Apr 24 04:29:50 <seebs> <-- been at WR for what is now officially something like 11 years, still never actually seen VxWorks.
Apr 24 04:29:50 <khem> which has all the headers and libs you need for app development
Apr 24 04:30:15 <khem> seebs: All I know is VxWorks is a facelift to VRTX
Apr 24 04:30:41 <Andy44> seebs: nice
Apr 24 04:31:13 <Andy44> I've been using VXWorks for all of 11 months and I'm litterally running to Yocto at 11pm
Apr 24 04:31:18 <Andy44> on a monday
Apr 24 04:32:06 <khem> seebs: ofcourse names it was I just made it big x
Apr 24 04:32:09 <Andy44> my SDK on my development ubuntu VM is just the toolchain download from the yocto site.
Apr 24 04:32:17 <khem> Andy44: ok
Apr 24 04:32:49 <Andy44> ...might be my first mistace - that's why I'm here. what's recomended?
Apr 24 04:32:56 <Andy44> mistake*
Apr 24 04:33:07 <khem> Andy44: it is installed under /opt
Apr 24 04:33:27 <Andy44> yeah
Apr 24 04:33:34 <khem> ok cd into sysroots
Apr 24 04:33:38 <Andy44> done
Apr 24 04:33:44 <khem> dir it should be somewhere under that tree
Apr 24 04:33:57 <khem> what dirs are under sysroots
Apr 24 04:34:32 <Andy44> sorry - it's "x86-64-poky-linux
Apr 24 04:34:34 <Andy44> "
Apr 24 04:35:11 <Andy44> "x86_64-poky-linux" i mean
Apr 24 04:35:22 <khem> just one dir
Apr 24 04:35:56 <Andy44> ahh no. there's also "x86_64-pokysdk-linuk"
Apr 24 04:36:23 <Andy44> so? am I supposed to use the sdk version?
Apr 24 04:36:26 <khem> Andy44: ok
Apr 24 04:36:35 <khem> Andy44: x86-64-poky-linux is the target sysroot
Apr 24 04:36:49 <khem> and x86_64-pokysdk-linuk is host sysroot for your build machine
Apr 24 04:36:53 <Andy44> yeah and that works for simple stuff
Apr 24 04:37:21 <khem> what does not work ?
Apr 24 04:38:18 <khem> you might need to add some more dev libs and headers if you are missing them which means you can generate a new sdk of your own
Apr 24 04:38:24 <Andy44> for example, for testing making kernal modules earlier today I was looking for an include file called </linux/module.h> and it's not there
Apr 24 04:38:41 <khem> thats not a userspace app isnt it ?
Apr 24 04:38:47 <khem> I asked you beforehand
Apr 24 04:38:54 <khem> anyhow I have to go to bed
Apr 24 04:38:56 <Andy44> but, i mounted the file system found in the core-image-sato-sdk and found it there.
Apr 24 04:39:04 <Andy44> sorry yeah I was just testing though
Apr 24 04:39:13 <Andy44> I wanted to see if I could make it work
Apr 24 04:39:23 <khem> there are different sdks
Apr 24 04:39:23 <Andy44> thanks for your time anyway
Apr 24 04:39:28 <Andy44> ok
Apr 24 04:39:34 <khem> you could try the one which have more stuff in them
Apr 24 04:39:40 <khem> like graphics libs etc.
Apr 24 04:39:46 <khem> I dont know what your app is like
Apr 24 04:39:56 <Andy44> ok ok
Apr 24 04:40:07 <khem> and my crystal ball is broken :)
Apr 24 04:40:08 <Andy44> thanks again. sorry to keep you up
Apr 24 04:40:11 <khem> anyway good luck
Apr 24 04:40:14 <Andy44> lol thanks
Apr 24 04:40:33 <Andy44> seebs: u around?
Apr 24 04:40:46 <seebs> Sorta.
Apr 24 04:41:18 <Andy44> c'mon man! tell me this linux stuff is for the birds and make me go back to VXWorks ;)
Apr 24 04:42:53 <seebs> hah, no, I work on wrlinux and now some yocto stuff.
Apr 24 04:43:04 <seebs> brb.  the time has come to challenge our popcorn maker once more to the deadly dance.
Apr 24 04:43:17 <Andy44> well it's still wind river
Apr 24 04:44:31 <Andy44> no worries I'll take this up tomorrow. I feel like I'm not articulating my issues well.  I need to think about it more.  Thank you everyone for the insight.
Apr 24 04:47:57 <Andy44> I might have to go read Linux Device Drivers 3rd cover to cover or something.  dammit!
Apr 24 07:19:45 <gizero> hi! need help figuring out where/when modules.dep should be generated/deployed. I'm creating my own BSP with edison
Apr 24 07:20:01 <gizero> anyone can help?
Apr 24 08:29:44 <RP__> Andy44: It sounds like there are no kernel headers for kernel module development in your meta-toolchain derived sysroot
Apr 24 08:29:58 <RP__> Andy44: We've not considered meta-toolchain for kernel module development before
Apr 24 09:37:34 <mckoan> good morning
Apr 24 10:27:09 <dtatulea> hi. I'm having issues with bitbaking poky-image-sato from the edison release. m4 fails to compile
Apr 24 10:27:55 <dtatulea> http://pastebin.com/KdCxB48q
Apr 24 10:31:01 <dtatulea> Erm, sorry. This was for poky :)
Apr 24 11:37:40 <RP> dtatulea: which operating system is that on?
Apr 24 11:38:03 <RP> dtatulea: thats a very early failure and its m4-native (i.e. being built for the host system)
Apr 24 11:38:20 <dtatulea> ubuntu x86_64 11.10
Apr 24 11:39:11 <dtatulea> but I cleared the build dir and re-started bitbake
Apr 24 11:39:19 <dtatulea> and it seems to be moving forward...
Apr 24 11:40:12 <RP> dtatulea: interesting. I have a x86_64 11.10 system here I run builds on all the time and have never seen that
Apr 24 11:45:33 <ant_work> RP: hi there. Buidling yocto kernels for armv4 (zaurus colllie) Ive seen a warning, being we tried to enable ARM_THUMB. Iirc there was a discussion about tune files long ago...do you think it's a sane behavior? It looks suspicious because that line is injected when ${ARM_INSTRUCTION_SET}" = "thumb"
Apr 24 11:46:03 <ant_work> (I was migrating the defconfigs from linux to linux-yocto, same toolchain)
Apr 24 11:48:13 <dtatulea> RP: thanks. Looks like a cosmic ray issue.
Apr 24 12:04:37 <RP> ant_work: There are some issues in that area we need to revisit
Apr 24 12:09:50 <ant_work> ok, I see
Apr 24 15:12:14 <zeddii> fray "pretended to not see" doesn't count.
Apr 24 15:12:47 <fray> no I overlooked it..
Apr 24 15:12:49 <zeddii> s/pretended to not see/ignored with malice/ ?
Apr 24 15:12:52 <fray> just found it in my mailbox
Apr 24 15:12:54 <zeddii> hehe
Apr 24 15:13:13 <darknighte> heh
Apr 24 15:13:42 <fray> as any FYI: https://wiki.yoctoproject.org/wiki/Release_1.2_Changes
Apr 24 15:14:09 * darknighte has sworn on several occasions that he didn't get an email only to find it sitting in his inbox
Apr 24 15:14:16 * darknighte usually blames it on gremlins
Apr 24 15:14:37 <zeddii> or corporate IT infrastructure. that's a catch all.
Apr 24 15:14:52 <zeddii> in particular if it's from family ;)
Apr 24 15:14:53 <darknighte> heh, in my case, i really really can.
Apr 24 15:15:02 <ant_work> mail caught by spamassassin, that is
Apr 24 15:15:04 <darknighte> ask the TI guys about sending email to my mentor email
Apr 24 15:15:36 <zeddii> corporate sanity filters, throttling and hiding of mail.
Apr 24 15:15:39 * zeddii likes it
Apr 24 15:15:43 <fray> I think in the last year I've only had 1 real email that went to the corporate spam system.. however, I can could half a dozen that I didn't get..
Apr 24 15:15:57 <fray> just never showed up.. (I blame the blackberry server for rewriting the email and mangling it for that)
Apr 24 15:16:13 <fray> I got a mangled header, but nothing readable.. so I suspect it was that email
Apr 24 15:19:56 <zeddii> msm, talking dates. very brave.
Apr 24 15:20:39 <msm> zeddii: i took a whoooole month ;)
Apr 24 15:20:53 * zeddii nods
Apr 24 15:21:01 <zeddii> clearly you've been trained :P
Apr 24 15:21:17 <fray> ;)
Apr 24 15:21:33 <zeddii> s/trained/burned/
Apr 24 15:21:42 * fray wishes his fingers would stop popping.. wonder if the weather is changing
Apr 24 15:48:38 <bluelightning> zeddii: one of the other things missing from the 1.2 change list is kernel changes... I've noted some but not others
Apr 24 15:51:26 <zeddii> I'll draw up a list.
Apr 24 15:51:40 <bluelightning> zeddii: cool, thanks
Apr 24 15:54:42 <fray> bluelightning there is on change I'm not seeing in the changelog..
Apr 24 15:55:00 <fray> the bitbake wrapper was modified to check for changes to pseudo, and if it detected any changes it would attempt to build pseudo first..
Apr 24 15:55:42 <bluelightning> fray: ah yes good point... I'll add that
Apr 24 15:55:57 <fray> f79184d4000708020f76d82330428b5e7a803642
Apr 24 18:39:11 <kergoth> damnit, bitbake just told me tasks failed with an exit code of 0
Apr 24 18:39:14 <kergoth> i hate it when that happens
Apr 24 19:15:10 <ka6sox> yes, but it failed OK...
Apr 24 19:18:01 <mranostay> heh
Apr 24 20:14:46 <RP> kergoth: master or an older bitbake?
Apr 24 20:14:58 * RP thought we'd nailed that down once and for all
Apr 24 20:23:03 <kergoth> master as of a few weeks ago
Apr 24 20:25:38 <RP> kergoth: hmm :/
Apr 24 20:25:46 <kergoth> agreed
Apr 24 20:26:03 * kergoth can't reproduce it reliably, though, punts for now
Apr 24 22:50:34 <kergoth> gah, bitbake just segfaulted trying to spawn depexp
**** ENDING LOGGING AT Wed Apr 25 02:59:58 2012

**** BEGIN LOGGING AT Wed Apr 25 02:59:58 2012
Apr 25 08:42:22 <ag> Is there any variable that can be used in a recipe to point to the layer dir?
Apr 25 08:42:34 <ag> Or i have to define on in the layer's conf?
Apr 25 08:46:22 <ag> one*
Apr 25 14:28:55 <khem> I am trying to add a machine to linux-yocto and I made a bare clone of kernel repo and then did stuff there now I want to use this as default SRC_URI for the kernel whats the best practice for this ?
Apr 25 14:29:14 <khem> KSRC seems to be not there anymore
Apr 25 14:29:29 <khem> so should I just brutely override SRC_URI ?
Apr 25 14:29:39 <khem> in the bbappend I have ?
Apr 25 14:36:31 <zeddii> either works. I just use the variables + bbappends in meta-kernel-dev. but recreating it without meta-kernel-dev should be simple enough.
Apr 25 14:36:40 <zeddii> khem, which machine ?
Apr 25 14:45:53 <khem> zeddii: I am adding mips64
Apr 25 14:46:01 <khem> essentially its malta
Apr 25 14:46:10 <khem> very similar to what we have
Apr 25 14:46:14 <khem> for 32bit
Apr 25 14:46:26 <khem> zeddii: I would also like to add qemush4
Apr 25 14:46:37 <khem> but thats next :)
Apr 25 14:46:50 <khem> zeddii: I am able to boot qemumips64
Apr 25 14:47:05 <khem> but usespace does not mount it fails to find init
Apr 25 14:47:22 <khem> but this was my own kernel
Apr 25 14:47:32 <zeddii> khem I already have a booting malta64 in linux-yocto-dev :)
Apr 25 14:47:34 <khem> and then I thought to do it *properly*
Apr 25 14:47:41 <khem> oh nice
Apr 25 14:47:59 <zeddii> but I didn't use the oe-core rootfs to boot.
Apr 25 14:48:19 <khem> I have a 64bit rfs
Apr 25 14:48:43 <khem> there are patches to OE that I will post soon to support mips64
Apr 25 14:48:45 <zeddii> I didn't have the tuning files available. So I used Wind River's 64 bit mips rootfs. so if we combine the two .. we should be done :)
Apr 25 14:48:48 <khem> n64 ABI
Apr 25 14:49:03 <khem> cool yes
Apr 25 14:49:04 <fray> well, sh tunings made it in pre freeze.. ;)
Apr 25 14:49:10 <fray> mips64 are there, but never tested.. :)
Apr 25 14:49:18 <khem> fray: yes it works
Apr 25 14:49:32 <khem> fray: I have not pushed my patches anywhere yet
Apr 25 14:49:55 <khem> but I have got mimimal image with oe-core to compile
Apr 25 14:49:58 <zeddii> nice. when I can send my next kernel update (3.4, tools, etc). then bolting the two together should be trivial.
Apr 25 14:50:09 <khem> yep
Apr 25 14:50:25 <khem> I have minimal image for SH4 building as well
Apr 25 14:50:32 <khem> but there I lack good kernel
Apr 25 14:50:43 <khem> I think SH4 needs some love
Apr 25 14:50:43 <fray> well, kernel.org works for sh4 doesn't it?
Apr 25 14:50:50 <zeddii> I like more simulations :)
Apr 25 14:50:52 <khem> 2.6.37 did
Apr 25 14:50:59 <khem> that is in oe.dev
Apr 25 14:51:07 <khem> I havent tried since then
Apr 25 14:51:11 <fray> There was a guy working on an sh4 port, which is why I fixed the tunings..
Apr 25 14:51:37 <khem> yeah may be I should ask him for valid .config.
Apr 25 14:52:03 <khem> let me prepare the patches today and I will push it on branch somewhere
Apr 25 14:52:12 <khem> my patchlist is growing too much
Apr 25 14:52:30 <fray> cool
Apr 25 14:52:42 <zeddii> that would be cool. I can try it against the -dev kernel (slightly different format, so it needs some associated tool changes).
Apr 25 14:54:28 <khem> zeddii: let me switch to dev kernel
Apr 25 14:54:38 <khem> I have been botching with linux-yocto_3.2
Apr 25 14:54:53 <khem> ok
Apr 25 14:55:17 <zeddii> you need a tool update as well, I can send the details. I'm sitting on growing pile myself.
Apr 25 17:49:06 <otavio> RP: I'll update u-boot to 2012.04.1; should I send a patch to update 2012.04 to 2012.04.1 or you will replace the patch on master-next?
Apr 25 17:57:04 <sgw> fray: question about the runtime dependency determination
Apr 25 18:00:00 <fray> ya, I'm here
Apr 25 18:00:12 <fray> -trying- to upgrade zypper.. ugh
Apr 25 18:34:03 <seebs> Does anyone outside WR and possibly Mentor Graphics care about issues pertaining to using prebuilt toolchain binaries, including a prebuilt libc?
Apr 25 18:34:35 <seebs> There's some issues here which I am looking at, and I would like to find out whether anyone else has opinions on them before I design something that solves my problem and no one else's.  :)
Apr 25 18:46:03 <incandescant> kergoth at Mentor has been working on that stuff most recently, I'm not really sure other than people who touch the code though
Apr 25 18:46:40 <seebs> Yeah, I've talked to him some.  I just figured I'd see whether anyone else was likely to care.
Apr 25 18:47:20 <seebs> In WRL, we had a concept of "multilibs" which we used to refer to any base prebuilt library (even if you had only one), and each CPU tuning set was tied to one.
Apr 25 18:47:47 <seebs> My thought was it might be cool if added-on layers that provided a toolchain had a good way to express "libc must be prebuilt and only these prebuilts exist".
Apr 25 18:53:33 <seebs> My sort of thought would be to, as a first step, tie every tuning to a base library type, and then have some kind of optional whitelist; if the whitelist is present, then defaulttune's library type must be in it.
Apr 25 18:54:09 <seebs> So far as I can tell this can be done without breaking anyone's existing stuff, and would make it super easy for hypothetical silicon vendor toolchain layers to impose such requirements if they wanted to.
Apr 25 19:00:22 <reaperofsouls> seebs: Montavista does as well. We have been providing our product using external tools with oe, long before yocto existed.
Apr 25 19:01:39 <fray> I think what seebs is asking is, is there a desire for a template or similar people can get started with to do this
Apr 25 19:01:44 <khem> seebs: prebuilt libc for embedded system might be an oversell
Apr 25 19:01:58 <seebs> We've been doing it for a longish time.
Apr 25 19:02:04 <seebs> It has some nice support payoff.  :)
Apr 25 19:02:16 <fray> khem, prebuilt libc is part of the toolchain setup..
Apr 25 19:02:25 <khem> heh but you built it *your* way
Apr 25 19:02:35 <fray> yes
Apr 25 19:02:38 <khem> and I may not want that
Apr 25 19:02:43 <khem> whereas I am ok for compiler
Apr 25 19:02:44 <reaperofsouls> khem: While we provide our libc in such away it can be rebuild(sans the rest of the toolchain), the majority of our customers don't rebuild glibc.
Apr 25 19:02:49 <khem> since that I dont ship on the target
Apr 25 19:03:00 <seebs> Well, in our live product, you have the *option* of rebuilding libc, but virtually no one does.
Apr 25 19:03:14 <khem> ok thats better
Apr 25 19:03:30 <khem> single reason OE became success was people could rebuild
Apr 25 19:03:45 <seebs> Hmm.  Okay, you raise a good point; the core implementation should have an override which will try to rebuild libc rather than using the prebuilt.
Apr 25 19:03:52 <reaperofsouls> seebs: Similar case here. Most of the customers that want to rebuild glibc and or the rest of the toolchain do so for purposes of never being stuck if X company disappears.
Apr 25 19:04:02 <seebs> In which case it ignores the whitelist, obviously.
Apr 25 19:04:35 <seebs> The basic purpose of the whitelist is to let you ship a toolchain layer which, if used, ensures that you get a prebuilt libc that the toolchain layer provider supports, unless you do something special to avoid it.
Apr 25 19:05:37 <seebs> I will do a draft design, test it a bit, and send it out for comments; I'd like to ideally provide something that any hypothetical toolchain layer providers can make use of.
Apr 25 19:07:47 <khem> seebs: now that you are here, how do you see pseudo compared to say electric cloud
Apr 25 19:07:59 <reaperofsouls> seebs: In any case we would be as well.
Apr 25 19:08:15 <khem> you know electric cloud has a make which tracks dependencies by capturing syscalls
Apr 25 19:08:18 <seebs> reaper, you would be what?  Interested in such a feature?
Apr 25 19:08:56 <seebs> khem:  I didn't know.  I did look at a couple of other designs, like using debugger traps, but it looked like the LD_PRELOAD feature was the easiest to set up and get working.
Apr 25 19:09:21 <seebs> Mostly pseudo exists to be like fakeroot but more robust when being used outside the duration of a single build, and in particular with better diagnostics.
Apr 25 19:09:44 <seebs> Next time they let me off the leash I plan to revamp pseudo's diagnostic messages substantially to make them more informative to people who aren't me.
Apr 25 19:10:38 <seebs> Turns out that "I can understand these messages because I wrote them all and also know exactly what's happening" and "a person who is just a user of the software understands these messages" are not logically equivalent.
Apr 25 19:10:40 <fray> khem, EC's make is a bit broken, last time I worked with it..
Apr 25 19:10:49 <fray> it might work w/ OE.. but it didn't work with out old buildsystem
Apr 25 19:10:51 <reaperofsouls> seebs: Coming to a common frame work for providing external toolchains that extends beyond the external stuff currently in yocto. It sounds like that is what your more or less suggesting.
Apr 25 19:10:57 <seebs> Yeah.
Apr 25 19:11:41 <reaperofsouls> seebs: unless I was misunderstanding what you were suggesting.
Apr 25 19:12:04 <seebs> That's larger than the immediate concern I'm looking at, but yeah, ultimately I think that's a good goal.
Apr 25 19:12:35 <seebs> Right now, I can just about get everything I want from the external CSL support, except I want a way to make builds notice if a requested tuning isn't going to have a supported prebuilt.
Apr 25 19:12:37 <reaperofsouls> Right.
Apr 25 19:13:29 <seebs> Which leads to a terminology question:  Old WR Linux called tunings "cpu" and prebuilt libcs "multilib".  So we might have a plain x86-32 multilib, and then we'd have CPU tunings which used that prebuilt libc, and compiled code outside of libc with additional options.
Apr 25 19:13:59 <seebs> It sounds like "multilib" is already being used to refer to something else in oe-core, though?  I'm still finding my way around this.
Apr 25 19:14:11 <fray> it is
Apr 25 19:14:28 <fray> the tune is closer to what we called a "cpu" before
Apr 25 19:14:36 <khem> fgcc defines a notion of multilib
Apr 25 19:14:43 <khem> which confuses hell out of  people
Apr 25 19:14:49 <fray> the tune encompases optimization & ABI
Apr 25 19:14:59 <fray> where a multilib is primarily ABI related [but might include tuning]
Apr 25 19:14:59 <seebs> Hmm.  tuneabi?
Apr 25 19:15:09 <reaperofsouls> khem:  yeah heavily overloaded at this time.
Apr 25 19:15:25 <khem> especially endianness
Apr 25 19:15:26 <seebs> Oh, dear, our language has a multimultilib.  :P
Apr 25 19:15:55 <khem> I once made a sysroot where I could mix uclibc
Apr 25 19:15:58 <seebs> If I referred to the base ABI a tune is built on as a "tuneabi", would anyone be compelled to kill me?  :)
Apr 25 19:16:02 <khem> and eglibc bins
Apr 25 19:16:17 <seebs> khem:  The fine line between genius and insanity has never been so fine.
Apr 25 19:16:24 <khem> heh
Apr 25 19:16:41 <khem> there is one difference though insanity is infinite
Apr 25 19:16:43 <reaperofsouls> khem: Unified gcc?
Apr 25 19:17:18 <khem> reaperofsouls: atleast llvm has right mindset
Apr 25 19:28:09 <seebs> llvm's diagnostics have influenced my belief that pseudo's diagnostics are pretty weak
Apr 25 19:31:52 <otavio> RP: I've sent the patches to be applied at top of master-next. (u-boot related)
Apr 25 19:54:33 <RP> otavio: ok thanks
Apr 25 19:54:50 <otavio> RP: yw
Apr 25 22:04:48 <khem> zeddii: Do we have all kernels for qemus sort of booting with linux-yocto-dev ?
Apr 25 22:07:05 <ant__> khem: hi there. May I fire you a quick question?
Apr 25 22:10:14 <khem> sure
Apr 25 22:10:25 <ant__> for kernels >3.1 some headers have changed place (i.e. bitsperlong.h  from include/asm -> include/generated/asm )
Apr 25 22:10:32 <ant__> and now klibc fails
Apr 25 22:10:49 <ant__> (temporarly I hacked around linking some headers)
Apr 25 22:11:02 <khem> ok check the kernel version and add required indirection
Apr 25 22:11:05 <ant__> now, debian can build with linux-libc-headers it seems
Apr 25 22:11:27 <ant__> http://patch-tracker.debian.org/patch/series/view/klibc/2.0~rc3-1/klibc-linux-libc-dev
Apr 25 22:13:01 <ant__> I'm a bit lost with DEB_HOST_MULTIARCH though
Apr 25 22:27:06 <khem> I am equally lost with DEB_HOST_MULTIARCH :)
Apr 25 22:27:12 <khem> and thats my wish too
Apr 25 22:28:02 <khem> ant__: in our case you can omit DEB_HOST_MULTIARCH
Apr 25 22:28:07 <khem> and that patch will work for us
Apr 25 22:51:18 <khem> zeddii: fray: I have pushed the OE-Core changes to support mips64 and sh4 here http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/misc
Apr 25 22:52:16 <khem> this branch has gcc-4.7 + override rework + uclibc update + mips64/sh4 support all in one
Apr 25 22:52:28 <khem> but it all works good
Apr 25 22:52:59 <khem> oh forgot one thing the kmod :)
**** ENDING LOGGING AT Thu Apr 26 03:00:00 2012

**** BEGIN LOGGING AT Thu Apr 26 03:00:00 2012
Apr 26 07:44:41 <mckoan> good morning
Apr 26 09:11:28 <Zagor> RP: did anything more come of http://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg13117.html ? I think it would be very useful.
Apr 26 09:13:55 <Zagor> I suppose technically I should ask that in #oe :)
Apr 26 09:32:33 <RP> Zagor: Its on my "to do" list but nothing has been done yet
Apr 26 09:32:49 <Zagor> RP: ok
Apr 26 09:33:03 <JaMa> RP: yay :)
Apr 26 09:34:55 * RP is trying to take it easy for few days...
Apr 26 09:35:16 <Zagor> RP: sounds like a good idea
Apr 26 09:45:01 <JaMa> RP: I've 2 more patches from some old patchset http://patchwork.openembedded.org/patch/24357/ http://patchwork.openembedded.org/patch/24359/ do you want me to resend them?
Apr 26 09:45:27 <JaMa> RP: 1st was postponed after release and I haven't seen any feedback for 2nd
Apr 26 09:46:33 <RP> JaMa: I think that should be PACKAGE_ARCH ?
Apr 26 09:47:12 <JaMa> in SDK_NAME?
Apr 26 09:47:18 <RP> JaMa: second one is fine
Apr 26 09:47:30 <RP> JaMa: yes
Apr 26 09:49:53 <RP> JaMa: I've applied the xev one
Apr 26 09:52:04 <JaMa> RP: I had PACKAGE_ARCH but McClintock Matthew-B29882 had some issues with it http://permalink.gmane.org/gmane.comp.handhelds.openembedded.core/16699
Apr 26 09:52:31 <JaMa> then we were discussing wheather TUNE_ARCH or TUNE_PKGARCH
Apr 26 09:54:22 <RP> JaMa: I agree TUNE_ARCH is wrong
Apr 26 09:55:35 <JaMa> TARGET_ARCH too
Apr 26 09:55:57 <RP> JaMa: Looking at the code, I guess TUNE_PKGARCH is ok. In general we should be using PACKAGE_ARCH where we can though
Apr 26 09:56:01 <JaMa> but both PACKAGE_ARCH TUNE_PKGARCH work for me, so you can pick which patch version you prefer :)
Apr 26 09:56:51 <RP> JaMa: I agree TARGET_ARCH is also wrong
Apr 26 09:57:25 <RP> JaMa: TUNE_PKGARCH is ok, it has the advantage that nothing should override it. I was worrying about something else which shouldn't happen
Apr 26 09:58:14 <RP> JaMa: also merged to master
Apr 26 11:20:32 <JaMa> RP: thanks
Apr 26 13:55:29 <aperezdc> hello to all
Apr 26 13:55:49 <aperezdc> I'm experiencing "connection reset by peer" issues when trying to clone from git://git.yoctoproject.org/poky.git
Apr 26 14:24:50 <abustany> aperezdc: works for me...
Apr 26 14:25:27 <RP> aperezdc: I've just been working with repos there and it also works for me. Possible firewall issues?
Apr 26 14:25:43 * aperezdc retries
Apr 26 14:28:02 <aperezdc> mmmh, adding "-v -v" seems that Git starts getting some data, and then the connection gets reset
Apr 26 14:28:13 <aperezdc> probably something bad here, yep
Apr 26 18:27:08 <seebs> More newbie questions!  There are settings like TUNEVALID[x86] = "Description".  How would I look that up?
Apr 26 18:27:18 <seebs> It appears that data.getVar("TUNEVALID") does not yield an array object.
Apr 26 18:29:58 <seebs> ... I am also a bit confused by the distinction between data.getVar(foo, True) and data.getVar(foo, e.data, True)
Apr 26 18:39:10 <seebs> Huh, this is interesting.  There's an oe.data.typed_value() which seems to rely on a value having a 'type' value assigned to it, possibly with setVarFlag, or possibly in some other way.
Apr 26 18:40:53 <seebs> Oh.
Apr 26 18:45:00 <seebs> Hmm.  It looks to me like TUNEVALID[x86] = "foo" is equivalent to d.setVarFlag("TUNEVALID", "x86", "foo"), and the corresponding operation would be getVarFlag.
Apr 26 18:47:40 <seebs> Ah-hah.  data.getVarFlag('TUNECONFLICTS', feature) => what I wanted
Apr 26 19:05:17 <RP> seebs: yes. The data.getVar approach is the preferred mechanism is preferred these days (and is slightly faster). bb.data.getVar is not really accepted in new code
Apr 26 19:06:04 <RP> seebs: and yes, you're looking at the flags. The tune stuff abuses them really but such is life, you work with what you've got
Apr 26 19:06:41 <seebs> So I should be using data.getVarFlag() with them, and not changing them to be TUNEVALID_tune-i586 = "description"?
Apr 26 19:06:57 <seebs> 'cuz I could do either.  And it's not as though anyone's actually using TUNEVALID and TUNECONFLICTS yet.  :P
Apr 26 19:08:34 <RP> seebs: I don't really want to state something solid without knowing all the details but I think flags are probably useful in this case
Apr 26 19:08:48 <seebs> k
Apr 26 19:09:22 <RP> seebs: there is also a getVarFlags iirc which can get you all the flags in one go
Apr 26 19:11:19 <seebs> Well, in this case, I only want to look at a few of them.
Apr 26 19:13:02 <RP> seebs: its still probably more efficient to use getVarflags if you're looking at more than one
Apr 26 19:13:32 <RP> seebs: I just say this knowing the gory details of what it does behind the scenes
Apr 26 19:13:32 <seebs> That just returns the whole dictionary?  Hmm, yeah, could be handy.
Apr 26 19:14:04 <RP> seebs: I think this was why we used flags for this
Apr 26 19:14:07 <seebs> Okay, can I get a quick cookbook answer for something?  I want to verify that I'm doing this correctly for multilibs.  What's a trivial way to generate a build which will try to build both x86_32 and x86_64?
Apr 26 19:15:23 <RP> seebs: MACHINE="qemux86-64", require conf/multilib.conf, MULTILIBS = "multilib:lib32", DEFAULTTUNE_virtclass-multilib-lib32 = "x86", BASE_LIB_tune-x86 = "lib32"
Apr 26 19:15:35 <RP> seebs: I have that as my test in local.conf
Apr 26 19:15:41 <seebs> thx
Apr 26 19:23:37 <seebs> Is there a pattern to when something is x86-64 and when it is x86_64?
Apr 26 19:32:13 <RP> seebs: "yes"? ;-)
Apr 26 19:32:55 <RP> seebs: some of the variables filter it due to issues with the underscore iirc.
Apr 26 19:36:51 <zeddii> what's the recommended way to figure out why a task you attempted to inject didn't fire. I can't get the right bitbake foo to see the queue.
Apr 26 19:37:30 * zeddii sees a typo in his addtask. hmmm. trying that first.
Apr 26 19:38:19 <zeddii> aha.
Apr 26 19:38:24 * zeddii hangs his head in shame
Apr 26 19:43:29 <seebs> Hmm.  Interesting.  If I have DEFAULTTUNE=core2, it works.  If I have a multilib setup, with DEFAULTTUNE_virtclass-multilib-lib32 = core2, my tests fail, because I can't find FEATURES_tune-core2 in that case.
Apr 26 19:44:18 <seebs> Do I need to manually require the .inc file for a multilib tuning?
Apr 26 19:44:38 <RP> seebs: ah, if the machine doesn't by default, yes
Apr 26 19:46:25 <seebs> Huh, that's sorta cool:  I can't determine the endianness for architecture i586i586.
Apr 26 19:46:39 <seebs> It seems to me that the TUNE_ARCH .= line is getting hit twice somehow.
Apr 26 19:47:27 * RP would agree
Apr 26 19:48:55 <seebs> Okay, here is what I need.  I need a bunch of objects which are not treasures, so the thief won't pick them up.  And I will drop them in .inc files as I reach them, and make a map.
Apr 26 19:51:29 <seebs> Hmm.  If I don't require tune-core2.inc, FEATURES_tune-core2 is not defined.  If I do, I get TUNE_ARCH = i586i586.  Hmmmm.
Apr 26 19:56:41 <seebs> Well, it seems that the issue is that I'm ending up with DEFAULTTUNE = core2, so core2 is in both defaulttune and MULTILIBS.
Apr 26 20:08:46 <seebs> Hang on, why is TUNE_ARCH additive at all?
Apr 26 20:08:57 <seebs> Does that make more sense on non-x86 systems, I guess?
Apr 26 20:09:33 <seebs> What seems to be biting me is that if I have two tunings that both require arch-ia32.inc, then it gets read twice, and each time through the TUNE_ARCH .= lines are hit.
Apr 26 20:12:10 <RP> seebs: hmm, I'd suggest that core2 should probably include i586 instead of arch-ia32
Apr 26 20:12:54 <seebs> In this case, I'm trying to map onto the custom binaries we get from Code Sourcery, where core2 is actually a distinct set of prebuilt binaries with a special arch (-tcore2).
Apr 26 20:12:56 * RP has his priorities all wrong as shown by the lack availability of a decent bottle opener :/
Apr 26 20:13:37 <RP> seebs: well, in other arch cases, you include other compatible tune files so armv5 includes armv4 and so on
Apr 26 20:13:40 <seebs> But I tried the same thing without any of my weird tunings in place, and I get the same behavior:  If I use the MACHINE, multilib, etc. lines you showed, set DEFAULTTUNE = x86_64, I still get x86_64x86_64 as my arch.
Apr 26 20:14:05 <RP> seebs: those lines works here...
Apr 26 20:14:17 <seebs> huh
Apr 26 20:14:19 <RP> seebs: I think nitink has reported this before
Apr 26 20:14:27 <seebs> Well, my tree could be out of sync, or I may have blown something up adding my sanity checks.
Apr 26 20:14:32 <RP> seebs: this happens on one of his machines and not on others
Apr 26 20:14:53 <seebs> Oh, whee.
Apr 26 20:15:05 <seebs> I wonder.  Is the intent of require foo.inc that it would only read a given file once?
Apr 26 20:15:21 <seebs> Because that was what I *thought* was usually implied by require, but I am not a Python wiz.
Apr 26 20:17:01 <seebs> Anyway, I have a trivial workaround if I need it (set TUNE_ARCH = "" at top of file, since in practice additive values for that make no sense anyway).
Apr 26 20:20:45 <RP> nitink: the mesa x32 patch is spectacularly broken :(
Apr 26 20:21:20 <seebs> argh
Apr 26 20:21:42 <seebs> One of the other parts of my tree has become defective in such a way that I cannot actually run a test build.  :P
Apr 26 20:25:19 <nitink> RP: good to know,
Apr 26 20:31:28 <nitink> RP : do you have more details regarding the mesa x32 breakage
Apr 26 20:31:43 <seebs> RP:  You're right, it works fine for me in poky.  Well.  It works fine then blows up a minute later.
Apr 26 20:32:01 <seebs> self.pkgs_mapping.append([pkg.split(self.extname + "-")[1], pkg])
Apr 26 20:32:06 <seebs> ^-- list index out of range
Apr 26 20:32:25 <RP> nitink: I will probably send a patch shortly. Its related to the gcc 4.7 breakage although I'm not sure why that triggers this
Apr 26 20:33:13 <nitink> RP: ok
Apr 26 20:34:42 <seebs> Oh.  Wait, no, it doesn't work for me in the base yocto tree, I just had my "fixed" layer in the way.
Apr 26 20:37:14 <RP> nitink: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t2&id=e340988892a9bea2d103a65afa2c3e5a9dd194af
Apr 26 20:40:51 <seebs> Huh.
Apr 26 20:42:20 <seebs> So, RP, I get another failure using that, which I do not comprehend, involving parsing the libxcb recipe.  It only happens if I have multilibs enabled.
Apr 26 20:42:32 <nitink> RP: interesting, so -mx32 was passed to arm build ? or was it -m32 ?
Apr 26 20:46:12 <seebs> ooohhh. Own fault.
Apr 26 20:46:29 <seebs> I casually renamed lib32 to lib because that was our local convention, and did not realize that was causing the problem.
Apr 26 20:46:46 <seebs> If multilib:lib causes failures, should a sanity-check be rejecting it?
Apr 26 20:51:19 <RP> nitink: -mx32 to an arm build
Apr 26 20:51:37 <RP> seebs: implement multilib sanity checks is an open bugzilla item
Apr 26 20:52:09 <seebs> I'm sort of doing it in passing.
Apr 26 20:52:27 <seebs> Basically, I need at least some in place for me to verify that I've done the thing I'm doing.
Apr 26 20:56:01 <seebs> So I'm doing sanity checks that all features have a TUNEVALID, that no tuning has TUNECONFLICTS[feature] that match a feature in its list, that no multilib specifies the default tuning, and that "lib" has not been provided as a multilib.
Apr 26 20:56:16 <seebs> Also checking against a whitelist if suitable stuff is defined.
Apr 26 21:04:55 <kergoth> khem: ever try building xserver for mips64?
Apr 26 21:15:33 <RP> seebs: those sound like good tests
Apr 26 21:15:54 <seebs> I sent a draft patch to the list.
Apr 26 21:16:28 <seebs> The idea is, anything that can blow up in a way that I can't figure out easily, I want to check for and give a coherent description in the sanity checks.  :)
Apr 26 21:16:48 <seebs> Now if I could just figure out why I get x86_64x86_64 for arch and you don't...
Apr 26 21:45:05 <nitink> RP: http://paste.ubuntu.com/948329/
Apr 26 22:30:28 * kergoth tries to work the kinks out of precompiled locales w/ external toolchain so he can move on to something else
Apr 26 22:30:43 <seebs> whee
Apr 26 22:31:07 <seebs> BTW, I sent some draft toolchain sanity checks to the list, this may be relevant to your interests.
Apr 26 22:31:18 <kergoth> sigh, so many stalled bugs on my plate, need to get past the various blocks
Apr 26 22:31:20 <kergoth> cool
Apr 26 22:32:39 <seebs> My thought is, if I have to get most of this done to verify that my code is working, or to meet my listed requirements, might as well clean it up a bit and send it around for review.
Apr 26 22:59:13 <kergoth> hmm, when you set the glibc internal locale mode to precompiled, it tries to ascertain what to use from the directory names, but if the directory has no '.', then there's no way for it to tell what charset/map was used to generate it, and charset ends up set to '', and things get quite unhappy. end up with, say, en-us.utf8 existing, but not en-us, as a result
Apr 26 22:59:15 * kergoth pokes at it
Apr 26 23:00:05 <kergoth> maybe it'd be best to use the included SUPPORTED file as a guide, assuming it's a correct description of the generated locales, and use that rather than the directory listing, and if that doesn't exist, then fall back to 'POSIX' or something, the way localedef does
Apr 26 23:00:09 * kergoth scratches head
Apr 26 23:00:33 <seebs> oooh
Apr 26 23:00:55 <seebs> that reminds me of a cognitively similar bug, which is that our path check only checks for a literal . in path; it doesn't notice empty path components, which do the same thing.
Apr 26 23:01:33 <seebs> I have this vague thought that we have had to deal with that locale issue before.
Apr 26 23:03:09 <kergoth> looks like it's not legal to add, say, 'en_US' to GLIBC_GENERATE_LOCALES for the same reason -- no knowledge of the charmap. hmm
Apr 26 23:03:23 <kergoth> makes sense, but still rather annoying
Apr 26 23:03:33 <kergoth> or rather, could be annoying, in theory :)
Apr 26 23:03:41 <kergoth> not that anyone really gives a crap about non-utf8 anymore
Apr 26 23:03:43 <kergoth> but still
Apr 26 23:03:54 <seebs> Huh, looking at this caused me to notice that I should be looking at the CSL_TARGET_CORE determination.
Apr 26 23:04:20 <seebs> I think we still have some stuff that ends up being run in "what do you mean character map?  it's a byte" mode.
Apr 26 23:08:27 <seebs> Hmm.  It *looks* like it's trying to support cases where there's no . in the name.
Apr 26 23:09:56 <seebs> I am not understanding this.
Apr 26 23:10:23 <seebs> It appears that "x" maps to "x  ", and "x.y" maps to "x.Y  "
Apr 26 23:10:26 <kergoth> trying is the key word
Apr 26 23:10:28 <kergoth> :)
Apr 26 23:10:51 <seebs> Then we take l[:-1], which I think gives us "x " or "x.Y " (only one space).
Apr 26 23:10:53 <kergoth> then later it reassembles the components, with '' as the charset, and ends up constructing a 'locale-base-en-us.' package
Apr 26 23:11:03 <kergoth> nah, thats stripping off the trailing newline, not the space, afaict
Apr 26 23:11:04 <seebs> And (locale, charset) = line.split(" ").
Apr 26 23:11:37 <seebs> But there's no newline in the os.listdir case, just an extra space.
Apr 26 23:11:52 <seebs> Huh!
Apr 26 23:12:07 <kergoth> if that's the case, then it chokes and dies on the split(), due to only having one element to unpack
Apr 26 23:12:15 * kergoth wonders if precompiled has ever been tested
Apr 26 23:12:28 <seebs> I betcha somsone changed the other case to use spaces, and missed this one.
Apr 26 23:12:49 <kergoth> i don't think this could work
Apr 26 23:12:55 <seebs> Ah-hah.
Apr 26 23:13:02 <kergoth> all the output_locale* functions assume encoding is a valid value, not the empty string
Apr 26 23:13:14 <kergoth> e.g. adds dep on eglibc-charmap-foo
Apr 26 23:13:26 <kergoth> lacking that knowledge, i don't see how that handling can actually work
Apr 26 23:13:51 <kergoth> of course, this is minor, there's nothing *wrong* with regenerating the locales
Apr 26 23:13:55 <kergoth> just seemed a bit unnecessary
Apr 26 23:13:59 <kergoth> heh
Apr 26 23:14:52 <seebs> This is odd.
Apr 26 23:15:05 <seebs> It looks like the os.listdir code is about a year older than the rest of that hunk.
Apr 26 23:15:22 <seebs> But the diffs for the patch that created the newer stuff don't look like this at all, so I'm confused anyway.
Apr 26 23:16:01 <seebs> Hmm.  Maybe just tweak it so it treats an empty name as 'UTF8'?
Apr 26 23:17:04 <seebs> But yeah, this looks suspiciously like this case hasn't been hit in ages.
Apr 26 23:18:43 <kergoth> I don't think that's safe (fallback to utf8). e.g. en_US usually uses one of the iso encodings, and en_US.utf8 is utf8
Apr 26 23:19:11 <seebs> Oh, good point.  Hmm.
Apr 26 23:19:15 <kergoth> going to make it use the encoding->charset mapping info in the SUPPORTED file, while using GLIBC_GENERATE_LOCALES or os.listdir() to gather the list of what locales to generate/package
Apr 26 23:19:21 <kergoth> separate the two pieces
Apr 26 23:19:28 <seebs> That makes sense.
Apr 26 23:22:56 <kergoth> heh, found another issue with that stuff. locale dirs are en_US.utf8, while the charset is UTF-8 (note the dash)
Apr 26 23:22:59 * kergoth rolls eyes
Apr 26 23:26:00 <seebs> What bitbake really needs is a convenient and standard idiom for "but whenever you see one of these two things, substitute the other, because the one you actually have is always wrong".
Apr 26 23:31:09 <kergoth> i think either the format needs to support more than just key=value, or we need to move all this sort of logic out of the bitbake file format, e.g. entirely into python bitbake plugins
Apr 26 23:31:25 <kergoth> either would make life easier when stretching the limitations
Apr 26 23:31:32 <kergoth> (int he long term)
Apr 26 23:32:36 <seebs> I think the intent is that the flags stuff could be used that way.
Apr 26 23:33:02 <seebs> Stuff like TUNEVALID[i586] might be more usable than TUNEVALID_tune-i586.  Scales better, anyway.
Apr 26 23:33:09 <seebs> Or should.
Apr 26 23:34:43 <kergoth> it's badly overloading the intent of flags though. flags by definition are metadata about the metadata, using it as a generic dictionary was never its intent
Apr 26 23:34:57 <kergoth> gets the job done, but it shows a weakness in the system that we need to do this
Apr 26 23:35:00 <seebs> Yeah, a generic dictionary tool of some sort would be nice.
Apr 26 23:36:25 <seebs> I miss lua, where lookup[x] or x doesn't throw exceptions.  :)
Apr 26 23:38:19 <kergoth> lua wouldn't be a bad format for recipes. only worry is that it's largely imperative, so it'd be hard to convert the recipes to a future different format. of course, we have the same issues now due to 'inherit' positioning, etc..
Apr 26 23:39:25 <seebs> Yeah.  Mostly I'm just biased, because I like lua better.  :)
Apr 26 23:39:45 * kergoth nods
Apr 26 23:40:20 <seebs> I'm just glad I once did a large project in PHP, so no matter what I work on, I am always happy that it's not PHP.
Apr 27 00:08:31 <kergoth> this code names utf-8 binary locales as non-utf-8 suffixed, so en_US.UTF-8 is just 'en_US', but the external toolchain doesn't necessarily subscribe to that same policy. this code should really just obey SUPPORTED, and if people want all-utf-8 base locales they can change SUPPORTED the way they want them. hmm
Apr 27 00:09:20 <seebs> I have to say, I am not entirely thrilled by the name "SUPPORTED" for "a list of locale to locale directory names".  :)
Apr 27 00:10:53 <kergoth> agreed. but it seems to be the convention among other distros. desktop locale generation seems to use that as both the list of supported locales, and the associated charsets to use when generating them, as far as i can tell
Apr 27 00:11:01 <kergoth> unless i'm missing something
Apr 27 00:12:19 <seebs> No clue, it just seems like a name that has such broad implications compared to what it actually does.  :)
Apr 27 00:13:48 <kergoth> indeed
Apr 27 00:15:11 <seebs> What goes in the file called "COPYRIGHT"?  Why, a list of the copyright holders of the major works of literature you usually get in 7th grade English in the US.  What were you expecting?
Apr 27 00:47:28 <khem> kergoth: so far, I have only tried console-image
Apr 27 00:47:39 <kergoth> khem: k
Apr 27 00:50:37 <khem> kergoth: right now I am still working on kernel support a bit
Apr 27 00:50:45 <khem> once I have a booting kernel + rfs
Apr 27 00:50:50 <khem> then it will be easier
Apr 27 01:01:36 * kergoth nods
Apr 27 01:27:33 <khem> putting SUPPORTED under /usr/share/local/SUPPORTED would make logical sense
Apr 27 01:27:55 * khem is out of a 3 days 24/7 bug finding spree
Apr 27 01:28:00 <kergoth> i think /usr/share/i18n/ is probably a better bet, next to locales/ and charmaps/
Apr 27 01:28:04 <kergoth> but either would do
Apr 27 01:28:10 <kergoth> heh, nice
Apr 27 01:28:30 <khem> 3 engineers 3.5 days
Apr 27 01:28:39 <khem> and bug was a stupid typecast
Apr 27 01:29:04 <khem> but I can now proudly say I understand Juniper routers inside out
Apr 27 01:29:15 <khem> software wise
Apr 27 01:29:56 <kergoth> i'm in bts housecleaning mode at the moment
Apr 27 01:29:57 <kergoth> heh
Apr 27 01:30:03 <khem> someone typecasted void** to char**
Apr 27 01:30:26 <khem> and it meant that only 1 byte is updated and not 4 bytes
Apr 27 01:30:36 <khem> since it was an address which meant it only updated the LSB
Apr 27 01:31:06 <khem> and guess what, this was a buffer code where you copy n bytes and then move the pointer by that many number of bytes
Apr 27 01:31:45 <khem> and now we were eseentially doing addr += (size & 0xfffffff0)
Apr 27 01:31:56 <khem> and this is a kernel code
Apr 27 01:33:01 <seebs> whee
Apr 27 01:33:29 <khem> so we were seeing I must say interesting behaviour in packets on routers
Apr 27 01:33:30 <seebs> I've had days like that.
Apr 27 01:33:47 <seebs> We spent an insane amount of time tracking down a bug that turned out to be initializing one more item than an array had.
Apr 27 01:33:49 <khem> suddenly Packets per second dropped and people started blaming the new compiler
Apr 27 01:34:13 <khem> seebs: oh yeah in past 14 days I have fixed 3 bugs which each tooks like a week
Apr 27 01:34:29 <khem> another one was uninitialized variable bug
Apr 27 01:34:38 <seebs> The thing that made it crazy was that the thing that got overwritten turned out not to be an adjacent local variable, but the spill space for a register, so the behavior was a value randomly becoming a null pointer when an unrelated function was called.
Apr 27 01:35:17 <khem> third one was someone allocated char buf[2] on local stack and then in code in function did write to code[2]
Apr 27 01:35:23 <khem> err buf[2]
Apr 27 01:35:24 <seebs> Also, the Linux idiom of declaring an array of FOO_MAX+1 members, 0 .. FOO_MAX, rather than having FOO_MAX be the exclusive upper bound?  Apparently error-prone.  :)
Apr 27 01:35:28 <khem> now yousee what happens :)
Apr 27 01:35:56 <seebs> and now... pizza time!
Apr 27 01:36:07 * khem contemplates stopping to work on compilers
Apr 27 01:36:26 <khem> since I get pulled into this nasty bugs t
Apr 27 01:36:44 <khem> if I was writing java code I would be eating pizza now :)
Apr 27 01:37:22 <khem> but proudly so far compiler 0  OS 14
Apr 27 01:37:27 <khem> is the score
Apr 27 01:38:49 * khem needs to read ml
Apr 27 01:55:15 <seebs> Heh.
Apr 27 01:55:29 <seebs> Oddly, the crazy bugs are why I like working on compilers.
Apr 27 01:58:14 <khem> but since I understand the OS and compiler codegen and opts on arm/mips/ppc/x86 this becomes a fit for me
Apr 27 01:58:30 <khem> wait ! did I put out my resume there in adulation
Apr 27 01:59:48 <khem> last problem, I debugged a mips system and then a ppc system and finally a amd64 system to figure out one bug
Apr 27 02:00:16 <khem> since amd64 system was sending packets to ppc system which was munging them and then sending them to mips system
Apr 27 02:00:24 <khem> and it was mips system which was crashing
Apr 27 02:00:24 <seebs> Nice!
Apr 27 02:00:34 <khem> bug was on amd64 box
Apr 27 02:00:51 <khem> well its a single router all system are in same box
Apr 27 02:03:25 <seebs> I'd say that if input was crashing the mips system, it wasn't paranoid enough.  :)
Apr 27 02:03:38 <khem> its not thats another story
Apr 27 02:03:40 <khem> :)
Apr 27 02:03:54 <khem> this system is on the line card and it has to run very fast
Apr 27 02:04:16 <khem> and software on it is pretty lousy since they only thought it cant go wrong
Apr 27 02:04:28 <khem> since ppc system should do all the error checks
Apr 27 02:04:44 <khem> it usually gets correct messages *most* of times
Apr 27 02:06:14 <khem> infact the crash was a watchdog timer created
Apr 27 02:06:20 <khem> which is timeout
Apr 27 02:06:37 <khem> and it reduced the line rate since the box was rebooting randomly
Apr 27 02:21:23 <khem> seebs: are you in bay area
Apr 27 02:24:06 <seebs> Nope!  I am in sunny Minnesota*.
Apr 27 02:24:10 <seebs> [*] Not actually sunny.
Apr 27 02:24:54 * kergoth grew up in MN, suburb of minneapolis
Apr 27 02:25:06 <kergoth> went from MN to AZ, talk about a climate shift. opposite extreme
Apr 27 02:25:08 <kergoth> heh
Apr 27 02:26:21 <khem> ah
Apr 27 02:26:47 <khem> while biking I sometimes ride past Wind River office here
Apr 27 02:28:09 <seebs> I have never actually been there, and I've been with WR on and off since 2001.  Was one of the BSDi acquisitions.
Apr 27 02:28:23 <seebs> My theoretical start date is, I think, actually before the first day I was technically employed by WR.  :)
Apr 27 02:28:49 <khem> oh
Apr 27 02:29:00 <khem> Do you happen to know David O Brien ?
Apr 27 02:52:08 <CcSsNET> khem: wind river eh. where you from?
Apr 27 02:55:47 <khem> i am in sunnyvale
Apr 27 02:56:05 <CcSsNET> o, i am near boston, ma
Apr 27 02:57:00 <khem> and I dont work for WRS
Apr 27 02:57:11 <CcSsNET> i bike alot myself. but where i actually am lacks any usefull tech companies
Apr 27 02:57:48 <khem> I dont bike in winters
Apr 27 02:57:57 <CcSsNET> i do. i have no car :)
Apr 27 02:58:02 <khem> but starting late april until october
Apr 27 02:58:17 <CcSsNET> ah
Apr 27 02:59:12 <CcSsNET> http://atccss.net/site/bmx.jpg
Apr 27 02:59:37 <CcSsNET> the ride. its an older pic though, i got new tires and a new chainwheel
**** ENDING LOGGING AT Fri Apr 27 03:00:00 2012

**** BEGIN LOGGING AT Fri Apr 27 03:00:00 2012
Apr 27 03:00:04 <khem> I am a roadbiker :)
Apr 27 03:00:12 <CcSsNET> yea this is a road bike :)
Apr 27 03:00:24 <CcSsNET> 24" bmx cruiser. turned street travel
Apr 27 03:00:42 <CcSsNET> if i had the money i would build a real roadbike but yea to expensive
Apr 27 03:00:54 <khem> yes they are indeed
Apr 27 03:01:35 <CcSsNET> this cruiser set me back around 1,000
Apr 27 03:01:44 <CcSsNET> but its sturdy as granite
Apr 27 03:02:13 <CcSsNET> i needed reliability, and you dont get that with cheap road/mountain bikes
Apr 27 03:02:26 <seebs> khem:  I think I've met David O'Brien, but I don't really know him particularly well.
Apr 27 03:02:42 <khem> yeah he worked at BSDi
Apr 27 03:02:49 <khem> he works with me in same team now
Apr 27 08:25:07 <mckoan> good morning
Apr 27 13:09:52 <xumbi> greetings! has anyone successfully build lirc in yocto?
Apr 27 13:38:24 <RP> xumbi: I've seen recipes for it before, I've never personally used it
Apr 27 13:39:57 <xumbi> RP: it appears to be abandoned in OE classic, I'm trying to bring the recipe into the latest poky release but there are missing dependencies
Apr 27 13:41:19 <xumbi> I'll see if I can work through some of the errors and pose questions to the mailing list
Apr 27 13:42:32 <RP> xumbi: ok, that is probably the best way forward
Apr 27 14:53:06 <khem> RP: qt 4.7 did yield a bug for gcc 4.7 :) although you mentioned we will get rid of qt 4.7 so it does not affect us badly
Apr 27 14:53:19 <khem> RP: but I have made a small testcase out of it
Apr 27 14:53:28 <khem> so it is taken care of in gcc 4.7
Apr 27 14:56:08 <RP> khem: using 4.8.1 seems like the best course of action since we'll be doing that anyway
Apr 27 14:56:36 <RP> khem: at least from a build perspective, it seems 4.7 is green on the autobuilder
Apr 27 14:56:55 <RP> khem: next I'll put in the eglibc update..
Apr 27 14:59:39 <khem> RP: its arm specific bug actually
Apr 27 14:59:47 <khem> so wont happen on armv5 I think
Apr 27 14:59:55 <khem> but happens for armv7
Apr 27 14:59:57 <RP> khem: it did ;-)
Apr 27 15:00:13 <khem> col
Apr 27 15:00:13 <RP> khem: http://autobuilder.yoctoproject.org:8010/builders/nightly-arm/builds/403
Apr 27 15:00:33 <RP> khem: beagleboard and qemuarm
Apr 27 15:00:57 <khem> ah yes then we see it
Apr 27 15:01:00 <khem> cool
Apr 27 15:01:10 <khem> but its been understood so dont worry
Apr 27 16:19:54 <msm> who was I disuccsing ccache / sstate issues with the other day?
Apr 27 16:29:00 <RP> msm: me maybe?
Apr 27 16:29:13 <RP> msm: I worked on that recently anyway
Apr 27 16:33:28 <msm> it wasnt you
Apr 27 16:33:33 <msm> it was a z*
Apr 27 16:33:35 <msm> zeddi or zen
Apr 27 16:33:36 <msm> anyways
Apr 27 16:33:45 <msm> disable ccache outright fixed some weird issue with gpsd
Apr 27 16:33:56 <msm> not really 100% sure though
Apr 27 16:33:59 <msm> *sigh*
Apr 27 16:34:45 <zenlinux> I don't think it was me
Apr 27 16:39:42 <dvhart> zeddii, and then all the SRCURI's at the next point release?
Apr 27 16:39:54 <sgw> halstead: Morning
Apr 27 16:40:01 <RP> msm: fray possibly?
Apr 27 16:40:04 <halstead> sgw, Good morning.
Apr 27 16:40:41 <halstead> sgw, I may need to reschdule the bugzilla name changes.
Apr 27 16:40:59 <sgw> halstead: The reclassificication has the all clear, I guess we have the kernel updates from the email.
Apr 27 16:41:21 <sgw> halstead: OK, until when?  You just need more time to build that script?
Apr 27 16:42:00 <halstead> sgw, Yes to make sure the script is right. I'll keep working on it but I may move it to the weekend.
Apr 27 16:42:47 <msm> RP: you are all so helpful it's hard to remember ;)
Apr 27 16:43:54 <sgw> halstead: it could wait for Monday, PRC team will be out for the first part of next week anyway
Apr 27 16:48:29 <halstead> sgw, dvhart RP: I'm re-reading the kernel taxonomy e-mail and it appears to say we are sticking with the spreadsheet as written. Is that correct?
Apr 27 16:48:51 <dvhart> halstead, with the exception of the tracing tools I think
Apr 27 16:49:00 <dvhart> I don't believe RP commented on that part of my email
Apr 27 16:53:27 <halstead> dvhart, Will you correct the spreadsheet with those and e-mail it?
Apr 27 16:53:59 <dvhart> Sure
Apr 27 16:54:26 * dvhart goes to stuff the worms back in the can
Apr 27 16:54:33 <halstead> Thank you. :)
Apr 27 17:49:56 <otavio> Is someone already working at qt5 support?
Apr 27 18:27:32 <kergoth> can someone explain why meta/conf/distro/include/tclibc-eglibc.inc explicitly sucks in locale-base-en-us and locale-base-en-gb when those are already handled by IMAGE_LINGUAS?
Apr 27 18:28:28 <seebs> Do you want a good justification for it, or an explanation of how it came to pass?
Apr 27 18:28:46 <seebs> Because I am guessing they will have no words in common.  :P
Apr 27 18:40:31 <ryane_> hello
Apr 27 18:40:59 <ryane_> i need help creating a connection with my d2700 board through eclipse
Apr 27 18:41:16 <kergoth> seebs: hehe, fair enough
Apr 27 18:41:32 <ryane_> is this the right place?
Apr 27 18:43:08 <seebs> ryane_:  I'm not sure, but it's not as though the channel's so overloaded that people will mind if you discuss the problems you're having.
Apr 27 18:43:40 <seebs> In practice:  If I see something automatically encluding en-us, I usually assume it's because someone was in a hurry, ran into a quirk with the official mechanism, and just bodged it in to get on with a project.
Apr 27 18:44:25 <ryane_> I have a d2700 evaluation board with an atom processor that I am trying to connect to using eclipse
Apr 27 18:44:42 <ryane_> so i have used qemu to connect to the emulator and run some cod
Apr 27 18:44:44 <ryane_> code
Apr 27 18:44:53 <ryane_> but now I am trying to connect to my actual hardware target
Apr 27 18:45:16 <ryane_> I am in debug configurations
Apr 27 18:45:31 <ryane_> and instead of qemu i am using the hardware target
Apr 27 18:45:38 <ryane_> when I hit debug
Apr 27 18:45:45 <ryane_> it says that the connection is refused
Apr 27 18:46:08 <ryane_> from my understanding eclipse is trying to use gdbserver to connect to my target
Apr 27 18:46:26 <ryane_> and I'm not sure if I need to set some things up on my target first
Apr 27 18:46:33 <ryane_> or if the port is incorrectly set on the host
Apr 27 18:47:35 <ryane_> the target is running now and I am able to ping between my host (running ubuntu) and my target
Apr 27 18:47:56 <ryane_> just not sure if i need to configure some extra things in eclipse
Apr 27 18:47:56 <seebs> Can you connect to the port it's supposed to be listening on?
Apr 27 18:48:02 <ryane_> or on the target itself
Apr 27 18:48:30 <ryane_> how do i know which port it is supposed to be listening on, i'm a noob btw
Apr 27 18:48:37 <ryane_> i read something about port 2345
Apr 27 18:51:29 <halstead> Short bugzilla downtime in 10 minutes.
Apr 27 18:51:47 <ryane_> i am connecting using ethernet btw
Apr 27 18:52:12 <ryane_> I specified the IP address of the target
Apr 27 18:52:23 <ryane_> in debug configurations of eclipse
Apr 27 19:08:38 <halstead> There is a possibly harmless error in the upgrade.
Apr 27 19:08:56 <halstead> I'm rolling bugzilla back to investigate.
Apr 27 19:09:18 <sgw> halstead: I will check back with you in about 1 hour.
Apr 27 19:09:49 <halstead> I need to reschedule the upgrade.
Apr 27 19:10:27 <halstead> sgw, Is a 24 hour delay acceptable?
Apr 27 19:11:09 <halstead> Bugzilla is back online. No data was changed.
Apr 27 19:15:03 <halstead> sgw, Sunday is more open. I'll announce a second attempt for noon on Sunday. (48 hours)
Apr 27 20:07:27 <kergoth> hmm
Apr 27 20:30:52 <msm> when would one 'inherit distutils'
Apr 27 20:30:58 <msm> if the package ever builds with distutils?
Apr 27 20:31:11 <msm> it seems like it would be included w/ python-native?
Apr 27 20:31:23 <msm> or does the class fix up the cross build?
Apr 27 20:33:18 <kergoth> i don't understand the question
Apr 27 20:33:35 <kergoth> when your project uses autotools, you inherit autotools. when it uses distutils you inherit distutils
Apr 27 20:33:43 <kergoth> rinse, repeat for cmake, etc
Apr 27 21:10:26 <kergoth> https://lwn.net/Articles/494532/ looks interesting
Apr 27 22:00:39 <ant__> zeddii: ping
Apr 27 22:41:59 <dvhart> tomz2, zeddii, I seem to have to set PREFERRED_VERSION = (instead of ?=) in my machine conf, or it doesn't stick.
Apr 27 22:42:06 <dvhart> I don't have anything in my local conf
Apr 27 22:42:10 <dvhart> have either of you run into this?
Apr 27 22:43:27 <tomz2> dvhart: that's a new one on me, haven't seen that before
Apr 27 22:45:49 <dvhart> tomz2, grmble
Apr 27 22:46:05 <dvhart> I really wish I could tell WHERE bitbake gets the assignment it used
Apr 27 22:48:34 <seebs> Me Too.
Apr 27 22:48:55 <seebs> I would kill for a tracking mode where you could query a variable as to what line of what file it got set on.  :)
Apr 27 22:52:56 <kergoth> the difficulty is handling of prepend, append, +=, =+, .=, =.. we can associate line number and filename information with each ast node, but once they're evaluated, the information will be lost. it's insufficient to simply hold a single lineno/filename pair per variable
Apr 27 22:53:27 <kergoth> its doable, but nontrivial
Apr 27 22:53:57 <seebs> Hmm.  I suppose a modification-stack thing would be useful, but expensive.
Apr 27 22:54:25 <seebs> Basically, have an optional mode where variables have a trace of modifications to them, including ?= that don't fire.
Apr 27 22:54:44 <seebs> So you can see that the reason your ?= didn't work is that, while we did hit it, we hit it after a regular =.
Apr 27 22:55:12 <kergoth> what i'd like to see is the metadata object simply acting as a mapping based interface to the underlying ast tree
Apr 27 22:55:23 <seebs> oooh
Apr 27 22:55:26 <kergoth> would open up all sorts of possibilities
Apr 27 22:56:11 <kergoth> e.g. then you could ask for all the ast nodes associated with a given variable, even follow the nodes across variable references, or something
Apr 27 22:56:12 * kergoth ponders
Apr 27 22:56:23 <seebs> yah
Apr 27 22:56:35 <seebs> I would also dearly love to have a nesting-and-ordering view of .inc files.
Apr 27 22:56:48 <seebs> So I can see why x.inc ran before y.inc, or who included them, etc.
Apr 27 22:57:24 * kergoth nods
Apr 27 22:58:04 <seebs> Also, a pony.
Apr 27 22:58:18 <kergoth> i think this sort of thing is the only viable method to a theoretical future where you could avoid reparsing the world when you touch local.conf
Apr 27 22:58:21 <kergoth> heh, indeed
Apr 27 22:58:23 <kergoth> </pipe dream>
Apr 27 22:59:15 <seebs> Well, hmm.  It might not be entirely unthinkable to just add a really trivial mode that basically modifies require to log things in some way.  That'd help a bunch.
Apr 27 22:59:54 <seebs> You know, that would be awesome.  Imagine that we track an inclusion-depth, and we write out, just as a dummy log file basically, the complete set of lines included, with leading > or something from them.
Apr 27 23:00:12 <seebs> That would be relatively cheap, I think, and it'd be verbose as all heck but you could use it to debug.
Apr 27 23:13:42 <gan> Hi.  I get errors on git fetches when yocto itself is in a git repository.  I suppose there is no way around that?  Or how can I run on the latest poky from git repos without errors?
Apr 27 23:14:56 <gan> Is it normal?
Apr 27 23:15:59 <dvhart> gan, can you be more specific?
Apr 27 23:17:15 <gan> Yes.  Hangon, I'll get the error.  Just wondering if this was known.  I think it is simply git refusing to do a git fetch into an already existing repo.  I have poky in a git repo and run this from poky/build and I suppose it is fetching into tmp/work or something like that?
Apr 27 23:17:54 <gan> It seems I have reinitialized so now a build is running from the beginning so I don't have the error yet
Apr 27 23:19:08 <gan> Anyway the error was related to libzypp_git.bb if I remember.
Apr 27 23:19:14 <gan> which includes ../meta/recipes-extended/libzypp/libzypp_git.bb:SRC_URI = "git://github.com/openSUSE/libzypp.git;protocol=git \
Apr 27 23:20:52 <gan> In general, do people successfully run poky inside a git repos?  I would assume so.  Can someone confirm?
Apr 27 23:21:09 <kergoth> hm?
Apr 27 23:21:17 <kergoth> people build poky from git every single day
Apr 27 23:22:31 <gan> yes that's why I assume so.  But to be specific so I understand what you mean by "build poky".  In other words, you can run a bitbake build within poky/build directory, if that is a poky that was checked out of git.
Apr 27 23:24:00 <kergoth> yes, again, thats expected and is done all the time
Apr 27 23:25:24 <gan> ok, yes it makes sense. I'll get the error soon hopefully... unfortunately a clean build started
Apr 27 23:29:10 <gan> Can I ask bitbake to build a specific recipe only? Because I remember which package failed
Apr 27 23:31:47 <kergoth> ?
Apr 27 23:31:54 <kergoth> what do you think 'bitbake foo' does:
Apr 27 23:32:03 <kergoth> it builds the foo recipe, or whatever other recipe PROVIDES foo
Apr 27 23:32:10 <gan> I think it builds foo.  Thanks for helping :)
Apr 27 23:32:11 <kergoth> if you want to build nano instead of an image, bitbake nano
Apr 27 23:32:28 <kergoth> or try running bitbake --help and read about its command-line interface
Apr 27 23:33:35 <gan> Looks like -b is what I need.  Maybe I meant package instead of recipe.  Sorry not up to speed with the names yet
Apr 27 23:34:38 <kergoth> you almost certainly do *not* want to use -b
Apr 27 23:34:53 <kergoth> it should almost never be used, and only then by someone who fully grasps the implications
Apr 27 23:34:59 <gan> Got it.  ok I'm back to RTFMing while the clean build runs.  Hopefully the error comes up again (or not).  Thanks for helping despite noobness
Apr 27 23:35:07 <kergoth> it completely bypasses inter-recipe dependencies
Apr 27 23:35:18 <kergoth> it only is of *any* use iif you've already built all of its deps, and know this
Apr 27 23:35:43 <kergoth> and even then the value is truly limited. all it gives you is a slightly shorter wait on the parsing
Apr 27 23:35:50 <gan> yes... or if I am lucky and it brings up the exact same error I wanted to ask about
Apr 27 23:36:24 <gan> yes I see now bitbake <name> is the correct way
Apr 27 23:36:30 <dvhart> gan, are you behind a firewall?
Apr 27 23:36:38 <dvhart> gan, any proxy involved?
Apr 27 23:37:37 <gan> No, no proxy.  I could do a manual git clone...  However the file does a git fetch
Apr 27 23:38:34 <dvhart> this is on libzypp?
**** ENDING LOGGING AT Sat Apr 28 03:00:00 2012

**** BEGIN LOGGING AT Sat Apr 28 03:00:01 2012
Apr 28 21:46:25 <Andy44> RP: a few days ago I was in this chan talking about building against linux kernel headers.  I remember you said that Yocto hadn't "thought about kernel developers before" with regards to the pre-made toolchains.  At the time I thought ok... but now I'm wonding if you were actually joking becuase in general writing "brinary blobs" seems to be fround upon.
Apr 28 21:50:55 <Andy44> As in Yocto doesn't suppy that content to this end?  I'm probably wrong but I've been reading about these topics and I'm having a hard time feeling out the current climate on these issues.
**** ENDING LOGGING AT Sun Apr 29 02:59:58 2012

**** BEGIN LOGGING AT Sun Apr 29 02:59:58 2012
Apr 29 16:02:47 <otavio> Hi
Apr 29 16:02:55 <otavio> I'd like to build a custom adt ...
Apr 29 16:03:04 <otavio> what recipes are involved at it?
Apr 29 18:38:18 <halstead> Bugzilla is going offline for upgrade in ~20 minutes.
Apr 29 18:39:09 <halstead> If anyone wants to test look at https://bugzilla.yoctoproject.org/test/
Apr 29 18:51:28 <khem> halstead: cool. is it an upgrade to 4.2
Apr 29 18:52:18 <halstead> khem, Yes we are going to 4.2.1.
Apr 29 18:54:25 <khem> nice go for it
Apr 29 18:54:30 <khem> I am checking out the test page
Apr 29 18:54:33 <halstead> Thanks khem.
Apr 29 18:55:09 <khem> it would be nice if there was some yoctoproject topping on the bz main page
Apr 29 18:56:13 <khem> Bugzilla's general appearance (skin) is disabled
Apr 29 18:56:24 <khem> is that by design ?
Apr 29 18:56:43 <JaMa> khem: those gcc build issues are always about different constant or invalid file (expected } or something) so as I said before I believe it's some sort of race condition with parallel build in gcc or with parallel build of all those *gcc* recipes, but hard to reproduce because with second run it's usually gone
Apr 29 18:57:24 <khem> hmmm
Apr 29 18:57:42 <khem> JaMa: so the build fails saying what ?
Apr 29 18:57:47 <khem> first time
Apr 29 18:57:55 <JaMa> thanks to RP's fix I can at least rebuilt just the one which was failing instead of all *gcc* again
Apr 29 18:58:26 <JaMa> undeclared constant or expected } or something, I think each time the error is a bit different
Apr 29 18:58:42 <khem> JaMa: I have changed gcc-4.7 to avoid some overlappings which should help too
Apr 29 18:58:53 <khem> oh I see
Apr 29 18:59:17 <khem> that means a .h file is not generated yet and is being referenced or included
Apr 29 18:59:38 <khem> and you said its looking in srcdir ?
Apr 29 18:59:59 <JaMa> last time we talked about it, I've blamed do_headerfix because it was running in parallel with do_configure in some other *gcc* recipe
Apr 29 19:00:09 <khem> JaMa: gcc 4.5 and 4.6 will be gone from OE-Core
Apr 29 19:00:12 <JaMa> s/do_configure/do_compile/g
Apr 29 19:00:22 <khem> would that be fine
Apr 29 19:00:35 <JaMa> yes seen it on ML.. that's why I'm rebuilding everything from scratch and fixing it
Apr 29 19:01:07 <khem> I dont want to maintain a copy in an extra layer unless its really really needed
Apr 29 19:01:29 <khem> so I would suggest tag your release with denzil to use 4.6
Apr 29 19:01:35 <khem> and then move to 4.7 on your trunk
Apr 29 19:02:17 <JaMa> I did release about month ago.. so next one is quite far now I hope
Apr 29 19:02:40 <khem> k
Apr 29 19:02:51 <JaMa> so I'm fine with e.g gtkmathview or firefox failing in feed, only blocker now for me is that webkit-efl
Apr 29 19:02:55 <khem> so you have ample time to play with gcc 4.7 then
Apr 29 19:03:22 <khem> ok do you need a fix or are you ok with tryin upgrade first
Apr 29 19:03:29 <khem> I dont have the sources handy
Apr 29 19:03:35 <khem> I could suggest otherwise
Apr 29 19:03:47 <khem> problem seems some fundamental inheritence issue
Apr 29 19:03:55 <khem> which could expose a real bug
Apr 29 19:03:57 <JaMa> I had to fix come apps because of needed glib upgrade
Apr 29 19:05:07 <khem> ok
Apr 29 19:05:18 <JaMa> so I can look at webkit-efl again, but daywork and finishing flat reconstruction first.. so probably next week or so..
Apr 29 19:05:49 <khem> will I be able to see it if I build elf-nodm-image with angstrom ?
Apr 29 19:05:53 <khem> I have angstrom setup handy
Apr 29 19:06:10 <khem> or just try webkit-efl may be ?
Apr 29 19:06:17 <JaMa> no but it's part of meta-efl.. so just bitbake webkit-efl will show it to you too
Apr 29 19:06:26 <khem> ok
Apr 29 19:06:33 <khem> let me see if I can reproduce it
Apr 29 19:06:48 <JaMa> if you want to test it in runtime then eve is based on it
Apr 29 19:06:51 <JaMa> also in meta-efl
Apr 29 19:06:57 <khem> btw. I tried to reproduce your gold/armv4t issue on qemu/armv4t
Apr 29 19:07:03 <khem> did not get the problem
Apr 29 19:07:14 <khem> I built bash into image
Apr 29 19:07:19 <khem> played with it
Apr 29 19:07:23 <khem> all seemed fine
Apr 29 19:07:39 <JaMa> do you want binary image to test?
Apr 29 19:08:05 <khem> statically linked ?
Apr 29 19:08:19 <khem> ok yeah that will work too
Apr 29 19:08:46 <JaMa> http://build.shr-project.org/shr-2012.01/images/om-gta02-broken-gold/
Apr 29 19:09:02 <JaMa> you can chroot to it from your gold/armv4t and you should see it too
Apr 29 19:09:23 <JaMa> I did when I was testing it from working image
Apr 29 19:09:28 <khem> I wont be doing it today
Apr 29 19:09:36 <khem> so will those live there forr a while ?
Apr 29 19:10:30 <khem> JaMa: you said you see a segdault right ?>
Apr 29 19:19:31 <JaMa> iirc sigill
Apr 29 19:20:33 <JaMa> yup it should be SIGILLs
Apr 29 19:20:56 <JaMa> sorry for slow response I was waiting for OOM killer to kill webkit-gtk build ..
Apr 29 19:21:11 <halstead> khem, Sorry about the delay. The skin on https://bugzilla.yoctoproject.org/ and  https://bugzilla.yoctoproject.org/test/ look the same to me.
Apr 29 19:21:28 <halstead> khem, Is one of them different for you?
Apr 29 19:32:29 <JaMa> khem: I've found couple of old build logs with gcc failing http://build.shr-project.org/tests/jama/gcc-upgrade-issue/
Apr 29 19:59:26 <JaMa> khem: and latest webkit-efl fails like this http://pastebin.ca/2142050 but it could be issue just now in tree (at least for last ~100 revs) not related to gcc-4.7
Apr 29 20:06:23 <halstead> Upgrade to Bugzilla 4.2.1 complete.
Apr 29 20:06:32 <halstead> I am still working on smoothly recategorizing and renaming classifications, products, and components.
Apr 29 20:06:43 <halstead> Total actual downtime was 6 minutes. Completed with 0 warnings, 0 errors.
Apr 29 20:24:44 <JaMa> khem: looks like webkit-efl got broken for armv4t by http://trac.webkit.org/changeset/109834/trunk and then it fails the same like old revision we had :) Unknown parameter math for tags/attrs
Apr 29 20:29:45 <JaMa> khem: and that is related to this http://trac.webkit.org/changeset/84123, because now -P is back somehow http://pastebin.ca/2142052
Apr 29 21:33:17 <RP> Andy44: I didn't mean anything for or against binary blobs
Apr 29 21:33:51 <RP> Andy44: Personally, like most open source developers I dislike them but that isn't why we don't have kernel headers in the sdk, its just that nobody has ever added that support
Apr 29 21:40:53 <khem> JaMa: yes I see, I think thats the problem
Apr 29 21:41:54 <JaMa> khem: fixed..
Apr 29 21:42:37 <JaMa> there is another issue a bit later in build.. rerunning build again to test fix for that
Apr 29 21:53:52 <Andy44> Thanks!
**** ENDING LOGGING AT Mon Apr 30 02:59:58 2012

**** BEGIN LOGGING AT Mon Apr 30 02:59:59 2012
Apr 30 14:20:42 <RP> halstead: Rather than go out of diskspace as we currently are on the autobuilder, it might be an idea to rig up some kind of warning :/
Apr 30 14:48:49 <halstead> RP, It is supposed to send warning e-mails. I must not have set up the warnings for network storage properly.
Apr 30 15:28:08 <StanleyHsu> list
Apr 30 15:29:16 <StanleyHsu> I am new to both yocto and angstrom....any suggestion for which one to pick up?Thanks
Apr 30 15:36:49 <fray> angstrom is a larger distribution with capability for more things currently.  Yocto Project's build system is smaller, and more focused on creating a starting point for people to build upon..
Apr 30 15:37:30 <fray> if you want a basic system and the Yocto Project's objectives meet your needs then that is a good place to start, you can always use that knowledge and transition to Angstrom if necessary..
Apr 30 15:37:45 <fray> but if you need a larger set of software to draw from Angstrom is not a bad choice at all
Apr 30 15:43:40 <RP> sgw: that fetcher bug is a duplicate of another already in the system
Apr 30 15:44:31 <sgw> Ok, bugzilla's helpful suggestions did not pick up on that!  What's the bug #?
Apr 30 15:44:53 <RP> sgw: I was trying to avoid looking that up :/
Apr 30 15:45:04 <sgw> Ok, I will try and dig it up
Apr 30 15:45:41 <RP> sgw: 2311 and there was discussion with Gary on the mailing list
Apr 30 15:45:52 <sgw> Ok, I will mark it dup
Apr 30 17:23:05 <nitink> RP, sgw: what is the purpose of the master-next branch?
Apr 30 17:24:11 <kergoth> I'd guess its the bits that would be in master if it wasn't for the release period, but *shrug*
Apr 30 17:24:34 <sgw> nitink: that was a holding place for RP planned work, similar to my MUT branch
Apr 30 17:35:54 <nitink> sgw: so it is a testing bed before commits go in the master
Apr 30 18:53:59 <seebs> Idle thought:  Should there be a stable/supported/clean way to do dictionary/hash mappings in bitbake variables, as opposed to overloading flags for them?
Apr 30 18:54:44 <seebs> I noticed that the flag mechanism has quirks (you can't use VAR[doc] for documentation if you're using the flags as a list of things, for instance), and I sorta wonder if this would be worth adding some functionality for.
Apr 30 18:57:29 <fray> I'm wondeing if var[doc] should just be excluded or something
Apr 30 18:57:43 <fray> might also be nice if there was a way to queery the var[doc]
Apr 30 18:59:11 <seebs> I think... fundamentally, the flags thing feels like it's intended for a different kind of operation.
Apr 30 18:59:21 <seebs> Unfortunately, that's the most natural and unconfusing spelling for dictionaries, too.
Apr 30 19:00:12 <seebs> Okay, crazy proposal:  We redefine flags to be var.flag, and use var[flag] for dictionaries.  Breaking change, but easy to identify and fix, and results in cleaner behavior in future.  Totally worth it.
Apr 30 19:24:53 <fray> I honestly don't know if flags are used for anything other then the dictionaries, and the items exported by bitbake..
Apr 30 19:25:03 <fray> the ones from bitbake are specific to the individual tasks..
Apr 30 19:25:12 <fray> I've never seen a variable with a flag (that ic an remember)
Apr 30 19:29:10 <kergoth> flags are used all over the place to exert control over bitbake and describe variables. 'easy to idenitfy and fix', i think not, unless you mean massive sed operations for little to no gain
Apr 30 19:31:41 <fray> kergoth beyond the bitbake control (tasks and vardeps stuff), and the var[doc].. where else is it commonly used?
Apr 30 19:32:42 <seebs> Hmm.  If they are that widely used, I guess my crazy proposal loses.
Apr 30 19:32:56 <seebs> Maybe something like VAR{key} = "value"?
Apr 30 19:34:16 <kergoth> I don't think we should *ever* break file format compatibility with the current recipes. I think it's valid to add to it, but not change/remove what exists, unless we decide to add support for an entirely new file format
Apr 30 19:34:22 <kergoth> but others may disagree, that's just my view
Apr 30 19:34:49 <seebs> You're probably right.
Apr 30 19:35:25 <seebs> Thus the proposal being tagged as "crazy".  It's just that I remember reading about how dmr decided not to fix an obvious precedence bug that has bitten millions of people because they had, at the time, *thousands* of lines of code.
Apr 30 19:35:49 <seebs> So I always like to ask whether a crazy change might improve clarity or QoL in some way enough to be worth it.  In this case, probably not if flags are widely used.
Apr 30 19:45:49 <kergoth> it depends on your definition of widely used, i expect
Apr 30 20:00:01 <RP> seebs: I can't really see the value winning over the pain
Apr 30 20:00:50 <seebs> I wasn't seeing any/many flags outside the TUNEVALID/TUNECONFLICTS stuff, but then, I have read only a tiny tiny portion of the tree.
Apr 30 20:01:31 <seebs> So, stealing that notation isn't viable.  Would it be remotely practical to add dictionary support using some other notation, so as to have dictionaries which aren't just implemented using the flag functionality?
Apr 30 20:01:52 <seebs> 'cuz really, it seems like flags should be metadata, and the tunevalid/tuneconflict stuff is really just data.
Apr 30 20:03:25 <RP> seebs: You're really working in an edge case so the abuse is probably reasonable
Apr 30 20:03:36 <RP> seebs: not many people get into those details
Apr 30 20:03:54 <RP> seebs: There are more user visible things I'd rather prioritise really
Apr 30 20:04:31 <seebs> Well, there's at least one more similar case that I'm looking at, and frankly a ton of the tune stuff we're doing already is doing stuff which probably ought to be expressed as dictionaries rather than lots of separate variables with patterned names.
Apr 30 20:05:07 <seebs> Stuff like TUNE_PKGARCH_tune-${DEFAULTTUNE}, etc.
Apr 30 20:05:34 <seebs> What worries me about it is mostly that I have seen at least two completely different idioms for dealing with "map keys to values" in use.
Apr 30 20:05:45 <fray> seebs, that stuff is "override" based..
Apr 30 20:06:02 <RP> fray: its worse than that, it doesn't even use overrides properly
Apr 30 20:06:21 <fray> it did in an earlier incantation.. but it got modified before it was accepted
Apr 30 20:06:27 <RP> well, I guess it does, we just abuse things to get other information back I guess
Apr 30 20:07:31 <seebs> My thought is sort of:  If we keep needing key-to-value maps, we're eventually going to produce a good way to do it, and the sooner that happens, the less extra work.  Probably.
Apr 30 20:07:58 <seebs> ... and yes, I think I am sort of volunteering to do it in my Copious Free Time if anyone's inclined to accept such patches.  But that requires me to find a proposed feature that people would like.
Apr 30 20:21:17 <awsation> fray and/or seebs, a quick question: I know that ${STAGING_LIBDIR} refers to tmp/sysroots/qemux86/lib/. What bb variable refers to tmp/sysroots/qemux86/usr/lib ? thanks
Apr 30 20:21:38 <seebs> No clue.
Apr 30 20:22:11 <fray> that should be libdir..
Apr 30 20:22:27 <awsation> ${LIBDIR}?
Apr 30 20:22:35 <fray> no the staging_libdir
Apr 30 20:22:45 <fray> I thought ther was a second staging_base_libdir for the "/lib
Apr 30 20:23:07 <fray> I'd suggest you do bitbake -e <task> and get for STAGING.. that may tell you what you need
Apr 30 20:24:27 <fray> 'er.. get -> grep
Apr 30 20:24:35 <awsation> got it.
Apr 30 20:24:37 <awsation> thanks
Apr 30 20:31:27 <RP> awsation: STAGING_LIBDIR refers to xxx/usr/lib
Apr 30 20:33:34 <awsation> I found it. thanks RP
Apr 30 20:50:20 <seebs> Hmm.  Should I maybe move the feature: description list out of the toolchain sanity check and into the "OE Build Configuration" listing?
Apr 30 20:50:46 <seebs> I just wanted it because it was really useful to see, and it's handy for confirming that the tuning you've picked is the one you thought you wanted.
May 01 02:23:28 <StanleyHsu> How to fix md5 checksum error after breaking a 'MACHINE=qemuarm bitbake core-image-minimal' by mistake and want to resume it...
May 01 02:24:06 <StanleyHsu> ERROR: Function 'File: '/home/bingxu/OE/poky-edison-6.0.1/build/downloads/linux-2.6.37.2.tar.bz2' has md5 checksum 919d84b1285b4e7177582a6ce801b147 when 89f681bc7c917a84aa7470da6eed5101 was expected (from URL: 'http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.37.2.tar.bz2')' failed
May 01 02:28:12 <khem> StanleyHsu: hmmm I wonder why the checksums are different
May 01 02:28:37 <khem> StanleyHsu: can you do bitbake -ccleanall virtual/kernel; bitbake -cfetch virtual/kernel
May 01 02:28:42 <khem> and see if that fixes it ?
May 01 02:29:00 <khem> it could be that you have a corrupted tar downloaded
May 01 02:31:01 <StanleyHsu> yes....a corrupted tar downloaded....interrupted by mistake CTRL+C
May 01 02:31:44 <khem> k
May 01 02:34:37 <StanleyHsu> Thanks for your help...the build process works.....
May 01 02:34:55 <StanleyHsu> Any suggestion for learning the yocto? learn the bitbake usage and the syntax of metadata first?
May 01 02:41:45 <otavio> Hi ... what is the MSG that is cited on Yocto's release notes?
**** ENDING LOGGING AT Tue May 01 03:00:01 2012

**** BEGIN LOGGING AT Tue May 01 03:00:03 2012
May 01 04:43:08 <pidge> otavio: It's a joke.
May 01 09:43:18 <bluelightning> hi all
May 01 13:49:42 <Andy44> Congrats on getting 1.2 out!  I can't wait to try 'er out!
May 01 15:08:19 <nitink> Good Morning All !
May 01 15:10:37 <RP> reaperofsouls: I've tagged bitbake 1.15.2 which matches the release
May 01 15:10:51 <kergoth> excellent
May 01 15:12:05 <RP> Andy44: thanks :)
May 01 15:46:08 * nitink is getting hit by this auto tools issue for guile upgrade: http://paste.ubuntu.com/960251/ any insight/help to get it resolved is welcome
May 01 15:56:38 <halstead> sgw, Regarding extra bugzilla fields, is now a good time for you to work through it with me?
May 01 15:57:19 <sgw> halstead: no, about to go into another meeting
May 01 15:57:41 <halstead> sgw, Thanks. I'll check in later.
May 01 15:59:44 <sgw> halstead: I will ping you when I am available again
May 01 16:02:23 <RP> nitink: the error is: sed: -e expression #1, char 9: unknown option to `s'
May 01 16:02:33 <RP> nitink: I don't know what is calling sed or why it breaks
May 01 16:02:57 <nitink> RP: I am still finding where is the code for that error
May 01 16:02:57 <RP> nitink: The AC_INIT comment also looks significant
May 01 16:03:08 <RP> sed: -e expression #1, char 9: unknown option to `s'
May 01 16:03:16 <RP> configure.ac:39: error: AC_INIT should be called with package and version arguments
May 01 16:03:31 <nitink> RP: sed error does not have any line number
May 01 16:07:40 <nitink> RP: I think those 2 errors are separate
May 01 16:07:59 <nitink> and I am trying to look at cause of the sed error
May 01 16:08:13 <nitink> and the AC_INIT error may be sideeffect of the 1st sed error
May 01 16:13:07 <nitink> RP: or the sed line is not an error ?
May 01 16:18:09 <nitink> RP: I see a 39955 chars long aclocal command is failing
May 01 16:19:56 <nitink> RP: look at /tmp/delme2 at yocto-hm1
May 01 16:24:39 <msm> i have a recipe that uses autotools and it's install python stuff in /usr/lib when it needs to be installed in /usr/lib64… what's the normal override I pass to configure to install it in /usr/lib64 instead
May 01 16:24:47 <msm> —libdir=${libdir} did not effect the python foo
May 01 16:24:49 <msm> AFAICT
May 01 16:26:34 <msm> its /usr/lib/python2.6/site-packages stuff
May 01 16:29:13 <kergoth> read the autotools bits and see how it's coming up with it
May 01 16:32:25 <msm> which would that be in?
May 01 16:32:29 <msm> Makefile.am?
May 01 16:32:32 <msm> Makefile.in?
May 01 16:33:35 <msm> i need to read a book on autotools
May 01 16:33:47 <msm> stop guessing what's going on
May 01 16:35:06 <bluelightning> automake uses the .am to produce the .in, then the (presumably autoconf generated) configure script turns the .in file into the final Makefile
May 01 16:37:38 <walters> msm, very likely the .am file uses $(prefix)/lib instead of $(libdir)
May 01 16:38:49 <msm> i found one hard coded reference to lib/ in the python foo
May 01 17:01:26 <reaperofsouls> RP: Thank you.
May 01 17:44:48 <sgw> khem: ping
May 01 17:58:12 <sgw> fray: ping
May 01 18:02:49 <Crofton|work> lonely?
May 01 18:04:15 <sgw> Crofton|work: no, trying to get some follow up on bugs!
May 01 18:05:18 <Crofton|work> heh
May 01 18:05:41 <Crofton|work> Now there is a release, I need to send in my patch to let you put bitbake in other places for oe-core
May 01 19:11:03 <sgw> halstead: you around?
May 01 19:17:46 <halstead> sgw, Yep.
May 01 19:52:15 <msm> RP: have you given though how to conditionally include multilib packages if it's enabled?
May 01 19:52:34 <RP> msm: in what sense?
May 01 19:52:37 <msm> like if we have turned on multilib and are building a toolchain, why not include both variants?
May 01 19:53:09 <msm> i've tried this: http://pastebin.com/TS7mZmmF
May 01 19:53:13 <RP> msm: I think this gets into a policy area for the user...
May 01 19:53:24 <msm> but its only building the package and not including it in the image
May 01 19:53:48 <RP> msm: ick ;-)
May 01 19:53:54 <msm> well im trying to make an image for the user which would contain all toolchains
May 01 19:54:10 <msm> it works at the IMAGE_INSTALL level I believe
May 01 19:54:15 <msm> not the RDEPENDs task level
May 01 19:55:15 <RP> msm:  bb.data.inherits_class("multilib", d) is a better test
May 01 19:56:24 <RP> msm: You probably need to write a python function which does the right things, then call that from the inline python
May 01 19:57:50 <msm> RP: do you have an opinion on adding an override if multilib is enabled?
May 01 20:01:17 <RP> msm: we don't need that
May 01 20:01:33 <msm> images themselves might need it
May 01 20:03:24 <seebs> Okay, quick summary of my idle curiousity project:
May 01 20:03:57 <seebs> It's not stupendously hard to add a trace to BBHandler.py and trace file inclusions, and a nested tree showing them really does explain a LOT about what happens during parsing.  But I am not good enough to do it elegantly.
May 01 20:10:43 <seebs> ... well, that's something.  Now I realize -- and I didn't know this -- that there's more than one context processing files, and one of them can cause another to read more stuff.
May 01 20:27:28 <RP> seebs: there are multiple contexts but they shouldn't interfer with each other
May 01 20:28:07 <RP> msm: images have other ways of telling whether multilibs are enabled, overrides aren't useful there really
May 01 20:29:23 <seebs> Ohh, wait.  I just realized, these are happening simultaneously, that's why I'm seeing stuff jump "out of order".
May 01 20:29:35 <RP> seebs: parallel parsing
May 01 20:30:01 <seebs> Anyway, casual observation suggests that if a pretty way to do this could be found, it would sure be awfully useful as a diagnostic tool.
May 01 20:31:19 <RP> seebs: that is interesting feedback. I wonder how we'd convey it to the user though...
May 01 20:32:08 <seebs> Well, the first thing that comes to mind is just in the temp directory for a package, create something like a log.do_parse which contains the tree.
May 01 20:32:20 <seebs> Where it's just sequential order, with includes indicated by indentation.
May 01 20:32:59 <seebs> http://pastebin.com/2fhJ0Zma
May 01 20:33:23 <seebs> And one for the project configuration parse, maybe.
May 01 20:33:51 <seebs> Given the number of times I've personally gotten lost trying to figure out why one file appeared to be getting hit before or after another, I'm sort of assuming this would be of value to other people too.  :)
May 01 20:35:38 <RP> seebs: the other thing I know people would like is a "where did X get set" type output
May 01 20:35:46 <RP> i.e. in file X, line Y
May 01 20:36:05 <RP> complete history of  a variable would be even more interesting
May 01 20:36:32 <seebs> Yeah.
May 01 20:37:19 <seebs> Okay, idle question:  Are people interested in a patch for that?  Because I want some of that functionality enough to be willing to work on it even if WR won't pay me to.  :P
May 01 20:38:08 <RP> seebs: Its just a question of doing it cleanly and without blowing up our memory footprint or parsing time
May 01 20:38:49 <msm> RP: how would one test in an image recipe if multilib is enabled? via an anonymous python function?
May 01 20:39:10 <RP> msm: You're trying to add extra packages, right?
May 01 20:39:50 <msm> RP: umm i'm trying to get it in the image ;)
May 01 20:40:05 <msm> i tried via tasks, it works fine via IMAGE_INSTALL
May 01 20:42:32 <seebs> ...
May 01 20:42:39 <seebs> Well, history I don't think I can do.
May 01 20:42:46 <seebs> But I think it may actually be cheap to get line numbers.
May 01 20:44:02 <RP> msm: I'd use something like http://pastebin.com/LYuAcwE1
May 01 20:44:43 <msm> RP: ooooh neato ;)
May 01 20:54:37 <seebs> http://pastebin.com/8SAm5VJy
May 01 20:54:44 <seebs> Obviously not a desireable output format, to put it mildly.
May 01 20:54:51 <seebs> But proof-of-concept it is.
May 01 20:55:44 <seebs> Observation:  Nearly all variable setting originates with __config_regexp__ returning a dictionary of match data.  You can add filename and lineno to that dictionary, and then it's available wherever you have that, such as in DataNode.
May 01 20:56:59 <seebs> Not super pretty, but the marginal cost of adding two small values to some dictionaries should be small, and then there could be a getVarSource(...) or something.
May 01 20:59:15 <RP> seebs: history suggests those two small values might cause a few problems
May 01 20:59:34 <seebs> Memory consumption, or namespace pollution, or both?
May 01 20:59:44 <RP> seebs: memory usage
May 01 21:00:06 <RP> seebs: we would probably need to be clever about when we did this but for "tracing enabled" we could probably not care
May 01 21:00:35 <seebs> We're already passing file and lineno into ast.handleData().
May 01 21:00:57 <seebs> And come to think of it.  AstNode() is already keeping that too.
May 01 21:01:08 <kergoth> seebs: it's not two small values per variable. it's a list of values, given append/prepend
May 01 21:01:20 <kergoth> and what those values are will depend on the current overrides
May 01 21:01:29 <seebs> Wait a second.  I had not comprehended AstNode yet.
May 01 21:01:36 <seebs> The AstNode *already* has self.filename/self.lineno.
May 01 21:02:03 <kergoth> the info is lost going from that into the DataSmart object
May 01 21:02:08 <seebs> Yeah.
May 01 21:02:34 <seebs> Hmm.  True, this is useless for append/prepend.
May 01 21:02:47 <seebs> For the case where you just care who touched it last, it's trivial to get the information you want.
May 01 21:03:12 <seebs> The history would be expensive to keep, so that would want to be tracing-only.
May 01 21:04:10 <seebs> Hmm.  Here's my thought:  A simple solution that only works in tracing mode and even then is not expected to catch everything, just raw assignments in files, would probably be an hour or two of work, and solve 90% of the problem.
May 01 21:05:07 <seebs> So we don't try to fix the case where someone has a python configuration thing that calls setVar directly, or whatever, and then we have something that can be done cheaply and will answer the questions that are mostly actually coming up, like "where did this penguin come from?"
May 01 21:09:10 <RP> seebs: the worry is then that people don't trust the info as we can show it is incorrect at times. Or can we show when we don't know?
May 01 21:09:39 <seebs> We could!
May 01 21:09:42 <RP> seebs: not trying to be negative, just speaking as someone who already spends too much time in the bugzilla
May 01 21:10:02 <seebs> Hey, it's a real problem.  My main argument is that it doesn't matter how perfectly you do things, people will STILL be confused.  :P
May 01 21:10:15 <RP> seebs: agreed
May 01 21:10:16 <seebs> But okay, here's my idea.  Imagine that we have a tracing mode which is enabled by some configuration widget.
May 01 21:10:34 <RP> seebs: I think a tracing mode makes a lot of sense...
May 01 21:10:40 <seebs> We change the signature for data.setVar() to (var, value, filename = None, lineno = None)
May 01 21:10:53 <seebs> or possibly filename = 'unknown', lineno = 'unknown'
May 01 21:11:23 <seebs> If tracing mode is enabled, then when we create a new node, we give it an empty array of modifications, and on each setvar, we store { newvalue, filename, lineno } in that array.
May 01 21:11:36 <seebs> We then add .getHistory(var), which returns that history.
May 01 21:12:30 <RP> seebs: its worth some further thought/investigation...
May 01 21:12:33 <seebs> And in trace mode, something at the end (around sanity.bbclass) writes (by default) a log of getHistory[-1] for everything.
May 01 21:13:00 <RP> seebs: How about bitbake -e triggers this and prints the variable history as part of the comments?
May 01 21:13:10 <seebs> Or possibly even something like MACHINE [18 modifications]: qemux86
May 01 21:13:13 <seebs> I like.
May 01 21:13:39 <seebs> In non-trace mode, we pay the cost of adding two already-calculated-and-available arguments to a handful of setVar calls.
May 01 21:13:56 <RP> -e is usually one shot anyway, I don't care about the overhead there
May 01 21:14:17 <seebs> Well, the calls might be there -e or not, but outside of -e we'd ignore the values.  Should be cheapish?
May 01 21:14:22 <seebs> I have no real model of Python's cost.
May 01 21:14:45 <seebs> Now for the newbie question:  How do I detect that we're in -e?
May 01 21:22:53 <RP> seebs: should be cheapish, yes
May 01 21:23:11 <RP> seebs: you'll probably have to set some flag in the cooker configuration code
May 01 21:23:31 <RP> seebs: There is no global state for the parser at the moment which is annoying
May 01 21:23:54 <RP> I've just done some profiling of our rootfs generation speed
May 01 21:24:08 <RP> I'm not happy at all about some of the stupid things we're doing :(
May 01 21:52:02 <zenlinux_> RP, I'd like to take some work off your hands if possible - can you get me push access to the oe-core git repo so I can push to denzil-next?
May 01 21:52:14 <Crofton|work> RP, oe is still way better than other build systems
May 01 21:52:26 <zenlinux_> Otherwise I can maintain two poky contrib branches, one based on oecore, and one based on poky.
May 01 21:52:46 <zenlinux_> (for denzil-next)
May 01 21:52:48 <RP> zenlinux_: lets start with oecore-contrib
May 01 21:52:58 <zenlinux_> ok, that works too
May 01 21:53:03 <zenlinux_> who do I send my ssh key to?
May 01 21:53:08 <RP> zenlinux_: I'm not sure OE ever did branch based acls (yocto did add them)
May 01 21:53:21 <RP> zenlinux_: I'll just fix this, its easier
May 01 21:54:49 <RP> zenlinux_: you should have access to oecore-contrib now
May 01 21:55:29 <Crofton|work> what is oecore-contrib?
May 01 21:55:45 <RP> Crofton|work: http://git.openembedded.org/openembedded-core-contrib/
May 01 21:55:57 <RP> Crofton|work: place to share trees for pull requests
May 01 21:57:48 * RP notes he should clear up his branches there
May 01 21:59:36 <zenlinux_> RP, thanks, it works
May 01 22:00:43 <seebs> Okay, this is almost usable.  Is there a cheap way (over in bitbake/data.py, in emit_var) to strip the parent directory when it's the directory containing build, meta, etc.?
May 01 22:02:03 <seebs> Oh, hey, $COREBASE.
May 01 22:02:05 <Crofton|work> I need to send you may patch that lets you put bitbake somewhere else
May 01 22:02:50 <RP> seebs: Note that COREBASE is a metadata defined variable, bitbake has no knowledge of it
May 01 22:03:23 <seebs> Yeah, but I am looking at the metadata.  So I can abuse that.  I want to see whether it improves the output enough to make up for the crawling sensation.
May 01 22:04:03 <RP> seebs: I just mean that any patches against generic bitbake code using COREBASE will be rejected :(
May 01 22:05:18 <seebs> Fair enough.  Hmm.  Boy, that really does improve legibility.  Is there any sane way for bitbake to refer to "that directory all this stuff is in"?  If not, I can live without it.
May 01 22:06:03 <seebs> It makes the difference between most variable assignments wrapping and most not wrapping, so it's worth a fair bit of effort, I think.
May 01 23:01:29 <seebs> Okay, that was amusing.  I could not for the life of me figure out why tracking wasn't staying enabled.  Answer:  There's "data = bb.data.createCopy(data)" in there.
May 01 23:01:31 <seebs> I have no idea why, but that was replacing a thing with tracking with a thing without tracking.
May 01 23:30:47 <seebs> I am totally failing to understand the override logic.
May 01 23:33:35 <seebs> So far as I can tell, if you set foo = "bar", and later set foo_something = "baz", then ultimately foo will get set to "baz" because foo_something is an override for foo.
May 01 23:34:21 <kergoth> seebs: if 'something' is listed in OVERRIDES, yes
May 01 23:34:32 <seebs> Ahh, that's what I'm missing.
May 01 23:35:43 <seebs> So this is stuff like PREFERRED_VERSION_linux-yocto_qemuarm winning over PREFERRED_VERSION_linux-yocto.
May 01 23:35:46 <kergoth> conceptually, OVERRIDES is similar to the 'include' order in bitbake.conf. it's a mechanism by which we get layered metadata by specificity. more specific information overrides less specific. machine information is used in preference to arch which is use din preference to the default value.
May 01 23:36:12 <seebs> Gotcha.
May 01 23:36:29 <kergoth> so overrides aren't just applied, they're applied in priority order
May 01 23:36:45 <seebs> This will be hard to express in my otherwise-pretty log.  :)
May 01 23:36:48 <kergoth> of course, under the hood it's really just a way to implement conditionally defined values for variables
May 02 00:33:33 <seebs> Sent a draft of the variable history tracking to the list.  Not really a pull request yet, just a rough draft in case of comments or people who need it to get something done.  :)
May 02 00:59:28 <dvhart> seebs, oooh, on my list to review tomorrow!
May 02 01:00:20 <seebs> I kept hearing people say they wanted it, *I* wanted it, and I'm supposed to be learning more about bitbake.  What better way than to mess with the data_smart class?
May 02 01:10:26 <dvhart> seebs++
May 02 01:11:02 <dvhart> yocti, karma seebs
May 02 01:11:02 <yocti> dvhart: Karma for "seebs" has been increased 2 times and decreased 0 times for a total karma of 2.
May 02 01:11:07 <dvhart> ;)
May 02 01:11:19 <seebs> There are stupid bugs in that patch, actually.
May 02 01:11:37 <dvhart> early and often, don't worry about it - thanks for doing it
May 02 01:11:40 <seebs> I "fixed" a couple of things at the last minute and forgot to sanity-check them on a sample of builds, and the one I was using happened not to trigger them.
May 02 01:12:01 <seebs> It's calling functions without extra arguments, or with, and forgetting to supply the defaults.
May 02 01:12:02 * dvhart handles SIGCHILDRENARECRYINGANDSPOUSEISEXHAUSTED
May 02 01:12:17 <dvhart> seebs, will review manana
May 02 01:12:21 <seebs> Cool..
May 02 01:12:43 <seebs> Yeah, that's an important signal to take.  Not good to put it in your signal mask, there can be unexpected issues.
May 02 01:14:10 <seebs> And... I'm back to my cryptic x86_64x86_64 problem.  The bright side is, I can actually EXPLAIN it now!
May 02 01:15:17 <seebs> Huh, it's exactly what I thought it was -- I'm getting arch-ia32.inc twice, and the TUNE_ARCH are additive.
May 02 01:25:07 <seebs> That's surreal.
May 02 01:25:41 <seebs> Trying to add a BBCLASSEXTEND sanity check for completeness, and I can't test it, because if I add anything, even a dummy empty class, to BBCLASSEXTEND I get strange failures expanding SRCPV.
May 02 01:26:12 <kergoth> man, data_smart.. COW.py is serious voodoo
May 02 01:26:35 <seebs> ... oh, wait, I'm running the test in the wrong directory, heh.
May 02 01:26:53 <seebs> data_smart isn't bad once you've poked around in it for an hour or two.  :)
May 02 01:30:59 <kergoth> nah, it's the underlying cow bit that's pretty .. not pleasant. uses metaclasses as classes and classes as objects as an optimization
May 02 01:34:08 <seebs> Ahh, hadn't gotten into that.
**** ENDING LOGGING AT Wed May 02 02:59:58 2012

**** BEGIN LOGGING AT Wed May 02 02:59:58 2012
May 02 06:20:37 <mckoan> good morning
May 02 06:32:01 <eFfeM_work> gm all
May 02 06:32:14 <eFfeM_work> someone should change the topic to mention 1.2
May 02 06:32:53 <eFfeM_work> btw 1.2 does not work with meta-oe head due to meta-oe using qt4.8.1 and 1.2 having qt 4.8.0
May 02 07:24:45 <JaMa> sgw: ping
May 02 07:26:23 <JaMa> sgw: glib-2.32.2 was released yesterday, so I'll upgrade glib-2.0 again and now it's failing for those tests from yocto #2369, do you have that patch applied somewhere or should I take it from bugzilla and send it in next pull request?
May 02 08:44:27 <bluelightning> morning all
May 02 10:46:45 <hwinkel> good morning
May 02 11:17:03 * jwessel searches for a MAINTAINERS file in the top of the git tree, but there does not seem to be one.
May 02 11:22:01 <jwessel> Is the https://lists.yoctoproject.org/ actually up to date?  I have a patch for scripts/runqemu*, but it is not very obvious where to send it since there is no map of files / directories to developer mailing lists.
May 02 11:25:11 <bluelightning> jwessel: if it's a patch to the core metadata (meta/, scripts/ etc.) then it should go to the openembedded-core mailing list: http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
May 02 11:26:35 <jwessel> Would it be possible that someone put a MAINTAINERS file together to explain where things go? :-)
May 02 11:26:53 <jwessel> bluelightning: Thanks.  That is where I'll send the patch.
May 02 14:22:47 <karw> has anyone build yocto for i486?
May 02 14:24:29 <denisATeukrea> not me at least
May 02 14:24:39 <denisATeukrea> but maybe state your problem
May 02 15:12:20 <sgw> JaMa: If you are still around, RP noted that the patch for 2369 will be need possibly for all arches
May 02 15:12:39 <JaMa> I've sent it to ML + ix86 and x86-64
May 02 15:12:54 <JaMa> I don't know what are correct values for other archs
May 02 15:16:54 <sgw> JaMa: Does this address the issue found with eds and qt4 builds?
May 02 15:17:30 <sgw> JaMa: ie did you build world or ?
May 02 15:26:57 <JaMa> sgw: not world, but my images + feed (which have qt4-x11-free but not eds)
May 02 15:27:37 <JaMa> and the issue with alignment in do_configure was only after switch from 2.32.1 to 2.32.2
May 02 15:28:00 <JaMa> qt4-x11-free was and still is building fine for my arm targets and qemux86-64
May 02 15:28:19 <sgw> hmm, I found problems with eds and qt4 in my builds the qt4 might have been the gcc4.7 issue though
May 02 15:28:43 <sgw> eds was clearly a deprecated g_atexit() call
May 02 16:03:27 <seebs> I am wondering whether I can add include nesting tracking to my assignment tracking.  Because I want that too.
May 02 16:06:19 <fray> foo was included by bar  like tracking?
May 02 16:08:08 <seebs> yeah
May 02 16:08:30 <seebs> I sort of imagine a chart at the top of the -e output which shows the internal list of things to read, and then what is included by them, and so on.
May 02 16:08:47 <seebs> Again, I care about this because I don't understand bitbake well enough to figure out where stuff is getting set or when.
May 02 16:09:43 <seebs> BTW, is it intentional that the name data is sometimes a class, such that it's data.setVar(name, value, data_store), and sometimes an object, such that it's data.setVar(name, value)?
May 02 16:09:47 <seebs> Because man, is that confusing.
May 02 16:15:20 <kergoth> thats why we usually call it 'd' rather than 'data', to avoid that confusion. also, we shouldn't be doing the 'from bb import data' thing at all, should use bb.data. explicitly in that case
May 02 16:15:34 <seebs> k
May 02 16:16:08 <seebs> Would anyone be offended if I wanted to toss out a patch for that, and for the inconsistency of cfgData/configdata, at some point?  They keep annoying me by being imperfect.
May 02 16:19:19 <sgw> fray: morning, need to bug you about some bugs
May 02 16:19:26 <fray> yup..
May 02 16:19:33 <fray> I ended up leaving early yesterday (kid got sick)
May 02 16:20:13 <sgw> Yeah, I have a kid at home 5 days now with pneumonia, sounds like he's coughing up a lung
May 02 16:20:29 <fray> sinus infection in her case.. but waiting at the Dr office all day sucks
May 02 16:21:30 <sgw> fray, 757 still needs retesting right?
May 02 16:22:21 <fray> ya, it should just be testing
May 02 16:22:50 <fray> last comment indicates it wasn't reproduced...
May 02 16:22:55 <fray> so i think we can close it as resolved
May 02 16:23:45 <sgw> fray OK please close and we can have QA verify it.
May 02 16:23:52 <fray> will do
May 02 16:24:31 <fray> done
May 02 16:24:51 <sgw> fray: 1659, is it different than the -n flag, your looking for different info there right?
May 02 16:25:23 <fray> looking at -n
May 02 16:26:37 <fray> ya, it's not -n
May 02 16:26:42 <fray> I'll comment
May 02 16:27:06 <sgw> Ok, let me know when you are done, I will move it to 1.3 / Usabiility
May 02 16:29:18 <fray> done..
May 02 16:29:27 <fray> the key thing is the way.. WHY is this task been picked to be executed?
May 02 16:29:50 <fray> has it not been built before, did a checksum change, is something that this item depends on been changed, etc
May 02 16:30:18 <sgw> Right, going backwards not what's going to happen by why, I just wanted to confirm.
May 02 16:30:42 <fray> yup.. the what is just the trigger for the why
May 02 16:30:57 <fray> the what do do_configure might simply be do_patch was run
May 02 16:32:37 <sgw> I think that was it, other than bugging you on your active bugs also!
May 02 16:33:36 <sgw> fray 2328 is a 1.2.1 bug that I think needs attention
May 02 16:34:08 <fray> I don't remember seeing that one before
May 02 16:34:09 <fray> looking
May 02 16:34:23 <fray> ohh, no I do know this one..
May 02 16:34:49 <fray> ya, the fix mentioned by Dongxiao is likely what we want..
May 02 16:35:31 <sgw> fray: can you follow through with the fix then please
May 02 16:35:52 <fray> ya.. I'm off tomorrow and Friday.. but we'll see if I can get to it "soon"
May 02 16:37:02 <fray> I've got three things on my immediate agenda, rpm uprev (almost done -- zypper uprev is a complete failure right now), update-alternatives, and this item
May 02 16:37:30 <fray> kergoth, here?
May 02 16:38:36 * fray goes to #oe to ask...
May 02 16:55:39 <seebs> Woot!
May 02 16:55:51 <seebs> A much prettier way of creating my include logs, although I am not totally sure it's working.
May 02 16:56:17 <seebs> I am not sure how to tell whether it's omitting files, but it looks reasonableish.
May 02 16:56:53 <seebs> Although I now see that line numbers are meaningless because they are not actual line numbers in many cases.
May 02 17:15:55 <xumbi> does anyone know of a yocto compatible ruby layer?
May 02 17:24:16 <sgw> xumbi: you could check the LayerIndex at: http://www.openembedded.org/wiki/LayerIndex, there is no Ruby specifically but maybe one of them contains a ruby recipe, OE-Classic has an older ruby recipe
May 02 17:27:29 <bluelightning> xumbi: people have talked about it but I'm not sure a layer exists yet
May 02 17:54:35 <msm> im having a problem where do_task[nostamp] = 1 is not causing the task to always be rerun
May 02 17:55:01 <msm> i cant really see why
May 02 17:55:17 <msm> it's falling back to use sstate-cache
May 02 17:55:47 <kergoth> nostamp says don't check or use stamps, i doubt it affects sstate behavior at all
May 02 17:57:11 <msm> i thought i could do
May 02 17:57:23 <msm> do_install[nostamp] = 1 do always have that step rerun?
May 02 17:57:27 <msm> its not even doing that
May 02 17:57:32 <msm> maybe im missing something
May 02 18:00:24 <kergoth> do_install is part of the tree encompassed by the populate_sysroot shared state
May 02 18:04:45 <sgw> I have recently seen a rash of pseudo getting "rebuilt" because it's out of date, this seems to be related to git changing the modtime on the meta/recipe-devtools/pseudo, anyone else see this behavior?
May 02 18:05:18 <seebs> Not I.
May 02 18:05:48 <sgw> I wonder if it has to do with my workflow of git pulls and rebases?
May 02 18:06:08 <sgw> I did not think the modification times should change  like that
May 02 18:06:20 <msm> kergoth: so… I need to disable sstate?
May 02 18:07:53 <kergoth> making do_install run every time also just doesn't make any sense, so i hope that was a contrived example :)
May 02 18:08:03 <msm> yes
May 02 18:08:07 <msm> this is for merge-files
May 02 18:09:08 <kergoth> there's no convenient way to disable sstate, as there's no -= to remove the task from the list of sstate tasks, but you could do it with anonymous python. afaik there's no easier way. or just create your own task outside the set of tasks covered by populate sysroot, and it'll be a nonissue
May 02 18:10:13 <msm> kergoth: then it will always be run? add a do_install?
May 02 18:10:30 <kergoth> hm?
May 02 18:10:32 <msm> kergoth: but then i need to rerun the ipkg/rpm foo to actually get the stuff on the system
May 02 18:10:40 <kergoth> again, do_install makes zero sense
May 02 18:10:43 <msm> i mean add a do_another_install
May 02 18:10:45 <kergoth> which is why do_install as nostamp makes no sense
May 02 18:11:00 <kergoth> by itself it's useless
May 02 18:11:28 <kergoth> yes, you could create an entire set of new tasks outside the sstate covered tasks, but that sounds like more trouble than its worth, i wasn't clear enough about what you're trying to do (still am not, but its clearly not a one-off task)
May 02 18:11:29 <msm> kergoth: yes, im seeing all this other srctree.bbclass foo which was making things work
May 02 18:12:02 <kergoth> srctree is only needed if you have bbclassextends involved -- that is, if there's a danger of task interleaving between native/cross/target
May 02 18:12:04 <msm> well, for merge files i want to always repackage the contents if the user added files
May 02 18:12:21 <kergoth> otherwise you can just zero SRC_URI and point S at hte local path
May 02 18:16:04 <seebs> Would be super interested in feedback on my proposed bitbake -e upgrades, performance concerns, suggested output improvements, etc.
May 02 18:19:02 <msm> kergoth: im just confused
May 02 18:19:14 <msm> manual says nostamp tasks are always rerun
May 02 18:19:18 <msm> that's not the case for me
May 02 18:19:37 <kergoth> wait, you think the bitbake manual is accurate and current? that's so cute!
May 02 18:19:38 <kergoth> :P
May 02 18:19:51 <kergoth> seebs: will take a look, it's queued in my inbox awaiting time :)
May 02 18:20:29 <seebs> I'm unsure about some of the logic for the include checker, and in particular, I thought of what seemed a better way to do it, but wasn't.
May 02 18:20:35 <seebs> But I will eventually figure it out.
May 02 18:20:45 <msm> kergoth: i think it's worked before
May 02 18:21:22 <kergoth> msm: you've tested it on tasks which are covered by sstate? I haven't, i honestly don't nkow how it'll behave, but in bitbake nostamp is specifically regarding stamp handling, i don't know if sstate even looks at it
May 02 18:22:14 <kergoth> seebs: heh, nearly every time i deep dive into bitbake i get very annoyed and want to throw parts of it out a window, and end up not doing much instead
May 02 18:23:00 * kergoth thinks
May 02 18:25:05 <seebs> Ahh, see.
May 02 18:25:27 <seebs> I have the same response, moreso since I dislike Python.  But!  I am coming to this from 5k of interspersed GNU Make and shell.
May 02 18:25:32 <seebs> So it's sort of an upgrade.  :P
May 02 18:26:20 <msm> kergoth: yes, for some recipe we have it works for the do_compile step
May 02 18:26:26 <seebs> If you ever want to be truly horrified by GNU make, look at the thing I wrote to allow expansion of a large macro for members of an arbitrarily large list without hitting shell command line limits or spawning a separate shell per list item.  :P
May 02 18:26:42 <msm> kergoth: im just really annoyed, i thought I knew how to make a task rerun…
May 02 18:26:53 <kergoth> msm: huh, interesting. i really have no idea then :\
May 02 18:27:45 <kergoth> seebs: yikes. make limitations is a big part of why oe/bitbake/yocto exists, really. buildroot wouldn't scale
May 02 18:27:55 <kergoth> of course, that was back before gnu make could even use macros to generate rules
May 02 18:29:19 <seebs> I seem to recall that the BSD people had better luck with their make, but even so, something higher-level really does seem like a good idea.
May 02 18:30:06 <walters> my gnu make disaster was called CDBS (http://build-common.alioth.debian.org/)
May 02 18:30:29 <walters> although it's still quite popular in debian
May 02 18:32:11 <seebs> I think everyone has to go through that phase of thinking "but really this is just build rules" once.
May 02 18:34:39 <kergoth> heh, indeed
May 02 18:35:08 <kergoth> you can see the make history when you look at bitbake. the lazy expansion and := in particular
May 02 18:35:40 <seebs> I am still horrified by the .= and =. thing.
May 02 18:36:06 <hollisb> :)
May 02 18:36:25 <kergoth> i'm not even sure where that originated, perhaps something i recalled from perl for concatenation? *shrugs*
May 02 18:36:58 <kergoth> the flags came to be when we realized that the entire thing was just a key/value store, and the only thing differentiating a task from a variable was bitbake's interpretation of it
May 02 18:37:38 <kergoth> seebs: i really want to prototype a different file format, but the problem is bitbake can't support another one at this time
May 02 18:37:44 <kergoth> everything is all tangled
May 02 18:37:58 <kergoth> the DataSmart object iself implies certain things about the format
May 02 18:39:52 <kergoth> oh well, we'll get there
May 02 18:40:48 <seebs> Well, no one has ever accused me of being afraid to destroy everything for minor cosmetic improvements.
May 02 18:40:55 <kergoth> hehe
May 02 18:41:05 <seebs> I think my current record is six consecutive build-breaking bugs from a single cosmetic fix.
May 02 18:41:14 <kergoth> impressive
May 02 18:41:16 <seebs> I changed the naming convention for toolchain wrappers.  :P
May 02 18:43:07 <seebs> because i686-target-gnu-gcc was nicer than i586-wrs-linux-gnu-x86_32-i686-glibc_small-gcc.
May 02 18:43:21 <kergoth> aha, thought so. perl's concatenation operator is '.', and has a '.=' for concate and assign. thought thats where it must have come from
May 02 18:43:32 <seebs> Oh, I know that.
May 02 18:43:42 <seebs> What bugged me was .= for append and =. for prepend.
May 02 18:43:46 * kergoth couldn't remember, avoids perl like hte plague
May 02 18:43:49 <kergoth> ah, yes :)
May 02 18:44:17 <kergoth> the problem is, we don't allow self referencing due to the lazy expansion, so you can't do A = "foo" + A or something
May 02 18:44:20 <kergoth> sadly
May 02 18:44:31 <seebs> What's killing me right now is that all my projects outside work are lua, and lua and python are... well, you know.  Not very similar.
May 02 18:44:48 <seebs> Basically, if there is a choice you can make in designing a language, they made it in roughly opposite ways.
May 02 23:51:53 <sgw> halstead: let's pull the trigger on the estimate field as soon as you can
May 03 01:31:09 <StanleyHsu> I cannot get "Yocto(Build by Poky 7.0) 1.2 qemuarm tty1"  and login session after booting from jffs2 rootfs on an at91sam9260 board with ttyS0 console  support only....
May 03 02:13:04 <msm> kergoth: ping?
**** ENDING LOGGING AT Thu May 03 03:00:01 2012

**** BEGIN LOGGING AT Thu May 03 03:00:02 2012
May 03 08:14:15 <mckoan> good morning
May 03 08:36:14 <florian> hi mckoan
May 03 09:04:48 <bluelightning> morning all
May 03 09:50:42 <kenws> morning
May 03 09:51:17 * kenws wonders what bitbake version poky-denzil-7.0 uses
May 03 09:52:08 <kenws> Does anyone know the git id for the bitbake version that is used?
May 03 10:09:49 <bluelightning> kenws: it's the 1.15.2 tag
May 03 10:11:06 <kenws> bluelightning: thanks! got it.
May 03 12:16:26 <rburton> has anyone tried using an atom-pc .hddimg inside kvm?
May 03 12:16:39 <rburton> my boot hangs at "Waiting for removable media..."
May 03 13:18:13 <mckoan> looks like The Yocto Project Quick Start page is quite outdated
May 03 13:19:11 <mckoan> section "Building an Image" uses poky-denzil-7.0 but the following are not related to its content
May 03 13:19:26 <mckoan> JFYI ;-)
May 03 13:47:41 <eFfeM_work> mckoan: are you looking at the web version or the version in the tarball, best use the former, the latter was not fully updated afaik
May 03 13:49:41 <mckoan> eFfeM_work: I was reading the web version, now the one embedded in the tarball, thx
May 03 13:50:20 <eFfeM_work> mckoan: I think the web version is better than the tarball one (at least that is what scott rifenbark told me)
May 03 13:51:42 <eFfeM_work> are you using this: http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html
May 03 13:51:53 <eFfeM_work> I more or less followed it and did not encounter a problem
May 03 13:52:01 <eFfeM_work> maybe mail your problem to the yocto list
May 03 13:53:08 <mckoan> eFfeM_work: I'm testing yocto-denzil-7.0
May 03 13:53:19 <eFfeM_work> so did I
May 03 13:54:14 <mckoan> I was reading that page too, but is nor sync with yocto-denzil-7.0 structure
May 03 13:54:36 <mckoan> anyway I was able to guess what to do ;-)
May 03 13:56:17 <eFfeM_work> hm, strange. gtw how did you get to yocto-denzil, the files on that page (and what I downloaded) was listed as poky-denzil
May 03 13:58:19 <mckoan> http://downloads.yoctoproject.org/releases/yocto/yocto-1.2/poky-denzil-7.0.tar.bz2
May 03 15:09:24 <ScriptRipper> ping pidge
May 03 15:29:18 <jmpdelos> is there an option to have builds clean up the work directories of packages after they're successfully built to reduce the total space required for a build?  I thought I remembered such a thing, but I'm not seeing it
May 03 15:30:13 <zeddii> rm_work ?
May 03 15:34:45 <jmpdelos> zeddii: that's the one.  thanks!
May 03 15:34:51 <zeddii> :)
May 03 15:35:04 * zeddii flees
May 03 15:35:08 <zeddii> since he is in sweden
May 03 16:40:15 <halstead> pidge, ping.
May 03 16:46:16 <ka6sox> hi halstead
May 03 16:48:18 <halstead> Hello ka6sox.
May 03 17:07:16 * mranostay yawns
May 03 17:46:53 <seebs> So, anyone (RP, probably) have strong feelings about the variable/include tracking stuff?  I assume I need to get on a bitbake list to submit bitbake patches.
May 03 18:01:36 <sgw> seebs, I was going to reply to that, yes you should send it to  bitbake-devel@lists.openembedded.org
May 03 18:02:25 <sgw> halstead: how's the bugzilla stuff going?
May 03 18:02:49 <seebs> I should probably get on the bitbake list.  I had forgotten that bitbake is not part of oe-core.  So many projects!
May 03 18:04:02 <halstead> sgw, Picking back up on it now. I need to add some extra milestones and versions to products in order to shift the components.
May 03 18:04:37 <halstead> sgw, The time estimate is there. I didn't move your saved search. I thought you might move it so you could update it as needed.
May 03 18:15:09 <kergoth> hmmm
May 03 18:32:18 <seebs> Ah-hah.  Figured out my include tracking problem.
May 03 18:32:58 <seebs> Problem is that there was a createCopy() happening while the include log was in an invalid state, which was used only for the special case of createCopy() used to handle a := assignment.
May 03 19:15:15 <sgw> khem: ping
May 03 19:42:21 <seebs> Huh.  Following some advice on the Internet, I tried writing "sys.exc_clear()", and got a message saying that the global name 'sys' is not defined, but elsewhere I was told it was always available.  Do I still need to import stuff from it?
May 03 19:44:11 <seebs> ... empirically, yes.  I guess "always available" means "you could import it if you wanted to".
May 03 20:12:49 <khem> sgw: yes
May 03 20:16:24 <sgw> khem: you recently filed some bugs and looks like providing patches for some of them, wanted to understand which ones you are addressing (or all of them?)
May 03 20:17:16 <khem> not all
May 03 20:17:28 <khem> some of them I have patches for
May 03 20:17:59 <khem> 2 patchsets I have not posted yet are mips64 support and arm hardfp
May 03 20:18:15 <khem> they are in my misc tree though if someone want to look at them
May 03 20:18:23 <khem> others are posted
May 03 20:19:43 <sgw> Ok, I will assign those bugs back to you then, you are putting the [YOCTO #xxxx] tag in your commit messages correct?
May 03 20:23:43 <khem> sgw: no I havent put yocto bug numbers in them
May 03 20:24:35 <sgw> khem in the future, could you add that tag in the commit message
May 03 20:31:46 <khem> ok
May 03 20:41:37 * jwessel is spelunking in the uihelper.py
May 03 20:41:51 <jwessel> Is there any way to find out the logfile name that a task is using?
May 03 21:01:47 <khem> zedd_: around ?
May 03 21:04:38 <jwessel> khem: zedd_ will be returning home from Sweden, you can probably reach him via e-mail.
May 03 21:06:33 <khem> jwessel: ah ok thx
May 03 21:06:41 <khem> I got some weirdness in kernel
May 03 21:07:05 <khem> its probably trying to probe my SSD while its running on qemy
May 03 21:07:08 <khem> qemu
May 03 21:07:13 <jwessel> I know plenty about kernels, but not so much about how they are built in bitbake :-)
May 03 21:07:14 <khem> dont know for sure
May 03 21:07:24 <khem> heh
May 03 21:08:04 <khem> jwessel: ok then I can pick your brains a bit
May 03 21:09:14 <jwessel> Generally speaking if I am using x86, I'd be using kvm to launch the simulation.  It is much faster.
May 03 21:09:29 <jwessel> Someone added the ability for it to work with the runqemu as well.
May 03 21:10:55 <khem> I am emulating mips64
May 03 21:11:10 <khem> yes x86 its not brainer to use kvm
May 03 21:11:12 <jwessel> Ah, likely good old 5kf
May 03 21:11:27 <jwessel> At least the simulation runs faster than the 5mhz FPGA.
May 03 21:11:35 <khem> yes :)
May 03 21:11:46 <khem> it says 100MHz
May 03 21:11:54 <khem> 20 times right there
May 03 21:12:23 <khem> kernel somehow things that qemu has a MTD and probes it and then goes into tail chasing
May 03 21:12:29 <khem> with unimplemented commands
May 03 21:12:38 <khem> so I guess I should first try to disable MTD
May 03 21:12:52 <jwessel> That was my first question, if you turned it off in the .config
May 03 21:13:16 <jwessel> It should be more or less the same .config as the 32 bit variant because the base board is the same.
May 03 21:13:38 <jwessel> They both use the Malta base board with the GT PCI controller.
May 03 21:13:39 <khem> on 32bit it does not detect the Intel/Sharp flash
May 03 21:13:47 <khem> initial probe fails therefore it works
May 03 21:14:20 <jwessel> Well it is looking for a magic value in there as well as the fact there is a memory map.
May 03 21:14:30 <khem> hmm
May 03 21:14:37 <khem> seems so
May 03 21:14:50 <jwessel> Could either be a bug in the kernel or something that is not implemented in the simulation.
May 03 21:15:05 <jwessel> I do have a working image for MIPS64 but not a 3.4 kernel.
May 03 21:15:08 <khem> btw. anybody knows if I dont zap the password whats the default root password for our images ?
May 03 21:15:28 <khem> yeah its a 3.4 kernel
May 03 21:15:38 <khem> let me try to disable mtd for now
May 03 21:15:57 <jwessel> I figured you were working with the master branch, because zedd_ mentioned you were cranking away on MIPS64 stuff.
May 03 21:17:03 <dvhart> zedd_, how we doing on the meta and sys940x mac merges?
May 03 21:17:29 <khem> CONFIG_MTD_CFI=y
May 03 21:17:44 <khem> may be I should disable that first before I disable whole MTD
May 03 21:18:08 <khem> jwessel: yes I have a userspace
May 03 21:18:18 <khem> now kernel is almost there
May 03 21:27:28 <khem> jwessel: ah so disabling CONFIG_MTD_CFI did the trick now its panic on next which is  perf related
May 03 21:27:46 <jwessel> You can probably just turn off perf.
May 03 21:28:36 <khem> jwessel: http://pastebin.com/nP3QsBXb
May 03 21:28:41 <khem> yeah prolly
May 03 21:29:41 <jwessel> The simulated machine doesn't have those regs.
May 03 21:29:43 <jwessel> oprofile: using mips/20K performance monitoring.
May 03 21:29:54 <jwessel> Looks like you got killed by user space activating oprofile.
May 03 21:30:17 <jwessel> No that was the oprofile configuration in the kernel.
May 03 21:30:27 <jwessel> khem: Turn off oprofile :-)
May 03 21:30:39 <khem> yeah
May 03 21:30:50 <khem> does oprofile work on mips64 btw.
May 03 21:31:26 <jwessel> Sure.  It works on qemu as well.
May 03 21:31:33 <jwessel> But on the 3.4 kernel.
May 03 21:31:47 <jwessel> You can tell oprofile not to use performance counters and it would still work.
May 03 21:31:48 <khem> CONFIG_OPROFILE and CONFIG_HAVE_OPROFILE is turned off lets see now
May 03 21:32:03 <jwessel> In fact you could probably boot that particular kernel if you pass oprofile args.
May 03 21:32:04 <dvhart> khem, hey, I reviewed an old kmod patch set - apologies. I just read the latest, my comments are the same though.
May 03 21:32:51 <jwessel> khem the kernel arg is: oprofile.timer=1
May 03 21:33:26 <khem> jwessel: I am shoehorning it into default options we have first
May 03 21:34:03 <khem> dvhart: OK thanks did you post them as followup to the patches
May 03 21:34:29 <dvhart> yes
May 03 21:34:39 <khem> thanks
May 03 21:34:44 <dvhart> the feb version unfortunately :/
May 03 21:34:57 <dvhart> they look good, thanks for doing it!
May 03 21:35:25 <khem> dvhart: hmmm yes busybox needs to disable
May 03 21:35:31 <khem> actually we could make it a virtual
May 03 21:35:42 <khem> jwessel: yay
May 03 21:35:46 <khem> it booted
May 03 21:35:48 <jwessel> :-)
May 03 21:35:55 <khem> right into the userspace
May 03 21:36:19 <jwessel> You can probably turn oprofile back on and just for it into timer mode, instead of performance registers.
May 03 21:36:34 <jwessel> They are not entirely implemented in the QEMU on all the chips.
May 03 21:36:36 <khem> http://pastebin.com/Fm2c3tQP
May 03 21:37:14 <khem> you mean add oprofile.timer=1 to KERNEL_CMDLINE
May 03 21:37:27 <jwessel> khem: Yes, until it is fixed, if you want to use oprofile.
May 03 21:37:36 <jwessel> If that doesn't work either, there is a different problem.
May 03 21:38:54 <khem> jwessel: ok. I dont think I need oprofile for now
May 03 21:39:12 <khem> jwessel: I need qemu with ssh so I can now run gcc/eglibc tests :)
May 03 21:44:08 <khem> root@qemumips64:~# file /lib/libc-2.15.so
May 03 21:44:10 <khem> /lib/libc-2.15.so: ELF 64-bit MSB shared object, MIPS, MIPS64 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, with unknown capability 0x410000000f676e75 = 0x1000000070401, stripped
May 03 21:44:36 <khem> so its really N64
May 03 22:00:17 <khem> jwessel: Kernel command line: root=/dev/nfs console=ttyS0 console=tty nfsroot=192.168.7.1:/tmp/xxx/,nfsvers=2,mountprog=21111,nfsprog=11111,udp,port=3049,mountport=3048 rw ip=192.168.7.2::192.168.7.1:255.255.255.0 mem=128M oprofile.timer=1  console=ttyS0
May 03 22:00:42 <khem> it still crashed
May 03 22:01:12 <jwessel> That probably means there is a problem with oprofile for the 3.4 kernel.
May 03 22:01:58 <jwessel> I did check the older vintage kernels and they work fine without the oprofile.timer=1, and the CFI MTD enabled.
May 03 22:02:10 <jwessel> At some point some bisecting of the kernel tree will be in order.
May 03 22:02:40 <jwessel> Somewhere between 2.6.34 and 3.4 it stopped working.
May 03 22:03:42 <khem> jwessel: ok
May 03 22:04:11 <jwessel> For now, I would just turn it off and file a defect to track it.
May 03 22:04:17 <khem> I will look upto you and zedd_ to do that and I will look into the userspace
May 03 22:04:34 <khem> yeah thats what I am going to do
May 03 22:04:46 <khem> first let me create a stop gap patch to meta
May 03 22:05:01 <jwessel> khem: Yup, eventually zedd_ will send it my way, and he or I will end up bisecting it, and once we see the cause it will either be a fix in QEMU or the kernel.
May 03 22:05:21 <khem> sure.
May 03 22:05:44 <khem> If I get some free cycles I will look into it too bbut since I know its in safe hands I will not worry
May 03 22:08:50 <ant__> khem: so, what did you suggest about the 3.2 headers in /kernel/arch/arm/include/generated/asm
May 03 22:09:06 <ant__> is it safe to create the symlink?
May 03 22:10:19 <RP> kergoth: when you did the original codeparser stuff, you had some tests that went with it. Any idea where that code is?
May 03 22:11:59 <RP> kergoth: no matter, as soon as I asked, I found the right search phrase :)
May 03 22:12:02 <RP> (https://github.com/kergoth/OE-Signatures)
May 04 00:01:10 <kergoth> hmm, depexp is really weak on the runtime dep stuff
**** ENDING LOGGING AT Fri May 04 02:59:59 2012

**** BEGIN LOGGING AT Fri May 04 02:59:59 2012
May 04 07:05:28 <karw> how can i make a build for i486? can i treat it as x86? if so, if i set MACHINE to "x86" in config will it work?
May 04 07:12:37 <karw> how can i make a build for i486? can i treat it as x86? if so, if i set MACHINE to "x86" in config will it work?
May 04 07:21:44 <karw> how can i make a build for i486? can i treat it as x86? if so, if i set MACHINE to "x86" in config will it work?
May 04 07:27:39 <mckoan> good morning
May 04 07:28:27 <mckoan> karw: IHMO should be the same, the important thing is kernel settings
May 04 08:15:23 <karw> how can i make a build for i486? can i treat it as x86? if so, if i set MACHINE to "x86" in config will it work?
May 04 08:16:49 <JaMa> karw: check openembedded-core/meta/conf/machine/include/tune-i586.inc and create tune-i486.inc and use it in your machine config
May 04 08:17:38 <JaMa> and don't repeat your question every few minutes, it's annoying
May 04 08:26:36 <B4gder> and it is much better if you go ahead and try it out and then ask when you face problems
May 04 08:27:37 <karw> sorry, had to restart and didnt see any reply
May 04 12:04:06 <rburton> how can i force a package to rebuild?
May 04 12:04:23 <rburton> without bumping the pr that is
May 04 12:07:20 <JaMa> -c cleansstate
May 04 12:18:19 <rburton> ah
May 04 12:18:28 <rburton> how does that differ from -c clean
May 04 12:18:30 <rburton> and why
May 04 12:22:37 <rburton> as much as its a pain, the license checksum magic is rather clever
May 04 12:48:53 <RP> kergoth: ping?
May 04 12:55:02 <bluelightning> otavio: ping
May 04 13:01:25 <RP> kergoth: I'm wondering if you're ok with http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t2&id=41d6d98f12b6b1dab607eb27866215dac8475ce6 (I borrowed some test cases from your code)
May 04 14:04:37 <kergoth> RP: I'm fine with that. as an aside, i'd suggest also adding at least two 'file:' uris to the fetch test, as the way we handle file uris differs from the way others do (e.g. what urlparse does)
May 04 14:05:26 <RP> kergoth: totally agreed, this is really just a start pulling together a few different pieces
May 04 14:05:49 <RP> kergoth: its going to take time to get the coverage improved but its areas like that we need to focus on
May 04 14:06:20 * kergoth nods
May 04 14:06:23 <kergoth> it's a good start
May 04 14:06:29 <kergoth> i like that you dug up the cow tests, that's helpful
May 04 14:07:07 <RP> kergoth: There are more things in the history too, I put the url in the commit so we could perhaps see what else might still be relevant
May 04 14:07:18 <RP> kergoth: The first thing this has highlighted is: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t2&id=ad7d7b5ee4a379a6e8a9c4ef0ae22580a2abaf02
May 04 14:07:40 <RP> kergoth: I'm all in favour of ripping out that particularly nasty piece of code...
May 04 14:08:48 <RP> kergoth: I think it may be a portage remnant?
May 04 14:09:01 <RP> kergoth: the nice thing was the cow tests ran without any changes :)
May 04 14:09:25 <RP> kergoth: There are a couple of commented out python expansion tests we should probably look at as they're failing
May 04 14:09:44 <kergoth> interesting
May 04 14:10:56 <hwinkel> Hello
May 04 14:21:56 <bluelightning> otavio: ping
May 04 14:30:47 <RP> hi hwinkel
May 04 14:40:31 <khem> qemu has 128M ram and tcf-agent is taking 86M
May 04 14:41:11 <kergoth> ouch
May 04 14:41:13 <khem> this should be investigated because default for some qemu machines is 64M
May 04 14:41:38 <khem> Ican delete it because I dont use eclipse
May 04 14:41:49 <khem> but for eclipse you need it I think
May 04 15:04:07 <RP> khem: that does seem like a lot :/
May 04 15:05:48 <kergoth> holy hell can self-hosted-image do_rootfs take a long time :)
May 04 15:05:50 * kergoth taps foot
May 04 16:05:33 <kergoth> my genext2fs has been going for an hour.
May 04 16:10:56 <hwinkel> Hi, anybody know the Yocto Build environment can be used to build packages for classic distributions (Ubuntu, HR etc.) as well ?
May 04 16:17:41 <seebs> I... wouldn't really want to try.  It might be possible if a target happened to be similar enough, but I can't imagine it being more convenient than the native build methods.
May 04 16:21:59 <sgw> kergoth: yes, its generating a 40G image, takes a really long time!
May 04 16:22:07 <kergoth> ah :)
May 04 16:22:39 <sgw> kergoth: the resulting vmdk is only about 3-4G depending on the size of your DL_DIR
May 04 16:23:25 <sgw> That also accounts for some time copying the DL_DIR in.
May 04 16:33:14 <kergoth> cool, thanks for the info
May 04 16:39:16 <RP> kergoth: trying to write a unit test of a simple http:// fetch makes me want to cry :(
May 04 16:40:19 <RP> kergoth: OVERRIDES unset = backtrace, PATH unset results in running PATH="None" tar, no default FETCHCMD, harcoded WORKDIR reference in unpack. Its painful
May 04 16:59:17 <khem> RP: yeah but I have to check it on a 32bit image too. This is mips64 image so I am not totally sure. I was looking into why gcc tests are taking so long to execute on target and then saw this
May 04 16:59:45 <RP> khem: Its work mentioning it to jessica
May 04 16:59:50 <RP> er, worth
May 04 16:59:56 <khem> I will check it again when I boot a normal qemu  in 32 bit
May 04 17:00:06 <khem> yeah once I can confirm it I will file a bug :)
May 04 17:00:16 <khem> that seems to be a good way of tracking
May 04 17:00:44 <khem> for now I will wait till tests are finished
May 04 18:19:35 <seebs> Anyone have feedback on the variable/include tracking stuff I should consider before I start sending pull requests?
May 04 18:32:41 <khem> seebs: I havent had a chance to look at the latest patchset yet
May 04 18:33:04 <seebs> Also looking for feedback on the toolchain stuff, as I'd like to get that in tree so I feel like I'm Doing Something.  :)
May 04 18:36:12 <sgw> seebs: I have it pending in "mut" for a Consolidated pull over the weekend.
May 04 18:36:18 <seebs> k
May 04 18:36:25 <sgw> mut is "Master Under Test"
May 04 18:37:33 <kergoth> 3.5 hour genext2fs and counting. yikes.
May 04 18:38:13 <sgw> kergoth: hmm, mine normally takes about 2
May 04 18:42:54 <kergoth> it's a VM, but a 12 core VM. maybe the i/o perforamnce isn't good enough, though?
May 04 18:42:55 * kergoth shrugs
May 04 18:44:37 <sgw> kergoth: yeah that might be it io bound for sure
May 04 18:44:43 * sgw swims
May 04 19:11:47 <jwessel> 2 hours for genext2fs ?
May 04 20:52:30 <sgw> kergoth: finished yet?
May 04 21:01:29 <mranostay> how big of a ext2 images takes 2 hours?
May 04 21:01:33 <mranostay> *image
May 04 21:08:29 <kergoth> nope, I think something may be wrong here :)
May 04 21:09:05 <kergoth> genext2fs process has been running for 6 hours. thankfully it's not the only box i'm using, so figured i'd wait it out, but this is crazy :)
May 04 21:25:31 <mranostay> kergoth: how big is the output so far?
May 05 00:14:12 <khem> sgw: around ?
May 05 00:15:18 <sgw> khem yeah, trying to wrap this pull up
May 05 00:15:26 <khem> heh
May 05 00:15:31 <khem> ok
May 05 00:15:37 <sgw> khem: what's up?
May 05 00:15:38 <khem> i have three branches
May 05 00:15:42 <khem> out there
May 05 00:15:47 <khem> which ones are you working on
May 05 00:16:07 <khem> kraj/kmod  kraj/misc-upsated and kraj/qemu-xserver
May 05 00:16:11 <sgw> misc-updates (without the parallel make),
May 05 00:16:20 <sgw> removed kmod until you get that fixed
May 05 00:16:49 <khem> i fixed it
May 05 00:17:00 <khem> sent email already
May 05 00:17:01 <sgw> qemu-xserver is in right now, I know there was some comment about the =??,
May 05 00:17:18 <khem> yeah d=?? does not work for reason
May 05 00:17:38 <khem> but I think kmod and misc-updates are ok I have addressed your comments
May 05 00:17:57 <sgw> Ok, let's leave that for now, I will pull the xserver and see if Richard still balks.
May 05 00:18:22 <khem> I did not add my sign-off to openssl patch since i did not write it i only updated it
May 05 00:18:32 <khem> added the upstream-status back though
May 05 00:18:51 <sgw> Ok thanks
May 05 00:18:53 <khem> time to go for kids school function now ttyl
May 05 00:19:05 <sgw> sure thing have fun
**** ENDING LOGGING AT Sat May 05 03:00:01 2012

**** BEGIN LOGGING AT Sat May 05 03:00:02 2012
May 05 04:59:30 <JaMa> khem: I've tried that armv4t+gold issue now with latest oe-core and it's still there
May 05 05:23:36 <khem> JaMa: OK
May 05 08:11:25 <hwinkel> good morning
May 05 15:45:05 <khem> pwd
May 05 16:08:56 <Crofton|work> /home/kraj
May 05 19:43:44 <khem> Crofton|work: indeed heh
May 05 19:44:01 <khem> Crofton|work: that my son's right click result
**** ENDING LOGGING AT Sun May 06 03:00:01 2012

**** BEGIN LOGGING AT Sun May 06 03:00:02 2012
May 06 18:51:04 <xxiao> while runnig hob, i could no longer launch 'runqemu qeumx86', after i killed hob, it runs, odd
May 06 20:01:47 <ag> Hello everybody!
May 06 20:02:14 <ag> Does anybody know anything about core-image-sato-dev on qemuppc?
May 06 20:02:53 <ag> I can't make it boot.
May 06 20:03:11 <ag> It stays at yocto logo screen....
May 06 20:11:43 <xxiao> ag: qemux86 works fine here, have not tried qemuppc
May 06 20:11:59 <ag> qemuppc not working as i see...
May 06 20:12:15 <ag> And i'm trying to reproduce a bug on qemuppc.... dammit.
**** ENDING LOGGING AT Mon May 07 02:59:59 2012

**** BEGIN LOGGING AT Mon May 07 02:59:59 2012
May 07 07:31:09 <mckoan> good morning
May 07 08:26:05 <yanus> test
May 07 13:22:01 <eFfeM_work> hi, does anyone by any chance have a link to some text describing how to best update a (non-applying) (kernel) patch? (I'm not really a guilt wiz)
May 07 13:36:27 <denisATeukrea> I often do it manually
May 07 13:36:39 <denisATeukrea> I force the application of the patch
May 07 13:36:43 <denisATeukrea> and merge the rejects
May 07 13:36:46 <denisATeukrea> using git
May 07 14:09:20 <eballetbo> hi all, I've a problem fetching my custom kernel from my git, yocto stops  with following message
May 07 14:09:26 <eballetbo> NOTE: package linux-igep-2.6.37-r4: task do_fetch: Started
May 07 14:10:20 <eballetbo> The log shows that the last command is a git clone --bare
May 07 14:10:31 <denisATeukrea> yes the clone may take a very long time
May 07 14:10:38 <denisATeukrea> because a kernel git is usually huge
May 07 14:10:56 <B4gder> usally? you mean there are times it isn't? B)
May 07 14:11:11 <eballetbo> the clone never finishes
May 07 14:11:47 <eballetbo> If I do the same command in a terminal it works but not doing a bitbake linux-igep
May 07 14:13:42 <eballetbo> http://pastebin.com/niPFLVrD
May 07 14:13:56 <eballetbo> I'm using denzil branch
May 07 14:18:28 <eballetbo> Any ideas why the fetch is blocked ?
May 07 14:34:21 <eFfeM_work> denisATeukrea: thanks for your reply, (was afk) with oe classic I always used quilt and found that quite convenient
May 07 14:34:29 <eFfeM_work> will ask the list
May 07 15:10:03 <ddompe> hi
May 07 15:10:08 <ddompe> I have a quick question
May 07 15:10:31 <ddompe> does yocto uses systemd for booting, or what other boot system uses?
May 07 15:21:19 <bluelightning> ddompe: out of the box, we use standard sysvinit
May 07 15:21:51 <ddompe> bluelightning: anyone knows about existing efforts to use systemd?
May 07 15:22:00 <ddompe> or if is on the plan?
May 07 15:22:26 <bluelightning> ddompe: there are people using systemd with angstrom, which is somewhat related to yocto
May 07 15:36:30 <zenlinux> RP, what's the status of the denzil-next branch on the main oe-core repo? Were you planning on maintaining that or deleting it until denzil-next is finalized?
May 07 15:37:57 <ddompe> bluelightning: thanks for the info
May 07 15:42:26 <RP> zenlinux: I will probably end up removing it
May 07 15:43:01 <zenlinux> k
May 07 15:48:07 <RP> zenlinux: btw, don't worry about rebasing. I wouldn't consider things final until they hit master
May 07 15:48:25 <RP> zenlinux: anything -next has a convention of being able to change
May 07 15:48:37 <zenlinux> well, that would make things more convenient
May 07 15:48:56 <RP> s/master/main branch/
May 07 16:13:22 <xxiao> while runnig hob, i could no longer launch 'runqemu qeumx86', after i killed hob, it runs, why is that
May 07 17:45:15 <mranostay> so is there a module or recipe example on creating a u-boot multi-image with a kernel + rootfs + dtb?
May 07 22:36:17 <halstead> The yocto project built stack is needs to be rebooted for updates.
May 07 22:36:38 <halstead> We will start in 15 minutes.
May 07 22:39:25 <incandescant> hmm, runqemu scripts failing under bash for me
May 07 22:39:29 <incandescant> anyone else seeing this?
May 07 22:39:37 * incandescant has low bash fu
May 07 22:40:18 <incandescant> seems to be in findimage()
May 07 22:54:33 <zenlinux> incandescant, the runqemu script was just updated to be non-bash specific, did something break for bash users?
May 07 22:54:45 <zenlinux> findimage was indeed recently modified :(
May 07 22:54:50 <incandescant> zenlinux: I just tried Dash and it's broken there too
May 07 22:55:00 <zenlinux> drat
May 07 22:55:26 <incandescant> I get line "305: [: too many arguments" in bash and "303: [: too many arguments" in dash
May 07 22:55:34 <incandescant> shall I file a bug?
May 07 22:56:50 <zenlinux> incandescant, could you find out which patch broke it? The changes were split up into six patches
May 07 22:57:42 <zenlinux> or if you send me a trigger case, I'll dig into it
May 07 22:57:55 <seebs> That sounds like it might be a bug in the bash-to-dash conversion.
May 07 23:00:35 <incandescant> the trigger is just to call findimage, I'm lazy so just use 'runqemu qemux86' and boom
May 07 23:00:52 <incandescant> it looks like it's http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=e99f652ede4612eec7cef5fa16638b07519cba8e
May 07 23:01:12 <incandescant> the Ubuntu Dash page tells me that switching from || to -o was the wrong move
May 07 23:01:25 <incandescant> but that's an aside, it's not that exclusively which breaks things
May 07 23:01:59 <incandescant> or is it...
May 07 23:03:53 <seebs> That could easily do it.
May 07 23:04:31 <seebs> I don't have a copy of my book handy to look it up, but I seem to recall that the conventional answer is that it is safer to [ condition ] || [ condition ] than to try to get -o working.  :P
May 07 23:04:57 <incandescant> yeah, that's what the dash page says
May 07 23:05:29 <incandescant> but if I change the -o \\ to || I then get "[: =~: binary operator expected"
May 07 23:05:45 <incandescant> and this is why I have no sh fu, because it's a pain
May 07 23:06:06 <seebs> The thing is.  You have to do [ x = y ] || [ z = w ], not [ x = y || z = w ]
May 07 23:06:13 <seebs> Note that you need extra ]..[ around the ||
May 07 23:06:30 <incandescant> yeah, I put those in
May 07 23:11:06 <seebs> Paste the line?  I am pretty good at shell, and a single line shouldn't destroy the channel.
May 07 23:12:40 <incandescant> if [ "$name" =~ core-image-sato-sdk ] || [  "$name" =~ core-image-sato ] || [ "$name" =~ core-image-lsb ] || [  "$name" =~ core-image-basic ] || [ "$name" =~ core-image-minimal ] ; then
May 07 23:12:57 <incandescant> I don't know the =~ operator
May 07 23:13:02 <incandescant> and Google isn't too useful yet
May 07 23:15:48 <incandescant> of course I can guess what it's doing...
May 07 23:16:19 <incandescant> the only way I can seem to get it to work is to change it to what we had before with [[ ]] around the whole thing, but that isn't supported in dash afaict
May 07 23:16:43 <seebs> ew
May 07 23:17:06 <seebs> Well, I'm guessing the problem there is that =~ is a bashism itself.
May 07 23:17:25 <incandescant> oh, maybe
May 07 23:17:26 <incandescant> heh
May 07 23:18:09 <kergoth> isn't =~ the bash regex match operator? don't often use tha tone
May 07 23:18:14 <seebs> Yeah, =~ is a regex ... yes
May 07 23:18:30 <seebs> I am not...sure.
May 07 23:18:39 <seebs> Okay, is the intent to match any name containing any of those?
May 07 23:18:59 <kergoth> I'd use echo | grep -q
May 07 23:19:01 <seebs> Because as a bashism, that'd accept values like godzilla-core-image-minimal-firingsquad
May 07 23:19:05 <seebs> I'd use case.
May 07 23:19:09 <seebs> case $name in
May 07 23:19:18 <seebs> core-image-minimal | core-image-lsb | ... )
May 07 23:19:30 <seebs> And if the intent is to match anything containing them, asterisks are cheap.
May 07 23:19:47 <seebs> Or possibly something fancy, like
May 07 23:19:58 <seebs> case ${name#core-image-} in
May 07 23:20:06 <seebs> sato-sdk | sato | lsb | basic | minimal )
May 07 23:20:21 <seebs> <-- has a love/hate relationship with the shell
May 07 23:26:02 * incandescant has only hate for scripting in sh
May 07 23:27:20 <incandescant> the current pattern matches /path/to/my/tmp/dir/core-image-minimal-*
May 07 23:28:34 <incandescant> so I don't think we can use case ?
May 07 23:34:25 <zenlinux> I'm starting to wonder whether making the script shell-agnostic was a good idea
May 07 23:34:43 <zenlinux> =~ does a lot for readability
May 07 23:35:09 <incandescant> it sure does, but having some scripts shell agnostic and others not is likely to be painful for users
May 07 23:35:53 <zenlinux> The build system needs to be shell-agnostic. The support scripts I'm not so sure.
May 07 23:38:24 <zenlinux> I'm going to reply to that pull request thread and start a discussion on this.
May 07 23:41:20 <seebs> Well, is the intent really to be pattern-matching?  What is an example name that we want to match that contains, but isn't, core-image-minimal?
May 07 23:44:47 <zenlinux> seebs, I'm not sure, but I think hob appends additional strings to the default image names
May 07 23:45:21 <zenlinux> incandescant, you may know this
May 07 23:45:27 <zenlinux> or is it prepend?
May 07 23:45:34 <incandescant> I don't know what hob does there tbh
May 07 23:47:20 <incandescant> the filenames variable already includes a bunch of paths that match a defined regex which includes the machine name and extension
May 07 23:47:55 <seebs> I'd tend to think of =~ as overkill for pattern matching, shell's rich with pattern matching.
May 07 23:48:30 <incandescant> the commit log certainly indicates that change was made for hob
May 07 23:50:42 <incandescant> zenlinux: it looks like that consideration may no longer be required
May 07 23:50:49 <incandescant> http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=fdb2027e6de6291486b36913d69ff49b769e2bb6
May 07 23:51:57 <zenlinux> incandescant, interesting
May 07 23:52:39 <zenlinux> I guess the bottom line is I'd like to get some feedback from the group's more senior members about how to fix this.
May 07 23:53:10 <zenlinux> The script worked fine before and I acked the refactoring under the assumption there were no downsides
May 07 23:58:14 <incandescant> you're saying you don't care what I think? ;-)
May 07 23:58:35 <zenlinux> incandescant, oh, I do. I also really appreciate that you dug into this
May 07 23:58:46 <incandescant> I don't think we need to rush out a fix, seems there aren't many folks who've run into this and it's easy enough to work around
May 07 23:59:04 <zenlinux> incandescant, there I definitely disagree. the runqemu script is fundamental to all of our testing
May 07 23:59:10 <zenlinux> builds are going to start failing immediately
May 07 23:59:25 <incandescant> really? I didn't realise we relied on findimage?
May 07 23:59:53 <incandescant> by workaround I'm using runqemu qemux86 core-image-minimal, instead of runqemu qemux86
May 08 00:00:00 <zenlinux> sorry, I'm being dragged out to something outside
May 08 00:00:10 <incandescant> np, I need to pedal home anyways
May 08 00:01:16 * incandescant does so
May 08 00:32:38 <halstead> autobuilder main sites are back online.
**** ENDING LOGGING AT Tue May 08 03:00:01 2012

**** BEGIN LOGGING AT Tue May 08 03:00:02 2012
May 08 07:05:46 <mckoan> good morning
May 08 08:44:51 <likewise> good morning all
May 08 08:47:29 <bluelightning> morning likewise, all
May 08 08:52:08 <mckoan> hi
May 08 14:31:29 <halstead> Good morning pidge.
May 08 14:32:23 <halstead> I have the master up and listening to it's own. I'm working on getting more builders.
May 08 14:47:44 <pidge> halstead: cool. I'm having problems getting into it.
May 08 15:14:11 <fray> HAHAHA..
May 08 15:14:26 <fray> wonder if there is a way to mute everyone
May 08 15:14:49 <fray> sounds like telecom italia.. ;)
May 08 15:14:56 <zeddii> someone is dialing in from the jungle.
May 08 15:16:38 <fray> BTW I built the self-hosted-sdk.. it took -hours- to build the filesystem.. is this unique to my environment, or has anyone else noticed this?
May 08 15:19:46 <Guest30910> fray: i let it run overnight and it never finished
May 08 15:20:09 <sgw> fray it's building a 40G filesystem and copying your downloads (2-4G) into it
May 08 15:20:20 <sgw> fray: yes it can take a couple of hours
May 08 15:21:22 <fray> sgw, ok..  I was really surprised.. it took my machine somewhere around 4-6 hours.. (maybe longer.. I finally gave up and went to bed after 4 hours of waiting)
May 08 15:21:29 <fray> it was done this morning though.. ;)
May 08 15:21:45 <sgw> Guest30910: what kind of hardware?
May 08 15:22:49 * fray was on an 8 core (16 w/ HT) 2.8Ghz Xeon X5560 system, but the drives are base SATA.. nothing special
May 08 15:25:12 <Guest30910> sgw: 4 core Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz w/ht
May 08 15:25:43 <fray> Guest30910 sounds similar to my config, as far as the disk creation goes..
May 08 15:26:30 <sgw> I have a similar machine to Guest30910
May 08 15:27:06 <sgw> I found that I could get it done in 2-4 hours
May 08 15:33:53 <halstead> pidge, http://autobuilder.yoctoproject.org:8010/buildslaves
May 08 16:27:36 <dvhart> Guest30910, zeddii : https://bugzilla.yoctoproject.org/buglist.cgi?list_id=5224&emailtype1=regexp&query_format=advanced&emailassigned_to1=1&bug_status=NEW&bug_status=ACCEPTED&bug_status=REOPENED&bug_status=NEEDINFO&bug_status=WaitForUpstream&email1=%28zanussi|dvhart|ashfield%29
May 08 17:39:31 <sgw> khem: ping
May 08 17:39:52 <khem> sgw: yes
May 08 17:40:29 <sgw> khem: with the xorg work you are doing have you looked at the update to 1.12.1
May 08 17:40:32 <sgw> ?
May 08 17:40:52 <khem> sgw: no
May 08 17:41:16 <sgw> Ok, just wondering so I don't duplicate any work someone else is doing.
May 08 17:41:16 <khem> sgw: I have been not looking at update but cherry picking fixes that needs the current platforms going
May 08 17:41:23 <khem> sure
May 08 17:41:56 <sgw> I will compare your patches vs what's in 1.12.1 maybe we can do that in 1 swoop
May 08 17:42:58 <khem> yes that will be nice
May 08 17:45:41 <JaMa> khem: can you please reply on that kmod patchset/late review?
May 08 17:45:57 <khem> JaMa: link?
May 08 17:46:36 <JaMa> http://lists.linuxtogo.org/pipermail/openembedded-core/2012-May/022096.html
May 08 17:47:02 <JaMa> and following 2 patches in same thread
May 08 17:47:58 <JaMa> also on oe-devel http://lists.linuxtogo.org/pipermail/openembedded-devel/2012-May/039424.html
May 08 17:49:58 <khem> JaMa: that needs a bit more since by default install happens into /usr/lib
May 08 17:50:10 <khem> let me see
May 08 17:50:25 <khem> there was another thing wrt to CONFLICS you mentioned
May 08 18:00:07 <sgw> zenlinux: are you going to look at fixing the runqemu issues that you and incandescant found?
May 08 18:02:05 <zenlinux> sgw, yes, I'm waiting to hear some feedback from the community on how to approach the fix
May 08 18:02:34 <zenlinux> RP, did you have any thoughts on whether removing bashisms from the runqemu scripts are worthwhile?
May 08 18:02:37 <sgw> Ok got it.
May 08 18:02:59 <sgw> zenlinux: Just need to get that fixed fairly quickly!
May 08 18:03:01 <zenlinux> sgw, we're not seeing autobuilder failures because of it, are we?
May 08 18:03:17 <fray> (not speaking for RP).. if the script says /bin/bash, I don't mind it having bash-isms...  but it absolutely can not say /bin/sh...
May 08 18:03:19 <sgw> zenlinux: not sure yet, we need ab up and running with latest master.
May 08 18:03:45 <zenlinux> I'm thinking the sanity tests are run using explicit paths to the rootfs/kernel images
May 08 18:03:58 <zenlinux> if so, I think that avoids triggering the problem
May 08 18:04:29 <sgw> yes, I think they might be.
May 08 18:04:55 <khem> JaMa: can you try http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/misc&id=8992b4142931e7e55e9fa319b176425e923e44f5 ?
May 08 18:05:20 <khem> JaMa: btw. I am not able to reproduce the gold issue on qemu/armv4t at all
May 08 18:05:39 <khem> JaMa: the bash binaries you have worked fine too
May 08 18:05:54 <khem> I guess it must be some hardware feature that qemu is not emulating propertly
May 08 18:07:18 <JaMa> khem: have you seen http://lists.linuxtogo.org/pipermail/openembedded-core/2012-May/022105.html ?
May 08 18:07:56 <khem> ah thats better
May 08 18:07:58 <khem> yes
May 08 18:08:09 <khem> can you merge the changes I just did in patch
May 08 18:08:14 <khem> and post a v2 ?
May 08 18:08:31 <JaMa> not now
May 08 18:09:09 <khem> thats fine
May 08 18:09:24 <JaMa> and that libdir change doesn't belong to this patch v2
May 08 18:09:33 <khem> yeah nm
May 08 18:09:44 <khem> I will make it a separate patch
May 08 18:09:45 <JaMa> so maybe you can send it as reply to http://lists.linuxtogo.org/pipermail/openembedded-core/2012-May/022104.html if that really fixes the issue
May 08 18:10:16 <JaMa> but it was in your previous version of kmod recipe so I guess you had some reason to comment it out in next revision you sent to oe-core ML...
May 08 18:11:42 <JaMa> and wrt gold issue, I can give you ssh access to freerunner with gold built chroot installed if that helps
May 08 18:11:53 <khem> JaMa: there were install problems with kmod into /lib and now they are fixed
May 08 18:11:56 <khem> it seems
May 08 18:12:20 <khem> JaMa: ok I can take a look
May 08 18:12:44 <khem> JaMa: also send me instruction on how to reproduce it
May 08 18:12:59 <khem> I might have forgotten
May 08 18:15:28 <JaMa> khem: http://pastebin.ca/2145760
May 08 18:17:23 <khem> ok. Can you build and boot kernel with user_debug=-1 please ?
May 08 18:17:43 <khem> so I can see what address and what opcode patterns are being reported
May 08 18:18:41 <khem> ah another way is chroot using busybox and then run bash under gdb
May 08 18:18:48 <JaMa> ok tomorrow.. I've removed that builddir today.. so need to build from scratch
May 08 18:19:08 <khem> ok when you build add debug info to the image too
May 08 18:19:49 <khem> EXTRA_IMAGE_FEATURES = "dbg-pkgs dev-pkgs debug-tweaks tools-debug"
May 08 18:46:49 <JaMa> khem: just to be sure.. that opcode is IIRC not in bash binary but in libtinfo or something like that (and IIRC I had bash working after replacing libtinfo with version built by bfd) but also it's not libtinfo only.. e.g. opkg got SIGILLs from other libs etc..
May 08 18:51:30 <JaMa> khem: and that kernel param should be just user_debug=1 without '-' right?
May 08 18:56:47 <khem> JaMa: that should be -1 its a mask
May 08 18:57:06 <khem> JaMa: yes linker problems can happen in many places
May 08 18:57:12 <khem> so no worries there
May 08 18:57:20 <khem> we can debug 1 instance
May 08 19:02:57 <JaMa> ok I wanted to be sure you had rebuilt whole image with gold not just bash when trying to reproduce it
May 08 19:35:02 <JaMa> khem: [  195.930000] bash (435): undefined instruction: pc=0007d70c
May 08 19:35:02 <JaMa> [  195.930000] Code: bc10fec5 4708bc02 1c05b538 2200434d (21001c28)
May 08 19:45:08 <eFfeM> khem, it looks like the uclibc patch works, but haven't tested the image yet (had some kernel issue that needed resolving first)
May 08 19:56:42 <JaMa> khem: newer log (cooker + do_compile) for that gcc race issue http://build.shr-project.org/tests/jama/gcc-issue/gcc-race-new/
May 08 22:00:34 <sgw> halstead: ping
May 08 22:05:02 <halstead> sgw, pong.
May 08 22:08:00 <sgw> halstead: I am looking at the 1.3 Features with uses the wikimeda/bugzilla stuff and I am not seeing updates to status such as Resolved when I know that issue is resolved and when I click the link I get the resolved bug.
May 08 22:08:07 <sgw> halstead: is there a cache?
May 08 22:08:24 <halstead> sgw, Yes there is a cache.
May 08 22:08:39 <halstead> sgw, You can add a single space and click minor edit to force a refresh.
May 08 22:09:05 <sgw> how long does it cache for or just edit to edit?
May 08 22:09:16 <halstead> sgw,  I can remove the cache if it is an issue.
May 08 22:09:37 <halstead> sgw, I'll check the expiry right now.
May 08 22:09:53 <sgw> Let me know what the expiry is and maybe we can reduce it
May 08 22:12:16 <halstead> sgw, It's using the mediawiki cache layer which by default waits for an edit to clear.
May 08 22:13:11 <halstead> I'll disable caching for now. If anyone notices performance problems I'll take another look.
May 08 22:13:39 <sgw> halstead: Ok, I know we are doing alot of queries right now.
May 08 22:14:24 <halstead> I bet the server has spare capacity enough. We'll see.
May 08 22:20:36 <seebs> kergoth (or any other toolchain folks):  Is it intended that glibc must provide rpc.h?
May 08 22:20:54 <fray> khem would be the right person to ask...
May 08 22:20:58 <seebs> I ask because we have a prebuilt that doesn't seem to include it, and busybox fails, and I am not sure whether this is a configuration/recipe thing or a toolchain thing.
May 08 22:20:59 <kergoth> seebs: recent versions of glibc no longer support them
May 08 22:21:09 <kergoth> those headers are obsolete, and apps sould be altered to use libtirpc
May 08 22:21:17 <kergoth> we've been bitten by this with an external toolchain also
May 08 22:21:30 <khem> I happen to sign in
May 08 22:21:32 <seebs> I would guess you have, since you're probably doing the same external toolchain I am.  :)
May 08 22:21:35 <kergoth> i have a link i got from the sourcery folks somewhere around here to the thread on the libc lists
May 08 22:21:57 <khem> we are reintroducing sunrpc into glibc
May 08 22:22:08 <kergoth> ah, really?
May 08 22:22:10 <khem> and in OE-Core I have reverted the original patch for 2.15
May 08 22:22:12 <seebs> I suppose the question is whether I should be setting some flag or variable or something to cause busybox to use libtirpc instead of failing because glibc doesn't have it.
May 08 22:22:16 <fray> then busybox and others need libtiprc requirements or sunrpc is needed in the glibc?
May 08 22:22:22 <khem> so in 2.16 sunrpc will be back
May 08 22:22:31 <fray> khme this is OE specific or in glibc itself?
May 08 22:22:39 <khem> since tirpc is not complete replacement and its felt that its not there yet
May 08 22:22:45 <khem> fray: glibc itself
May 08 22:22:51 <kergoth> yeah, i tried converting linuxquota to libtirpc and got nowhere fast
May 08 22:22:53 <kergoth> due to missing bits
May 08 22:22:58 <khem> yep
May 08 22:23:02 <seebs> I guess I can ask the toolchain vendor to backport that, then.
May 08 22:23:17 <khem> so for near future expect sunrpc to be provided by glibc/eglibc
May 08 22:23:29 <khem> once tirpc matures then it may go away
May 08 22:24:05 <khem> seebs: yes. all distros are carrying patches to disable or somehow workaround sunrpc removal
May 08 22:24:18 <khem> and glibc community feels its was a bit premature to delete it
May 08 22:24:22 <seebs> k
May 08 22:24:25 <seebs> thanks!
May 08 22:24:30 <khem> np
May 08 22:24:57 <kergoth> yeah, thanks, we have a task to deal with that mess before our next release, heh
May 08 22:26:11 <khem> its still being discussed though Its almost certain it will be reintroduced only thing being left is a way to put it back so it can  easily be punted out when time comes
May 08 22:26:15 <seebs> Well, good news, kergoth, it'll be showing up in CS's inbox as an "enhancement request".  :)
May 08 22:26:25 <sgw> khem, your right looks like the xorg.conf did not get installed correctly, I am checking the meta-yocto layer to see if it does anything
May 08 22:26:49 <khem> sgw: ok, yeah let me glance over meta-yocto quickly
May 08 22:28:02 <sgw> khem it seems to package it correctly, just not installed!
May 08 22:28:24 <khem> hmmm met-yocto only have xserver-xf86-config_0.1.bbappend
May 08 22:29:20 <khem> sgw: actually take this patch too http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/misc&id=955dee621361e01627ebfde152f25873070cf301
May 08 22:29:34 <khem> its strange why its not being put into image
May 08 22:29:54 <khem> since I have kdrive completely removed
May 08 22:30:24 <khem> although I dont see any relation to the problem
May 08 22:53:17 <sgw> khem: It appears to be a line in task-core-x11.bb:  XSERVER ?= "xserver-kdrive-fbdev" that may have overridden your XSERVER setting
May 08 23:33:15 <sgw> khem commenting out that line worked
May 08 23:59:48 <khem> sgw: ah
May 09 00:00:00 <khem> sgw: hmm I think that line should go away I think
May 09 00:00:29 <khem> that also explains the problem I was having with ??=
May 09 00:11:57 <sgw> khem: Ok, please send a fully updated patch set, I am guessing it would be Ok to remove kdrive, but it might warrant a seperate email not sure about other layers.
May 09 00:12:46 <khem> yes for now I am going to not touch those bits
May 09 00:13:10 <sgw> khem: OK
May 09 00:13:11 <khem> I am going to change ??= to ?= and change the order of inclusion of qemu.inc for x86 and x86_64
May 09 00:13:23 <khem> that will mean I dont have to toch anything else
May 09 00:20:06 <khem> sgw: I have updated the pull tree
May 09 00:20:13 <sgw> Please send email
May 09 00:20:15 <khem> sgw: now it should work better
May 09 00:20:20 <sgw> Thanks
May 09 00:20:22 <khem> with v2 ?
May 09 00:20:30 <sgw> v2 or v3?
May 09 00:20:33 <khem> ok
May 09 00:20:42 <khem> let me send it just now
May 09 00:22:08 <sgw> halstead: pidge: you still around?  What gives with the sanity failures across the board, are the machines setup for vnc correctly?
May 09 00:23:30 <sgw> khem, there might also be an issue with multiple providers for kmod, have you seen that issue?
May 09 00:24:07 <sgw> khem: check the notes at the top of this build: http://autobuilder.yoctoproject.org:8010/builders/nightly/builds/444/steps/shell_14/logs/stdio
May 09 00:24:07 <halstead> sgw, ab04, ab05, and ab06 having been changed yet.
May 09 00:24:08 <pidge> sgw: next on my plate.
May 09 00:24:41 <sgw> pidge: let me know if I can fire a MUT when you are done (or fire one for me, please)
May 09 00:25:14 <sgw> I just love these 11+ hour days!
May 09 00:25:27 <pidge> sgw: gotcha will do.
May 09 00:27:53 <halstead> pidge, Can I swap in the new storage before you start the next build?
May 09 00:28:30 <pidge> halstead: sure.
May 09 00:28:47 <khem> sgw: new pull request for qemu stuff is out
May 09 00:28:49 <pidge> halstead: did the ips change on the abs?
May 09 00:29:01 <halstead> Only on the master.
May 09 00:29:08 <khem> sgw: there is pull request for kmod which I think should fix the multiple provider issue too
May 09 00:29:12 <sgw> khem thanks will work on those bits again tomorrow, trying to get the other stuff tested for a C-pull
May 09 00:29:20 <pidge> hrmm. very odd then.
May 09 00:29:29 <sgw> khem: great thanks, have not reviewed them yet.
May 09 00:29:30 <khem> sgw: ok
May 09 00:29:33 <halstead> 10.0.10.101 became 10.0.10.111 internally.
May 09 00:29:52 <khem> sgw: ok no problem
May 09 00:30:27 <khem> let me know if anything is needed on those two
May 09 00:30:46 <sgw> khem: tomorrow, unless RP gets there first!
May 09 00:32:00 <halstead> pidge, It looks like nfs dropped on ab01. Important?
May 09 00:32:18 <khem> sgw: ok
May 09 00:32:21 <pidge> yes
May 09 00:33:30 <halstead> pidge, fixing that now.
May 09 00:34:29 <pidge> halstead: ping me when the swap is done. I've restarted the vncs. Once the swap is done I can run a mut
May 09 00:35:17 <halstead> pidge, Okay. It's syncing at 90mb/s should be done soon fairly quicklty.
May 09 00:44:48 <halstead> pidge, Would you like to meet at the office to get ab 3,7,8 and 9 reconnect together?
May 09 00:49:01 <pidge> halstead: I'm going to pop in real quick tomorrow morning and get them up before I head out of town for a day. I can get them hoocked up on my own, I think. If not, I'll ping you.
May 09 00:49:43 <sgw> pidge your going away tommorrow!
May 09 00:50:24 <halstead> pidge, If you know when you're planning to arrive I can meet you and make sure the process goes as smoothly as possible.
May 09 00:52:02 <pidge> sgw: if you can wait until thursday, I can skip it until then?
May 09 01:40:28 <kergoth> what the hell
May 09 01:40:29 <kergoth> ERROR: No eligible RPROVIDERs exist for 'kernel-base'
May 09 01:40:29 <kergoth> NOTE: Runtime target 'kernel-base' is unbuildable, removing...
May 09 01:40:30 <kergoth> Missing or unbuildable dependency chain was: ['kernel-base']
May 09 01:41:01 <kergoth> hrm
May 09 01:41:07 * kergoth digs into various layers to find the cause
May 09 02:00:31 <pidge> halstead: downloads.yp.org is down
May 09 02:01:18 <halstead> ack
May 09 02:03:41 <halstead> pidge, Thanks. I cause a stale NFS file handle.
May 09 02:03:46 <halstead> Fixed now..
May 09 02:22:44 <pidge> halstead: can I start a mut now?
May 09 02:23:28 * pidge runs one to find out.
May 09 02:23:34 <halstead> One sec.
May 09 02:23:39 <halstead> I need to cancel out of this..
May 09 02:28:11 <halstead> pidge, Okay you should be set.
May 09 02:34:22 <halstead> pidge, NFS was read only until 19:28. If that's bad you may need to restart.
May 09 02:35:29 <halstead> pidge, It needs to be restarted I think. (http://autobuilder.yoctoproject.org:8010/builders/nightly/builds/445/steps/shell_14/logs/stdio)  OSError: [Errno 13] Permission denied: '/srv/www/vhosts'
**** ENDING LOGGING AT Wed May 09 02:59:58 2012

**** BEGIN LOGGING AT Wed May 09 02:59:59 2012
May 09 06:26:37 <halstead> Looks like the MUT build is no longer dying early.
May 09 06:26:45 * halstead sleeps.
May 09 07:05:44 <mckoan> good morning
May 09 08:52:24 <ag> Anybody around?
May 09 08:58:07 <bluelightning> hi all
May 09 08:58:09 <bluelightning> ag: yep
May 09 08:58:35 <ag> bluelightning: Is there any way i can add a task to all recipes without inherit?
May 09 08:59:21 <ag> bluelightning: A default task after xxxx for all recipes.
May 09 08:59:43 <bluelightning> I don't think so, no...
May 09 09:00:24 <ag> bluelightning: I need to generate a list of packages on final fs with some info (srcuri, license etc etc)
May 09 09:00:49 <JaMa> ag: why not inherit (like e.g. rm_work does)?
May 09 09:00:51 <bluelightning> ag: buildhistory.bbclass does this already
May 09 09:01:01 <ag> thanks
May 09 09:01:08 <ag> this is what i was looking for
May 09 09:01:15 <ag> Grateful :)
May 09 09:02:45 <ag> bluelightning: Last one: how is this class inherited / used?
May 09 09:07:50 <bluelightning> ag: https://wiki.yoctoproject.org/wiki/Buildhistory
May 09 09:18:30 <ag> bluelightning: 10x
May 09 09:51:39 <eballetbo> Hi all, I need some help from yocto gurus. My recipe tries to git clone from one repository any idea how can I debug the fetch function. -DDD don't show useful information. Thanks in advance
May 09 10:00:36 <bluelightning> eballetbo: have you had a look at the log.do_fetch?
May 09 10:10:04 <eballetbo> yes,  http://pastebin.com/5jzMZyh1
May 09 10:10:20 <eballetbo> seems is cloning but never finishes
May 09 10:16:21 <eballetbo> how can I see the output of the git clone command ?
May 09 10:16:44 <eballetbo> Any debug flag or something similar ?
May 09 10:24:11 <ag> eballetbo: Where is the error?
May 09 10:24:51 <ag> i tried to clone it i works...
May 09 10:25:11 <ag> But this should take a while....
May 09 10:28:38 <eballetbo> the problem is yocto is blocked at this step, if I try to clone this repository from a console works but if I try doing a bitbake myrecipe doesn't work
May 09 10:29:02 <ag> hmmm...
May 09 10:29:14 <ag> give me your recipe
May 09 10:29:22 <ag> dropbox link?
May 09 10:31:17 <eballetbo> is very simple
May 09 10:31:20 <eballetbo> http://pastebin.com/86H99pTA
May 09 10:34:37 <ag> eballetbo: What version is this?
May 09 10:35:58 <eballetbo> I'm using denzil
May 09 10:36:11 <ag> What version is this kernel.
May 09 10:36:18 <ag> You use PV in tag.
May 09 10:36:38 <eballetbo> no KV = 2.6.37-2
May 09 10:36:51 <ag> yes
May 09 10:36:59 <ag> and kv is created from pv
May 09 10:36:59 <ag> ok
May 09 10:41:19 <ag> now we wait...
May 09 10:53:36 <ag> It works in my recipe.
May 09 10:53:57 <ag> eballetbo: It took a while... but ended successfully.
May 09 10:54:11 <ag> But i used srcrev.
May 09 10:54:16 <ag> I will try with tag as well
May 09 10:58:33 <bluelightning> eballetbo: are you using a proxy at all?
May 09 10:58:53 <eballetbo> no
May 09 11:04:00 <eballetbo> It's possible to log the output of the bb.process.run command ?
May 09 11:09:26 <ag> eballetbo: Just finished your recipe. It works ok.
May 09 11:09:41 <ag> Maybe you are behind a proxy or something.
May 09 11:10:46 <eballetbo> arghhh, many thanks to check ag
May 09 11:11:08 <eballetbo> maybe a problem with my network
May 09 11:12:30 <ag> eballetbo: No problem. SUre is your local network problem.
May 09 15:58:54 <dirthead> It's not clear to me how to make use of the poky-tiny.conf to create an image that boots in less than 4MB of ram. Can anybody provide suggestions on how to make use of it?
May 09 16:01:24 <RP__1> dirthead: set DISTRO="poky-tiny" and you will get settings that have lower profile on things like memory and disk
May 09 16:02:06 <dvhart> dirthead, if you want to boot on a particular platform, you will likely need to adjust the kernel config as well
May 09 16:02:17 <dvhart> dirthead, it is a very minimal config
May 09 16:02:31 <dvhart> dirthead, consider it a starting point
May 09 16:03:09 * dvhart bumps tiny documentation up a couple notches...
May 09 16:05:01 <chackal_sjc> guys.. what should I do when I'm getting errors?
May 09 16:05:03 <chackal_sjc> Summary: There were 3 ERROR messages shown, returning a non-zero exit code.
May 09 16:05:06 <chackal_sjc> like this one
May 09 16:05:11 <zenlinux_> RP__, do you think this is a good candidate for 1.2.1? http://git.openembedded.org/openembedded-core/commit/?id=8a0edae0b1aa94f73445070659d1640d97cbf1cb
May 09 16:05:27 <dvhart> chackal_sjc, scroll up or review the cooker log, and see what the ERRORs are
May 09 16:05:37 <RP__> zenlinux_: yes
May 09 16:05:45 <zenlinux_> ok, grabbing that commit
May 09 16:06:05 <chackal_sjc> dvhart: where is this cooker log?
May 09 16:06:23 <dvhart> chackal_sjc, in tmp, find tmp -name "cooker*log"
May 09 16:06:42 <chackal_sjc> ok
May 09 16:50:43 <eFfeM> bluelightning: if you and/or jim have time now, fine with me (or in 10 or 15 mins whatever you prefer)
May 09 17:21:46 <msm> zenlinux: do you recall how you determined (if it was  you) that docbook was using an OASIS license?
May 09 17:23:11 <zenlinux> msm, let me look something up
May 09 17:24:00 <msm> seems like it could be GNU Free Doc license
May 09 17:24:13 <msm> I've just started looking at this though it though
May 09 17:26:22 <msm> http://docbook.org/tdg/en/html/aph.html
May 09 17:26:26 <zenlinux> msm, looks like I originally pulled docbook-utils from oe classic
May 09 17:27:06 <zenlinux> msm, which docbook recipe are you referring to - the stylesheets?
May 09 17:27:13 <zenlinux> docbook-utils is GPLv2
May 09 17:28:00 <msm> docbook-sgml-dtd-3.1-native.bb
May 09 17:30:04 <zenlinux> msm, it's been too long, I'm not sure how I determined this
May 09 17:33:06 <zenlinux> I'd probably check to see what license a distro like debian uses for their dtd packages
May 09 17:35:04 <msm> is there a web page for this?
May 09 17:40:11 <msm> it's not immediately obvious what package would be equivalent on packages.debian.org
May 09 18:19:18 <Jefro> I just came back to a 1.2 build tree and find that I can't do anything.  [Errno 13] Permission denied: .../layer.conf.  I sourced oe-init-build-env, what am I doing wrong?
May 09 18:29:52 <Jefro> never mind, I was doing something silly.  I added  a udev-mounted disk to /etc/fstab, and forgot that I had previously run bitbake on the udev-mounted partition.
May 09 18:38:30 <eFfeM> heh, thought those things only happened to me ;-)
May 09 18:39:18 <Jefro> eFfeM not a chance. Using Linux on a daily basis reminds me frequently of how poor a sysadmin I was in about 1988 (and haven't improved)
May 09 18:40:02 <eFfeM> fortunately i never was a sysadmin (apart from my own system), i think I'd be bad at it too
May 09 18:41:00 <Jefro> I was mostly limited to being a backup bot (this was long before network backups - we had QIC drives on each machine), and babysitting printers
May 09 19:05:36 <seebs> I am a world-class bad sysadmin.
May 09 19:05:59 <seebs> There is something horrifically dangerous about someone who is actually *comfortable* programming shell, and with severe ADHD, looking at a # prompt.
May 09 19:06:20 <seebs> About the only mistake I haven't made is assuming that, since the line starts with a #, the shell will ignore it.  :)
May 09 19:11:32 <seebs> Oooh, hey.  I found a hole in sanity.bbclass; it checks for "." in PATH, but not for empty strings.
May 09 19:11:44 <seebs> Note that PATH=:/bin is equivalent to PATH=.:/bin
May 09 19:14:52 <RP__> seebs: fun. We did have systems which commonly injected "."
May 09 19:15:02 <RP__> seebs: wreaked havoc :(
May 09 19:15:22 <seebs> I'ma send out a two-line diff for that in case anyone cares.
May 09 19:16:26 <RP__> seebs: I'm not ignoring your patches btw, I'm just out of bandwidth and have to prioritise some other things atm :(
May 09 19:16:27 * fray was a little surprised he didn't see any feedback on the blacklist patch.. I figured my changes would be controversial....
May 09 19:17:03 <seebs> No worries.  I'm pretty sure we'll be testing them some internally, because we have a lot of people suddenly ramping up on bitbake, and these patches Help.  :)
May 09 19:19:26 <RP__> fray: Its only had about 4 hours
May 09 19:19:50 <fray> ha
May 09 19:45:26 <JaMa> RP: hi, just pushed kmod patch was supperseeded by this one http://patchwork.openembedded.org/patch/27317/ but having both won't hurt so no big issue
May 09 19:45:54 <RP> JaMa: right, I had the other in the queue and just realised too :/
May 09 19:46:04 <RP> JaMa: I'll merge the others, then we can sort this out...
May 09 19:46:42 <JaMa> it doesn't hurt so I vote for keeping both
May 09 19:55:12 <RP> halstead: Was some fix made to the autobuilder qemu sanity testing to fix it for the last build?
May 09 19:58:46 <halstead> RP, pidge recreated the tap devices and I fixed stale nfs locks.
May 09 19:59:19 <RP> halstead: ok, great. I just wanted to check that was why the were failing and not some change in master!
May 09 19:59:20 <RP> thanks
May 09 19:59:32 <halstead> As well as fixed permissions on the nas export.
May 09 19:59:41 <halstead> I don't think any other changes were made.
May 09 20:00:17 <JaMa> RP: do you have more patches in queue? because one from kmod patchset is missing now
May 09 20:02:15 <RP> JaMa: getting there, its in
May 09 20:02:46 <JaMa> thz
May 09 20:02:46 <JaMa> x
May 09 20:03:21 <halstead> pidge, Are the MUT builds usually core-image-sato, core-image-minimal or ...?
May 09 20:31:42 <sgw> halstead: yes, MUT uses the same as master for image creation
May 09 20:32:11 <sgw> halstead: do you know what's wrong with the sanity test setup?  We need to get that fixed
May 09 20:32:27 <halstead> sgw, So that would be core-image-sato?
May 09 20:33:26 <halstead> sgw, Recreating the tap devices was the last fix.
May 09 20:33:47 <sgw> halstead: Ok so that was done this morning?
May 09 20:34:21 <sgw> halstead: core-image-sato is one of the images, it builds core-image-sato-dev, sato-sdk, ...
May 09 20:34:25 <halstead> sgw, I did it on ab05 and ab06 right before I started the current build.
May 09 20:34:37 <halstead> Ah so it does all of them.
May 09 20:34:54 <sgw> yes, but sanity tests minimal or sato only
May 09 21:10:36 <seebs> So, would anyone *like* a per-recipe sanity check pass added, possibly optional?  Seems like it might be really useful for package maintainers, although we might want it off by default.
May 09 21:12:37 <kergoth`> seebs: ages ago i added a 'recipe_sanity' class which was opt-in to identify common mistakes in recipes. as one example, if you define FOO_recipename instead of FOO_${PN} when both are defined, it'll identify the former being overwritten by the latter
May 09 21:12:50 <kergoth`> but i think that sort of thing is different than waht you're proposing
May 09 21:15:54 <seebs> d'oh
May 09 21:16:20 <seebs> So, about 20-25 years ago, I got sick of not being able to see file details.  And I wrote a utility named stat which was a wrapper around stat(2).
May 09 21:16:24 * kergoth` ponders
May 09 21:16:31 <seebs> Guess what just broke quilt.  :P
May 09 21:16:39 <seebs> I really, really, have to get around to renaming that.
May 09 21:17:42 <seebs> So, hmm.  My initial thought was that the test against BB_WORKERCONTEXT in sanity.bbclass might distinguish between top-level config parsing and package config parsing, but it appears it is not so.
May 09 21:22:25 <kergoth`> gah, i'mg etting task failures with exit code 0 again :|
May 09 21:22:45 <bluelightning> kergoth`: any more details?
May 09 21:23:06 <kergoth`> i can't find any rhyme or reason to it, seems to happen at random
May 09 21:23:21 <seebs> Well, the good news is, there is definitely actually an error.  The bad news is, the one we know about is in the error reporting.  :P
May 09 21:23:39 <kergoth`> heheh
May 09 21:26:19 <fray> kergoth` I don't know if it would help... but I've got some local patches rearranging the way the logic messages and such are generated..
May 09 21:26:35 <fray> it at least gave me more insight into the order things ran...
May 09 21:27:33 <khem> fray: are these bitbake logger patches  ?
May 09 21:27:49 <khem> or to oe metadata
May 09 21:27:52 <fray> kind of?  they're exec_task and exec_func_<type> patches to change where the logging is
May 09 21:28:37 <fray> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=mhatle/bitbake/order&id=e95b654d3e9710ab4b6dd5437021fe22555c319c
May 09 21:28:57 <fray> this is -very- preliminary work.. but if you want to play, feel free and give me feedback.. does it make it easier or harder to debug..
May 09 21:29:10 <fray> I'm also not printing any func error or return info into the logs..
May 09 21:29:33 <fray> but with this I was capable of seeing more clearly the order that tasks w/in a recipe and the functions within a task were executed
May 09 21:30:36 <fray> [mhatle@msp-mhatle-lx2 zlib-1.2.7-r0]$ cd temp/
May 09 21:30:36 <fray> [mhatle@msp-mhatle-lx2 temp]$ ls
May 09 21:30:36 <fray> do_fetch  do_populate_lic  log.do_fetch  log.do_populate_lic  log.task_order
May 09 21:30:36 <fray> do_patch  do_unpack        log.do_patch  log.do_unpack
May 09 21:30:45 <fray> the steps for each task are in a subdirectory..
May 09 21:30:52 <fray> the log.<task> is a link to the last task log..
May 09 21:30:59 <fray> log.task_order shows the order of the tasks
May 09 21:31:38 <kergoth`> wonder why we aren't using os.WEXITSTATUS() in the runqueue
May 09 21:31:40 <kergoth`> will do
May 09 21:34:34 <seebs> I am trying to understand the parse/cache relationship.
May 09 21:35:29 <seebs> It *looks* to me as though the point at which a given package's data have reached completion is the end of CoreRecipeInfo.add_cacheData().
May 09 21:35:47 <seebs> So if you wanted to sanity-check a package, that would be the place to trigger.  I think.
May 09 21:36:14 <kergoth`> we have events and event handlers for a reason
May 09 21:37:02 <seebs> Well, so far as I can tell (???) there is not currently an event happening at the point "I have fully parsed the config for recipe foo, but not yet done anything with it".
May 09 21:38:19 <seebs> So I was thinking it might be neat to add one, but then I'd want to figure out where to fire it.
May 09 21:39:01 <kergoth`> hm?
May 09 21:39:15 <kergoth`> what do you think 'RecipePreFinalise' and 'RecipeParsed' are, if not after parsing but before task execution?
May 09 21:39:38 <seebs> ...Ah-HAH!
May 09 21:40:01 <seebs> See, I was thinking I was missing something, but I couldn't figure out what.  Answer:  I was grepping in lib/bb, not lib/bb/parse.  :)
May 09 21:40:39 <kergoth`> you grep without -r? seems pointless to me. better yet, use ack
May 09 21:40:50 <kergoth`> heh
May 09 21:41:04 <seebs> I am not familiar with ack.  And yeah, I tend to not use -r, because I do not have sufficiently fast hardware.  :P
May 09 21:41:12 <incandescant> git grep ftw !
May 09 21:41:18 <seebs> oooh
May 09 21:41:22 <kergoth`> http://betterthangrep.com/
May 09 21:41:30 <kergoth`> git grep is handy indeed, performs well
May 09 21:41:32 <CcSsNET> i think he ment awk not ack
May 09 21:41:36 <kergoth`> no
May 09 21:41:36 <seebs> Yeah, very cool.
May 09 21:41:49 <kergoth`> awk and ack are entirely different tools with entirely different purposes
May 09 21:41:55 <CcSsNET> ah
May 09 21:42:17 <seebs> Every programming language has its purpose.
May 09 21:42:33 <seebs> awk's purpose is making people who thought they were working on a shell script cry.
May 09 21:43:09 * kergoth` chuckles
May 09 21:43:16 <CcSsNET> seebs. exactly
May 09 21:43:25 <seebs> ... You know, the funny thing is.  I am pretty sure the reason I don't use grep -r isn't really the performance, it's that it didn't have a -r when I learned it.  :P
May 09 21:43:50 <seebs> d'oh
May 09 21:43:58 <kergoth`> have you seen the code for z, autojump, or v?
May 09 21:44:07 <seebs> "apt-get install ack", says me.  That will give me a utility, says me.  "ack - Kanji code converter"
May 09 21:44:10 <seebs> I have not.
May 09 21:44:18 <kergoth`> https://github.com/rupa/z/blob/master/z.sh
May 09 21:44:30 <kergoth`> seebs: apt-get install ack-grep; alias ack=ack-grep
May 09 21:44:34 <kergoth`> ubuntu folk are silly
May 09 21:44:40 <kergoth`> the distro developers, that is
May 09 21:45:13 <seebs> I once had the privilege of encountering someone who said that Ubuntu was irrelevant, because they did not understand marketing.
May 09 21:45:29 <seebs> See, had they been wise, they would have renamed debian helper to something else that would promote their brand.
May 09 21:46:53 <seebs> Okay, that ack thing?  That is probably one of the best programming tips I've gotten in ages.
May 09 21:47:28 <CcSsNET> seebs++ for debian helper comment
May 09 21:47:59 <seebs> It was awesome.  This guy showed up in comp.lang.c promoting a thoroughly mediocre fork() wrapper which he called "daemon helper", and named "dh".
May 09 21:48:16 <seebs> When people pointed out that the name "dh" was in use, he dismissed Debian users as a bunch of unimportant whiners and said no one used Debian.
May 09 21:48:22 <kergoth`> haha
May 09 21:48:26 <kergoth`> yikes
May 09 21:48:26 <CcSsNET> heh
May 09 21:48:43 <CcSsNET> debian is for learning
May 09 21:48:46 <CcSsNET> imho
May 09 21:48:48 <kergoth`> seebs: https://bitbucket.org/kergoth/dotfiles/src/b1516144f080/ackrc
May 09 21:49:02 <seebs> BSD/OS had one of those named daemon which actually WAS useful, this guy's was full of clever ideas like "invent your own wildly new format and store it as foo.pid".
May 09 21:49:25 <kergoth`> bleh
May 09 21:50:28 <seebs> Thanks for the tip, wouldn't have figured out for ages why it wasn't noticing bitbake files.  :P
May 09 21:50:56 <kergoth`> hehe. yeah, by default it only searches known file types. another useful tip: ack -a makes it search all files
May 09 21:51:04 <kergoth`> quite handy if you care about random files in a layer like 'interfaces'
May 09 21:53:05 <kergoth`> hmm, i think i may see how the 'exited with 0' failures can occur
May 09 22:17:25 <khem> someone should update the channel topic to highlight 1.2 release
May 09 22:17:28 <bluelightning> kergoth`: what did you find?
May 09 22:18:40 <kergoth`> bluelightning: if status is not zero, we call task_fail, but only pass one byte of the status field (the exit code portion). if a process exits via a signal rather than _exit(), i could imagine a case where the status is nonzero but the exit code portion is zero.
May 09 22:18:54 <kergoth`> i'm theorizing here, but it would make sense
May 09 22:20:08 <bluelightning> ah, yes... hmm
May 09 22:21:16 <kergoth`> i expect we should pass the full status to task_fail and let the UI show it, potentially enhancing the ui later to explain how it exited
May 09 22:24:43 <kergoth`> regardless, there's a clear case where what happened isn't whats being shown to the user, that mismatch has to be addressed one way or another :)
May 09 22:24:53 * kergoth` tests this and waits to see if he encounters this random case again
May 09 22:28:10 <seebs> Pretty sure signals show up in exit code as 128+N.
May 09 22:28:23 <seebs> So the exit status should still be non-zero.
May 09 22:29:46 <kergoth`> well, i can't think of anything else that would make any sense. clearly it's calling task_fail even when the exit code is 0, and the only case i can imagine given the code is a case where the exit code is zero but the remainder of the status isn't
May 09 22:29:52 <kergoth`> maybe i'm just missing it
May 09 22:30:27 <khem> why is just 1 byte passed and not the whole value ?
May 09 22:30:47 <seebs> Well, because that's all there is.  Sort of.
May 09 22:30:58 <seebs> WEXITSTATUS() is low-order-8-bits-only.
May 09 22:30:59 <kergoth`> our events expect an exit code, and thats waht we pass
May 09 22:31:04 <seebs> Wait.
May 09 22:31:05 <kergoth`> but there's more to the exit than the exit code
May 09 22:31:07 <kergoth`> afaict anyway
May 09 22:31:09 <seebs> Hang on.
May 09 22:31:16 <seebs> What *exactly* are we passing the bottom byte of?
May 09 22:31:30 <seebs> I just realized I was thinking in terms of shell status codes.
May 09 22:31:37 <kergoth`> os.waitpid() returns process id and status
May 09 22:31:41 <kergoth`> see the man page for wait or waitpid
May 09 22:31:54 <seebs> The status it returns has a format which is, I believe, a System Internal Not To Look At.
May 09 22:32:27 <seebs> You are supposed to use WEXITSTATUS(), etcetera.
May 09 22:32:39 <kergoth`> right, tahts a minor concern, we aren't using that, we're manually shifting
May 09 22:32:42 <seebs> And WEXITSTATUS(status) yields the low-order 8 bits of the exit status passed to exit() or whatever.
May 09 22:32:54 <seebs> But they are not the low-order 8 bits of the process status.
May 09 22:33:16 <seebs> Bits 8-15 are the exit status, bit 7 is the coredump flag, bits 1-7 are the terminating signal (if any).
May 09 22:33:54 <seebs> So you're quite right; if we're just passing the status bits, then we would indeed report 0 for terminated-by-signal at least sometimes.
May 09 22:33:56 <kergoth`> right, we choose task_fail vs task_completed based on the full exit status as passed to exit, but then we drop the other bits and only pass the exit status to task_fail, losing information
May 09 22:33:58 * kergoth` nods
May 09 22:34:34 <seebs> So, yeah, your diagnosis is right.  Also, the idiom of getting 128+N for signals?  That's shell magic, not the underlying status returns.
May 09 22:34:41 <kergoth`> another option would be to distinguish between types of failure in the runqueue rather than passing the full thing and letting the UI interpret it
May 09 22:34:45 <kergoth`> ah
May 09 22:34:49 <khem> I think we should stop mucking
May 09 22:34:59 <kergoth`> i figured that might be the case, so the exit code could well be zero in the signal case
May 09 22:35:02 <khem> and use WEXITSTATUS
May 09 22:35:37 <khem> exit code can be 0 if a exception is thrown which is handled successfully
May 09 22:35:47 <seebs> Well, you still have to check WIFEXITED, too.
May 09 22:36:01 <seebs> Because otherwise, kill -9 can yield WEXITSTATUS of 0.
May 09 22:36:44 <kergoth`> we could always use the shell idiom, encode the signal into the exit code and pass *that* to task_fail
May 09 22:36:51 <kergoth`> that'd be something the user might recognize
May 09 22:36:58 <seebs> Interestingly, at least on Linux, apparently WIFEXITED(status) == !(WTERMSIG(status))
May 09 22:37:01 <kergoth`> otherwise we can have the UI call WIFEXITED & friends
May 09 22:37:46 * kergoth` thinks
May 09 22:38:07 <seebs> Note that you *can* return values which are in the 128+SIGFOO range.
May 09 22:42:19 <chackal_sjc> how can I compile for armv7 with yocto
May 09 22:44:35 <kergoth`> fray: out of curiosity, why the seemingly extraneous change from 'function' to 'func'?
May 09 22:51:51 <RP> kergoth`: any thoughts on BB_STAMP_POLICY = "full" ?
May 09 22:52:10 <RP> kergoth`: something we should keep or has the need for it become obsolete?
May 09 22:57:15 <RP> We should use os.WEXITSTATUS() and friends in runqueue
May 09 22:59:03 <kergoth`> does https://github.com/kergoth/bitbake/commit/5f89e60 look sane?
May 09 23:00:07 <kergoth`> reads a bit more cleanly using named variables instead of result[N] also, heh
May 09 23:00:32 <kergoth`> RP: I doubt there's much need for BB_STAMP_POLICY = "full" anymore, but i'd have to look more closely and refresh my memory, will take a look
May 09 23:01:43 <RP> kergoth`: basically its the switch between stopping at filename changes when checking timestamp consistency and doing it completely recursively. I just noticed we also have a totally dead function in there (check_stamps())
May 09 23:02:07 <kergoth`> ah, hmm
May 09 23:02:58 <RP> kergoth`: I think I have a fix for the performance issue Rich Pixley found, its just a question of whether we want to support it going forwards...
May 09 23:03:22 <RP> Looking at the code, its not a massive maintenance headache with check_stamps() removed I guess
May 09 23:24:19 <seebs> kergoth:  I would suggest, just as defensive programming, commenting the 128+N computation.
May 09 23:24:52 <seebs> It's a non-obvious convention if you don't habitually keep $? in your shell prompt.  :P
May 09 23:24:58 <kergoth`> hehe, fair enough
May 09 23:25:20 <seebs> I really, really, like replacing result[0] and result[1] with pid and status, though.
May 09 23:27:26 <khem> chackal_sjc: choose the right machine e.g. beagleboard
May 09 23:27:57 <chackal_sjc> khem: where can I find a list of machines?
May 09 23:55:13 <khem> chackal_sjc: look under meta-yocto/conf/machine
May 10 00:04:41 <kergoth`> anyone gotten bitten recently by the SUMMARY/DESCRIPTION self reference bug?
May 10 00:05:12 <kergoth`> i'm honestly amazed we aren't bitten by it all the time. package_ipk applies a pkgname override, so SUMMARY_<pkg> replaces SUMMARY, yet it references the un-suffixed SUMMARY..
May 10 00:05:42 <kergoth`> either it should avoid the override and use explicit getvars of the suffixed vars, or the per-package summary vars shouldn't reference the un-suffixed version
May 10 00:05:46 <kergoth`> (same for DESCRIPTION)
May 10 00:06:19 <kergoth`> i have a local workaround that forces an early expansion of SUMMARY_<pkg> and DESCRIPTION_<pkg> before the override is applied in package_ipk.bbclass
May 10 00:08:59 <sgw> is Marko in this chat?
May 10 00:13:31 <kergoth`> ugh, archiver.bbclass could really use some cleanup
May 10 00:14:15 <kergoth`> usability could be improved also
May 10 00:14:51 <kergoth`> and there's no copyleft-like license-based archival (yet)
May 10 00:16:23 <kergoth`> has variables that control its behavior but no default values for those variables..
May 10 00:16:51 <kergoth`> also, the archiver bbclass is of limited usefulness by itself, maybe it should be a .inc or something, to avoid confusion
May 10 00:17:47 <kergoth`> hardcoded reference to workdir/temp rather than using T..
May 10 00:18:44 <kergoth`> typo - do_remove_taball[deptask] = "do_archive_scripts_logs"
May 10 00:19:09 <kergoth`> completely unnecessary and useless 'export get_package', i think the author didn't understand what 'export' does
May 10 00:19:17 * kergoth` mutters and hacks a bit
May 10 00:20:12 <kergoth`> looks like that shouldn't be using deptask at all, as far as i can see
May 10 00:21:11 <seebs> I haven't been bitten by it, but I probably will now.  :P
May 10 00:21:35 <kergoth`> heh, i hate when something seems like it should never have worked, but was
May 10 00:21:53 <kergoth`> always worries me a little, given there's an obvious mismatch between mental model and reality :)
May 10 00:22:07 <kergoth`> which is the usual cause of debugging difficulties
May 10 00:23:01 <kergoth`> ugh, archiver.bbclass basically reimplements variable typing / choices for SOURCE_ARCHIVE_PACKAGE_TYPE
May 10 00:23:11 <kergoth`> does no one know about variable typing support? :)
May 10 00:24:18 <kergoth`> SOURCE_ARCHIVE_PACKAGE_TYPE[type] = "choice"
May 10 00:24:23 <kergoth`> SOURCE_ARCHIVE_PACKAGE_TYPE[choices] = "tar srpm"
May 10 00:24:31 <kergoth`> oe.data.typed_value('SOURCE_ARCHIVE_PACKAGE_TYPE', d)
May 10 00:24:32 <kergoth`> done.
May 10 00:24:35 * kergoth` rolls eyes
May 10 00:27:18 <incandescant> sadly I think it's safe to assume nobody knows
May 10 00:27:18 <seebs> I am pretty sure that almost no one knows about variable typing support.
May 10 00:27:33 <incandescant> we do have a lot of nice API that doesn't get used
May 10 00:28:03 <incandescant> most recently I wrote a patch to use oe.process instead of using subprocess directly
May 10 00:28:11 * incandescant realises he has yet to submit that
May 10 00:28:30 <kergoth`> we should either do an email or wiki page or both talking about lesser known functionality
May 10 00:28:36 <kergoth`> both classes and the oe python package
May 10 00:28:54 <incandescant> agreed and well volunteered ;-)
May 10 00:28:55 <kergoth`> potentially could be a useful talk at a conference, also
May 10 00:28:57 <kergoth`> haha
May 10 00:28:58 <kergoth`> saw that coming
May 10 00:29:02 <kergoth`> :)
May 10 00:29:22 <incandescant> I'm for wiki, as they seem to turn up more often in $SEARCH_ENGINE results
May 10 00:29:28 <kergoth`> both richard and i would really like to see the variable typing stuff incorporated into bitbake somehow, but its definitely nontrivial
May 10 00:29:31 <kergoth`> heh
May 10 00:29:46 <incandescant> kergoth`: in fairness much of that stuff is your code so I can't think of a better author
May 10 00:30:01 <incandescant> the variable typing stuff is nice
May 10 00:30:26 <kergoth`> true, good point. I'll add it to my todo
May 10 00:30:36 <kergoth`> I'm sure mentor would be willing to let me do it on work time, it benefits them too
May 10 00:31:00 <incandescant> thanks sir!
May 10 00:31:05 <incandescant> if it's anything like my todo we may not see it before the singularity ;-)
May 10 00:31:33 <kergoth`> heh :)
May 10 00:31:43 <kergoth`> well, documentation/training is rapidly becoming a priority for me
May 10 00:31:48 <kergoth`> need to bring other engineers up to speed
May 10 00:31:55 <incandescant> awesome
May 10 00:32:17 <incandescant> on both counts, in fact
May 10 00:32:19 <kergoth`> i bet a lot of the additional functionality could be described almost entirely via resurrection of original commit messages :)
May 10 00:32:23 <kergoth`> https://github.com/kergoth/oe-core/commit/a04ce49
May 10 00:32:36 <incandescant> yeah, I was thinking that a wiki page listing those might be a start
May 10 00:33:02 <incandescant> it'd be a good beginner project to take a commit message, create patches to use the feature and document it
May 10 00:33:21 <incandescant> heck, it'd be a good project for anyone with spare time
May 10 00:34:14 <incandescant> especially with lib oe where we have a lot of instances of copy/paste patterns that would be better off using a shared method
May 10 00:37:18 <kergoth`> yeah, true.. i'm sure there are still lots of cases where some bits should be either updated to use lib/oe bits or be moved out of classes into lib/oe
May 10 00:37:26 <kergoth`> heh, have to say, i'm proud of get_callable_args() in the typing stuff. when you register a callable as a type, if the callable has named arguments, it automatically knows to pull flags of that name from the metadata, and checks for required vs optional ones :)
May 10 00:38:51 <incandescant> that's magic
May 10 00:53:13 <kergoth`> why the hell is SOURCE_ARCHIVE_PACKAGE_TYPE used in package_rpm.bbclass?
May 10 00:53:21 <kergoth`> the bits in there should be *general*
May 10 00:53:44 <kergoth`> if they can't do something archiver needs, they should be enhanced to be able to do so, without hardcoding any knowledge of the caller
May 10 00:53:51 * kergoth` grumbles
May 10 01:15:21 <kergoth`> https://gist.github.com/2650254 -- i think setting ARCHIVER_MODE = "original" is nicer, usability wise, than INHERIT += "archive-original-sources", particularly since with variable typing it will error and tell me what my options are
May 10 01:16:07 * kergoth` puts that in mentor's distro .conf for now
May 10 01:42:49 <sgw> kergoth`: file a bug please
May 10 01:43:21 <sgw> kergoth`: I have already talked with him about some sane defaults
May 10 01:43:55 * kergoth` adds to todo for tomorrow
May 10 02:09:50 * kergoth` tests out http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?id=e95b654
May 10 02:17:27 <kergoth`> fray: this is really quite nice, nice work on this. I like it. I think the s/function/func/g is rather unnecessary, but in general I like it. You should send it to the list for comments if you haven't already
May 10 02:22:09 <seebs> some day, I would totally like to see some general consistency edits on names.
May 10 02:22:43 <kergoth`> in general, i prefer full to truncated, unless the length is getting ridiculous, personally
May 10 02:22:45 <kergoth`> heh
May 10 02:22:49 <seebs> For instance, replacing the variable 'data' with 'd' in a bunch of bitbake, to distinguish it from the 'data' class and make it consistent.
May 10 02:22:49 <kergoth`> but not everyone agrees
May 10 02:23:02 <seebs> I can go either way on func/function, but either consistently is better than alternation.
May 10 02:23:10 <kergoth`> i think everyone would agree on that one, it could be a solid janitorial task for bitbake
May 10 02:23:13 <kergoth`> (data->d)
May 10 02:23:28 <seebs> The other one that consistently annoyed me while I was studying the variable code was the unpredictability of whether something was named configdata or cfgData.
May 10 02:23:57 <kergoth`> ah, yes, internal naming consistency in bitbake itself is certainly an issue
May 10 02:24:08 <kergoth`> we should be complying with PEP8, but right now we're not
May 10 02:24:10 <seebs> Huh.  I might do a commit or two of this some time.
May 10 02:24:20 <kergoth`> http://www.python.org/dev/peps/pep-0008/ for reference
May 10 02:32:26 <kergoth`> fray: bug: you setVar BB_LOGFILE in _exec_task, but use it in exec_func. this breaks when an eventhandler calls exec_func (e.g. buildhistory_commit). I think you'll have to rethink the log name bits a bit
May 10 02:46:14 <kergoth`> fray: or at the very least define a default BB_LOGFILE value in oe-core :)
May 10 02:46:26 * kergoth` tests that
May 10 02:48:10 <khem> Do we install the kconf tools from kernel into native sysroot ?
**** ENDING LOGGING AT Thu May 10 03:00:03 2012

**** BEGIN LOGGING AT Thu May 10 03:00:04 2012
May 10 03:32:28 <yilong> hi hongna
May 10 04:49:18 <khem> JaMa: I got to understand the gold/armv4t/thumb problem now
May 10 04:52:14 <khem> JaMa: bad thing is that its not that easy to fix, since it would mean gold has to support thumb plts and also thumb interworking glue code for arch < armv5t, its quite a bit of work. I did do some patch for it but only to find that it needs a lot more than I expected. May be my approach is not good but I am not going to fix it for armv4t. For arm v5t+ I would fix gold to do thumb plts
May 10 04:53:03 <khem> JaMa: do you see an issue where you default to gold for all arm > v5 only
May 10 05:16:21 <eFfeM_work> gm
May 10 05:38:36 <khem> hi eFfeM_work
May 10 05:40:16 <eFfeM_work> khem, image seems to build fine with the rtld patch, but still haven't tested it due to time constraints and work that was needed to update my kernel (moving from 2.6.38 to 3.2)
May 10 05:40:43 <eFfeM_work> still interested to learn from someone what the best way is to get rid of of_register_platform_driver as that one disappeared after 2.6.38
May 10 05:47:08 <khem> eFfeM_work: wouldn't platform_driver_register work instead
May 10 06:09:18 <eFfeM_work> khem, not sure, will check that out, thanks for the suggestion
May 10 06:11:28 <eFfeM_work> khem, did a quick peek, found the patches that removed it and if I peek at http://lists.ozlabs.org/pipermail/linuxppc-dev/2011-February/088517.html that seems quite straightforward
May 10 06:22:23 <JaMa> khem: no issues for armv5te and armv7a
May 10 06:23:00 <JaMa> khem: well GNUtoo reported that firefox is segfaulting since switch to gold, but I haven't confirmed it (yet)..
May 10 06:23:11 <JaMa> khem: on armv7a ^
May 10 06:34:09 <JaMa> khem: and can you please report this issue upstream (you can surely describe it better then I) maybe someone else will decide to fix armv4t
May 10 07:10:52 <mckoan> good morning
May 10 07:43:01 <bluelightning> morning all
May 10 07:59:41 <sgw> bluelightning: morning
May 10 07:59:49 <bluelightning> hi sgw
May 10 08:36:30 <hwinkel> Hi
May 10 08:36:54 <hwinkel> Somebody around knows a bit more about packaging with Yocto
May 10 08:36:56 <hwinkel> ?
May 10 09:21:23 <bluelightning> hwinkel: sure, what's the question?
May 10 10:13:03 <hwinkel> We are scratich our heads to use yocto to build regular .DEB and .RPM packages
May 10 10:13:48 <hwinkel> I know the Support to Build such packages is there in bbclasses
May 10 10:14:25 <hwinkel> the questions is how to build them for a particual already existing target like Ubuntu, Debian, RH
May 10 10:15:12 <hwinkel> to streamline the build process of Software and generate packages for all our targets (embedded, RPM, DEB) from a single source
May 10 10:57:33 <RP> hwinkel: You would need to define some kind of compaitibility mappings for Ubuntu/debian to ensure the correct package names get used for example
May 10 10:57:54 <RP> hwinkel: Its not something people have really tried or that is well supported at present
May 10 10:58:15 <RP> hwinkel: Its certainly possible but would likely need work to get it going and to maintain it
May 10 11:20:47 <hwinkel> RP: work its expected
May 10 11:21:22 <hwinkel> RP: just meesing around with other options like OBS or homegrown stuff
May 10 11:23:04 <RP> hwinkel: I'd imagine you can extend what we already have easier than growing something new at least...
May 10 11:49:52 <ant_work> RP: ping
May 10 11:52:29 <hwinkel> RP: thats the goa, not really starting from scratch makes sens
May 10 11:52:48 <RP> ant_work: pong
May 10 11:53:23 <ant_work> hi
May 10 11:53:45 <ant_work> after 3.1 some headers have been reworked and arm is impacted
May 10 11:54:36 <ant_work> now, some headers are in generated/asm
May 10 11:55:00 <ant_work> (pointing to include/asm-generic)
May 10 11:55:18 <ant_work> atm I have a single package failing
May 10 11:55:52 <ant_work> this is klibc but I think it can be a generic issue
May 10 11:56:05 <ant_work> i.e   http://lxr.free-electrons.com/source/include/asm-generic/int-ll64.h?v=3.2;a=arm
May 10 11:56:13 <ant_work> #include <asm/bitsperlong.h>
May 10 11:56:29 <ant_work> ^^ this is now in /include/generated/asm/
May 10 11:56:42 <ant_work> so, what is wrong? the kernel header itself?
May 10 11:57:14 <ant_work> the recipe just includes unistd and types.h, thus int-ll64.h
May 10 11:57:29 <ant_work> should I special-case the header install?
May 10 11:58:24 <exosyst> Heya, is there any work on getting beaglebone working with Yocto?
May 10 11:58:38 <exosyst> I see the beagleBOARD is already supported
May 10 11:59:07 <RP> ant_work: I doubt the kernel header install is wrong, I'd suspect klibc needs an update to match
May 10 11:59:48 <ant_work> hmm, the last include comes fromanother kernel header...
May 10 12:00:30 <RP> ant_work: I don't know enough about it to comment really :(
May 10 12:00:40 <RP> ant_work: You really need to talk to the arm kernel people
May 10 12:01:00 <RP> ant_work: If our generated headers are incorrect we should fix that
May 10 12:01:15 <RP> ant_work: AFAIK, we just run the kernel makefile target though
May 10 12:01:20 <ant_work> it is a new mechanism in the kernel makefiles
May 10 12:02:06 <ant_work> http://lxr.free-electrons.com/source/scripts/Makefile.asm-generic?v=3.2;a=arm
May 10 12:04:06 <RP> ant_work: well, looking at my arm 3.2 kernel libc headers here, the bitsperlong.h header is there just fine
May 10 12:04:21 <ant_work> there = ?
May 10 12:05:03 <RP> /usr/include/asm/bitsperlong.h
May 10 12:05:19 <ant_work> ah, the copy in /usr
May 10 12:05:35 <ant_work> sure, but this is not in path...
May 10 12:05:56 <RP> ant_work: which path?
May 10 12:06:29 <RP> you usually compile libc against linux-libc-headers
May 10 12:06:37 <ant_work> no, full kernel source
May 10 12:07:15 <RP> ant_work: no, we *do* compile uclibc, eglibc and glibc against linux-libc-headers
May 10 12:07:47 <ant_work> I know, debian did some work but I see gentoo stil compiles against kernel headers
May 10 12:08:12 <RP> ant_work: I *know* how our toolchain builds ;-)
May 10 12:08:28 <ant_work> in fact klibc is still machine-specific for that reason , sigh :/
May 10 12:08:44 <ant_work> maybe you can help here :)
May 10 12:08:46 <RP> ant_work: can't klibc compile against the libc headers like everything else
May 10 12:08:57 <ant_work> not long ago, no
May 10 12:09:22 <RP> things have changed in the intervening years...
May 10 12:09:34 * RP -> back in a bit
May 10 12:11:02 <ant_work> http://patch-tracker.debian.org/package/klibc/2.0~rc3-1  -> klibc-linux-libc-dev  maybe this
May 10 12:12:20 <exosyst> Is it typically easy to mix and match components in a yocto setup? I want to take an existing rootFS but rebuild the kernel from source... is this a standard thing to want to do?
May 10 12:32:51 <RP> exosyst: an externally provided rootfs?
May 10 12:34:20 <RP> ant_work: yes
May 10 12:35:10 <ant_work> RP: I think this is only for the install part, i.e. building with klcc
May 10 12:36:05 <RP> ant_work: I'd doubt you have to do an kernel install headers each time!
May 10 12:38:14 <ant_work> ok, so you say: build with sanitizied linux-libc-dev headers
May 10 12:38:31 <ant_work> even if Gentoo's says "The sys-kernel/linux-headers are too stripped down to use unfortunately"
May 10 12:39:15 <ant_work> ok, once klibc 2.0 is released I'll try to get rid of the kernel-source
May 10 12:40:06 <RP> ant_work: They're stripped down but uclibc and glibc can use them...
May 10 12:40:28 <ant_work> I really can't say what's so special there
May 10 12:40:45 <ant_work> khem once helped me but the result is we need kernel sources
May 10 12:40:49 <ant_work> atm
May 10 12:42:02 <ant_work> I have worked-around th eissue adding some symlinks in do_compile_prepend but clearly this is not orthodox
May 10 12:43:21 <RP> ant_work: http://packages.debian.org/source/wheezy/klibc - it depends on linux-libc-headers (in our terms)
May 10 12:47:44 <ant_work> I'll be happy to try: I'll adapt that debian patch..ignoring DEB_HOST_MULTIARCH, just ARCH
May 10 12:47:45 <exosyst> RP, Sorry - I'm working my way through the reams of documentation! I want to take the rootfs provided by Yocto as a binary but configure/build the kernel seperately... hopefully within Yocto. Can that be done, is it discouraged?
May 10 12:48:27 <ant_work> RP: I'll let you know about evtl. missing required headers
May 10 12:49:37 <ant_work> RP: one last thing: do you see interest for klibc in oe-core? We can compile practically all now (still to try kmod tbh)
May 10 12:50:05 <RP> exosyst: well, the trouble would be injecting kernel modules as packages and ensuring consistency
May 10 12:50:29 <RP> exosyst: Most usually you'd just take an existing kernel source tree/configuration and just build it within the system as the easiest solution
May 10 12:50:34 <ant_work> RP: I say that because I see more and more msgs about initramfs in Yocto ML
May 10 12:51:08 <RP> ant_work: I'm having a hard time working up enthusiasm for klibc, I've not heard any requests for that
May 10 12:52:12 <ant_work> RP: there was some slow progress wrt linux 'tiny' c/o CELF
May 10 12:52:31 <ant_work> tiny kernel *and* userspace
May 10 12:52:59 <RP> ant_work: we also have ways of a small userspace with eglibc...
May 10 12:54:08 <ant_work> I can't say generally, but for our project klibc and maybe dietlibc are the only libs allowing small static binaries
May 10 12:54:24 <RP> ant_work: right, but I'm not hearing many requests for this
May 10 12:55:11 <ant_work> remember that soon if /usr is on a separate partition you'll need an initramfs
May 10 12:55:36 <ant_work> it could be nice to add a small initramfs to do that first things
May 10 12:55:41 <RP> ant_work: no, that doesn't follow
May 10 12:56:15 <ant_work> not on embedded, agreed
May 10 13:14:52 <exosyst> RP, The problem is that I am still finding my feet with Yocto but do thing it's a good solution. I'm going to be teaching people on Beaglebones but there's only a BeagleBOARD BSP. I assume the rootfs will work fine but imagine the kernel will give me grief. I am not adverse to rolling my own but would like to do it "The Yocto Way"
May 10 13:19:19 <bluelightning> exosyst: there is a meta-ti layer which contains support for beaglebone AFAIK
May 10 13:19:33 <bluelightning> exosyst: I have a beaglebone here now but haven't tried to build anything for it yet
May 10 13:20:00 <bluelightning> http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti
May 10 13:20:14 <bluelightning> http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/README
May 10 13:24:45 <khem> JaMa: upstream does have a similar bug for gold
May 10 13:25:37 <khem> JaMa: i did not see much interest in my comment to the bug where i metion about armv4t
May 10 13:26:42 <khem> re. firefox, yes it could fail, if compiled in thumb2
May 10 13:26:54 <khem> for which I do know the fix
May 10 13:27:00 <exosyst> bluelightning, That's useful - I hadn't seen that. I only saw beaglebone in the supported list (i nabbed denzil-poky.tar.gz from the site). How would I go about building for the beaglebone? I tried adding it to the options but, perhaps obviously, it failed to find the beaglebone layer
May 10 13:27:52 <khem> exosyst: you need to add this layer to bblayer.conf file
May 10 13:29:01 <JaMa> khem: do you have link for that bug?
May 10 13:29:40 <JaMa> khem: maybe they should at least provide error message saying that resulting armv4t binaries will be useless..
May 10 13:29:44 <exosyst> khem, what layer? I'm still reading through the docs as I go - I've built a test run for QEmu, and one for the BeagleBoard but am not sure on how I would add the beaglebone layer to a stock denzil tarball?
May 10 13:32:01 <khem> JaMa: http://sourceware.org/bugzilla/show_bug.cgi?id=13320
May 10 13:33:03 <khem> exosyst: clone meta-ti layer somewhere and then add that to build/conf/local.conf
May 10 13:33:21 <khem> to BBLAYERS
May 10 13:34:26 <bluelightning> khem: you mean build/conf/bblayers.conf right?
May 10 13:34:45 <khem> err yes
May 10 13:35:00 <khem> one hand typing :)
May 10 13:35:40 <ag> Anybody with some problems while fetching linux-yocto?
May 10 13:35:41 <exosyst> khem, does MACHINE ?= "beaglebone" need to be added to the local.conf as well?
May 10 13:35:59 <ag> Unable to fetch URL from any source....
May 10 13:36:34 <khem> exosyst: yes or you can specify it on cmdline
May 10 13:36:48 <exosyst> oh... didn't know I could cli it :-/
May 10 13:37:21 <zeddii> ag: what sort of problem are you seeing ? aborted fetch ?
May 10 13:37:23 <khem> MACHINE=... bitbake ...
May 10 13:37:31 <JaMa> khem: well they had only 15 minutes to show interest, maybe later someone will reply :)
May 10 13:37:33 <ag> zeddii: ERROR: Function failed: Fetcher failure for URL: 'git://git.yoctoproject.org/linux-yocto-3.0;protocol=git;bareclone=1;branch=yocto/standard/base,meta;name=machine,meta'. Unable to fetch URL from any source.
May 10 13:38:01 <khem> JaMa: its over a day
May 10 13:38:13 <zeddii> > git ls-remote git://git.yoctoproject.org/linux-yocto-3.0 yocto/standard/base
May 10 13:38:13 <zeddii> da7c40006b08916ff3a3db104def82aaf9ac2716        refs/heads/yocto/standard/base
May 10 13:38:18 <khem> you clock is skwed
May 10 13:38:29 <exosyst> khem, I get a ParseError... you any good at debugging them? http://pastebin.com/3wA6bx7d
May 10 13:39:04 <ag> zeddii: yeah... strange
May 10 13:39:27 <khem> exosyst: you need meta-oe too i guess
May 10 13:39:33 <zeddii> ag: indeed.
May 10 13:40:00 <exosyst> khem, Oh - Can I ask why and from where I get it?
May 10 13:40:20 <bluelightning> exosyst: it's listed on the layer index: http://www.openembedded.org/wiki/LayerIndex
May 10 13:40:21 <khem> i thought meta-ti just worked on top of oe-core
May 10 13:40:36 <bluelightning> khem: unfortunately it references systemd.bbclass so it still needs meta-oe
May 10 13:41:03 <zeddii> I thought Denys said a few days ago 'nearly there', but I may be imagining things.
May 10 13:41:17 <bluelightning> well at least it no longer needs meta-angstrom to work
May 10 13:41:17 <khem> yeah
May 10 13:41:27 <khem> yeah
May 10 13:41:36 <exosyst> khem, bluelightning Ok. So I can clone that in, add that onto the bblayer.conf and fire away?
May 10 13:41:52 <bluelightning> honestly I really think we need to stop having separate bbclasses for init and just have the one that does the right thing depending on distro policy
May 10 13:42:04 <khem> JaMa: btw. that bug is not the only problem though there is more attached to it
May 10 13:42:10 <ant_work> yes, some BSP do directly reference meta-oe. This is wrong imho
May 10 13:42:21 <bluelightning> trying to maintain the two separately so that you can support either in the one distro config is going to get increasingly harder and seems a bit pointless to me
May 10 13:42:38 <bluelightning> exosyst: should be able to yes
May 10 13:42:54 <khem> JaMa: but if you can work on mozilla issue that we can try to fix since its for armv7
May 10 13:43:01 <ant_work> bluelightning: pls raise the systemd issue by next TSC
May 10 13:43:09 <exosyst> bluelightning, we shall see =)
May 10 13:43:36 <bluelightning> ant_work: I'll raise it on the mailing list first, then we can discuss it in the TSC if that goes nowhere
May 10 13:43:41 <khem> systemd is spun out into layer of its own iirc
May 10 13:44:44 <bluelightning> khem: I believe that's the plan yes, but it doesn't seem to have been done yet (not sure whether koen agreed to do it or whether someone else needs to volunteer)
May 10 13:45:20 <bluelightning> short term that's fine, but long term we want to pull it into oe-core
May 10 13:45:29 <exosyst> Is it 'safe' to ignore warnings about network manager/SYSTEMD_PACKAGES on this?
May 10 13:45:33 <bluelightning> I still think it shouldn't be a separate class though
May 10 13:46:11 <bluelightning> exosyst: well, it should be... I don't know how well-tested meta-oe is without fully moving to systemd though
May 10 13:46:53 <exosyst> bluelightning, how do you mean? Is systemd the preferred init when using meta-oe and is it sysvinit otherwise?
May 10 13:47:25 <khem> ideally it should work fine if systemd is not chosen
May 10 13:47:30 <bluelightning> exosyst: it shouldn't be that way, but the main users of meta-oe have moved to systemd whereas currently within the yocto project we are still using sysvinit
May 10 13:47:39 <exosyst> bluelightning, khem Failed miserably with qt4-x11-free problems :(
May 10 13:48:00 <bluelightning> exosyst: it's just that the combination is not well-tested, so you may experience problems
May 10 13:48:27 <khem> IMAGE_INIT_MANAGER is what decides
May 10 13:48:30 <bluelightning> exosyst: could you pastebin the error?
May 10 13:49:05 <exosyst> bluelightning, I'm seeing no recipes available for qt4 and openssh  http://pastebin.com/dCwTAnFd
May 10 13:49:12 <bluelightning> khem: which OE-core doesn't define at all... (maybe it doesn't need to)
May 10 13:49:46 <JaMa> exosyst: you need to watch for stuff like polkit which by default pulls systemd to your image even with INIT_MANAGER set to sysvinit..
May 10 13:49:52 <JaMa> exosyst: http://comments.gmane.org/gmane.comp.handhelds.openembedded/50240
May 10 13:50:57 <bluelightning> exosyst: ah I see, so meta-oe has moved on to match master of OE-core; you may need to back off to an earlier version of meta-oe
May 10 13:51:19 <khem> yeah systemd if meta-ti is needing it then best is to use it default init manager for success
May 10 13:51:41 <bluelightning> exosyst: in fact there is a denzil branch of meta-oe, you should do a "git checkout denzil" in meta-openembedded
May 10 13:51:41 <khem> there is denzil branch
May 10 13:52:06 <khem> git checkout -b denzil origin/denzil
May 10 13:52:48 <bluelightning> khem: git checkout denzil does the same thing...
May 10 13:53:13 <bluelightning> (unless you already have a local branch called denzil of course)
May 10 13:53:59 <exosyst> bluelightning, I did that... how do I sync it up though? A git pull shows it as all being upto date
May 10 13:54:25 <bluelightning> exosyst: doing a checkout is enough, you're now on the denzil branch if you've done that (the last pull you did fetched it already)
May 10 13:54:52 <exosyst> Oh, i don't need to pull the changes? the recipes will take care of that?
May 10 13:55:44 <bluelightning> exosyst: should all be fine, particularly as you haven't built anything yet
May 10 13:56:48 <khem> bluelightning: i dont have normal repos so I refrain from simplified checkouts
May 10 13:57:13 <exosyst> bluelightning, Ok, well i've fired off a bitbake -k core-image-minimal to see how we get on thanks :D
May 10 13:57:30 <bluelightning> exosyst: cool, let us know how it goes
May 10 16:04:54 <jmdelos_> how do you specify a differnet local file name for a wget fetcher SRC_URI?
May 10 16:14:38 <incandescant> I believe there's a localfile parameter on SRC_URI
May 10 16:19:31 <jmpdelos> that's what I thought but a coworker claimed it was just passed to wget; guess I'll have to pursue it myself
May 10 16:19:33 <jmpdelos> thanks
May 10 17:06:13 <kergoth`> hmm, t hats odd, i can't clone openembedded-core-contrib
May 10 17:16:50 <kergoth`> Cloning into 'openembedded-core-contrib'...
May 10 17:16:51 <kergoth`> fatal: remote error: Repository not found.
May 10 17:16:54 * kergoth` scratches head
May 10 17:22:20 <bluelightning> kergoth`: that is odd, it's working here...
May 10 17:22:36 <kergoth`> think i found it, its my git url replacements
May 10 17:22:39 * kergoth` rolls eyes
May 10 17:24:01 <kergoth`> hmm, i thought so anyway..
May 10 17:24:05 * kergoth` mutters
May 10 17:49:18 <sgw> halstead: ping
May 10 17:58:50 <halstead> sgw /srv/www/vhosts/sstate.yoctoproject.org/sstate/
May 10 18:51:02 <alephan> zeddii: That kernel died again.
May 10 18:51:14 <alephan> I still think is something wrong with remote.
May 10 18:51:45 <zeddii> there seems to be trouble on the mirrors. given the other reports floating by on the various lists.
May 10 18:53:15 <alephan> I see.
May 10 18:53:20 <alephan> Any temporary fix?
May 10 18:53:56 <zeddii> not that I know of. maybe sgw or halstead may have ideas.
May 10 18:54:25 <alephan> sgw: Any ideas?
May 10 18:55:04 <sgw> alephan: what's the issue?
May 10 18:55:21 <alephan> ERROR: Function failed: Fetcher failure for URL: 'git://git.yoctoproject.org/linux-yocto-3.0;protocol=git;bareclone=1;branch=yocto/standard/beagleboard,meta;name=machine,meta'. Unable to fetch URL from any source.
May 10 18:56:14 <sgw> alephan: can you clone by hand?
May 10 18:56:20 <alephan> zeddii said that is a known problem or at least reported by others as well
May 10 18:56:32 <sgw> alephan: I am able to clone that by hand
May 10 18:56:32 <alephan> sgw: Yes i can.
May 10 18:56:49 <alephan> me too. Somethib is broken in the build.
May 10 18:56:51 <sgw> zeddii: I am not aware of this issue.
May 10 18:56:54 <alephan> something*
May 10 18:57:18 <zeddii> see what Tom and Kishore were talking about on the yocto list.
May 10 18:57:36 <zeddii> some sort of intermittent issue with the 3.0 kernel tree (I'm guessing).
May 10 18:58:09 <alephan> I'm talking about the same build the last night suceeded and today died. Nothing changed.
May 10 18:58:38 <alephan> s*ucceeded
May 10 18:58:41 <sgw> that's strange, it should not have to re-clone if nothing has changed
May 10 18:58:53 <alephan> Yeah...
May 10 18:59:35 <alephan> Are you able to reproduce this in a build of yours?
May 10 18:59:50 <alephan> Obviously, if you have time to do it.
May 10 19:00:31 <sgw> alephan: I will have to set somethingup, but if tomz2 is working on it already
May 10 19:01:07 <alephan> uh. Btw. I'm talking about denzil tag
May 10 19:01:20 <tomz2> sgw: i just verified that it was a problem fetching the 3.0 kernel
May 10 19:01:29 <alephan> So i still think it's a problem related to mirror / remote
May 10 19:01:49 <sgw> tomz2: so is it fixed now or does the mirror have a bad image somehow?
May 10 19:01:53 <tomz2> sgw: wget -t 5 --passive-ftp --no-check-certificate 'http://downloads.yoctoproject.org/mirror/sources/git2_git.yoctoproject.org.linux-yocto-3.0.tar.gz' fails
May 10 19:02:19 <tomz2> sgw: while substituting 3.2 for 3.0 works fine
May 10 19:03:13 <tomz2> sgw: no idea, looks like a bad git2_ file for the 3.0 kernel in downloads
May 10 19:03:32 <sgw> tomz2: Ok, let me check it out.
May 10 19:05:04 <zenlinux> I'm confused about where /var/volatile is cropping up in my build of a recipe. The directory doesn't exist in workdir/image, but it's there in workdir/package.
May 10 19:05:28 <sgw> Yesh, I am on the server, looks like it got clobbered on tuesday !  Not sure what writes that directory, we are restoring it now
May 10 19:06:06 <alephan> sgw: Nice
May 10 19:06:24 <alephan> sgw: One thumb up when you are ready.
May 10 19:07:14 <sgw> try again
May 10 19:07:28 <sgw> but that does not address if the git clone is failing!
May 10 19:07:50 <tomz2> sgw: working for me here now
May 10 19:08:08 <seebs> Hey, idle question.  I have a toolchain with no RPC in glibc.  In the interests of testing other stuff, I'd like to use it anyway.  Is there a trivialish way, such as a variable I could override, that would make busybox not try to use RPC?
May 10 19:08:28 <sgw> alephan: what about you is git working?
May 10 19:08:29 <seebs> I am vaguely aware that there was some option that could be set in busybox's config, but I do not understand the recipe well enough to apply it.
May 10 19:09:04 <alephan> sgw: fetching...
May 10 19:09:58 <kergoth`> seebs: just look at what files use the rpc headers. iirc just disable the nfs mount bits
May 10 19:10:22 <seebs> I have the feature list handy because we already do this for our uclibc builds in our regular product.  :)
May 10 19:10:32 <seebs> I am just staring in blank confusion at busybox.inc.  :)
May 10 19:14:46 <khem> seebs: yeah busybox needs something better there
May 10 19:15:12 <khem> I sometimes intended that something we have for uclibc can be an improvement for busybox to start with
May 10 19:15:18 <seebs> I am thinking I want to add a "norpc" DISTRO_FEATURES that turns off MOUNT_NFS and HAVE_RPC, and then bolt that onto DISTRO_FEATURES.
May 10 19:15:31 <khem> ideally it would be nice if we have similar experience with all packages that use kconfig
May 10 19:15:42 <seebs> Heh.  Annoyingly, I'm working with a copy of bitbake which lacks my lovely variable tracking so I have no idea how this works now.  :)
May 10 19:16:00 <seebs> I would especially like it if the similar experience involved shooting kconfig in the head.  :P
May 10 19:16:17 <khem> seebs: eglibc's featurelist is what I would suggest since it grouped around posix groups
May 10 19:16:52 <seebs> Well, right now, I am trying for "shortest path to running some builds so I can test stuff".
May 10 19:18:10 <khem> seebs: there is something like libc-sunrpc and libc-nis in eglibc
May 10 19:18:19 <khem> you might want to reuse those LIBC_FEATURES
May 10 19:18:33 <alephan> sgw: It works now
May 10 19:18:38 <alephan> thanks you very much
May 10 19:18:44 <seebs> That makes sense.
May 10 19:18:49 <khem> it would be less confusing if users has same featureset across libc's more or less
May 10 19:18:55 <alephan> sgw: see you on Monday
May 10 19:18:59 <alephan> sgw: :)
May 10 19:19:12 <sgw> alephan: Sure thing!
May 10 19:19:23 <alephan> cheers
May 10 19:19:26 <alephan> gone home
May 10 19:19:33 <khem> sgw: do you know Stu :)
May 10 19:19:58 <seebs> Good thought, khem.  Although, as noted, this will probably last for all of two weeks before being eradicated by force.
May 10 19:20:10 <sgw> Stu?
May 10 19:21:32 <khem> sgw: Stu Grossman
May 10 19:21:44 <khem> from past life
May 10 19:21:45 <sgw> Yes I do know him from ages ago!
May 10 19:21:54 <khem> he remembers you
May 10 19:22:12 <sgw> Say hello, do you guys work together?
May 10 19:22:17 <khem> yes we do
May 10 19:22:58 <khem> sgw: on a different note do you have some of my pulls under test atm ?
May 10 19:23:23 <sgw> yes, but we are having some AB issues with the kernel
May 10 19:23:38 <khem> oh due to my stuff ?
May 10 19:23:41 <sgw> I am working to resolve that now
May 10 19:23:44 <sgw> no not your stuff
May 10 19:23:49 <khem> k
May 10 19:23:51 <sgw> other strange happenings
May 10 19:24:00 <khem> hmm ok
May 10 19:24:13 <khem> seebs: ok.
May 10 19:27:17 <seebs> Hmm.  Come to think of it:  With eglibc having, at least sometimes, no RPC:  Should we be trying to fix things so that can work without being a big hassle?
May 10 19:27:48 <seebs> If that can be done cheaply, it's probably worth a bit of effort to clean it up.
May 10 19:31:04 <khem> seebs: yes why not
May 10 19:31:43 * khem gets SIGFOOD
May 10 19:42:25 <seebs> Hmm.  Building ncurses-native, I had a failure where tic failed because "tic: error while loading shared libraries: /wall/of/path/libtinfo.so.5: file too short"
May 10 19:42:38 <seebs> That is a new one on me.  But I can't reproduce it by running tic manually, so I suspect race conditions.
May 10 19:44:17 <sgw> zeddii: I think were just having a bad download somehow, I did a cleanall and refetched and it works fine, I hate that as a solution, becuase I really want to know what happened!
May 10 19:46:21 <zeddii> agreed.
May 10 19:46:33 <RP> seebs: there is an open bug
May 10 19:46:55 <seebs> Yay.
May 10 19:46:59 <RP> seebs: it is a race
May 10 19:47:14 <seebs> k.  I may look at it if it ever bites me again.
May 10 20:32:14 <khem> so I can now build core-image-sato for mips64 later today I will check if it boots into gui too or not
May 10 20:36:05 <zeddii> khem. I was just poking around at the kernel on that as well, since I was about to move linux-yocto-dev to a 3.4 tree. should I stop poking at it ?
May 10 20:43:04 <khem> oh wow it boots straight into xorg how nice
May 10 20:43:36 <khem> zeddii: you mean userspace bits ?
May 10 20:43:42 <khem> zeddii: or kernel
May 10 20:43:53 <khem> zeddii: I have few patches to meta in kernel
May 10 20:44:03 <khem> that I pointed in my bug I filed for yoy
May 10 20:44:09 <khem> I am still carrying them
May 10 20:44:20 <khem> right now I have kind of three layers
May 10 20:44:29 <khem> oe-core + meta-qemextra
May 10 20:44:34 <khem> + poky-extra
May 10 20:44:39 <khem> that I am using
May 10 20:44:52 <khem> kind of spread around arm
May 10 20:44:55 <khem> err atm
May 10 20:45:50 <zeddii> khem. kernel in particular. ok that's good. I just wanted to make sure there wasn't any big changes.
May 10 20:45:59 <zeddii> I'll pick it up again tomorrow.
May 10 20:46:25 <khem> zeddii: no big changes
May 10 20:46:33 <khem> only two issues, 1 with oprofile
May 10 20:46:40 <khem> which I think you kind of addressed
May 10 20:46:45 <khem> I have not tried that yet
May 10 20:46:51 <zeddii> yah. for now :) I'll revisit it as well.
May 10 20:46:52 <khem> second is with SSD
May 10 20:47:08 <zeddii> that's the one I recalled. and where I was going to start. disk boot was broken.
May 10 20:48:59 <khem> k
May 10 20:49:05 <khem> I have a workaround for nw
May 10 20:49:37 <khem> zeddii: do you want to play with the root file system ?
May 10 20:49:54 <zeddii> if possible. I'm still using my old one.
May 10 20:50:04 <khem> then I can put the qemuextras patches into oe-core and push out a contrib tree
May 10 20:50:08 <khem> let me do that today
May 10 20:50:17 <khem> so you can pull my branch of oe-core
May 10 20:50:26 <khem> and slap poky-extras on top
May 10 20:50:26 <zeddii> perfect. that will help me get going faster tomorrow.
May 10 20:50:45 <khem> ok
May 10 20:51:10 <zeddii> off for food now.
May 10 20:51:12 * zeddii flees
May 10 20:53:29 <khem> its a nice weather here all week and I am sitting with bruised shoulder and arm otherwise I will be rather biking
May 10 20:56:52 * zenlinux brings another 1.5 TB online for his point-release build machine
May 10 20:59:25 <halstead> More storage is fun times eh zenlinux?
May 10 21:00:16 <zenlinux> well, not as fun as SSD storage
May 10 21:03:32 <denix> I finally got my speedy ssd replaced after it lost one of the raid drives...
May 10 21:03:36 <denix> khem: ping
May 10 21:06:19 <khem> denix: yes
May 10 21:06:31 <khem> zeddii: btw. I have a contrib tree that you can use now
May 10 21:06:39 <zenlinux> khem, sorry to hear about your injured arm
May 10 21:06:55 <khem> zenlinux: yes it happened :(
May 10 21:07:00 <khem> crazy teens
May 10 21:07:02 <zenlinux> what happened?
May 10 21:07:43 <khem> two kids pushing each other in frolic pushed one of them into bike lane when I raised my head it was too late tried to dodge and lost balance :)
May 10 21:08:01 <khem> I trusted pedestrians more than I should have
May 10 21:08:12 <zenlinux> khem, ouch! as a fellow avid rider I can sympathize
May 10 21:08:20 <denix> khem: as a gold linker specialist, any hints for this issue: https://lists.yoctoproject.org/pipermail/meta-ti/2012-May/001092.html
May 10 21:08:24 <khem> zeddii: http://git.openembedded.org/openembedded-core-contrib kraj/misc
May 10 21:08:35 <denix> khem: I know a special word - please! :)
May 10 21:08:59 <khem> zeddii: and slap poky-extra on top
May 10 21:09:02 <khem> for kernel
May 10 21:09:15 <khem> then MACHINE=qemumips64 bitbake core-image-sato
May 10 21:10:00 <khem> zenlinux: I would have biked all week but have nurse the arm
May 10 21:10:06 <khem> and bike needs repair too :)
May 10 21:10:09 <khem> but thats waiting
May 10 21:10:33 <zenlinux> that's rough too, because since the person wasn't in a car, there's no insurance you can collect from :-/
May 10 21:10:44 <zenlinux> (except your own)
May 10 21:10:52 <denix> khem: get well! I haven't had time to start riding this spring yet...
May 10 21:11:02 <khem> denix: you are trying to link kernel with gold
May 10 21:11:09 <khem> denix: that may not fly
May 10 21:11:37 <khem> denix: kernel and glibc are two beasts that are eternally in love with gnu linker
May 10 21:11:38 <denix> khem: kernel linking with gold is not supported?
May 10 21:11:47 <khem> kernel is getting better
May 10 21:11:47 <denix> ah
May 10 21:11:52 <khem> uboot is another one
May 10 21:12:01 <denix> need to exempt kernel from defaults then
May 10 21:12:03 <khem> zenlinux: yep
May 10 21:12:27 <khem> zenlinux: and my shoe came out in time so I could do a heroic roll over and save my bones
May 10 21:12:28 <denix> right, we have that exception in u-boot already
May 10 21:12:44 <khem> but that error is worth knowing
May 10 21:12:52 <khem> can you give me some standalone test case
May 10 21:13:05 <khem> like objects and a script to link
May 10 21:13:12 <khem> so I can debug it
May 10 21:13:24 <denix> khem: I'll try to extract it for you
May 10 21:13:29 <khem> it mostly looks like relocation issue from looks of it
May 10 21:13:33 <khem> denix: ok thx
May 10 21:13:40 <denix> khem: thank you!
May 10 21:14:31 <khem> zenlinux: my copay is 400 bucks
May 10 21:14:41 <khem> bike needs prolly around 100-150
May 10 21:14:50 <khem> only handle bar and front brakes need fixing
May 10 21:14:59 <khem> I have to go and talk to mechanic
May 10 21:14:59 <denix> that't not bad
May 10 21:15:06 <zenlinux> definitely could be worse
May 10 21:15:17 <zenlinux> still no fun
May 10 21:15:24 <khem> yeah I am happy that bones didnt break
May 10 21:15:35 <khem> so I am happy to spend 200 odd
May 10 21:15:36 <khem> :)
May 10 21:16:03 <khem> I am hoping in a week I should be back to biking
May 10 21:17:01 <khem> zeddii: my bblayer.conf looks like
May 10 21:17:02 <khem> BBLAYERS = " \ /home/kraj/work/angstrom/sources/poky-extras/meta-kernel-dev \ /home/kraj/work/angstrom/sources/openembedded-core/meta \ "
May 10 21:32:45 <khem> denix: btw. are you using thumb/thumb2 by any chance to build kernel ?
May 10 21:33:00 <denix> indeed
May 10 21:33:09 <khem> there you go
May 10 21:33:25 <khem> ok its something we need to fix in gold then
May 10 21:33:39 <denix> thumb2 is koen's requirement for sub-second boot
May 10 21:33:43 <khem> I will wait for you to create a testcasde
May 10 21:33:53 <khem> hmm ok.
May 10 21:34:05 <khem> and is it for userspace too or just kernel ?
May 10 21:34:30 * khem should subscribe to meta-ti ml
May 10 21:36:16 * khem sends subscription request
May 10 21:36:22 <denix> khem: kernel afaics
May 10 21:36:52 <khem> ok, I think you should try userspace to be t2 as well
May 10 21:37:03 <khem> Welcome to the "meta-ti" mailing list
May 10 21:37:25 <denix> khem: welcome!
May 10 21:37:27 <khem> ok so now I signed up for more crap :)
May 10 21:37:32 <denix> :)
May 10 21:37:44 <khem> shit first message comes is it uber active  ?
May 10 21:37:54 <denix> khem: try userspace to get more issues? :)
May 10 21:38:24 <khem> denix: and better code denisity and coolness for free
May 10 21:38:25 <denix> not normally :) it's your luck
May 10 21:39:25 <khem> denix: meta-ti still needs systemd stuff from meta-oe
May 10 21:39:36 <khem> are you somehow going to make it work with just oe-core
May 10 21:40:25 <denix> khem: yes, my plan to move non-essentials (bone payload etc.) to a separate optional layer - that covers systemd
May 10 21:40:47 <denix> khem: for now the suggestion is to BBMASK meta-ti/recipes-misc
May 10 21:40:54 <khem> denix: ok
May 10 21:41:08 <khem> can you add that information to README please
May 10 21:41:10 <denix> khem: at the same time koen is working on separating systemd in its own layer
May 10 21:41:16 <khem> yes
May 10 21:41:39 <khem> there are folks who are trying to use meta-ti on top of oe-core
May 10 21:41:40 <denix> in the future we'd like it to be an option in oe-core (we had a discussion with RP already at collab)
May 10 21:41:49 <khem> such a info in README will help
May 10 21:43:05 <denix> right
May 10 21:43:14 <khem> thanks
May 10 21:44:22 <denix> gotta go for now, bbl
May 10 21:54:12 <ant__> kh
May 10 21:55:14 <ant__> khem: RP: finally I've got klibc compiling against linux-libc-headers
May 10 22:04:27 <Crofton|work> having oe-core work cleanly with systemd is going to be really importnat
May 10 22:25:07 <zenlinux> Is there something special that needs to be done to save a diff patch sent by email that makes it play nice with git apply?
May 10 22:25:29 <zenlinux> I think I've only pulled patches from other git trees.
May 10 22:26:14 <fray> if the mailer and mta havn't messed it up..  save it as a mail file.. and git am should be able to apply it
May 10 22:26:31 <fray> (I don't use that very often, but I rarely get patches emailed to me)
May 10 22:27:31 <zenlinux> fray, thank you - I was editing the mail to remove the headers, didn't realize I could do it with the raw saved mail file as-is
May 11 01:02:54 <khem> zeddii: around ?
**** ENDING LOGGING AT Fri May 11 02:59:58 2012

**** BEGIN LOGGING AT Fri May 11 02:59:59 2012
May 11 07:09:41 <mckoan> good morning
May 11 14:28:27 <RP__> halstead: Is something wrong with git.yoctoproject.org?
May 11 14:28:56 <RP__> hmm, could be OSU :/
May 11 14:39:47 <ant_work> RP__: hi, problem solved wrt linux-libc-headers and klibc
May 11 14:40:47 <RP__> ant_work: great! :)
May 11 14:40:53 <ant_work> RP__: now just some doubts about the right location in sysroot: what's confusing is STAGING_DIR_TARGET and STAGING_DIR_HOST
May 11 14:40:53 <RP__> ant_work: I think that is the best solution
May 11 14:41:14 <RP__> ant_work: In the target case they are equal
May 11 14:41:31 <ant_work> both seems to work but for the klcc cross-compiler I'm using the _HOST, so it ios mangled
May 11 14:42:12 <RP__> ant_work: well, for a cross compiler, you should install it into the native sysroot...
May 11 14:42:23 <RP__> ant_work: (in  a suitable sub directory)
May 11 14:42:31 <ant_work> yep, I inherit cross and put it where gcc-cross is
May 11 14:42:52 <RP__> ant_work: ok, that is fine
May 11 14:42:58 <ant_work> thx for confirming it
May 11 14:43:43 <ant_work> I'll commit the new recipes this evening and will bother you for a quick check soon ;)
May 11 14:51:40 <halstead> RP, I don't have any notices from OSU. What ar eyou seeing?
May 11 14:52:39 <RP__> halstead: I can't connect to git.yoctoproject.org or the website, or the linuxfoundation stuff for that matter
May 11 14:53:23 <RP__> halstead: Its possible some routes between me and it are going into a blackhole...
May 11 14:53:26 <halstead> RP__, Just checking in with the LF. It looks like we may have DDOS going on.
May 11 14:53:52 <halstead> We have a huge spike here http://netfoo.nero.net/netviewer?meta=osuosl&locale=OSUOSL-Linux-Foundation
May 11 14:54:34 <RP__> halstead: right :(
May 11 14:55:47 <RP__> halstead: I can get to corv-car1-gw.nero.net but nothing showing on traceroute beyond that
May 11 14:58:51 <halstead> We are looking into it. I'll update as I know more.
May 11 14:59:25 <RP__> halstead: thanks
May 11 17:15:14 <sgw> RP: Are you going to pull the poky.conf change?
May 11 18:33:01 <kergoth`> Hmm, wonder why check_output() is in oe.path, not oe.process
May 11 18:50:32 <seebs> I am just not good at getting builds some days.
May 11 18:51:23 <seebs> In current poky, my attempt to build core-image-base fails because cairo-xlib is needed but not found.
May 11 18:51:58 <seebs> Ahh, I need x11 enabled, and somehow it's not getting into DISTRO_FEATURES.  Silly me.
May 11 20:00:55 <khem> do you want what exactly do you want to look in the sources
May 11 20:26:48 <mranostay> so is there any easy way to make a package/license BOM that is mid-management readable? :)
May 11 20:27:01 <mranostay> Tartarus: *ahem*
May 11 20:31:56 <Tartarus> csv baby!
May 11 20:32:16 <mranostay> ok yes but there a bbclass that already does this? :)
May 11 20:32:32 <mranostay> that isn't OSS IP :)
May 11 20:35:36 <mranostay> distrodata?
May 11 20:36:10 <Tartarus> kergoth got some stuff merged in with what was already upstream, iirc
May 11 20:37:25 <mranostay> yeah i think i see it now
May 11 20:37:34 * mranostay hates INHERIT += in the local.conf
May 11 21:41:46 <khem> msm: around ?
May 11 22:57:32 <seebs> Huh, this is new.  I'm trying to build a test thing and I get failures on x86 because "relocation R_386_GOTOFF against undefined hidden symbol (...) can not be used when making a shared object" in libcairo.
May 11 23:06:52 <fray> usually a pic or similar setting is wrong
May 11 23:31:18 <pidge_> mranostay: license.bbclass creates a manifest in ${LICENSE_DIRECTORY}/${IMAGE_NAME}/license.manifest
May 11 23:31:58 <pidge_> mranostay: the package.manifest is at ${LICENSE_DIRECTORY}/${IMAGE_NAME}/package.manifest
May 12 00:10:22 <mranostay> pidge_: you sure it does? :)
May 12 01:04:43 <pidge_> mranostay: Which version are you using? It should.
May 12 01:10:05 <mranostay> old.. well it was a time to git pull anyway
**** ENDING LOGGING AT Sat May 12 02:59:58 2012

**** BEGIN LOGGING AT Sat May 12 02:59:59 2012
**** ENDING LOGGING AT Sun May 13 02:59:59 2012

**** BEGIN LOGGING AT Sun May 13 02:59:59 2012
**** ENDING LOGGING AT Mon May 14 02:59:59 2012

**** BEGIN LOGGING AT Mon May 14 02:59:59 2012
May 14 07:09:25 <mckoan> good morning
May 14 09:22:42 <bluelightning> morning all
May 14 13:05:15 <otavio> Hi all
May 14 13:05:17 <otavio> bluelightning:
May 14 13:05:25 <bluelightning> hi otavio
May 14 13:05:29 <otavio> bluelightning: I found a bug in combo-layer
May 14 13:05:34 <otavio> :)
May 14 13:05:55 <bluelightning> otavio: what's up?
May 14 13:06:04 <otavio> Try to do a interactive call and make a patchlist empty... it will fail
May 14 13:06:24 <otavio> the code expect at least one patch on every patchlist file
May 14 13:07:54 <bluelightning> otavio: ah ok... we should handle that
May 14 13:08:16 <bluelightning> otavio: would you mind filing a bug and assigning it to me?
May 14 13:17:29 <otavio> bluelightning: what is your user in buzilla?
May 14 13:19:08 <bluelightning> otavio: paul.eggleton@linux.intel.com
May 14 13:24:06 <otavio> bluelightning: and I just found a new one ...
May 14 13:25:42 <otavio> bluelightning: I've been using it to merge the layers we use at O.S. Systems and I have done a merge in meta-fsl-arm using the github interface. It always include an empty merge commit at end and combo-layer does handle the apply of it properly however it doesn't move the conf to point to the just applied changeset.
May 14 13:26:42 <otavio> Did you get what I meant?
May 14 13:28:21 <bluelightning> otavio: I think so, but I'm not sure why it would behave that way
May 14 13:28:31 <bluelightning> otavio: I know we don't handle merge commits particularly well
May 14 13:28:48 <otavio> bluelightning: so it end up pointing to the commit before the merge
May 14 13:29:14 <otavio> bluelightning: so in next iteration the diff points to every commit done after the commit in the other tree
May 14 13:29:23 <bluelightning> probably due to what git is reporting when we ask for a revision list I guess
May 14 13:29:34 <otavio> bluelightning: but those might have been applied already... as they were in my case.
May 14 13:29:44 <otavio> bluelightning: yes
May 14 13:30:00 <otavio> bluelightning: the combo-layer.conf ought to point to the merge commit in this case
May 14 13:31:28 <bluelightning> otavio: I agree; getting git to report something sane over a merge commit is quite tricky though :/
May 14 13:32:00 <otavio> bluelightning: for combo-layer to work properly we'll need to figure a way of doing that ...
May 14 13:32:04 <otavio> bluelightning: :)
May 14 13:32:11 <bluelightning> otavio: I'm open to suggestions ;)
May 14 13:32:18 <otavio> bluelightning: but in fact it is not that hard ...
May 14 13:32:22 <bluelightning> after all, the script just calls out to git
May 14 13:32:34 <otavio> bluelightning: as far as I know you check if there's something to commit
May 14 13:32:58 <otavio> bluelightning: it is just the matter of if there's nothing to commit you point to this hash
May 14 13:33:06 <otavio> bluelightning: am I missing something?
May 14 13:36:19 <bluelightning> otavio: I'm not sure I understand what you mean
May 14 13:36:26 <bluelightning> we need to be able to get a sane list of commits
May 14 13:36:46 <otavio> bluelightning: how do you handle empty commits in combo-layer (CL) ?
May 14 13:36:56 <otavio> bluelightning: in CL you do it byhand ?
May 14 13:37:57 <bluelightning> otavio: we skip them IIRC
May 14 13:38:23 <otavio> bluelightning: yes and when skipping you ought to update the hash to it
May 14 13:38:36 <otavio> bluelightning: being empty means it has been applied in CL POV
May 14 13:41:59 <bluelightning> otavio: ah right I see the problem
May 14 13:42:17 <bluelightning> otavio: we use --no-merges and thus the merge commit never enters the list
May 14 13:42:28 <bluelightning> we probably need to update last_revision differently
May 14 13:42:31 <otavio> bluelightning: otherwise it'll call the format-patch with previos the merge commit
May 14 13:42:35 <otavio> bluelightning: yes
May 14 13:49:07 <bluelightning> otavio: if you could file that bug as well please that would be great
May 14 13:52:10 <otavio> bluelightning: just done it; please check if you understand me description there ...
May 14 14:02:14 <bluelightning> otavio: yep, looks OK to me
May 14 14:02:17 <bluelightning> thanks
May 14 14:57:52 <sgw> bluelightning: Did you make any progress on the buildhistory issue on the AB?
May 14 14:58:16 <bluelightning> sgw: I'm unable to log into the autobuilder at the moment
May 14 14:58:36 <bluelightning> sgw: Beth will be fixing it hopefully when she's awake
May 14 14:58:37 <sgw> have you tried to ping halstead?
May 14 14:58:50 <bluelightning> sgw: he says he has no access to the Intel ABs
May 14 14:59:04 <sgw> bluelightning:  is it an issue she can tackle?
May 14 14:59:36 <bluelightning> sgw: probably, I am assuming it's something related to the recent autobuilder movements
May 14 14:59:39 <sgw> bluelightning:  there is a problem with the x86 and x86-64 builds on the extenal machines, not internal
May 14 15:18:45 <chackal_sjc> guys
May 14 15:18:51 <chackal_sjc> how can I change my compiler??
May 14 15:19:02 <fray> morning
May 14 15:19:04 <chackal_sjc> CC=x bitbake foo??
May 14 15:19:15 <fray> the compiler setting is in the bitbake.conf file..
May 14 15:19:20 <exosyst> Hey guys, So I've built a setup for the beaglebone but I've got a lot of uImages (./tmp/sysroots/beaglebone/kernel/uImage, ./tmp/work/beaglebone-poky-linux-gnueabi/linux-ti33x-psp-3.2-r0/git/arch/arm/boot/uImage,./tmp/work/beaglebone-poky-linux-gnueabi/linux-ti33x-psp-3.2-r0/sysroot-destdir/kernel/uImage, ./tmp/work/beaglebone-poky-linux-gnueabi/linux-ti33x-psp-3.2-r0/image/kernel/uImage) which is the correct one with rega
May 14 15:19:20 <exosyst> rds to workflow and what's the purpose of the others/
May 14 15:19:32 <fray> if you want a variable way to set which compiler a package is going to use, you need to override that setting for the specific package..
May 14 15:19:36 <fray> in your local.conf you can do:
May 14 15:19:44 <fray> CC_pn-<recipe> = ....
May 14 15:21:33 <chackal_sjc> fray: ok. how to compile the standard qt that is implemented in yocto?
May 14 15:21:59 <fray> if bitbake qt doesn't work.. then it's a bug.. if you want to change the compiler for that.. then CC_pn-qt = ...
May 14 15:22:15 <fray> (note I havn't actually tried to change the compiler before.. but that should work)
May 14 15:24:04 <chackal_sjc> ok, lemme see
May 14 15:25:36 <bluelightning> the qt recipe isn't called qt - depending on whether you want the x11 or framebuffer-only flavour it's qt4-x11-free or qt4-embedded (respectively)
May 14 15:26:23 <fray> ahh.. ok
May 14 15:27:08 <chackal_sjc> thanks
May 14 15:27:48 <chackal_sjc> how can I see which compiler is yocto using??
May 14 15:27:54 <fray> gcc
May 14 15:27:57 <fray> :)
May 14 15:28:10 <fray> meta/recipes-devtools/gcc/*
May 14 15:28:15 <chackal_sjc> fray: i mean, I want to see which command is yocto currently using
May 14 15:28:32 <fray> bitbake -e <task>  that is all of the variables.. you can search it for CC
May 14 15:29:32 <bluelightning> or, to look at was already run, check TMPDIR/work/*/recipename-version/temp/log.do_compile
May 14 15:30:03 <bluelightning> assuming whatever build system your application uses internally echos the commands it is running
May 14 15:38:28 <chackal_sjc> thanks
May 14 15:46:58 <seebs> Okay, back to the code mines with me.  Quick sanity-check:  I'm trying a set of compiler binaries, and cairo's blowing up (on x86) because it can't use a particular relocation type with an undefined symbol.  This seems like it shouldn't happen, but I am not sure whether to blame the compiler or Something Else.
May 14 15:54:55 <jwessel> seebs: Any time I see a relocation type error I always blame the compiler first.
May 14 15:55:08 <jwessel> And the I go hunting for a work around.
May 14 15:55:28 <fray> I usually see it when an -fpic or -fPIC setting is wrong..
May 14 15:55:32 <fray> but sometimes it's just a compiler error
May 14 15:55:57 <jwessel> Debugging one of those can be as bad as a compiler ICE.
May 14 15:56:24 <fray> yup
May 14 16:06:10 <seebs> Figures.  Well, I'm retrying on PPC in case that fixes it, and if it does, then I will spend roughly the rest of today trying to get a reproducer out of it.
May 14 17:08:28 <seebs> aghh.  I just found the typo in my toolchain sanity checks.
May 14 17:59:42 <kergoth`> hmm, think a recent bitbake change just broke runtime_mapping_rename parsing
May 14 18:01:37 <seebs> So last week, I could build with an rpc-less libc just by tweaking busybox.  Tried again this week after fixing something else, and now portmap is (unsurprisingly) failing to build.
May 14 18:02:03 <seebs> Now the mystery becomes "why didn't that failure bite me last week".  Not to mention "who is telling me I need portmap?"
May 14 18:06:38 <kergoth`> seebs: we should propose dropping portmap in favor of rpcbind, i think. rpcbind is newer, uses libtirpc already, so works without rpc in libc, and supports ipv6, which portmap dosen't
May 14 18:07:13 <fray> Hmm.. I through we were already using rpcbind..  I seem to remember though there was something minor rpcbind didn't support..
May 14 18:07:21 <fray> non-privileged ports maybe?
May 14 18:07:26 <seebs> But think of all the FAQs from the 1990s that would be invalidated if we stopped using portmap!  :P
May 14 18:07:36 <kergoth`> fray: at least one task/image includes *both*
May 14 18:07:45 <kergoth`> so clearly its evolved, not consciously chosen
May 14 18:07:50 <kergoth`> heh
May 14 18:07:54 <seebs> Hmm.  While I am asking about things like variable tracking.
May 14 18:08:14 <seebs> Is there a reasonable way to answer the question "why are you trying to build <foo>, I didn't think I asked for it?"
May 14 18:08:32 <fray> there is an enahcement bug in the yocto project bugzilla to give you the way..
May 14 18:08:36 <fray> 'er.. why
May 14 18:08:50 <kergoth`> seebs: bitbake -g, optionally bitbake -g -u depexp
May 14 18:08:51 <fray> but AFAIK there isn't anything to show you the why, other then look at the actual DEPENDS mapping..
May 14 18:09:03 <seebs> oooh
May 14 18:09:04 <fray> depends mapping is visible using what kergot posted
May 14 18:10:14 <seebs> ... if I am reading this correctly, portmap is included because it is a requirement for portmap.
May 14 18:11:22 <kergoth`> hehe. depexp sucks for runtime dependencies, sadly
May 14 18:11:26 <seebs> The only things I see listing dependencies on portmap are portmat-dbg and portmap-dev.
May 14 18:12:16 <seebs> I'm just wondering about build-time, I think.  I don't care whether the filesystem *runs*.  I just want to exercise the compiler.  :)
May 14 18:12:27 <seebs> And the only listed "reverse depends" for portmap is "portmap".
May 14 18:12:33 <kergoth`> no, you didn't understand what i said
May 14 18:12:45 <kergoth`> bitbake uses runtime dependnecies to figure out what to build
May 14 18:12:48 <seebs> Ahh.
May 14 18:12:48 <kergoth`> not just waht to put in an image
May 14 18:12:54 <seebs> Ahh, I get it.
May 14 18:13:01 <kergoth`> if you rdep on some package, bitbake knows to build the thing tha tprovides that package
May 14 18:13:14 <kergoth`> which is how tasks and iamges work at all without listing everything twice :P
May 14 18:13:32 <seebs> hmm
May 14 18:13:39 <kergoth`> damnit, somehow 74daad03ca29a03b0005f7d2b90a0347d5b583a5 completely hosed my builds, my bitbake is failing to parse mapping_rename_hook, saying the def' line is there twice
May 14 18:13:58 <kergoth`> hrm
May 14 18:14:07 <seebs> Huh.  Well, bitbake -e's output doesn't show any RDEPENDS.*portmap lines.  Hmm.
May 14 18:14:32 <seebs> And I can't grep the tree naively because a lot of packages do RDEPENDS_foo = "\
May 14 18:15:04 <kergoth`> ack --type=bitbake -w portmap shows task-base, task-core-console, task-core-basic, and nfs-utisl
May 14 18:15:09 <kergoth`> took about 2 seconds
May 14 18:15:11 * kergoth` rolls eyes
May 14 18:15:23 <kergoth`> most of which was my parsing the output, nt the actual search
May 14 18:16:07 <seebs> Heh.  I thoughtfully looked at an RDEPENDS line, observed that they were not consistently in a usefully greppable form, and didn't bother to try in case the ones I needed were friendly.
May 14 18:16:30 <seebs> I have a tendency to overthink problems like that.
May 14 18:16:33 <kergoth`> well, how many places do you think use the word 'portmap' other than in dependencies?
May 14 18:16:44 <kergoth`> best to just search rather than assuming the result will be unwieldy
May 14 18:16:49 <seebs> Yeah.
May 14 18:17:16 <seebs> Ooh.
May 14 18:17:31 <seebs> That is a really, really, good insight.
May 14 18:19:13 <seebs> ... and yes, task-core-sys-services has both rpcbind and portmap.
May 14 18:19:20 <kergoth`> not unlike the whole profile before optimization thing. we all tend to suck at guessing about how things will turn out :)
May 14 18:19:30 <kergoth`> how fun and redundant :)
May 14 18:19:33 <seebs> Oh, geeze, tell me about it.
May 14 18:19:48 <seebs> I'm doing a mobile app for recreation, and it wasn't performing well, so I ran it under a profiler.
May 14 18:20:00 <kergoth`> hmm, i don't think i ever got my patch merged to add and use a startups cript for rpcbind
May 14 18:20:04 * kergoth` checks email
May 14 18:20:15 <seebs> Was the largest cost rendering?  No.  Calculating where to draw lines?  No.  It was, by a large margin, "determining which color to use".
May 14 18:20:37 <seebs> Replace the 6-line calculation of a smooth transition between colors with a table lookup, and the app goes from about 30fps to about 40.
May 14 18:20:51 <kergoth`> hah
May 14 18:20:52 <kergoth`> nice
May 14 18:21:34 <kergoth`> hmm
May 14 18:21:47 <kergoth`> i wonder if rpcbind should RPROVIDES_${PN} portmap, given they provide equivalent functionality
May 14 18:21:50 * kergoth` scratches head
May 14 18:22:45 <kergoth`> oh, there it is
May 14 18:22:48 <kergoth`> seebs: https://github.com/kergoth/oe-core/compare/rpcbind
May 14 18:23:21 <kergoth`> knew i remembered doing something abuot that
May 14 18:23:35 <kergoth`> i really need some sort of automagic 'search every git branch of every git repo i have for this work i did' script
May 14 18:23:43 <kergoth`> i'm always forgetting wher ei put things
May 14 18:24:45 <mranostay> morning
May 14 18:25:08 <khem> kergoth`: there is no tool called DWIM
May 14 18:25:16 <kergoth`> hehe
May 14 18:25:34 <khem> and thinking of writing one is a doomed
May 14 18:25:44 <khem> it will be worse than MS products
May 14 18:25:58 <khem> :)
May 14 18:28:06 <kergoth`> https://gist.github.com/dda5da11b8f5a289801a - not pretty, but searches everything i could think of in a given repository for a string
May 14 18:28:10 <kergoth`> hehe
May 14 18:30:02 <seebs> The bright side of working on a Device For Being Soothing in my spare time is that I now *have* one.
May 14 18:31:11 <khem> seebs: what is it ?
May 14 18:31:25 <khem> soothing is nice thing can you ship one to me too
May 14 18:31:57 <seebs> It's an ipod/android app which does Things.  The things are characterized by bright rainbow colors, geometric/mathematical patterns, and bell tones that relate to the patterns.
May 14 18:32:28 <seebs> The responses to it seem to be roughly evenly split between "that's sort of pretty" and "i can never stop looking at this where do i send all my money".
May 14 18:32:47 <khem> wow
May 14 18:33:06 <khem> are you proposing it to android market and apple store
May 14 18:37:10 <seebs> That's the plan.
May 14 18:37:18 <seebs> It's a spare time thing so it's gonna take a while.
May 14 18:37:54 <seebs> Unfortunately, my screen-recording app has a bug right now that loses saturation on thin objects for reasons not obvious to me, although supposedly an update will fix it later.
May 14 18:38:36 <khem> you can make enough money on it. :)
May 14 18:38:40 <khem> and retire
May 14 18:39:11 <seebs> Seems unlikely.  Although if I do, I know what happens after that:  I finally fix pseudo's !*$#!# error messages.
May 14 18:39:18 <seebs> Priorities, I haz them.
May 14 18:39:25 <khem> heh
May 14 18:39:44 <khem> software is like kids you babysit it all its life
May 14 18:41:30 <seebs> Yeah, pretty much.
May 14 18:44:29 <seebs> hah!
May 14 18:44:37 <seebs> I finally managed to get all the nfs/portmap stuff out of my test build.
May 14 18:45:01 <seebs> ... which failed because it couldn't find locale-base-en-us.  But at least I know, now, that this is not only broken in the other tree I was using.  :)
May 14 19:19:16 <seebs> http://www.youtube.com/watch?v=D4gNrgaucgE&feature=youtu.be <-- this is what the gizmo I've been working on looks like, except that the colors are a lot more saturated in the original.
May 14 19:21:31 <fray> is it a high res app?  ;)
May 14 19:22:24 <seebs> Sorta.  It's smoother on retina displays, although it's barely functional on the current-gen ipod touch, because the CPU is way too slow for the higher-rez display.
May 14 19:22:58 <seebs> One of the upcoming steps is adding some benchmark and tuning functionality so it'll try to be at least usable on most devices.
May 14 20:11:28 * mranostay waves to galak_pb 
May 14 20:12:55 <mranostay> kergoth`: so can you override classes in overlays? from what i've seen you can't :/
May 14 20:13:44 <fray> layers?
May 14 20:14:01 <fray> you can replace classes in a layer.. but not append to them
May 14 20:14:28 <fray> there are strategies you can do though to do things "like" append
May 14 20:31:01 <kergoth`> mranostay: as fray says, you can override them just fine, as long as your BBLAYERS is ordered correctly.
May 14 20:44:57 <seebs> ... And now I get errors because libstdc++ won't rebuild because it can't find -lm.  I am just cursed today.  :)
May 14 20:53:03 <jawilson> can I force the udev version from a machine .conf in my BSP?
May 14 20:53:32 <jawilson> I tried PREFERRED_VERSION_udev but it doesn't seem to do anything
May 14 20:54:20 <bluelightning> jawilson: that will work unless your distro already does that
May 14 20:54:32 <bluelightning> it worked for me just yesterday FWIW
May 14 20:55:29 <jawilson> ah, angstrom has it set...
May 14 22:06:51 <_paul> Is it possible to port an android distribution to build under poky? If so, has anyone already done this?
May 14 22:45:03 <zenlinux> I've created a custom image based on core-image-minimal, and when I first booted it I realized I needed the package management tools. So I removed ROOTFS_POSTPROCESS_COMMAND += "remove_packaging_data_files ; " from the image file and rebuilt the image.
May 14 22:45:16 <zenlinux> Thing is, I *still* am not getting the package management tools (rpm in this case)
May 14 22:45:36 <zenlinux> Is there a task I need to clean before rebuilding?
May 14 22:46:50 <khem> zenlinux: why not use core-image-core instead ?
May 14 22:46:57 <khem> if you want OPM
May 14 22:47:09 * zenlinux takes a look at the image def for core-image-core
May 14 22:47:52 <zenlinux> khem, I don't see how that matters. I'm just building an image for testing a command line zigbee stack. I don't even need x11.
May 14 22:48:28 <zenlinux> and I guess I'm not sure what you mean by OPM?
May 14 22:50:00 <incandescant> zenlinux: core-image-minimal doesn't include the package-management IMAGE_FEATURES
May 14 22:50:02 <zenlinux> here's my image recipe: http://pastebin.com/3FVAczgZ
May 14 22:50:14 <incandescant> that's what handles installing the package management tools
May 14 22:50:28 <bluelightning> just what I was about to say ;)
May 14 22:50:49 <zenlinux> are they part of apps-console-core?
May 14 22:50:51 <ant__> khem: by chance pls give a look at meta-initramfs/recipes-devtools/klibc status
May 14 22:51:06 <bluelightning> zenlinux: no, it's called package-management
May 14 22:51:47 <zenlinux> thanks, I think that brings my clue factor back to sustainable levels. :)
May 14 22:52:09 <incandescant> it's part of ENHANCED_IMAGE_FEATURES and X11_IMAGE_FEATURES
May 14 22:52:29 <incandescant> which is how most of our images get it, IMAGE_FEATURES += "package-management" will do
May 14 22:52:49 <zenlinux> I guess I just needed to dig further down into X11_IMAGE_FEATURES, I took that at face value to mean "X11 image features" :-/
May 14 22:53:00 <bluelightning> some of that stuff is heinously overcomplicated :/
May 14 22:53:20 <incandescant> and badly named
May 14 22:53:50 <zenlinux> In fact I don't really see why X11 features and package-management features should be coupled this way. We should probably separate them more explicitly in the image definitions.
May 14 22:54:07 <incandescant> agreed
May 14 22:54:14 <incandescant> did you just volunteer? :-)
May 14 22:54:20 <zenlinux> yeah, yeah....
May 14 22:54:23 * zenlinux goes to file a bug
May 14 22:54:37 <incandescant> it's one of those things that always falls off peoples' lists
May 14 22:58:10 <khem> well you just need a X'less image with OPM which does not exist in OE-Core so create one is another option
May 14 22:58:23 <khem> core-image-minimal is minimal as it sounds
May 14 23:00:00 <zenlinux> https://bugzilla.yoctoproject.org/show_bug.cgi?id=2458
May 14 23:00:28 <ant__> well, for a bit more size you get core-image-base
May 14 23:03:41 <ant__> more than 'a bit', 4.5M -> 13M for rootfs.tar.gz
May 14 23:15:40 <fray> more discrete apps
May 14 23:32:59 <halstead> We are having some routing issues to autobuilder.yoctoproject.org. I'm currently investigating.
May 14 23:52:45 <halstead> Downloads from downloads.yoctoproject.org  are temporarily interrupted during router config.
May 15 00:08:17 <halstead> All back online.
May 15 02:07:32 <seebs> Is there anything comparable to a FOO_subtract operator, which removes a specified word?
May 15 02:08:05 <seebs> There exists a list which, for various reasons, I want to remove a single word from.  And it's a ?=, so I can just duplicate it and remove the word, but that strikes me as likely error-prone.
May 15 02:12:31 <kergoth`> no, there's no -= or equivalent, you'd have to use anonymous python or similar
May 15 02:12:42 <kergoth`> e.g. := + oe_filter_out
May 15 02:29:49 <seebs> I might have a look at that.  I want to cleanly strip libc-sunrpc from the huge libc feature list.
May 15 02:30:04 <seebs> Of course, this will stop being relevant "soon" when we get an updated toolchain that has it again.
May 15 02:30:24 <seebs> Prediction:  About a year or two from now, this exact same issue will turn up, and it will turn out that no one ever got around to a clean fix.
**** ENDING LOGGING AT Tue May 15 02:59:59 2012

**** BEGIN LOGGING AT Tue May 15 02:59:59 2012
May 15 08:10:22 <mckoan> good morning
May 15 09:19:08 <exosyst> I'm after some advice, I've got all my deployable images for a beaglebone and set it up to boot via tftp and NFS - if I want to reconfig/recompile the kernel then what's the best way to do it? Should i be exporting flags and using generated toolchains etc? Is this sort of thing already covered somewhere?
May 15 09:21:41 <bluelightning> hi all
May 15 09:31:50 <halstead> hi bluelightning.
May 15 09:32:01 <bluelightning> hi halstead
May 15 09:32:04 <halstead> Switching to the new download server.
May 15 09:32:19 <halstead> http://packages.yoctoproject.org/ is temporarily down.
May 15 09:39:23 <bluelightning> halstead: ok, thanks
May 15 10:07:11 <exosyst> Are there any docs on working within a Yocto build to reconfig/recompile the kernel?
May 15 10:24:08 <bluelightning> exosyst: I believe we have some kernel dev documentation yes
May 15 10:24:31 <bluelightning> exosyst: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#configuring-the-kernel
May 15 10:27:30 <exosyst> bluelightning, thanks - I have it open to read but am working my way through an understanding of layers. I think it will be good once I have all this to write it into my course notes. I want something clean and easy for the delegates!
May 15 10:56:07 <Hubert_> is there a way to build image for old pc using yocto? by old i mean sth like i486
May 15 10:56:26 <Hubert_> i googled a lot and didnt find any clue
May 15 10:57:32 <Hubert_> is this possible to achieve with yocto? i want to keep it extreme minimal so there is hard to find distribution for this purpose
May 15 11:00:12 <B4gder> I can't see why it wouldn't
May 15 11:06:06 <Hubert_> so could you point me a direction what to do? in conf/local.conf there are machines like beagleboard etc and qemu's but no x86
May 15 11:08:30 <Hubert_> i found some information about "tune files" and even created one for i486 (based on i586 file) but still dont know how to build image with it
May 15 13:06:07 <bluelightning> Hubert_: you would need to create a machine .conf file for the machine which "require"s the tune file you created and sets anything else appropriate for the machine
May 15 13:06:37 <bluelightning> Hubert_: have a look at some of the files in conf/machine in the meta-intel layer for examples
May 15 13:31:56 <exosyst> Hubert_, I'm not massively familiar with Yocto but the docs are pretty good (thought there's a lot and could do with more quick start/cookbook style docs!) and this could be a useful resource for what you want http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#dev-manual-bsp-appendix
May 15 15:43:55 <xumbi> greetings!  I'm trying to move to poky 7.0, I have an image recipe with some SRC_URI files/folders that I pull in at image creation time, it worked fine in 6.0, but now it doesn't look like anything in SRC_URI is being pulled into ${WORKDIR}
May 15 15:45:47 <zeddii> nicknames said out loud .. just never sound quite right :P
May 15 15:48:23 <halstead> darknighte, https://wiki.yoctoproject.org/wiki/Bugzilla_Category_Change
May 15 15:49:24 <darknighte> halstead: thanks
May 15 15:51:50 <halstead> darknighte, I added lines so it's slightly more readable.
May 15 15:52:13 <darknighte> halstead: ahh, thanks, much better.
May 15 15:55:19 <ant_work> zeddii: hi there. I'll have now to manage fragments. Question: wouldn't it be possible to have an output file containing a 'suggested' machine.cfg? We already know the non-hw options and those could be easily pruned out.
May 15 15:56:09 <ant_work> zeddii: a solution for the lazy, that is :)
May 15 16:02:40 <zeddii> ant_work, scripts external to the build process can do that. I've had a few here in the past. It's just a matter of taking those generated reports and deciding if you want to prune what it is telling you :)
May 15 16:05:11 <ant_work> zeddii: I'd have to convert a bulk of (ipaq) machines...I was thinking about a mega-sed in a new task
May 15 16:09:50 <zeddii> I just don't like it buried into the build. It's a script that can be called, but only on demand.
May 15 16:10:09 <zeddii> I can dust off what I have around here.
May 15 16:29:46 <ant_work> zeddii: great, thx. It is just to do the monkey transition to linux-yocto for a bunch of (bitrotted) machines
May 15 16:29:59 <ant_work> bluelightning: ^^
May 15 16:31:01 <ant_work> bluelightning: maybe we should set a policy in meta-handheld layer
May 15 16:31:46 <zeddii> np. I'll definitely dig it up.
May 15 16:32:49 <ant_work> zeddii: what I didn't discover yet are the bindings btw machine features and kernel features/frags
May 15 16:34:02 <ant_work> zeddii: let say we expect the machines able to boot ext2,3,4 ubifs jffs2 fat/vfat from nand/sd/cf/usb
May 15 16:34:33 <ant_work> this common blocks could be part of a layer policy
May 15 17:48:04 <kergoth`> alias bback='ack --type=bitbake' is so handy
May 15 17:48:43 <seebs> Okay, idle question.  Right now, there is a DISTRO_FEATURES_LIBC_DEFAULT ?= "big list of features".
May 15 17:49:09 <seebs> I am unable to see a way to set DISTRO_FEATURES_LIBC to "all but one of those features" without just duplicating that line.
May 15 17:50:28 <seebs> The relevant feature is libc-sunrpc, which as people may have heard is not consistently present in newer glibc.  I am wondering whether it might make sense to just remove it from DISTRO_FEATURES_LIBC_DEFAULT, on the grounds that later setup code automatically re-adds it anyway.
May 15 17:50:49 <seebs> At which point we could add a bit more smarts to that so it would only get added if it were correct.
May 15 18:18:02 <RP__> seebs: grep for filter_out
May 15 18:18:37 <seebs> hmm
May 15 18:21:02 <seebs> That seems to be always used in a :=.  Given my success rate at comprehending bitbake assignments, what is the sequencing/meaning of :=?  I note at least one use of CXXFLAGS := @oe_filter_out(... ${CXXFLAGS}...), so I assume it is processed sometime after other assignments?
May 15 18:21:26 <seebs> I really ought to know this after working on the variable tracking, but mostly what I took in from that is that variable assignment is probably turing-complete.
May 15 18:22:23 <kergoth`> := forces immediate expansion, which resolves the recursion issue by ensuring it uses the previous value
May 15 18:23:40 <kergoth`> course, if we did some sort of SSA type thing, we'd be ablet o handle that without requiring :=, but..
May 15 18:23:44 <kergoth`> heh
May 15 18:27:41 <exosyst> Where's the toolchain from a Yocto build stored? Should I be able to use it to rebuild the kernel after a reconfig? is it a case of ARCH=arm MACH=beaglebone PATH=$PATH:/path/to/cross-compiled tools make menuconfig?
May 15 18:28:49 <kergoth`> you should use devshell or the menuconfig task
May 15 18:30:00 <exosyst> kergoth`, I know I can do it that way, but I want to teach students on how to use the normal make menuconfig && make && make uImage style.
May 15 18:31:13 <exosyst> seebs, I found this really useful when trying to grep it all http://docs.openembedded.org/bitbake/html/
May 15 18:31:57 <seebs> Hmm.  Problem is, I am pretty sure my include file is processed before the ?= that sets the default values.
May 15 18:34:25 <kergoth`> exosyst: then you need to pass CROSS_COMPILE= to the make. also, ARCH= should be passed on the make line as well
May 15 18:34:38 <kergoth`> make ARCH=arm CROSS_COMPILE=/path/to/toolchain/bin/arm-linux-
May 15 18:34:40 <kergoth`> or whatever
May 15 18:35:08 <kergoth`> seebs: could use anonymous python, that runs at RecipeParsed time
May 15 18:35:21 <kergoth`> or a ConfigParsed event handler
May 15 18:38:02 <seebs> Hmm.
May 15 18:38:40 <kergoth`> getVar, remove, setVar
May 15 18:38:41 <kergoth`> heh
May 15 18:39:01 <kergoth`> ConfigParsed would be ideal, since that occurs only once, at the end of the bitbake.conf + INHERIT parsing
May 15 18:39:07 <seebs> Okay, idle thought:  How would people feel about a proposed FOO_subtract being implemented?  It's not gonna affect my immediate plans, but I think it'd be useful.
May 15 18:39:19 <kergoth`> if it was trivial, we'd have implemented it already :P
May 15 18:39:24 <kergoth`> someone asks about it every couple months
May 15 18:39:24 <chackal_sjc> hey guys
May 15 18:39:42 <kergoth`> but you're welcome to, there's obvious interest
May 15 18:39:47 <seebs> Ahh, wasn't saying it'd be *trivial*.  But I think I know enough from the variable tracking I already did that I could do it.
May 15 18:39:48 <chackal_sjc> how can I choose the cross compilers, likers and everythong else?
May 15 18:40:02 <kergoth`> seebs: and how will it interact with expansion?
May 15 18:40:16 <kergoth`> if i have FOO = "${BAR}" and "subtract" 'baz', does that expand bar first?
May 15 18:40:17 <chackal_sjc> because I don't want to use the arm-yocto-gnueabi*
May 15 18:40:31 <kergoth`> chackal_sjc: huh?
May 15 18:40:34 <seebs> That is an interesting question.  My theory was to do it after the _append values.
May 15 18:40:48 <kergoth`> thats a fine time to do it, but doesn't answer the question
May 15 18:40:54 <kergoth`> the trouble is determining what's intuitive to the user
May 15 18:41:13 <chackal_sjc> kergoth`: sorry, arm-poky-gnueabi-*
May 15 18:41:24 <seebs> Ohhh.  Because, as I just remembered, appends don't actually imply full expansion.
May 15 18:41:33 <kergoth`> chackal_sjc: still not making sense. you always use the prefixed binaries from a crosscompiler
May 15 18:41:40 <exosyst> kergoth`, Where does the cross-compiled gcc get thrown out to? is is names arm-poky-* or arm-yocto-* or arm-linux-*
May 15 18:41:50 <kergoth`> huh?
May 15 18:42:09 <kergoth`> it doesn't get 'thrown out' at all. the toolchain internally used by a bitbake build is not intended to be deployed elsewhere. use meta-toolchain if you want that
May 15 18:42:30 <kergoth`> you can poke into the sysroots and run the binaries, but it's not intended to go anywhere else
May 15 18:42:57 <exosyst> kergoth`, Oh right, sorry I misunderstood. Is there docs on how to use the meta-toolchain?
May 15 18:43:15 <chackal_sjc> kergoth`: I know.. but I want to compile with our compiler..
May 15 18:43:19 <kergoth`> honestly don't know. it's a recipe that produces a tarball/archive with a standalone toolchain
May 15 18:43:41 <kergoth`> chackal_sjc: if you're not using oe/yocto stuff, why are you even asking in here?
May 15 18:43:51 <kergoth`> this channel isn't here to cover how to crosscompile a kernelw ith a random toolchain
May 15 18:44:32 <chackal_sjc> kergoth`: I know.. i just want to know if its possible to use the yocto infrastructure with other toolchain
May 15 18:44:44 <chackal_sjc> or oe, perhaps
May 15 18:44:46 <kergoth`> that doesn't make sense.
May 15 18:44:47 <seebs> It can be, yes.  See the external-csl stuff for an example.
May 15 18:44:56 <seebs> At least I think that's an answer to your question.
May 15 18:45:32 <chackal_sjc> kergoth`: why it doesn't make sense? actually my toolchain is just a different compiler set
May 15 18:45:34 <kergoth`> its worht pointing out that its a global, configuration level decision whether to use an internally built or external toolchain, not particular to any individual recipe like your kernel
May 15 18:45:51 <kergoth`> and the only external toolchain supported by yocto right now is sourcery g++ / codesourcery
May 15 18:45:53 <seebs> Okay, thinking about the intuitive intent of a FOO_subtract or FOO_remove feature.  I have concluded that the intuitively-obvious thing is to remove before expansion if the string contains a $, and after expansion otherwise.  But it occurs to me that you could just do both.
May 15 18:46:08 <seebs> And I don't think that'd break anything for either case.
May 15 18:46:34 <kergoth`> there will be cases where that'll break expectations, i suspect
May 15 18:46:36 <seebs> Yeah.
May 15 18:46:53 <kergoth`> as a user, i don't necessarily know how many indirections are involved in a given variable
May 15 18:46:58 <seebs> Okay, what if FOO_subtract itself subject to expansion, and then is run after expansion.
May 15 18:47:03 <kergoth`> which means i won't know to remove from the variable twice removed
May 15 18:47:05 <kergoth`> rather than the main one
May 15 18:47:19 <seebs> So if you write FOO_subtract = "${BAR}", we fully expand ${BAR}, and then subtract the resulting list from the fully expanded ${FOO}.
May 15 18:47:41 <kergoth`> okay, now another one.
May 15 18:47:45 <kergoth`> FOO = "alpha beta"
May 15 18:47:50 <kergoth`> FOO_subtract = "beta alpha"
May 15 18:47:52 <kergoth`> what does that do?
May 15 18:48:01 <kergoth`> :)
May 15 18:48:04 <seebs> I *think* the right answer is "FOO is now empty".
May 15 18:48:06 <chackal_sjc> kergoth`: I'm using this one here https://sourcery.mentor.com/sgpp/lite/arm/portal/release858
May 15 18:48:11 <kergoth`> i'd think so too
May 15 18:48:23 <seebs> Because the things where we append/subtract are all lists that are being used as sets, for "if foo in bar" tests.
May 15 18:48:30 <kergoth`> chackal_sjc: TCMODE = "external-csl" EXTERNAL_TOOLCHAIN = "/path/to/toolchain/install" in local.conf
May 15 18:48:33 <kergoth`> two lines, obviously
May 15 18:49:15 <chackal_sjc> EXTERNAL_TOOLCHAIN would be the bin dir?
May 15 18:49:22 <kergoth`> seebs: and god help you if there are any unexpected spaces anywhere :) but i agree, it makes sense to do that, i just think we need to carefully consider a variety of cases
May 15 18:49:26 <kergoth`> chackal_sjc: no, the root of the toolchain
May 15 18:49:28 <kergoth`> not root/bin
May 15 18:49:38 <kergoth`> it needsm ore than just binaries
May 15 18:49:41 <seebs> Well, Python's .split() is pretty good about doing what I think we want.
May 15 18:49:49 <kergoth`> it has to extract the c library and headers from the toolchain to create packges for the target
May 15 18:49:55 <exosyst> kergoth`, I think what I'm looking for is meta-toolchain-sdk - if anyone can confirm before I spend some cycles that'd be cool
May 15 18:49:59 <chackal_sjc> ok\
May 15 18:50:06 <seebs> Proposal:  Next time I have some idle loops, I'll implement it as described and see how horrifically it explodes in my face.
May 15 18:50:15 <kergoth`> exosyst: i suspect you're right, but sadly i'm not the experton it, hopefully someone else in here will jump in
May 15 18:50:16 <seebs> I'll also send an RFC out to the list with a discussion of the proposed semantics.
May 15 18:51:19 <kergoth`> seebs: might potentially be worthwhile to encode those semantics into unit tests
May 15 18:51:31 <kergoth`> like the ones richard resurrected and pulled from my ref tracking code for the datasmart object
May 15 18:51:46 <kergoth`> if not that, at least in the commit messages :)
May 15 18:51:48 <kergoth`> but worth thinking about
May 15 18:52:40 <kergoth`> also, an immediate -= would be nice, but that's impliciations are even more confusing due to potential implicatiosn of early forced expansions
May 15 18:52:52 <kergoth`> heh
May 15 18:53:06 <seebs> Yeah, I thought about it and concluded that it was Too Crazy.  Also too likely to not do what you mean.
May 15 18:53:25 <seebs> Observation:  If you are trying to override something's behavior, you are probably getting parsed first at least some of the time, meaning your -= will be hit before their +=.
May 15 18:53:39 <kergoth`> part of me wants to say "if you want to do something at the end of the parse, then write an event handler, and make not just _subtract but also _prepend and _append DIAF)
May 15 18:53:43 <kergoth`> s/)/"/
May 15 18:54:19 <seebs> The only thing worse than writing this dodgy code for the _subtract case would be having multiple people write it incorrectly.  :)
May 15 18:54:33 <chackal_sjc>  I have a kernel from a local git.. what step I need to make to select this kernel?
May 15 18:54:36 <seebs> Basically, I think it's ugly, but it's a kind of ugly that people will want repeatedly.
May 15 18:54:50 <kergoth`> seebs: alternatively, just write a method on datasmart for it.
May 15 18:54:56 <seebs> Hmm.
May 15 18:55:01 <kergoth`> :)
May 15 18:55:06 * kergoth` ponders
May 15 18:55:29 <kergoth`> chackal_sjc: read the documentation on creation of bsps on the yocto site
May 15 18:55:48 <chackal_sjc> kergoth`: yeah,, ok
May 15 18:56:07 <kergoth`> such a method would probably be a good idea regardless of whether you implement an _subtract, even if all it does is some splitting, removal, and re-concatenating
May 15 18:56:13 <kergoth`> heh
May 15 18:59:31 <seebs> Agreed.
May 15 18:59:49 <RP__> More methods on the datasmart object would probably be a good thing
May 15 18:59:57 <RP__> we should use appendVar more
May 15 18:59:59 <kergoth`> appendVar <3
May 15 19:00:01 <kergoth`> RP__: :)
May 15 19:00:24 <kergoth`> RP__: i think 50% of the time i use appendVar I forget the leading space, though :)
May 15 19:01:00 <RP__> kergoth`: That is annoying. I wonder if we should have a named parameter for that...
May 15 19:01:26 <RP__> kergoth`: Took me a while to conclude without space was a better default since its easy enough to add, major pain to remove
May 15 19:02:07 <RP__> of course using the named parameter will take many more keystrokes than adding the space in the first place
May 15 19:02:55 <incandescant> IMHO whitespace at the beginning of a string often looks like a typo, the named parameter is more explicit of the authors intent
May 15 19:04:28 <RP__> raises the question about typing in the core...
May 15 19:05:13 <incandescant> adding the oe_types stuff to BB? That would be marvellous
May 15 19:12:19 <fray> looking for a python clue..  I have a string  /foo/bar/foobar.. I want to remove /foo/bar from it.. when is the easiest way?
May 15 19:14:35 <incandescant> do you just want os.basename?
May 15 19:15:49 <fray> nope..
May 15 19:15:51 <fray> I need to remove it..
May 15 19:15:57 <fray> case is:
May 15 19:16:08 <fray> I've got a link I'm generating.. I know the user wants it to go from A -> B
May 15 19:16:09 <RP__> fray: xxx.split(yyy)[1]
May 15 19:16:32 <fray> I can do the basename of A.. and then if it leaves only the last element in B.. the link will be eaiser..
May 15 19:17:21 <RP__> fray: "/foo/bar/foobar".split("/foo/bar")[1] will do what you want. Its ugly but...
May 15 19:17:21 <fray> (I'm not trying to make it a complicated relative link like ../bin/foobar... but handle the obvious case..
May 15 19:18:21 <fray> so something like:  "/foo/bar/foobar".split("/foo/bar" + "/")[1] -- then check for a '/' is the result.. if no '/' then we know we're in the same directory and can make a relative link..
May 15 19:18:26 <fray> my reasoning seem sane?
May 15 19:18:50 <kergoth`> value[len(prefix_to_remove):] can be useful as well, if also not pretty
May 15 19:18:54 * kergoth` yawns
May 15 19:18:57 <kergoth`> split is clearly better for paths
May 15 19:19:36 <RP__> fray: I think so
May 15 19:19:50 <fray> before I do this, checking on the update-alternatives documentation.....
May 15 19:21:00 <kergoth`> does our relative link generator not handle this case sanely?
May 15 19:22:36 <fray> that is why I asked, do we have such a thing, if so where?
May 15 19:23:32 <kergoth`> oe.path
May 15 19:23:33 <kergoth`> iirc
May 15 19:23:45 <kergoth`> oe.path.relative()
May 15 19:23:51 <kergoth`> uses os.path.commonprefix()
May 15 19:24:13 <kergoth`> interestingly, make_relative_symlink doesn't actually use the relative path generator
May 15 19:24:16 <kergoth`> dose its own thing
May 15 19:24:23 <fray> I'll try it and see if it does what I want
May 15 19:24:49 <fray> seems like it might be good to update it then.. :)  (and I can't use that because update-alternatives is what is going to generate hte link)
May 15 19:24:51 <kergoth`> actually, os.path has relpath() nowadays, though i'm not sure what python version added it
May 15 19:25:03 <fray> I -think- it was 2.7, but not sure
May 15 19:25:41 * kergoth` checks release notes
May 15 19:25:54 <kergoth`> ah, there ti is
May 15 19:25:55 <kergoth`> it was added in 2.6
May 15 19:26:05 <kergoth`> so we shouldn't need to reimplement that anymore, unlses its flawed
May 15 19:26:08 <fray> ahh so we would be good
May 15 19:26:11 <kergoth`> yep
May 15 19:26:24 <fray> some of these actually check on the disk.. and in all of the cases I'm working, there is no actual files on the disks to check
May 15 19:26:25 * kergoth` thought he remembered that we'd be able to drop relative() at some point in the future, but forgot when :)
May 15 19:26:45 <kergoth`> gotcha. thats why relative() existed, to be general. not sure about the os.path one yet
May 15 19:27:16 <kergoth`> heh
May 15 19:27:21 <kergoth`> relpath() is a loot like our relative()
May 15 19:27:25 <kergoth`> in the implemetntation
May 15 19:27:30 <fray> Hmm it didn't work
May 15 19:27:41 <kergoth`> doesn't touch disk, from what i can tell
May 15 19:27:57 <kergoth`> course thats the 2.7 sources i was reading, not 2.6
May 15 19:28:06 <fray> alt_link = /usr/bin/rz  ;  alt_target = "/usr/bin/lsz"
May 15 19:28:17 <fray> os.path.relative(alt_link, alt_target) == ../lrz
May 15 19:28:28 <fray> (typo alt_target = /usr/bin/lrz)
May 15 19:28:33 <RP__> kergoth`: I was wondering if we should default to 2.7 now...
May 15 19:28:48 <kergoth`> fray: it assumes the second argument is a directory, afaict
May 15 19:28:53 <kergoth`> so it has to back out of that
May 15 19:28:57 <kergoth`> use dirname() on the second arg
May 15 19:29:14 <fray> ahh
May 15 19:29:15 <kergoth`> should take care of it
May 15 19:29:16 <kergoth`> does here
May 15 19:29:45 <kergoth`> RP__: would be nice to use check_output() and the like, but i'm not sure how many distros are still using 2.6 by default..
May 15 19:29:48 <kergoth`> heh
May 15 19:30:06 <RP__> kergoth`: your comment about that made me wonder. We always have the external python tarball
May 15 19:30:38 <kergoth`> fray: heh, i didn't notice that, our relative() implementation calls os.path.relpath if it exists :)
May 15 19:30:41 <kergoth`> hmm, true
May 15 19:30:53 <fray> nice
May 15 19:32:36 <fray> Hmm still didn't work.. I got '..' this time
May 15 19:32:43 <fray> trying once more..
May 15 19:33:25 <kergoth`> >>> os.path.relpath("/usr/bin/lsz", os.path.dirname("/usr/bin/rz"))
May 15 19:33:25 <kergoth`> 'lsz
May 15 19:33:28 <kergoth`> '
May 15 19:33:30 * kergoth` shrugs
May 15 19:34:05 <kergoth`> what you're pointing at has to be the first argument, remember :)
May 15 19:35:53 <fray> NOTE: oe.path.relative(/usr/bin/lrz, os.path.dirname(/usr/bin/rz) - /usr/bin) = ..
May 15 19:36:21 <fray> I'll try the os.path.relpath
May 15 19:37:07 <kergoth`> hmm
May 15 19:37:19 <fray> NOTE: os.path.relpath(/usr/bin/lrz, os.path.dirname(/usr/bin/rz) - /usr/bin) = lrz
May 15 19:37:30 <fray> so os.path.relpath works, but oe.path.relative doesn't..
May 15 19:37:34 <fray> it seems to always be "off"
May 15 19:37:44 <fray> argument order or?
May 15 19:37:57 <kergoth`> relative() uses opposite argument order. src, dest, not dest, src
May 15 19:38:05 <kergoth`> it flips back when callig relpath, if you look at the code
May 15 19:39:08 <fray> NOTE: os.path.relpath(/usr/bin/lrz, os.path.dirname(/usr/bin/rz) - /usr/bin) = lrz
May 15 19:39:08 <fray> NOTE: oe.path.relative(os.path.dirname(/usr/bin/rz) - /usr/bin, /usr/bin/lrz) = ..
May 15 19:39:43 * kergoth` shrugs
May 15 19:39:52 <fray> wait.. my mistake..
May 15 19:40:28 <fray> there we go..
May 15 19:40:32 <fray> NOTE: os.path.relpath(/usr/bin/lrz, os.path.dirname(/usr/bin/rz) - /usr/bin) = lrz
May 15 19:40:32 <fray> NOTE: oe.path.relative(os.path.dirname(/usr/bin/rz) - /usr/bin, /usr/bin/lrz) = lrz
May 15 19:40:41 <fray> ok.. it -does- work.. but as you said order it different
May 15 19:41:01 <fray> so, is there a preference into which one I use?
May 15 19:41:36 <kergoth`> might as well use relpath, it's built into 2.6. we should probably deprecate relative()
May 15 19:42:01 <fray> (BTW I only found one user in classes of relative(), and that looked like a wrapper..)
May 15 19:43:02 <RP__> agreed, good time to clean things like this up
May 15 19:54:37 <Adam_> Hi everyone, I have a question about distributing my own linux distro
May 15 19:55:14 <Adam_> When I bitbake my build, I must use PACKAGE_DEB, rather than the default PACKAGE_RPM
May 15 19:56:37 <Adam_> And that's ok, except I want to set that parameter in my own console-image.bb file, and not in the local.conf
May 15 19:56:51 <fray> deb style is least used, so may have issues.. if you find/fix any problems we would like the patches..
May 15 19:57:17 <fray> thats the wrong place to set it.. you should be setting it in your distribution .conf or in the local.conf (or some other .conf)
May 15 19:57:25 <Adam_> hm actually deb style works for me. It is rpm that doesn't work
May 15 19:57:34 <fray> ok, what doesn't work with RPM?
May 15 19:57:35 <Adam_> I see
May 15 19:57:45 <Adam_> can you tell me where that .conf is located in my distribution
May 15 19:57:57 <Adam_> ok hold on i will show you the error message
May 15 19:58:04 <fray> local.conf, as well as the files causes to be loaded..
May 15 19:58:17 <fray> if you are using yocto, look for poky.conf  that is an example of a distribution .conf file
May 15 19:59:19 <Adam_> I see that sounds great. Now I wouldn't have to set that parameter at all if I get rid of the following error
May 15 19:59:21 <Adam_> error: Failed dependencies:         /home/adam/Code/yocto/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/ckermit-211-r3/image/usr/bin/kermit is needed by ckermit-211-r3.armv7a
May 15 19:59:43 <fray> the ckermit-211-r3 package has a dependency on that full path..
May 15 19:59:48 <fray> something is there is broken w/o it
May 15 19:59:50 <Adam_> so it is the ckermit-211-r3.armv7a.rpm
May 15 20:00:07 <fray> the same think will be broken w/ ipkg or deb.. they just don't have the internal dependencies to notice the breakage
May 15 20:00:14 <Adam_> yes i checked the dependency of that package with rpm -qr and it indeed has the full path
May 15 20:00:22 <Adam_> oh..
May 15 20:00:26 <Adam_> ok that's not good
May 15 20:00:28 <fray> most likely it's a bad symlink or a shell script w/ a #! thats bad
May 15 20:00:34 <Adam_> the file exists in that path however
May 15 20:00:52 <Adam_> do you know where that shell script would be?
May 15 20:01:10 <fray> rpm -q <package> --filerequires
May 15 20:01:16 <fray> that should tell you where the dep came from
May 15 20:01:46 <Adam_> ohoh
May 15 20:01:58 <Adam_> yes that's what i did, and it lists that full path along with others
May 15 20:02:23 <fray> sorry it's rpm -qp ...
May 15 20:02:35 <Adam_> hmm yes I think that's what i did haha
May 15 20:02:39 <fray> rpm -qp x86_64/bash-4.2-r2.x86_64.rpm --filerequire
May 15 20:02:48 <fray> Hmm ok.. that didn't output what I thought
May 15 20:03:19 <Adam_> oh
May 15 20:03:36 <Adam_> so i run that rpm -qp command on the bash package?
May 15 20:03:46 <Adam_> not on the ckermit?
May 15 20:03:46 <fray> give me a sec.. I need to find the right command.. it's not working for me
May 15 20:03:58 <Adam_> alright thanks fray
May 15 20:04:41 <fray> I forgot, we're not laoding it that way.. Hmm.
May 15 20:04:47 <fray> you'll have to look in your tmp directory..
May 15 20:05:03 <fray> i.e. build/tmp-eglibc/work/x86_64-oe-linux/bash-4.2-r2
May 15 20:05:08 <fray> look at bash.requires and bash.provides
May 15 20:05:18 <fray> "/home/mhatle/git/oss/oe-core/build-ia32-4/tmp-eglibc/work/x86_64-oe-linux/bash-4.2-r2/package/bin/bashbug" : "/bin/sh ",
May 15 20:05:27 <fray> that is saying bashbug requires /bin/sh
May 15 20:05:50 <Adam_> ok one sec
May 15 20:05:50 * fray makes a note to try to remember to fix the filerequire/fileprovide
May 15 20:07:14 <RP__> We should have a hard error on full build system paths in a #! line
May 15 20:07:46 <RP__> i.e. not defer that problem to rootfs construction, we can do better...
May 15 20:08:17 <Adam_> from bash.requires
May 15 20:08:17 <Adam_> "/home/adam/Code/yocto/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/bash-4.2-r2/package/bin/bashbug" : "/bin/sh ",
May 15 20:08:35 <Adam_> bash.provides does not have any deps listed
May 15 20:08:44 <fray> that would be correct
May 15 20:08:48 <Adam_> hmmm
May 15 20:08:58 <fray> now use that same thing, find the ckermit package and look at ckermit.requires
May 15 20:09:12 <Adam_> ohh
May 15 20:09:14 <Adam_> before we go on
May 15 20:09:20 <Adam_> yesterday i did sudo mv /bin/sh /bin/sh.bak sudo ln -s /bin/bash /bin/sh
May 15 20:09:33 <Adam_> on my system because i was getting Bad FD Number errorrs
May 15 20:09:43 <Adam_> i followed http://ubuntuforums.org/showthread.php?t=382548
May 15 20:09:53 <Adam_> do you think this may have caused the problem?
May 15 20:10:07 <fray> says I don't have permission to view that
May 15 20:10:41 <fray> but dash should work.. if you find cases where it doesn't.. please file bug(s) on bugzilla.yoctoproject.org with as much ifnormation as you can..
May 15 20:11:15 <Adam_> hm in the ckermit directory, i don't see any provides or requires files
May 15 20:11:49 <fray> you may need to bitbake -c cleansstate ckermit ; bitbake ckermit and reconstruct them...
May 15 20:11:59 <Adam_> deploy-debs  deploy-rpms  license-destdir  package  packages-split  pkgdata  pseudo  shlibs  sstate-install-deploy-rpm  sstate-install-package  temp
May 15 20:12:00 <fray> they are temporary files and disappear if you are using the ccache
May 15 20:12:03 <Adam_> oh let me try that
May 15 20:12:04 <Adam_> ok
May 15 20:12:11 <fray> 'er..sstate cache.. not ccache
May 15 20:15:18 <Adam_> ok i changed back to PACKAGE_RPM, then cleaned and rebuilt ckermit
May 15 20:15:28 <Adam_> i still don't see any .requires or .provides
May 15 20:15:44 <Adam_> =(
May 15 20:16:44 <Adam_> here is what i see in the directory
May 15 20:16:45 <Adam_> deploy-rpms  license-destdir  package  packages-split  pkgdata  pseudo  shlibs  sstate-install-deploy-rpm  sstate-install-package  sysroot-destdir  temp
May 15 20:16:58 <Adam_> i searched recursively, no .requires
May 15 20:17:15 <fray> you need to make sure you run bitbake -c cleansstate ckermit first
May 15 20:17:31 <fray> the cleansstate resets things so it will generate the files from scratch
May 15 20:17:51 <Adam_> ERROR: Task do_cleanstate does not exist for target ckermit
May 15 20:17:58 <Adam_> so i just used clean
May 15 20:18:00 <Adam_> not cleanstate
May 15 20:18:10 <fray> two ss's
May 15 20:18:10 <Adam_> ohh itls cleansstate
May 15 20:19:21 <Adam_> awesome i have .requires and .provides
May 15 20:19:38 <Adam_> ok i have that path in .requires
May 15 20:19:56 <Adam_> "/home/adam/Code/yocto/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/ckermit-211-r3/package/usr/bin/kermit" : "rtld(GNU_HASH) libc.so.6(GLIBC_2.7) libc.so.6 libc.so.6(GLIBC_2.4) ",
May 15 20:20:12 <Adam_> but there is no bash
May 15 20:20:46 <Adam_> i mean sh listed
May 15 20:20:56 <fray> there should be more lines that that one?
May 15 20:21:22 <Adam_> "/home/adam/Code/yocto/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/ckermit-211-r3/package/usr/bin/ckermit.ini" : "/home/adam/Code/yocto/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/ckermit-211-r3/image/usr/bin/kermit ", "/home/adam/Code/yocto/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/ckermit-211-r3/package/usr/bin/kermit" : "rtld(GNU_HASH) libc.so.6(GLIBC_2.7) libc.so.6 libc.so.6(GLIBC_2.4) ",
May 15 20:21:37 <Adam_> sorry it's hard to read
May 15 20:21:43 <fray> there we go...
May 15 20:21:55 <fray>           i/ckermit-211-r3/package/usr/bin/ckermit.ini" :
May 15 20:21:55 <fray>           "/home/adam/Code/yocto/build/tmp/work/armv7a-vfp-neon-poky-linux-gnue
May 15 20:21:55 <fray>           abi/ckermit-211-r3/image/usr/bin/kermit ",
May 15 20:22:09 <fray> look at the ckermit.ini file.. it's somehow incorrect
May 15 20:22:15 <Adam_> ok
May 15 20:22:35 <fray> the first side of the ',' is the file, the second side if the dependency (require or provide)
May 15 20:22:56 <fray> RPM said it needed /home/..../usr/bin/kermit, so looking at this, the only thing that needs that patch is the ckermit.ini
May 15 20:23:09 <Adam_> hmm
May 15 20:23:20 <Adam_> i'm looking at the .ini file
May 15 20:23:22 <Adam_> it's quite long
May 15 20:23:23 <fray> so the bug is in ckermit.ini -- either it's a symlink to the wrong place -- or it has an internal reference or something.. but it's wrong.. it should reference "/usr/bin/kermit"
May 15 20:23:48 <Adam_> ohhh
May 15 20:24:35 <Adam_> i searched for kermit in the file, but there is nothing similar to /usr/bin/kermit
May 15 20:24:45 <Adam_> or the full path i mentioned above
May 15 20:26:06 <fray> is the recipe somewhere i can look at it?
May 15 20:27:30 <Adam_> hmm 1 sec
May 15 20:28:48 <Adam_> you only have to look at the .bb file?
May 15 20:29:02 <fray> I'd like the recipe so I can try to build
May 15 20:29:13 <Adam_> sorry i 'm quite new
May 15 20:29:32 <Adam_> this is something my colleague has worked on for a while
May 15 20:29:49 <Adam_> so i don't think the recipes are in a repository yet
May 15 20:29:51 <fray> no problem.. you hit a corner case, and I'd like to know if it's the rpm dependency generator, or something else loading from the .ini file..
May 15 20:30:26 <fray> but that is the issue, the system thinks that long path is needed based on something in the .ini file..
May 15 20:30:47 <Adam_> i seee
May 15 20:30:55 <Adam_> can i send you the .ini file? if you don't mind?
May 15 20:31:27 <Adam_> i can try reading it first
May 15 20:31:30 <fray> I can look at it, but it might not be enough
May 15 20:31:34 <Adam_> i see
May 15 20:31:40 <fray> I'd just search inside of it for /kermit and see if you find anything
May 15 20:32:21 <Adam_> asg _dialdir \v(home)ckermit.kdd
May 15 20:32:33 <Adam_> asg _netdir \v(home)ckermit.knd
May 15 20:32:39 <Adam_> asg _servicedir \v(home)ckermit.ksd
May 15 20:32:57 <Adam_> those are all the 'kermit' i can find in the .ini file
May 15 20:33:02 <fray> that might be it.. not sure..
May 15 20:33:10 * fray goes to look somewhere else quick
May 15 20:34:27 <Adam_> alrightt
May 15 20:36:30 <fray> sorry, I'm stuck.. I don't see anything else..
May 15 20:36:55 <fray> can you check if the .ini file is exectuable?
May 15 20:36:57 <Adam_> those 3 lines were find within :Stratus_VOS                    ; Stratus VOS
May 15 20:37:01 <fray> if it's +x that could trigger an issue
May 15 20:37:05 <Adam_> is Stratus VOS an operating system?
May 15 20:37:09 <fray> no idea
May 15 20:37:34 <Adam_> +x ??
May 15 20:37:48 <fray> ls -Fla <path to .ini file>
May 15 20:37:57 <fray> -rwxr-xr-x. 1 root root 943360 May 21  2010 /bin/bash*
May 15 20:38:00 <otavio> RP__: http://paste.debian.net/168969/ <= seems to work for kmod
May 15 20:38:05 <fray> if it's '+x' then its' evaluated for depdencies..
May 15 20:38:10 <fray> if it's not, it's ignored..
May 15 20:38:23 <Adam_> so just the path to the .ini file, not including the file itself right?
May 15 20:38:25 <fray> so it might be posible in the do_install step to simply do chmod ugo-x ....ini
May 15 20:38:30 <fray> include the file
May 15 20:38:35 <Adam_> ok
May 15 20:38:55 <Adam_> -rw-rw-r-- 1 adam adam 21239 2003-09-05 09:10 ckermit.ini
May 15 20:39:04 <fray> ya.. then I simply don't know what the issue is then..
May 15 20:39:12 <fray> if you can post the recipe for me to try it, I'll be happy to..
May 15 20:39:18 <fray> but I don't see what the problem is..
May 15 20:39:26 <Adam_> hmm what exactly is a recipe +_+?
May 15 20:39:29 <khem> otavio: patch looks ok to me
May 15 20:39:30 <Adam_> so it's not just the .bb file
May 15 20:39:44 <fray> everything in the <layer>/recipe-*/ckermit  directory
May 15 20:39:44 <Adam_> btw, thank you so much for your help fray
May 15 20:39:44 <khem> otavio: however can you move .so to libdir too ?
May 15 20:39:56 <Adam_> ok i will upload it to somewhere and will let you know
May 15 20:40:03 <fray> ok
May 15 20:40:33 <Adam_> hmm ok inside the ckermit directory uner the recipes-core, i only have .bb file
May 15 20:40:43 <otavio> khem: i'd prefer to have it in before going further with changes; meta-oe just fails to build completely for me currently
May 15 20:40:45 <fray> then that should be all I need to replicate this
May 15 20:40:55 <otavio> khem: without this
May 15 20:41:12 <khem> otavio: I know but when you fix things and there is some feedback its better to include it
May 15 20:41:36 <khem> otavio: if you dont want feedback why do you ask then you can simply send the patch and ask for inclusion
May 15 20:42:04 <Adam_> http://www.sendspace.com/file/x99w71 is where the file is
May 15 20:42:11 <otavio> to move the so it will be hackish; in fact i don't know how to do that without mangling pkgconfig file and handling ugly symlinks
May 15 20:42:54 <otavio> khem: i pointed it to RP__ as he were concerned about /usr in separated partition; this seems to fix the issues for me.
May 15 20:43:07 <khem> yes I know the problem very well
May 15 20:43:39 <khem> nevertheless, you patch is an improvement
May 15 20:43:42 <otavio> khem: do you have any suggestion how to move the so there too? or is the hashish way the only one?
May 15 20:44:26 <khem> the way we do stuff in oe w.r.t to /usr being totally separate I dont see
May 15 20:44:34 <khem> any elegant way
May 15 20:44:58 <khem> you could just intall in libdir
May 15 20:45:14 <khem> and then move libkmod.so.* to base_libdir
May 15 20:45:29 <otavio> khem: and fix the symlinks
May 15 20:45:35 <khem> and adjust the libkmod.so symlink to base_libdir
May 15 20:45:39 <khem> yes
May 15 20:45:50 <otavio> grr ... horrible heheh
May 15 20:46:03 <fray> ok, I've replicated the problem..
May 15 20:46:04 <khem> but keep an eye on kmod itself
May 15 20:46:06 <otavio> ok; will finish to test my images and work on that
May 15 20:46:13 <fray> found it..
May 15 20:46:14 <Adam_> haha yay, i'm not alone with that problem
May 15 20:46:21 <fray> in the ckermit.ini -- very top line is the problem
May 15 20:46:24 <khem> since it might now want libkmod in libdir
May 15 20:46:25 <fray> #!/home/mhatle/git/oss/oe-core/build-ia32-4/tmp-eglibc/work/x86_64-oe-linux/ckermit-211-r3/image/usr/bin/kermit
May 15 20:46:31 <otavio> khem: in any case, i prefer to do it in another patch so this one can go in before ...
May 15 20:46:35 <fray> that line should read #!/usr/bin/kermit
May 15 20:46:42 <otavio> khem: by rpath?
May 15 20:46:45 <otavio> possible
May 15 20:46:52 <khem> otavio: that later never comes
May 15 20:47:17 <khem> I see code everyday which was written in 1996 with comments "fix it later"
May 15 20:47:18 <otavio> khem: i usually fix the stuff i leave to later
May 15 20:47:41 <khem> ok if you assume responsibility thats good
May 15 20:47:54 <otavio> khem: i try to.
May 15 20:47:56 <Adam_> hm the very top line of my .ini file says
May 15 20:48:00 <Adam_> COMMENT - Standard C-Kermit initialization file
May 15 20:48:06 <fray> there is a line above that
May 15 20:48:09 <khem> although I still dont like the separation of / and /usr
May 15 20:48:17 <khem> its a backward approach IMO
May 15 20:48:23 <otavio> khem: i don't use it
May 15 20:48:25 <Adam_> hhmm i don't have one?!
May 15 20:48:32 <khem> nobody in modern world uses it
May 15 20:48:35 <fray> maybe your editor is hiding it?
May 15 20:48:40 <otavio> khem: for me it seems easier to use a initrd and be done with that
May 15 20:48:49 <Adam_> hmm
May 15 20:48:52 <Adam_> ok h1 sec
May 15 20:49:06 <fray> Adam_ add the following to the end of do_install()
May 15 20:49:07 <fray>         sed -e "s,${D},," -i ${D}/usr/bin/ckermit.ini
May 15 20:49:27 <khem> further more most of apps now a days assume /usr
May 15 20:49:28 <otavio> specially because anything requiring this would be due safeness and like and a extra requirement for a small initrd wouldn't hurt
May 15 20:49:37 <Adam_> adam@adam-Gumstix:~/Code/yocto/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/ckermit-211-r3$ cat ckermit.ini COMMENT - Standard C-Kermit initialization file ;
May 15 20:50:02 <khem> otavio: yeah initrd is a good approach for such a requirement
May 15 20:50:05 <Adam_> it doesn't look like my file has that first line of yours
May 15 20:50:09 <fray>  /home/mhatle/git/oss/oe-core/build-ia32-4/tmp-eglibc/work/x86_64-oe-linux/ckermit-211-r3/package/usr/bin/ckermit.ini
May 15 20:50:18 <fray> your are looking at the raw version, not the installed version
May 15 20:50:25 <fray> something added the #! to the installed version
May 15 20:50:27 <Adam_> ohhhh
May 15 20:50:33 <Adam_> sorry my bad
May 15 20:50:44 <khem> we have added extra complexity into our metadata and recipes to deal with this separation of church and state
May 15 20:50:45 <fray> no problem.. easy fix.. just change the line to the right value
May 15 20:52:10 <Adam_> ok so with that added, do i still need to eit the do_install() ?
May 15 20:52:55 <Adam_> edit*
May 15 20:52:57 <fray> you need your do_install to look like:
May 15 20:53:30 <fray> http://pastebin.com/UQVM5VLV
May 15 20:54:12 <Adam_> and do_install() is in .bb file?
May 15 20:54:37 <Adam_> got it
May 15 20:54:42 <fray> yes
May 15 20:56:05 <Adam_> sorry, so iwth the new .bb file, if I do bitbake -c cleansstate ckermit, do i still have to modify the first line of .ini ?
May 15 20:56:24 <Adam_> with*
May 15 20:56:49 <fray> nope, the "sed" line modifies it for you
May 15 20:57:00 <Adam_> i awesome
May 15 20:57:16 <Adam_> i'm gonna go build the whol distro, it may take some time but i think it will work this time
May 15 20:57:20 <Adam_> THANK YOU FRAY!!
May 15 20:57:24 <fray> np..
May 15 20:57:38 <fray> (I heavily test RPM.. it often finds problems other package managers don't..)
May 15 20:58:22 <Adam_> awesome, I'm so glad to have met you =D
May 15 20:58:47 <Adam_> it's gonna take like 30min haha oh joy
May 15 21:03:25 <Adam_> hm it WORKED!!!!!! Fray THANK YOU. I spent a full day on this and I was about tojump =D
May 15 21:03:43 <mranostay> -ETOOEXCITED
May 15 21:05:09 <fray> no problem
May 15 21:06:37 <otavio> khem: agreed; i did same complain in ml
May 15 21:06:48 <khem> otavio: good
May 15 21:07:15 <otavio> khem:  in fact both; your and mine -ENOTIME hehe
May 15 21:07:22 <otavio> lol
May 15 21:07:36 <khem> otavio: qa-checks are like insurance policy, which tells that mr. qa please dont let me do it and bard if I do
May 15 21:07:52 <khem> now you have to assess if insurance is worht the premium
May 15 21:08:00 <khem> and in this case premium seems to be high
May 15 21:08:09 <khem> gains are just for one arcane case
May 15 21:08:57 <otavio> khem: the cost of premium, you mean?
May 15 21:11:12 <khem> yes
May 15 21:11:27 <khem> look how many recipes have bandaids to support this
May 15 21:14:12 <kergoth`> heh, should split it into a separate layer
May 15 21:16:22 <khem> kergoth`: separate what
May 15 21:50:07 <fray> just love w/ the IRC server stops responding.. but yet my client doesn't realize it
May 15 21:57:11 <otavio> khem: the workarounds and hacks for /usr in another partition ;)
May 15 21:57:18 <otavio> kergoth`: am I right?
May 15 21:58:54 <kergoth`> aye
May 15 22:04:00 <khem> kergoth`: yes a separate layer for such would be reccommended I think
May 15 22:04:10 <khem> whoever needs that can maintain it
May 15 22:04:16 <khem> but certainly not in OE-Core
May 15 22:07:07 * kergoth` nods
May 15 22:39:04 * kergoth` works on cleaning up old branches
May 15 22:50:33 <kergoth`> Is there a way to force a kernel pr bump when modifying kernel.bbclass? I'm assuming not
May 15 22:50:37 <kergoth`> khem: do you know, by chance?
May 15 22:54:38 <khem> kergoth`: meta-oe has something for it but not in OE-Core
May 15 22:54:51 <khem> IIRC
May 15 22:57:53 <khem> I am thinking of MACHINE_KERNEL_PR but I think thats different too doesnt fit here
May 15 22:58:03 <khem> I guess you need to bump PRs of kernels
May 15 23:01:27 <otavio> MACHINE_KERNEL_PR ought to  be the near thing of it.
May 15 23:01:49 <otavio> but I do see a value for a CLASS_PR and it might be prepended to the PR
May 15 23:16:12 <kergoth`> hmm
May 15 23:29:34 <kergoth`> maybe our per-recipe classes should start incrementing PRINC the way we do in bbappends
May 15 23:36:31 <jwessel> I have to admit I wonder why cleansstate eliminates _all_ the checksummed packages for a package name.
May 15 23:36:48 <jwessel> Vs clearing out the sum it plans to build the next time around.
May 15 23:38:25 <kergoth`> that behavior doesn't make much sense, i agree
May 15 23:39:03 <bluelightning> AIUI cleansstate is supposed to get rid of everything (aside from the source)
May 15 23:39:04 <jwessel> I don't know about others, but I am actually using a sstate for multiple builds, and it get a bit annoying to get pkg's wiped out that I could actually use.
May 15 23:39:08 <bluelightning> it doesn't need to be smart
May 15 23:39:57 <kergoth`> cleansstate is supposed to remove the sstate package, but it isn't remving just the current one, it's removing all of them, is what jwessel is saying
May 15 23:40:10 <kergoth`> even those that might be valid in other circumstances, as long as they make the SSTATE_PKGSPEC
May 15 23:40:11 <jwessel> correct.
May 15 23:40:39 <jwessel> I asked because I noticed things rebuilding that shouldn't be rebuilding.
May 15 23:40:42 <bluelightning> for me that's expected; but that's because I view cleansstate as something I use when I really want to build from scratch
May 15 23:41:02 <kergoth`> it'd still build from scratch if it only removed the current one
May 15 23:41:24 <bluelightning> if we trust sstate then cleansstate shouldn't need to be used at all
May 15 23:41:56 <kergoth`> which doesn't change the fact that the current behavior is unintuitive
May 15 23:42:26 <jwessel> I wonder how hard it would be to fix the current behavior, I had not looked yet, but probably will as my level of annoyance grows with it :-)
May 15 23:45:37 <bluelightning> jwessel: can you explain your workflow that results in "old" sstate files for the same recipe that you actually want to preserve?
May 15 23:47:07 <fray> bluelightning:  I have a case which I'm working on now..
May 15 23:47:12 <fray> inherit update-alternatives
May 15 23:47:19 <fray> change the values of the update alternative variables...
May 15 23:47:21 <fray> it never rebuilds
May 15 23:47:31 <jwessel> mainly it was I had 3 projects each with a different busybox.
May 15 23:47:43 <jwessel> Meaning different config options to busybox.
May 15 23:47:45 <bluelightning> fray: that's something different though, that's something missing from the checksum
May 15 23:47:46 <fray> jwessel ya, busybox config I don't think is being evaluated as part of it
May 15 23:48:05 <jwessel> It seems to work with different sums at the feature level.
May 15 23:48:05 <fray> how do i get it into the checksum?  something in update-alternatives?
May 15 23:48:24 <bluelightning> fray: well, it works via variable dependencies
May 15 23:48:46 <jwessel> But I would cleansstate in one dir and then the others started rebuilding busybox for no good reason because the (reason was the sstate went away)
May 15 23:49:03 <fray> so function[vardeps] += "new stuff"?
May 15 23:49:18 <bluelightning> fray: normally it's calculated automatically and everything's fine, but in some cases you may need to and add something in that manner, yes
May 15 23:49:26 <fray> cleansstate removes the sstate.. if you are sharing the same sstate it'll cause a rebuild..
May 15 23:51:28 <bluelightning> we do definitely want any substantive (i.e. output-influencing) changes to the recipe to trigger a rebuild; if something isn't doing that it's a bug that needs to be fixed
May 15 23:51:58 <bluelightning> FYI changes to the content of associated files (items in SRC_URI) is something I'm working on right now
May 15 23:55:44 <fray> ok, in vardeps, how do I specify a wild card? :P
May 15 23:55:51 <fray> the variable is ALTERNATIVE_<pkg>
May 15 23:56:00 <fray> or do I need to use python substitution?
May 15 23:57:04 <bluelightning> fray: that I'm not sure of I'm afraid...
May 15 23:57:20 <bluelightning> I am fairly sure there is no support for wildcarding
May 15 23:57:33 <fray> populate_packages[vardeps] += "ALTERNATIVE_LINKS ALTERNATIVE_NAME ALTERNATIVE_PATH"
May 15 23:57:36 <fray> lets see if that works
May 15 23:57:50 <bluelightning> if all else fails, you could use an anonymous python section
May 15 23:58:32 <bluelightning> I gotta get some sleep, night all
May 15 23:58:37 <fray> later
May 16 00:03:32 * fray tries:
May 16 00:03:32 <fray> populate_packages[vardeps] += "ALTERNATIVE_${@' ALTERNATIVE_'.join((d.getVar('PACKAGES', True)).split())}"
May 16 00:30:36 <fray> var[flags] are not evaluated.. damn
May 16 00:48:57 <pixelgeek> otavio: I mentioned your name several times to the IDF attendees today.  Several of them commented that they already knew you :)
May 16 01:00:52 <otavio> pixelgeek: nice! :)
May 16 01:01:33 <otavio> pixelgeek: I hope they have told the good things about me, not the bad ones hehehe
May 16 01:01:54 <pixelgeek> Yes - nothing but positive comments :)
May 16 01:02:37 <otavio> Ufa!
May 16 01:02:47 <otavio> they left the bad one secret heheheh
May 16 01:02:50 <otavio> LOL
May 16 01:02:52 <pixelgeek> I think everyone 'got' the concept of what we are doing with Yocto, although some were a little surprised to see a ARM board on an Intel demo
May 16 01:03:17 <otavio> Yeah ... it might be surprising
May 16 01:03:24 <pixelgeek> The Linux world people came around 2 or 3 times.
May 16 01:03:44 <pixelgeek> So don't be surprised if we get an article in there at some point in the future.
May 16 01:03:54 <otavio> Good :)
May 16 01:07:36 <otavio> pixelgeek: so in the end people have enjoyed the talk :) that's good.
May 16 01:07:45 <otavio> pixelgeek: are you enjoying Brazil?
May 16 01:07:57 <pixelgeek> So far
May 16 01:08:01 <otavio> pixelgeek: it is a shame I couldn't go to SP
May 16 01:08:01 <pixelgeek> The food is good
May 16 01:08:11 <otavio> pixelgeek: ahahha not only the food
May 16 01:08:11 <pixelgeek> (if expensive)
May 16 01:08:35 <pixelgeek> The weather has been disappointing though.
May 16 01:08:43 <otavio> cloudy?
May 16 01:08:50 <pixelgeek> 15C & rain
May 16 01:08:54 <otavio> ah
May 16 01:09:03 <otavio> well, it is winter so expected
May 16 01:09:07 <pixelgeek> It's been 28 C & Sunny in Oregon this week.
May 16 01:09:19 <otavio> even though in SP is is hotter then this usually
May 16 01:09:23 <pixelgeek> People there expect Brazil to be hot and sunny all the time.
May 16 01:09:26 <otavio> even in winter
May 16 01:09:31 <otavio> lol
May 16 01:09:40 <pixelgeek> We must have brought it with us.
May 16 01:09:47 <otavio> heheheh
May 16 01:09:56 <otavio> must be heheh
May 16 01:10:02 <otavio> you bad!
May 16 01:10:04 <otavio> :P
May 16 01:10:29 <pixelgeek> Well, don't worry - we fly back tomorrow, and the weather forecast for here is warmer next week.
May 16 01:10:41 <pixelgeek> (And worse for Oregon when we get back)
May 16 01:11:00 * pixelgeek just can't catch a break in the weather
May 16 01:13:07 <otavio> hehe
May 16 01:23:44 * kergoth` ponders
May 16 01:25:47 <mranostay> kergoth`: random pondering?
May 16 01:26:41 <kergoth`> mulling over possible ways of implementing SSA in bitbake
May 16 02:46:12 <chackal_sjc> guys
May 16 02:46:24 <chackal_sjc> there is a bug with udev for beagleboard version
May 16 02:47:09 <chackal_sjc> udev-164 uses SOCK_CLOEXEC from socket.h
May 16 02:48:35 <chackal_sjc> but SOCK_CLOEXEC doesnt exists for <= 2.6.27 (+-)
**** ENDING LOGGING AT Wed May 16 03:00:01 2012

**** BEGIN LOGGING AT Wed May 16 03:00:01 2012
May 16 06:49:12 <eFfeM_work> chackal_sjc: I don't think this is a yocto issue, yocto does not have any recipes for pre 2.6.28 kernels (actually yocto 1.2 only has 3.0 and 3.2 recipes iirc), guess you are using oe-classic or so
May 16 06:58:54 <exosyst> Should I be able to bitbake to 'recipes' in the same location? i.e. I wanted a core-image-minimal and a meta-toolchain so issues a bitbake for both?
May 16 06:59:33 <exosyst> *two :D
May 16 07:00:40 <exosyst> Also, do TI have a specific place I can file bugs to?
May 16 07:10:41 <exosyst> I'm seeing configure: error: C preprocessor " arm-poky-linux-gnueabi-gcc -E" fails sanity check when trying to bitbake the meta-toolchain, is something broken here?
May 16 07:13:32 <eFfeM_work> exosyst: not sure what you mean with your same location question, but you can definitely say "bitbake core-image-minimal meta-toolchain"
May 16 07:19:40 <exosyst> eFfeM_work, Ok cool. So there's just something wrong with the recipe for the toolchain then, that's at least something :D
May 16 07:20:19 <eFfeM_work> exosyst: can't really comment on the meta-toolchain part, never build that for yocto, only in oe-classic and quite a while ago
May 16 07:25:49 <mckoan> good morning
May 16 07:29:34 <eFfeM_work> hi mckoan
May 16 07:30:11 <exosyst> eFfeM_work, OK, well i fired off an email to the meta-ti list, hopefully I'll have something back soon.
May 16 07:32:33 <eFfeM_work> exosyst: gl
May 16 07:41:25 <exosyst> Is there a way to remove a specific package from a build? I'm seeing "ERROR: Required build target 'vlc' has no buildable providers." after a git pull on the meta-ti branch and want to exclude it
May 16 07:46:38 <exosyst> Grr, it turned out a cleanall world tried to do something bizarre - nevermind
May 16 12:29:33 <exosyst> If I'm getting "libcurl.so.4 is needed by qemu-nativesdk-0.15.1-r6.i686" - is that something I need installed on my host?
May 16 12:31:10 <exosyst> Is there somewhere I can throw a --disable-curl ?
May 16 12:44:05 <ant_work> exosyst: strange, a similar patch seems merged  http://patches.openembedded.org/patch/26045/
May 16 12:44:34 <exosyst> ant_work, Is it possible I am pulling from the wrong repos?
May 16 12:45:45 <exosyst> ant_work, Or is it just not available in git yet? I had to chuck out my work on denzil as couldn't find any support for the meta-ti problems I was having.
May 16 12:45:55 <ant_work> I see that in git master
May 16 12:46:15 <ant_work> and in denzil branch
May 16 12:46:41 <ant_work> http://cgit.openembedded.org/openembedded-core/log/?h=denzil&qt=grep&q=curl
May 16 12:46:44 <exosyst> ant_work, The problem I had with denzil was with getting a toolchain-meta to build, kept failing out and had no clue how to fix it.
May 16 12:47:58 <ant_work> see, it was [YOCTO #2305]
May 16 12:48:41 <exosyst> ant_work, I've got that --disable-curl in the right place which leaves me wondering if something overrides it and how to find the culprit?
May 16 12:50:26 <exosyst> I'm also seeing a 'No package libkmod found' issue as well, I've not heard of the library before so any light shed on where I can get it would be appreciated.
May 16 12:57:02 <exosyst> It looks like it's a new dependency of udev? Anyone have a clue about libkmod?
May 16 13:01:14 <ant_work> kmod replaces module-init-tools
May 16 13:01:42 <ant_work> it has been committed recently
May 16 13:04:42 <bluelightning> yes that is a recent annoying bug
May 16 13:04:57 <bluelightning> some fixes have been proposed but not merged yet AFAIK
May 16 13:05:01 <exosyst> ant_work, So how do I pull the latest and greatest? I did a git clone of the following git://github.com/Angstrom-distribution/meta-ti.git,  https://github.com/openembedded/meta-oe.git and pulled from git://git.yoctoproject.org/poky poky-git
May 16 13:05:29 <exosyst> bluelightning, hmm... so is there no way of getting a working udev from Yocto at the moment then?
May 16 13:06:05 <exosyst> This has eaten so much time :( beginning to think I should just roll my own distro but I feel so close!
May 16 13:09:14 <ant_work> exosyst: no idea about your hw but I'm noticing meta-ti needs meta-oe toolchain-layer (no idea why). You could start removing the meta-oe layer and rebuilding from scratch
May 16 13:09:33 <ant_work> this to avoid nasty 'crosstalks' between layers
May 16 13:10:03 <ant_work> (meta-oe is not yet fully integrated whit oe-core)
May 16 13:12:29 <exosyst> ant_work, I didn't realise that, I shall strip it back and see how I fare
May 16 13:12:40 <ant_work> ah, well, ofc no issues if you just include the specific toolchain layer
May 16 13:13:48 <exosyst> How do you mean?
May 16 13:14:21 <exosyst> Stripping off meta-oe doesn't work due to a dependency on systemd which comes from meta-oe
May 16 13:14:30 <bluelightning> exosyst: the udev with the problem is not in "yocto", it's in meta-oe
May 16 13:14:46 <bluelightning> exosyst: one way to get around it is to just set PREFERRED_VERSION_udev = "164"
May 16 13:15:10 <bluelightning> that will use the older OE-Core/Yocto supplied version of udev that doesn't look for libkmod
May 16 13:15:22 <ant_work> exosyst: you don't need meta-oe layer to build the core-images
May 16 13:15:31 <bluelightning> ant_work: you do need it for meta-ti though
May 16 13:15:34 <bluelightning> unfortunately
May 16 13:15:35 <exosyst> Where do I set that? In my .conf?
May 16 13:15:41 <bluelightning> exosyst: local.conf yes
May 16 13:15:49 <ant_work> well, I've onlyseen references to the toolchain layer
May 16 13:16:17 <ant_work> which is now on the remove list...
May 16 13:16:55 <ant_work> https://github.com/Angstrom-distribution/meta-ti/blob/master/README
May 16 13:17:01 <exosyst> bluelightning, do I need to bump/remove anything or can I just rebitbake?
May 16 13:17:16 <bluelightning> exosyst: should be ok to just bitbake
May 16 13:19:04 <exosyst> It's fun this, already had to tweak a Makefile for the TI stuff so it didn't generate x86 instructions for ARM :-/
May 16 13:19:35 <exosyst> bluelightning, How do you track all the numbers versions? Is there some information I should have or do you just work on this a lot?
May 16 13:20:19 <bluelightning> exosyst: well, I'm paid to work on the Yocto Project plus I use Yocto/OE in my spare time so I have a fair bit of experience with it...
May 16 13:20:29 <bluelightning> exosyst: that said, we do want to reduce a lot of these silly problems
May 16 13:21:05 <bluelightning> exosyst: the main issue is meta-oe is trying to do too many things right now; we hope to be able to improve it in the current dev cycle
May 16 13:21:10 <exosyst> They're a massive stumbling block when the core is broken :( - I'm a big cheerleader for FOSS stuff but it's always these things that people notice first when you show them
May 16 13:21:26 <bluelightning> yeah, I know what you mean
May 16 13:21:53 <bluelightning> within the Yocto Project we probably don't pay enough attention to meta-oe but that's because we mostly have our hands full with work on OE-Core
May 16 13:22:14 <exosyst> bluelightning, Ok well the core-image-minimal completed (albeit with 8 warning and the old udev), time to try and generate the toolchain, Did you see my issue with --disable-curl being overridden? Any insight?
May 16 13:22:17 <Crofton|work> +1
May 16 13:22:49 <bluelightning> Crofton|work: hint, others can help ;)
May 16 13:24:11 <exosyst> I'd love to work on it but would need hand holding, I'm a software consultant and am giving a talk on using Yocto on Atom boards at a conference soon... wish I'd given myself more time! I am balancing getting it to work on the beaglebone for a course as well as getting the atom version working for the masterclass. Good times!
May 16 13:24:20 * Crofton|work notes his patch to fix the oe-core setup to avoid mixing bitbake with tge oe-core directory is going no where
May 16 13:24:35 <Crofton|work> exosyst, which conference?
May 16 13:24:44 <exosyst> Embedded Master Class in Cambs UK
May 16 13:24:53 <Crofton|work> ok
May 16 13:26:25 <bluelightning> exosyst: I'm afraid I'm not sure with the curl issue; you might be able to get past it by doing "bitbake -c cleansstate qemu-nativesdk" first though
May 16 13:26:55 * bluelightning wonders what qemu is doing linking to curl in the first place
May 16 13:27:45 <exosyst> Hmm, yeah something is definitely overriding the --disable-curl setting in qmenu.inc (or perhaps just not being used?). How would I track that? Output here http://pastebin.com/iHccQbGb
May 16 13:28:51 <bluelightning> Crofton|work: feel free to ping on it
May 16 13:30:07 <bluelightning> exosyst: you could have a look at the qemu-nativesdk configure log - see TMPDIR/work/*nativesdk*/qemu-nativesdk-*/temp/log.do_configure
May 16 13:35:50 <exosyst> bluelightning, Looks like this http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=robert/qemu&id=23138099c77cd3dc6af309c81ef52da03a9ad004 is the fix
May 16 13:36:40 <bluelightning> exosyst: ah ok... good that we have a proper fix :)
May 16 13:36:42 <exosyst> Not sure why it's not been pulled in, though the PR number in qemu_0.15.1.bb had already been bumped so possible
May 16 13:37:42 <bluelightning> exosyst: probably because Richard and Saul (who normally merge changes) are out of their respective countries atm
May 16 13:37:50 <bluelightning> (just for this week)
May 16 13:38:20 <bluelightning> so merging is a little slow atm
May 16 13:39:32 <exosyst> Spoke to soon - didn't fix it, though thinking about the fix I tried applying, should the same apply to  package meta-toolchain-1.0-r7.bb as that's what's failing? Perhaps I'm clutching at straws :P
May 16 13:41:03 <Crofton|work> I hope davest survives his trip
May 16 13:41:23 <Crofton|work> bluelightning, you need to convince one of that lot to stop by Berlin :)
May 16 13:42:58 <bluelightning> Crofton|work: obviously the usual suspects are busy, but it's amazing with all the OE folks we have in Germany we don't have one person who could be there...
May 16 13:43:16 <Crofton|work> yeah
May 16 13:43:23 <Crofton|work> I am annoyed
May 16 13:44:44 <bluelightning> Crofton|work: I think Robert & co do such a great job we have been taking them for granted :(
May 16 13:44:56 <Crofton|work> although I do like the idea or forcing RP to spend a week in Berlin with no internet
May 16 13:45:02 <Crofton|work> yeah
May 16 13:45:35 <Crofton|work> robert is in France now
May 16 13:45:54 <bluelightning> ah ok
May 16 13:47:52 <bluelightning> exosyst: it's failing in meta-toolchain because that's attempting to install packages into a filesystem and one of those packages has a missing dependency
May 16 13:48:30 <bluelightning> exosyst: if qemu-native actually gets rebuilt with that fix it should solve it...
May 16 13:49:33 <davest> Crofton|work: Someone supplied to me a 75% dog-free running route ... for tomorrow
May 16 13:50:17 <bluelightning> davest: I hope for your sake the remaining 25% isn't populated with hungry pit-bulls...
May 16 13:52:05 <bluelightning> I guess that's one kind of data you could easily crowd-source... presumably someone's already done that
May 16 13:52:34 <exosyst> bluelightning, Ah, is that what cleanstate should do?#
May 16 13:52:54 <bluelightning> exosyst: -c cleansstate is a way to force it to rebuild a recipe from scratch
May 16 13:52:59 <exosyst> Hoo-bloody-ra, it completed. Now to see if what got created is sensical :P
May 16 13:53:10 <bluelightning> yay :)
May 16 13:53:15 <Crofton|work> heh
May 16 13:53:49 <exosyst> That patch should *reaaaally* be pulled in. What better way to upset people then require esoteric knowledge to fix build errors! :-P
May 16 13:54:49 <exosyst> Where would I find the sdk it generated? Shouldn't it be in /deploy/images/?
May 16 13:55:09 <exosyst> Found it, under sdk (who would've thunk it? :)
May 16 13:59:39 <szu> in /meta-yocto/recipes-kernel/linux are several kernel files - how can i choose which kernel version i would like to use before starting bitbake?
May 16 14:00:49 <exosyst> Is there a good way to pull the kernel tree out of Yocto? I need it standalone so I can cross-compile it as part of a lesson. Is it a case of just copying out the sourcecode from ./work/beaglebone-poky-linux-gnueabi/linux-ti33x-psp-3.2-r0/git/ and hoping for the best?
May 16 14:01:20 <exosyst> I need to remove the need to call Yocto for menuconfig etc so it's a bit of a pain
May 16 14:01:32 <Crofton|work> I assemble a git repo that matches what is in the kernel
May 16 14:01:41 <Crofton|work> koen may have a repo that matches that
May 16 14:01:50 <holgerwrs> exosyst: bluelightning: the udev 182 part of meta-systemd (plus meta-ivi) should be working http://git.yoctoproject.org/cgit/cgit.cgi/meta-systemd/tree/recipes-core/udev
May 16 14:02:02 <Crofton|work> then set CROSSCOMPILE and your path to use the toolcahin in the sysroot :)
May 16 14:02:06 <exosyst> holgerwrs, good to know
May 16 14:02:31 <exosyst> Crofton|work, You talking to me? How do you mean assemble a git repo that matches? You don't snag what's in the tmp tree?
May 16 14:02:36 <Crofton|work> yeah
May 16 14:02:38 <Crofton|work> hang on
May 16 14:04:09 <Crofton|work> https://github.com/koenkooi/linux/branches
May 16 14:04:18 <Crofton|work> I think one of those will match what is in the recipe
May 16 14:04:44 <exosyst> So what should I do... bearing in mind I've got a beagleboned up kernel here ;P
May 16 14:04:57 <Crofton|work> read the recipe
May 16 14:05:01 <Crofton|work> and look at the commits
May 16 14:05:14 <Crofton|work> thinking is needed
May 16 14:06:55 <Crofton|work> this is another approach http://www.slimlogic.co.uk/2011/05/openembeddedangstrom-kernel-workflow/
May 16 14:07:05 <Crofton|work> I'm old fashioned :)
May 16 14:08:13 <exosyst> Crofton|work, haha, that's where I'll fall down. So am I right in thinking I need to fork the kernel and merge in my changes and track that? I'm tempted by the written up guide :)
May 16 14:09:01 <Crofton|work> yeah, just depends on how you think
May 16 14:10:21 <exosyst> I'd like to have: Kernel at known working (so, as built with config patches applied) and then I'd like to git that up and use that as a way for students to be able to git diff etc
May 16 14:39:39 <exosyst> Can I ask what the difference is between tmp/sysroots/beaglebone/kernel and tmp/work/beaglebone-poky-linux-gnueabi/linux-ti33x-psp-3.2-r0/git/ ?
May 16 14:39:55 <kergoth`> sysroots are by definition the shared area for use by other recipes.
May 16 14:40:02 <kergoth`> work is only used in building that recipe
May 16 14:40:30 <exosyst> kergoth`, OK, so if I want to transplant the kernel out so I can build it outside yocto I'd want the sysroot version right?
May 16 14:40:57 <kergoth`> no. the kernel sysroot directory is not the kernel source tree, it's a minimum subset needed to build out of tree modules
May 16 14:41:47 <exosyst> kergoth`, Oh. So which would I go with for that? I want to take it with all the patches applied to the source
May 16 14:42:53 <kergoth`> then grab it out of the work dir. as i said, the sysroot isn't the source tree, the work dir is, as it's impossible to build it without it
May 16 14:43:12 <exosyst> Gotcha. Ok thanks
May 16 15:02:52 <exosyst> Quick question about the generated SDK... are you supposed to source the provided script before using the tools or is it fine to add the binaries to $PATH and then make ARCH=arm CROSS_COMPILE=arm-poky-gnueabi- all?
May 16 15:02:57 <exosyst> as an example :P
May 16 15:07:02 <kergoth`> the script is just a convenience for setting PATH and other vars
May 16 15:07:15 <kergoth`> nothing stopping you from doing it manually]
May 16 15:10:30 <exosyst> kergoth`, I'll have a mess with it and see how I get on. Just setting up my build env with NFS and TFTP boot so no rush. Get the generated stuff working before breaking it with my own spins :P
May 16 15:39:44 <exosyst> Does anyone know the correct defconfig for the beaglebone?
May 16 15:51:38 <Crofton|work> look in the meta-ti recipes
May 16 16:00:37 <exosyst> It's just called defconfig and gets splooshed into the build directory
May 16 16:01:06 <exosyst> It's based off of the am335x_evm_defconfig pretty closely. I should write this down!
May 16 16:13:27 <exosyst> Just calling in to say I successfully built for the beaglebone from git. I have a toolchain. Extracted the kernel from the sourcecode and used the generated SDK to build the kernel on a new machine. I had to make some patches - info was mailed to the mailing list for meta-ti - but overall quite happy with that result.
May 16 16:20:29 <adam_> Good day y'all. I am trying to bitbake core-image-sato
May 16 16:21:02 <adam_> And I get ERROR: Nothing RPROVIDES 'libgles-omp3' (but .... /bask-base.bb RDEPENDS or requires it)
May 16 16:21:53 <adam_> Any help would be appreciated =D
May 16 16:29:05 <bluelightning> adam_: if it really is "libgles-omp3" and not "libgles-omap3" then that's a typo somewhere
May 16 16:30:57 <bluelightning> adam_: libgles-omap3 is from meta-ti
May 16 16:31:17 <bluelightning> adam_: what layers do you have enabled in bblayers.conf? what machine are you building for?
May 16 16:32:34 <adam_> hhmm
May 16 16:32:40 <adam_> oh it's omap3
May 16 16:32:42 <adam_> my bad!
May 16 16:32:52 <adam_> let me check .conf
May 16 16:33:19 <adam_> 1 sec I am building for gumstix
May 16 16:33:33 <adam_> a small embedded device that i'm in love right now
May 16 16:33:48 <adam_> in bblayers, i have meta, meta-yocto, and meta-gumstix
May 16 16:34:34 <bluelightning> adam_: according to the readme for meta-gumstix you need meta-texasinstruments
May 16 16:34:39 <bluelightning> adam_: these days that's called meta-ti
May 16 16:34:52 <bluelightning> http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti
May 16 16:35:01 <adam_> ohh i do have that installed, let me try again with meta-ti in my bblayer
May 16 16:36:07 <adam_> This is what i get with the meta-ti enabled
May 16 16:36:08 <adam_> ERROR: ParseError at /home/adam/Code/yocto/meta-ti/recipes-misc/payload/bonescript.bb:5: Could not inherit file classes/systemd.bbclass                                                             | ETA:  00:00:10
May 16 16:36:24 <bluelightning> right, meta-ti requires meta-oe, so you need that also
May 16 16:36:26 <adam_> sorry  i'm really new to all this
May 16 16:36:29 <adam_> ohhhh
May 16 16:36:31 <bluelightning> no worries :)
May 16 16:36:33 <adam_> haha okk
May 16 16:36:38 <khem> or you could add a BBMASK
May 16 16:36:39 <adam_> thanks bluelightning
May 16 16:36:47 <adam_> BBMASK?
May 16 16:37:00 <kergoth`> yeah, you can mask out recipes-misc
May 16 16:37:05 <khem> yes which will filter certain recipes
May 16 16:37:13 <kergoth`> adam_: it's a regular expression that makes bitbake not even parse any filenames that match
May 16 16:37:24 <kergoth`> BBMASK = "/meta-ti/recipes-misc/"
May 16 16:37:34 <adam_> hm i see, where can i add that line?
May 16 16:37:40 <bluelightning> adam_: local.conf
May 16 16:37:42 <kergoth`> where you add anything else?
May 16 16:38:05 <bluelightning> kergoth`: it's not obvious if you're new to the project
May 16 16:38:19 <adam_> hm before i try that, how does masking work? if meta-ti requires certain things from meta-oe,
May 16 16:38:36 <adam_> how is it possible that it gets by without it when i have bbmask in my .conf file
May 16 16:38:36 <kergoth`> i just told you how it worksk it prevents bitbake from even parsing those files
May 16 16:38:54 <adam_> hmm alright =D
May 16 16:38:56 <bluelightning> adam_: only a small part of meta-ti really needs stuff from meta-oe, the BBMASK effetively disables that part
May 16 16:39:05 <adam_> I see awesome
May 16 16:41:22 <adam_> awesome it's going further this time thanks bluelightning, kergoth and khem
May 16 16:44:35 <adam_> btw bluelightning, how did you know i needed meta-oe by looking at that error message?
May 16 16:45:03 <khem> systemd
May 16 16:45:11 <khem> thats only in meta-oe as of now
May 16 16:45:14 <adam_> i see
May 16 16:45:22 <khem> it will eventually move into OE-Core though
May 16 16:45:39 <khem> which gives me fits about supporting it on uclibc
May 16 16:45:59 <khem> it will be a nightmare since systemd maintainers only think glibc+linux
May 16 16:45:59 <adam_> haha go easy
May 16 16:46:34 <khem> it will be everlasting battle to keep patching it everytime some glibc'ism is added
May 16 16:47:37 <adam_> hmm is there an easy way to improve the build process? I will be patching my stuff to a lot, and even with four CPU cores running, it takes a while to bitbake =(
May 16 16:49:33 <khem> well you could use SDK to do intial development if its an app its easier
May 16 16:49:44 <khem> and then once you are satisfied
May 16 16:49:52 <khem> write a recipe for it and hook it into build system
May 16 16:50:08 <khem> thats one of many ways
May 16 16:50:40 <adam_> hm i don't know what you mean, but let me look into the SDK first to figure it out
May 16 16:50:45 <khem> some people use srctree method which IIRC is called archiver now ? I forget
May 16 16:51:33 <adam_> switching to irssi, done with this webirc
May 16 16:52:44 <khem> strike that archiver is something esle
May 16 16:53:37 <adam__> ok
May 16 16:56:10 <kergoth`> khem: archiver is like src_distribute_local and copyleft_compliance (though it doesnj't replace the latter yet)
May 16 16:57:42 <khem> yeah
May 16 16:57:46 <khem> figured
May 16 16:58:04 <khem> RP__ had patch for srctree functionality too IIRC
May 16 16:58:17 <khem> did it make it to OE-Core yet
May 16 17:01:21 * RP__ doesn't remember such a patch
May 16 17:14:56 <kergoth`> RP__: i think he's talking about your class which was an alternative, simpler version of srctree, though i'm drawing a blank on its name at the moment
May 16 17:16:06 <bluelightning> externalsrc?
May 16 17:16:39 <bluelightning> if so, it is in OE-core, but externalsrc is something completely different from what was being discussed above...
May 16 17:19:00 <kergoth`> no, it isn't. khem brought up srctree 30 minutes ago, but couldn't remember its replacement, mistakeningly brough tup archiver
May 16 17:19:07 * kergoth` grumbles about build failures
May 16 17:20:21 <RP__> kergoth`: ah, yes. That was merged
May 16 17:20:25 <RP__> khem: ^^^
May 16 17:21:13 <bluelightning> kergoth`: ah yes I missed the reference to srctree earlier
May 16 17:21:36 <exosyst> I don't have a better place to post my setup guide so I've slapped it onto a gist - hopefully it will help someone https://gist.github.com/2712354
May 16 17:24:11 <denix> exosyst: meta-ti lives at git://git.yoctoproject.org/meta-ti
May 16 17:24:37 <denix> here's the Web UI: http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/
May 16 17:25:39 <exosyst> denix, I didn't realise! So many repos ;P
May 16 17:26:32 <exosyst> Fixed the gist
May 16 17:26:48 <denix> that is true :)
May 16 17:26:58 <exosyst> Thanks for reading it though - it might help a few more newbies out
May 16 17:27:15 <chackal_sjc> why do PREFERRED_PROVIDER_package needs to be virtual/package?
May 16 17:27:48 <denix> also, the title is "Getting Yocto working on the Beaglebone", but it's not exactly that. in your case you are building an SDK and using it to build a kernel manually
May 16 17:28:40 <exosyst> The last part isn't mandatory. It's the workflow I wanted to follow. It would be fair to just cap it off at the point of the /images/ being ready and put them on the SD card.
May 16 17:28:48 <kergoth`> chackal_sjc: it doesn't. PREFERRED_PROVIDER isn't about the package, nor the recipe, it's abuot what's listed in PROVIDES. the only time you use virtual/ is when recipes add that to their PROVIDES
May 16 17:29:19 <denix> chackal_sjc: that's the case for virtual packages. i.e. there is no specific recipe for <package>. but there are few that PROVIDES that.
May 16 17:29:29 <chackal_sjc> kergoth`: and how should I know that recipes add that?
May 16 17:29:49 <denix> yeah, what kergoth` said. the thing is there's nothing behind "virtual" - it's just a convention
May 16 17:30:26 <chackal_sjc> ok, so if I want to PREFERRED_PROVIDER_ for Qt, should I use PREFERRED_PROVIDER_qt or PREFERRED_PROVIDER_virtual/qt?
May 16 17:31:01 <bluelightning> chackal_sjc: we don't have multiple providers of "qt" though
May 16 17:31:02 <denix> it's not virtual, it's real
May 16 17:31:13 <denix> qt4-embedded for example
May 16 17:31:44 <denix> bluelightning: thanks for helping exosyst!
May 16 17:31:55 <bluelightning> denix: np
May 16 17:32:03 <chackal_sjc> bluelightning: I have access to qt commercial and I want to use that from our git, so I will add this recipe in my bsp layer, so how should I select that?
May 16 17:33:56 <bluelightning> chackal_sjc: good question...
May 16 17:34:28 <denix> chackal_sjc: there are embedded and x11 versions. which one you need?
May 16 17:34:38 <chackal_sjc> x11
May 16 17:35:06 <bluelightning> chackal_sjc: I would probably start by having a differently named recipe in your layer, say qt4-x11-commercial, that can just pull in the inc files we already have and set SRC_URI itself
May 16 17:35:26 <bluelightning> then, it depends on whether you want to build an existing recipe that already depends on qt4
May 16 17:35:39 <kergoth`> chackal_sjc: grep is your friend
May 16 17:35:44 <denix> copy it from qt4-x11-free and adjust
May 16 17:35:45 <kergoth`> chackal_sjc: as is bitbake -e
May 16 17:35:58 <chackal_sjc> ok
May 16 17:36:18 <chackal_sjc> ok, so we have our own custom kernel and qt versions
May 16 17:36:46 <bluelightning> chackal_sjc: I suspect you will only be building your own recipes, in which case they can just depend on qt4-x11-commercial and you don't need to do anything else
May 16 17:37:10 <chackal_sjc> so probably the best way to go is to write recipes with different names right? like my-kernel and qt-commercial
May 16 17:37:27 <bluelightning> chackal_sjc: yep
May 16 17:37:42 <chackal_sjc> ok
May 16 17:37:49 <exosyst> denix, Good point. Thanks to yourself, bluelightning kergoth` eFfeM_work  et al. It's been a fun ride. I'll no doubt be back when I have to do similar with an Atom board later in the week :D
May 16 17:38:04 <chackal_sjc> I'm starting to understand the yocto build system.. it's kind big
May 16 17:38:15 <bluelightning> chackal_sjc: for the kernel though there is a virtual, so your kernel recipe should do PROVIDES += "virtual/kernel" and then you should set PREFERRED_PROVIDER_virtual/kernel = "linux-whatever"
May 16 17:38:32 <bluelightning> chackal_sjc: (traditionally if it's linux then the recipe name starts with "linux-")
May 16 17:38:34 <chackal_sjc> oh ok
May 16 17:38:52 <chackal_sjc> inside meta-linux dir, right?
May 16 17:39:00 <bluelightning> chackal_sjc: then again if your kernel recipe inherits kernel.bbclass the provide is probably done already
May 16 17:39:18 <bluelightning> chackal_sjc: well, meta-yourlayer/recipes-linux
May 16 17:39:22 * denix wonders on a general note - what happened to the trial and error concept? apparently in our age of digital communications it's a dying breed... :)
May 16 17:39:49 <chackal_sjc> bluelightning: because I'm using my own bsp
May 16 17:40:02 <bluelightning> chackal_sjc: right, yeah
May 16 17:40:23 <bluelightning> chackal_sjc: btw I would recommend you keep your BSP and your software in separate layers
May 16 17:40:25 <chackal_sjc> bluelightning: ok i got it
May 16 17:40:34 <bluelightning> chackal_sjc: that way if you want to swap out the hardware in future it's much easier
May 16 17:40:52 <chackal_sjc> bluelightning: what you mean? my source code?
May 16 17:41:01 <bluelightning> qt commercial and your apps
May 16 17:41:14 <chackal_sjc> they are in a git repo outside
May 16 17:41:36 <bluelightning> so, metadata to support the hardware (BSP) in one layer, and metadata to support the software you want to run on the device in another
May 16 17:42:16 <bluelightning> if in future you want to move the same software onto a different piece of hardware, you just replace the BSP with another and keep your software layer
May 16 17:43:06 <bluelightning> chackal_sjc: I'm just talking about the metadata here (recipes + conf files for building)
May 16 17:43:09 <chackal_sjc> hm
May 16 17:43:21 <chackal_sjc> so my software recipies should be in different dir?
May 16 17:43:31 <bluelightning> I'd recommend it yes
May 16 17:43:46 <chackal_sjc> like meta-mybsp/ and meta-qt-commercial/? and meta-linux-custom/ ?
May 16 17:44:21 <bluelightning> well the kernel probably should go into the BSP right? I assume you have the custom kernel to support the hardware...
May 16 17:44:47 <chackal_sjc> yes, the kernel is high bsp dependent
May 16 17:44:47 <bluelightning> unless you have the base BSP supplied by someone else and then your customisations on top of it, in which case they could be separate
May 16 17:45:16 <bluelightning> whatever makes sense for your situation...
May 16 17:45:20 <chackal_sjc> i see
May 16 17:45:24 <chackal_sjc> thanks
May 16 17:45:34 <bluelightning> ultimately you can have it all in one dir, it just saves pain in future if you set things up from the beginning
May 16 17:45:41 <bluelightning> separately
May 16 17:45:59 * bluelightning -> home
May 16 18:11:18 <adam__> a quickie, is there a recipe for depmod available? I can't seem to find it online
May 16 18:23:05 <kergoth`> adam__: kmod.
May 16 18:23:33 <adam__> awesome in /meta/recipes-kernel right?
May 16 18:24:11 <kergoth`> 'find' is your friend
May 16 18:24:20 <msm> i'm seeing 'Summary: There was 1 WARNING message shown.' on denzil… but there is no message displayed
May 16 18:24:27 <adam__> yes =D
May 16 18:24:37 <fray> nothing in the cooker log?
May 16 18:30:24 <msm> fray:  i did not think to check
May 16 18:30:46 <msm> let me see if I can make a new one or grok for the old one
May 16 18:31:38 <msm> ha
May 16 18:31:45 <msm> its the very first message perhaps?
May 16 18:31:46 <msm> 'WARNING: Host distribution "Fedora release 13 (Goddard)" has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution.'
May 16 18:31:54 <msm> but it's not redisplaying the message
May 16 18:31:54 <fray> ok.. I'm passing ont he request.. I'll let you know when I get something back
May 16 18:33:32 <incandescant> yeah, it's just a count of WARNING messages - it doesn't collect them at the end
May 16 18:39:19 <fray> ok, I'm can't figure out why it keeps telling me variouns 2 items are not being packaged, but they are listed in the FILES_${PN}-staticdev.. :P
May 16 18:43:30 <fray> ugh figured it out..
May 16 21:21:50 <msm> has anyone ever built an image inside another image?
May 16 21:21:57 <msm> or is there some example somwhere?
May 16 21:22:53 <msm> im not sure if make do_rootfs of one image depend on do_rootfs of another image somehow and then tarring up and copying over
May 16 21:23:15 <msm> or if I should try to package up a rootfs into an rpm/deb/ipkg as a tarball or something and depend on it that way
May 16 21:24:43 <fray> msm, I havn't done it.. but it should be possible..
May 16 21:24:57 <fray> create a recipe that internally constructs and image, and then packages it up.. then the master image reuqires that thing
May 16 21:41:03 <msm> fray: yea, we dont package our images into rpms
May 16 21:41:12 <msm> seems like that would be a nice *option* for all images by default
May 16 21:41:24 <fray> that will likely be needed.. or custom code for the image generate to include specific files.. (not hard to add
May 16 21:41:45 <msm> fray: i hacked something together that already worked, will need to rethink about upstreaming
May 16 21:42:11 <msm> just RDEPENDS + a new IMAGE_EXTRA_FILES
May 16 21:42:23 <msm> and a new cp in do_rootfs
May 16 21:42:40 <msm> anywways, i feel rpm + DEPENDS is the right way to go
May 16 21:42:49 <msm> off for now
May 16 21:42:58 <fray> I was going to recomment a ROOTFS_POSTPROCESS_COMMANDS
May 16 21:43:39 <fray> ROOTFS_POSTPROCESS_COMMAND
May 16 21:44:01 <fray> there we go.. all of the rootfs*bbclass support that to run at the end.. just add something there that runs a functiont hat copies in the stuff you need..
May 16 21:44:23 <msm> actually, i like that… no changes needed
May 16 21:44:29 <fray> yup
May 16 21:44:44 <fray> likely you'll need to implement a new .bbclass that has the functions you need.. but thats about it
May 16 21:47:07 <khem> msm: I had a quick question on ppc64/p5020 for you
May 16 21:47:23 <khem> msm: Do you have any simulation/qemu bsp support for that ?
May 16 21:48:44 <msm> yes
May 16 21:48:48 <msm> can I give you an email?
May 16 21:49:36 <ant__> khem: kmod-klibc  configure+compile http://paste.debian.net/169173/   http://paste.debian.net/169174/
May 16 21:49:41 <msm> it might only be native though
May 16 21:49:51 <msm> now that I think about what you are asking for ;)
May 16 21:49:52 <ant__> any obvious reason?
May 16 21:51:46 <ant__> well, maybe one: ac_cv_env_CPP_value='arm-oe-linux-gnueabi-gcc -E --sysroot=/oe/oe-core/build/tmp-eglibc/sysroots/poodle  -march=armv5te  -marm -mthumb-interwork  -mtune=xscale'
May 16 21:52:01 <ant__> should read klcc and not gcc hm...
May 16 21:52:34 <khem> msm: ok
May 16 21:56:00 <khem> ant__: yes CPP is set explicitly in bitbake env
May 16 21:56:18 <khem> Do you override that in klibc class
May 16 21:56:22 <ant__> in klibc.bbclass we only set CC
May 16 21:58:00 <khem> hmm you might want to override CPP and CXX as well
May 16 21:58:16 <khem> where CPP is just $CC -E
May 16 21:58:28 <khem> all those warnings mean include paths are messed
May 16 22:04:24 <ant__> ok, now I get ac_cv_env_CPP_value='arm-oe-linux-gnueabi-klcc -E'
May 16 22:04:42 <adam_> Hello, I'm doing bitbake core-image-sato
May 16 22:04:49 <adam_> and i get the following error
May 16 22:04:51 <adam_> | configure: error: Package requirements (libkmod >= 5) were not met:
May 16 22:05:02 <adam_> Anyhelp would be appreciated =D
May 16 22:05:26 <ant__> khem: --sysroot lost so it's more clear what's happening
May 16 22:48:13 * kergoth` sighs
May 16 22:48:47 <kergoth`> gnu_hash is fatal now, but not all recipes in oe-core are fixed to pass ldflags along
May 16 22:48:50 <kergoth`> smooth
May 16 23:14:55 <bluelightning> kergoth`: could you please file a bug?
May 17 00:14:54 <halstead> pidge I've laid the groundwork for the dev AB cluster. It will be ready by tomorrow morning.
May 17 00:17:02 * halstead has to run before he gets a parking ticket.
May 17 01:00:31 <kergoth`> hrm
May 17 01:06:11 <kergoth`> seebs: ping
May 17 01:06:18 <seebs> ack
May 17 01:06:40 <kergoth`> seebs: where's the current version of your var tracking stuff at? do you have a branch somewhere?
May 17 01:07:00 <seebs> I ... hmm.  I don't know if I ever did an actual branch of it, or just sent the patches out.  Lemme look.
May 17 01:07:02 <kergoth`> i find myself in a situation where a var is inexplicably set wrong, and grep is failing to find the culprit :)
May 17 01:07:04 <seebs> I know it is missing some files still.
May 17 01:07:50 * kergoth` checks the bitbake patchwork install
May 17 01:10:01 <seebs> d'oh
May 17 01:10:09 <seebs> I am so not competent with git.
May 17 01:11:23 <kergoth`> http://patches.openembedded.org/patch/27049/ doesn't apply, as far as i can tell.
May 17 01:11:32 <seebs> Hmm.
May 17 01:11:33 * kergoth` tries with wiggle
May 17 01:12:47 <seebs> Okay, I may have done this wrong, but there should now be a seebs/tracking branch on the poky-contrib repository, which is two patches ahead of poky-master.
May 17 01:13:14 <seebs> I think I established that the tracking wasn't picking up layer.conf files or something, but I haven't tracked it down yet.
May 17 01:20:41 <kergoth`> ah, thats what was biting me. poky's ERROR_QA is different than insane.bbclass's default
May 17 01:21:00 <kergoth`> seebs: thanks, that worked
May 17 01:21:09 <seebs> cool!
May 17 01:21:34 <kergoth`> definitely not ready to go in as is, but still useful as a debugging aid on a separate branch
May 17 01:21:34 <kergoth`> heh
May 17 01:22:29 <seebs> Yeah.  It needs cleanup, but I find it super useful anyway.
May 17 01:22:49 <kergoth`> i have a lot of old branches basically stuck perpetually in 'prototype' stage
May 17 01:22:59 <kergoth`> some should probably just throw away, others were interesting to play with
May 17 01:23:00 <kergoth`> heh
May 17 01:31:41 <kergoth`> https://github.com/mroth/lolcommits - this amuses me
May 17 01:35:08 <seebs> that's beautiful
May 17 01:41:24 <kergoth`> hmm, anyone else failing to build recipes like xf86-video-fbdev recently? I'm having a number of x recipes fail due to no xorg server macros, it seems, but this succeeded a few days ago. unless i have something else lurking
May 17 01:41:25 <kergoth`> hm
**** ENDING LOGGING AT Thu May 17 02:59:59 2012

**** BEGIN LOGGING AT Thu May 17 03:00:00 2012
May 17 07:25:18 <eballetbo> Hi guys, I would like to know your opinions. Do you think that can be problematic merge meta-toolchain-gmae + meta-toolchain-qte in a unique meta-toolchain-sdk ?
May 17 07:30:54 <mckoan> good morning
May 17 15:22:16 <ag> Is there any way to "bbappend" a machine conf?
May 17 15:26:15 <bluelightning> ag: no, but you can "require" it in a differently named machine conf file
May 17 15:30:20 <ag> Yeah. I know this but all those compatible machine will be broken.
May 17 15:34:03 <ag> bluelightning: How can i do this. I want to build a machine but with another preferred_version of something.
May 17 15:35:47 <bluelightning> ag: if you have your own distro configuration, you can set it there
May 17 15:36:18 <ag> bluelightning: Thank you. Forgot about distro conf.
May 17 16:02:06 <ag> bluelightning: I want to use a layer which includes a bbappend for a package in oe-core. We don't have that package and i want to exclude it somehow not by removing them from layer.
May 17 16:02:17 <ag> bluelightning: Is there something like BBMASK for bbappend?
May 17 16:02:48 <bluelightning> ag: BBMASK should work for .bbappends as well as .bb files
May 17 16:03:15 <ag> bluelightning: Is wrong to set it in a distro conf?
May 17 16:04:18 <bluelightning> ag: I don't think it would be a good idea...
May 17 16:04:32 <ag> shoot me why
May 17 16:07:04 <bluelightning> ag: BBMASK is handled super early in the process
May 17 16:07:17 <bluelightning> I'm not sure if it will even work
May 17 16:09:07 <ag> bluelightning: Well it's ok. I just want to avoid a bbappend from a layer that was not intended for poky in the first place. I added BBMASK = "package" and it works. Error avoided.
May 17 16:09:34 <bluelightning> ag: it just seems a bit wrong to me
May 17 16:10:07 <ag> bluelightning: Isn't this the purpose of bbmask?
May 17 16:10:39 <bluelightning> I'm not altogether sure, I rarely use it... I consider it as a huge hammer to be used only as a last resort
May 17 16:20:55 <ag> bluelightning: Ok. Realized your point of view. But still... :) I will use it! :)
May 17 16:21:11 <bluelightning> ag: sure, I can't stop you ;)
May 17 16:21:29 <ag> bluelightning: Thank you very much
May 17 16:26:00 <adam_> Hm my bitbake has been stuck for a while with no cpu usage
May 17 16:26:14 <adam_> no network activity either
May 17 16:26:32 <adam_> what can i do now? I retried bitbake after doig a clean
May 17 16:27:02 <ag> adam_: And?
May 17 16:27:22 <ag> This used to happen to me also when messing with PATH...
May 17 16:27:33 <adam_> hm...
May 17 16:27:53 <adam_> i actually did with an environment variable
May 17 16:27:58 <adam_> actually did something*
May 17 16:28:08 <ag> well... you got your answer :)
May 17 16:28:19 <adam_> http://comments.gmane.org/gmane.comp.handhelds.openembedded/52131
May 17 16:29:14 <adam_> well i changed the PKG_CONFIG_PATH  in some of my recipes
May 17 16:29:16 <ag> You want to fix udeb 182?
May 17 16:29:19 <ag> udev*
May 17 16:29:25 <adam_> i wanted to fix it
May 17 16:29:41 <adam_> so i changed the PKG_CONFIG_PATH according to the comment
May 17 16:29:49 <ag> What are you using? poky?
May 17 16:29:52 <adam_> then i am running into this
May 17 16:29:59 <adam_> hmm i suppose i am?
May 17 16:30:07 <adam_> i do bitbake -k core-image-sato
May 17 16:30:16 <ag> and sorce on?
May 17 16:30:18 <ag> source*
May 17 16:30:26 <adam_> source on?
May 17 16:30:37 <ag> source poky/oe-init... bla
May 17 16:30:38 <ag> ?
May 17 16:31:32 <adam_> it is within yocto directory
May 17 16:31:43 <adam_> as in yocto/oe-init...
May 17 16:31:50 <ag> what repo are you using?
May 17 16:32:42 <ag> i guess poky
May 17 16:32:50 <ag> anyway how did you change that variable?
May 17 16:32:58 <chackal_sjc> guys, what is "Pseudo is not present but is required, building this first before the main build" from bitbake?
May 17 16:33:16 <ag> chackal_sjc: Grep :) and you will see :)
May 17 16:33:27 <adam_> i changed the .bb in udev and systemd
May 17 16:33:35 <chackal_sjc> ag: grep where ;)
May 17 16:34:19 <adam_> i added the line near the top
May 17 16:34:50 <ag> chackal_sjc: Check bitbake script
May 17 16:35:14 <ag> chackal_sjc: L118
May 17 16:35:40 <ag> adam_: It should work. i thought you tried to modify that variable in the terminal directly :)
May 17 16:35:57 <ag> just clean your terminal and try again. something went wrong
May 17 16:36:12 <adam_> i seee
May 17 16:36:13 <bluelightning> chackal_sjc: it's normal, nothing to worry about
May 17 16:36:24 <adam_> clean terminal as in close it?
May 17 16:36:33 <bluelightning> chackal_sjc: it's just telling you what it is about to do
May 17 16:36:37 <ag> adam_: Start with that :)
May 17 16:36:37 <chackal_sjc> ok
May 17 16:36:44 <ag> chackal_sjc: yes
May 17 16:37:11 <chackal_sjc> ok, than I'm getting an error here (btw, I'm trying to bake my repice)
May 17 16:37:19 <adam_> alright thank youu
May 17 16:37:26 <ag> adam_: np
May 17 16:37:28 <bluelightning> chackal_sjc: what is the error?
May 17 16:38:10 <chackal_sjc> http://paste.kde.org/480908/
May 17 16:38:23 <chackal_sjc> this is the cat from the cooker log
May 17 16:39:10 <ag> i ran into this yesterday - if i remember right some variable was not defined in my image...
May 17 16:40:01 <chackal_sjc> ag: you mean the error that I pasted?
May 17 16:40:13 <ag> chackal_sjc: yes.
May 17 16:40:20 <chackal_sjc> what did you do about?
May 17 16:40:32 <chackal_sjc> felipe@mlabs-ftonello:~/projects/poky$ git pull
May 17 16:40:32 <chackal_sjc> Already up-to-date.
May 17 16:40:40 <ag> Tell me more what you did. Just added a bb in recipes?
May 17 16:40:43 <ag> Adn bitbake on it
May 17 16:40:44 <ag> ?
May 17 16:40:46 <ag> And*
May 17 16:40:50 <chackal_sjc> ok
May 17 16:41:21 <bluelightning> the only calls to split() are for DISTRO_FEATURES and MACHINE_FEATURES
May 17 16:41:30 <ag> y
May 17 16:41:33 <bluelightning> if either of those are None, something bad happened much earlier on
May 17 16:41:34 <chackal_sjc> felipe@mlabs-ftonello:~/projects/g2-metadata$ tree
May 17 16:41:34 <chackal_sjc> .
May 17 16:41:34 <chackal_sjc> └── meta-g2
May 17 16:41:34 <chackal_sjc>     ├── binary
May 17 16:41:34 <chackal_sjc>     │   ├── bootloader
May 17 16:41:34 <chackal_sjc>     │   └── zImage
May 17 16:41:35 <chackal_sjc>     ├── conf
May 17 16:41:35 <chackal_sjc>     │   ├── layer.conf
May 17 16:41:36 <chackal_sjc>     │   └── machine
May 17 16:41:36 <chackal_sjc>     │       └── g2.conf
May 17 16:41:37 <chackal_sjc>     └── recipes-kernel
May 17 16:41:37 <chackal_sjc>         └── linux
May 17 16:41:43 <ag> in my case was  MACHINE_FEATURES
May 17 16:42:04 <chackal_sjc> and I did a "bitbake linux-g2-master-kernel"
May 17 16:42:26 <ag> did you diedine the variables bluelightning mentioned above?
May 17 16:42:31 <ag> define*
May 17 16:42:34 <bluelightning> chackal_sjc: does g2.conf set MACHINE_FEATURES?
May 17 16:42:44 <chackal_sjc> one sec
May 17 16:42:49 <adam_> ag, it's still stuck =(
May 17 16:43:06 <chackal_sjc> no
May 17 16:43:08 <ag> adam_: Ask bluelightning or anybody around. I gotta go. Sorry and good luck!
May 17 16:43:16 <chackal_sjc> bluelightning: no it doesnt set
May 17 16:43:27 <ag> chackal_sjc: well you found your problem
May 17 16:43:35 <bluelightning> chackal_sjc: ok, you should set it as appropriate for your machine
May 17 16:43:45 <adam_> oh thank you!
May 17 16:43:59 <adam_> bluelightning! Thanks in advance =P
May 17 16:44:03 <ag> See ya guys!
May 17 16:44:07 <adam_> laterz
May 17 16:44:19 <chackal_sjc> ok, so let me check
May 17 16:45:54 <chackal_sjc> what should I put in MACHINE_FEATURES?
May 17 16:46:01 <bluelightning> adam_: you may want to apply this patch: http://patches.openembedded.org/patch/27571/
May 17 16:46:02 <chackal_sjc> the doc just says the obvious
May 17 16:46:15 <bluelightning> chackal_sjc: have a look at other machine conf files for examples
May 17 16:46:21 <chackal_sjc> and what's that for?
May 17 16:46:22 <chackal_sjc> sure
May 17 16:47:00 <bluelightning> chackal_sjc: http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#ref-features-machine
May 17 16:47:04 <adam_> blueligtning: ok let me try that
May 17 16:47:18 <bluelightning> chackal_sjc: that may not be a complete list though
May 17 16:47:42 <chackal_sjc> ok but whats that fore?
May 17 16:47:49 <chackal_sjc> it will set automatically stuff?
May 17 16:48:49 <adam_> blueligtning: i'm not sure what the right way is to apply a patch
May 17 16:49:01 <adam_> do i change the code manually or can i do something with git
May 17 16:49:18 <chackal_sjc> bluelightning: and also, where can I find all the lists?
May 17 16:51:08 <bluelightning> adam_: for a patch like that you can just do a git am patchfile.patch
May 17 16:51:36 <bluelightning> adam_: to save pain you may want to do this first: git checkout -b fix_branch
May 17 16:51:57 <bluelightning> adam_: that will put you on a separate branch; when you want to go back to master you can do "git checkout master"
May 17 16:52:15 <adam_> ok so that all happens in meta directory?
May 17 16:52:30 <bluelightning> adam_: no, one dir up from there
May 17 16:52:37 <adam_> ok
May 17 16:52:52 <adam_> so git checkout -b fix_branch first
May 17 16:52:58 <adam_> and then git am patchfile.patch?
May 17 16:54:06 <adam_> ~/Code/yocto$ git am patchfile.patch
May 17 16:54:17 <adam_> cat: /home/adam/Code/yocto/.git/rebase-apply/next: No such file or directory
May 17 16:54:24 <bluelightning> chackal_sjc: the complete list AFAICT is "acpi alsa apex apm bluetooth efi ext2 ext3 irda keyboard pcbios pci pcmcia phone qvga redboot screen serial touchscreen uboot usbgadget usbhost vfat wifi x86"
May 17 16:54:26 <adam_> previous rebase directory /home/adam/Code/yocto/.git/rebase-apply still exists but mbox given.
May 17 16:54:38 <bluelightning> chackal_sjc: some of those are probably obsolete though (eg. "phone")
May 17 16:55:27 <bluelightning> adam_: erm, sounds like you've done a rebase before and it didn't complete
May 17 16:55:43 <adam_> arg, what does that mean?
May 17 16:56:05 <bluelightning> adam_: have you ever done "git rebase" on this clone?
May 17 16:56:15 <adam_> nope
May 17 16:56:26 <bluelightning> ok... well that's strange, I wouldn't expect that error
May 17 16:56:40 <adam_> hm...
May 17 16:56:54 <adam_> i might have broken something. not so efficienty with git yet
May 17 16:57:03 <bluelightning> adam_: is this a fresh checkout or something you have been making changes to?
May 17 16:57:10 <adam_> i have been making changes
May 17 16:57:18 <bluelightning> ok
May 17 16:57:48 <bluelightning> are you at least on a named branch?
May 17 16:57:58 <adam_> yes it's named after me
May 17 16:57:59 <bluelightning> i.e. not in detached head state
May 17 16:58:02 <bluelightning> ok
May 17 16:58:03 <bluelightning> good
May 17 16:58:15 <adam_> well now it's on fix_branch
May 17 16:58:24 <bluelightning> ah ok
May 17 16:58:28 <adam_> =)
May 17 16:58:42 <bluelightning> do you still have modified files? i.e. does "git diff" report anything?
May 17 16:59:25 <adam_> diff --git a/bitbake/lib/bb/fetch2/wget.py b/bitbake/lib/bb/fetch2/wget.py
May 17 16:59:51 <adam_> there is an empty line that i seem to have removed
May 17 16:59:58 <adam_>          """Fetch urls"""
May 17 16:59:58 <adam_> -
May 17 16:59:58 <adam_>          if checkonly:
May 17 17:00:13 <bluelightning> adam_: ok... if you don't want to keep that change you can just do a git checkout bitbake/lib/bb/fetch2/wget.py
May 17 17:01:12 <bluelightning> if you have no other uncommitted changes, since you're on a separate branch you should be able to do a git rebase --abort
May 17 17:01:13 <adam_> done
May 17 17:01:40 <adam_> that's done too
May 17 17:01:53 <bluelightning> ok, now you should be able to "git am" the patch
May 17 17:02:22 <adam_> and i am still in /yocto directory?
May 17 17:02:25 <bluelightning> yep
May 17 17:02:28 <adam_> oks
May 17 17:03:28 <adam_> is it git amit's git am patchfile.patch?
May 17 17:03:42 <adam_> /usr/lib/git-core/git-am: line 180: patchfile.patch: No such file or directory
May 17 17:03:54 <adam_> =(
May 17 17:04:08 <bluelightning> adam_: yep that's what I meant, but I meant substute the name of the downloaded patch from the link I gave above...
May 17 17:04:18 <adam_> lol i see
May 17 17:04:33 <bluelightning> s/substute/substitute/
May 17 17:05:17 <adam_> git am ~/Downloads/1-1-kmod-fix-installation-path-of-pkgconfig-files.patch
May 17 17:05:18 <adam_> cat: /home/adam/Code/yocto/.git/rebase-apply/next: No such file or directory
May 17 17:05:18 <adam_> previous rebase directory /home/adam/Code/yocto/.git/rebase-apply still exists but mbox given.
May 17 17:05:49 <bluelightning> well that's just annoying
May 17 17:05:55 <incandescant> 'git rebase --abort' will clean that up
May 17 17:06:15 <bluelightning> incandescant: I just got adam_ to do that above and it seems to not have... :/
May 17 17:06:44 <incandescant> oh, if it's a git apply which failed use git apply --abort
May 17 17:06:57 <bluelightning> adam_: try that ^
May 17 17:13:16 <adam_> i appreciate your help, but i gotta runto something. I will report back =D
May 17 17:17:49 <bluelightning> ok, np
May 17 17:22:58 <halstead> pidge, I've added a 3600 second expiration header to all downloads. This may help with some of the proxy issues.
May 17 17:23:32 <pidge> halstead: ok. I'm writing up the work around to post to the list
May 17 17:23:54 <chackal_sjc> guys
May 17 17:24:06 <chackal_sjc> I'm using code sorcery toolchain
May 17 17:24:16 <chackal_sjc> but its getting an error while compiling
May 17 17:24:21 <chackal_sjc> ERROR: QA Issue: No GNU_HASH in the elf binary: '/home/felipe/projects/g2-yocto-distro/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/external-csl-toolchain-2009q1-203-r5/packages-split/libgcc/lib/libgcc_s.so.1'
May 17 17:24:35 <chackal_sjc> I've already added TARGET_CC_ARCH += "${LDFLAGS}" to the recipe
May 17 17:24:42 <chackal_sjc> but still getting the error
May 17 17:25:11 <kergoth`> hmm, anyone tried a centos5 build recently? kmod-native failing miserably. guess maybe its time to try 6
May 17 17:39:31 <pidge> halstead: sent out the work around. crosses fingers.
May 17 17:47:49 <halstead> pidge, Looks good!
May 17 17:57:38 <kergoth`> khem: you happen to know fhte minimum kernel version to build kmod offhand?
May 17 18:19:23 <khem> kergoth`: it uses some new syscalls from 2.6.33 onwards IIRC
May 17 18:19:33 <khem> kergoth`: whats error you are running into
May 17 18:21:35 <adam_> hello everyone, i am back with a different issue. My image is missing /lib/modules/3.2.0/kernel directory
May 17 18:21:51 <adam_> the kernel directory should contain the wifi driver, so i kinda need it =P
May 17 18:27:16 <kergoth`> khem: old host distro + kmod-native
May 17 18:27:24 <kergoth`> don't have hte error handy, was something undefined in the headers though
May 17 18:27:26 <kergoth`> unsurprising
May 17 18:30:32 <khem> kergoth`: yeah could be a new syscall/function
May 17 18:30:43 <khem> it uses lot of *at functions
May 17 18:30:46 <khem> which are relatively new
May 17 19:06:25 <ag> RP__1: Are you around?
May 17 19:23:11 <RP__> ag: kind of
May 17 19:24:55 <ag> RP__: I just wanted to know how to use BBMASK. But after digging into code i realized that i needs to be regex form.
May 17 19:25:04 <ag> RP__: How yocto training? :)
May 17 19:25:11 <ag> how's*
May 17 19:29:03 <RP__> ag: Not too bad thanks. There is a lot to teach I guess :)
May 17 19:29:13 <RP__> yes, BBMASK is regexp based
May 17 19:29:35 <ag> RP__: Good luck and watch the dogs. :)
May 17 19:29:56 <RP__> ag: I don't plan to go running ;-)
May 17 19:30:29 <adam_> Hmm I am trying to get wifi driver in my image
May 17 19:30:33 <ag> :) cheers! I'm working on rpi layer so back to work.
May 17 19:30:41 <adam_> i did bitbake -c menuconfig my_image
May 17 19:30:49 <adam_> and i get this Task do_menuconfig does not exist for target my_image
May 17 19:31:03 <ag> adam_: What do you want to do?
May 17 19:31:04 <adam_> =(
May 17 19:31:16 <adam_> hi ag
May 17 19:31:29 <adam_> my image does not seem to have wireless driver
May 17 19:31:35 <ag> adam_: hey. so you have a driver and want it in an image?
May 17 19:31:38 <RP__> adam_: menuconfig only exists for kernels at this point
May 17 19:31:49 <adam_> i think i have the driver
May 17 19:32:02 <ag> adam_: you have a bb file?
May 17 19:32:03 <adam_> not sure if it is the right driver
May 17 19:32:14 <adam_> but it's something ineed in my image so i can test it
May 17 19:32:14 <ag> it's supported in kernel?
May 17 19:32:29 <adam_> supported in kernal?
May 17 19:32:37 <adam_> i don't have a bb file
May 17 19:32:41 <adam_> just the driver
May 17 19:32:49 <ag> Which is compiled?
May 17 19:33:16 <adam_> yess
May 17 19:33:28 <adam_> wait i do have a bb file
May 17 19:33:37 <ag> and it's compiled for your target arhitecture?
May 17 19:33:41 <ag> architecture ?
May 17 19:34:21 <adam_> i have the file in /lib/firmware in my iamge
May 17 19:34:25 <adam_> it's an omap
May 17 19:34:28 <adam_> gumstix
May 17 19:34:55 <adam_> but i was expecting to see something in /lib/modules/3.2.0/kernel
May 17 19:35:09 <adam_> so i can use depmod and modprobe to load the driver
May 17 19:35:15 <ag> good i see
May 17 19:35:17 <adam_> not sure what iam saying makes sense
May 17 19:35:20 <adam_> yupp
May 17 19:35:26 <ag> but i asked you one thing
May 17 19:35:37 <ag> your driver is procompiled or do you have sources for it?
May 17 19:35:59 <ag> it's already in your distro?
May 17 19:35:59 <adam_> it's a .bin file?
May 17 19:36:02 <adam_> yes
May 17 19:36:06 <ag> ok
May 17 19:36:38 <ag> your bitbake driver_wifi works?
May 17 19:37:38 <adam_> haven't tried it. i should replace 'driver_wifi' with my own driver?
May 17 19:37:55 <ag> yes
May 17 19:38:26 <ag> i'm still not sure if you want to integrate a driver or to compile one from a distro.
May 17 19:38:47 <adam_> hmm
May 17 19:39:12 <adam_> i think what i want is to be able to
May 17 19:39:19 <adam_> boot up my image
May 17 19:39:24 <adam_> and have wifi connection +_+?
May 17 19:39:53 <ag> where is the driver?
May 17 19:40:00 <ag> gimme the recipe link
May 17 19:40:10 <adam_> 1 sec
May 17 19:42:50 <adam_> http://pastebin.com/bSZ4yiLg
May 17 19:43:45 <ag> You just have to add your package to IMAGE_INSTALL
May 17 19:44:38 <ag> Sorry for this late answer but i wasn't sure what you are trying to do.
May 17 19:44:42 <adam_> IMAGE_INSTALL?
May 17 19:44:49 <ag> What image are you using?
May 17 19:44:50 <adam_> oh no problem, thank you for your help=)
May 17 19:45:20 <adam_> it's a custom build of my colleague
May 17 19:45:35 <ag> Go to that image and add at the end:
May 17 19:45:43 <ag> IMAGE_INSTALL += "mydriver"
May 17 19:45:52 <adam_> like in the conf/layer.conf file?
May 17 19:45:52 <ag> got it/
May 17 19:46:03 <ag> No. In the image file.
May 17 19:46:14 <adam_> ohohoh
May 17 19:46:28 <adam_> as in my_image.bb in recipes-images folder?
May 17 19:46:36 <ag> bingo!
May 17 19:46:37 <adam_> got it
May 17 19:46:54 <ag> In this was you include a single package
May 17 19:47:07 <adam_> hm
May 17 19:47:10 <adam_> it is in there already?
May 17 19:47:34 <ag> the best way is to create task and add you package in that task and add the task to image's IMAGE_INSTALL
May 17 19:47:56 <ag> but anyway
May 17 19:48:04 <ag> for a single package you can add it just like this
May 17 19:48:11 <adam_> ok, but my IMAGE_INSTALL already has the package
May 17 19:48:32 <ag> you are using rpms?
May 17 19:48:36 <adam_> yes
May 17 19:48:49 <ag> what rpm's are generated by your driver recipe?
May 17 19:49:04 <adam_> 1 sec
May 17 19:53:50 <adam_> its'a marvell chipset but i can't find the rpm
May 17 19:54:12 <ag> ok now, go in you build
May 17 19:54:34 <ag> tmp / work
May 17 19:54:39 <ag> what do you have there?
May 17 19:55:48 <adam_> all-poky-linux  all-poky-linux-gnueabi  armv7a-vfp-neon-poky-linux-gnueabi  overo-poky-linux-gnueabi  x86_64-linux
May 17 19:56:11 <adam_> i was looking for my rpm in arm7a-vfp...gnueabi
May 17 19:56:16 <adam_> couldn't find it there
May 17 19:56:20 <ag> go in arm
May 17 19:56:27 <adam_> ok
May 17 19:56:29 <ag> search for your driver
May 17 19:56:53 <adam_> i did find ./ -name marvel in work directory
May 17 19:56:54 <ag> deploy-rpms
May 17 19:56:58 <adam_> it's stillr runnig
May 17 19:57:03 <adam_> still running*
May 17 19:57:09 <ag> what is still running?
May 17 19:57:14 <adam_> the find command
May 17 19:57:27 <adam_> now it's down, didn't find anything
May 17 19:57:34 <ag> forget the command
May 17 19:57:38 <adam_> lol ok
May 17 19:57:39 <ag> go in arm...
May 17 19:57:44 <adam_> ok
May 17 19:57:49 <ag> how is your driver recipe called?
May 17 19:58:29 <adam_>   marvell-sdio-fw \
May 17 19:58:43 <adam_> is my recipe listed in image.bb
May 17 19:59:02 <ag> marvell-sdio-fw.bb?
May 17 19:59:45 <adam_> marvell-sdio-fw_9.70.3-p37.bb
May 17 19:59:50 <adam_> is my recipe
May 17 19:59:56 <adam_> file name.
May 17 20:00:00 <ag> very good
May 17 20:00:31 <adam_> =)
May 17 20:00:41 <ag> bitbake marvell-stdio-fw
May 17 20:00:48 <adam_> kk
May 17 20:00:58 <ag> search for it in tmp/work dirs
May 17 20:01:12 <ag> and inside you will find deploy_rpms
May 17 20:01:31 <ag> tell me which rpm includes your driver
May 17 20:01:36 <adam_> ERROR: Nothing PROVIDES 'marvell-stdio-fw'
May 17 20:01:38 <adam_> =(
May 17 20:01:47 <adam_> i guess this is it
May 17 20:01:57 <ag> this recipe is in your layer?
May 17 20:02:04 <ag> did you add this layer to bblayers?
May 17 20:02:15 <adam_>   marvell-sdio-fw \
May 17 20:02:23 <adam_> is in my image bb file
May 17 20:02:39 <ag> where is located marvell-sdio-fw_9.70.3-p37.bb?
May 17 20:03:07 <adam_> it's in /home/adam/Code/yocto/meta-gumstix/recipes-bsp/firmwares
May 17 20:03:22 <ag> and you are using poky?
May 17 20:03:48 <adam_> hmm i think so?
May 17 20:03:54 <ag> do you have /home/adam/Code/yocto/meta-gumstix in ${BUILDPATH}/conf/bblayers.conf?
May 17 20:04:36 <adam_>  /home/adam/Code/yocto/meta-gumstix \
May 17 20:04:41 <adam_> is in my bblayers.conf?
May 17 20:04:52 <ag> I'm asking you this... :)
May 17 20:04:56 <ag> Is it?
May 17 20:04:56 <adam_> lol
May 17 20:04:57 <adam_> yes
May 17 20:04:58 <adam_> it is
May 17 20:06:01 <ag> wait to try it.
May 17 20:06:30 <adam_> k thankls ag
May 17 20:08:07 <ag> you will have to wait a sec. gimme you image file as well
May 17 20:08:16 <ag> your*
May 17 20:08:46 <adam_> jusdt the .bb right?
May 17 20:09:05 <ag> yes
May 17 20:09:07 <adam_> kk
May 17 20:10:16 <adam_> http://pastebin.com/c5VnkP1V
May 17 20:10:45 <adam_> thank you for your help btw
May 17 20:10:55 <ag> no worries
May 17 20:11:04 <ag> image seems ok
May 17 20:11:18 <ag> so there is a problem with our package file
May 17 20:12:07 <adam_> package file as in our recipe.bb?
May 17 20:15:05 <ag> lol
May 17 20:15:10 <adam_> =D
May 17 20:15:14 <ag> The problem is your filename mate...
May 17 20:15:19 <adam_> LOL
May 17 20:15:38 <ag> ERROR: Nothing PROVIDES 'marvell-stdio-fw'
May 17 20:15:40 <adam_> my binary file?
May 17 20:15:46 <ag> Is not stdio
May 17 20:15:51 <ag> is adio
May 17 20:15:53 <ag> sdio
May 17 20:15:58 <adam_> ........
May 17 20:16:06 <adam_> ...
May 17 20:16:06 <ag> Right?
May 17 20:16:07 <adam_> omg
May 17 20:16:28 <ag> Am i right?
May 17 20:17:13 <adam_> hmmm 1 sec
May 17 20:17:15 <adam_> +_+
May 17 20:18:02 <adam_> omg... sorry i ran wrong bitbake
May 17 20:18:10 <adam_> bitbake marvell-sdio-fw
May 17 20:18:10 <ag> as i said.
May 17 20:18:13 <adam_> works fine..
May 17 20:18:21 <ag> ok.
May 17 20:18:27 <adam_> sorry
May 17 20:18:28 <ag> so now everything it's ok right>
May 17 20:18:29 <ag> >
May 17 20:18:47 <adam_> checking for rpm fiole
May 17 20:18:49 <adam_> file*
May 17 20:19:07 <ag> trust me. Now everything should be ok.
May 17 20:19:27 <ag> bake your image and check for your driver in tar or whatever your image is
May 17 20:20:22 <adam_> hmm sorry but what's different now and before?
May 17 20:20:35 <adam_> i got error when i did bitbake marvell-stdio-fw
May 17 20:20:39 <adam_> because of the typo
May 17 20:20:52 <adam_> but that doesn't affect bitbake my_image right?
May 17 20:21:37 <adam_> i still don't see marvell-sdio-fw in my /tmp/work/arm directory..
May 17 20:21:42 <ag> your driver is called marvell-sdio-fw
May 17 20:21:52 <adam_> yes
May 17 20:21:57 <ag> this driver is included in your image
May 17 20:22:07 <adam_> yes
May 17 20:22:08 <ag> so just bake your image and everything will be ok
May 17 20:22:16 <ag> last time you had a typo
May 17 20:22:23 <ag> this is way there was no marvell-stdio-fw
May 17 20:23:23 <adam_> hmmm sorry i am not following
May 17 20:23:50 <adam_> so bitbake marvell-sdio-fw was required
May 17 20:23:55 <adam_> before doing bitbake my_image?
May 17 20:23:59 <ag> no
May 17 20:24:07 <ag> but it was a test
May 17 20:24:14 <adam_> yes
May 17 20:24:16 <ag> to see that you can bake you driver
May 17 20:24:20 <adam_> yup
May 17 20:24:20 <ag> after that
May 17 20:24:29 <ag> just bake your image
May 17 20:24:34 <ag> and that's it
May 17 20:24:43 <adam_> hmm i baked my image before
May 17 20:25:04 <adam_> hmmmm
May 17 20:25:20 <ag> bake your image
May 17 20:25:24 <adam_> ok
May 17 20:25:41 <ag> and then check for total_solution_manifest file
May 17 20:25:49 <ag> is located in the temp directory of your image
May 17 20:25:52 <adam_> okk i'm building now
May 17 20:26:01 <ag> and tell me if you can find your driver rpm there
May 17 20:26:10 <adam_> ok
May 17 20:27:01 <adam_> it's doing do_rootfs.. almost there
May 17 20:27:49 <ag> ok
May 17 20:31:00 <adam_> sorry the total_solution_manifest is in build/tmp?
May 17 20:31:10 <adam_> i can't find it in tmp
May 17 20:31:50 <ag> as i said in the tmp directory of the image;s build location
May 17 20:32:10 <ag> /tmp/work/blablabla/yourimage/temp
May 17 20:32:18 <adam_> ohohoh
May 17 20:34:36 <adam_> i couldn't find it, so i ran this tmp/work$ find ./ -name total_solution_manifest
May 17 20:34:41 <adam_> doesn't return anything =(
May 17 20:35:02 <ag> Man. I didn't write the exactly file name...
May 17 20:35:09 <ag> Just look into the path i told you
May 17 20:35:16 <adam_> sorry
May 17 20:35:18 <adam_> hold onnn
May 17 20:35:33 <ag> total_solution.manifest
May 17 20:35:49 <adam_> lol i got it
May 17 20:35:53 <adam_> yes it is in there
May 17 20:35:55 <adam_> =D
May 17 20:36:06 <adam_> yocto/build/tmp/deploy/rpm/all/marvell-sdio-fw-9.70.3+p37-r1.all.rpm
May 17 20:36:08 <adam_> yay
May 17 20:36:15 <ag> good
May 17 20:36:26 <ag> problem solved
May 17 20:36:36 <adam_> alright thanks ag
May 17 20:36:37 <adam_> =)
May 17 20:36:42 <adam_> i'm gonna test it out now!
May 17 20:36:46 <adam_> i appreciate your help
May 17 20:37:01 <ag> No problem adam_
May 17 20:37:18 <ag> But as a very good practice go and read the yoctoproject's documentation
May 17 20:37:32 <ag> it will clear a lot up a lot of problems
May 17 20:37:40 <adam_> yes... that should hlep
May 17 20:38:40 <adam_> =)
May 17 21:00:47 <adam_> hm.. arg
May 17 21:01:06 <adam_> ifup wlan0 complains it can't read interface
May 17 21:01:12 <adam_> that there is no such device
May 17 21:15:23 <chackal_sjc> guys
May 17 21:15:36 <chackal_sjc> I'm having a GNU_HASH error all the time
May 17 21:15:37 <chackal_sjc> ERROR: QA Issue: No GNU_HASH in the elf binary: '/home/felipe/projects/g2-yocto-distro/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/external-csl-toolchain-2009q1-203-r5/packages-split/libgcc/lib/libgcc_s.so.1'
May 17 21:15:53 <chackal_sjc> the problem is that it isn't in my recipe, its here
May 17 21:16:09 <chackal_sjc> ERROR: Task 87 (/home/felipe/projects/poky/meta/recipes-core/meta/external-csl-toolchain.bb, do_package) failed with exit code '1'
May 17 21:16:25 <fray> that toolchain is too old.. you need a newer one
May 17 21:16:50 <fray> the alternative if you must use an old toolchain, is to disable the gnu_hash support and revert back to sysv
May 17 21:17:21 <chackal_sjc> how can I desable the gnu_hash support and revert back to sysv?
May 17 21:18:03 <fray> I'm looking it up..
May 17 21:18:56 <fray> in your local.conf -- LINKER_HASH_STYLE = "sysv"
May 17 21:19:21 <chackal_sjc> thanks, lemme try
May 17 21:33:26 <adam_> fray, have you dealt with wifi drivers? My linux distro loads everything fine (usb and etc) except for wifi
May 17 21:33:34 <fray> nope
May 17 21:33:54 <adam_> ok
May 17 22:16:01 <chackal_sjc> guys
May 17 22:16:08 <chackal_sjc> I have a recipe, righ
May 17 22:16:23 <chackal_sjc> I just want to run that recipe, why does the poky runs a bunch of bitbake?
May 17 22:17:20 <chackal_sjc> take a look at my recipe: http://paste.kde.org/481226/
May 17 22:17:32 <chackal_sjc> and its not doing the configuration that I want
May 17 22:17:40 <chackal_sjc> and also I can't see the compiled source
May 17 22:17:55 <chackal_sjc> also I don't want to package anything.. just to run the recipe
May 17 22:22:28 <bluelightning> chackal_sjc: what do you mean by "running" the recipe?
May 17 22:22:43 <chackal_sjc> i mean
May 17 22:22:57 <chackal_sjc> I would like to run 'bitbake recipe' and configure and compile my kernel code
May 17 22:23:01 <chackal_sjc> thats all
May 17 22:23:08 <bluelightning> chackal_sjc: all that other stuff that bitbake is doing, is almost certainly necessary steps that have to be done in order to be able to run the tasks within your recipe
May 17 22:23:26 <bluelightning> like, you can't expect to cross-compile your kernel if there is no cross-compiler yet, for example
May 17 22:23:44 <chackal_sjc> bluelightning: but I have the crosscompiler
May 17 22:23:51 <bluelightning> that's just one example
May 17 22:23:51 <chackal_sjc> thats why I'm telling you
May 17 22:24:03 <bluelightning> so what is it doing that you think it shouldn't be?
May 17 22:24:18 <chackal_sjc> bitbake is compiling a bunch of stuff
May 17 22:24:27 <bluelightning> could you provide some details?
May 17 22:24:52 <chackal_sjc> bash, gettext, etcetc
May 17 22:25:27 <bluelightning> so, this is just from memory, but afaik bash is pulled in because perf (part of the kernel tools) needs it
May 17 22:25:53 <chackal_sjc> can you tell me how to make my recipe just do this: clone the branch of the git, run the do_configure that I wrote, and than do_compile that I wrote?
May 17 22:26:09 <adam_> anyone familiar with how yocto handles/generate kernel objct files (.ko files) for device drivers?
May 17 22:26:28 <bluelightning> don't forget that when you say bitbake virtual/kernel, what you're really saying is "build me a kernel suitable for putting in an image on the device" i.e. it's going to need to package it, and build everything that the packages would need when deployed on the target system
May 17 22:26:52 <bluelightning> you can skip a bunch of that by doing bitbake -c compile virtual/kernel
May 17 22:27:07 <bluelightning> but it's still going to have to do some stuff first, there is no way around that
May 17 22:34:29 <bluelightning> chackal_sjc: looking at that recipe, you have ${PN}_ in front of do_*, that is not going to work AFAIK
May 17 22:34:49 <chackal_sjc> hmm
May 17 22:34:56 <bluelightning> that might be why those never get used right now
May 17 22:35:23 <chackal_sjc> bluelightning: my recipe's name is linux-g2-master-kernel.bb
May 17 22:35:32 <bluelightning> also you should not be setting ARCH in there
May 17 22:35:45 <chackal_sjc> should I rename the function linux-g2-master-kernel_do_* ?
May 17 22:35:50 <chackal_sjc> bluelightning: where?
May 17 22:35:58 <bluelightning> no, just call it do_*
May 17 22:36:14 <bluelightning> chackal_sjc: it says ARCH = "arm" towards the top
May 17 22:36:45 <chackal_sjc> ii know
May 17 22:36:50 <bluelightning> at best that will do nothing, at worst it will break hideously if you tried to build it for some other architecture (I realise you probably wouldn't, but there it is)
May 17 22:36:50 <chackal_sjc> I mean, where should I put ir?
May 17 22:36:51 <chackal_sjc> it
May 17 22:37:10 <bluelightning> I guess I would ask what you are trying to do by adding it...?
May 17 22:37:45 <chackal_sjc> well.. lets just forget about that =)
May 17 22:37:50 <chackal_sjc> let me see if it works
May 17 22:38:04 <bluelightning> also, since this is a kernel recipe, you should really be doing "inherit kernel"
May 17 22:38:16 <bluelightning> that takes care of a whole bunch of things to do with building the kernel
May 17 22:38:57 <bluelightning> I'm sure we have some examples somewhere that you could copy...
May 17 22:39:58 <chackal_sjc> really? but why?
May 17 22:40:37 <bluelightning> sorry, why what?
May 17 22:41:07 <chackal_sjc> inherit kernel
May 17 22:41:55 <chackal_sjc> I can't understand why bitbake is running so many tasks just to build the kernel..
May 17 22:41:56 <bluelightning> chackal_sjc: have a look at meta/classes/kernel.bbclass and you'll see some of the things it is doing
May 17 22:42:31 <chackal_sjc> like, it running sqlie3 recipe, why !?
May 17 22:42:35 <bluelightning> chackal_sjc: it's a dependency chain, you ask it to build something and it will go off and ensure that dependency chain is satisfied
May 17 22:42:54 <chackal_sjc> bluelightning: yeah, but I have no dependencies.. thats why
May 17 22:43:07 <bluelightning> every recipe has default dependencies
May 17 22:43:23 <bluelightning> chackal_sjc: if you want you can see an entire dependency graph for the thing you are building by doing bitbake -g -u depexp virtual/kernel
May 17 22:43:46 <chackal_sjc> ok
May 17 22:43:48 <bluelightning> or for just plain graphviz graphs you can view externally: bitbake -g virtual/kernel
May 17 22:44:10 <bluelightning> that shows in detail how it ends up building those things it is building
May 17 22:51:01 <chackal_sjc> bluelightning: why my kernel has so many dependencies if I didn't set any?
May 17 22:51:26 <bluelightning> chackal_sjc: every recipe has a set of default dependencies applied
May 17 22:51:33 <bluelightning> chackal_sjc: it has to be that way or nothing would work
May 17 22:51:52 <chackal_sjc> but why?
May 17 22:57:45 <bluelightning> chackal_sjc: for anything that is intended to be built for the target, there are requirements
May 17 22:58:01 <bluelightning> chackal_sjc: the cross-compiler, tools it needs to build, libraries it has to link to, etc.
May 17 22:58:29 <chackal_sjc> bluelightning: ok, but I will explain
May 17 22:58:51 <chackal_sjc> I already have all the external toolchain
May 17 22:59:08 <chackal_sjc> so I set this in my local.conf
May 17 22:59:09 <chackal_sjc> TCMODE = "external-csl"
May 17 22:59:09 <chackal_sjc> EXTERNAL_TOOLCHAIN = "/home/felipe/bin/CodeSourcery/Sourcery_G++_Lite"
May 17 22:59:20 <chackal_sjc> where is the root dir of the toolchain, ok
May 17 22:59:25 <chackal_sjc> so I don't need to build anything
May 17 22:59:56 <bluelightning> I don't use external toolchains, myself, so I can't really give you any specific advice on that
May 17 23:00:23 <bluelightning> however if bitbake is building something it means it does not know that it is provided
May 17 23:00:51 <bluelightning> our external toolchain recipe tells bitbake it provides a bunch of things, but maybe it doesn't declare everything that appears in your specific toolchain, I don't know
May 17 23:01:02 <bluelightning> if you still aren't convinced I can only say, follow the dependencies via depexp or the graphs as I mentioned above, that will explain it completely why it is building everything it is building
May 17 23:01:23 <bluelightning> kergoth` might be able to help you with external toolchain stuff, he has worked on that recently
May 17 23:02:28 <seebs> I've been using the external-csl stuff too.
May 17 23:02:50 <seebs> I haven't actually looked super-closely at what it's doing.
May 17 23:03:05 <chackal_sjc> really.. the graph is huge
May 17 23:03:10 <chackal_sjc> it calls more than 500 recipes
May 17 23:04:29 <seebs> A lot of those will be host tools.  And come to think of it.
May 17 23:04:46 <chackal_sjc> for nothing, right
May 17 23:04:47 <seebs> I am not sure, but I think yocto will in some cases build a HOST toolchain even if you're using the CSL toolchain for CROSS compiles.
May 17 23:05:05 <chackal_sjc> hmm
May 17 23:05:09 <chackal_sjc> looks like it
May 17 23:05:30 <chackal_sjc> yocto is not yet fully prepared for extern toolchain I believe
May 17 23:06:05 <chackal_sjc> how to unset any LDFLAGS and stuff like that?
May 17 23:06:09 <seebs> Works fine for my purposes.
May 17 23:06:20 <seebs> Hmm.  Unset them why?  This sounds disturbing.
May 17 23:06:27 <chackal_sjc> | arm-none-linux-gnueabi-ld: unrecognized option '-Wl,-O1'
May 17 23:06:27 <chackal_sjc> | arm-none-linux-gnueabi-ld: use the --help option for usage information
May 17 23:06:41 <chackal_sjc> I didn 't set that
May 17 23:06:51 <chackal_sjc> for my kernel recipe
May 17 23:07:28 <chackal_sjc> brb
May 17 23:09:52 <seebs> That might not be coming from LDFLAGS to begin with, sounds like the compiler being Helpful.
May 17 23:13:55 <fray> actually that sounds like something is calling ld, when gcc is what they wanted
May 17 23:31:39 <khem> when setting LDFLAGS in bitbake.conf we assume that we are using gcc driver for linking and not bare ld as is the case above
May 17 23:32:09 <khem> in kernel e.g. you should be overriding LDFLAGS that comes from bitbake anyway
May 17 23:32:31 <khem> so find out why is LDFLAGS is being still not overidden
May 17 23:35:59 <kergoth`> chackal_sjc: i do builds for 8+ machines with an external toolchain and oe-core every day
May 17 23:36:06 <kergoth`> for what that's worth
May 17 23:46:03 <fray> ok.. rpm v2 patches out.. I'm heading home.. later!
May 18 00:10:12 <chackal_sjc> kergoth`: what you mean by that?
**** ENDING LOGGING AT Fri May 18 02:59:58 2012

**** BEGIN LOGGING AT Fri May 18 02:59:58 2012
May 18 07:07:38 <mckoan> good morning
May 18 10:51:49 <eballetbo> Hi, I would like to know your opinion. Do you think that can be problematic merge meta-toolchain-gmae + meta-toolchain-qte in a unique meta-toolchain-sdk ?
May 18 13:22:14 <sgw> bluelightning: you around?  Want to talk with you about bug#2336
May 18 13:22:22 <bluelightning> sgw: yep
May 18 13:23:06 <sgw> bluelightning: I was talking with RP about this issue this morning and he thought you might be able to help, I need to add some more information to the bug, but wanted to talk with you about it.
May 18 13:23:44 <bluelightning> I'd probably have to see how it shows up in hob, but sure I could have a look
May 18 13:25:51 <sgw> bluelightning: It shows the same bb.fatal() message from sanity.bbclass but "scrunched" into a dialog box
May 18 13:26:02 <sgw> I just updated the bug BTW
May 18 13:26:27 <bluelightning> sgw: ok... I think we want to raise the error a different way than bb.fatal() anyway to avoid the debug output
May 18 13:28:26 <sgw> bluelightning: that would be good also, but hob need a way to capture the msg part of the error only and not the initial text if you catch my meaning
May 18 13:29:21 <bluelightning> sgw: yeah, I think a specific error class could do that
May 18 13:30:09 <sgw> bluelightning: Ok can I assign this to you, it is a 1.2.1 issue, not sure how much you have on your plate?
May 18 13:30:23 <sgw> or if you can describe it to me I can make the fix
May 18 13:36:11 <bluelightning> sgw: just did a proof of concept but unfortunately it doesn't work, I'll probably have to consult with RP
May 18 13:36:39 <bluelightning> sgw: but it should be OK for me to do it by early next week
May 18 13:40:45 <sgw> bluelightning: great thanks
May 18 13:41:20 <sgw> bluelightning: assigned
May 18 14:26:56 <msm> anyone notice bitbake is not a the yocto projects page?
May 18 14:27:35 <ignus> hi all - does anyone know what might cause this error (after upgrading from 1.1 to 1.2) "ERROR: Unable to determine endianness for architecture 'INVALID'"
May 18 14:28:16 <autif> ignus - what machine?
May 18 14:28:49 <ignus> its for an internal machine
May 18 14:29:18 <autif> I meant what is MACHINE specified in conf/local.conf
May 18 14:30:03 <bluelightning> ignus: looks like HOST_ARCH is not set...
May 18 14:30:14 <bluelightning> ignus: hi btw
May 18 14:30:34 <ignus> bluelightning: hi, hows it going?
May 18 14:30:37 <bluelightning> HOST_ARCH is set from TARGET_ARCH
May 18 14:30:44 <bluelightning> ignus: good, and you?
May 18 14:31:35 <ignus> great, brain is melted at this point, trying to context switch from buildbot back to yocto and the upgrade to 1.2 is first thing on the list... i think friday afternoon might not be the right time to tackle this job :D
May 18 14:31:48 <bluelightning> ignus: possibly not :)
May 18 14:32:04 <bluelightning> ignus: let me know if I can help at all
May 18 14:32:32 <ignus> bluelightning: ok cool!
May 18 14:38:14 <ignus> bluelightning: so where is TARGET_ARCH set?
May 18 14:47:38 <bluelightning> ignus: generally it's set via the machine config file - could be in the config file itself or the tune includes it pulls in
May 18 15:11:56 <kergoth`> msm: I don't think bitbake is part of yocto directly, only via poky, no?
May 18 15:14:15 <msm> well
May 18 15:14:24 <msm> kergoth`: oe-core is listed there
May 18 15:14:34 <kergoth`> ah
May 18 15:14:35 <msm> seems like it's a project within the umbrella
May 18 15:14:48 <msm> you can't use much on that list of projects w/o bitbake ;)
May 18 15:14:59 <kergoth`> poky is under the umbrella, and poky includes it
May 18 15:15:01 <msm> maybe technically it's not? ;)
May 18 15:15:03 <kergoth`> you can't get poky without it
May 18 15:15:06 * kergoth` shrugs
May 18 15:15:22 <msm> kergoth`: right its just not 100% clear in my head how all users would get that right away
May 18 15:15:30 <msm> but its just a nit pick anyways
May 18 15:15:32 <kergoth`> fair point
May 18 15:15:35 <msm> wanted to see if anyone thought anything
May 18 15:15:38 <kergoth`> either way, if oe-core is there, bitbake should be
May 18 15:15:42 <kergoth`> they're on equal footing
May 18 15:15:45 <msm> kergoth`: that was my thought
May 18 15:15:50 <kergoth`> or neither should be, one or the other
May 18 15:15:54 * kergoth` doesn't really care, was just curious
May 18 15:19:48 <kergoth`> can someone explain where exactly a bug againsta  class in oe-core goes in the bugzilla, 'layers' or 'meta recipes'? and why are these even separate?
May 18 15:20:15 <kergoth`> also, why is 'poky' listed as a separate item including bitbake but not oe-core?
May 18 15:20:17 * kergoth` scratches head
May 18 15:23:09 <fray> there was a plan to change the categories, I don't know when it's going to be implemented..
May 18 15:23:56 <kergoth`> ah, k
May 18 15:24:09 <kergoth`> i assume its largely remnants of the old pokylinux.org db
May 18 15:24:11 <kergoth`> ?
May 18 15:24:13 <fray> yes
May 18 15:24:17 <kergoth`> k, np
May 18 15:25:29 * kergoth` hasn't used the bugzilla too much, but is trying to do better at active project participation rather than just pushing bits he's already done :)
May 18 15:28:18 <incandescant> I believe layers is non-core layers (meta-yocto, meta-intel, etc) but I don't really know
May 18 15:28:50 <incandescant> the only big difference seems to be default assignee but the bugs get triaged weekly, so it's no big deal
May 18 15:28:51 <fray> I usually just pick build system or whatever the similar category is.. and let someone else sort it out..
May 18 15:28:56 <incandescant> that
May 18 15:28:58 <kergoth`> hrmph. well i assume the bugs i just opened can be moved if need be
May 18 15:28:59 <kergoth`> k
May 18 15:29:17 <incandescant> yeah, someone will move them if needed
May 18 15:44:41 <mckoan> I wonder if exist any document explaining how to build a xorg based image with yocto for a generic Atom cpu, this seems nice but uses core-image-minimal http://www.yoctoproject.org/download/bsp/intel-atom-based-pcs-and-devices
May 18 15:45:32 <mckoan> I need to understand how to go further than a basic minimal console with yocto
May 18 15:45:36 <kergoth`> so build core-image-sato instead
May 18 15:45:44 <kergoth`> you don't need new instructions to build a different image
May 18 15:45:54 <kergoth`> it's just a bitbake command
May 18 15:47:40 <mckoan> kergoth`: thx, BTW where are located the images? (something like recipes/images/*)
May 18 15:48:06 <fray> find meta* -name *-image-*
May 18 15:48:13 <fray> that will get you all of the possible stock images..
May 18 15:48:20 <fray> easiest way to generate custom images is use hob
May 18 15:49:15 <mckoan> and could you please confirm that I have to use yocto-7-denzil?
May 18 15:49:29 <fray> that is the last release version..
May 18 15:49:38 <fray> but you can use any git version you like
May 18 15:51:32 <mckoan> thank you :-)
May 18 16:02:34 <mckoan> have a nice rest of the day
May 18 16:03:10 <mckoan|away> BTW bitbake core-image-sato in progress...
May 18 16:14:52 <adam_> Does anyone know how i can ask yocto to build kernel objects?
May 18 16:15:01 <adam_> Specifically my wireless driver...
May 18 16:15:22 <adam_> It doesn't seem like it places any of the .ko files in /lib/modules
May 18 16:18:07 <bluelightning> adam_: is this an in-tree driver or out-of-tree?
May 18 16:18:44 <bluelightning> i.e. is it part of the kernel or separate
May 18 16:20:02 <adam_> hmm it's something i added into my image
May 18 16:20:23 <adam_> as in my_image.bb file
May 18 16:20:49 <bluelightning> so the module is already built? or not?
May 18 16:20:59 <adam_> i have a .bin file for the driver?
May 18 16:21:10 <adam_> and i can bitbake it too separately
May 18 16:21:14 <adam_> i get no errors
May 18 16:21:19 <bluelightning> I'm totally confused now
May 18 16:21:43 <adam_> hmm sorry =P
May 18 16:21:47 <adam_> the situation is this:
May 18 16:22:11 <adam_> upon boot up of my image
May 18 16:22:16 <adam_> i have no network devices
May 18 16:22:26 <adam_> i can see the message during boot up too
May 18 16:22:42 <adam_> so as i normally do, i try to modprobe my_driver
May 18 16:22:48 <adam_> but i get errors like this:
May 18 16:23:07 <adam_> wl12xx: Unknown symbol ieee80211_stop_queues (err 0)
May 18 16:23:13 <adam_> when i do depmod -a
May 18 16:23:22 <adam_> WARNING: could not open /lib/modules/3.2.0/modules.order: No such file or directory
May 18 16:23:25 <adam_> WARNING: could not open /lib/modules/3.2.0/modules.builtin: No such file or directory
May 18 16:23:28 <adam_> i get the above as well
May 18 16:23:44 <adam_> so i think there is something wrong with how the kernel objects and modules are installed
May 18 16:23:53 <bluelightning> was the driver packaged properly or did you just copy the .ko file in by hand?
May 18 16:24:10 <adam_> oh initially there was no .ko files at all in my image
May 18 16:24:23 <adam_> but when i searched in my yocto/build directory, i saw the .ko files
May 18 16:24:44 <adam_> running out of things to do, i tried copying them into /lib/modules/3.2.0/kernel
May 18 16:24:57 <adam_> that's when i did modprobe on the driver, and got the errors
May 18 16:25:15 <bluelightning> ok, so the proper way to install a kernel module is to install the kernel-module-your-driver package
May 18 16:25:48 <adam_> hm is there a tutorial on that?
May 18 16:25:51 <bluelightning> that will ensure all dependencies are pulled in
May 18 16:25:58 <adam_> ok..
May 18 16:26:07 <adam_> hm package as in a recipe right?
May 18 16:26:10 <adam_> i do have the recipe
May 18 16:26:17 <adam_> that's how i included my driver
May 18 16:26:39 <adam_> but are you saying there is another package that i need for kernel modules?
May 18 16:27:12 <bluelightning> package as in package for the target system, i.e. rpm/ipk
May 18 16:27:29 <bluelightning> which would be produced either from the kernel recipe or some external module recipe
May 18 16:27:53 <adam_> hmm i am using PACKAGE_RPM
May 18 16:27:59 <bluelightning> each kernel module that is built out of the standard kernel tree is put into its own separate package
May 18 16:28:25 <dvhart> where does this module come from?
May 18 16:28:31 <dvhart> sounds like it is an out of tree driver
May 18 16:28:34 <adam_> sorry i am not sure what exactly i have to do
May 18 16:28:34 <bluelightning> dvhart: that's what I'm trying to ascertain...
May 18 16:28:43 <adam_> it's something my colleague found online
May 18 16:28:46 <adam_> i can show you the .bb
May 18 16:28:48 <adam_> 1 sec
May 18 16:29:15 <adam_> http://pastebin.com/18AFMrrQ
May 18 16:29:18 <dvhart> if it's an out of tree driver, follow the meta-skeleton/recipes-kernel/hello-mod example
May 18 16:29:29 <adam_> bluelightning, brb in 3 min
May 18 16:29:40 <dvhart> that's just the firmware
May 18 16:29:43 <dvhart> not a kernel module
May 18 16:30:19 <seebs> Hey, would anyone object to a patch which disabled sanity checks when running bitbake -e?
May 18 16:30:38 <seebs> It turns out that having sanity checks fail prevents me from looking at the include/variable tracking to find out why they failed.
May 18 16:31:55 <dvhart> adam_, see the meta-intel common dir for an example on how to extend the linux-firmware package to provide the firmware you need. See the meta-intel/meta-fri2 linux-yocto bbappends for how to ensure the wireless driver is installed with the image.
May 18 16:34:23 <bluelightning> seebs: that sounds useful to me
May 18 16:35:20 <adam_> hm
May 18 16:35:34 <adam_> out of tree driver - does this mean it's not included in kernel by default?
May 18 16:36:08 <dvhart> adam_, out-of-tree means the source for the driver is not provided by the linux recipe you are using
May 18 16:36:14 <adam_> looking into meta-intel now. thanks for all your help btw
May 18 16:36:31 <adam_> i see. so yes it is an out-of-tree driver
May 18 16:36:43 <dvhart> adam_, you need two pieces: 1) the kernel driver and 2) the firmware
May 18 16:36:49 <dvhart> adam_, the recipe you posted is for the firmware
May 18 16:36:54 <dvhart> which gets loaded at boot
May 18 16:37:02 <adam_> oh i seee
May 18 16:37:12 <adam_> thank youu
May 18 16:37:14 <dvhart> adam_, that firmware may be available as part of the linux-firmware package, and just needs to be enabled (see meta-intel)
May 18 16:37:27 <dvhart> as for the driver, the sources may be in the linux-yocto kernel, but just need to be enabled
May 18 16:37:38 <dvhart> with a config fragment: CONFIG_MYWIFI_DRIVER=m
May 18 16:37:59 <dvhart> note: always do drivers with firmware as modules and not built-in, otherwise you have to have the firmware in the initrd (messy)
May 18 16:38:00 <adam_> yes that was configured
May 18 16:38:45 <dvhart> so, that is why you need to add the kernel-module-mywifi-driver to the packages installed as bluelightning suggested, see meta-intel/meta-fri2/conf/machine/fri2.conf for an example of that.
May 18 16:39:11 <dvhart> this is generically described in the reference manual
May 18 16:39:12 <adam_> ok sounds awesome, i am checking out meta-intel now
May 18 16:39:20 <dvhart> but a more task-based set of documentation is admitedly needed
May 18 16:39:38 <bluelightning> adam_: you probably won't need the recipe linked above but btw for future reference you can just add ${WORKDIR}/ in front of the license filename in LIC_FILES_CHKSUM and then you won't need the do_cp_lic stuff
May 18 16:39:40 <dvhart> adam_, would you send me an email after you've been through this, explaining what wasn't clear?
May 18 16:39:49 <dvhart> adam_, that will help feed into some new documentation
May 18 16:40:17 <adam_> wow i am learning so much and it's friday too! this is great
May 18 16:40:30 <adam_> dvhart, yes i will send you an email
May 18 16:40:36 <adam_> what is it?
May 18 16:40:38 <dvhart> adam_, thanks, much appreciated
May 18 16:40:47 <adam_> glad i can help in someway =D
May 18 16:59:49 <seebs> Okay, I'm thinking to try to do a pull request for the variable tracking stuff.  Anyone have complaints/suggestions/demands for it?
May 18 17:00:00 <seebs> I guess that's particularly aimed at kergoth`.
May 18 17:00:12 <dvhart> seebs, pull request is the ideal way to find out;-)
May 18 17:01:01 <seebs> Well, I would sorta like to fix anything obvious that people have already noticed first.
May 18 17:01:16 <seebs> I was totally convinced the include file tracking was missing stuff, but I can't reproduce that now.
May 18 17:01:33 <bluelightning> seebs: you can always make it an RFC pull request first (-c option if you're using create-pull-request)
May 18 17:01:48 * dvhart nods - email will reach a broader audience
May 18 17:01:56 <seebs> k
May 18 17:03:30 <seebs> oooh.
May 18 17:03:40 <seebs> I can break it using the copy in WR for some reason, but not using the yocto copy.
May 18 17:06:12 <seebs> Oh.  Because that one is the old version from before I already fixed that bug.  Wow.  I am SO good at this.
May 18 17:10:16 <dvhart> seebs, ;)
May 18 17:10:56 <kergoth`> python 3.3 has an immutable dictionary type, MappingProxyType
May 18 17:10:59 <kergoth`> nifty
May 18 17:11:13 <seebs> I was right, though.  It was SUSPICIOUSLY similar to the missing include tracking I remembered from before.
May 18 17:11:58 <kergoth`> seebs: I don't like the need to sprinkle extra setVar args all over the source tree. I don't have an alternative, but I'd hesitate to ack it as a result.
May 18 17:25:11 <seebs> Yeah, I'm not super happy with that.  Hmm.
May 18 17:26:06 <kergoth`> the setvars from the ast are easily dealt with, its the other ones that are less so
May 18 17:26:08 <seebs> Okay, crazy thought.  Could we have the datasmart offer some kind of now_processing(file, line) interface, so the feeder could call now_processing(file, line) as it goes, and then setVar, etc., would use those cached values?
May 18 17:26:23 <kergoth`> in theory, setVar could look at the caller and potentially figure it out
May 18 17:26:26 <seebs> It's no faster, but it might be easier to control.
May 18 17:26:39 <kergoth`> the ast nodes already have the file/lineno, no? and they're what do 90% of the setvars
May 18 17:26:49 <seebs> Yes.
May 18 17:27:01 * kergoth` ponders
May 18 17:27:30 <kergoth`> it is possible to use the traceback stack to inspect your caller
May 18 17:27:36 <kergoth`> but i'd be worried about potential performance impact
May 18 17:27:46 <seebs> Hmm.
May 18 17:28:00 <kergoth`> obviously you have to know fn/lineno to show a traceback, so.. :)
May 18 17:28:16 <kergoth`> i'd think it wouldn't perform too badly, the python core has to maintain that knowledge regardless
May 18 17:28:20 <kergoth`> in case of an exception or wahtever
May 18 17:28:27 <kergoth`> we just want to look at it
May 18 17:28:51 <seebs> Hmm.  Of course, part of the thing is, we don't know what to look at in the caller; we don't know that the caller has a local variable named fn or whatever.
May 18 17:30:15 <kergoth`> no, you're not seeing it
May 18 17:30:26 <kergoth`> tracebacks have *internal* knowledge of filename/lineno from the compiled python code objects
May 18 17:30:32 <kergoth`> you don't need variables
May 18 17:30:53 <seebs> Oh!  You're talking python source file/line.  I'm talking config file/line.
May 18 17:31:10 <seebs> Which I don't think Python knows about as such.
May 18 17:31:15 <kergoth`> config file/line we already have, in teh ast nodes
May 18 17:31:32 <kergoth`> the missing bit is all the other setvars in the bitbake codebase, which we could get from traceback
May 18 17:31:36 <kergoth`> unless i'm missing something?
May 18 17:31:38 <seebs> Ohhh.
May 18 17:31:45 <seebs> Thinking about it...
May 18 17:32:05 <seebs> I think some of them are cases where there's a meaningful file name or lineno which isn't the ... hmm.
May 18 17:32:21 <seebs> Ohh.
May 18 17:32:31 <kergoth`> it'd get you 90% of the way there, i think. might be a couple corner cases
May 18 17:32:42 <seebs> Okay, here's my suggestion:  What if we make it so the default is None, and if it's None we inspect the parent.
May 18 17:33:17 <kergoth`> if you're curious about traceback objects at all, see https://gist.github.com/743677
May 18 17:33:26 <seebs> So if you know that you are setting something that is best thought of as coming from a file, you specify that, otherwise you leave it blank and we pick up the best guess from the traceback.
May 18 17:33:28 <kergoth`> thats where i figured out how to adjust the line number when compiling python code from parsed files
May 18 17:33:42 <kergoth`> which would let us eventually have correct  filename/lineno in the code objects for tasks and eventhandlers and the like
May 18 17:33:45 <seebs> That would indeed remove like 90% of the cases where extra args are being passed to setVar.
May 18 17:33:52 <kergoth`> yeah, that'd make sense
May 18 17:34:23 <seebs> Okay.  I will see if I can figure out a way to do that.  I think the internal calls from one set* to another will still want to pass on their filename/lineno, but it still cleans up a lot of cases.
May 18 17:34:32 <kergoth`> see also line 137 of https://gist.github.com/743677, note the tb.tb_next. that's how it's referring to its caller rather than itself
May 18 17:34:51 <seebs> k
May 18 17:35:05 <seebs> I am thinking this requires enough learning of New Things that I may have to let it sit until Monday.
May 18 17:35:24 <kergoth`> i'd also suggest running this stuff, both the old implementation and theoretical new one by richard
May 18 17:35:35 <kergoth`> he and i disagree on such things 90% of the time, so there's no telling
May 18 17:35:45 <kergoth`> heh
May 18 17:35:47 <seebs> I was just gonna surprise him, everyone likes surprises.
May 18 17:35:50 <kergoth`> hehe
May 18 17:36:42 <kergoth`> or perhaps send another RFC out with your latest patchset along with thoughts on a potential new one, to the bitbake list
May 18 17:37:02 <seebs> Well, I just sent the RFC out, now I'm sending just a followup comment without the code to implement it.
May 18 17:37:20 <kergoth`> cool
May 18 17:38:19 <kergoth`> also, in python there's no need to use accsesors like getThis, or getThat
May 18 17:38:34 <kergoth`> just access the variable member, you can change it to a property later on if processing is needed
May 18 17:38:53 <kergoth`> that's a minor thing  of course
May 18 17:39:14 <seebs> Did I do accessors?  If so, I bet I did them for what seemed at the time like a clever reason.
May 18 17:39:52 <seebs> I am a little confused by Python sometimes.  I've been doing a ton of Lua lately, and Python and Lua have systematically picked opposite sides of basically every language design decision I can think of.
May 18 17:43:51 <kergoth`> Hmm, the URI rfc has a reference regular expression pattern for matching uris per the spec, we should adjust decodeurl() to use that
May 18 17:53:02 <kergoth`> seebs: want the code you'll need for the discussed inspection of hte caller? :)
May 18 17:53:03 <kergoth`> https://gist.github.com/2726709
May 18 17:53:21 <seebs> Ooh, handy.  I may try to use that.
May 18 17:54:06 <kergoth`> that's exactly what you need, should be like 3 lines to add it to setVar when the values are None
May 18 17:54:10 <kergoth`> :)
May 18 17:57:04 <kergoth`> https://gist.github.com/2726718 will do if you want to be able to pass just filename but not lineno or vice versa. otherwise it'd be simpler. if filename is None, set both
May 18 17:57:10 * kergoth` gets something to eat
May 18 17:58:22 <kergoth`> the limit has to be 2 to ensure you get teh caller. the last element in the stack is always teh current function. so passing limit=2 pushes that to element 1 instead of 0, and 0 is the cller
May 18 17:58:23 <seebs> I am inclined to just set both if filename is None.
May 18 17:58:27 <kergoth`> agreed
May 18 17:58:56 <kergoth`> i was thinking about possible spots in teh parser where you might want to indicate filename but not line number
May 18 17:59:04 <kergoth`> but thats a theoretical concern, you're actually in the code
May 18 18:02:47 <kergoth`> i guess since the tracking isn't always enabled, the performance is less of an issue, eh?
May 18 18:07:45 <seebs> Yeah.  If we were doing that, the computation could be conditional on tracking, so it'd be nugatroy in the normal case.
May 18 18:08:08 <seebs> My thought is, if you specify a filename, but not a line number, we just assume N/A for line number, because it didn't matter to you.
May 18 18:44:10 <seebs> ... we have, so far as I can tell, no calls at all to appendVar except in a test.
May 18 18:44:25 <seebs> At least, not inside bitbake/lib/bb.  Might be some elsewhere, I guess.
May 18 18:49:28 <msm> anyone seeing virtual-locale issues?
May 18 18:50:46 <kergoth`> appendVar is used in the metadata some, we should use it more
May 18 18:54:58 <seebs> Real soon now, I plan to submit two bitbake patches.
May 18 18:55:08 <seebs> Patch #1 consistently replaces "cfgData" with "configdata".
May 18 18:55:35 <seebs> Patch #2 eliminates uses of the name "data" for variables to avoid confusion with references to the class "data".
May 18 18:55:58 <seebs> I am sick of having to distinguish between data.setVar(key, value) and data.setVar(key, value, data_smart_object)
May 18 19:09:50 <fray> wow.. IRC hates me
May 18 19:10:06 <fray> keeps kicking me off w/o so much as a rejected packet.. :P
May 18 19:18:49 <msm> core-image-sato + virtual-locale foo
May 18 19:47:52 <mranostay> fray: there are much worse things that can hate you
May 18 19:48:13 <fray> heh
May 18 19:58:05 * fray is being entertained by watching FB stock prices and bid/ask pricing.. ;)
May 18 20:02:24 <kergoth`> seebs: sounds good to me. we should probably eliminate all 'from foo import..' from bitbake entirely in the long run
May 18 22:04:46 <incandescant> halstead: ping?
May 18 22:05:13 <halstead> incandescant, pong.
May 18 22:05:43 <incandescant> hey halstead, I'm unable to ssh into the autobuilder - can you help me?
May 18 22:05:48 <incandescant> halstead: side-channel?
**** ENDING LOGGING AT Sat May 19 02:59:58 2012

**** BEGIN LOGGING AT Sat May 19 02:59:59 2012
May 19 17:09:49 <comphappy> when using hob and clicking on the layers button I get the trace back
May 19 17:09:52 <comphappy> 'gtk.CellRendererText' object has no attribute 'set_padding'
**** ENDING LOGGING AT Sun May 20 02:59:58 2012

**** BEGIN LOGGING AT Sun May 20 02:59:59 2012
May 21 00:56:46 <halstead> It the cause of this do_fetch (http://paste2.org/p/2030190) error when running bitbake core-image-sato obvious?
May 21 00:57:39 <halstead> I logged all outbound network traffic and I don't see any if that matters.
May 21 01:04:13 <kergoth`> halstead: http://patches.openembedded.org/patch/25217/ seems appropriate
May 21 01:04:22 <kergoth`> erm, wrong link, hold
May 21 01:04:37 <kergoth`> http://patches.openembedded.org/patch/28013/
May 21 01:04:41 <kergoth`> that's the one
May 21 01:27:25 <halstead> Thanks kergoth` that woks now.
May 21 01:27:50 <halstead> I wonder why that was required for opensuse 12.1 but not for centos 6.2.
**** ENDING LOGGING AT Mon May 21 02:59:59 2012

**** BEGIN LOGGING AT Mon May 21 02:59:59 2012
May 21 07:47:16 <mckoan> good morning
May 21 09:07:26 <bluelightning> morning all
May 21 09:29:30 <moolinex> morning
May 21 10:14:16 <mckoan> I'm trying to boot a core-image-sato-atom-pc.hddimg on an Atom-N550
May 21 10:14:26 <mckoan> graphics doesn't work
May 21 10:14:39 <mckoan> and the console prompt asks me a user
May 21 10:14:56 <mckoan> using root with no password doesn't work
May 21 10:15:01 <mckoan> any clue?
May 21 10:20:10 <bluelightning> mckoan: well, for the login issue, as long as debug-tweaks is in IMAGE_FEATURES you should be able to log in with root and no password
May 21 10:21:23 <mckoan> bluelightning: :-(
May 21 10:24:02 <mckoan> I suspect everybody tested qemu only
May 21 10:24:27 <bluelightning> I've had core-image-sato working fine on my netbook not that long ago
May 21 12:42:04 <denisATeukrea> hi, freedesktop git seem down, that prevent me from fetching systemd git...
May 21 13:43:42 <mckoan> bluelightning: Driver "vesa" instead of "intel" worked smoothly
May 21 13:44:30 <bluelightning> mckoan: I guess there is an issue using the intel driver on that hw atm... would you mind filing a bug?
May 21 13:45:46 <mckoan> bluelightning: where?
May 21 13:46:16 <bluelightning> mckoan: bugzilla.yoctoproject.org
May 21 13:48:00 <mckoan> gosh! there are a plenty of categories https://bugzilla.yoctoproject.org/describecomponents.cgi
May 21 13:59:12 <mckoan> bluelightning: may you sugegst the product on which to enter the bug?
May 21 14:00:12 <bluelightning> mckoan: Yocto Projects -> Runtime Distribution -> System startup I guess
May 21 14:00:29 <bluelightning> the categories are in the process of being reworked I think
May 21 14:00:41 <bluelightning> in the mean time that's close enough
May 21 14:01:50 <mckoan> Meta Recipes
May 21 14:08:25 <mckoan> bluelightning: https://bugzilla.yoctoproject.org/show_bug.cgi?id=2477
May 21 14:09:10 <bluelightning> mckoan: great, thanks for that
May 21 14:09:44 <mckoan> bluelightning: np I hope to be able to go further with yocto ;-)
May 21 14:27:21 <seebs> So, given a data_smart object d, can anyone tell me why one line of code would use data.setVar(var, value, d) and another d.setVar(var, value)?  They're like five lines apart.
May 21 14:31:47 <d4ny> Hi All, where is the code behind http://packages.yoctoproject.org/, how is this data generated ?
May 21 14:34:53 <bluelightning> seebs: the first form is deprecated
May 21 14:37:44 <seebs> Okay.
May 21 14:49:59 <denisATeukrea> hmmm, since mckoan is asking Xorg questions I'll do it too: I've (EE) FBDEV(0): FBIOPUT_VSCREENINFO succeeded but modified mode with xf86-video-fbdev, the problem is that the resolution is not modifiable at runtime but rather at boot-time(kernel-parameters), does someone knows how to handle that?
May 21 14:50:46 <denisATeukrea> I'd like to fix the issue but I got no response in #xorg
May 21 14:53:50 <mckoan> denisATeukrea: you won't always get any response in #xorg :-D
May 21 14:53:59 <denisATeukrea> ah ok
May 21 14:54:12 <mckoan> is a black hole
May 21 14:54:22 <denisATeukrea> /dev/null?
May 21 14:54:27 <mckoan> :-D
May 21 14:54:43 <mckoan> denisATeukrea: which machine?
May 21 14:54:46 <denisATeukrea> else I can still read all the sources
May 21 14:54:49 <denisATeukrea> eukrea-cpuimx35
May 21 14:54:55 <denisATeukrea> the problem is the following:
May 21 14:55:03 <denisATeukrea> http://pastie.org/private/7szeaglctd7t4wcttqswg
May 21 14:55:07 <mckoan> IMHO is a machine related issue
May 21 14:55:14 <denisATeukrea> yes somehow
May 21 14:55:27 <denisATeukrea> it's a generic problem applied to a machine
May 21 14:56:09 <denisATeukrea> I guess the correct solution is to implement monitor detection in the kernel right?
May 21 14:56:40 <mckoan> denisATeukrea: xrandr didn't help?
May 21 14:56:41 <kergoth`> seebs: looked at 2to3? its refactoring capabilities seem useful, i can't help but wonder if one could easily create custom ones to do api adjustments in a more sane, less error-prone way than sed
May 21 14:56:50 <kergoth`> custom fixers, that is
May 21 14:56:57 <kergoth`> haven't had a time to take a close look, yet
May 21 14:57:00 <denisATeukrea> Xorg doesn't even start
May 21 14:57:02 <kergoth`> on the loong todo :)
May 21 14:57:26 <denisATeukrea> the error is from Xorg not starting
May 21 14:57:33 <mckoan> denisATeukrea: sorry I'm confused, what's the problem?
May 21 14:58:00 <denisATeukrea> Xorg fails to start with the following error:
May 21 14:58:03 <denisATeukrea> (EE) FBDEV(0): FBIOPUT_VSCREENINFO succeeded but modified mode
May 21 14:58:03 <denisATeukrea> (EE) FBDEV(0): mode initialization failed
May 21 14:58:20 <denisATeukrea> and that error is because the modes are not modifiables
May 21 14:58:31 <seebs> Huh, that's a thought.  I think this case may be tangled enough to make it Too Hard because of all the uses of 'data' as a variable name.
May 21 14:58:35 <denisATeukrea> and it's not modifiable because of that: http://pastie.org/private/7szeaglctd7t4wcttqswg
May 21 14:58:54 <denisATeukrea> so I wondered if there was a workarround
May 21 14:59:06 <denisATeukrea> like you add something in xorg.conf and it doesn't modify the mode
May 21 14:59:27 <denisATeukrea> I already tried to add the following in the Monitor section:
May 21 14:59:28 <denisATeukrea> http://pastie.org/private/l0al6c0jvkem8umau7lyua
May 21 14:59:56 <denisATeukrea> but so far no luck
May 21 15:06:47 <mckoan> denisATeukrea: no clues apart this http://lists.debian.org/debian-arm/2009/02/msg00065.html
May 21 15:07:32 <denisATeukrea> yes I saw that, the problem is that the patch is against Kdrive and that it's a patch
May 21 15:15:14 <seebs> kergoth`, thanks a ton for your help on that traceback stuff.  That has dramatically improved the tracking patch.
May 21 15:23:53 <kergoth`> seebs: nice, glad to hear it
May 21 15:24:50 <mckoan> (test)
May 21 15:51:19 <kergoth`> RP: would you be fine with me adding the appropriate quote/unquote to encodeurl/decodeurl to handle %20, etc in url paths? would be triival to add, and i suspect would have no problems
May 21 15:51:23 * kergoth` tries that
May 21 15:51:44 <RP> kergoth`: it sounds reasonable...
May 21 15:53:16 <kergoth`> not sure why we never did that before, i guess nobody cared enough to bother :)
May 21 15:53:41 * kergoth` certainly didn't, just happened to think about it while looking over that code
May 21 16:16:47 <sgw> halstead: what's the status of the bug re-classifications
May 21 16:27:00 <Eren> I cannot find most of the documents in getting started wiki page
May 21 16:27:03 <Eren> https://www.yoctoproject.org/documentation/getting-started
May 21 16:32:17 <autif> Eren:  I am able to hit everything - except "Downloads Page"
May 21 16:40:08 <Eren> https://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html
May 21 16:40:18 <Eren> https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html
May 21 16:40:27 <Eren> https://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html
May 21 16:40:29 <Eren> these are all 404
May 21 16:41:46 <Eren> am I missing something?
May 21 16:42:19 <bluelightning> Eren: looks like a difference in behaviour between http:// and https://
May 21 16:42:29 <bluelightning> Eren: if you switch to http:// in the URL it should work
May 21 16:42:36 <bluelightning> halstead: ^ any ideas?
May 21 16:44:10 <Eren> oh, then why these links doesn't work in https :(
May 21 16:44:21 <Eren> ops, it should be :)*
May 21 16:44:38 * Eren is using https everywhere btw..
May 21 16:44:51 <bluelightning> Eren: good question, I hope halstead can figure it out (he manages our infrastructure)
May 21 16:45:17 <Eren> okkie
May 21 16:45:29 <bluelightning> Eren: thanks for bringing this to our attention :)
May 21 16:46:23 <Eren> bluelightning: my pleasure :)
May 21 16:51:01 <Eren> I've AMD Geode LX 800 which is a x86 compatible device. I've installed a regular stripped down linux which has been built for i486 target. However, when I use speex libraries, I get illegal instructon on the device :)
May 21 16:51:19 <Eren> then I decided that I need a special image for the device and thought that Yocto could be a good start
May 21 16:51:29 <Eren> is there any ongoing work on AMD Geode family?
May 21 16:51:31 <fray> most of the binaries in the system are designed for an i586 or i686 system that has a couple of instructions that the Geode doesn't..
May 21 16:51:58 <fray> if you want to use OE-core (Yocto Project) on such an "old" processor.. you'll need to define your own cpu tuning and machine template..
May 21 16:52:19 <fray> You can instruct the compiler, via a machine tune, to no longer generate the few instructions..  (cmov is one of them if my memory is correct)
May 21 16:52:19 <Eren> hmm
May 21 16:53:01 <Eren> fray: right, as far as I searched, the problem was in gcc in that gcc thought the instruction is supported on all the x86-like processors
May 21 16:53:07 <Eren> however, geode did not support it
May 21 16:53:09 <fray> if you look at meta/conf/machine/include  look at "tune-c3.inc".. it's very similar to what you will need..
May 21 16:53:41 <Eren> thanks, I will look at what I can do about it
May 21 16:53:44 <fray> most likely you need to copy tune-c3.inc to "tune-geode.inc"
May 21 16:53:49 <fray> then modify it to be something like:
May 21 16:54:19 <chackal_sjc> is there any document which shows how to create an Image?
May 21 16:54:20 <fray> (search/replace "c3" with geode).. then chang ethe -march and -mtune to be =i486
May 21 16:54:31 <chackal_sjc> I want to create a root filesystem, only..
May 21 16:54:50 <Eren> although I'm experenced in packaging, debugging and stuff like it, I haven't read about yocto project much :)
May 21 16:54:59 <Eren> chackal_sjc: there are documents on building an image
May 21 16:55:17 <Eren> chackal_sjc: http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html#building-image
May 21 16:55:48 <chackal_sjc> Eren: Thanks, but I'm looking in building my own image.. how to create your own image
May 21 16:59:27 <fray> Eren, modifying the tune file is the simpilest way for you to do this.. you'll have to build teh sofwtare.. but I doubt you will have to change any userspace software..
May 21 16:59:32 <fray> it most likely will just "work"
May 21 16:59:50 <Eren> fray: well I will also need to build libspeex and gsm codecs
May 21 16:59:51 <fray> the kernel configuration will have to be custom for your board, but it shouldn't bee too hard
May 21 16:59:57 <Eren> are there supported in yocto?
May 21 17:00:28 <fray> No, but I believe they are available in a layer that is compatible with openembedded-core.. and the Yocto Project system does support using those layers (just not the software in them)
May 21 17:00:46 <Eren> fray: yes, I will need to activate amateur radio modules such as ax25, kiss modem etc
May 21 17:00:50 <fray> for something specialized like codecs, if it's to run on the core CPU, it's possible they've been optimized with MMX or other instructions the geode may not control
May 21 17:01:07 <fray> I know there are some software defined radio layers out there..
May 21 17:02:35 <fray> there is a page (somewhere) on openembedded.org that has a list of layers..b ut I can't find it..
May 21 17:02:38 <fray> it used to be on the main page..
May 21 17:02:55 <fray> found it..
May 21 17:02:56 <fray> http://www.openembedded.org/wiki/LayerIndex
May 21 17:03:26 <fray> not sure if anything of that will help you, but it might
May 21 17:04:55 * Eren looking now
May 21 17:07:53 <Eren> hm, seems that there are some telephony support
May 21 17:07:56 <Eren> it includes libgsm
May 21 17:26:06 <khem> sgw: I am seeing the yocto bug trends and it shows qemu not booting into X for arm,mips,ppc
May 21 17:26:32 <khem> sgw: is it because of kdrive->xorg-xserver swithc ?
May 21 17:26:44 <khem> I am confused a bit since I dont see those patches merged yet
May 21 17:34:23 <halstead> sgw, The reclassified bugs work is on a vm that isn't attached to the Internet yet. It's also still not 100%.
May 21 17:35:16 <halstead> Eren, bluelightning, those docs exist as static files managed by git and are outside the webroot of the main website.
May 21 17:35:45 <halstead> Eren, the extra config that makes them work is absent from the https.
May 21 17:38:40 <halstead> Eren, bluelightning, I've included new config and those docs are available via https now.
May 21 17:39:02 <bluelightning> halstead: great, thanks
May 21 17:39:33 * halstead goes back to reclassifying.
May 21 17:57:17 <kergoth`> seebs: that's much cleaner indeed :) will have to play with it
May 21 17:57:47 <kergoth`> heh, at first i wondered why you infer in the wrappers, but that's clearly because of the additional indirection in the call, the callee has to know how far back to look
May 21 17:57:50 <seebs> It has been a total lifesaver for me.
May 21 17:57:52 <seebs> Yes.
May 21 17:58:56 <seebs> Huh.  I suppose I could walk back up the stack looking for something outside data_smart.py and data.py.  There is no way THAT could ever misfire or be inefficient.
May 21 17:59:46 <kergoth`> sounds like more trouble than its worth
May 21 17:59:54 <kergoth`> also, it's too much magic/implicit
May 21 18:00:03 <kergoth`> we enough more than enough magic already
May 21 18:00:04 <kergoth`> :)
May 21 18:00:32 <kergoth`> i assume you've seen the zen of python before?
May 21 18:00:41 <kergoth`> http://www.python.org/dev/peps/pep-0020/
May 21 18:01:37 <kergoth`> we should deprecate the old data wrappers at some point
May 21 18:02:53 <kergoth`> long term, obviously, particularly since metadata is affected
May 21 18:03:33 <kergoth`> totally unrelated, but https://kanbanflow.com/ seems rather nice. has a task board-like interface to changing states of your todos
May 21 18:15:32 <kergoth`> seebs: i'd suggest concat-before concat-after or similar instead of 'postdot', but thats personal opinion, others might disagree
May 21 18:15:51 <kergoth`> the dot is more indicative of the characters used, but is less conceptually clear
May 21 18:15:54 <kergoth`> debatable
May 21 18:16:11 <seebs> I wouldn't object to that at all, I was just tossing in values so I could see what I was doing.
May 21 18:16:24 * kergoth` nods
May 21 18:16:32 <kergoth`> just perusing bitbake -e
May 21 18:16:43 <seebs> And yes, I've seen TZoP.  I do not much care for the dogmatic nature of the Python community.
May 21 18:16:46 <kergoth`> does it handle and distinguish ?= and ??=?
May 21 18:16:56 * kergoth` didn't check
May 21 18:16:57 <seebs> I ... don't actually know.  It probably doesn't.
May 21 18:17:35 <kergoth`> ??= is applied as an 'end-of-parse' operation. the default value is saved and then later used/applied
May 21 18:17:45 <kergoth`> you can almost certainly treat it the same way you do _append
May 21 18:17:53 * kergoth` gets food
May 21 18:17:57 <seebs> Yeah, I'd have to go look to see how it's being handled.
May 21 18:18:19 <kergoth`> we're wanting to transition to more use of ??=, with ?= being used in explicit circumstances only, i think
May 21 19:09:33 <seebs> Huh.
May 21 19:09:43 <seebs> So, apparently "No GNU_HASH" is fatal.
May 21 19:09:54 <seebs> And the prebuilt toolchain I just got has no GNU_HASH in some binaries.
May 21 19:15:35 <kergoth`> yeah, i ran into that too :\ you can use INSANE_SKIP to worka round it. what we did is overrode poky.conf to use the default ERROR_QA and WARN_QA
May 21 19:15:44 <kergoth`> the default non-distro-specific values of those don't set gnu_hash to fatal
May 21 19:15:47 <kergoth`> it's poky that does
May 21 19:15:53 <fray> yes, if you know better (in the case of a prebuilt) you need to remove the check from ERROR_QA.. (ldflags).. just don't know the filter method off the top of my head
May 21 19:16:21 <fray> well, we want GNU_HASH fatal fro everything except these prebuilt binary cases..
May 21 19:16:33 <kergoth`> there's no global INSANE_SKIP for all packages
May 21 19:16:40 <kergoth`> that's what we really need, for prebuilt binary recipes, i suspect
May 21 19:17:07 <comphappy> I am trying to build a kernel from my own local repo for a custom machine bsp, but I keep getting the error:
May 21 19:17:07 <comphappy> NOTE: Error expanding variable do_patch
May 21 19:17:26 <kergoth`> i'm keeping the full hardcoded list of WARN_QA and ERROR_QA in my distro for now, in case poky does anything else that breaks any of our layer content. downside to basing on a moving target
May 21 19:18:19 <comphappy> the full error can be seen here: http://pastebin.com/XvHrGHS3
May 21 19:25:29 <seebs> Huh.  Seems like a package-local INSANE_SKIP modifier would be super handy.
May 21 19:25:44 <kergoth`> hm?
May 21 19:25:50 <kergoth`> INSANE_SKIP_pkgname = "foo" works fine
May 21 19:25:55 <kergoth`> its just taht you have to use it for each package
May 21 19:26:02 <kergoth`> its recipe-local / package-wide that's missing
May 21 19:26:03 <seebs> Huh.  ... Maybe I should do that.
May 21 19:26:09 <kergoth`> it works
May 21 19:26:25 <seebs> Alternatively, I can try to bribe the Code Sourcery people to include GNU_HASH in things.
May 21 19:26:49 <kergoth`> well, as fray says, it's a general issue with any prebuilt stuff
May 21 19:27:01 <fray> INSANE_SKIP_pkgname though skips -all- of the steps...
May 21 19:27:07 <kergoth`> no
May 21 19:27:08 <fray> (if I'm remembering right)
May 21 19:27:21 <kergoth`> you can list any element from ERROR_QA or WARN_QA to skip just taht check
May 21 19:27:23 <fray> no.. take that back..
May 21 19:27:26 <fray> it skips only what you list..
May 21 19:27:29 <kergoth`> yeah
May 21 19:27:36 <fray> so ya.. INSANE_SKIP_pkgname = "ldflags" is what you want
May 21 19:28:07 <kergoth`> seebs: feel free to push the insane skips for external-csl-toolchain, its only 3 packages, iirc
May 21 19:28:18 <kergoth`> or rather, submit for merge, not push
May 21 19:28:22 <kergoth`> whatever :)
May 21 19:28:35 * kergoth` mutters and adds a todo to rename csl to sourcery, since he keeps forgetting
May 21 19:29:19 <fray> don't let the corporate trademark police get to you.. ;)
May 21 19:30:25 <kergoth`> :)
May 21 20:33:54 <kergoth`> god, the amount of tasks involved in a core-image-minimal is ridiculous, we need to work o nthis
May 21 20:33:58 <seebs> Huh.
May 21 20:34:14 <seebs> Ask me someday about "glibc_std".  :P
May 21 20:34:26 <fray> well, thats not a "minimal" image
May 21 20:34:41 <fray> but ya, core-image-minimal take a lot to generate.. a lot more then it likely should
May 21 20:34:48 <seebs> Okay, apparently I am not good enough to use INSANE_SKIP.
May 21 20:34:58 <seebs> It appears that I should be setting INSANE_SKIP_${PN}.
May 21 20:35:16 <fray> INSANE_SKIP_<split package name>
May 21 20:35:26 <seebs> Which I naively thought would be INSANE_SKIP_external-csl-toolchain, because the package that failed was "external-csl-toolchain-4.6-51-r5".
May 21 20:35:27 <fray> ${PN} is one of the possible splits..
May 21 20:36:18 <seebs> Interestingly, it's hardcoded (partially) as 'INSANE_SKIP_' + package
May 21 20:36:33 <kergoth`> heh, we still have some funkiness with the way we implemented variable references in variable names. i'd love to find a better way to handle that
May 21 20:36:34 <fray> it's iterating over the list of packages
May 21 20:38:19 <seebs> Ohhhh.  So lemme guess.  Package name isn't the name of the top-level thing it thinks it's building, but the name of the specific packages, with names like libc-headers?
May 21 20:38:35 <fray> iterates over the contents of "PACKAGES"
May 21 20:38:50 <fray> which are what the binary package naems will be (before they're munged by the debian class)
May 21 20:38:57 <fray> a.k.a. package splits..
May 21 20:39:37 <seebs> Woo, found a bug in my tracker.
May 21 20:39:37 <kergoth`> seebs: thats what we said earlier. there's no *recipe level* variable, its binary *package* name
May 21 20:40:16 <seebs> Ahh!  I had misparsed that because I had not comprehended the recipe/package distinction correctly.
May 21 20:49:57 <seebs> I do not understand this.
May 21 20:50:11 <seebs> I am getting errors from the includeLog stuff, which has obviously worked in general.
May 21 20:50:44 <seebs> The killer is in the self.include_stack[-1][1].append(position) line.  This throws an exception because tuples don't have an append, which is a very good reason for an exception.
May 21 20:50:55 <seebs> Except that type(self.include_stack[-1][1]) is 'list'.
May 21 20:53:54 <seebs> hmm.  Except now sometimes it's a tuple.  Mysteries!
May 21 20:55:36 <RP> kergoth`: I'm hearing reports of the fetcher sometimes doing nasty things, seemingly due to being in an incorrect directory - anything you've hear/seen before? Looking at the git fetcher code, I can't see how other than a chdir call failing silently :/
May 21 20:56:13 <seebs> d'oh
May 21 20:56:20 <seebs> my copy mechanism was misspelled.
May 21 20:57:42 <kergoth`> RP: nope, haven't heard aboutthat one
May 21 21:02:20 <seebs> RP/kergoth`: Don't merge the tracking changes just yet, as I found an actual bug.
May 21 21:02:34 <RP> seebs: ok
May 21 21:02:54 <RP> kergoth`: I just wish someone could show a reproducer :/
May 21 21:03:16 <seebs> I am pretty sure the Internet is full of pictures of people reproducing.
May 21 21:05:20 * Bagder blinks
May 21 21:08:23 <seebs> aggghhg
May 21 21:08:38 <seebs> Suddenly my world is full of binaries without GNU_HASH.  It is probably because I am a bad person at heart.
May 21 21:09:05 <fray> prebuilt binaries are one thing, but if the toolchain starts producing them as well, something is broken either in the toolchain -- or in the ldflags..
May 21 21:09:47 <seebs> Gonna explore this a little more.
May 21 21:11:36 <seebs> I'll put in an INSANE_SKIP for that one package and see whether I hit more.
May 21 21:13:47 <seebs> Huh, just zip doing it so far.  Everything else seems fine.
May 21 21:16:32 <fray> maybe zip isn't using the system ldflags?
May 21 21:16:43 <fray> that would seem to indicate the default of the compiler is set to sysv and not gnu_hash
May 21 21:16:53 <fray> if that is the case, it's something we'll likely have to request change..
May 21 21:17:01 <fray> but fixing zip needs to be done as well
May 21 22:34:03 <kergoth`> Tartarus: http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/commit/ recipes aren't there yet, but getting there :)
May 21 22:34:15 * kergoth` ponders
May 21 22:46:57 <Tartarus> whee
May 21 23:03:20 <seebs> ...
May 21 23:03:50 <seebs> I am skeptical of this error message telling me I have insufficient directories for the sstate-cache directory, given that I own it and it is rwx.
May 21 23:04:15 <kergoth`> seebs: i've gotten that too. re-run the build, i bet it'll work the second time
May 21 23:04:16 <kergoth`> it did here
May 21 23:04:21 <kergoth`> not sure whats going on
May 21 23:04:31 <kergoth`> clearly some sort of bug in taht code
May 21 23:04:37 <seebs> Yeah, seems like it.
May 21 23:04:42 <seebs> Maybe it's a race condition.  :)
May 21 23:04:58 <kergoth`> this is what happens when people do : if this doesn't exist: mkdir
May 21 23:05:02 * kergoth` rolls eyes
May 21 23:05:06 <kergoth`> (and the like)
May 21 23:05:24 * kergoth` gets caffeine
May 21 23:06:09 <seebs> "mkdir -p", the mnemonic for which is "please work"
May 21 23:09:35 <kergoth`> also known as bb.mkdirhier()
May 21 23:10:22 <kergoth`> seebs: emailed a few patches, one of which includes insane_skips
May 21 23:10:38 <seebs> Cool.
May 21 23:11:05 <seebs> Yeah, I've been trying to make sure I have the right set of those, but since everything else seems to have that trouble too, I am not sure I have it.
May 21 23:11:33 <kergoth`> strange
May 21 23:11:41 <seebs> Trying to figure out whether this is a compiler problem or something else I have invoked in my mad science.
May 21 23:34:04 <kergoth`> heh, adding quote/unquote to the decode/encode url, but fixing all the other spots that assume the url filename doesn't have spaces: less trivial :)
May 21 23:34:12 <kergoth`> s/url/url is easy/
May 21 23:52:00 <seebs> FWIW, my GNU_HASH problems are indeed because our new prebuilt toolchain doesn't default to that, and some packages aren't picking up LDFLAGS as expected.
May 21 23:52:06 <seebs> So I should probably bug-report the affected packages.
May 22 02:15:33 <khem> seebs: some packages have buggy build systems
May 22 02:15:45 <khem> seebs: whereby they dont respect LDFLAGS from env
May 22 02:15:57 <khem> seebs: so for them you have to add it to TARGET_CC_ARCH
May 22 02:19:58 <adam__> Helped needed...
May 22 02:20:05 <adam__> ERROR: Task do_menuconfig does not exist for target my_image
May 22 02:20:30 <adam__> There is no documentation i was able to find to enable my image with menuconfig
May 22 02:20:32 <khem> did you inherit kernel
May 22 02:20:44 <adam__> hm... in my .bb file?
May 22 02:20:56 <khem> menuconfig is a special task for kconfig based recipes
May 22 02:21:34 <adam__> hm.. ok here is what i'm trying to do: I'm trying to enable my wireless driver
May 22 02:21:43 <adam__> spent a couple days on it. I'm pretty stuck with it.
May 22 02:22:18 <khem> ok hack it into linux-yocto is one option
May 22 02:22:32 <khem> another option is to write a recipe to build it as external module
May 22 02:23:01 <adam__> yes I think what i want to do is
May 22 02:23:06 <adam__> build it as external module
May 22 02:23:17 <adam__> that's what i have been trying to do: add out-of-tree module
May 22 02:23:30 <khem> look at meta/recipes-kernel/systemtap/systemtap-uprobes_git.bb
May 22 02:23:53 <khem> thats an external module
May 22 02:23:55 <adam__> ok
May 22 02:24:09 <adam__> do i need MACHINE_EXTRA_RDEPENDS = "marvell-sdio-fw libertas-sd-firmware"
May 22 02:24:31 <adam__> in my conf/machine/include/omap.inc?
May 22 02:24:42 <adam__> libertas-sd-firmware is my wireless chipset
May 22 02:24:55 <khem> you need to add that to your image RDEPENDS somehow yes
May 22 02:25:00 <adam__> i think i have pretty much everything in palce... yet the device does not exist
May 22 02:25:03 <adam__> ok..
May 22 02:25:14 <adam__> i will take a look at that .bb file first
May 22 02:25:15 <adam__> brb!
May 22 02:25:19 <khem> is module built and bundled in your rfs
May 22 02:25:42 <adam__> rfs?
May 22 02:25:48 <adam__> root file system?
May 22 02:26:00 <khem> yes
May 22 02:26:30 <adam__> i'm not sure
May 22 02:26:33 <adam__> how do i check?
May 22 02:26:48 <adam__> when i peek in to /lib/modules/3.2.0/
May 22 02:26:52 <adam__> i don't see any .ko files
May 22 02:26:56 <adam__> is that what you mean?
**** ENDING LOGGING AT Tue May 22 02:59:58 2012

**** BEGIN LOGGING AT Tue May 22 02:59:59 2012
May 22 07:08:46 <moolinex> good morning all
May 22 07:12:57 <mckoan> good morning
May 22 09:34:00 <bluelightning> morning all
May 22 13:45:57 <shoragan> what is the state of systemd in poky/yocto?
May 22 13:46:06 <shoragan> if it should work, how do i enable it?
May 22 13:48:41 <bluelightning> shoragan: it's not officially supported; you can enable it by adding the meta-oe layer though
May 22 13:49:19 <bluelightning> several other projects are making use of it with success though
May 22 13:49:39 <bluelightning> I think we plan on working on supporting it officially for the upcoming 1.3 release
May 22 14:05:02 <shoragan> ok, thank you, bluelightning :)
May 22 15:00:57 <fray> morning....
May 22 15:01:06 <fray> (I'm on the call as well)
May 22 15:05:12 <Zagor> I'd just like to make a note that I intend to resume attenting these meetings shortly. I've just had a stint of poor timing a few weeks.
May 22 15:15:12 <fray> is there a way I can put a python script in a do_install_append?
May 22 15:25:39 <fray> sorry, I missed it, which page are we looking at?  is it the Yocto Project v1.3 Status?
May 22 15:26:10 <incandescant> https://wiki.yoctoproject.org/wiki/Yocto_1.3_Features
May 22 15:26:19 <fray> Ahh ok.. I -was- looking at the wrong one
May 22 15:45:24 <seebs> Anyone want a script for extracting a list of affected packages from a do_package log that failed because of missing GNU_HASH?  :)
May 22 15:54:41 <dvhart> halstead++
May 22 15:55:55 <halstead> Aww the bot has left the channel. I'll kick it.
May 22 15:58:19 <sgw> pidge: incandescant: zenlinux: Regarding the usage of the AB, can we schedule 3 build back/back of master (so we can see where we are), 1.2.1 (to have a build available for everyone to look at and maybe QA to try weekly on) and then 1.1.2 for sanity check and same as 1.2.1?
May 22 15:58:39 <incandescant> sgw: I am OK with that plan
May 22 15:58:53 <incandescant> sgw: seems like 1.2.1 should get a higher priority than 1.1.2?
May 22 15:59:30 <zenlinux> sgw, sounds good to me
May 22 16:00:34 <sgw> RP: do you have any other changes planned for master this morning?
May 22 16:00:55 <sgw> RP: I would like to fire off master as soon as I hear back from you.
May 22 16:08:35 <sgw> pidge: Not hearing from RP, I am going to assume there is no more changes right now, please fire up a Master build
May 22 16:08:58 <pidge> sgw: ok
May 22 16:09:48 <sgw> pidge: thanks
May 22 16:10:23 <pidge> sgw: I'm going to do this with a clean sstate
May 22 16:11:16 <sgw> pidge: sounds like a good idea, will you cleansstate for all 3 builds?
May 22 16:11:23 <chackal_sjc> hey guys
May 22 16:11:35 <chackal_sjc> I just built qt4-x11-free
May 22 16:11:59 <chackal_sjc> but when I try to run some Qt program, it says that could not find X Server
May 22 16:12:07 <chackal_sjc> I've already included the X11 libraries
May 22 16:12:15 <pidge> sgw: yes
May 22 16:12:16 <chackal_sjc> but there is no startx program
May 22 16:12:23 <chackal_sjc> how to start x?
May 22 16:12:29 <sgw> chackal_sjc: which image and machine?
May 22 16:12:46 <chackal_sjc> qt4-x11-free and my own machine
May 22 16:15:51 <sgw> chackal_sjc: I mean target machine?  qt4-x11-free is not really a final target image, you might try core-image-sato which includes the qt4-pkgs
May 22 16:16:14 <sgw> chackal_sjc: target machine like qemu<arch> or some hardware?
May 22 16:16:38 <chackal_sjc> arm
May 22 16:17:02 <sgw> Ok, then maybe you need to build core-image-sato which includes the xserver
May 22 16:17:15 <chackal_sjc> ok, but how to build the xserver only?
May 22 16:17:20 <chackal_sjc> because I just need the xserver
May 22 16:17:44 <chackal_sjc> xorg-xserver ?
May 22 16:19:13 <sgw> Follow X11_IMAGE_FEATURES, probably x11-base is what you want to include in your image
May 22 16:20:27 <chackal_sjc> sgw: how to include that?
May 22 16:22:23 <kergoth`> so, is there no variable a machine can adjust to add/set the Xorg drivers/plugins it'll require? seems like this is a missing piece, and we should create such a var and use it in the x features/tasks. thoughts?
May 22 16:22:42 <sgw> chackal_sjc: you need to start with an image base of somekind, did you just build qt4-x11-free?  That's why I suggested the sato image, you could start with core-image-core, which include and then add qt4-x11-free to that.
May 22 16:24:49 <chackal_sjc> sgw: but how do I do that? bitbake core-image-core qt4-x11-free ?
May 22 16:41:47 <sgw> chackal_sjc: sorry, add to your EXTRA_IMAGE_FEATURES = "qt4-x11-free" in your local.conf
May 22 16:42:13 <bluelightning> er, I don't think that will work
May 22 16:42:41 <sgw> bluelightning: suggestion?
May 22 16:42:54 <bluelightning> it'll need to be added to CORE_IMAGE_EXTRA_INSTALL
May 22 16:43:27 <bluelightning> alternatively if you just want to include an app that needs qt, just include that app's package and it will pull in any needed qt packages (aside from utilities etc.)
May 22 16:55:43 <baby> KBRANCH = "standard/base"
May 22 16:56:00 <baby> KBRANCH_qemux86  = "standard/common-pc/base"
May 22 16:56:33 <baby> KBRANCH_qemux86 is for the qemux86 branch
May 22 16:56:47 <bluelightning> chackal_sjc: it's worth noting that adding qt4-x11-free as a package to your image will install *everything* that qt builds, which is almost certainly more than you need
May 22 16:56:48 <baby> KBRANCH =  is for ? what is used for?
May 22 16:57:04 <bluelightning> chackal_sjc: fine for initial testing though I guess
May 22 16:58:52 <chackal_sjc> bluelightning: just to build qt4 , should I add CORE_IMAGE_EXTRA_INSTALL="qt4-x11-free" ?
May 22 16:58:57 <chackal_sjc> in my local.conf
May 22 17:01:00 <bluelightning> chackal_sjc: that should work, yes, but as I said above that pulls everything in
May 22 17:01:11 <bluelightning> if that's OK for the moment, then no problem
May 22 17:04:04 <chackal_sjc> bluelightning: for now I just want to see it working
May 22 17:05:05 <chackal_sjc> bluelightning: in the end I want to make my own image that builds, Qt4(commercial), xorg-server, ofono, dbus,... stuff like that
May 22 17:05:18 <chackal_sjc> is there any doc that shows how to create an image like that?
May 22 17:05:24 <chackal_sjc> or at least some example
May 22 17:05:43 <chackal_sjc> I just want to build the root filesystem
May 22 17:07:27 <bluelightning> chackal_sjc: there's info on customising an image in the manual: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#usingpoky-extend-customimage
May 22 17:07:36 <zenlinux> pidge, I think I need a primer on using the autobuilder. Should I be able to queue up a nightly build for my 1.2.1 contrib branch now?
May 22 17:08:14 <chackal_sjc> bluelightning: thanks
May 22 17:11:57 <chackal_sjc> bluelightning: in long term, I have this scenario.
May 22 17:12:26 <chackal_sjc> I have a custom uboot and a custom kernel(I don't want to use the yocto), I also use CS toolchain(again, not the yocto) for both uboot and kernel...
May 22 17:12:47 <chackal_sjc> my root file system is like I already told you...
May 22 17:13:13 <bluelightning> chackal_sjc: sure, that is all possible
May 22 17:13:18 <chackal_sjc> the uboot and kernel recipes suppose to be easy, since it just needs to run 3 make commands and that's all(there is no dependencies in the recipe).. but when I bake my recipe, bitbake call other 500 recipes
May 22 17:13:21 <chackal_sjc> so that is a pain
May 22 17:14:06 <bluelightning> chackal_sjc: I think you probably overestimate how simple building such things are
May 22 17:14:35 <bluelightning> chackal_sjc: in any case, as I suggested before you can see why things are built using bitbake -g and bitbake -g -u depexp
May 22 17:14:47 <bluelightning> I gotta go, will probably be back later
May 22 17:25:56 <pidge> zenlinux: You should be able to
May 22 17:41:47 <kergoth`> seebs: can you summarize how one makes use of TUNEABI*? have to admit i didn't review those patches has closely as i should have, was occupied with other things
May 22 17:44:05 <seebs> Okay, the idea is this.  Say you have a prebuilt toolchain which has x86, x86_64, and core2 libraries.  You would use TUNEABI_WHITELIST = "x86 x86_64 core2".
May 22 17:44:26 <seebs> The reason this isn't just TUNING_WHITELIST is that you could then have some other tunings, maybe an i686 tuning, that would be described as
May 22 17:44:38 <seebs> TUNEABI_tune-i686 = "x86"
May 22 17:45:18 <seebs> If the i686 tuning's flags cause the compiler to pick up the x86 libraries, this will then work, but other tunings will be rejected.
May 22 17:45:58 <seebs> In WR Linux, we called the basic libraries "multilibs", even when you only had one of them, and the tunings on top of them were "cpus".
May 22 17:46:32 <seebs> So we'd have said that the i686 cpu relied on the x86 multilib.  Since multilib's used differently in yocto, I picked "TUNEABI" as capturing the thing we mean, which is the basic calling ABI.
May 22 17:46:56 <seebs> The underlying observation is that it rarely matters whether your libc is built with exactly the tuning flags you want for user code.
May 22 17:47:14 <seebs> So we tend to have a fairly basic least-common-denominator libc and multiple tunings which pick it up by reference.
May 22 17:49:32 <kergoth`> hmm, okay, that makes a certain amount of sense, i'll have to mull that over
May 22 17:50:48 <kergoth`> hmm... inspection of TUNE_CCARGS + ${CC} -print-multi-lib.. i wonder
May 22 17:51:05 <seebs> I'm still messing with it to see whether it actually works as planned.  It seems to so far.
May 22 17:51:15 <seebs> Ooh, that's a thought.
May 22 17:51:29 <kergoth`> you could in theory, *maybe* automatically set up the tuneabi vars
May 22 17:51:33 <kergoth`> but i don't know if that'd be viable or not
May 22 17:51:35 <kergoth`> just a thought
May 22 17:52:44 <kergoth`> e.g. this sourcery toolchain shows te500v2;@te500v2@fPIC@mstrict-align, yet only the -te500v2 triggers the use of that multilib, the other args don't seem required, so i'm a bit confused there, unless those are behaviors which are automatically enabled, and therefore don't need to be passed as args
May 22 17:53:07 * kergoth` scratches head
May 22 17:53:27 <kergoth`> or maybe i'm mis-parsing -print-multi-lib, haven't checked the gcc docs yet :)
May 22 17:54:07 <seebs> I am not quite sure.  It is totally possible that those are indeed enabled by default as part of it.  I'm still trying to get my head around how bitbake tunings work.
May 22 17:54:14 <seebs> They are dissimilar to the system I'm used to.  :)
May 22 17:54:55 * kergoth` nods
May 22 17:57:04 <kergoth`> parsing multi-lib wouldnt' tell you anything about the '.' multilib, either, so maybe thats just not viable. still a useful reminder for the person creating the vars, but .. hmm
May 22 17:57:07 * kergoth` ponders
May 22 17:57:45 <kergoth`> the tuneabi vars seem tightly bound to a particular toolchain, whereas the tcmode file is relatively general. guess we'd have to create variant tcmodes to enable that sanity checking
May 22 17:57:49 * kergoth` thinks
May 22 17:58:07 <fray> kergoth` the -t... automatically sets a number of items in the Sourcery toolchains
May 22 17:58:14 <kergoth`> yeah, i know
May 22 17:58:16 <fray> the -t is a shortcut to a whole list of options
May 22 17:58:35 <kergoth`> -t both sets the tunings we already set, and selects the multi-lib, in theory
May 22 17:58:43 <fray> yes
May 22 17:59:51 <kergoth`> hmmm
May 22 18:01:37 <seebs> Well, the way *I* was doing it was:
May 22 18:01:57 <seebs> I have a layer called wr-toolchain.  This layer sets the TCMODE, etc., and then sets the TUNEABI_* variables and such locally.
May 22 18:02:51 <seebs> So the idea is, it's just a configuration/setup thing in another layer's layer.conf.
May 22 18:03:15 <seebs> If you pick that layer, suddenly you have a bunch of TUNEABI settings and the Sourcery tcmode is selected and configured for you.
May 22 18:04:23 <kergoth`> ah, i see
May 22 18:04:59 <fray> my current feeling is the (binary) toolchain needs to be with a layer with all of it's configuration settings
May 22 18:05:02 <kergoth`> our of curiosity, what would be in that layer other than the layer.conf?
May 22 18:05:08 <fray> otherwise, it's too easy to get out of sync
May 22 18:05:23 <fray> the tune files that match the tunings of the toolchain..
May 22 18:05:39 <fray> since the -t<tune> is different then the combination of -mcpu=... =march=... items in the normal tunings
May 22 18:05:47 <seebs> Yeah, pretty much.  A heavily-modified copy of conf/machine, pretty much.
May 22 18:05:59 <kergoth`> it is? i thought it just set other vars + multilib
May 22 18:06:00 <seebs> And right now, copies of tcmode-external-csl.inc and csl-versions.inc because our tree is out of sync.
May 22 18:06:17 <kergoth`> fray: maybe we should consider splitting the sourcery toolchain bits out of oe-core
May 22 18:06:22 <seebs> ... and of course the unpacked binary toolchains.
May 22 18:06:28 * kergoth` thinks
May 22 18:06:43 <fray> no.. because when you select e500v2 for instance.. in the sourcery toolchain you want "-te500v2".. in the "real" gcc you want "-mcpu=e500v2 -mspe=double-precision"  (or something like that)
May 22 18:06:47 <fray> you get the idea though, it's "different"
May 22 18:07:03 <fray> the sourcery folks made it "easier" to get the right multilib.. but that results in the difference
May 22 18:08:09 <kergoth`> ppce500v2 in oe-core already passes -mcpu=e500v2 -mspe -mfloat-gprs=double, which i suspect matches up with -te500v2, but its a good point, they don't necessarily
May 22 18:08:24 <fray> yup
May 22 18:08:44 <fray> thats why we copy the conf/machine/include and adjust it to match the sourcery version
May 22 18:09:01 <fray> w/o doing that (our support contract) makes it more difficult to reproduce and thus get support from Mentor
May 22 18:10:27 <kergoth`> i was hoping to avoid the need to pass -te500v2 unconditionally, instead continuing to leverage existing TUNE_FEATURES, at least in the oe-core config, but maybe thats just a dream :)
May 22 18:12:15 <fray> we didn't feel that was safe for our particular case
May 22 18:12:31 * kergoth` nods
May 22 18:24:19 <Eren> it seems that https problem has been solved :)
May 22 18:26:12 <zenlinux> What are people's thoughts on pre-populating /etc/resolv.conf with OpenDNS servers for our QEMU sessions?
May 22 18:26:38 <incandescant> I think connman will clobber /etc/resolve.conf ?
May 22 18:26:53 <zenlinux> incandescant, how about for core-image-minimal?
May 22 18:27:00 <zenlinux> (which doesn't have conman)
May 22 18:27:08 <fray> I'd rather we put in a DNS proxy for the qemu session based on the host
May 22 18:27:21 <incandescant> I'm not against the idea, I'm just suggesting that connman may put a spanner in the works :-)
May 22 18:27:31 <fray> (I've been on ISPs before that filter DNS to their own servers and such.. a dns proxy would allow the working host config to be used seemlessly
May 22 18:27:45 <zenlinux> fray, ah, interesting point
May 22 18:28:26 <fray> trying to remember the name of the dns proxy I saw.. it was -very- small and simple..
May 22 18:29:07 <zenlinux> fray, would this then mean we'd need to add a dns proxy service on the host OS?
May 22 18:30:00 <fray> http://sourceforge.net/projects/dproxy/
May 22 18:30:46 <zenlinux> so start up something like this from the runqemu script before booting the qemu session?
May 22 18:30:57 <fray> the code is -very- old, for all I know it won'te ven work with dnssec.. but it's used on a hell of a lot of DSL modems..
May 22 18:31:21 <fray> they use iptables to capture DNS requests, and then route them internally to the proxy that is configured to read the (dsl modems) /etc/resolve.conf for their DNS resolution table..
May 22 18:31:32 <fray> ensuring all of requests end up with the ISP... thus the ISP can be evil and filter stuff
May 22 18:34:25 <fray> dnrd might be better..
May 22 18:34:30 <fray> they have versions for other platforms as well
May 22 18:42:06 <Jay7> pdnsd :)
May 22 18:42:20 <Jay7> but this is not just proxy
May 22 18:55:31 <fray> thought pdnsd was python based..
May 22 18:55:38 <fray> (maybe I'm thinking of something else)
May 22 21:38:16 <kergoth`> what's the purpose of virtual/gettext?
May 22 23:26:24 <halstead> pidge, Back.
May 22 23:26:43 <halstead> pidge, It worked before because of the bad default route.
**** ENDING LOGGING AT Wed May 23 02:59:59 2012

**** BEGIN LOGGING AT Wed May 23 02:59:59 2012
**** ENDING LOGGING AT Wed May 23 04:35:22 2012

**** BEGIN LOGGING AT Wed May 23 04:36:15 2012
May 23 07:35:06 <mckoan> good morning
May 23 07:42:37 <florian> hi mckoan
May 23 11:12:06 <bizhanMona> HI Does Yocto has support for kvm?
May 23 14:11:34 <moolinex> do_fetch fails on libowl_git.bb anyone? ideas?
May 23 14:33:40 <comphappy> I have specified a different git repo for the linux kernel and I am getting an odd error when it is looking for the license file: /mnt/cldstr/erallo/newyocto/build/tmp/work/armv5te-poky-linux-gnueabi/linux-yocto-3.2.11+git1+76eb471d179ef5a4a8624f24ed0729d68648a770-r1/linux-yocto-3.2.11+git1+76eb471d179ef5a4a8624f24ed0729d68648a770/COPYING
May 23 14:33:52 <comphappy> there is nothing in that folder
May 23 14:34:19 <comphappy> I would expect that the content of the git repo to be there
May 23 15:12:53 <fray> morning
May 23 15:13:21 <moolinex> morning
May 23 15:35:00 <kergoth`> meh
May 23 17:24:09 <mranostay> mooing
May 23 18:34:41 <sgw> pidge: incandescant: Looking at the failure of the AB, I am wondering if SSTATE_DIR is not getting passed correctly, but why if fails just here???  The check was recently added I think by incandescant.
May 23 18:36:54 <pidge> sgw: It shouldn't be the case, at least not from an infrastructure stand point. The part that's interesting here is that it's auto.conf shows the correct SSTATE_DIR: http://autobuilder.yoctoproject.org:8010/builders/nightly-mips/builds/399/steps/shell_14/logs/stdio
May 23 18:38:16 <pidge> sgw: incandescant: Also, the denzil branch zenlinux is working on does run sanity correctly. So my off the cuff guess here is that it's either on of the sstate changes or a runqemu change. I know the change happened after the 13th so that narrows it down a bit.
May 23 18:38:53 <sgw> pidge: right, but somehow it's not getting picked up, it has to do with the perms checks that incandescant added
May 23 18:39:04 * sgw swims
May 23 18:39:08 <kergoth`> are we talking about the error about the permissions for the directory? i get hit by that every time i start from scratch with a nonexistent sstate dir
May 23 18:39:13 <kergoth`> a second build without changing anything works fine
May 23 18:40:57 <seebs> Hey, people!  I have an experimental feature I would like to propose for moving to upstream once it's implemented, based on a feature WR Linux had.
May 23 18:41:32 <seebs> Toolchain wrappers!  Which is to say, once you have a toolchain, you make new programs with slightly different names that can be used to compile with given ABI and sysroot settings automatically.
May 23 18:41:49 <pidge> kergoth: I'm getting hit with it on sanity with a prepopulated shared SSTATE_DIR. First sanity runs fine. Second chokes with the error from c2df43b5dbeadc6
May 23 18:42:05 <seebs> So the idea is, you'd run a build, and then if you needed a hello-world, you'd type something like cross-compile/i686-yocto-target-gcc -o hello hello.c
May 23 18:42:18 <seebs> And it would infer things like the CC arguments, sysroot, and so on, and Do What You Mean.
May 23 18:42:33 <seebs> WR Linux had this and it was STUPENDOUSLY useful for iterating and experimenting.
May 23 18:43:20 <seebs> I have a half-baked implementation of this which is currently tied to some of our assumptions, but which could be further improved and made useful with the native toolchain as well.
May 23 18:44:46 <pidge> kergoth`: Any chance that you're doing this with an NFS mounted SSTATE_DIR?
May 23 18:45:13 <kergoth`> nope, all local
May 23 18:46:35 <pidge> kergoth`: Is it at least returning the correct SSTATE_DIR?
May 23 18:47:04 <kergoth`> it says it has no permissions to write to a directory that exists and has correct permissions.
May 23 18:47:25 <kergoth`> it's clearly a bug in the logic of the sstate sanity check, but i haven't had time to investigate further
May 23 18:55:03 <pidge> kergoth`: ty. Trying to narrow down why this is doing this.
May 23 18:55:18 <incandescant> kergoth`: iirc you don't use oe-init-build-env ?
May 23 18:55:55 <kergoth`> incandescant: true
May 23 18:56:04 <incandescant> I'm curious that you would see it every time and I've never seen it, that gives me something to look at
May 23 18:56:43 <incandescant> I know I failed to test thoroughly, I just don't know what people are doing differently so I can reproduce
May 23 18:56:56 <kergoth`> at mentor we use our own setup tool, and personally i use a submodule based setup
May 23 19:00:06 <incandescant> I'll spend some more time trying to reproduce
May 23 19:00:26 <kergoth`> i'll see if i can get a trimmed down setup that shows it, if i find time today
May 23 19:00:42 <incandescant> thanks, that'd be awesome but I understand not a priority
May 23 19:27:07 <incandescant> hmm... I suppose I could just have the check_create_long_filename() test return its errno as well as a string and test the errcode for 13 (permission denied) and tack onto the messages in that instance
May 23 19:28:56 <pidge> incandescant: I find it interesting that I only see it on the second sanity and it returns the incorrect SSTATE_DIR. Ideas?
May 23 19:32:02 <incandescant> pidge: not really, the code I introduced doesn't affect how that variable is set. In this case it just reveals that at that time it's not set as expected.
May 23 19:35:36 <kergoth`> what event triggers these checks, again, ConfigParsed? BuildStarted?
May 23 19:36:08 <incandescant> ConfigParsed
May 23 19:36:17 <pidge> incandescant: That's the point. It says to me that something is going on there.
May 23 19:36:43 <kergoth`> does it do a finalize()? that's the danger with ConfigParsed, the datastore hasn't been finalized, have to remember to do that whenever doing sanity checks and the like
May 23 19:36:51 <kergoth`> otherwise appends/overrides won't be applied
May 23 19:37:08 <kergoth`> i'd assume it does, but that was the only thing that'd affect the value that came to mind
May 23 19:37:11 <incandescant> sanity.bbclass doesn't explicitly call finalize
May 23 19:38:13 <kergoth`> it should do a d.createCopy() or similar, then calling finalize() on that copy, and using that from then on, afaik
May 23 19:38:47 <incandescant> it does not
May 23 19:39:22 <incandescant> there's a createCopy() when some variables are being modified by a test, maybe we should do that at the beginning of check_sanity?
May 23 19:39:37 <kergoth`> that's what i'd suggest. createcopy, finalize, pass the new copy to everything from then on
May 23 19:39:43 <kergoth`> do it right away in the event handler
May 23 19:39:50 <incandescant> kergoth`: ok, cool - thanks
May 23 19:39:56 <incandescant> I'll create a patch for that shortly
May 23 19:40:01 * incandescant -> afk, bbiab, etc
May 23 19:40:05 <kergoth`> but, it depends, if any vars are set that you want to be set permanently, for tasks, then it'll need to set them on the main e.data object, obviously
May 23 19:40:16 <kergoth`> hopefully sanity doesn't set anything like that, though :)
May 23 20:36:54 <incandescant> oh no, the reason there's code already which takes a copy is so that the main data object isn't changed
May 23 20:52:17 <kergoth`> incandescant: actually, i'd suggest moving the sanity checks to BuildStarted instead of ConfigParsed, then they would still occur once at the start of the build, but wouldn't prevent bitbake -e from showing information
May 23 20:52:56 <incandescant> kergoth`: good idea! I'll include that in my series too, though as a separate change
May 23 20:53:07 * kergoth` nods
May 23 21:11:44 <sgw> pidge: we seem to have the same issue with LSB
May 23 21:33:24 <seebs> So, any feedback from anyone on the concept of toolchain wrappers for prototyping/developing?  I need to do these anyway because our customers want 'em, but I'm inclined to try to make them clean and portable.
May 23 21:41:42 <pidge> sgw: yes. Sent an email to the yocto-builds list on it. scroll up a bit to see discussion on it.
May 23 23:02:21 <sgw> pidge: I assume you will announce the weekly even with the sanity
May 23 23:06:03 <sgw> fray you around?
May 23 23:15:24 <pidge> sgw: Yes. I'm banging my head on the new ab setup. I'm going to take a break and then send out the weekly email in a moment before PRC gets in.
May 24 00:03:49 <incandescant> pidge: kergoth`: FYI I've just submitted a series of changes against sanity.bbclass
May 24 00:07:02 <pidge> incandescant: ty.
May 24 00:07:35 <incandescant> caveat: I'm unable to reproduce the issue so I can only tell you that the changes WFM :-)
May 24 00:10:00 <pidge> incandescant: That's fine, the AB seems to always reproduce it. I'll run a 1.1.2 after the weekly is done and then queue up a master for tomorrow.
May 24 00:11:34 <incandescant> pidge: if the changes aren't on master at that point it might be worth running josh/sanity
May 24 00:29:19 <kergoth`> incandescant: nice, will check it out
May 24 00:37:36 <pidge> incandescant: They should be. RP generally has them in by then. If not, I'll run josh/sanity. But are you ok for a 1.1.2 tonight?
May 24 00:38:14 <incandescant> pidge: yes, that branch is good to go - josh/edison
May 24 00:41:13 <pidge> incandescant: ok, queued up.
May 24 00:41:21 <incandescant> thanks pidge
May 24 00:41:38 <sgw> pidge: can I get a mut over night?  I will pull those changes
May 24 00:49:56 <pidge> sgw: if incandescant can wait for a 1.1.2?
May 24 00:50:13 <sgw> pidge: 1.1.2 and then mut
May 24 00:51:42 <pidge> sgw: ok, I'll queue up a mut.
May 24 00:52:11 <sgw> pidge great after 1.1.2
May 24 02:47:30 <mranostay> so has anyone receive the free FRI2 box from Yocto Day yet?
May 24 02:55:56 <msm> nope
May 24 02:56:06 <msm> err rather.. not me ;)
**** ENDING LOGGING AT Thu May 24 02:59:58 2012

**** BEGIN LOGGING AT Thu May 24 02:59:58 2012
May 24 03:01:25 <kergoth`> whew, confirmed that josh/sanity fixes those sanity permissions errors i was seeing
May 24 06:31:07 <snkt> can I able to knew .... why in ARM based embedded system we have to give hardcoded LCD Screen resolution parameters? why the drivers detects the possible screen resolution supported by an LCD ?
May 24 07:21:18 <mckoan> good morning
May 24 11:31:02 <ag> Hello. Anybody can help me with some strange boot-time errors with sysvinit?
May 24 11:31:42 <ag> bootlogd can't start at boot with sysvinit throwing this error: bootlogd cannot allocate pseudo tty - no such file
May 24 11:32:03 <ag> After foort i can start this daemon without any problems.
May 24 11:32:23 <ag> boot*
May 24 11:32:37 <ag> poweroff
May 24 11:32:51 <ag> (missed the window :) )
May 24 11:36:25 <RP__> ag: sounds like missing /dev entries or mounts it needs?
May 24 11:36:43 <moolinex> or missing udev
May 24 11:37:09 <ag> udev is started just above it
May 24 11:37:26 <ag> Starting udev
May 24 11:37:32 <ag> Starting bootlog daemon :...
May 24 11:39:50 <moolinex> do you have a /dev/ entry in /etc/mtab ?
May 24 11:41:38 <ag> i have /dev/root, /dev/mmc*, /dev/shm, .dev.prs.
May 24 11:42:01 <ag> moolinex: /dev/pts
May 24 11:42:23 <moolinex> just plain /dev/ ?
May 24 11:42:41 <moolinex> e.g.: udev /dev tmpfs etc,etc
May 24 11:42:59 <ag> hmm... nope
May 24 11:47:21 <ag> moolinex: mtab is a symlink to /proc/mounts
May 24 11:48:54 <moolinex> that's fine
May 24 11:49:11 <ag> Yes. But don't know why there is no /dev entry there...
May 24 11:50:06 <moolinex> you said that, after boot, you can start the service ok?
May 24 11:50:32 <ag> moolinex: Yes.
May 24 11:51:37 <moolinex> it's weird that bootlogd is started right after udev ...
May 24 11:52:03 <moolinex> is there a devfs service being started separately by chance?
May 24 11:52:35 <ag> Nope...
May 24 11:53:09 <moolinex> do you have one ? :)
May 24 11:53:49 <moolinex> brb
May 24 12:49:56 <moolinex> back
May 24 12:50:11 <ag> i realized that i had no devtmpfs in kernel
May 24 12:50:14 <ag> now it is mounted ok
May 24 12:50:22 <ag> but the problem is still here
May 24 12:53:28 <moolinex> ag: and, still, after booting, bootlogd can be successfully started?
May 24 12:53:33 <ag> yes
May 24 12:54:02 <ag> bootlogd -r
May 24 12:54:05 <ag> echo $? = 0
May 24 12:54:11 <ag> And it is in ps
May 24 12:55:46 <moolinex> hm
May 24 12:56:37 <ag> it seems like ptmd is not here fast enough...
May 24 12:56:53 <moolinex> i think that you should have bootlogd in the "boot" run-level
May 24 12:57:15 <moolinex> currently you may have udev and bootlogd both in sysinit
May 24 12:58:36 <ag> Strange as this is the way yocto does it.
May 24 13:02:37 <ag> I found the problem.
May 24 13:02:58 <moolinex> ag: maybe placing it in boot will work for you
May 24 13:03:05 <moolinex> ag: which is? :)
May 24 13:04:08 <ag> moolinex: :) S38devtpts.sh S07bootlogd
May 24 13:04:14 <ag> moolinex: Rings a bell?
May 24 13:04:37 <moolinex> :))
May 24 13:05:10 <ag> moolinex: Pfff.... now it's funny when it's solved.
May 24 13:05:12 <ag> :)
May 24 13:05:51 <ag> moolinex: Gotta go. Thanks a lot for your help.
May 24 13:06:01 <moolinex> ok
May 24 13:06:05 <moolinex> np
May 24 13:06:08 <moolinex> you're welcome
May 24 13:14:30 <moolinex> ag: i still think that udev is missing somehow somewhere, before bootlogd
May 24 14:00:07 <ag> moolinex: mda...
May 24 14:11:58 <moolinex> ag: :)) what?
May 24 14:27:32 <comphappy> I built some arm images, and I am trying to test them with runqemu, but I cannot seem to specify MACHINE to the script
May 24 14:28:00 <comphappy> I get Error: unable to classify arg [MACHINE=qemuarm]
May 24 14:40:40 <eballetbo> hi, someone had encountered following  problem ...
May 24 14:40:43 <eballetbo> rpmdb: mmap: Invalid argument
May 24 14:40:55 <eballetbo> was running rpm under jffs2 filesystem
May 24 14:51:44 <eballetbo> mmm... seems an ancient issue, sorry for the noise
May 24 14:53:34 <exosyst> Should binaries compiled on my fedora x86 host run on an Atom board running Yocto?
May 24 14:58:43 <RP__> exosyst: "possibly". I can think of ways it might work and ways it might not
May 24 15:16:06 <exosyst> RP__, Oh?
May 24 15:26:40 <ag> RP__: What is the best approach for this bug: bootlogd comes from sysvinit and is added to rsS wth S07. This needs devppts from initscripts which includes this in rcS with S37. This dependency is broken as you can see.
May 24 15:42:25 <RP__> ag: we need to reorder the scripts to account for that I guess
May 24 15:43:45 <kergoth`> hmm, i need to find the time to take another look at oe-lite, see how much work it'd be to pull some of its improvements
May 24 15:43:54 <kergoth`> course, finding that time seems to be nontrivial
May 24 15:45:05 <ag> RP__: What do you say to bring devpts to S04 just after S03 which is udev.
May 24 15:45:23 <ag> that solves my problem and keeps the dependency of devpts to udev.
May 24 15:49:07 <RP__> I'd really like to understand what else is in the init system around that time...
May 24 15:50:08 <ag> RP__: Correct. But right now this is a bug. And in my opinion devpts should be up as soon as possible
May 24 15:50:37 <RP__> ag: What I don't want to do is break something else by fixing this
May 24 15:50:57 <RP__> ag: presumably there was a reason we left this until S37...
May 24 15:51:10 <ag> RP__: Yeah i know...
May 24 15:51:46 <RP__> ag: for example, I know we used to have issues with mounting of /sys and /proc and so on which if I remember rightly devpts depends upon
May 24 15:52:00 <RP__> ag: I think udev now does it all but I don't know for sure
May 24 15:53:09 <ag> RP__: I read about this as well. This was my concern and didn't go with a patch.
May 24 15:54:00 <RP__> kergoth`: I know the feeling :/
May 24 16:08:21 <ag> RP__: Thank you. I filled a bug on this topic. We will discuss there about this.
May 24 16:08:28 <ag> Gotta go now. Cheers all!
May 24 16:26:30 <exosyst> RP__, Hmm, I don't think it works properly
May 24 16:26:41 <exosyst> RP__, I get a segfault on gstreamer
May 24 16:26:50 <exosyst> RP__, Could just be me and not the toolchain
May 24 16:27:24 <RP__> exosyst: Its impossible for me to comment really...
May 24 16:27:30 <RP__> too many different variables
May 24 17:14:11 <chackal_sjc> guys
May 24 17:14:40 <chackal_sjc> qt4.inc has this directive to the ./configure script "-crossarch ${QT_ARCH}"
May 24 17:15:01 <chackal_sjc> but the thing is, qt4.8.0 doesn't have this argument
May 24 17:38:52 <chackal_sjc> I got it
May 24 17:38:57 <chackal_sjc> they insert it in some patches
May 24 18:53:26 <kergoth`> damn, the file checksums thing is exposing all sorts of seemingly missing files in my builds :)
May 24 19:13:36 <kergoth`> what the heck. my tcmode-external-csl.inc which loads tcmode-external-sourcery.inc doesn't work. that is, the preference vars end up set, yet bitbake thinks they aren't
May 24 19:13:38 * kergoth` is confused
May 24 19:14:32 * kergoth` switches his config to external-sourcery and punts on this till later
May 24 19:15:24 <mranostay> kergoth`: talking to ourselves? :)
May 24 19:15:48 <kergoth`> it makes no sense. it says i should define PREFERRED_PROVIDER_virtual/libc, yet bitbake -e shows that exact variable set
May 24 19:16:34 <kergoth`> actually, even using external-sourcery it's doing that, but only for one variable there
May 24 19:16:38 <kergoth`> what the hell is going on?
May 24 19:16:39 <kergoth`> :|
May 24 19:18:33 <sgw> fray, with Robert's patch added, a rebase is needed of the rpm update.
May 24 22:31:05 <kergoth`> anyone know if/when meta-yocto will become its own repository?
May 24 23:03:20 <chackal_sjc> how to check the graph dependencies without graphiz dot syntax?
May 24 23:03:24 <chackal_sjc> is there other option?
May 24 23:04:03 <kergoth`> bitbake -u depexp -g <recipe>
May 24 23:04:09 <kergoth`> graphical dependency explorer UI
May 24 23:04:34 <chackal_sjc> thx
May 24 23:07:24 <chackal_sjc> kergoth`: but how to check which depedency depends on a specific recipe?
May 24 23:07:38 <kergoth`> ?
May 24 23:07:39 <chackal_sjc> reverse dep?
May 24 23:07:41 <chackal_sjc> i mean
May 24 23:07:44 <kergoth`> that's in the UI
May 24 23:07:49 <chackal_sjc> yeah yeah
May 24 23:07:50 <kergoth`> if you'd bothere to run it the way i told you to
May 24 23:07:52 <kergoth`> you'd have seen that
May 24 23:07:52 <chackal_sjc> lemme explain
May 24 23:08:06 <kergoth`> you click on a recipe, it tells yo uwhat it depends on, and what depends on it
May 24 23:08:07 <kergoth`> both directions
May 24 23:08:22 <chackal_sjc> I copied the qt4-x11-free to a qt4-x11-commercial recipe
May 24 23:08:42 <chackal_sjc> but i don't know why, my qt4-x11-commercial depends on the free one..
May 24 23:08:48 <chackal_sjc> so its building the free also
May 24 23:09:18 <chackal_sjc> and when I check the dep for the qt4-x11-free, it says in reverse dependencies, that qt4-x11-commercial needs that
May 24 23:09:34 <kergoth`> then your question isn't *what* the dependencies are, it's *why*
May 24 23:09:37 <kergoth`> and that info isn't easily available
May 24 23:09:46 <chackal_sjc> hmm
May 24 23:09:49 <kergoth`> other than through inspecting recipes, obviously
May 24 23:10:06 <kergoth`> a certain amount of info is available in the .dot files, but it's not always ssufficient
May 24 23:16:31 <chackal_sjc> kergoth`:
May 24 23:16:33 <chackal_sjc> I found it
May 24 23:16:39 <chackal_sjc> I believe its a bug
May 24 23:17:12 <chackal_sjc> meta/classes/qt4x11.bbclass
May 24 23:17:12 <chackal_sjc> 1:DEPENDS_prepend = "${@["qt4-x11-free ", ""][(d.getVar('BPN', True)[:12] == 'qt4-x11-free')]}"
May 24 23:17:35 <chackal_sjc> since my BPN is qt4-x11-commercial.. it will prepend the qt4-x11-free depedency
May 24 23:25:50 <chackal_sjc> yeah, it is
May 24 23:25:56 <chackal_sjc> i checked
May 24 23:26:48 <chackal_sjc> that condition is pretty ugly.. i don't even know who wrote's intention
**** ENDING LOGGING AT Fri May 25 02:59:59 2012

**** BEGIN LOGGING AT Fri May 25 02:59:59 2012
May 25 08:14:17 <moolinex> morning
May 25 08:15:23 <ilepetrisor> morning moolinex :)
May 25 08:39:14 <RP__> morning all
May 25 09:08:13 <stuk_gen> hi all :) can somebody said me how is manage the qt recipes from yocto to angstrom?
May 25 09:10:22 <RP__> stuk_gen: I don't understand the question, the same qt recipes should work fine in both
May 25 09:11:55 <stuk_gen> RP__: i'm using angstrom to build image, and in my /meta/recipes-qt/ i have 4.8.0 but if i look at http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-qt/qt4 i see there is 4.8.1
May 25 09:12:44 <stuk_gen> so i think there is a people that 'copy' or manage the qt reciper from yocto feed to angstrom feed no?
May 25 09:12:54 <stuk_gen> recipes*
May 25 09:17:54 <RP__> stuk_gen: I don't know, this is a question for the angstrom people
May 25 09:18:11 <RP__> stuk_gen: It sounds like you need to update the OE-Core revision
May 25 09:18:29 <stuk_gen> RP___: angstrom people get the ball to you...you to angstrom...recursive loop :)
May 25 09:19:08 <stuk_gen> RP____: but who is the source of the qt recipes?
May 25 09:19:44 <RP__> stuk_gen: That qt recipe is coming from OE-Core. As you can see we've updated. Why Angstrom has not updated to match I do not know. Is this on a release branch or something?
May 25 09:21:17 <stuk_gen> RP___: ok so the reciper for qt is OE-CORE...interesting thanks. I don't know the anwser to your question
May 25 09:53:56 <ignus16> hi all - does anyone know what might cause the following when using a ramdisk to test my rootfs: "ERROR: postinst /etc/rpm-postinsts/* failed."
May 25 10:08:04 <RP__> ignus16: is it readonly?
May 25 10:38:00 <ignus16> RP__: i think so... ramdisks are usually readonly i think...
May 25 11:54:39 <Howard> how i can remove perl before bitbaking so it is not built?
May 25 12:04:11 <Howard> during core-image-rt it keeps returning failure
May 25 12:04:22 <Howard> ( atom-pc )
May 25 13:57:10 <ignus16> does anyone know how i would go about mounting debugfs on boot in yocto?
May 25 14:05:34 <RP__> ignus16: add it to /etc/fstabs?
May 25 14:28:42 <kergoth`> RP__: https://gist.github.com/2788410
May 25 14:29:40 <kergoth`> RP__: just a prototype obviously, but i was surprised at how painless it was to try out
May 25 14:49:09 <exosyst> During a poky build, how do I trigger the make menuconfig for busybox?
May 25 14:56:42 <exosyst> I want to configure the core-image-minimal but not sure how best to override the recipes as opposed to the traditional menuconfig approach
May 25 14:56:55 <exosyst> How can I do this for busybox?
May 25 15:04:16 <hollisb> exosyst: the kernel recipe has a "menuconfig" command; maybe busybox does too. try bitbake -c menuconfig busybox
May 25 15:06:09 <exosyst> hollisb, I'll give that a go thanks. Is there a guide on how to override the default recipes or is it just pulled form the general docs on the main yocto site?
May 25 15:08:30 <exosyst> hollisb, or should I just edit the recipes/busybox/.../defconfig?
May 25 15:17:36 <exosyst> Hmm - I want to add an SSH server to my rootfs and I thought dropbear came as part of busybox. Is there a preferred sshd that I can easily add in?
May 25 15:19:39 <hollisb> exosyst: the "right" way is to provide your own recipe that overrides the default defconfig
May 25 15:20:35 <exosyst> hollisb, I apologise. I think I asked the wrong question. I want an SSH server in my rootfs. I thought I had to get it by messing with busybox but it looks like it might be a flag I can set?
May 25 15:24:32 <hollisb> exosyst: dropbear is a separate package
May 25 15:24:55 <hollisb> exosyst: I believe there's standard documentation describing how to add a package to your rootfs
May 25 15:25:06 <hollisb> (though I don't know a link off the top of my head)
May 25 15:26:09 <exosyst> hollisb, yeah I realise that now - classic mistake. I would've thought I could just add IMAGE_FEATURES += "ssh-server" into my local.conf?
May 25 15:28:18 <hollisb> I don't know what counts as a "feature" or not. I think you can actually specify packages in local.conf somehow, but it's frowned upon
May 25 15:29:04 <hollisb> because in contrast to using a proper layer, your local.conf isn't shared with co-workers or the next time you check out your code
May 25 15:33:42 <exosyst> hollisb, Right - so I'm better off creating my own layer? The problem is I'm working with proof of concept stuff atm and imagine doing it with a layer would be quite involved?
May 25 15:37:23 <fray> morning....
May 25 15:38:11 <fray> exosyst, I always suggest to people when they're prototyping and such to create a scratch layer..  this way they can just create recipes and dump things in there and use them... once it does what they want, then you work on making it more "production ready"
May 25 15:39:15 <exosyst> fray, That's a good point. I should probably figure it out at some point!
May 25 15:45:52 <fray> setting a basic layer is pretty easy.. if you need help, let me know and I have some default configuration files I use..
May 25 16:02:52 <dvhart> exosyst, CORE_IMAGE_EXTRA_INSTALL += "dropbear"
May 25 16:03:14 <dvhart> for core-image-base, sato, etc (does not work for minimal)
May 25 16:03:48 <dvhart> indexing these sorts of questions into the existing documentation (which does cover it) is difficult :/
May 25 16:04:38 <exosyst> dvhart, Thanks I slapped IMAGE_FEATURES += "ssh-server-dropbear"
May 25 16:04:38 <exosyst> IMAGE_INSTALL_append = " dropbear" and it worked for my core-image-minimal
May 25 16:05:13 <exosyst> fray, yeah it would be good to get some up on a wiki or something. I've been posting stuff as I go on github in gists :(
May 25 16:05:14 <dvhart> exosyst, I shouldn't think you would need both
May 25 16:07:16 <exosyst> dvhart, I was reading 4.2.3.on http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html and it looked like I had to choose a package as well as a FEATURE. I agree it's hard to add these into the docs - perhaps a Cookbook style document could be put together? I'm happy to help but unless it's official it would become *another* resource that falls through the googlegaps
May 25 16:07:37 <fray> the featue usually enables the image install as well, but not always
May 25 16:08:56 <exosyst> fray, haha, fantastic. Well I'm double-plus guaranteeing it
May 25 16:09:06 <kergoth`> exosyst: most image features are just groups of packages, a convenience to avoid having to manually add packages to IMAGE_INSTALAL.
May 25 16:09:12 <dvhart> exosyst, see the how-do-i pages
May 25 16:09:25 <kergoth`> bitbake -e | grep \^PACKAGE_GROUP_
May 25 16:09:27 <dvhart> exosyst, yeah, the feature should be sufficient
May 25 16:09:44 <kergoth`> though, bitbake -e <imagename. would probably be better
May 25 16:11:13 <exosyst> hmm - that's interesting, I like the how-do-i page; it's very useful.
May 25 16:23:37 <chackal_sjc> what are available values for TARGET_VENDOR ?
May 25 16:27:18 <kergoth`> it's just an arbitrary string
May 25 16:27:31 <kergoth`> you can put whatever you want there, it's called vendor because that's whats often put there
May 25 16:28:54 <chackal_sjc> ok
May 25 16:29:19 <chackal_sjc> kergoth`: how the yocto splash screen works?
May 25 16:29:59 <chackal_sjc> I would like to set our own splashscreen.. and also, where do I look at to startup some application(Qt) just after the boot, like sato
May 25 16:37:10 <kergoth`> no idea, haven't looked at splash sutff in a long time
May 25 16:39:08 <chackal_sjc> do you know who could help me with that?
May 25 16:53:59 <mranostay> *ahem* google
May 25 16:55:04 <mranostay> chackal_sjc: you want psplash probably
May 25 16:55:34 <chackal_sjc> does yocto support plymouth ?
May 25 19:47:49 * pidge looks at the autobuilder. Downtime is going to be around 10PM UTC.
May 25 21:22:29 <halstead> sgw, https://bugzilla.yoctodev.org/ is ready to look at.
May 25 21:28:53 <sgw> halstead: looking, unfortunately I already see some issues, not sure how we can best resolve this, for example in Layers - oe-core, there is core and layers-oe-core, they should be collapsed into something like Core recipes - all other recipes that are not Graphics,Kernel,Connectivity
May 25 21:29:40 <sgw> I am not sure I understand the usage of the 3 "*Testing" Components, are they for the test suites and instructions?
May 25 21:30:37 <halstead> sgw, The first issue you see is a result of replacing general with a repeat of the product name to make it filterable.
May 25 21:31:03 <halstead> sgw, I could switch it back to general for a moment so you can see it how we first intended.
May 25 21:31:08 <sgw> we should collapse those two then, at least in that case
May 25 21:31:21 <sgw> No, I think that's fine
May 25 21:31:48 <halstead> Ok. I'll collapse those into "core".
May 25 21:32:37 <halstead> sgw, As far as testing are you seeing these 4 from the new QA class (https://bugzilla.yoctodev.org/enter_bug.cgi?classification=QA%2FTesting)
May 25 21:32:55 <pidge> halstead: https://bugzilla.yoctodev.org/describecomponents.cgi?product=AutoBuilder should read "General issues related to the Autobuilder"
May 25 21:33:38 <halstead> Thanks pidge my copy paste must have messed.
May 25 21:34:19 <pidge> halstead: No problem. I'm seeing a few descriptions that I know I have entries for
May 25 21:34:27 <pidge> but are listed as pending
May 25 21:40:27 <halstead> redeploying with changes.
May 25 21:45:26 <halstead> Done.
May 25 22:12:13 <chackal_sjc> guys, im getting a lot of
May 25 22:12:14 <chackal_sjc> NOTE: consider defining a PREFERRED_PROVIDER entry to match libqtdeclarative4-dev
May 25 22:12:14 <chackal_sjc> NOTE: multiple providers are available for runtime libqtpvrqwswsegl4-dev (qt4-x11-commercial, qt4-x11-free)
May 25 22:12:17 <chackal_sjc> for all qt libraries
May 25 22:12:46 <incandescant> have you set a PREFERRED_PROVIDER entry, as the message suggests?
May 25 22:12:48 <chackal_sjc> and I've put this in my distro conf
May 25 22:12:49 <chackal_sjc> PREFERRED_PROVIDER_qt4 = "qt4-x11-commercial"
May 25 22:12:58 <chackal_sjc> but doesnt work
May 25 22:16:42 <kergoth`> that wont work, unless 'qt4' is in both recipes PROVIDES
May 25 22:17:09 <chackal_sjc> so, what should I do?
May 25 22:17:16 <chackal_sjc> because I'm getting this to all qt libraries
May 25 22:17:26 <kergoth`> PREFERRED_PROVIDER_qt4-x11-commerial = "qt4-x11-commercial" - will quiet that message. bitbake will see a preference, any preference, on that recipe, and implicitly apply that preference when encountering the runtime multiple provider situation
May 25 22:17:39 <chackal_sjc> ok
May 25 22:17:40 <chackal_sjc> thx
May 25 22:18:34 <incandescant> you may want to consider having the qt recipes PROVIDES qt4 and changing dependencies on qt4-x11-free to qt4
May 25 22:18:38 <chackal_sjc> kergoth`: I'm still getting the message
May 25 22:18:45 <incandescant> a patch for that might be useful, too
May 25 22:19:10 <chackal_sjc> but I do not have a dependency on qt4-x11-free
May 25 22:19:14 <kergoth`> ideally bitbake would support direct statement of runtime preferences, but it doesn't have that today
May 25 22:19:47 <kergoth`> your issue isn't a dependency, it's a runtime dependency. as the message implies, something rdepends on libqtdeclarative4-dev, which is emitted by both recipes, and bitbake doesn't know which to build
May 25 22:20:16 <chackal_sjc> now its good
May 25 22:20:29 <chackal_sjc> you wrote commerial and not commerCial
May 25 22:20:30 <chackal_sjc> ;)
May 25 22:21:10 <chackal_sjc> ok
May 25 22:21:21 <chackal_sjc> another thing
May 25 22:21:54 <chackal_sjc> I have my own image, like this
May 25 22:22:02 <chackal_sjc> IMAGE_INSTALL = "task-core-x11-mini qt4-x11-commercial"
May 25 22:22:03 <chackal_sjc> inherit core-image
May 25 22:22:20 <chackal_sjc> the problem is that when I boot the rootfs, x server wont start
May 25 22:22:35 <chackal_sjc> xinit got errors
May 25 22:22:55 <chackal_sjc> Starting Xserver
May 25 22:22:55 <chackal_sjc> Starting syslogd/klogd: done
May 25 22:22:55 <chackal_sjc>  * Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon
May 25 22:22:55 <chackal_sjc> _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6
May 25 22:22:55 <chackal_sjc> _XSERVTransOpen: transport open failed for inet6/g2:0
May 25 22:22:55 <chackal_sjc> _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6
May 25 22:22:56 <chackal_sjc> xinit: XFree86_VT property unexpectedly has 0 items instead of 1
May 25 22:22:56 <chackal_sjc> D-BUS per-session daemon address is: unix:abstract=/tmp/dbus-GHBVeYfS2j,guid=3db12ad14be2efd3e61084f70000c
May 25 22:22:57 <chackal_sjc> /usr/bin/x-session-manager: line 24: stat: command not found
May 25 22:22:57 <chackal_sjc> Size 1024x768 not found in available modes
May 25 22:22:58 <chackal_sjc> xinit: connection to X server lost
May 25 22:23:00 <chackal_sjc> like this
May 25 22:29:45 <mranostay> pastebin!
May 25 22:30:32 <chackal_sjc> sorry
May 25 22:31:38 <chackal_sjc> http://paste.kde.org/487220/
May 25 23:01:01 <pidge> yocto-autobuilder going down for upgrade. It will be back and functional sometime this weekend.
May 25 23:31:11 <chackal_sjc> can someone help me with the xserver?
May 25 23:43:39 <khem> what arr you doing
May 25 23:57:05 <chackal_sjc> as I told before
May 25 23:57:20 <chackal_sjc> I have an image like this
May 25 23:57:28 <chackal_sjc> IMAGE_INSTALL = "task-core-x11-mini qt4-x11-commercial"
May 25 23:57:28 <chackal_sjc> inherit core-image
May 25 23:57:43 <chackal_sjc> but xserver dont start on boot
May 25 23:57:54 <chackal_sjc> I get this error here: http://paste.kde.org/487220/
May 26 00:09:50 <khem> chackal_sjc: I think there are some conflicts
May 26 00:09:58 <khem> can you boot core-image-sato
May 26 00:10:44 <chackal_sjc> yes
May 26 00:10:49 <chackal_sjc> well
May 26 00:10:55 <chackal_sjc> i did in qemu
May 26 00:10:59 <chackal_sjc> not im my target machine
May 26 00:13:17 <chackal_sjc> khem: thats what I actually want to do
May 26 00:13:41 <chackal_sjc> I want to start some Qt app just after the psplash, like sato does
May 26 00:13:53 <chackal_sjc> but I don't have any guess how sato does
May 26 00:16:26 <khem> ok then use the qt imaes
May 26 00:17:42 <khem> chackal_sjc: eg. try bitbake qt4e-demo-image
May 26 00:18:12 <chackal_sjc> ok
May 26 01:11:50 <chackal_sjc> khem: i found it
May 26 01:11:54 <chackal_sjc> qt-demo-init does that
May 26 01:12:04 <chackal_sjc> qt-demo-init recipe
**** ENDING LOGGING AT Sat May 26 02:59:57 2012

**** BEGIN LOGGING AT Sat May 26 02:59:58 2012
May 26 07:44:53 <moolinex> morning all
**** ENDING LOGGING AT Sun May 27 02:59:59 2012

**** BEGIN LOGGING AT Sun May 27 02:59:59 2012
May 27 19:50:47 <m4t> the kernel.org mirror link is broken... should be http://mirrors.kernel.org/yocto/yocto/yocto-1.2/poky-denzil-7.0.tar.bz2
**** ENDING LOGGING AT Mon May 28 02:59:58 2012

**** BEGIN LOGGING AT Mon May 28 02:59:58 2012
May 28 07:10:18 <moolinex> morning all
May 28 07:10:30 <moolinex> morning Laurentiu1
May 28 07:16:40 <mckoan> good morning
May 28 07:17:57 <Laurentiu1> salut
**** ENDING LOGGING AT Tue May 29 02:59:58 2012

**** BEGIN LOGGING AT Tue May 29 02:59:58 2012
May 29 07:14:02 <mckoan> good morning
May 29 09:47:44 <ag> RP__: Hello. I'd like to add hwclock to MACHINE FEATURES. We don't use this now and init scripts for setting the hardware clock are added on board without hwclock as well. So i can submit a patch on busybox to check for hwclock in MACHINE FEATURES before installing the hwclock scripts and so on.
May 29 09:48:55 <ag> But this change will lead to another problem. We will need to add hwclock to all MACHINES with hwclock.
May 29 09:49:52 <ag> But in my opinion this is a good change.
May 29 10:06:07 <RP__> ag: Does that script really cost much at boot time or space in the image?
May 29 10:06:34 <ag> RP__: Nope. But we will avoid errors / warning on boards without hwclock.
May 29 10:06:55 <RP__> ag: Can't we just improve the detection in the script?
May 29 10:07:12 <RP__> ag: I understand the desire but I worry this is making things a little too machine focused :/
May 29 10:09:45 <ag> RP__: This is why i'd like to see this in the MACHINE_FEATURES. :)
May 29 10:11:12 <RP__> ag: I'm in two minds about it :/
May 29 10:11:27 <ag> Modifying the script is a workaround. But as boards have wifi and other stuff it should have hwclock and so on.
May 29 10:13:15 <RP__> ag: How are we going to retrofit this to every machine out there?
May 29 10:13:16 <ag> RP__: I will have lunch. Hope after you will be "hwclock one minded" :)
May 29 10:15:06 <ag> Well... what about adding : no-hwclock. :)
May 29 10:16:46 <ag> Still, after this change the whole hwclock thing in MACHINE_FEATURES will make a lot of sense for future boards. But anyway, it was just a thought.
May 29 10:28:41 <RP__> ag_away: We could consider something like the distro features back filling I guess
May 29 11:22:44 <ant_work> RP__: ping
May 29 11:27:48 <RP__> ant_work: pong
May 29 11:37:40 <ant_work> RP__: hi, I was wondering about the 'preferred' method for loading kernel modules nowadays.
May 29 11:38:49 <ant_work> some can be auto-loaded. some by udev, others manually.. is there some kind of policy?
May 29 11:38:54 <ant_work> RP__: e.g. about sound, some modules are device-specific and could be compiled in kernel while the oss/alsa stuff could remain modular
May 29 11:38:54 <ant_work> the idea here is to share an .inc between ram-challenged devices
May 29 11:38:55 <ant_work> like the ones in meta-handheld
May 29 11:38:55 <ant_work> RP__: or doing that on the kernel side, using the Yocto fragments like  "include cfg/sound.scc"
May 29 11:38:55 <ant_work> but here we don't have modules but a monolithic kernel
May 29 11:38:55 <ant_work> opinions?
May 29 12:16:43 <RP__> ant_work: generally the device specific pieces should either get compiled in or autoloaded
May 29 12:16:57 <RP__> ant_work: things like usb drivers and so on should be modules
May 29 12:17:31 <RP__> ant_work: certainly that was the way the zaurus kernel was configured and yes, I think using sensible config fragments would be a good way of doing it
May 29 13:35:10 <ydeb> Hi, I am trying to build a linux bsp using yocto, based on the qt4e-demo-image for an emenlow machine. I am trying to figure out how to enable the touchscreen.
May 29 13:35:33 <ydeb> currently, the touchscreen is recognized as /dev/input/mouse1
May 29 13:36:38 <ydeb> seems like some packages are missing (tslib, ts_calibrate, ...). I don't know how to add them. Can anyone help?
May 29 13:37:52 <ydeb> in the end, I want to run my own QT application on it. Thought I'd start with the qt4e-demo-image.
May 29 13:46:50 <RP__> ydeb: Adding touchscreen to MACHINE_FEATURES is probably a good place to start
May 29 13:51:52 <ydeb> RP__: Thanks. I had added it to ia32-base.inc in my home/meta-intel/conf/machine/include folder. Would that be the proper location?
May 29 13:53:34 <ydeb> it did not have any effect, btw
May 29 14:11:10 <bluelightning> ydeb: you shouldn't really be modifying that file
May 29 14:11:28 <bluelightning> ydeb: you should add it to MACHINE_FEATURES within the .conf file for the machine
May 29 14:46:34 <ydeb> bluelightning: I added IMAGE_FEATURES += "touchscreen" to the emenlow.conf file now. Bitbaking...
May 29 14:47:50 <ydeb> bluelightning: I meant MACHINE_FEATURES...
May 29 14:51:26 <bluelightning> ydeb: which yocto project version are you using?
May 29 14:53:59 <ydeb> I cloned the latest one from the git repository
May 29 14:55:35 <ydeb> bluelightning: I noticed that the tslib.so library is already part of the image, however ts_calibrate is not, so I cannot generate a calibration file
May 29 15:01:40 <bluelightning> ydeb: there is a tslib-calibrate package, if you also install that into your image you will have it
May 29 15:03:27 <ydeb> bluelightning: I was browsing through the packages in hob, but I could not find such a package. Where should I add it? I'm new to all this.
May 29 15:09:37 <bluelightning> ydeb: if you are at the list of packages in Hob there should be one under tslib called tslib-calibrate
May 29 15:39:37 <seebs> So, idle poking about reveals to me that some packages have an explicit --enable-static, and some an explicit --disable-static.  From this I infer that there is no such thing as a general-purpose "make the whole build static" option.
May 29 15:40:25 <kergoth`> those arguments, afaik, only affect libtool, specificaloy the emission of libraries, not binaries
May 29 15:40:29 <jwessel> More specifically, can you perhaps do it on a per image basis?
May 29 15:40:33 <kergoth`> they come from libtool's macros
May 29 15:42:36 <ant_work> jwessel: you could think to add CFLAGS+=-static neverthless some programs have to be patched to build statically
May 29 15:43:28 <jwessel> ant_work: That is probably to be expected.  Early I had asked seebs if there was a way to build two very minimal images, one dynamically linked, and one statically linked.
May 29 15:44:24 <jwessel> I was ultimately looking at some kind of an image that is basically just a kernel + a statically linked app.
May 29 15:44:33 <ant_work> no idea about uclibc but with I'm using klibc-static compiled binaries
May 29 15:44:43 <ant_work> in the initramfs
May 29 15:45:28 <ant_work> (why did I write 'with' above there... ?)
May 29 15:45:43 <jwessel> ant_work: :-)
May 29 15:46:22 <jwessel> ant_work: Sure I can see there is a specific klibc case, we were just wondering about the generic possibility of building fully statically binaries in an image.
May 29 15:46:36 <jwessel> Doesn't sound like it is currently something that is implemented.
May 29 15:46:51 <ant_work> how many, I'd say if mor than 4-5 you do better deploy a shared lib
May 29 15:47:08 <jwessel> Sure, but this is for a specific use case of 1-2
May 29 15:47:16 <jwessel> Most often just one.
May 29 15:47:17 <ant_work> then klibc is a sure win
May 29 15:47:50 <ant_work> well, if you have to be small-sized, otherwise let's bloat it
May 29 15:47:54 <jwessel> But of course having the full functionality of eglibc.  Klibc is not quite enough.
May 29 15:48:13 <halstead> Preview new classifications at https://bugzilla.yoctodev.org/
May 29 15:48:18 <ant_work> what kind of binary, out of curiosity?
May 29 15:48:36 <jwessel> ant_work: You mean elf binary?
May 29 15:48:46 <jwessel> Or what the application do?
May 29 15:53:39 <chackal_sjc> guys, im getting an strange error when creating rootfs
May 29 15:53:40 <chackal_sjc> http://paste.kde.org/489392/
May 29 15:53:59 <chackal_sjc> my image adds this module-init-tools
May 29 15:54:10 <chackal_sjc> and I tried bitbake module-init-tools and it's compiled
May 29 15:57:57 <ant_work> jwessel: yes, which kind of app? what is it doing?
May 29 15:58:39 <ant_work> chackal_sjc: afaik you should use kmod, module-init-tools is deprecated
May 29 15:59:45 <chackal_sjc> ant_work: just add kmod?
May 29 15:59:53 <chackal_sjc> instead of module-init-tools?
May 29 16:00:53 <ant_work> probably, no idea about your g2-image-1.0 though
May 29 16:01:16 <jwessel> ant_work: These types of apps are for small single purpose devices, sometimes with a graphics display full of button with a digital graph (or some cases just buttons and leds).  This is for small parts with very little ram and not a lot of CPU power.   But also these things some times have networking sockets and open ports etc...
May 29 16:01:57 <jwessel> ant_work: Think of manufacturing and process control devices.  Stuff that is usually fairly simple, but the latest generation wants the world to be networked.
May 29 16:02:25 <jwessel> Arguably an arduino is probably a better fit for some of these types of apps. :-)
May 29 16:03:02 <ant_work> I see, last hype would be qte nowaday ;)
May 29 16:05:26 <ant_work> if size is a matter, try to compile it against klibc 2 anyway
May 29 16:05:46 <ant_work> sockets have been reworked
May 29 16:09:43 <kergoth`> https://gist.github.com/2788410#file_local.conf.snippet
May 29 17:37:15 <chackal_sjc> guys
May 29 17:37:21 <chackal_sjc> my image is here: http://paste.kde.org/489446/
May 29 17:37:35 <chackal_sjc> but im getting this error: http://paste.kde.org/489392/
May 29 17:53:06 <chackal_sjc> guys
May 29 17:53:13 <chackal_sjc> im getting a
May 29 17:53:13 <chackal_sjc> | error: Failed dependencies:
May 29 17:53:13 <chackal_sjc> | 	/usr/bin/env is needed by xrandr-1.3.5-r8.1.armv7a
May 29 17:53:15 <chackal_sjc> ?!
May 29 19:30:47 <fray> how do I setup the NFS root for runqemu? (from an image tarball)?
May 29 19:30:58 <fray> I thought there was an automated script that would extract the tarball, but I can't find it
May 29 19:33:46 <zenlinux> fray, there is - runqemu-extract-sdk
May 29 19:34:08 <fray> that does more then the sysroot though right?
May 29 19:34:36 <zenlinux> I thought it used to be called -extract-tarball, it's not really sdk specific
May 29 19:34:57 <fray> I'll try it.. but ya, it's poorly named, and even more poorly documented..
May 29 19:35:53 <fray> well, what the hell it didn't create a tarball?!
May 29 19:36:28 <zenlinux> fray, what image is this?
May 29 19:36:30 <fray> took me two+ hours to generate a self-hosted-image.. I'd rather not do that again..
May 29 19:37:06 <zenlinux> ah, the self-hosted-image stuff is fairly new, sounds like something was missed
May 29 19:37:15 <fray> genext3 is horribly slow.. NFS booting is way faster....
May 29 19:37:30 <fray> I guess I'll just have to scp to the image and install the couple of things that way.. :(
May 29 20:52:57 <chrisw957> I've been banging my head against the wall trying to do a simple FILESEXTRAPATHS_prepend to netbase, but it seems to insist on ignoring my files and using the ones supplied by the recipe.
May 29 20:53:25 <chrisw957> Is there a way to debug this?
May 29 20:54:14 <chrisw957> In my layer, I created netbase_4.47.bbappend file with FILESEXTRAPATHS_prepend := "${THISDIR}/files:" and PRINC="2"
May 29 20:54:46 <chrisw957> Then a files directory with my hosts, init, and interfaces file.  Which are getting ignored.
May 29 21:13:59 <chackal_sjc> how to include /usr/bin/env to the distro image?
May 29 21:24:13 <chackal_sjc> guys
May 29 21:24:19 <chackal_sjc> im getting this error with module-init-tools
May 29 21:24:27 <chackal_sjc> does someone can give me a clue
May 29 21:24:28 <chackal_sjc> ?
May 29 21:28:53 <kergoth`> why are you using module-init-tools?
May 29 21:32:00 <chackal_sjc> sorry
May 29 21:32:08 <chackal_sjc> kergoth`: its related to this: https://bugzilla.yoctoproject.org/show_bug.cgi?id=2289
May 29 21:32:23 <chackal_sjc> | error: Failed dependencies:
May 29 21:32:23 <chackal_sjc> | 	/usr/bin/env is needed by xrandr-1.3.5-r8.1.armv7a
May 29 21:32:51 <chackal_sjc> kergoth`: it's related because module-init-tools(which is kmod right now) has this dependency issue
May 29 22:08:26 <chackal_sjc> guys
May 29 22:08:49 <chackal_sjc> im getting a kernel panic for no init found with the image that I built inheriting core-image
May 29 22:08:57 <chackal_sjc> is there any package missing?
May 29 23:30:18 <chackal_sjc> hello guys
May 29 23:30:27 <chackal_sjc> im having some troubles with init
May 29 23:30:39 <chackal_sjc> there is no /sbin/init in the image
May 30 00:09:19 <chackal_sjc> how do i say that I don't need to provide a kernel because I've already have it ?
May 30 00:50:40 <khem> chackal_sjc: how did you build your image
May 30 01:01:02 <chackal_sjc> khem: I already make it work ;)
May 30 01:01:10 <chackal_sjc> I'm just having issue with xserver
May 30 01:01:20 <chackal_sjc> cant start it
May 30 01:01:44 <chackal_sjc> im using IMAGE_FEATURES += "x11-mini" but wont start xserver
May 30 01:01:57 <chackal_sjc> so im trying with IMAGE_FEATURES += "x11-base"
May 30 01:09:12 <khem> hmm
May 30 01:15:51 <chackal_sjc> khem: do you know why is that?
May 30 01:17:39 <khem> whats your image target
May 30 01:17:57 <khem> paste the output of bitbake -g <your image> somwhere
May 30 02:49:17 <seebs> Is there a good idiom for "find me a file that I believe to be in the scripts directory"?
**** ENDING LOGGING AT Wed May 30 02:59:58 2012

**** BEGIN LOGGING AT Wed May 30 02:59:58 2012
May 30 03:01:14 <jwessel> seebs: You mean like changing out the base name of your process?
May 30 03:01:52 <seebs> Not sure.  What I want is a variable that will, roughly speaking, expand to something like /path/to/poky/scripts.
May 30 03:02:13 * jrw returns for just a min...
May 30 03:02:17 <seebs> I suppose if the scripts directory is in $PATH I could just invoke a script and have it find itself.
May 30 03:02:31 <jrw> What is your goal though?
May 30 03:03:05 <jrw> bash does this trick where it finds out where it is executing from for example.
May 30 03:03:12 <seebs> I want to, if wrappers don't exist, compile them.  To do this, I'd want to find the source file, and looking around I noticed other stuff living in scripts/*.c.
May 30 03:03:17 <jrw> and then you can look relative to that if it is in a known location.
May 30 03:03:37 <jrw> seebs: There is a much sneaker way to do things...
May 30 03:03:39 <seebs> If I were in a layer, I could probably refer to ${LAYERDIR}, but that doesn't seem to work for stuff that's just in meta.
May 30 03:03:45 <jrw> Have you taking a look at jargs?
May 30 03:03:50 <seebs> No...
May 30 03:04:24 <jrw> wrlinux-5/layers/wrlcompat/scripts/jargs
May 30 03:04:45 <jrw> jargs.sh: jargs.sh.in jargs.c jargs.sh.footer
May 30 03:04:45 <jrw>         cat jargs.sh.in > jargs.sh
May 30 03:04:45 <jrw>         cat jargs.c >> jargs.sh
May 30 03:04:45 <jrw>         cat jargs.sh.footer >> jargs.sh
May 30 03:04:45 <jrw>         chmod 755 jargs.sh
May 30 03:04:50 <seebs> Sneaky.
May 30 03:05:19 <jrw> This is a really nasty way to build a C program into a shell script, but also have a complete infrastructure for maintaining and testing the files.
May 30 03:05:49 <jrw> This the thing that I told you about where I could have also gone the extra mile to have it replace itself upon compilation.
May 30 03:05:57 <jrw> But I didn't see the need.
May 30 03:05:59 <seebs> That does have some appeal.  Of course.  I also still don't know how to invoke a program in scripts/ by path.  Unless the intent is that you don't specify the path, you just let $PATH find it.
May 30 03:06:57 <jrw> Keep in mind with more shell foo I could have even skipped the intermediate file and fed the shell script to the compiler too...  But I am still not sure exactly what you need
May 30 03:07:30 <jrw> Are you saying set PATH=/place_of_wrapper
May 30 03:07:38 <jrw> wrapper-gcc
May 30 03:07:44 <jrw> And then something else?
May 30 03:08:34 <jrw> Because I figure in wrapper-gcc you can do the lookup of its current location from /proc/pid/exe, like bash and gcc front end..
May 30 03:08:40 <jrw> They just get the dirname from there.
May 30 03:09:01 <jrw> And if you need your config file it is assumed to be in the same location.
May 30 03:09:55 <jrw> And from there you have everything you need for real further invocation of compiler either specified by path OR allow it to exec search, even if you have to path search your self, but generally exec search is enough.
May 30 03:10:22 * jrw has written some fairly nasty wrappers over the years... jargs being one of the more simple, but interesting ones.
May 30 03:12:23 <seebs> What I'm looking at is, in my bbclass, I want to do something to the effect of cc -DFOO=BAR /path/to/toolchain-wrapper.c
May 30 03:12:27 <seebs> but I don't know how to find /path/to.
May 30 03:13:11 <seebs> When I was doing it in the toolchain layer, I did d.getVar("LAYERDIR", True), and that gave me the directory containing scripts/, conf/, and so on.  But if I do it in the main poky tree, LAYERDIR seems to be None.
May 30 03:13:27 <seebs> Or possibly just because it's being hit at a different time; haven't yet looked that closely.
May 30 03:14:07 <seebs> The only reference I see to the poky/scripts directory is that it's in $PATH.  I'd sort of casually assumed there would be a variable pointing to either the scripts directory or the poky directory as such.
May 30 03:14:16 <seebs> Oh, wait.
May 30 03:14:18 <seebs> $COREBASE
May 30 03:14:47 <seebs> Is it kosher to refer to $COREBASE/scripts when referring to a thing that should be in the scripts/ directory?
May 30 03:37:39 <kergoth`> LAYERDIR only exists when bblayers.conf is being parsed
May 30 03:37:48 <kergoth`> and it changes depending on which layer is being parsed at the moment of expansion
May 30 03:38:02 <kergoth`> s/bblayers/layer/
May 30 07:27:00 <mckoan> good morning
May 30 08:38:35 <bluelightning> morning all
May 30 13:04:50 <d4ny> Hi All, is there a good way to add an alternate SRC_URI, if one source is down ?, i.e. if the git:// fetch of a git repo fails, try again with a http fetch
May 30 13:05:46 <d4ny> i.e. The meta-fsl-ppc kernel git:// seems to be down, but http cloning seems to work for the moment ..
May 30 13:05:59 <bluelightning> d4ny: that would be the task of MIRRORS
May 30 13:06:45 <bluelightning> you could even do it generically for any git:// to try http:// afterwards... not sure if that's a great idea though
May 30 13:07:08 <bluelightning> for now a specific one for the site would fix the issue
May 30 13:07:36 <d4ny> Ah, thanks bluelightning
May 30 13:19:17 <d4ny> Hmm, cant get that one to work
May 30 13:19:18 <d4ny> MIRRORS += "git://git.freescale.com/ppc/sdk/linux.git git://git.freescale.com/git/cgit.cgi/ppc/sdk/linux.git;protocol=http \n"
May 30 13:20:08 <d4ny> MIRRORS are mainpulated in distro.conf
May 30 13:26:39 <bluelightning> d4ny: try MIRRORS_append
May 30 13:26:47 <d4ny> will do
May 30 13:26:58 <bluelightning> although you will need to have a space at the start of your string to be appended
May 30 13:27:05 <bluelightning> since _append doesn't add one for you
May 30 13:27:46 <d4ny> did it, and no change
May 30 13:28:16 <bluelightning> d4ny: if you look in log.do_fetch you'll see which URIs it actually tried, making use of MIRRORS
May 30 13:30:59 <d4ny> Seems like it was not added, http://pastebin.com/mWDNgwaX
May 30 13:31:14 <d4ny> bt.w. why would append vs. += be different ?
May 30 13:32:46 <bluelightning> d4ny: they get applied at different times
May 30 13:33:16 <bluelightning> d4ny: if you do += it adds the value immediately, then later you get an = and your earlier added value is wiped out
May 30 13:33:42 <bluelightning> d4ny: on the other hand, _append stores the appended value away and then at the end of parsing the _appends are processed
May 30 13:37:09 <d4ny> Thanks for the explanation.
May 30 13:37:13 <bluelightning> you can always check whether or not your value was applied by doing bitbake -e | grep ^MIRRORS
May 30 13:38:28 <d4ny> its there
May 30 13:44:47 <d4ny> Ah, DEBUG: For url git://git.freescale.com/ppc/sdk/linux.git returning http://downloads.yoctoproject.org/mirror/sources/git2_git.freescale.com.ppc.sdk.linux.git.tar.gz
May 30 13:45:07 <d4ny> I guess it would work with a tarball, but perhaps not a git repo...
May 30 13:52:03 <bluelightning> d4ny: maybe use _prepend and move your leading space to the end
May 30 13:52:17 <d4ny> will try it
May 30 13:52:19 <bluelightning> d4ny: that way your expression will be tried first
May 30 13:55:12 <d4ny> bluelightning: Not working, it mangles the name assuming its a bitbake generated mirror. http://pastebin.com/5sTQ0eMC
May 30 13:55:28 <d4ny> Its finds it, but there is no tarball with that name at that location ..
May 30 14:03:02 <d4ny> Perhaps we can open for a ALT_SRC_URI to support this ?
May 30 14:14:43 <bluelightning> d4ny: hmm, that's perplexing
May 30 14:15:00 <bluelightning> d4ny: I would suggest posting to the list at this point, see if anyone has any suggestions there
May 30 19:17:48 <kergoth> anyone hitting 'attr' do_install failures?
May 30 19:23:27 <khem> kergoth: what failure
May 30 19:23:30 <khem> do u see
May 30 19:23:58 <kergoth> claims libattr.lai doesn't exist. checking more closely now
May 30 19:25:33 <khem> hmmm
May 30 19:25:45 <khem> something missing wrt libtool ?
May 30 19:26:28 <msm> is there a way to get http://packages.yoctoproject.org/ to show versions for an old release?
May 30 21:42:54 <chackal_sjc> guys
May 30 21:43:14 <chackal_sjc> task-x11-mini does not start X server
May 30 21:43:19 <chackal_sjc> why?
May 30 23:11:12 <khem> chackal_sjc: you should start with proper image ?
May 30 23:11:54 <chackal_sjc> IMAGE_FEATURES += "x11-mini"
May 30 23:11:55 <chackal_sjc> CORE_IMAGE_EXTRA_INSTALL = "\
May 30 23:11:55 <chackal_sjc>   qt4-x11-commercial \
May 30 23:11:55 <chackal_sjc>   module-init-tools \
May 30 23:11:55 <chackal_sjc>   psplash \
May 30 23:11:55 <chackal_sjc>   qt-demo-init \
May 30 23:11:55 <chackal_sjc> "
May 30 23:11:55 <chackal_sjc> inherit core-image
May 30 23:12:05 <chackal_sjc> khem: just that
May 30 23:15:58 <khem> why x11-mini
May 30 23:17:58 <chackal_sjc> khem: because I just want minimal x11 server to run Qt apps
May 30 23:18:10 <chackal_sjc> and x11-base install matchbox stuff that I dont want to
May 30 23:20:16 <khem> chackal_sjc: Look at qt4e-demo-image.bb
May 30 23:20:19 <khem> and customize it
May 31 00:14:27 <chackal_sjc> another thing
May 31 00:14:43 <chackal_sjc> i did a patch for some recipe(using git repo)
May 31 00:14:51 <chackal_sjc> so i did git diff > patch
May 31 00:15:04 <chackal_sjc> but bitbake cant apply the patch..
May 31 00:15:12 <chackal_sjc> cant find the file to apply
May 31 00:15:26 <kergoth> ;striplevel=0
May 31 00:15:32 <kergoth> by default it passes -p 1 to patch
May 31 00:15:45 <chackal_sjc> oh, ok
May 31 00:15:46 <chackal_sjc> tx
May 31 00:16:52 <kergoth> damn, i'm betting i'm going to have serious sstate reuse problems until i find and add more things to BB_SIGNATURE_EXCLUDE_FLAGS
May 31 00:16:55 <kergoth> :|
May 31 00:17:04 <chackal_sjc> SRC_URI_prepend = " file://cercacor_colors.patch;striplevel=0 "
May 31 00:17:10 <chackal_sjc> like this? it still not working
May 31 00:17:52 <kergoth> prepend? that doesn't make any sense. you'd have the patch before the actual git or tarball url
May 31 00:18:04 <kergoth> won't break anythign, just pointless
May 31 00:18:12 <kergoth> regardless, see patch.bbclass for details
May 31 00:18:42 <chackal_sjc> ok
May 31 00:18:49 <chackal_sjc> so how should I do it?
May 31 00:18:57 <chackal_sjc> SRC_URI += "" ?
May 31 00:19:08 <chackal_sjc> (its in a .bbappend)
May 31 00:20:54 <kergoth> generally, yes. avoid _prepend or _append unless you're doing a conditional append/prepend or have a very good reason for it. use +=/=+/.=/=. instead whenever possible
May 31 00:21:36 <chackal_sjc> ok
May 31 00:22:32 <chackal_sjc> SRC_URI += "file://cercacor_colors.patch;striplevel=0"
May 31 00:22:34 <chackal_sjc> still not working
May 31 00:56:01 <chackal_sjc> whats the PRINC var for?
May 31 01:14:07 <chackal_sjc> kergoth: i find out why the patch was not working.. the recipe was fetching a commit from git that hasn't the source that i was trying to apply the patch
May 31 01:19:42 <kergoth> ahh
May 31 01:19:43 <kergoth> that'd do it
May 31 01:19:52 <kergoth> PRINC is a integer based way to increment PR
May 31 01:19:57 <kergoth> rather than appending to it stringwise
May 31 02:19:54 <mebrown> anybody aware that the dosfstools mkdosfs in yocto 1.1 has a bug where it doesnt work for >2GB?
May 31 02:20:15 <mebrown> cflags get passed in which overwrite the makefile's -D_FILE_OFFSET_BITS=64
May 31 02:20:27 <mebrown> fix is to pass that in via CFLAGS_append ...
**** ENDING LOGGING AT Thu May 31 02:59:58 2012

**** BEGIN LOGGING AT Thu May 31 02:59:58 2012
May 31 03:05:16 <seebs> mebrown:  good catch.  Check whether it's fixed, if not I'd say just send in a patch or something?
May 31 03:05:49 <mebrown> I'm in the middle of a frenzy right now and can't send in anything atm
May 31 03:05:55 <seebs> k
May 31 03:06:21 <seebs> well, I probably won't remember, but if I happen to when I'm not doing something else I might send it in.  Good catch, anyway.
May 31 03:06:57 <mebrown> I have (finally) fully converted the Dell IDRAC build over to yocto. Decision point tomorrow is if we are ready to switch the entire dev org over to it or not
May 31 03:07:09 <mebrown> if not, I've wasted 5 months of my life.
May 31 03:07:21 <mebrown> so I'm furiously fixing bugs tonight
May 31 03:07:29 <mebrown> that ended up being one of them
May 31 03:07:56 <mebrown> last time I sent a patch, I ended up having to send it through about three different mailing lists before I got the right one. don't have time for that now.
May 31 03:09:32 <seebs> Okay.
May 31 03:10:05 <seebs> I'll file it for you so it doesn't get lost, so at least that'll be SOME productive output.  :P
May 31 03:10:18 <kergoth> not surprising, that's common enough. frantic scramble, then after the deadline push the backlog up
May 31 03:10:20 <kergoth> heh
May 31 03:10:33 <seebs> I like to be all optimistic and figure that worst case I got a ton of experience and learned stuff.  And possibly got paid for it.
May 31 03:10:51 <kergoth> heh, indeed
May 31 03:10:52 * kergoth is still trying to get caught up on pushing the bits that went into mentor's last release
May 31 03:11:09 <mebrown> Well, in this case, I think a large part of my end of year bonus is riding on this
May 31 03:11:14 <seebs> MHO, switching to Yocto is a good call in that, even if there are problems, having a lot of us collaborating means we all get more mileage out of our time.
May 31 03:11:29 <seebs> Eww.  I hate it when bonuses depend on stuff that is not actually under my control.
May 31 03:12:01 <mebrown> Anybody have experience with kernel and yocto stuff? I have literally everything moved over to yocto *except* our kernel build.
May 31 03:12:03 <mebrown> but...
May 31 03:12:03 <seebs> "So, there's some random guy in a suit, and if he's having a good day and had enough coffee to understand what people are saying to him, or just happens to be agreeable, you get paid!"
May 31 03:12:20 <seebs> I don't.  I know we have people who have been doing kernel stuff with yocto, but I'm not one of them.
May 31 03:12:22 <mebrown> our kernel build is currently a very hacked together non-git thing
May 31 03:12:38 <mebrown> and I'd like to know the easiest way to transplant it
May 31 03:12:42 <seebs> Ugh.  We had one of those once.
May 31 03:12:57 <mebrown> same thing with our uboot copy
May 31 03:12:59 <kergoth> just use a SRC_URI with a tarball + patches or so, i'd say. you don't have to use the linux-yocto stuff if you don't want to
May 31 03:13:03 <seebs> Well.  I should be fair.  It was about as pretty as a hacked-together non-git thinig could reasonably be.
May 31 03:13:07 <kergoth> there's yocto docs on bsp creation, etc that should cover it
May 31 03:13:17 <mebrown> I've read all those
May 31 03:13:26 <mebrown> but the kernel recipes are daunting, to say the least
May 31 03:15:59 <kergoth> mebrown: clone poky-extras, look at meta-kernel-dev, specifically recipes-kernel/linux/, more specifically linux-korg.bb
May 31 03:16:03 <kergoth> copy and modify
May 31 03:16:15 <mebrown> ok. thanks, I'll look
May 31 03:16:57 <kergoth> it's mentioned in http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html, but i don't know if there's all that much detail about it
May 31 03:17:25 <mebrown> I've read all the docs, multiple times, over the past week
May 31 03:17:36 <mebrown> trying to figure out how to get kernel+uboot in.
May 31 03:19:29 <seebs> Confirmed, BTW, that the bug's still present now, and I filed it as bug #2525.  Thanks!
May 31 03:19:38 <mebrown> you are welcom.
May 31 03:19:39 <mebrown> e
May 31 06:23:01 <mebrown> You can do VAR_virtclass-native to set a variable only when it's built native. Is there a corresponding way to set a variable only if it's a cross compile?
May 31 06:24:41 <seebs> Hmm.
May 31 06:24:47 <seebs> Well, if I were in a hurry.
May 31 06:24:58 <seebs> I'd set VAR, and then set an empty override for VAR_virtclass-native.
May 31 06:25:27 <seebs> And I'd probably get laughed at if I tried to submit that as a patch without more consultation, but I bet it'd work.
May 31 06:25:44 <mebrown> Actually, I want to set an append for cross.
May 31 06:25:56 <seebs> Hmm.  That might be harder.
May 31 06:26:00 <mebrown> something like VAR_append_virtclass-cross
May 31 06:26:07 <seebs> Oh, wait.
May 31 06:26:15 <seebs> VAR_append = "${I_FEEL_DIRTY}"
May 31 06:26:21 <seebs> I_FEEL_DIRTY = "cross value"
May 31 06:26:29 <seebs> I_FEEL_DIRTY_virtclass-native...
May 31 06:26:41 <mebrown> ah. so a hack. thanks.
May 31 06:27:07 <seebs> I would consider that an ugly hack.  But anyone who's up at what is around here about 1:30 trying to solve a problem probably prefers a hack to a silent channel.
May 31 06:27:19 <mebrown> yes.
May 31 06:27:29 <mebrown> so you are CST, too, then?
May 31 06:27:32 <seebs> Yup.
May 31 06:27:58 <seebs> BTW, if you are having trouble figuring out how things get set, I believe my variable-assignment-tracking patches should still apply on the current tree or anything reasonably recent.
May 31 06:28:06 <seebs> I mention this because I know that I have found them awfully useful.
May 31 06:28:20 <mebrown> ok, I'll take a look
May 31 06:29:04 <seebs> And since I'm CST and have a meeting in the morning, I think I'll wander off.
May 31 06:29:12 <seebs> Good hunting!
May 31 06:29:23 <mebrown> thanks
May 31 07:03:05 <mebrown> anybody have experience hooking yocto into distcc?
May 31 07:18:34 <Zagor> how can I get some more details about a failed do_populate_sysroot_setscene? even with -ddd -v it just says "failed with exit code '1'"
May 31 07:26:23 <moolinex> Zagor: have you checked the logs?
May 31 07:26:45 <Zagor> that's my question: what logs?
May 31 07:26:49 <moolinex> :)
May 31 07:27:08 <moolinex> it should be log mentioned there, somewhere
May 31 07:27:17 <Zagor> it's not
May 31 07:27:29 <Zagor> that's why I'm puzzled, and asking
May 31 07:27:30 <moolinex> check the cooker logs first in build/tmp/
May 31 07:28:22 <Zagor> those show the same as the screen output: failed with exit code '1' - real task will be run instead
May 31 07:28:37 <moolinex> Zagor: which package fails?
May 31 07:29:17 <Zagor> apparently all my cached ones. starting with pseudo-native-1.3-r10
May 31 07:33:06 <moolinex> check for build/tmp/work/x86*-linux/pseudo-native-1.3-r10/temp/log.do_populate_sysroot_setscene
May 31 07:33:40 <Zagor> ah, there it is. thanks!
May 31 07:34:12 <Zagor> a note "see logfile X for details" like we get for build errors would be nice
May 31 07:35:09 <moolinex> it should be there somewhere, i guess
May 31 07:35:12 <mckoan> good morning
May 31 07:35:31 <moolinex> morning mckoan
May 31 09:40:20 <bluelightning> morning all
May 31 09:45:46 <d4ny> morning
May 31 09:46:37 <d4ny> Is there a good way to find out the layer name ?, I want to add
May 31 09:46:37 <d4ny> PR .= "+${LAYER_NAME}.0" to my bbappends for clarity.
May 31 10:03:45 <moolinex> d4ny: you may use the path in ${FILE} to figure the meta layer which contains your recipe
May 31 10:04:18 <d4ny> I guess ${LAYERDIR} is out of scope for normal .bbappend files ?
May 31 10:05:43 <d4ny> moolinex: That would not be entirely easy, every layer would have to heed to a standard path naming. How many direcories down would that reicpe be in ?
May 31 10:13:51 <RP__> d4ny: LAYERDIR is not in the scope of normal files, no
May 31 13:24:42 <RP__> zeddii: around?
May 31 13:37:44 <zeddii> RP__, here. what's up?
May 31 13:49:05 <zeddii> anyone else seeing:
May 31 13:49:07 <zeddii> |  * satisfy_dependencies_for: Cannot satisfy the following dependencies for task-core-boot:
May 31 13:49:07 <zeddii> |  *    libusb-compat (>= 0.1.3) *
May 31 13:49:07 <zeddii> |  * opkg_install_cmd: Cannot install package task-core-boot.
May 31 13:50:18 <RP__> zeddii: Did you get yesterday's revert?
May 31 13:50:31 <RP__> zeddii: potentially that could be related to that, hard to say
May 31 13:50:41 <zeddii> I just pulled and was up to date on master.
May 31 13:50:46 <RP__> zeddii: I cc'd you on the patch in the end
May 31 13:51:03 <RP__> zeddii: hmm, I've not seen that then
May 31 13:52:27 <zeddii> and I definitely do a have a build of libusb-compat 0.1.3. I'll dig some more. I just wanted to boot my last 3.4 kernel so I could send changes .. I should have expected something :P
May 31 13:52:52 * zeddii sees RP__'s ncurses foo.
May 31 13:53:31 <RP__> zeddii: The revert yesterday was to fix various package renaming issues that crept in as the result of a broken commit
May 31 13:53:54 <RP__> zeddii: I'm not entirely happy with the ncurses fix but that was the best I could do
May 31 13:54:16 <zeddii> RP__, I assume it was this revert? Revert "meta: replace os.popen with subprocess.Popen"
May 31 13:54:26 <RP__> zeddii yes
May 31 13:54:46 <zeddii> ok. I do have it. I bet I'm just in some indeterminate build state.
May 31 13:55:04 <zeddii> as a last resort, I'll save off my sstate, etc, and start over.
May 31 15:56:44 <peachj> I poked the #oe channel about this without much avail, so now I'm trying here.  I'm using bitbake 1.15.1 and I'm a little unclear on how the --log-domains flag works.  I've looked for docs to see what it expects and what it does, and I sort of understand that it filters debugging output after looking at lib/bb/msg.py, but I'm still quite confused.  Thoughts?
May 31 16:01:12 <RP__> peachj: It turns up/down the verbosity of the different pieces of bitbake. Since we started directing so much output to the logfiles, the domains have become less useful
May 31 16:01:56 <peachj> So basically, don't worry about it?
May 31 16:05:05 <peachj> The only other thing I'm confused about at the moment are the flags relating to a bitbake server.  I assume such a server would be used to help speed up builds by off-loading some amount of work, but I haven't been able to find any docs on exactly what the server is or how one goes about setting it up.  Any advice there?
May 31 16:22:48 <kergoth> peachj: the 'server' is just the part of bitbake that does the real work. it can be a separate process from the UI
May 31 16:29:50 <peachj> Okay, so it's just a way to have multiple UIs connect to the same build workspace
May 31 16:29:51 <peachj> ?
May 31 16:40:10 <rburton> peachj: more like an easy way to parallelise the building
May 31 16:45:28 <peachj> Ah, okay...So if that's true, and I want my organization to do continuous integration with multiple images building, it sounds like I'd be very interested in that.
May 31 16:45:46 <peachj> So, is there good documentation for setting up and using bitbake servers?
May 31 16:54:28 <kergoth> every time you run bitbake, it runs the daemon process in the background, the ui connects to it, and instructs it to do a build
May 31 16:54:37 <kergoth> there's no "setting up and using bitbake servers" at this time
May 31 16:54:47 <kergoth> unless you count the work being done on webhob
May 31 19:30:57 <seebs> Design question!  Imagine that you were to create a toolchain wrapper such that <tuning>-poky-linux-gcc would invoke your real gcc (say, toolchain_staging_bindir/blah-poky-linux/blah-poky-linux-gcc) with suitable --sysroot options and cflags for the current tuning.
May 31 19:31:19 <seebs> Would that be better done with a recipe, or just built directly from the class creating it?
May 31 19:31:39 <seebs> I'm not sure this affects most people, because it's only really necessary if you have a single binary compiler that has to have tuning options and such passed to it.
May 31 19:32:23 <kergoth> I'd say a recipe
May 31 19:34:01 <seebs> Why!  Why must you make me do things the right way which takes more time!  You were supposed to tell me to do the convenient quick hack.
May 31 19:34:24 <seebs> *sulk*
May 31 19:35:28 <kergoth> it also sounds like its of questionable usefulness outside of the context of something like meta-toolchain. people aren't supposed to be running stuff out of the sysroots directly anyway
May 31 19:35:40 <kergoth> but i don't know the use case well
May 31 19:36:04 <seebs> There are a couple.  The big use case for us is:  I have an existing sysroot.  I want a five-line test program compiled and tossed in it.
May 31 19:36:21 <seebs> Being able to just say foo-gcc -o t t.c is a LOT more convenient than writing a recipe.  :)
May 31 19:36:38 <fray> simple usecase.. I've built my image.. ohh damn, I need a simple program to upload to the target..  <wrapper> -o hello hello.c   then scp to target
May 31 19:36:55 <seebs> Well, that's for me.  I am told that the tools and developer support people have some case which they care about involving exporting a sysroot and using it to build apps entirely outside the build system.
May 31 19:37:04 <fray> I don't need a recipe for hello.c, just want the binary to make it quick and easy to see if it worked or not
May 31 19:37:19 <seebs> And strictly speaking, since those are the guys whose work produces the money that pays me, I guess I care about their stupid jerk users who aren't me.
May 31 19:37:24 <kergoth> seebs: that particular case sounds like they want a meta-toolchain or similarly *deployed* sysroot, not the one oe happens to use in its build process
May 31 19:37:26 <kergoth> but *shrug*
May 31 19:37:27 <fray> seebs, ya thats more of the SDK/ADT usecase.. but it's the quick prototype in the build
May 31 19:37:28 <seebs> But mostly I just care for test programs.  :)
May 31 19:37:38 <kergoth> it makes sense for tests, sure
May 31 19:37:42 <kergoth> its a good point
May 31 19:38:30 <seebs> Right.  Recipe it is.
May 31 19:38:41 <seebs> That's cleaner than my other strategy anyway.
May 31 19:39:10 <seebs> I'm trying to make this clean enough to be of use to other people, because I think it's one of those things that becomes indispensible once you've had it for a bit.
May 31 19:39:52 <kergoth> it does sound like one of those things you don't realize the value of until you have it in the toolkit
May 31 19:43:37 <fray> seebs, BTW there is already a package called "gcc-symlinks" being generated for the target..  likely "gcc-wrappers", "binutils-wrappers" is what you will want to naem the output packages [if they ever get installed onto the target --  otherwise it doesn't matter]
May 31 19:45:54 <kergoth> damnit, meta-ti has a bunch of recipes that blindly set PR = MACHINE_KERNEL_PR, yet not all of its machines define MACHINE_KERNEL_PR
May 31 19:46:02 <kergoth> there's a reason kernel.bbclass only sets PR to that if it exists..
May 31 19:46:47 <seebs> I was going to call it toolchain-wrappers, and I had no intention of installing on the target.
May 31 19:48:30 <fray> call it toolchain-wrappers-native then  ;)
May 31 20:00:40 <seebs> Nah, that's just tempting people to think of reasons to break it.
May 31 20:05:49 <dvhart> halstead, has the wiki/bz plugin changed recently?
May 31 20:06:03 <dvhart> halstead, the bug links go to empty wiki pages rather than the bug report
May 31 20:07:23 <halstead> dvhart, I haven't changed anything there yet.
May 31 20:07:34 <dvhart> huh, I swear those worked before
May 31 20:07:42 <halstead> dvhart, I did have interwiki linking working.
May 31 20:17:39 <halstead> dvhart, Fixed.
May 31 20:27:46 <kergoth> hmm, didn't think abou the fact that ??= interacts badly with overrides. that is, foo_bar ??= "1" won't collapse to foo, as the default is applied after overrides were applied
May 31 20:53:54 <denix> kergoth: can you be more specific?
May 31 21:03:39 <dvhart> halstead++
May 31 22:46:34 <khem> kergoth: yeah there is a competition for laziness here
May 31 22:50:10 <fray> isn't that the purpose of being an engineer.. figure out how to not have to keep doing what you are doing?
May 31 22:54:10 <khem> yes it is
May 31 22:54:44 <khem> when teacher punished gauss to go out of class and sum the numbers from 0 to 100 and come back in
May 31 22:54:49 <khem> guess what
May 31 22:54:58 <khem> he came with the formula
May 31 22:54:59 <khem> :)
May 31 22:55:50 <khem> (1 + N)*(N/2)
May 31 22:59:09 <denix> :)
May 31 23:04:56 <mranostay> heh
May 31 23:39:35 <ant__> khem: next time he'll rewrite Fibonacci algo's
**** ENDING LOGGING AT Fri Jun 01 02:59:58 2012

**** BEGIN LOGGING AT Fri Jun 01 02:59:58 2012
Jun 01 06:58:25 <Zagor> perl-5.14.2-r6: task do_package_setscene takes a crazy amount of time
Jun 01 07:24:43 <mckoan> good morning
Jun 01 10:24:29 <ignus16> hi all - is there any way to set the c lib used by meta-toolchain? it seems to default to eglibc but i really need uclibc...
Jun 01 10:30:28 <bluelightning> ignus16: hi
Jun 01 10:30:38 <bluelightning> ignus16: TCLIBC is set to uclibc ?
Jun 01 10:36:15 <ignus16> bluelightning: hey - hows it going?
Jun 01 10:36:27 <bluelightning> ignus16: great thanks, and you?
Jun 01 10:36:45 <ignus16> bluelightning: im good yeah, looking for ward to a long weekend over here :D
Jun 01 10:37:26 <ignus16> forward*
Jun 01 10:37:28 <ignus16> bluelightning: looks like i was wrong and it is building uclibc
Jun 01 10:37:30 <bluelightning> ignus16: indeed :)
Jun 01 10:37:36 <bluelightning> ignus16: ah ok, that's good..
Jun 01 10:38:44 <ignus16> it seems to expect the toolchain to be in /opt though, do you think it would be ok to move it and change the environment-setup-... script or would that break everything?
Jun 01 10:41:06 <bluelightning> ignus16: I think you can have it put into any path you want by changing the SDKPATH variable
Jun 01 10:41:39 <bluelightning> the default is /opt/${DISTRO}/${SDK_VERSION} if using the "poky" (default) DISTRO
Jun 01 10:51:11 <ignus16> bluelightning: where is that variable stashed?
Jun 01 10:51:42 <bluelightning> ignus16: by default it's set in meta-yocto/conf/distro/poky.conf
Jun 01 10:52:27 <bluelightning> ignus16: it's set by = which means it can't be set in the traditional manner from local.conf, I'm not sure if that's deliberate
Jun 01 10:52:42 <ignus16> cool, ill give that a shot. thanks!
Jun 01 10:53:37 <bluelightning> no worries
Jun 01 11:03:51 <ignus16> bluelightning: setting SDKPATH in local.conf seems to be ignored :(
Jun 01 11:04:37 <bluelightning> ignus16: right, as I mentioned above... you may be able to do it by using an override... SDKPATH_forcevariable for example
Jun 01 11:04:43 <bluelightning> somewhat of a blunt instrument though
Jun 01 11:05:07 <bluelightning> I wonder if we just need to make the distro configuration use ?= if it's something that people would normally want to change
Jun 01 11:05:38 <ignus16> i might just set it in poky.conf - hopefully i wont have to change it all that often anyway
Jun 01 11:12:53 <ignus16> bluelightning: is there any way to be sure this is using uclibc? it seems to keep fetching the eglibc sources when it builds which is.. worrying...
Jun 01 11:13:59 <bluelightning> ignus16: hmm, it shouldn't be doing that at all... you could do a "bitbake -g meta-toolchain" to see what is pulling it in in your case
Jun 01 11:14:30 <ignus16> -g gives you the list of packages it compiles does it?
Jun 01 11:16:08 <ignus16>  package eglibc-nativesdk-2.15-r6+svnr17386: task do_compile: Started
Jun 01 11:16:13 <ignus16> that doesnt look right to me...
Jun 01 12:27:52 <bluelightning> ignus16: it gives you dependency graphs for whatever you specify
Jun 01 12:28:04 <bluelightning> at the task, recipe (PN) and package level
Jun 01 15:52:04 <fray> I'm getting an odd error from bitbake:
Jun 01 15:52:10 <fray> Parsing recipes...ERROR: Error Method already seen: get_policyconfigarch in' libselinux_2.1.9.bb' now in 'libselinux_git.bb'
Jun 01 15:52:10 <fray> done.
Jun 01 15:52:45 <fray> there are two recipes, libselinux_2.1.9.bb and libselinux_git.bb that both define the "def:\nget_policyconfigarch"..... but why would this cause a parse error?
Jun 01 15:52:51 <fray> http://git.yoctoproject.org/cgit/cgit.cgi/meta-selinux/tree/recipes-security/selinux/libselinux_2.1.9.bb
Jun 01 16:35:46 <seebs> Hmm.
Jun 01 16:35:50 <seebs> I may have outsmarted myself.
Jun 01 16:36:49 <seebs> I am trying to get the values of TARGET_PREFIX and STAGING_BINDIR_TOOLCHAIN in a recipe.  They are both coming back empty.  If I grab them somewhere else, though, they seem to get set.  I am wondering whether this is one of those things where I need to understand the relationship between bitbake configurations and package configurations and so on.
Jun 01 16:37:22 <fray> where do they work?
Jun 01 16:37:28 <fray> they may be defined in a class or something
Jun 01 16:38:01 <seebs> When I was doing this as a handler for BuildStarted, they worked.  Now that I'm grabbing them in a do_configure, they're not.
Jun 01 16:38:26 <fray> STAGING_BINDIR_TOOLCHAIN is defined in the cross-candian, crosssdk, and nativesdk classes
Jun 01 16:38:50 <seebs> Hmm.  Maybe that is not the directory I want, even.
Jun 01 16:39:10 <seebs> If I want the directory that would contain i586-poky-linux-gcc, what name would I use for that?
Jun 01 16:39:14 <fray> target_prefix, -I think- comes from the crosssdk class
Jun 01 16:39:26 <fray> ...looking...
Jun 01 16:39:40 <seebs> Hmm.  This is interesting, "bitbake -e toolchain-wrappers" shows STAGING_BINDIR_TOOLCHAIN set.
Jun 01 16:39:58 <fray> I was just going to say, it SHOULD be staging_bindir_toolchain
Jun 01 16:40:07 <seebs> But "bitbake toolchain-wrappers" ends up with an empty value for it.  Hmmm.
Jun 01 16:40:20 <fray> something must be clearing it then?
Jun 01 16:40:25 <fray> bitbake.conf:PATH_prepend = "${COREBASE}/scripts:${STAGING_BINDIR_TOOLCHAIN}:${STAGING_BINDIR_CROSS}:${STAGING_DIR_NATIVE}${sbindir_native}:${STAGING_BINDIR_NATIVE}:${STAGING_DIR_NATIVE}${base_sbindir_native}:${STAGING_DIR_NATIVE}/${base_bindir_native}:"
Jun 01 16:40:29 <fray> that is the normal path set
Jun 01 16:40:36 <seebs> Hmm.
Jun 01 16:40:48 <fray> bitbake.conf:STAGING_BINDIR_TOOLCHAIN = "${STAGING_DIR_NATIVE}${bindir_native}/${TUNE_PKGARCH}${TARGET_VENDOR}-${TARGET_OS}"
Jun 01 16:42:11 <fray> all I can say is check for typos.. otherwise, I'm really not sure
Jun 01 16:42:25 <seebs> I should maybe use that construct to guess at the prefix to use in the case where TARGET_PREFIX isn't set.
Jun 01 16:42:57 <seebs> Similar to the way I check for EXTERNAL_TOOLCHAIN, and use STAGING_BINDIR_TOOLCHAIN if it's not set.
Jun 01 16:43:50 <seebs> Oh, wait.  I'm smart.
Jun 01 16:44:01 <seebs> BINDIR is fine, SYSROOT is wrong.
Jun 01 16:44:17 <fray> Target prefix will -not- be set unless this is a 'cross' package
Jun 01 16:44:19 <seebs> Which I was setting to STAGING_DIR_HOST.
Jun 01 16:44:25 <fray> I bet that is your problem..
Jun 01 16:44:33 <seebs> Yeah.  Okay, I can fix that, then.
Jun 01 16:44:33 <fray> this shouldn't be a -native but instead should be a -cross.
Jun 01 16:45:49 <seebs> Wow, who would have thought that a tool for building target binaries would be a -cross package.
Jun 01 16:46:22 <seebs> <-- got about four hours of sleep
Jun 01 16:46:44 <seebs> Hey, speaking of late nights:  mebrown, how'd your Yocto thing go?
Jun 01 16:48:12 <seebs> And yes, that fixed it all.  I was building as the wrong package type.
Jun 01 16:51:52 <scottrif> halstead: ping
Jun 01 16:52:05 <halstead> scottrif, pong.
Jun 01 16:52:28 <scottrif> halstead: having issues again trying to use Git to create a remote branch.  Can you help me?
Jun 01 16:52:39 <halstead> Sure.
Jun 01 16:52:52 <halstead> scottrif, pm?
Jun 01 16:52:59 <scottrif> halstead: sure
Jun 01 19:10:17 <kergoth> <3 knotty2
Jun 01 19:18:22 <kergoth> RP__: thoughts on marking up log events sent from a task process with the task info, and displaying that in the UI?
Jun 01 20:39:32 <pingswept> After changing KERNEL_IMAGETYPE, what do I need to clean in order to get the kernel rebuilt as a uImage? More than just linux-yocto?
Jun 01 22:33:25 <dvhart> pingswept, try "bitbake linux-yocto -c compile -f; bitbake linux-yocto"
Jun 02 00:45:35 <pingswept> dvhart: Thanks for the suggestion. I'll give it a try next week. Cheers.
**** ENDING LOGGING AT Sat Jun 02 02:59:58 2012

**** BEGIN LOGGING AT Sat Jun 02 02:59:58 2012
Jun 02 04:36:43 * kergoth ponders
Jun 02 16:48:36 <otavio> Hi
Jun 02 16:48:50 <otavio> How is the process to get changes on denzil?
**** ENDING LOGGING AT Sun Jun 03 02:59:59 2012

**** BEGIN LOGGING AT Sun Jun 03 02:59:59 2012
Jun 03 14:42:49 <kos_tom> hello
Jun 03 14:43:18 <kos_tom> how does the Yocto Eclipse plugin provides its remote debugging capabilities? using gdbserver or tcf-agent?
Jun 03 17:46:19 <khem> kos_tom: tcf-agent
Jun 03 18:03:39 <kos_tom> khem: but from what I understand, the tcf-agent debugging capabilities are only for x86
**** ENDING LOGGING AT Mon Jun 04 02:59:58 2012

**** BEGIN LOGGING AT Mon Jun 04 02:59:59 2012
Jun 04 08:23:49 <mckoan> good morning
Jun 04 08:29:31 <d4ny> morning,
Jun 04 08:29:55 <d4ny> How do I get out of this loop after killing a locked bitbake session ?, ERROR: Only one copy of bitbake should be run against a build directory
Jun 04 08:32:09 <d4ny> rm -fr bitbake-lock for those who get the same problem .
**** BEGIN LOGGING AT Mon Jun 04 15:56:03 2012
Jun 04 16:36:17 <pidge> halstead: ping
Jun 04 16:37:10 <pidge> halstead: can you check www. Things are kind of slow right now both on the site and via git. Curious as to why.
Jun 04 16:47:36 <halstead> pidge, Sure.
Jun 04 16:49:24 <halstead> pidge, bandwidth looks okay. I was trying up a bunch for backups this weekend.
Jun 04 16:52:39 <pidge> hrm. Ok. just saw some slowness about 20 minutes ago and was wondering why.
Jun 04 16:55:17 <halstead> pidge, I'm not sure but all of my open connections to the ab stack died about 20 minutes ago as well. I suspect something with the ISP but I haven't received any notices yet.
Jun 04 16:56:22 <chackal_sjc> where can I find information about the runlevel descriptions??
Jun 04 16:58:34 <halstead> pidge, There is a DOS attack on the OSU edge router but they caught it pretty quickly so it should have minimal impact.
Jun 04 16:58:54 <pidge> halstead: ty!
Jun 04 17:27:14 <fray> is there anyway to run a python script (class item) from ROOTS_POSTINSTALL_COMMANDS ?
Jun 04 17:27:33 <fray> I want to do something that is fairly complicated, but I was hoping to do it in python...
Jun 04 17:27:41 <kergoth> do_rootfs[postfuncs] += might be easier
Jun 04 17:27:50 <kergoth> otherwise youc ould hack something with ${@} but i wouldn't recommend that
Jun 04 17:28:04 <fray> do_rootfs[post..] is too late
Jun 04 17:28:18 <fray> and ${@...} causes the item to be evaluated way to early
Jun 04 17:28:26 <kergoth> then no
Jun 04 17:28:31 <fray> process_changelist() {
Jun 04 17:28:32 <fray>   echo "${@do_process_changelist(d)}"
Jun 04 17:28:32 <fray> }
Jun 04 17:28:32 <fray> ROOTFS_POSTPROCESS_COMMAND += "process_changelist ;"
Jun 04 17:28:35 <fray> that is what I had..
Jun 04 17:28:45 <fray> it evaluates do_process_changelist during parsing
Jun 04 17:28:55 <fray> which makes no sense, because we don't yet have a filesystem
Jun 04 17:29:16 <kergoth> postprocess command is just ${} referenced from do_rootfs, it's not done from python context, as do_rootfs isn't python
Jun 04 17:29:22 <kergoth> so not many options
Jun 04 17:29:34 <fray> yes, thats the problem I'm having
Jun 04 17:29:57 <fray> re-write this in shell, or write an external program.. no other options?
Jun 04 17:32:13 <kergoth> not that i'm aware of, no, unfortunately
Jun 04 17:32:55 <fray> thanx
Jun 04 17:36:33 <chackal_sjc> guys
Jun 04 17:36:59 <chackal_sjc> my image just have the IMAGE_FEATURES += "x11-mini"
Jun 04 17:37:06 <chackal_sjc> but the x server wont start
Jun 04 17:42:57 <khem> chackal_sjc: what errors do you get and I think you have to debug it
Jun 04 17:47:04 <chackal_sjc> khem: http://paste.kde.org/492956/
Jun 04 17:47:08 <chackal_sjc> how to debug?
Jun 04 17:49:36 <khem> chackal_sjc: what is your end goal
Jun 04 17:50:01 <khem> you can try to boot this image into shell
Jun 04 18:01:48 <pidge> fray: Confirming that your recent rootfs_rpm.bbclass is for the do_populate_sdk issue?
Jun 04 18:02:47 <pidge> fray: ah, nm. I see that it is.
Jun 04 19:09:21 <xumbi> greetings! has anyone been using samba under yocto recently?
Jun 04 19:45:04 <zenlinux> xumbi, we had a demo of a NAS device that I think supported samba
Jun 04 19:45:13 <zenlinux> meta-baryon
Jun 04 19:45:49 <xumbi> oh awesome, yep here it is http://git.yoctoproject.org/cgit/cgit.cgi/meta-baryon/tree/recipes-connectivity/samba
Jun 04 19:45:54 <xumbi> thanks!
Jun 04 20:07:22 <pingswept> When I rebuild my kernel, even using -c compile -f, the timestamps don't update. Do I need to do something else to force a rebuild?
Jun 04 20:10:40 <xumbi> pingswept: have you tried -c clean?  that will clear everything out, not sure if that's what you want
Jun 04 20:11:31 <pingswept> xumbi: yes. It *does* delete my uImage file correctly, but when it is rebuilt, the timestamps are not updated and the binary is unchanged.
Jun 04 20:12:05 <pingswept> (In theory, the binary should have changed, but I might be doing something else wrong invalidating that.)
Jun 04 20:53:32 <chackal_sjc> khem: sorry, im back now
Jun 04 20:53:50 <chackal_sjc> well.. my end goal is to start x then start a qt application
Jun 04 22:20:53 <chackal_sjc> guys
Jun 04 22:20:53 <chackal_sjc> my image just have the IMAGE_FEATURES += "x11-mini"
Jun 04 22:20:53 <chackal_sjc> but the x server wont start
**** ENDING LOGGING AT Tue Jun 05 02:59:57 2012

**** BEGIN LOGGING AT Tue Jun 05 02:59:58 2012
Jun 05 06:38:36 <moolinex> morning
Jun 05 06:42:40 <mranostay> not here it isn't
Jun 05 07:45:35 <mckoan> good morning
Jun 05 12:55:34 <otavio> sgw: did you see the patch for openjade?
Jun 05 16:39:59 <ignus16> hello all - is there any easy way to disable a single sanity check?
Jun 05 16:55:52 <chackal_sjc> guys
Jun 05 16:56:01 <chackal_sjc> how to use properly the ALTERNATIVE?
Jun 05 16:56:19 <chackal_sjc> any example?
Jun 05 17:42:53 <fray> for the alternative are you talking the update-alternatives
Jun 05 20:19:34 <msm> how would i list the rpm packages installed on a machine from an x86 host?
Jun 05 20:19:42 <msm> sudo ../tmp/sysroots/x86_64-linux/usr/bin/rpm -qa —root=/path/to/untarred/rfs
Jun 05 20:19:46 <msm> does not seem to print anything
Jun 05 20:19:58 <msm> yet the rpm database is rather large
Jun 05 20:27:51 <pidge> fray: More rpm 'fun' for you: http://autobuilder.yoctoproject.org:8010/builders/nightly-multilib/builds/81/steps/shell_24/logs/stdio
Jun 05 20:28:08 <fray> looking
Jun 05 20:28:50 <fray> this looks like the same bug as before.. if the manifest file is empty..  rpm goes "well duh you asked me to do something stupid, so I won't do it"
Jun 05 20:30:04 <fray> I'll look at it in a minute.. but may not be able to as easily reproduce this.. but at least I have a feeling as to whats wrong..
Jun 05 20:33:18 <fray> pidge, where is the local.conf for this particular build?
Jun 05 20:33:23 <fray> I think I need it to reproduce the issue
Jun 05 20:37:46 <pidge> fray: one sec
Jun 05 20:38:14 <fray> appears the target fs is lib32-core-image-minimal..  but I'm not sure what the lib32 settings are
Jun 05 20:38:21 <pidge> http://autobuilder.yoctoproject.org:8010/builders/nightly-multilib/builds/81/steps/shell_17/logs/stdio
Jun 05 20:38:35 <pidge> fray: the echo creates the local.conf
Jun 05 20:38:57 <fray> thanx.. that has what I need.. I'll get on it
Jun 05 21:52:45 <chackal_sjc> how do I bake a package that is already in cache?
Jun 05 21:52:56 <chackal_sjc> I dont want to run like bitbake -c compile package
Jun 05 21:53:07 <chackal_sjc> because i want to run all the commands
Jun 05 21:55:31 <fray> pidge, patch pending...
Jun 05 21:58:37 <fray> pidge, ok.. update sent..  HOPEFULLy the final one!
Jun 05 22:03:53 <mranostay> chackal_sjc: bitbake -c clean ?
Jun 05 22:15:06 * pidge crosses fingers and pulls them into mut
Jun 05 22:21:36 <chackal_sjc> mranostay: not actally
Jun 05 22:24:41 <chackal_sjc> mranostay: actually it works hehe
Jun 05 22:24:42 <chackal_sjc> thx
**** ENDING LOGGING AT Wed Jun 06 02:59:58 2012

**** BEGIN LOGGING AT Wed Jun 06 02:59:58 2012
Jun 06 03:51:28 <n0t> Sorry to bother you, does the yocto project support GMA3600?
Jun 06 08:43:35 <mckoan> good morning
Jun 06 16:10:36 <chackal_sjc> guys.. my keyboard is not working with Xfbdev
Jun 06 16:10:43 <chackal_sjc> dont know what yo do
Jun 06 16:10:45 <chackal_sjc> to*
Jun 06 16:49:38 <mranostay> press on the keys harderd?
Jun 06 16:49:46 <mranostay> *harder
Jun 06 16:50:09 <chackal_sjc> mranostay: very funny
Jun 06 16:50:22 <chackal_sjc> the map is not setted
Jun 06 16:50:36 <chackal_sjc> and the keymap.default doesnt work either
**** ENDING LOGGING AT Thu Jun 07 02:59:58 2012

**** BEGIN LOGGING AT Thu Jun 07 02:59:59 2012
Jun 07 08:11:04 <mckoan> good morning
Jun 07 13:10:00 <Zagor> I propose adding CCACHE to BB_HASHBASE_WHITELIST
Jun 07 14:22:28 <jrw> Is there any way to call "oe_runmake ..." from a "python do_compile() {  oe_runmake?}"
Jun 07 14:22:50 <jrw> I searched the tree a bit and could not find an example, so it is not clear that you or if there is another way to do it.
Jun 07 14:35:30 <jrw> heh... I didn't look hard enough. Answer = bb.build.exec_func("oe_runmake", d)
Jun 07 14:38:08 <rburton> just heard about PACKAGECONFIG in .bb, is there a good example/documentation for it?
Jun 07 15:00:05 <rburton> anyone seen autogen-native failing with "ccache: failed to create /dev/null/.ccache (Not a directory)nbootstrap failure"
Jun 07 15:02:05 <rburton> ah, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672570 seems relevant
Jun 07 20:56:38 <vmeson> Does the yocto build support distributing package build and linking across a set of build servers? (pretty sure the answer is no...)
Jun 07 20:58:19 <rburton> vmeson: i *think* you can use distcc if you want
Jun 07 20:58:47 <rburton> vmeson: but throw yocto at a 8-core i7 and you'll be doing a compete distro build from scratch in about an hour
Jun 07 20:58:59 <vmeson> rburton: yes but some systems (OBS I'm told) distribute the package builds to N machines.
Jun 07 20:59:13 <rburton> yes, OBS wants about 20 machines
Jun 07 20:59:36 <rburton> in my experience, OBS is rather slow
Jun 07 21:00:09 <vmeson> _wants_ ? yikes... I heard that it build in a VM on each machine but a factor of 20 slower is nuts.
Jun 07 21:00:22 <rburton> well, the meego obs farm was ~20 machines
Jun 07 21:00:45 <rburton> with something like 13 build slaves
Jun 07 21:01:27 <vmeson> rburton: any idea what the speed-up from distcc is? I expect the build is i/o and dependency bound on a good builder.
Jun 07 21:01:30 <rburton> i'm not exagerating when i say my fairly normal laptop can build the yocto sato image faster than the meego farm could rebuild
Jun 07 21:01:36 <rburton> vmeson: none
Jun 07 21:02:17 <rburton> yocto will heavily parrellise (hm, how do you spell that!)
Jun 07 21:02:22 <vmeson> ok, I might test that at some point.
Jun 07 21:02:34 <vmeson> it's ||ize :)
Jun 07 21:02:36 <rburton> you can run N builder threads, and each thread will pass -jM to make
Jun 07 21:03:29 <rburton> so you'll almost never actually have a cpu not at 100% :)
Jun 07 21:03:42 <vmeson> I had some fun visits from the oom-killer on my 12 G 8x2 core box when I first stared using OE.
Jun 07 21:03:59 <rburton> hehe
Jun 07 21:04:21 <vmeson> k, l8r.
**** ENDING LOGGING AT Fri Jun 08 02:59:59 2012

**** BEGIN LOGGING AT Fri Jun 08 02:59:59 2012
Jun 08 07:40:12 <mckoan> good morning
Jun 08 16:23:03 <chackal_sjc> i just pulled from the git repo and my build is breaking =/
Jun 08 16:23:15 <zeddii> see the mailing list.
Jun 08 16:23:30 <zeddii> remove a 'l' from the end of linux-yocto_3.2.bb's meta SRCREV
Jun 08 16:23:34 * zeddii goes to hide
Jun 08 16:24:36 <chackal_sjc> hmm
Jun 08 16:24:39 <chackal_sjc> which list
Jun 08 16:24:57 <zeddii> yocto
Jun 08 16:27:18 <chackal_sjc> zeddii, thanks
Jun 08 16:27:49 * zeddii broke it. so it's now his duty to troll and find those that are suffering.
Jun 08 16:28:03 <chackal_sjc> hahaha ok
Jun 08 16:28:16 <chackal_sjc> whats the difference to submit a patch from the bugzilla and the list?
Jun 08 16:31:10 <khem> zeddii: now 3.4 is out
Jun 08 16:31:32 <khem> zeddii: will you also update poky-extras layer too pleaee ?
Jun 08 16:32:33 <zeddii> I was working on that. I was poking at 3.5-rc1. but breaking the build has me distracted :)
Jun 08 17:01:49 <dvhart> chackal_sjc, the difference is that project policy is for patches to go to the lists in order to receive peer review. Email is a more flexible medium for discussing patches than bugzilla.
Jun 08 17:18:04 <walters> so, i'd like to modify eglibc, and am struggling a bit with devshell
Jun 08 17:18:14 <walters> am looking at http://www.openembedded.org/wiki/Devshell
Jun 08 17:18:43 <walters> so is there a sane way to invoke do_compile() from inside the shell?
Jun 08 17:18:59 <walters> i've done the "git init; git add .; git commit -m init" dance that i have to do with fedora packages too
Jun 08 17:19:15 <walters> (to avoid going insane working without revision control)
Jun 08 17:55:27 <GNUtoo> walters, look at morphis's devshell
Jun 08 17:56:03 <GNUtoo> https://github.com/morphis/meta-staging/blob/master/recipes-devtools/devshell/devshell.bb
Jun 08 17:56:32 <walters> um... this https://github.com/morphis/meta-staging/commit/8d418b058e3f929360e97bca3cf936c7f5c173df ?
Jun 08 17:56:37 <walters> right
Jun 08 17:58:57 <walters> hm, i think i'll just keep going with my approach of pointing the recipe at a local git repo
Jun 09 00:03:36 <riskable> When making a .bb file is there some variable where it is customary to point to the official home of the package?
Jun 09 00:03:56 <dvhart> riskable, see the HOMEPAGE comment in various recipes
Jun 09 00:04:18 <riskable> dvhart: Can you give me an example recipe (so I don't have to grep the entire directory structure)?
Jun 09 00:04:26 <dvhart> ?
Jun 09 00:04:35 <dvhart> git grep HOMEPAGE
Jun 09 00:04:45 <dvhart> meta/recipes-bsp/grub/grub_0.97.bb:HOMEPAGE = "http://www.gnu.org/software/grub/"
Jun 09 00:04:52 <dvhart> one of many examples
Jun 09 00:05:25 <riskable> Ahh, so it isn't a comment it is an actual variable :)
Jun 09 00:05:32 <riskable> Perfect, thanks
Jun 09 00:05:34 <dvhart> indeed, I remembered incorrectly
Jun 09 00:05:41 <dvhart> welcome
Jun 09 00:07:42 <riskable> I'm putting together an ipython_0.12.1.bb right now and I thought it would be a good idea to point to the home page
Jun 09 00:09:48 <dvhart> absolutely, setting up all the fields and comment blocks initially is always a good idea (because nobody will want to do it later ;)
Jun 09 00:28:31 <riskable> I noticed that there's an old zeromq*.bb floating out there in patchwork...  But it was never accepted apparently?
**** ENDING LOGGING AT Sat Jun 09 02:59:59 2012

**** BEGIN LOGGING AT Sat Jun 09 02:59:59 2012
**** ENDING LOGGING AT Sun Jun 10 03:00:02 2012

**** BEGIN LOGGING AT Sun Jun 10 03:00:03 2012
**** ENDING LOGGING AT Mon Jun 11 02:59:58 2012

**** BEGIN LOGGING AT Mon Jun 11 02:59:59 2012
Jun 11 07:26:32 <mckoan> good morning
Jun 11 09:54:39 <bluelightning> hi folks
Jun 11 15:21:42 <otavio> sgw: I am back to udev consolidation work
Jun 11 15:21:57 <otavio> sgw: I am working on 182 merging on oe-core
Jun 11 15:23:11 <otavio> RP__: Once I have it working fine for sysv and systemd based images I'll ping you for a initial review ... it is not easy to split it among serveral incremental patches
Jun 11 15:24:43 <otavio> RP__: do you mind?
Jun 11 15:36:58 <ant_work> zeddii: ping
**** ENDING LOGGING AT Tue Jun 12 02:59:58 2012

**** BEGIN LOGGING AT Tue Jun 12 02:59:58 2012
Jun 12 08:19:55 <mckoan> good morning
Jun 12 09:55:44 <bluelightning> morning folks
Jun 12 11:14:30 <exosyst> If I have the default output for an atom build and use PXEBoot to boot with NFS, are there any gotchas? I have APPEND root=/dev/nfs init=/sbin/init nfsroot=192.168.2.1:/nfsroot,rw ip=dhcp devfs=nomount but when it boots it hangs for a while after IP config and then panics about no rootfs. Any ideas?
Jun 12 11:15:43 <exosyst> oh, and kernel bzImage-atom-pc.bin
Jun 12 13:23:28 <otavio> RP__: replied on your proposed patch
Jun 12 13:23:44 <otavio> RP__: thanks by looking how to fix it properly
Jun 12 15:36:05 <sgw> khem: ping regarding your busybox comment
Jun 12 15:47:27 <zeddii> fray was too busy typing on his new macbook ?
Jun 12 15:48:06 <fray> hehe no, I hit the wrong button and didn't clear mute.. ;)
Jun 12 21:09:34 <khem> on a fresh poky clone I get ERROR: Function failed: Fetcher failure for URL: 'ftp://ftp.ossp.org/pkg/lib/uuid/uuid-1.6.2.tar.gz'. Unable to fetch URL  from any source.
Jun 12 21:09:45 <khem> anyone seen it
Jun 12 21:11:29 <khem> http://autobuilder.yoctoproject.org/pub/sources/ does not have a copy either
Jun 12 21:12:59 <khem> can some one populate the autobuilder with a copy so fresh downloads can work ?
Jun 12 21:13:07 <khem> http://www.mirrorservice.org/sites/ftp.ossp.org/pkg/lib/uuid/uuid-1.6.2.tar.gz
Jun 12 21:17:05 <sgw> khem: I am seeing that also, I will work pidge or halstead to get that on the autobuilder mirror
Jun 12 21:17:32 <sgw> fray: you around?  I am seeing a build failure with new RPM and libdb versioning.
Jun 12 21:17:37 <khem> sgw: thanks
Jun 12 21:17:53 <khem> sgw: did you do fresh build or incremental
Jun 12 21:17:53 <sgw> pidge: halstead: ping re libuuid
Jun 12 21:18:15 <khem> sgw: when I did incremental build then it complained about db versions
Jun 12 21:18:17 <sgw> fresh with an existing DL_DIR
Jun 12 21:18:29 <sgw> khem, talking about RP?
Jun 12 21:19:18 <khem> sgw: build from scratch succeeded with new rpm
Jun 12 21:19:34 <khem> and also build from sstate-mirrors
Jun 12 21:19:52 <khem> its just when I tried to build on top of existing build it failed with db versioning error
Jun 12 21:20:06 <sgw> yes, that's what I am seeing
Jun 12 21:20:16 <khem> sgw: I did not understand what did you mean by taking about RP
Jun 12 21:20:46 <sgw> meant RPM
Jun 12 21:21:27 <khem> oh yed
Jun 12 21:21:29 <khem> yes
Jun 12 21:23:36 <pidge> sgw: hrm. let me look
Jun 12 21:25:15 <pidge> khem: sgw: is this a new package?
Jun 12 21:25:31 <sgw> not really, but the upstream seems to be failing somehow
Jun 12 21:25:44 <pidge> hrm. ok. I have it in sources now
Jun 12 21:25:59 <khem> yes upstream ftp server is not letting do cd which is what wget does
Jun 12 21:26:11 <khem> http/web download works ok
Jun 12 21:26:19 <pidge> kind of odd, since the rsync seems to have not moved the copy I had over in my jailed sources over to live.
Jun 12 21:26:28 * pidge looks into why that happened
Jun 12 21:28:20 <pidge> hrm. cronjob is missing.
Jun 12 21:28:36 <chackal_sjc> how do I use bitbake with ssh+git ??
Jun 12 21:30:21 <sgw> khem: have you seen the issue with gcc-4.7 and systemtap-sdt?
Jun 12 21:34:24 <khem> sgw: yes, I havent reproduced it here though, it seems to be a problem in gcc configure
Jun 12 21:34:46 <khem> havent had time to look into why its probing the build host
Jun 12 21:35:18 <sgw> I looked at it briefly, seems to be a hard coded check in configure
Jun 12 21:39:09 <sgw> zeddii: you around, seems you kernel -rt stuff has a bad SRCPV
Jun 12 21:39:21 <sgw> zeddii: or SRCREV
Jun 12 21:44:46 <sgw> khem: the issue is the setting of $target_header_dir was somehow not correct, I did not get much deeper that than in gcc/configure
Jun 12 21:45:20 <khem> hmmm
Jun 12 21:46:44 <khem> I see
Jun 12 21:47:03 <khem> that would be because we dont have --with-sysroot or sysroot is set to /
Jun 12 21:50:15 <khem> I would like to see run.do_configure of gcc
Jun 12 21:52:20 <sgw> doing that now, hang on
Jun 12 21:55:54 <sgw> Toplevel configure command: http://pastebin.com/iVDGHxzB
Jun 12 21:57:47 <khem> ok I see the problem
Jun 12 21:59:58 <sgw> missing --with-sysroot?
Jun 12 22:01:12 <khem> sgw: can you also pastebin the output of bitbake -e gcc  somewhere ?
Jun 12 22:01:55 <khem> sgw: yes missing both --with-sysroot and more importantly --with-build-sysroot
Jun 12 22:01:56 <sgw> sure hang on, I had fired up a build to get the gcc/config.log file
Jun 12 22:02:23 <sgw> are those new to 4.7?
Jun 12 22:02:44 <khem> they are not new
Jun 12 22:03:02 <khem> but they must be used since it now have with-native-include option
Jun 12 22:03:10 <khem> and it defaults to that if none specified
Jun 12 22:03:29 <khem> so we have to use proper values
Jun 12 22:03:51 <sgw> right, I will have the -e as soon as the do_compile finishe (slow machine)
Jun 12 22:05:35 <khem> oh interrupt it
Jun 12 22:05:45 <khem> it will resume where it left next time anyway
Jun 12 22:06:52 <sgw> emailed
Jun 12 22:14:42 <khem> sgw: can you try this patch http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/misc&id=df9ccc1a7b01ab9730ed3747e6b48f4ecabc822e
Jun 12 22:15:23 <sgw> sure, give me a minute
Jun 12 22:15:34 <khem> its quite invasive for target recipe so when you see that it fixes the build issue try to execute it on target
Jun 12 22:15:43 <khem> and compile some sane programs
Jun 12 22:15:56 <khem> on target using it and see if it find headers and libs correctly
Jun 12 22:16:01 <sgw> that will take a while, I will get back to you later.
Jun 12 22:16:05 <khem> sure
Jun 12 22:16:56 <khem> sgw: leave a message here and I will read later
Jun 12 22:17:17 <sgw> do I need the 1-rc patch also or will it work with 4.7?
Jun 12 22:17:26 <khem> no you dont need that
Jun 12 22:18:25 <sgw> khem: PR bumps for all gcc recipes or will that only affect target?
Jun 12 22:18:36 <khem> only target
Jun 12 22:18:58 <khem> but lets first test it out if it fixes the thing or not
Jun 12 22:43:58 <sgw> halstead: ping
Jun 12 22:57:00 <halstead> sgw pong.
Jun 12 23:07:16 <sgw> halstead: package reporting system seems to be having a problem, it's not sending out the weekly email, and it's getting an internal server error on one of the pages (I think unable to get a db connection)
Jun 12 23:07:51 <halstead> sgw, Which page has the internal server error?
Jun 12 23:08:04 <sgw> http://packages.yoctoproject.org/upgradeinfo
Jun 12 23:09:06 * halstead takes a look.
Jun 12 23:41:40 <pidge> sgw: halstead: Ok, cronjob for the source rsync fixed. seems it disappeared : / Once an hour now and everything should be up to date.
Jun 12 23:48:39 <halstead> pidge, Thanks. Is that running on ab01?
Jun 12 23:53:56 <pidge> halstead: Yeah
Jun 12 23:59:31 <halstead> sgw,  https://privatepaste.com/63b446f71e is the error I see. I'll need to edit index.py which you have a lock on to continue to troubleshoot.
Jun 13 00:00:16 <sgw> halstead:  all yours
Jun 13 00:29:43 <halstead> sgw, Does http://packages.yoctoproject.org/upgradeinfo look correct now?
Jun 13 01:10:13 <sgw> better, but now: http://packages.yoctoproject.org/upgradehistory fails!
Jun 13 01:10:18 <sgw> halstead: ^^^
Jun 13 01:11:41 <halstead> sgw, Okay. I'll pursue that. The problem was an invalid template control command.
Jun 13 02:48:01 <halstead> This one is quite a bit trickier. I'll pick back up on it later.
**** ENDING LOGGING AT Wed Jun 13 02:59:58 2012

**** BEGIN LOGGING AT Wed Jun 13 02:59:58 2012
Jun 13 14:10:01 <walters> anyone know of a recipie for mit kerberos floating around anywhere, before i write one?  didn't see one in meta-oe or core
Jun 13 14:16:51 * walters finds http://patches.openembedded.org/patch/20141/
Jun 13 14:39:47 <rburton> morning walters
Jun 13 14:44:28 <walters> hey rburton
Jun 13 15:31:32 * RP__ is pleased to have rburton working on Yocto now :)
Jun 13 15:32:14 <rburton> RP__: say that again, davest missed it :)
Jun 13 15:32:38 * RP__ is pleased to have rburton working on Yocto now :)
Jun 13 15:32:51 <RP__> but davest knows that already
Jun 13 15:32:52 <rburton> gee, thanks RP__!
Jun 13 15:37:56 <khem> with poky i get
Jun 13 15:37:57 <khem> ERROR: kern-tools-native: md5 data is not matching for file://git/tools/kgit;beginline=5;endline=9;md5=d8d1d729a70cd5f52972f8884b80743d
Jun 13 15:38:01 <khem> ERROR: kern-tools-native: The new md5 checksum is e2bf4415f3d843f43d2e22b0d91a6fee
Jun 13 15:38:04 <khem> ERROR: kern-tools-native: Check if the license information has changed in
Jun 13 15:38:06 <khem> ERROR: Licensing Error: LIC_FILES_CHKSUM does not match, please fix
Jun 13 15:38:19 <khem> same worked with OE-Core standlone (I think)
Jun 13 15:39:11 <zeddii> not seeing that here. I had send a patch last week that addressed it.
Jun 13 15:39:17 <zeddii> s/send/sent/
Jun 13 15:40:13 <khem> is it committed already ?
Jun 13 15:41:27 <zeddii> should be. let me rummage around.
Jun 13 15:43:00 <khem> what is poky's sync schedule with oe-core ?
Jun 13 15:43:24 <khem> does it sync at every commit or at some given time regularly
Jun 13 15:43:36 <khem> I guess patches flow in both directions so I am a bit unclear
Jun 13 15:45:15 <khem> zeddii: I have poky-extras/meta-kernel-dev
Jun 13 15:45:20 <khem> so thats the problem here
Jun 13 15:45:28 <khem> since it alters the SRC_URI in bbappend
Jun 13 15:45:43 <zeddii> aha. I have it here as well. did I not push that part. hmm.
Jun 13 15:46:01 <khem> to poky-extras ?
Jun 13 15:46:21 <khem> last commit was on apr-30
Jun 13 15:47:40 <zeddii> I'm seeing my changes from 5 days ago in master (of poky extras)
Jun 13 15:48:43 <khem> ok but my question is do we need the bbappend from poky-extras still
Jun 13 15:49:48 <zeddii> for kern-tools. not really. I left it in, and commented out the SRC_URI by deafult in master. the master branch of kern-tools will work with master + meta-kernel-dev.
Jun 13 15:50:29 <khem> hmmm
Jun 13 15:50:32 <khem> it doesnt
Jun 13 15:51:15 <zeddii> really ? I'm running that combo here. what's your error ?
Jun 13 15:51:27 <khem> i pasted above
Jun 13 15:51:32 <khem> license checksum error
Jun 13 15:51:54 <zeddii> argh. definitely not seeing it here. why is that ....
Jun 13 15:53:00 <khem> on master SRC_URI is different
Jun 13 15:53:16 <khem> git://git.yoctoproject.org/yocto-kernel-tools.git
Jun 13 15:53:45 <khem> RC_URI = "git://git.yoctoproject.org/yocto-kernel-tools.git;protocol=git;branch=tools-ng"
Jun 13 15:53:55 <khem> is tools-ng branch still relevant
Jun 13 15:54:11 <zeddii> not anymore. I merged it all to master of the kern-tools.
Jun 13 15:54:23 <khem> so therefore the bbappend is stale
Jun 13 15:55:02 <zeddii> that's what I don't understand. the master branch of poky-extras that I'm looking at has that bbappend commented out completely.
Jun 13 15:55:12 <khem> oh
Jun 13 15:55:26 <khem> I am on dev-ng
Jun 13 15:55:59 <zeddii> aha. now that makes more sense.
Jun 13 15:56:16 <zeddii> you can go to master for everything now. it all merged.
Jun 13 15:56:26 <zeddii> fray, ping.
Jun 13 15:56:46 <khem> yes did that now
Jun 13 15:56:57 <khem> I am doing this all dance to get mips64 kernel
Jun 13 15:57:18 <khem> since I still need to use my own meta branch
Jun 13 15:58:04 <zeddii> I can merge meta commits for to linux-yocto-3.4 if you have some. there's likely no users besides you and me at the moment.
Jun 13 15:58:18 <khem> I have some more asking
Jun 13 15:58:29 * zeddii can't package linux-yocto-rt #@$
Jun 13 15:58:33 <khem> whom I have to talk today :)
Jun 13 16:00:22 <fray> zeddii her
Jun 13 16:00:55 <khem> NOTE: Error during finalise of /home/kraj/work/poky/meta/recipes-kernel/linux/li
Jun 13 16:00:55 <khem> nux-yocto_3.0.bb
Jun 13 16:00:55 <khem> ERROR: ExpansionError during parsing /home/kraj/work/poky/meta/recipes-kernel/linux/linux-yocto_3.0.bb: Failure expanding variable SRCPV,
Jun 13 16:01:27 <khem> prolly need to sync my repo
Jun 13 16:03:13 <zeddii> fray. I can't figure out why my new linux-yocto-rt_3.4 recipe is throwing a packaging error when the 3.0 and 3.2 ones aren't .. they are the same, just different version numbers. I'm hunting up the log now.
Jun 13 16:04:02 <fray> odd..
Jun 13 16:05:22 * zeddii really didn't want to fight with this today, I'm drowning in my TODO list :)
Jun 13 16:05:41 <fray> ya, I understand
Jun 13 16:05:47 <fray> pastebin or email me the log and I can look
Jun 13 16:06:14 <khem> oh dev kernel has not moved a lot since hmmm
Jun 13 16:06:51 <zeddii> ah yes. I'm updating it to 3.5, I can just push the linux-yocto-3.4 tree there if that helps.
Jun 13 16:07:04 <khem> dont worry
Jun 13 16:07:47 <sgw> khem: ran it a problem with my sdk build last night, so no test results yet on that gcc issue.
Jun 13 16:07:54 <zeddii> yah. for what I was using -dev for, I now just use linux-yocto in master. 3.5-rcX is next.
Jun 13 16:08:02 <zeddii> (on that todo list).
Jun 13 16:08:19 <khem> sgw: no issues someone verified it
Jun 13 16:11:01 <zeddii> fray, dropped you an email. I'm looking at it myself now.
Jun 13 16:11:43 <zeddii> my grep for error returns .. nothing.
Jun 13 16:12:06 <zeddii> aha. pkg already staged error.
Jun 13 16:12:11 <zeddii> hmm.
Jun 13 16:15:36 <zeddii> so very strange. I have no idea why it partially staged that file. oh well.
Jun 13 16:18:18 <fray> bruce, still looking..
Jun 13 16:18:23 <fray> ya, I'm wondering if that is the real error
Jun 13 16:19:26 <fray> ya.. it's saying it's already been copied to the sstate.. thats odd
Jun 13 16:19:39 <fray> md5sum collision?
Jun 13 16:20:30 <zeddii> hmm. could be. I've got about 4 kernels building at the same time. I diff'd my 3.2 and 3.4 -rt recipes. the only difference is s/3.2/3.4/
Jun 13 16:21:09 <zeddii> I did get a strange error when I was using ipk packaging. maybe that's the real issue. I'll switch back to that and see.
Jun 13 16:21:40 <fray> could be
Jun 13 16:22:07 * zeddii wait for rpm to complete his latest run.
Jun 13 16:22:27 <zeddii> ok. fray. why would it do this.
Jun 13 16:22:51 <fray> no idea
Jun 13 16:22:55 <zeddii> bitbake linux-yocto-rt ... completes NOTE: Tasks Summary: Attempted 1059 tasks of which 1056 didn't need to be rerun and all succeeded.
Jun 13 16:22:59 <zeddii> so it worked.
Jun 13 16:23:01 <zeddii> no errors.
Jun 13 16:23:10 <zeddii> I rerun that command
Jun 13 16:23:15 <zeddii> why does it start re-packaging it ?
Jun 13 16:23:24 <zeddii> it then blows up on the already staged kernel.
Jun 13 16:23:59 <fray> no idea.. sorry
Jun 13 16:24:34 <zeddii> as long as I didn't break it .. I can ignore it for now. I'm reasonably sure that 3.4 -rt didn't cause this.
Jun 13 16:42:41 <khem> zeddii: I implanted my two patches onto to 3.4 for now
Jun 13 16:42:48 <khem> lets see if it builds and boots
Jun 13 16:43:56 <khem> hmmmm, I wonder if it would make sense to create a layer for secondary qemu machines
Jun 13 16:46:49 <RP__> zeddii: FWIW, I suspect some revision is floating somewhere and causing chaos
Jun 13 16:47:16 <RP__> zeddii: or there is some other element creeping in and confusing bitbake/stamps/caches :/
Jun 13 16:48:50 <zeddii> RP__, could be. I was seeing this yesterday, and then this morning rm -rf'd tmp and sstate. when it happened again .. I finally got concerned.
Jun 13 16:51:02 * zeddii cleans sstate and launches again.
Jun 13 17:12:57 <zeddii> RP__, after my cleansstate .. it repacked with ipk. I'll keep watching for it to debug further. very strange.
Jun 13 17:45:11 <RP__> zeddii: strange indeed :/
Jun 13 19:41:41 <challinan> howdy folks. getting errors spawning any task requiring a terminal (menuconfig, devshell, etc.) via ssh -X
Jun 13 19:41:44 <challinan> ERROR: Unable to spawn terminal auto: Execution of 'gnome-terminal --disable-factory -t "OpenEmbedded Developer Shell" -x /bin/bash' failed with exit code 1:
Jun 13 19:41:44 <challinan> Xlib:  extension "RANDR" missing on display "localhost:10.0".
Jun 13 19:41:44 <challinan> Failed to summon the GConf demon; exiting.  Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See http://projects.gnome.org/gconf/ for information. (Details -  1: Failed to get connection to session: /bin/dbus-launch terminated abnormally with the following error: Autolaunch requested, but X
Jun 13 19:41:45 <challinan> 11 support not compiled in.
Jun 13 19:41:49 <challinan> Cannot continue.
Jun 13 19:41:51 <challinan> )
Jun 13 19:41:53 <challinan> ERROR: Function failed: do_devshell
Jun 13 19:41:55 <challinan> ERROR: Logfile of failure stored in: /scratch/working/build_mx53qsb/tmp/work/imx53qsb-poky-linux-gnueabi/linux-imx-2.6.35.3-r21/temp/log.do_devshell.20504
Jun 13 19:41:58 <challinan> NOTE: package linux-imx-2.6.35.3-r21: task do_devshell: Failed
Jun 13 19:42:00 <challinan> ERROR: Task 3 (/scratch/yocto/meta-fsl-arm/recipes-kernel/linux/linux-imx_2.6.35.3.bb, do_devshell) failed with exit code '1'
Jun 13 19:42:03 <challinan> arg, sorry, clipboard contents wrong :(
Jun 13 19:42:55 <challinan> with OE_TERMINAL set to "auto" it fails, but succeeds with "xterm"
Jun 13 19:43:24 * challinan had meant to pastebin that error message, not here on #yocto
Jun 13 21:51:50 <jrw> challinan: That is because there is only a primative check to see if it should try the next terminal type.
Jun 13 21:52:25 <jrw> I had proposed a bitbake patch to allow you to set the preference list to something else.
Jun 13 21:52:54 <challinan> I can execute the gnome-terminal command from the remote X (ssh) term, in the same way bitbake does and it works
Jun 13 21:53:10 * challinan wonders why it doesn't work when bitbake issues the command itself
Jun 13 21:53:27 <jrw> That does seem kind of odd.
Jun 13 21:53:30 <challinan> indeed
Jun 13 21:53:49 <jrw> Is there a dbus env var that is not set?
Jun 13 21:53:50 <fray> bitbake sanitizes the environment.. and then when (in OE) it calls for a terminal or something, it selectively restores part of the environment
Jun 13 21:53:58 <fray> it could be this select restore isn't happening?
Jun 13 21:54:24 <jrw> I have had to muck with the restore to get screen to work properly and this perhaps sounds like another instance of the same problem.
Jun 13 21:54:35 * mranostay pokes in
Jun 13 21:54:38 <challinan> fray: must be
Jun 13 21:54:48 <jrw> The easiest way to debug it is env |sort -u > file in your ssh session.
Jun 13 21:54:51 <bluelightning> I'm sure someone else reported that gnome-terminal wasn't working in this manner recently
Jun 13 21:55:07 <jrw> OE_TERMINAL=xterm bitbake -c devshell your_cmd
Jun 13 21:55:12 <challinan> hi mranostay!
Jun 13 21:55:15 <jrw> env |sort -u > file2
Jun 13 21:55:25 <jrw> diff -u file file2
Jun 13 21:55:42 <challinan> jrw: setting OE_TERMINAL=xterm works, as I stated above
Jun 13 21:55:51 <challinan> ah
Jun 13 21:55:54 <jrw> Yes, but you need to collect the ENV.
Jun 13 21:56:00 <challinan> yup, sorry
Jun 13 21:56:04 <jrw> To compare what is completely different :-)
Jun 13 21:56:25 <jrw> My initial guess was some dbus or gnome-session daemon key.
Jun 13 21:56:56 <challinan> i'll try it later, that machine is tied up atm
Jun 13 21:58:03 <mranostay> hey challinan
Jun 13 21:58:18 <challinan> hey, how's life in SF?
Jun 13 22:41:06 <khem> challinan: life is busy, I drove to SF and took me ages to come back to home, I live 40 miles south :)
Jun 13 22:43:19 <mranostay> challinan: busy mostly
Jun 13 22:44:28 <challinan> i'd like to come to SF again - it was fun riding the train, pitchers of margaritas, etc ;)
Jun 13 22:44:31 <challinan> that was a fun day
Jun 13 22:45:08 <reanguiano> Caltrain is often the only sane way to make it up the peninsula into SF.
Jun 13 22:45:21 <mranostay> yeah i hate driving in SF
Jun 13 22:45:44 <mranostay> only drive when it something near Route 1 which isn't too bad
Jun 13 22:46:31 <challinan> yeah, reanguiano, esp when you are consuming margaritas by the pitcher ;)
Jun 13 22:46:42 * challinan goes off to dinner
Jun 13 22:46:52 <reanguiano> Cabs and trains.
Jun 13 23:19:58 <khem> zeddii: so I cloned 3.4 and applied two patches I needed and it works as expected for mips64 now
Jun 13 23:20:55 <khem> one patch disables oprofile in kernel and another one CONFIG_MTD_CFI
Jun 13 23:21:41 <khem> somehow it CFI gets me into infinite loops its accessing my hosts SSD
Jun 13 23:22:17 <khem> Both features I can live without for now
Jun 13 23:24:38 <khem> RP__: btw. gcc 4.7.1 is coming up
Jun 13 23:24:46 <khem> I am already testing a RC locally
Jun 13 23:24:54 <khem> heads up
Jun 13 23:34:23 <sgw> khem: autoconf and site file question, where's the right place to put a path item in the recipe or site/... file?
Jun 13 23:34:55 <khem> is it a autoconf cached variable ?
Jun 13 23:35:04 <khem> something liek ac..
Jun 13 23:35:05 <sgw> yes it can be
Jun 13 23:35:29 <khem> recipe is right place
Jun 13 23:35:31 <sgw> khem ac_cv_path_BASH in quilt and ac_cv_path_KSH  ac_cv_path_BASH_SHELL in eglibc
Jun 13 23:36:03 <sgw> khem: so in the EXTRA_OECONF, correct?
Jun 13 23:36:15 <khem> if we put this in site files they become globally available to all
Jun 13 23:37:03 <khem> you can put it in CACHED_CONFIGUREVARS
Jun 13 23:37:20 <khem> CACHED_CONFIGUREVARS = "ac_cv_path_KSH=..."
Jun 13 23:37:24 <khem> in recipe
Jun 13 23:37:47 <sgw> ah that's a new one, will use it instead!  Thanks
Jun 13 23:37:59 <khem> k
Jun 14 02:21:14 <mebrown> I have a (hopefully) simple question: All of our recipes need to be able to be built in either "debug" or "release" modes to enable or disable certain debugging. Typically this involves switching around cflags/ldflags. Anybody have ideas on how to usefully build single components in one or the other mode?
Jun 14 02:21:39 <mebrown> Most developers will want to build the entire tree in 'release' mode and then just build one recipe in debug mode.
**** ENDING LOGGING AT Thu Jun 14 02:59:58 2012

**** BEGIN LOGGING AT Thu Jun 14 02:59:58 2012
Jun 14 05:43:48 <moolinex> morning
Jun 14 15:04:41 <gungfuwayne> howdy folks
Jun 14 15:05:23 <gungfuwayne> i am curious--does anyone know of any python3 recipes being worked on?
Jun 14 15:23:32 <jwessel> RP__: I would be interested to understand how you want to address the PRE-MIRROR git archive problem.  I was limited in the available options due to the way someone stacked on the mirror tar ball "stuff" from git.py
Jun 14 15:24:35 <jwessel> Ideally I would have liked to be able to prefer the search for a local git tree and fall back to the tar.gz version, but the rule syntax for fetcher doesn't allow you to do anything like that on a single line.
Jun 14 15:25:09 <jwessel> This is the result of moving away from GITDIR and over to trying to use PREMIRROR and keep bare clones with multiple sets of branches that are regularly updated etc...
Jun 14 15:36:51 <RP__> jwessel: We need to change the behaviour of some of that code significantly
Jun 14 15:37:07 <RP__> jwessel: Your patch fixes some use cases at the expense of breaking other things :(
Jun 14 15:38:30 <jwessel> I am exactly certain what would have broken given that the change "adds" a new type of PREMIRROR.
Jun 14 15:38:43 <jwessel> Rather I am not certain what use case would have broken.
Jun 14 15:39:11 <jwessel> I would like to understand what problem I "traded into".
Jun 14 17:01:49 <RP__> jwessel: sorry, have been pulled into meetings etc. I'm working on exploring the problems here...
Jun 14 17:02:10 <RP__> jwessel: first step likely needs to be better enhance the test suite
Jun 14 18:26:49 <jwessel> RP__: There is a test suite?
Jun 14 18:27:00 <jwessel> Are there details how to run it?
Jun 14 18:28:01 <jwessel> I would certainly run things like that first prior to submitting further patches for 2 reasons.   1) I don't like to break things  2) The tests often offer a great deal of clues about how the system was actually intended to work.
Jun 14 18:31:11 <RP__> jwessel: "bitbake-selftest", its new and a work in progress though
Jun 14 18:49:25 * jwessel goes to see if it passes without changes first
Jun 14 18:51:17 <jwessel> Is there any verbose mode?
Jun 14 18:52:40 <jwessel> Ran 79 tests in 10.303s
Jun 14 18:53:09 <jwessel> RP__: Even with all my patches applied there are no failures, so I am still really curious about what the PREMIRROR patch broke.
Jun 14 18:53:38 <RP__> jwessel: the test suite doesn't test that area of functionality, I said it was limited
Jun 14 20:10:52 <challinan> if SRC_URI specifies git://, why is do_fetch using wget (ftp) to d/l a linux-yocto tarball? (MACHINE=mpc8315e-rdb)
Jun 14 20:13:45 <jwessel> challinan: Probably because of PREMIRROR redefining stuff.
Jun 14 20:14:03 <challinan> hmm, interesting
Jun 14 20:14:22 <jwessel> But it really depends on if you have a rule that re-writes things.
Jun 14 20:15:11 <jwessel> I am debugging something right now with respect to making local git archives work thanks to the wise words from RP, who explained how the PREMIRROR re-writes actually work.
Jun 14 20:16:08 <challinan> the other curiousity (annoyance ;)) is that the d/l happens every time, ie. doesn't seem to ever recognize the copy in DL_DIR
Jun 14 20:16:30 <jwessel> That certainly sounds like a bug.
Jun 14 21:24:47 <khem> challinan: do you have AUTOREV ?
Jun 14 21:27:38 <challinan> khem: no, i don't believe so
Jun 14 21:28:11 <challinan> at least, I didn't do anything to enable it
Jun 14 21:28:33 <khem> hmmm there is a bug in fetcher code where if you have special characters like + in tar name then it goofs it up
Jun 14 21:28:34 <challinan> SRCREV="INVALID" in my env
Jun 14 21:39:20 <jwessel> This was fixed in the master branch this morning.
Jun 14 21:39:40 <jwessel> khem: Perhaps you just need to pull again?
Jun 14 21:46:24 <khem> jwessel: oh is it in one of your patches ?
Jun 14 21:46:31 <jwessel> No.
Jun 14 21:46:34 <khem> it was filed as PR
Jun 14 21:46:35 <khem> ok
Jun 14 21:46:45 <jwessel> Richard rejected one of mine and put something else almost the same in.
Jun 14 21:46:46 <khem> I havent groked my emails today
Jun 14 21:46:53 <khem> k
Jun 14 21:47:08 <jwessel> commit 95c0595d66b3f8a5f0716662ba2a878600f312ea
Jun 14 21:47:10 <jwessel>     fetch2/local: Ensure quoting is handled correctly from the url
Jun 14 21:47:30 <jwessel> That in bitbake itself.  If you are based of poky, it is obviously different.
Jun 14 21:47:51 <jwessel>     [YOCTO #2558]
Jun 14 21:48:23 <khem> good.
Jun 14 21:48:35 <khem> so I wonder if challinan has this fix
Jun 14 22:55:21 <chackal_sjc> how can i use variables from the system environment?
Jun 14 23:16:08 <kb> Hi, I get dependency failure | Processing rpm... | error: Failed dependencies: |       libm.so.6(GLIBC_2.15) is needed by libwsbm1-1.0-r2.2.core2 NOTE: package core-image-sato-1.0-r0: task do_rootfs: Failed
Jun 14 23:16:26 <kb> how do I add the libm.so dependency?
Jun 15 00:03:52 <squirly> I am compiling a distro for my hardware using DEBs for my package management. In package_deb.bbclass I need DPKG_ARCH = "armel" instead of TARGET_ARCH (which is "arm"). When I run dpkg on my device armel is the architecture, not arm, but yocto wants my TARGET_ARCH to be set to "arm". Is there a non hackish way to do this?
Jun 15 00:57:13 <seebs> So, that variable tracking stuff -- was there something else I needed to do to nudge it towards upstream acceptance?  Is it already included and I'm just cleverly failing to spot it?
**** ENDING LOGGING AT Fri Jun 15 02:59:59 2012

**** BEGIN LOGGING AT Fri Jun 15 02:59:59 2012
Jun 15 03:06:20 <khem> squirly set DPKG_ARCH = "armel" in your local.conf
Jun 15 09:34:42 <bluelightning> morning all
Jun 15 13:36:46 <otavio> RP__: You missed the PR bump in openjade-native; sorry by didn't catch it before
Jun 15 13:45:28 <jwessel> Is there any way to compile a single package without optimization?  The docs don't seem to indicate that this is possible.
Jun 15 13:45:58 <jwessel> The DEBUG_BUILD = "1" is fine for doing everything, but I want to turn it on for just a specific package, such as "popt" for example.
Jun 15 13:46:40 <jwessel> fray told me you could do something like: DEBUG_BUILD_popt = "1"
Jun 15 13:46:50 <jwessel> But this doesn't seem to work.
Jun 15 13:59:25 <RP__> jwessel: DEBUG_BUILD_pn-xxx = "1" ?
Jun 15 13:59:38 <RP__> jwessel: The pn- is important
Jun 15 14:08:56 <jwessel> So it should be DEBUG_BUILD_pn-popt = "1" ?
Jun 15 14:09:04 * jwessel goes to try.
Jun 15 14:15:34 <jwessel> That is amazing, no wonder I couldn't find it.  It isn't documented anywhere.
Jun 15 14:16:02 <jwessel> RP__: Are there other variables that make use of the VARNAME_pn-xxx syntax?
Jun 15 14:16:35 <jwessel> There were exactly 2 hits on a goggle for DEBUG_BUILD_pn, so clearly people must not do it too often :-)
Jun 15 14:17:04 <jwessel> I'd like to update the yocto user guide.  I already updated our internal documentation, but that doesn't help the community too much.
Jun 15 14:18:03 <RP__> jwessel: *any* variable can use that syntax, its an override
Jun 15 14:18:14 * jwessel wonders how to submit a change to the html docs.
Jun 15 14:18:29 <RP__> jwessel: Look at the documentation repository
Jun 15 14:18:45 <RP__> jwessel: bitbake -e  | grep OVERRIDES
Jun 15 14:19:10 <RP__> jwessel: Those are the various modifiers you can use, you'll see pn-${PN} is one of them
Jun 15 14:19:48 <jwessel> OVERRIDES is also not documented in the dev-manual.html.
Jun 15 14:20:05 <jwessel> Is the documentation repository a git tree somewhere?
Jun 15 14:20:07 <RP__> jwessel: it is in the bitbake manual at least
Jun 15 14:20:30 <RP__> jwessel: http://git.yoctoproject.org/cgit.cgi/yocto-docs/
Jun 15 14:21:36 <jwessel> RP__: Apologies for all the newbie questions.  :-)    I do want to improve the docs a bit here and there because some of this feels very much like it should be rtfm material.
Jun 15 14:21:57 <RP__> jwessel: I think these are good questions and expose some bug gaps in the manuals
Jun 15 14:22:06 <RP__> er, big gaps
Jun 15 14:22:57 <jwessel> Eventually I'll be able to port an LDAT layer to bitbake and have a guide for that too, but I had found so far, that every time I try I end up with a newbie question :-)
Jun 15 14:23:36 <jwessel> heh... It would be cool to also add a pointer in the docs to the doc repo ;-)
Jun 15 14:23:36 <bluelightning> yeah that's a pretty big gap not documenting OVERRIDES :(
Jun 15 14:23:52 <bluelightning> I was sure we covered that in the poky ref manual at some point
Jun 15 14:50:59 <jwessel> Thanks for the pointer to the doc repo.   I started writing a new section in the development guide which will cover in more detail the DEBUG_BUILD variable and how to use it per package now that I have working examples.
Jun 15 14:51:23 <jwessel> Of course, it might be a few weeks yet before I finalize the changes because I have a pile of other use cases to work through.
Jun 15 15:38:19 <RP__> jwessel: scott rifenbark likes doc patches :)
Jun 15 16:19:57 <fray> I'm getting a very odd error..
Jun 15 16:20:11 <fray> In master, I'm trying to enble "lua" functionality in the rpm-native.. so I added a bbappend:
Jun 15 16:20:16 <fray> PACKAGECONFIG_append_virtclass-native += "lua"
Jun 15 16:20:21 <fray> and I'm getting python parse errors..
Jun 15 16:35:45 <seebs> Where are you getting them?  I had some recently that turned out to be a typo causing me to try to expand an unset variable in some context where this resulted in confusion.
Jun 15 18:06:10 <khem> fray: PACKAGECONFIG_append_virtclass-native += "lua"
Jun 15 18:06:26 <khem> there is _append and += at same time
Jun 15 18:06:31 <khem> is that really what you want
Jun 15 18:34:18 <jwessel> I don't know if it is what he wants, but without the += you have to do:
Jun 15 18:34:28 <jwessel> PACKAGECONFIG_append_virtclass-native = " lua"
Jun 15 18:34:35 <jwessel> Note the difference of 1 space
Jun 15 18:34:39 <jwessel> before lua
Jun 15 20:28:56 <halstead> I am taking bugzilla offline for about 5 minutes while we update are classifications.
Jun 15 20:41:30 <halstead> Beginning now...
Jun 15 20:48:48 <halstead> Completed and we are back online.
Jun 15 21:23:39 <fray> khem/jwessel..  either += or = causes the same errors..
Jun 15 21:23:42 <fray> I'm confused..
Jun 15 21:23:49 <fray> (sorry ahd to go, back now though)
Jun 15 23:06:55 <khem> zeddii: around ?
**** ENDING LOGGING AT Sat Jun 16 02:59:58 2012

**** BEGIN LOGGING AT Sat Jun 16 02:59:59 2012
Jun 16 10:19:37 * RP__ wonders how on earth he's managed to sprain a finger like this. Rules out most of what I wanted to do today :(
Jun 16 12:28:31 <Crofton|work> RP__, fall of the bike again?
Jun 16 12:38:50 <otavio> Hello; I am building a image, ext4, and the image doesn't extend to the partition size of the sdcard when I write it there ...
Jun 16 12:39:03 <otavio> how people handle it?
Jun 16 14:07:45 <m4t> hi, i've hit a circular dependency when doing a uclibc build...
Jun 16 14:07:51 <m4t> glib depends on libiconv, which depends on pkgconfig, which depends on glib
Jun 16 14:08:01 <m4t> any known workaround?
Jun 16 16:10:13 <khem> m4t: hmmm
Jun 16 16:10:52 <m4t> hey khem
Jun 16 16:11:17 <khem> m4t: I dont see problems like that
Jun 16 16:11:32 <khem> what specific errors do u run into
Jun 16 16:11:42 <m4t> glib needs iconv
Jun 16 16:11:47 <m4t> iconv needs pkgconfig
Jun 16 16:11:54 <m4t> pkgconfig needs glib
Jun 16 16:12:09 <khem> is that what you see or what you interpret
Jun 16 16:12:13 <m4t> what i see
Jun 16 16:12:24 <m4t> when i try to build iconv, glib is built first
Jun 16 16:12:38 <m4t> well
Jun 16 16:12:56 <m4t> bitbake -n shows that order
Jun 16 16:13:17 <m4t> and it is always failing with glib missing iconv
Jun 16 16:13:30 <m4t> but trying to build virtual/libiconv tries to build glib
Jun 16 16:14:26 <m4t> it makes my head spin
Jun 16 16:15:29 <m4t> so i brought the no-iconv.patch back into my layer
Jun 16 16:15:46 <m4t> hopefully it applies , im getting there in the build now...
Jun 16 16:15:50 <m4t> within 5min i will see :)
Jun 16 16:15:52 <khem> that patch is wrong though
Jun 16 16:16:24 <khem> what image do you build
Jun 16 16:16:31 <m4t> systemd-image, console-image
Jun 16 16:18:57 <khem> oh, angstrom
Jun 16 16:19:29 <m4t> yep
**** ENDING LOGGING AT Sun Jun 17 02:59:59 2012

**** BEGIN LOGGING AT Sun Jun 17 02:59:59 2012
**** ENDING LOGGING AT Mon Jun 18 02:59:58 2012

**** BEGIN LOGGING AT Mon Jun 18 02:59:58 2012
Jun 18 08:54:14 <exosyst> hey guys - is there a quick conf option to setup an atom yocto build for NFS rather than an initrd that wants the iso?
Jun 18 09:14:20 <Zagor> wants the iso?
Jun 18 10:46:05 <bluelightning> hi all
Jun 18 11:57:45 <Zagor> RP__: thank you for the feedback. I was starting to wonder if nobody else felt this is interesting at all :-)
Jun 18 12:01:50 <RP__> Zagor: I for one would love to see it. It just got lost in too many emails in my inbox :(
Jun 18 12:06:34 <Zagor> yeah, I can imagine.
Jun 18 17:20:30 <dvhart> bluelightning, ping, you around?
Jun 18 17:20:40 <dvhart> khem, ping as well
Jun 18 17:20:54 <bluelightning> dvhart: pong
Jun 18 17:20:59 <dvhart> I'm looking into how to get a busybox config just for poky-tiny that doesn't override things if poky is chosen
Jun 18 17:21:08 <dvhart> without needing to put tiny in a new layer
Jun 18 17:21:26 <dvhart> I'm not sure how to go about a conditional defconfig override based on distro
Jun 18 17:21:36 <dvhart> is there a standard procedure here?
Jun 18 17:21:39 <bluelightning> dvhart: actually it should be pretty easy
Jun 18 17:22:13 <dvhart> bluelightning, I'm trying to narrow down which mechanisms to use
Jun 18 17:22:26 <bluelightning> dvhart: you should be able to add a bbappend that adds the path in the traditional manner, then add (subdir)/poky-tiny/defconfig
Jun 18 17:22:26 <dvhart> I could bbappend with a do_configure_append and use the DISTRO_FEATURE mechanism
Jun 18 17:22:51 <bluelightning> (where (subdir) is whatever subdir you added within the bbappend, e.g. files or ${PN}
Jun 18 17:22:53 <dvhart> ok, so bitbake will treat DISTRO like MACHINE when searching for files?
Jun 18 17:23:02 <bluelightning> yep, anything in OVERRIDES
Jun 18 17:23:22 <bluelightning> even forcevariable ;)
Jun 18 17:24:10 <dvhart> ah excellent
Jun 18 17:24:20 <dvhart> I didn't know about the OVERRIDES thing
Jun 18 17:24:22 <dvhart> very helpful
Jun 18 17:24:26 <dvhart> that's super easy then
Jun 18 17:24:48 <bluelightning> yeah I discovered to my horror we don't have OVERRIDES explicitly documented anywhere
Jun 18 17:24:59 <bluelightning> I need to get the appropriate info to Scott
Jun 18 17:25:03 <bluelightning> (R)
Jun 18 17:26:23 <dvhart> :-)
Jun 18 17:26:31 <dvhart> thanks Paul!
Jun 18 17:26:40 <dvhart> saved me a ton of time
Jun 18 17:26:47 <dvhart> exploring the wrong paths
Jun 18 17:27:38 <dvhart> hrm... now that I think about it
Jun 18 17:27:49 <dvhart> I wonder if I would be better off with a configure_append in the bbappend
Jun 18 17:27:59 <dvhart> so that all I do is ADD the two options I care about
Jun 18 17:28:12 <dvhart> rather than duplicate the defconfig and have it get out of sync
Jun 18 17:28:37 <dvhart> then again, this is a good opportunity to gut the busybox config...
Jun 18 17:29:49 <bluelightning> right, yes
Jun 18 17:30:01 <bluelightning> I guess it would be easier with config fragment support....
Jun 18 17:36:32 <dvhart> bluelightning, it would :-)
Jun 18 17:36:38 <dvhart> that needs to happen, but not right now
Jun 18 17:36:43 <dvhart> will just do the defconfig for now
Jun 18 17:45:48 <khem> dvhart: I guess you and bluelightning sorted it out already
Jun 18 17:50:45 <dvhart> I think so
Jun 18 17:51:16 <dvhart> trying to debug why it isn't using the new defconfig now...
Jun 18 17:52:46 <khem> dvhart: bitbake -e is your friend
Jun 18 17:53:06 <dvhart> I was grepping through -DDD atm, will do -e next
Jun 18 17:53:12 <khem> either your override is not in effect or bbpath is not ok
Jun 18 17:58:23 <bluelightning> dvhart: what does the bbappend contain and what's the dir structure you have?
Jun 18 17:59:07 <dvhart> meta-yocto/recipes-core [dvhart/tiny *+]
Jun 18 17:59:07 <dvhart> $ tree busybox/
Jun 18 17:59:07 <dvhart> busybox/
Jun 18 17:59:07 <dvhart> ??? busybox-1.19.4
Jun 18 17:59:07 <dvhart> ?   ??? poky-tiny
Jun 18 17:59:07 <dvhart> ?       ??? defconfig
Jun 18 17:59:09 <dvhart> ??? busybox_1.19.4.bbappend
Jun 18 17:59:24 <dvhart> $ cat busybox_1.19.4.bbappend
Jun 18 17:59:24 <dvhart> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
Jun 18 17:59:37 <bluelightning> ah right, there's your problem
Jun 18 18:00:10 <dvhart> OVERRIDES does include poky-tiny
Jun 18 18:00:14 <dvhart> oh? what did I miss?
Jun 18 18:00:18 <bluelightning> the subdir is called "busybox-1.19.4" but you've added "${PN}" to the path
Jun 18 18:00:31 <bluelightning> just rename that dir to busybox and it should work
Jun 18 18:01:48 <dvhart> ok, I'd prefer to keep the defconfig paired with version
Jun 18 18:01:55 <dvhart> do I need a PV in there?
Jun 18 18:02:07 <bluelightning> ok you could change it to add "${PN}-${PV}" instead in that case
Jun 18 18:02:23 <bluelightning> it will be paired with the version by virtue of the bbappend file naming though
Jun 18 18:03:01 <bluelightning> (unless of course you ended up with two versions you needed to bbappend in this layer)
Jun 18 18:03:05 <dvhart> right
Jun 18 18:03:28 <dvhart> this layout matches what the oe-core recipe does
Jun 18 18:03:37 <dvhart> thought I should keep it consistent
Jun 18 18:03:59 <khem> or you can make FILESEXTRAPATHS_prepend := "${THISDIR}/${P}:"
Jun 18 18:04:22 <khem> P = PN-PV
Jun 18 18:05:01 <bluelightning> yep that's equivalent, possibly neater
Jun 18 18:05:10 <dvhart> khem, better
Jun 18 18:05:11 <dvhart> thanks
Jun 18 18:06:23 <dvhart> so I didn't see the bbappend even mentioned in the -DDD log
Jun 18 18:06:48 <bluelightning> sometimes I wonder if we could make this easier to debug... I added a bbappend to meta-yocto that was wrong in this way and it was in there for ages before anyone noticed and fixed it...
Jun 18 18:06:53 <dvhart> would have been good to see something about it being parsed, and not files being found... something.
Jun 18 18:07:37 <bluelightning> it's a bit tricky, but I'll have a think about how we could improve it
Jun 18 18:07:41 <dvhart> I need to talk to Scott on this too and see how we're doing on bbappend documentation
Jun 18 18:07:49 <dvhart> (R)
Jun 18 18:07:50 <dvhart> ;)
Jun 18 18:07:54 <bluelightning> :)
Jun 18 18:09:18 <dvhart> ok, perfect, poky-tiny booted in qemu with setsid and cttyhack present
Jun 18 18:09:23 <dvhart> many thanks guys!
Jun 18 18:10:51 <khem> bluelightning: bitbake layering tool should be right place for this kind of stuff
Jun 18 18:18:26 <bluelightning> dvhart: np
Jun 18 18:18:45 <bluelightning> khem: yeah; it might also involve some additional debug output as darren was suggesting
Jun 18 18:20:47 <seebs> So, idle question.  For sound technical reasons beyond my control, we have a tuning for which we have prebuilt binaries, which is basically an armv7a with no FPU instructions.  I have been looking at the arm tunings, and it seems to me that "armv7a" already implies VFP in Yocto.
Jun 18 18:21:20 <seebs> So I am going to be making, for our system, a tuning which does not imply VFP.  I'm not sure what to call this; should I just call it -nf, as is done with other targets where the FPU is implicit?
Jun 18 18:23:49 <fray> -nvfp would be fine
Jun 18 18:26:17 <seebs> Hmm.  I like that.
Jun 18 18:27:00 <sgw> RP__: I am trying to use oe_filter_out on FILES_${PN}_doc to remove a certain item, but it does not seem to work well , this is back to the _subtract / _remove issue!
Jun 18 18:27:03 <seebs> I once told a friend of mine that we have a pair of sysroots, a default and one called "soft-float".  The distinction being that the latter uses a hardware FPU.
Jun 18 18:27:40 <seebs> Trying to explain how this was not, in fact, the result of cutting crack with whatever powders could be found in the cleaning supplies cabinet was a delightful experience.
Jun 18 18:28:49 <fray> the key thing is that it's an ABI specification, which implies the VFP implementation..
Jun 18 18:28:50 <fray> :)
Jun 18 18:29:14 <fray> soft - no FP.. softfp - VFP, but register passing through ARM, and hardfp - VFP and register passing through VFP
Jun 18 18:29:29 <fray> sneaky.. but it kind of makes sense.. in a warped way
Jun 18 18:33:21 <sgw> fray: have you had a chance to look at my latest PACKAGE reorder stuff?  I think this first pass is ready to go.
Jun 18 18:33:39 <fray> I haven't.. sorry was it sent to oe-core or?
Jun 18 18:33:59 <sgw> oe-core last week, I have a summary and a buildhistory_diff file attached.
Jun 18 18:34:26 <fray> whats the topic.. I archived my oe-core this weekend.. so I need to search for it
Jun 18 18:34:35 <sgw> I guess in all fairness I sent friday afternoon ;-)
Jun 18 18:34:42 <sgw> [OE-core] PACKAGE List reorder Update
Jun 18 18:35:20 <fray> found it.. I'll look it over
Jun 18 18:38:59 <fray> sgw - curl-dev, what is in it? just curl-config or other stuff?
Jun 18 18:39:26 <sgw> I am reviewing that one right now!  curl-config should move back to libcurl-dev
Jun 18 18:39:47 <fray> ok.. abovue 1/3 of the way through the lsit and so far that was my only issue
Jun 18 18:40:30 <fray> grub-doc  locale files.. shouldn't through be automagically broken into "locale-*" packages by OE?
Jun 18 18:41:07 <sgw> actually I think curl has been packaged wrong all along because it had been a "+=" so the curl-dev contained things that should have been in libcurl!
Jun 18 18:41:33 <sgw> fray: regarding grub, I was wondering about that also, need to see why that's not happening
Jun 18 18:41:38 <fray> gotcha
Jun 18 18:42:29 <fray> eveyrthing else in the initial description looks fine
Jun 18 18:43:11 <fray> (and it's nice to find and fix a number of these.. it should reduce the image size)
Jun 18 18:43:41 <fray> any idea on this:
Jun 18 18:43:41 <fray> packages/i586-poky-linux/grub/grub-dbg: RRECOMMENDS: removed "liblzma-dbg"
Jun 18 18:43:41 <fray> packages/i586-poky-linux/grub/grub-dev: RRECOMMENDS: removed "liblzma-dev"
Jun 18 18:44:40 <fray> (and grub also removed liblzma)
Jun 18 18:45:30 <fray> packages/i586-poky-linux/libsamplerate0/libsamplerate0-dbg: RRECOMMENDS: removed "libsndfile1-dbg"
Jun 18 18:45:30 <fray> packages/i586-poky-linux/libsamplerate0/libsamplerate0-dev: RRECOMMENDS: removed "libsndfile1-dev"
Jun 18 18:45:30 <fray> packages/i586-poky-linux/libsamplerate0/libsamplerate0: RDEPENDS: removed "libsndfile1 (>= 1.0.25)"
Jun 18 18:46:23 <fray> quota has a new dependency as well
Jun 18 18:46:51 <fray> as does sudo, and x11vnc
Jun 18 18:46:56 <fray> wget had some removed..
Jun 18 18:47:02 <fray> I'm wondering if these are build order issues
Jun 18 18:48:04 <fray> (if those are build ordering, I'd suggest janitor debugs be opened) otherwise it looks fine
Jun 18 18:48:08 <sgw> Right those I am still trying to figure out, I also had an issue building the image with libevent and crypto and libssl
Jun 18 18:48:45 <sgw> fray: Failed dependencies:
Jun 18 18:48:45 <sgw> |       libcrypto >= 1.0.0i is needed by libevent-2.0.16-r1.i586
Jun 18 18:48:45 <sgw> |       libssl >= 1.0.0i is needed by libevent-2.0.16-r1.i586
Jun 18 18:49:04 <fray> ya.. I'd suspect build order or lack of build-time dep..
Jun 18 18:49:18 <fray> my -guess- is that adding an openssl dep is needed -or- a --without-ssl
Jun 18 18:49:54 <sgw> Yeah, was going to look at that
Jun 18 18:59:15 <sgw> fray: what's strange looking at grub and lzma, it's included in the config.log and in the pkgdata/runtime/grub
Jun 18 21:09:55 <khem> zeddii: I got a question about fragments
Jun 18 21:10:24 <khem> zeddii: I know with fragments I can add features to kernel but is it possible to delete features as well ?
Jun 18 21:10:59 <khem> zeddii: with delete I mean say the defconfig of a given machine contains an option and is it possible for me to delete it using frags
Jun 18 21:47:52 <RP__> sgw: oe_filter_out is basically horrible for this reason
Jun 18 21:59:59 <ant__> khem: you can force a new value using frags
Jun 18 22:01:06 <khem> ant__: even for say I get CONFIG_FOO = y
Jun 18 22:01:20 <khem> and now I want to make it # CONFIG_FOO is not set
Jun 18 22:01:43 <khem> enenenabling bits is clear
Jun 18 22:01:52 <ant__> let me see the logs a mom
Jun 18 22:02:39 <ant__> hm.. rm_work :/
Jun 18 22:02:44 <ant__> though, I get
Jun 18 22:02:46 <ant__> There were 5 required kernel config options redefined (and changed)
Jun 18 22:03:28 <ant__> the list is in workdir  linux /meta/cfg/standard/tiny/required_redefinition.txt
Jun 18 22:03:41 <ant__> let me launch a partial build
Jun 18 22:06:06 <khem> redefinition.txt is promising
Jun 18 22:13:14 <ant__> yes
Jun 18 22:13:16 <ant__> bingo
Jun 18 22:13:18 <ant__> Previous value: CONFIG_PRINTK=y
Jun 18 22:13:18 <ant__> New value: # CONFIG_PRINTK is not set
Jun 18 22:13:32 <khem> ok where did you make that change ?
Jun 18 22:13:37 <khem> thats what I am interested in
Jun 18 22:13:44 <ant__> mom
Jun 18 22:13:46 <khem> e.g. I was to disable CONFIG_MINIX_FS=m
Jun 18 22:13:58 <khem> its coming from ./cfg/kernel-cache/ktypes/standard/standard.cfg.sanitized
Jun 18 22:14:01 <ant__> in the defconfig, now renamed
Jun 18 22:14:22 <khem> I am talking about yocto-kernel's way of doing it
Jun 18 22:14:31 <khem> I can  muck with defconfig I know
Jun 18 22:14:33 <ant__> yes, abusing of it
Jun 18 22:14:49 <khem> thats not what I want
Jun 18 22:14:58 <ant__> http://cgit.openembedded.org/meta-handheld/tree/recipes-kernel/linux/linux-yocto-tiny-kexecboot_3.2.bbappend
Jun 18 22:15:18 <ant__> it is an .scc by now
Jun 18 22:15:32 <ant__> and a.cfg on top of it
Jun 18 22:15:46 <ant__> (this was the defconfig)
Jun 18 22:15:59 <ant__> I still have to purge it but you get the idea
Jun 18 22:17:19 <khem> so essentially you are overriding the big chunk of defaults coming for  linux yocto
Jun 18 22:17:23 <ant__> yes
Jun 18 22:17:28 <khem> instead of seeing what really needs to be overridden
Jun 18 22:17:53 <khem> in my case I have a the list of things I specifically want to disable
Jun 18 22:17:58 <ant__> no, I know exactly what I need, size must be 900kb
Jun 18 22:18:38 <ant__> now I'll test a script to prune the config frags
Jun 18 22:18:55 <ant__> so that the .cfg will be minimal
Jun 18 22:19:20 <ant__> ofc you can do the opposite
Jun 18 22:19:24 <ant__> Previous value: CONFIG_BLK_DEV_RAM=y
Jun 18 22:19:24 <ant__> New value: # CONFIG_BLK_DEV_RAM is not set
Jun 18 22:19:39 <ant__> sry, you get the idea
Jun 18 22:20:07 <khem> yes,
Jun 18 22:20:09 <ant__> to set harwdare frags apart
Jun 18 22:20:14 <khem> I think I know answer to my question
Jun 18 22:20:36 <khem> I just wanted to know if it was possible to disable an option that came from an earlier fragment
Jun 18 22:20:44 <ant__> you have to look in the /meta/cfg dir
Jun 18 22:21:00 <khem> I still need to understand the priority order
Jun 18 22:21:21 <khem> what if the same option is toggled in three different frags
Jun 18 22:21:28 <khem> which one has the last say
Jun 18 22:21:55 <ant__> ah, some months ago if one file defconfig was found, this won
Jun 18 22:22:14 <khem> did it still consider the rest of fragments ?
Jun 18 22:22:17 <ant__> now it depends on the order in the .scc
Jun 18 22:22:23 <khem> or just ignored the whole mechanism ?
Jun 18 22:22:32 <ant__> not ethat th epaths are not relative to OE but to kernel workdir
Jun 18 22:22:34 <khem> ok .scc order is promising
Jun 18 22:22:43 <ant__> it's a bit strange...
Jun 18 22:23:23 <ant__> I put together the transition to Yocto kernel on the behalf of Bruce
Jun 18 22:23:25 <khem> my aim is to create one extra fragment to disable/enable 5 option I want
Jun 18 22:23:43 <khem> you mean a document ?
Jun 18 22:23:45 <ant__> sounds like one .cfg would do
Jun 18 22:23:46 <khem> of some sort
Jun 18 22:24:04 <khem> yeah I think I will create a cfg and stick it to end of .scc
Jun 18 22:24:08 <khem> that should be it
Jun 18 22:24:13 <khem> as I read the tooling
Jun 18 22:24:17 <khem> it goes line by line
Jun 18 22:24:18 <ant__> I'd say yes
Jun 18 22:24:51 <ant__> remember the normal path overrides of bitbake do not work :/
Jun 18 22:25:02 <khem> ant__: on another note Italy made into Euro 2012 QFs
Jun 18 22:25:04 <khem> :)
Jun 18 22:25:16 <ant__> i.e. one patch must be listed in each SRC_URI and be in the same dir as the .scc ...
Jun 18 22:25:28 <khem> I know I dont intermix bitbake methods and kernel tooling
Jun 18 22:25:34 <ant__> khem: pure luck
Jun 18 22:26:35 <ant__> khem: I've seen today a patch to make an hybrid .git kernel use some yocto tools
Jun 18 22:26:43 <ant__> iirc is one skeleton
Jun 18 22:26:50 <khem> nice
Jun 18 22:27:31 <khem> http://www.thefinancepages.co.uk/companies/nokia-layoffs/01263/
Jun 18 22:27:53 <ant__> sad
Jun 18 22:28:27 <khem> its on a death spiral
Jun 18 22:28:32 <khem> it will just make it quick
**** ENDING LOGGING AT Tue Jun 19 02:59:58 2012

**** BEGIN LOGGING AT Tue Jun 19 02:59:59 2012
Jun 19 07:02:37 <JaMa> RP__: ping (or anyone with write to opkg-utils repo)
Jun 19 07:25:07 <RP__> JaMa: I'll sort those patches...
Jun 19 07:26:04 <JaMa> thanks
Jun 19 07:36:29 <RP__> JaMa: done
Jun 19 07:58:43 <mckoan> good morning
Jun 19 09:53:10 <bluelightning> hi all
Jun 19 12:13:54 <Zagor> We're having a linux foundation representative here giving presentations to management about linux and open source - using a mac!
Jun 19 12:14:22 <Zagor> I find that rather strange, bordering on offensive.
Jun 19 12:38:14 <d4ny> Zagor: Cut him some slack, he's a nice guy, disregarding the mac. :)
Jun 19 13:14:06 <RP__> Zagor: It is kind of sad...
Jun 19 13:14:25 <jwessel> RP__ / bluelightning: What would you think about splitting the sstate into something other than a single level?
Jun 19 13:14:45 <jwessel> The latest changes from bluelightning pushed my slow disk system over the edge in terms of performance.
Jun 19 13:14:56 <bluelightning> jwessel: what kind of division were you thinking about?
Jun 19 13:15:05 <jwessel> The sstate dir accumulated 200,000 sstate entries
Jun 19 13:15:15 <jwessel> and I started getting really bad performance.
Jun 19 13:15:17 <RP__> jwessel: I know kergoth found multiple path levels to sstate to be problematic
Jun 19 13:15:32 <bluelightning> jwessel: er, how many times did you run -C / -f to get to that?
Jun 19 13:15:33 <jwessel> bluelightning: Very simple, but what was the problem with multiple path levels in sstate?
Jun 19 13:15:52 <jwessel> bluelightning: It was more like a straw that broke the camels back.
Jun 19 13:16:08 <jwessel> It wasn't that was so much additional, it was "just enough".
Jun 19 13:16:17 <bluelightning> hmm :/
Jun 19 13:16:38 <RP__> jwessel: From what I recall, the issue was that multiple path levels in the urls break things like the mirroring code for a start
Jun 19 13:16:46 <jwessel> I was thinking about a 1 line change to sstate.bbclass.
Jun 19 13:16:49 <jwessel> SSTATE_PKG        = "${SSTATE_DIR}/${PACKAGE_ARCH}/${PN}/${SSTATE_PKGNAME}"
Jun 19 13:17:13 <jwessel> Not knowing anything about the mirroring code, why wouldn't you just fix it?
Jun 19 13:17:14 <RP__> jwessel: I'm pretty mirroring code will fail
Jun 19 13:17:27 <jwessel> It would be suffering from the same performance problems at that point anyway.
Jun 19 13:17:57 <RP__> jwessel: You realise I've spent the best part of the last week trying to fix the mirroring code? ;-)
Jun 19 13:18:09 <bluelightning> jwessel: out of interest, what file system are you using for sstate-cache dir?
Jun 19 13:18:18 <bluelightning> s/for/for the/
Jun 19 13:18:22 <jwessel> ext3
Jun 19 13:18:31 <RP__> The start of the problem is just trying to figure out all the different permutations we use for it :/
Jun 19 13:18:35 <bluelightning> hmm, ok, nothing unusual there then
Jun 19 13:19:17 <jwessel> % time ls -R > /dev/null    0m4.597s
Jun 19 13:19:58 <RP__> jwessel: I'm not adverse to fixing it FWIW, its just not as simple as a one line change
Jun 19 13:20:40 <RP__> jwessel: it may even be as simple as updating the sstate mirror uri syntax examples too
Jun 19 13:20:41 <jwessel> Of course there is other fallout, but my point being we hit another performance issue, we'll call it a growing pain.
Jun 19 13:20:57 <RP__> jwessel: but that gives us a compatibility problem/transition to deal with in user config
Jun 19 13:21:16 <jwessel> ext3 when you put too many files in one dir, the performance gets _really_ bad for some cases.
Jun 19 13:21:55 <jwessel> Same reason ccache supports a multi-level "changeable" hash.
Jun 19 13:22:25 <jwessel> Not to mention, I hit the limit that I could no longer do rm  /opt/sstate_cache/*
Jun 19 13:22:35 <jwessel> It now tells me the command line is too long.
Jun 19 13:22:43 <RP__> jwessel: that one is trivial to workaround ;-)
Jun 19 13:22:50 <jwessel> Of course we all know that.
Jun 19 13:23:15 <RP__> rm /opt/sstate_cache/*/*/* isn't going to work any better
Jun 19 13:24:39 <jwessel> But at point I can purge the target stuff and not the native things, because they'll actually be organized.
Jun 19 13:24:53 <jwessel> rm -rf /opt/sstate_state/i586
Jun 19 13:25:02 <jwessel> Believe it or not that is really useful.
Jun 19 13:25:25 <jwessel> Sure I have scripts that were doing this already and just using different patterns.
Jun 19 13:25:47 <jwessel> But I notice the performance issue mainly because the script broke from the arg list too long.
Jun 19 13:26:31 <jwessel> I guess I could have led with that statement, but obviously the solution would have been to modify the script.  I happen to dig further because I was wondering what was taking so long.
Jun 19 13:27:22 <jwessel> Is there some kind of documentation on the mirroring?  Not having used it I don't even know what I am missing out on.
Jun 19 14:29:27 <jwessel> In the multi-level sstate dir structure:
Jun 19 14:29:27 <jwessel> % time ls -R > /dev/null
Jun 19 14:29:27 <jwessel> real    0m0.291s
Jun 19 14:31:22 <jwessel> vs real    0m4.807s, and yes I realize most of that comes from "ls" sorting things.
Jun 19 15:11:36 <jwessel> bluelightning: I was just testing your bitbake -p change,
Jun 19 15:11:52 <jwessel> and it still fails, but I have no idea why.
Jun 19 15:12:32 <jwessel> Is there a file you used that is full of siginfo or pickle information that you decoded to determine what is different?
Jun 19 15:12:44 <jwessel> I know I had to do that to debug the kernel always rebuilding for example.
Jun 19 15:13:39 <RP__> jwessel: sstate mirroring is mentioned in local.conf.sample
Jun 19 15:13:55 <RP__> jwessel: syntax is shared with PREMIRRORS and MIRRORS
Jun 19 15:13:59 <jwessel> Thanks RP__I'll take a look.
Jun 19 15:14:04 <bluelightning> jwessel: when I was diagnosing it I simply did a bitbake -e > output1.txt and then hacked the bitbake wrapper to execute bitbake -e under pseudo and ran it again, then compared the two outputs
Jun 19 15:14:43 <bluelightning> jwessel: you have to adjust for TIME changing between the two executions but after doing that the only difference was PSEUDO_BUILD
Jun 19 15:15:09 <jwessel> hmm... There must be something more in my environment.
Jun 19 15:15:34 <jwessel> Is there a way to clear the bitbake parse cache entirely?
Jun 19 15:15:47 <bluelightning> jwessel: rm -rf tmp/cache
Jun 19 15:15:48 * jwessel admits to not even knowing where it lives.
Jun 19 15:15:53 <bluelightning> that totally clears it
Jun 19 15:17:43 <jwessel> Getting off this 5400 rpm drive will make things much better, but I figure I ought to look at it while it is still annoying.
Jun 19 15:18:07 <bluelightning> jwessel: sure, if we can narrow down what's changing we definitely want to fix it
Jun 19 15:18:47 <jwessel> I just wanted to re-confirm the findings.  Still waiting for the results.
Jun 19 15:20:29 <jwessel> Ran 4 times:  bitbake -p acl
Jun 19 15:20:29 <jwessel> Parsing of 953 .bb files complete (951 cached, 2 parsed). 1258 targets, 23 skipped, 8 masked, 0 errors.
Jun 19 15:20:29 <jwessel> and then for the same command without -p:  bitbake acl
Jun 19 15:20:29 <jwessel> Parsing of 953 .bb files complete (0 cached, 953 parsed). 1258 targets, 23 skipped, 8 masked, 0 errors.
Jun 19 15:20:50 <jwessel> So something is different.  Just don't know what.
Jun 19 15:21:41 <jwessel> I noticed even when it gets to the stage after it does the psudeo compile (~ first 75 task) it does another full parse at that point.
Jun 19 15:22:08 <bluelightning> jwessel: yes that's the same issue I believe
Jun 19 15:22:16 <jwessel> bluelightning: Is there any further debug information I can provide for you, or do you have suggestions?
Jun 19 15:22:20 <bluelightning> jwessel: could you try my bitbake -e method above? to get it to run under pseudo for the second part the only thing you need to do is remove -e from NO_BUILD_OPTS at the top
Jun 19 15:22:31 <bluelightning> (of scripts/bitbake)
Jun 19 15:22:43 <jwessel> Should I leave the parse stuff intact or erase it?
Jun 19 15:23:17 <bluelightning> jwessel: for this test I don't think it matters
Jun 19 15:24:39 <jwessel> So you need "bitbake -p -e acl" with the modified script and same without the modified script?
Jun 19 15:25:06 <bluelightning> jwessel: no, just bitbake -e for both cases
Jun 19 15:25:22 <bluelightning> jwessel: we're only concerned with the global environment changing here I think
Jun 19 15:27:20 <jwessel> http://pastebin.com/tCzJr6ut
Jun 19 15:27:30 <jwessel> I replaced some time stuff, but not all for the comparison.
Jun 19 15:28:04 <rburton> m4t: just reading backlog, the general solution to the glib-pkgconfig circular dependency is to build glib without pkgconfig, i.e. use envvars to set locations
Jun 19 15:28:31 <bluelightning> jwessel: hmm, the only thing I can see changing other than PSEUDO_BUILD is _
Jun 19 15:29:36 <jwessel> bluelightning: That is why I asked how you debug it.
Jun 19 15:30:03 <jwessel> Some how the parse is fast for both cases after initially getting through it.
Jun 19 15:30:21 <jwessel> That is what led me to ask if there was some kind of hash file stored somewhere that could also be diffed.
Jun 19 15:30:52 <bluelightning> jwessel: I don't think we do store it, we just compute a hash of the data store and use it in the name for the cache file
Jun 19 15:31:17 <bluelightning> jwessel: thus, if non-whitelisted variables change they change that signature and it needs to rebuild the cache
Jun 19 15:31:43 <RP__> jwessel: Add some prints to get_hash() in data_smart.py
Jun 19 15:32:10 <RP__> jwessel: perhaps dump a pickled data object of files there
Jun 19 15:32:26 <bluelightning> jwessel: does adding _ to BB_HASHCONFIG_WHITELIST in conf/bitbake.conf fix it ?
Jun 19 15:32:50 <bluelightning> (changing that file will force a parse of course, but after that)
Jun 19 15:32:54 <jwessel> RP__: That is what I was looking for and how debugged a different problem previously.
Jun 19 15:33:02 <jwessel> bluelightning: No reason not to try it. :-)
Jun 19 15:33:51 <jwessel> RP__: I just don't where you would insert the call or what the call is that gives you the pickle files.
Jun 19 15:33:53 <RP__> bluelightning: why would we be preserving "_" ? :/
Jun 19 15:34:46 <bluelightning> RP__: I'm assuming it has been allowed through in this case, I don't think we do that in the default config...
Jun 19 15:34:47 <RP__> jwessel:         with open(sigfile, "wb") as f:
Jun 19 15:34:47 <RP__>             p = pickle.Pickler(f, -1)
Jun 19 15:34:47 <RP__>             p.dump(data)
Jun 19 15:35:08 * jwessel assume RP typed it from memory ;-)
Jun 19 15:35:40 <jwessel> bluelightning: That fixed it.
Jun 19 15:35:53 <jwessel> BB_HASHCONFIG_WHITELIST ?= "${BB_HASHBASE_WHITELIST} DATE TIME SESSION_MANAGER DBUS_SESSION_BUS_ADDRESS SSH_AGENT_PID XDG_SESSION_COOKIE SSH_AUTH_SOCK XAUTHORITY PSEUDO_BUILD _"
Jun 19 15:36:08 <jwessel> Kind of fugly...
Jun 19 15:36:16 <jwessel> I'll purge the cache entirely to be sure.
Jun 19 15:36:32 <RP__> I'd like to understand why "_" is in there in the first place. Would be better to just exclude it
Jun 19 15:37:10 <bluelightning> jwessel: ok - the next question is did you previously change the config to allow _ through into the environment ?
Jun 19 15:37:12 <jwessel> Do we have a method for tracking that one down?
Jun 19 15:37:32 <jwessel> Ah you mean custom WHITELIST.
Jun 19 15:37:34 <jwessel> good question.
Jun 19 15:38:28 <jwessel> echo $BB_ENV_EXTRAWHITE |xargs -n1 echo  |grep ^_
Jun 19 15:38:31 <jwessel> Nothing there.
Jun 19 15:39:56 <jwessel> I can only imagine someone added a statement somewhere in an exported variable or some such.
Jun 19 15:40:40 <bluelightning> jwessel: what about bitbake -e | grep BB_ENV_EXTRAWHITE
Jun 19 15:41:57 <jwessel> Nothing there either.
Jun 19 15:44:41 <bluelightning> hmm, puzzling... how is it being allowed through?
Jun 19 15:47:38 <jwessel> bluelightning: I am not clear how to locate the answer at the moment.
Jun 19 15:48:59 <bluelightning> jwessel: I'm not entirely sure either but I'm looking at the code now
Jun 19 15:55:05 <bluelightning> RP__: er, _ is in preserved_envvars explicitly in utils.bbclass...
Jun 19 15:56:48 <bluelightning> actually I meant lib/bb/utils.py
Jun 19 16:00:15 <RP__> bluelightning: we should kill "_" and "LANG" from there
Jun 19 16:03:45 <jwessel> I can delete those locally and run some test.  Looks to me like that is probably the right thing to do.
Jun 19 16:05:27 <RP__> The stuff in there is a hangover from older days
Jun 19 16:05:41 <bluelightning> ok, cool
Jun 19 16:05:57 <bluelightning> I was about to dig back through the history to see if I could find why they were added...
Jun 19 16:05:58 <jwessel> Definitely works correctly with LANG and _ zapped.
Jun 19 16:06:13 <RP__> To "complete" that changeover, we save the original environment away, we just need to have things like the terminal class restore it
Jun 19 16:06:24 <Zagor> RP__: it's late here now but I'll try get a mail off in a couple of hours describing my concerns
Jun 19 16:07:03 <RP__> Zagor: Basically, "-f" in theory is a null op unless you've made some local change you want to force into the system
Jun 19 16:07:20 <RP__> if you change any input to the task, bitbake xxx should rebuild anything effected by the change automatically
Jun 19 16:07:55 <RP__> Zagor: So the question is when do you need the -f option but don't want sstate invalidated
Jun 19 16:08:05 <jwessel> -f was really only intended as a local iterative change method.
Jun 19 16:08:19 <jwessel> Zagor: Like if you want to see something compile, and you already have the sstate version.
Jun 19 16:08:40 <darknighte> RP__, I think Zagor has a point.  didn't the change that was described change the signature by injecting a random value?
Jun 19 16:09:04 <RP__> darknighte: yes, it did
Jun 19 16:09:20 <jwessel> darknighte: That is why you end up with a new sstate for each -f you do.
Jun 19 16:09:29 <jwessel> I pointed that out earlier today.
Jun 19 16:09:29 <darknighte> then the shared state generated by the "-f" build won't be resusable?
Jun 19 16:09:40 <jwessel> Only within your local build.
Jun 19 16:09:59 <RP__> darknighte: but it stops you sharing tainted sstate files
Jun 19 16:10:07 * darknighte ponders a bit more
Jun 19 16:10:25 <jwessel> The upside as bluelightning implemented is that you don't expose local changes.
Jun 19 16:10:27 <RP__> darknighte: imagine person A has sstate X with configuration C and person B has sstate X with configuration D, same checksum
Jun 19 16:10:52 <RP__> darknighte: If you don't taint when doing things like -c menuconfig or -f, that is the position you end up in
Jun 19 16:14:24 <bluelightning> jwessel: / RP__ - I will send another patch to remove those vars then
Jun 19 16:15:49 <jwessel> bluelightning: Fine with me, assuming it is really just those to lines, you can add my ack on both patches, if we do such things in yocto / bitbake.
Jun 19 16:15:58 <jwessel> I have reviewed and tested both pieces.
Jun 19 16:16:18 <bluelightning> jwessel: ok, thanks, will do
Jun 19 16:16:28 <jwessel> Thanks for tracking this one down.
Jun 19 16:16:43 <bluelightning> jwessel: no worries... another one bites the dust ;)
Jun 19 16:16:48 <jwessel> Makes my slow HDD a bit more tolerable. :-)
Jun 19 16:18:18 <jwessel> It does make me wonder what is so slow about the parse in the first place, because it is not clear to me if it is writing lots of stuff or where it actually spends all the time.  Until I try this on a SSD (next week) I don't have anything to compare it to for the initial parse.
Jun 19 16:18:30 <jwessel> That is clearly another battle for another day though.
Jun 19 16:19:26 <bluelightning> jwessel: it did slow down a little recently when we added file checksums although even if the parser cache is invalidated, that is cached separately at least
Jun 19 16:20:17 <jwessel> Working correctly is obviously most important for now.  This particular optimization was low hanging fruit.
Jun 19 16:21:11 <jwessel> 3 x 71 seconds = 3 1/2 minutes off my build time for the smallest system.
Jun 19 16:34:46 <hwinkel> hi
Jun 19 17:02:15 <bluelightning> RP__: so just to clarify, what was the reason why _ / LANG were added?
Jun 19 17:02:36 <RP__> bluelightning: LANG needed to be set. We now set it in bitbake.conf
Jun 19 17:02:47 <RP__> bluelightning: The idea was to remove it from bitbake once it was set there
Jun 19 17:03:06 <RP__> So LANG is easy, I know that one is safe. "_", I'm not sure why that ended up there
Jun 19 17:03:24 <RP__> If builds work without it, I'm happy. I can't imagine why we'd need it
Jun 19 17:03:43 <bluelightning> hmm, LANG isn't set in bitbake.conf
Jun 19 17:04:15 <RP__> bluelightning: ah, export LC_ALL = "C"
Jun 19 17:04:23 <RP__> bluelightning: that should be what we need
Jun 19 17:04:43 <bluelightning> also does not allowing it through cause any issues for people wanting to set the locale for messages produced by the compiler for example?
Jun 19 17:05:17 <RP__> bluelightning: we have a conscious decision that all messages should be in "C" locale because we do so much processing of the output
Jun 19 17:05:39 <RP__> bluelightning: and hence we also disable all localisation within things like the compiler and native packages
Jun 19 17:05:43 <fray> ya, processing requires the C local
Jun 19 17:05:50 <bluelightning> RP__: ah ok, fair enough... if the question comes up I now know the answer :)
Jun 19 17:06:15 * RP__ -> afk for a bit
Jun 19 17:31:20 <sgw> zeddii: for the perf recipe if you use STAGING_KERNEL_DIR directly which is in tmp/sysroots you should be able to use standard DEPENDS instead of the do_configure and do_compile depends you have now.
Jun 19 17:32:01 <zeddii> ok. trying that out. I'll resubmit the patches after testing.
Jun 19 18:05:37 <khem> bluelightning: in OE classic we had a license dumping capability using testlabs it would dimp the licenses of packages that go into target
Jun 19 18:05:42 <khem> image
Jun 19 18:05:57 <khem> I am sure we have something to achieve same in OE-Core
Jun 19 18:06:01 <khem> do you know
Jun 19 18:06:08 <bluelightning> khem: we do indeed
Jun 19 18:06:19 <bluelightning> khem: let me check where that's documented...
Jun 19 18:11:38 <bluelightning> khem: hmm, having trouble finding anything :/
Jun 19 18:12:20 <khem> hmm
Jun 19 18:14:17 <bluelightning> khem: well, I think I can at least point you in the right direction
Jun 19 18:14:28 <bluelightning> license.bbclass is where the work is done for this
Jun 19 18:14:29 <khem> I am lookng at lincense.bbclass
Jun 19 18:14:31 <bluelightning> right
Jun 19 18:14:41 <khem> https://wiki.yoctoproject.org/wiki/License_Audit
Jun 19 18:14:59 <bluelightning> yeah I think that's old, I've just asked Beth about it
Jun 19 18:15:32 <khem> I am looking for package - license
Jun 19 18:15:36 <khem> that makes my image
Jun 19 18:15:47 <bluelightning> if license.bbclass is used (and it is by default at least for poky) then it outputs to tmp/deploy/licenses
Jun 19 18:15:53 <khem> I dont care about the license that are for packages I use to build the image
Jun 19 18:16:40 <khem> ../../build/tmp/deploy/licenses/core-image-minimal-qemuarm-20120616004513/license.manifest
Jun 19 18:16:43 <khem> got it
Jun 19 18:16:45 <bluelightning> right
Jun 19 19:27:16 <zeddii> sgw. aha. I figured out why we needed the 'source' link for the perf build.
Jun 19 19:27:46 <zeddii> now to see what the options are ..
Jun 19 19:31:16 <sgw> zeddii: ok, clearly there was some other files in source that are not in the KERNEL_STAGING_DIR
Jun 19 19:31:43 <zeddii> yah.
Jun 19 19:32:10 <zeddii> so either I need to install more into the syroot (like perhaps tools/*) .. or create some sort of hook.
Jun 19 19:32:23 <zeddii> I think leaving enough source to build tools/* or modules is fine ..
Jun 19 19:41:36 * zeddii goes into 'find' hell
Jun 19 19:50:06 <sgw> lucky zeddii ;-)
Jun 19 19:50:08 <Zagor> oh bugger, I sent the mail from my non-subscribed mailing address. does that get moderated or discarded?
Jun 19 19:50:18 <sgw> I will moderate it!
Jun 19 19:50:32 <Zagor> thanks
Jun 19 19:50:50 <sgw> Zagor: if it's oe-core, I can't but I yocto or poky I can
Jun 19 19:51:00 <Zagor> bitbake-devel
Jun 19 19:51:02 <zeddii> sgw. woo. I survied. should have a new perf series tonight.
Jun 19 19:51:09 * zeddii dislikes find syntax
Jun 19 19:51:13 <sgw> Zagor: not that one either.
Jun 19 19:51:21 <Zagor> ok
Jun 19 19:51:22 <sgw> zeddii: nicely done!
Jun 19 22:46:10 <ant__> zeddii: ping
**** ENDING LOGGING AT Wed Jun 20 02:59:59 2012

**** BEGIN LOGGING AT Wed Jun 20 02:59:59 2012
Jun 20 10:17:16 <RP__> The more I poke at the fetchers with unittests, the more worried I get :(
Jun 20 11:53:42 <jwessel> RP__: Of that I have no doubt.
Jun 20 11:54:12 <jwessel> The fetchers have some "underhanded" dealings and private agreements with the base class.
Jun 20 11:55:10 <RP__> jwessel: Be pleased you didn't see how this used to work...
Jun 20 11:55:33 <RP__> That part is positively beautiful compared to the fetch1
Jun 20 11:56:11 <jwessel> :-)
Jun 20 11:57:01 <jwessel> Is it possible to use INHIBIT_PACKAGE_STRIP on a single recipe?
Jun 20 11:57:05 <jwessel> INHIBIT_PACKAGE_STRIP_pn_lemon-server = "1"
Jun 20 11:57:22 <RP__> that should work
Jun 20 11:57:40 <RP__> jwessel: My WIP patch is http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t11&id=806ed503ca556d1bbd16b9eb172cfd7d99a5e021 FWIW. I need to split this up into logical changes now
Jun 20 11:57:58 * jwessel goes to look at the change set first.
Jun 20 11:58:23 <jwessel> What I have observed is that my binaries are getting stripped and split even though I have the _pn_ syntax.
Jun 20 11:58:42 <jwessel> I might have to try it with a package in oe-core to see if it works, because this something off in my own private layer.
Jun 20 11:59:04 <RP__> jwessel: ah, INHIBIT_PACKAGE_STRIP_pn-lemon-server = "1"
Jun 20 11:59:14 <RP__> jwessel: note the s/_/-/
Jun 20 12:03:33 <jwessel> Perhaps that will work. I'll try it in a bit.
Jun 20 12:04:11 <jwessel> It is not obvious to me how your patch set address the multi split of the git urls -> local git archive.
Jun 20 12:05:58 <jwessel> RP__: I would have expected that there was a change for a callback or an expansion to the replace logic.
Jun 20 12:06:25 <jwessel> But yes, this does look a lot cleaner and you re-factored two sections that really bothered me.
Jun 20 12:07:09 <jwessel> I had considered a re-factor, but time was not on my side with respect to the fact all our local pre-mirrors were no longer working correctly.
Jun 20 12:19:57 <Majid> Hi
Jun 20 12:20:33 <Majid> I'm builing core-image-minimal
Jun 20 12:21:00 <Majid> it is showing:
Jun 20 12:21:01 <Majid> NOTE: Running noexec task 1308 of 1342 (ID: 702, /home/mazimi/Desktop/poky-denzil-7.0/meta/recipes-devtools/perl/perl_5.14.2.bb, do_package_write)
Jun 20 12:21:21 <Majid> it doesn't proceed
Jun 20 12:21:27 <Majid> waiting for a long time
Jun 20 12:21:35 <Majid> 3 hours probably
Jun 20 12:21:44 <jwessel> In the master branch?
Jun 20 12:22:07 <Majid> what do you mean master branch?
Jun 20 12:22:19 <Majid> I have downloaded it from yocto site
Jun 20 12:22:42 <jwessel> This problem probably fixed if you checkout the very latest from git.
Jun 20 12:22:48 <Majid> I'm using it under debian 6.0.5. there was no error until now
Jun 20 12:23:09 <jwessel> It doesn't sound as if there is an error, though, just a performance issue.
Jun 20 12:23:15 <RP__> Majid: Do you know which tasks are still running?
Jun 20 12:23:33 <jwessel> RP the _ - did the trick.
Jun 20 12:23:34 <Majid> how should now that? Is there any command?
Jun 20 12:23:55 <jwessel> I wonder how many more times I'll be burned by that?  ;-)
Jun 20 12:24:24 <RP__> Majid: Well, if you Ctrl+C the build, it will start to shutdown and a side effect will print a list of what is currently running. You'll be able to restart after it exists with no problem
Jun 20 12:24:32 <RP__> Majid: It could be worth updating to the denzil branch, we have various fixes queued there for a point release
Jun 20 12:25:13 <Majid> it shows this:
Jun 20 12:25:19 <Majid> Waiting for 1 running tasks to finish:
Jun 20 12:25:20 <Majid> 0: linux-yocto-3.2.11+git1+b14a08f5c7b469a5077c10942f4e1aec171faa9d_1+8ada1bb97415fe959a57a08504be4eb8a656ed30-r1 do_fetch (pid 7709)
Jun 20 12:25:39 <RP__> Majid: ok, its cloning the kernel which is large
Jun 20 12:25:59 <RP__> Majid: I suspect it is building ok, its just taking a long time to download that
Jun 20 12:26:57 <RP__> jwessel: The syntax you need is  "git://.*/([^/]+/)*([^/]*)",  "git:///somedir/\\2;protocol=file "
Jun 20 12:27:14 <Majid> so there is nothing wronge with perl? I mean this line: Running noexec task 1308 of 1342 (ID: 702, /home/mazimi/Desktop/poky-denzil-7.0/meta/recipes-devtools/perl/perl_5.14.2.bb, do_package_write)
Jun 20 12:27:21 <RP__> jwessel: for git -> local file urls
Jun 20 12:27:29 <RP__> Majid: no, that was just the last task to complete
Jun 20 12:28:05 <Majid> ok, thank you very much for help
Jun 20 12:28:14 <Majid> when will the new version become GA
Jun 20 12:28:38 <RP__> Majid: The point release is due within a few weeks now
Jun 20 12:28:58 <RP__> Majid: it won't help the above issue though, that just looks like its taking time to complete the fetch
Jun 20 12:29:14 <Majid> ow, ok thanks
Jun 20 12:31:24 <ant_work> RP__: I'm experiencing strange issues with linux-libc-headers 3.4. The mtd/ubi-user.h in sysroot is *not* the one in 3.4 mainstream, is older (one ioctl was renamed).How can that happen?
Jun 20 12:33:46 <RP__> ant_work: it sounds rather strange, not sure :/
Jun 20 12:40:05 <ant_work> RP__: hm... in fact the header changed with linux 3.0. Maybe the python __anonymous in linux-libc-headers is failing
Jun 20 13:03:28 <RP__> jwessel: I've updated that branch with the patch split into pieces now
Jun 20 14:19:50 <jwessel> RP__: Just because it is not clear from your change log,  can you now use a git premirror that a flat repo?
Jun 20 14:20:09 <jwessel> I am talking about something that is not stored in tar.gz
Jun 20 14:20:31 <RP__> jwessel: in the form git:///somepath/;protocol=file , yes
Jun 20 14:21:01 <jwessel> How do I generically specify that in the PREMIRROS, has the syntax changed?
Jun 20 14:21:06 <RP__> jwessel: You probably want something like git://.*/([^/]+/)*([^/]*) git:///somedir/\\2;protocol=file
Jun 20 14:21:36 <jwessel> Obviously we don't have docs to match at the moment, but I will certainly try this.
Jun 20 14:21:57 <RP__> jwessel: It hasn't "changed", it never worked before. After much thought, I concluded git://xxxx git://xxx;protocol=file was the best syntax to use
Jun 20 14:22:14 <jwessel> That was the one I toyed with at one point as well.
Jun 20 14:22:33 <RP__> jwessel: This means the git://.*/.* http://xxxx syntax can be used exclusively for mirror tarballs
Jun 20 14:23:39 <RP__> jwessel: I did have fun coming up with the right regexp to handle different server layouts and correctly map the urls. It does dispel the myth that ".*" is the only thing allowed in there though :)
Jun 20 14:24:01 <RP__> jwessel: and the tests do at least document this to a degree
Jun 20 14:24:48 <jwessel> I looked at the tests, and there was no mention of protocol=file for git URL.
Jun 20 14:24:52 <jwessel> Hence my question.
Jun 20 14:25:05 <jwessel> I would have dug deeper and tried the code first if I had seen that.
Jun 20 14:25:09 <RP__> jwessel: ah, it takes any protocol the git fetcher does
Jun 20 14:25:38 <jwessel> So I assume there is no test for a bare clone as a pre-mirror at the moment then.
Jun 20 14:25:46 <RP__> someone should write a tester of a file:// premirror :)
Jun 20 14:26:07 <RP__> jwessel: Want me to write one? :)
Jun 20 14:26:27 <jwessel> Well it is something that is a lynch pin to our use case, so having it can only help us.
Jun 20 14:26:58 <jwessel> RP__: Are those patches in a tree I can just pull from ?
Jun 20 14:27:04 <jwessel> or do a git remote add ...
Jun 20 14:27:22 <RP__> jwessel: Not a bitbake one at this point
Jun 20 14:27:30 <jwessel> You pointed me to a URL earlier, and it led me to wonder if you published staging trees.
Jun 20 14:27:47 <RP__> jwessel: well, that tree exists but its poky based and has other stuff in it
Jun 20 14:28:03 <RP__> I generated the patch set off the top of that
Jun 20 14:29:07 <jwessel> No worries.  git apply works ok too :-)
Jun 20 14:29:24 <jwessel> I am sure we all have an mbox apply strategy by now.
Jun 20 15:01:03 <jwessel> RP__: With your new changes applied to bitbake master, most everything fails to fetch from my pre-mirros.
Jun 20 15:01:10 <jwessel> I am trying to decode the problem at the moment.
Jun 20 15:03:30 <jwessel> RP__: Is it the case I have to change all the premirror_appends with your new patch?
Jun 20 15:03:47 <jwessel>      http://.*/.* file://${LAYERDIR}/downloads/ \n \
Jun 20 15:04:09 <jwessel> That is the rule that previously worked
Jun 20 15:05:40 <RP__> jwessel: that wasn't the intent, no
Jun 20 15:05:51 <jwessel> The layer is pretty simple.
Jun 20 15:06:21 <jwessel> oe-core-dl/downloads/quilt-0.51.tar.gz
Jun 20 15:06:43 <jwessel> And the layer.conf has the preemiror append as shown above, and it used to work.
Jun 20 15:07:33 <jwessel> The other thing being that I always run with: BB_NO_NETWORK = "1"
Jun 20 15:08:28 <jwessel> Did you want to see the log?  I don't have time to debug this at the moment because I have a few other tasks that need some tending, but I thought I would at least try to describe the problem.
Jun 20 15:09:02 <RP__> jwessel: I'm about to get pulled into a lot of meetings. Obviously we do need to figure this out though
Jun 20 15:09:19 <jwessel> It just means the patches should not like be merged yet :-)
Jun 20 15:09:23 <RP__> jwessel: I just tried adding the above to the test cases and it seems to do what I'd expect
Jun 20 15:10:41 <jwessel> I am thinking the log won't help, because it doesn't really have anything that appears useful in it, like the match sets.
Jun 20 15:10:44 <RP__> jwessel: extra test cases: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t11&id=103e6d5c03dcc39aae237b8ba4cc847bc3c3ec54
Jun 20 15:26:32 <denisATeukrea> hi, did someone saw that:"Xorg: symbol lookup error: /usr/lib/xorg/modules/drivers/fbdev_drv.so: undefined symbol: DGAInit"
Jun 20 15:26:48 <denisATeukrea> previously it was sufficent to recompile xf86-video-fbdev
Jun 20 15:26:55 <denisATeukrea> but that doesn't seem to work anymore....
Jun 20 15:29:45 <RP__> denisATeukrea: it sounds like dga was disabled somewhere
Jun 20 15:30:06 <RP__> (like the xserver)
Jun 20 15:30:10 <denisATeukrea> ok
Jun 20 15:30:42 <denisATeukrea> let me look at the code of xf86-video-fbdev because I don't remember what dga is
Jun 20 15:31:43 <RP__> denisATeukrea: Direct Graphics Access iirc
Jun 20 15:32:00 <denisATeukrea> ahh ok
Jun 20 15:32:02 <denisATeukrea> that thing
Jun 20 15:32:13 <denisATeukrea> where it permits apps to bypass the Xorg server
Jun 20 15:32:20 <bluelightning> one wonders why the framebuffer driver needs to talk to DGA... or is it so they somehow don't fight eachother?
Jun 20 15:32:44 <denisATeukrea> like mplayer should support DGA I think
Jun 20 15:32:52 <denisATeukrea> I tested it on some device in oe-classic times
Jun 20 15:33:35 <RP__> bluelightning: I'm not sure about why fbdev needs it. I know the mesa driver does though to poke the int11 bits
Jun 20 15:34:12 <denisATeukrea> for having DGA support I guess
Jun 20 15:34:18 <denisATeukrea> it's not ifdefed tough
Jun 20 15:34:34 <denisATeukrea> I mean to let apps take control of the framebuffer so it's faster
Jun 20 15:34:44 <denisATeukrea> but it doesn't work when xf86-video-fbdev is rotated
Jun 20 15:38:17 <denisATeukrea> openembedded-core/meta/recipes-graphics/xorg-xserver/xserver-xorg-lite.inc:                 --disable-dga \
Jun 20 15:38:18 <bluelightning> ah right, somehow I got confused .. DGA is at the application end, I knew that :)
Jun 20 15:38:30 <bluelightning> so it's not unreasonable the driver would need some knowledge of it
Jun 20 15:39:01 <denisATeukrea> so I guess I need the non-lite version of xorg
Jun 20 15:39:22 <denisATeukrea> or should I send a patch for master + denzil?
Jun 20 15:39:24 <bluelightning> or, fix the fbdev driver to make that bit optional, presumably that's not impossible
Jun 20 15:39:43 <denisATeukrea> hmmm but then I would need to make the patch upstream
Jun 20 15:40:15 <denisATeukrea> *would need to upstream the patch
Jun 20 15:40:24 <denisATeukrea> so it would have to be done right, takes time etc...
Jun 20 15:40:54 <denisATeukrea> beside I see an issue
Jun 20 15:41:08 <denisATeukrea> xf86-video-fbdev would have to be compiled twice right?
Jun 20 15:41:23 <denisATeukrea> or DGA would need to be disabled for both xorg full and lite
Jun 20 15:42:02 <denisATeukrea> what distro runs as root beside SHR?
Jun 20 15:42:23 <denisATeukrea> because if I remember well it requires root to work
Jun 20 15:48:44 <bluelightning> right yes
Jun 20 15:48:53 <bluelightning> hmm
Jun 20 15:49:00 <bluelightning> tricky :(
Jun 20 15:49:41 <denisATeukrea> the thing is that DGA gives a performance boost in mplayer, but only few people know about it
Jun 20 15:49:59 <denisATeukrea> maybe for now I use xorg-full?
Jun 20 15:50:10 <bluelightning> I'm guessing that would work
Jun 20 15:50:13 <bluelightning> my understanding was that DGA was deprecated though
Jun 20 15:50:17 <denisATeukrea> ah?
Jun 20 15:50:22 <denisATeukrea> what replaces it?
Jun 20 15:54:56 <bluelightning> denisATeukrea: that I don't know, I believe that my understanding is based upon readings of various mailing list posts years ago but I don't remember the details
Jun 20 15:55:04 <bluelightning> google might be of assistance...
Jun 20 15:58:19 <denisATeukrea> ok thanks
Jun 20 15:58:23 <denisATeukrea> I'll duck duck go it
Jun 20 16:13:41 <darknighte> compliance doc link: https://wiki.yoctoproject.org/wiki/Working_Draft_of_Compliance_Prop
Jun 20 16:15:15 <Crofton> whatever number I dialed worked
Jun 20 16:17:04 <darknighte> Crofton: thx.
Jun 20 16:18:05 <denisATeukrea> thanks a lot
Jun 20 16:18:10 <denisATeukrea> I'll go bye
Jun 20 16:20:37 <darknighte> Crofton: you get a chance to look it over?
Jun 20 16:20:52 <darknighte> Crofton: OpenSDR was listed as an example.
Jun 20 16:20:56 <Crofton|work> yeah
Jun 20 16:23:31 <msm> anyone know how to handle file conflicts in rpms?
Jun 20 16:23:42 <Crofton> sorry if I made some noise, I had a delivery ...
Jun 20 16:23:44 <msm> how do I make one "recipe" take precedence over all others
Jun 20 16:23:53 <msm> when generating a rootfs
Jun 20 16:25:36 <darknighte> davest: too late
Jun 20 16:26:03 <darknighte> Crofton: not that I noticed
Jun 20 16:29:41 <davest> Portlland weather update...
Jun 20 16:30:05 <davest> Spring 2012 had 8 days over 80 (F), max 88
Jun 20 16:30:18 <davest> Spring 2011 had 1 day over 80 (f), max 86
Jun 20 16:32:27 <msm> davest: pretty sure the world's ending
Jun 20 16:39:43 <darknighte> msm: isn't that this year, according to the Mayan calendar?
Jun 20 16:40:46 <mranostay> not till December 21st or something
Jun 20 16:40:51 <khem> 21/12 world goes EOL per Mayas
Jun 20 16:41:44 <mranostay> well to be fair the mayans that are alive don't believe the world is ending :)
Jun 20 16:42:40 <khem> some people are deciding to get married before that :) and I tell you if EOL is extended they will repent for rest of it :)
Jun 20 16:45:15 <darknighte> khem: funny, you'd think that getting married expecting to only *have* to be married for less than a year would be the way to go!
Jun 20 16:53:31 <mranostay> darknighte: still too long :)
Jun 20 16:54:51 <darknighte> mranostay: hah
Jun 20 16:54:54 <seebs> I dunno, I think things really improved around year 15-16 or so.
Jun 20 16:55:08 <seebs> (I've been married nearly 18 years.  Consecutively.  To the same person.)
Jun 20 16:55:30 <seebs> ... I mostly just say that because I think it's funny that the qualifiers are meaningful.
Jun 20 16:57:07 <mranostay> seebs: use of the word consecutively makes me thing of a prison term :)
Jun 20 16:57:17 <seebs> Hah.
Jun 20 16:58:13 <seebs> Viewed as prison terms, I think I'd call it parallel life sentences.  :P
Jun 20 16:59:56 <Crofton|work> http://www.flickr.com/photos/86669029@N00/7408744774
Jun 20 17:03:14 <wmat> +1 for clothes pin usage
Jun 20 17:04:24 <pidge> +10 for the octopus
Jun 20 17:05:12 <Crofton|work> Jefro, show Tracey the octopus
Jun 20 17:06:01 <mranostay> deja vu
Jun 20 17:07:07 <bluelightning> cool, but I'm guessing that GUI is somewhat less that usable on that screen :)
Jun 20 17:07:26 <pidge> Crofton|work: it's `sudo Jefro, show Tracey the octopus`
Jun 20 17:07:30 <bluelightning> I might be missing the point of that pic though :)
Jun 20 17:07:53 <Crofton|work> the main point is the spi to display
Jun 20 17:08:16 <Crofton|work> koen posted it on G+ with comments about the spi
Jun 20 17:08:42 <Crofton|work> the yoctopus is for #yocto's amusement
Jun 20 17:09:54 <mranostay> yeah i have the same display as well
Jun 20 17:12:02 <wmat> heh, I was so busy noticing the clothespin, I missed the octopus entirely
Jun 20 17:13:08 <bluelightning> Crofton|work: indeed, that is the cool part, I was commenting on the triviality of my own comment :)
Jun 20 17:45:15 <Jefro> Crofton|work the yoctopus strikes again!
Jun 20 17:48:36 <darknighte> I seem to recall a janitors' list somewhere for the project.  Can anyone point me at it again.  I can't find it currently.
Jun 20 17:51:31 * darknighte notices something strange
Jun 20 17:54:26 <darknighte> a search for "janitor" in the wiki search box doesn't find the page, but a search for "janitors" does.
Jun 20 17:54:31 <bluelightning> darknighte: I think what we did was to have a "janitors" severity level in bugzilla
Jun 20 17:56:30 <darknighte> bluelightning: there it is. thx.
Jun 20 17:57:07 <darknighte> btw, the reference page was here... https://wiki.yoctoproject.org/wiki/Janitors
Jun 20 17:57:42 <bluelightning> darknighte: the search issue is the typical problem with the search indexing in mediawiki, it is definitely rather annoying :/
Jun 20 17:58:28 <darknighte> yep.  I should have added a '*' to the search, which works fine.
Jun 20 17:58:48 <darknighte> in any case, thanks for pointing me to the sev in bugzilla bluelightning
Jun 20 17:58:56 <bluelightning> np :)
Jun 20 18:51:59 * Jay7 got
Jun 20 18:52:10 <Jay7> ... same error as ant_work today
Jun 20 18:52:22 <Jay7> | ubi-utils/libubi.c:1361:19: error: 'UBI_IOCSETPROP' undeclared (first use in this function)
Jun 20 19:58:04 <nitink> fray ping
Jun 20 19:58:43 <fray> I'm here
Jun 20 19:59:18 <nitink> I am getting some issue with dynamic linking
Jun 20 19:59:49 <nitink> fray: /bin/login: error while loading shared libraries: unexpected reloc type 0xc8
Jun 20 20:00:13 <fray> let me see if I can figure out what that is.. which target x32?
Jun 20 20:00:35 <nitink> no it is fri1- atom 32bit
Jun 20 20:01:39 <fray> I don't see any c8 reloc type
Jun 20 20:02:03 <fray> if you turn off the prelinker, any changes?
Jun 20 20:04:15 <nitink> Fray: I will try that
Jun 20 20:04:36 <nitink> fray: I also have issues with starting init on sugarbay
Jun 20 20:04:45 <nitink> there I tried disabling prelinker which did not help
Jun 20 20:05:35 <nitink> fray: all this is with 3.4 linux-yocto kernel
Jun 20 20:07:00 <fray> I don't know.. I've not see it then.. check w/ Khem, he might have an idea
Jun 20 20:32:33 <khem> nitink: thats an unknown reloc for ldso
Jun 20 20:32:42 <khem> you can approach this twofolds
Jun 20 20:32:50 <khem> 1. find the offending library first
Jun 20 20:33:15 <khem> 2. Make sure that library is using  right compiler flags e.g. fPIC -fPIE etc.
Jun 20 20:33:46 <khem> do you have a working set ? if yes then you can kind of bisect
Jun 20 20:35:45 <khem> Jay7: are your kernel headers upto date with what app is expecting ?
Jun 20 20:36:39 <Jay7> khem: [16:30] <ant_work> RP__: I'm experiencing strange issues with linux-libc-headers 3.4. The mtd/ubi-user.h in sysroot is *not* the one in 3.4 mainstream, is older (one ioctl was renamed).How can that happen?
Jun 20 20:36:49 <Jay7> I've not looked into yet
Jun 20 20:36:59 <Jay7> switched to other task :)
Jun 20 20:37:07 <RP__> Jay7: you're seeing it too?
Jun 20 20:37:28 <Jay7> RP__: yes, fresh oe-core + meta-initramfs + meta-handheld
Jun 20 20:37:44 <Jay7> build of zaurus-installer for akita
Jun 20 20:38:17 <RP__> There is something odd going on there. When did you last update before this?
Jun 20 20:38:24 <Jay7> btw, good idea to build only ubi-utils with oe-core
Jun 20 20:38:34 <zeddii> I'm not seeing it with just oe-core + meta-yocto FWIW.
Jun 20 20:38:36 <Jay7> RP__: right before building :)
Jun 20 20:39:29 <RP__> Jay7: I mean before it failed
Jun 20 20:39:47 <RP__> are we talking days? weeks? months?
Jun 20 20:40:06 <Jay7> oh, it was very aged installation
Jun 20 20:40:12 <Jay7> some month ago imho
Jun 20 20:40:20 <Jay7> but this was clean build
Jun 20 20:40:33 <Jay7> better to debug with ant then
Jun 20 20:40:39 <Jay7> he is building frequenly
Jun 20 20:40:49 <RP__> Jay7: I'm just trying to get a feel for when the regression may have come in
Jun 20 20:41:23 <RP__> I wonder if mtd-utils is overwriting headers or something
Jun 20 20:41:28 <Jay7> seems it come from meta-hh or meta-initramfs
Jun 20 20:41:39 <zeddii> RP__, I exchanged email on this today. and couldn't reproduce it here. so it's definitely from another layer
Jun 20 20:41:43 * zeddii was too slow.
Jun 20 20:42:09 <RP__> old version of mtd-utils pinned?
Jun 20 20:46:49 <khem> zeddii: can you share your workflow of managing the linux-yocto kernel
Jun 20 20:47:02 <khem> zeddii: how do you sync it with upstream etc.
Jun 20 20:47:48 <khem> meta-initramfs/recipes-devtools/mtd/ubi-utils-klibc_1.4.9.bb:SRC_URI = "git://git.infradead.org/mtd-utils.git
Jun 20 20:47:57 <khem> I think thats the problem for Jay7
Jun 20 20:48:51 <khem> oe-core mtd-utils is at ca39eb1d98e736109c64ff9c1aa2a6ecca222d8f
Jun 20 20:49:13 <zeddii> at the moment .. no. but later this week, sure. I'm pinned @ 100% for the next few days.
Jun 20 20:49:26 <khem> and the one from meta-initramfs is 995cfe51b0a3cf32f381c140bf72b21bf91cef1b
Jun 20 20:49:26 <zeddii> I have a huge queue of changes to get tested and out.
Jun 20 20:49:46 * zeddii heads out for a bit to get the kids.
Jun 20 20:49:55 <khem> zeddii: no problems
Jun 20 20:49:58 <Jay7> ah
Jun 20 20:49:59 <khem> whenever you have time
Jun 20 20:50:02 <Jay7> well, may be
Jun 20 20:50:07 <zeddii> khem, absolutely. I wrote it down :)
Jun 20 20:50:36 <khem> zeddii: carve it on stone please :)
Jun 20 20:50:57 * zeddii gets out a chisel.
Jun 20 20:51:23 <zeddii> later. 42 degrees C outside today. I may make it home alive .. or not.
Jun 20 20:51:58 <khem> zeddii: I need to give a workflow sometimes on various prcoesses and this would help a lot
Jun 20 21:36:01 <ant__> RP__: I've found out mtd-utils is responsible for mangling the mtd-headers. Purposedly?
Jun 20 21:43:44 <khem> zeddii: http://patchwork.openembedded.org/patch/30351/ :)
Jun 20 21:58:47 <nitink> khem: thanks for the tips
Jun 20 21:59:02 <nitink> khem same libraries work fine with 3.2 kernel
Jun 20 21:59:12 <khem> hmm
Jun 20 21:59:30 <khem> you mean if you sneak in 3.2 kernel beneath same rfs it works ?
Jun 20 22:00:01 <nitink> I updated kernel from 3.2 to 3.4
Jun 20 22:00:12 <nitink> so only change is kernel
Jun 20 22:00:17 <nitink> 3.2 image works fine
Jun 20 22:00:22 <nitink> 3.4 image does not
Jun 20 22:00:27 <khem> images is different story
Jun 20 22:00:44 <khem> cncan you try booting same image owith 3.2 and 3.4
Jun 20 22:01:02 <khem> since if you used different kernel headers a lot will change
Jun 20 22:01:03 <nitink> I see,
Jun 20 22:01:15 <nitink> can give it a try
Jun 20 22:02:00 <nitink> khem: with kernel I will also be switching initrd binary
Jun 20 22:04:20 <ant__> guys..I always spend time looking for irclogs.. please, in the Topic... one is http://logs.nslu2-linux.org/livelogs/yocto.txt
Jun 20 22:04:36 <ant__> khem: yes, prolly we need to update mtd-utils
Jun 20 22:06:53 <ant__> unfortunately http://git.infradead.org/ is out of reach atm
Jun 20 22:07:03 <nitink> khem: 3.4 kernel is also failing with 3.2 image same way
Jun 20 22:08:44 <nitink> and 3.2 kernel is booting fine with 3.4 rootfs image
Jun 20 23:58:50 <khem> nitink1: ok it seems some anamoly in kernel then
Jun 21 00:26:19 <seebs> Okay, this may be something super obvious to someone else, so...
Jun 21 00:26:48 <seebs> I'm having strange behaviors using an external toolchain with yocto.  The failure is that an initial build always comes up with two copies of all the binary locale packages, which is 153 ERROR lines, and aborts.
Jun 21 00:26:55 <seebs> If I just re-run the build, everything completes without difficulty.
Jun 21 00:27:40 <seebs> The issue *seems* to be, in a way I do not understand, tied to a desire to find a copy of usr/bin/localedef.  I am not sure why; the external toolchain configuration disables the locale generation, or at least seems to.
Jun 21 00:28:13 <seebs> And one thing that I am particularly confused by is that localedef is showing up in usr/include/eglibc-locale-internal-$MACHINENAME/usr/bin.
Jun 21 00:28:30 <seebs> This is clearly being done intentionally by eglibc-package's do_install_locale, but I can't find anything else that refers back to it.
Jun 21 00:31:33 <seebs> Hmm.  Come to think of it, eglibc-locale seems to use that.
Jun 21 00:32:18 <khem> is LOCALE_GENERATION_WITH_CROSS-LOCALEDEF set
Jun 21 00:32:59 <seebs> Doesn't seem to be.  Only LOCALE_GEN match in a bitbake -e is "ENABLE_BINARY_LOCALE_GENERATION="
Jun 21 00:33:09 <seebs> Which fits, because the external tcmode unsets that.
Jun 21 00:33:33 <seebs> It also sets GLIBC_INTERNAL_USE_BINARY_LOCALE = "precompiled"
Jun 21 00:33:48 <seebs> So I don't *think* anything should be needing to try to generate locale stuff to begin with.
Jun 21 00:33:56 <khem> right
Jun 21 00:34:00 <seebs> But then, I think it's actually looking for a target localedef.
Jun 21 00:34:15 <seebs> So it may be that it isn't requesting this to make locale files, but just because it's supposed to have one on the target anyway.
Jun 21 00:35:58 <seebs> So it seems like part of what's happening is that the external toolchain picks up eglibc-package, which dutifully stashes localedef in usr/include/blahblahblah, but never invokes the corresponding rule to copy that localedef back out of there into the sysroot.
Jun 21 00:36:34 <khem> you can add a SUPPORTED file for locales
Jun 21 00:36:58 <seebs> One is already present.  Our external toolchain stuff is eerily similar to a couple-week-old copy of the external-csl tcmode stuff.
Jun 21 00:37:09 <khem> ah ok
Jun 21 00:37:18 <seebs> Basically, it looks exactly like that plus some workarounds and variable overrides based on the specific binary toolchains we get.
Jun 21 00:37:27 <khem> sure
Jun 21 00:38:01 <seebs> I am sort of wondering whether I should just add a direct copy in of the localedef file, since I know where it is, and see whether that magically fixes it.  But I am sort of bothered by not being able to figure out what's happening.
Jun 21 00:38:08 <khem> when you say 2 copies is it the .ipk ?
Jun 21 00:38:30 <khem> yes that would be right thing
Jun 21 00:38:39 <khem> plus any assume provided needed
Jun 21 00:38:56 <khem> btw. does it compile any stuff from eglibc when building with external toolchain
Jun 21 00:39:01 <seebs> Yeah.  And that's what I'm not sure about -- thing is, I haven't figured out what's causing the other eglibc package to get invoked for this.
Jun 21 00:39:07 <seebs> Nope.  All precompiled.
Jun 21 00:39:26 <fray> missing provide?
Jun 21 00:39:39 <khem> yes that could be it
Jun 21 00:39:45 <seebs> So I'm assuming that some kind of PROVIDES or RPROVIDES would make this work (possibly accompanied by a manual copy of the missing binary), but I haven't figured out what it would be.
Jun 21 00:39:48 <khem> bitbake -g it and see
Jun 21 00:40:45 <seebs> Heh.  I'm not even sure what the *package name* is.  Heck, I'm not entirely sure the localedef thing is the actual problem, and not a red herring.
Jun 21 00:41:26 <seebs> I've got a build running with buildhistory on, hoping this will result in magical clarity.  :)
Jun 21 00:43:16 <khem> output_locale_binary_rdepends is magical function
Jun 21 00:44:21 <seebs> Yeah.  I can't even figure out whether the execution path is supposed to get to it.  I think I once convinced myself that it shouldn't because it was inside a test against ENABLE_BINARY_LOCALE_GENERATION.
Jun 21 00:44:38 <seebs> But my ability to follow execution of bitbake rules is not *quite* up to actually succeeding in that task.
Jun 21 00:46:05 <seebs> Ahh, there was a data point.  One of the other people looking at this tried renaming the eglibc-local-*.bb files, and a build failed because "nothing RPROVIDES localedef".
Jun 21 00:46:20 <seebs> er locale-*, I think.
Jun 21 00:46:33 <seebs> But that is where I got the idea that it was localedef, I think.
Jun 21 01:36:48 <nitink> khem: that is what I am thinking too, thanks for your help !
**** ENDING LOGGING AT Thu Jun 21 02:59:58 2012

**** BEGIN LOGGING AT Thu Jun 21 02:59:58 2012
Jun 21 06:50:59 <Majid> hi guys,
Jun 21 06:51:03 <Majid> quack start guide for fedora
Jun 21 06:51:19 <Majid> xsltproc, eglibc-devel, python-psyco is not included in the fedora 17 repositories
Jun 21 06:51:21 <Majid> any solution?
Jun 21 07:10:45 <Majid> how to install eglibc-devel in fedora 17 scince it is not in the repository
Jun 21 12:27:52 <awafaa> rburton: cooey :)
Jun 21 12:28:03 <slaine> he's here, quick, hide
Jun 21 12:28:33 <awafaa> slaine: it's very easy to go off people! :P
Jun 21 12:28:42 <slaine> lol
Jun 21 12:34:07 <awafaa> is there a way of using a different toolchain? Specifically i'd like to use the Linaro toolchain
Jun 21 12:34:45 <RP__> awafaa: Its certainly possible and people have done it before. We're lacking good documentation about it at the moment though. The CSL external toolchains are known to work well at leasty
Jun 21 12:44:24 <ant_work> RP__: about mtd-utils, probably today can be built w/out staging (at least the basic headers are already there, unsure about jffs2 and ubi-media)
Jun 21 12:45:05 <ant_work> anyway I've asked in #mtd whether they plan to synch with kernel again. They did that almost regularly before
Jun 21 12:47:59 <awafaa> RP__: ok so that's a start I suppose. Is there bad documentation as a starter for 5?
Jun 21 12:49:38 <RP__> awafaa: various mailing list posts at times, try the archives
Jun 21 12:49:52 <awafaa> thanks
Jun 21 13:33:55 <rburton> hi awafaa  :)
Jun 21 15:06:29 <kergoth> morning
Jun 21 15:06:34 * kergoth yawns
Jun 21 15:12:09 <denisATeukrea> hi, how are the sato images supposed to launch sato? here we use xserver-nodm
Jun 21 15:12:25 <denisATeukrea> so first it doesn't find x-window-manager
Jun 21 15:12:27 <denisATeukrea> so I add it
Jun 21 15:12:33 <denisATeukrea> but then I've a blank screen
Jun 21 15:12:47 <denisATeukrea> probably that x-session-manager is not launched
Jun 21 15:12:56 <denisATeukrea> so after launching it I've the icons and such
Jun 21 15:13:01 <denisATeukrea> but no top-bar
Jun 21 15:13:48 <denisATeukrea> ah maybe the theme is wrong then
Jun 21 15:16:36 <denisATeukrea> ah ok, it seem that the thing to launch is x-session-manager
Jun 21 15:16:44 <denisATeukrea> and not x-window-manager as usual
Jun 21 15:30:03 <autif> denisATeukrea: yes - thats true - in fact I have modified matchbox session file to launch my app instead of matchbox desktop
Jun 21 15:30:48 <autif> denisATeukrea:  very soon we realized that X is not a window manager and we needed one - the default window placement was not what we liked
Jun 21 15:31:16 <denisATeukrea> ok
Jun 21 15:31:21 <denisATeukrea> so what should I do?
Jun 21 15:31:35 <denisATeukrea> xserver-nodm expects x-window-manager....
Jun 21 15:32:23 <denisATeukrea> and it works fine with other wm like enlightenment that update-alternative e-wm for x-window-manager
Jun 21 15:32:43 <denisATeukrea> I think the ideal should be to rename it in x-window-manager
Jun 21 15:32:50 <denisATeukrea> but I guess it would break some stuff
Jun 21 15:33:03 <denisATeukrea> because I guess something expect x-session-manager
Jun 21 15:33:17 <autif> yup
Jun 21 15:33:42 <denisATeukrea> so my question was what expects x-session-manager
Jun 21 15:33:47 <denisATeukrea> because I could change that too
Jun 21 15:33:47 <autif> actually if you chase startx/xinit etc down - it will lead to x-session-manager
Jun 21 15:33:55 <denisATeukrea> ok
Jun 21 15:34:23 <denisATeukrea> so do we keep x-window-manager or x-session-manager?
Jun 21 15:34:49 <autif> what we found simplest was to keep matchbox and start our custom app (webkit based browser - full screen etc) from the 'session' file in matchbox-session-sato recipe
Jun 21 15:35:04 <autif> you need to keep both x-window manager and x-session manager
Jun 21 15:35:12 <denisATeukrea> ah ?
Jun 21 15:35:12 <autif> i think
Jun 21 15:35:16 <autif> let mecheck that
Jun 21 15:35:22 <denisATeukrea> so I could do something like that then
Jun 21 15:35:29 <denisATeukrea> if x-window-manager is not there
Jun 21 15:35:35 <denisATeukrea> start x-session-manager
Jun 21 15:35:41 <denisATeukrea> in xserver-nodm
Jun 21 15:38:28 <autif> hmmn - it seems like the scripts look for x-window manager and x-session manager and which ever is found first is used
Jun 21 15:38:43 <autif> so, I guess either would do code wise
Jun 21 15:38:54 <autif> in my case - there is no x-window manager
Jun 21 15:39:12 <autif> only an x-sesson manager - symlinked to /usr/bin/matchbox-session
Jun 21 15:39:47 <denisATeukrea> ok here too only that xserver-nodm expects an x-window-manager which break matchbox starting
Jun 21 15:40:03 <autif> hmmmn
Jun 21 15:40:11 <autif> let me check that too
Jun 21 15:40:24 <denisATeukrea> I'm on denzil btw
Jun 21 15:41:56 <RP__> denisATeukrea: you might want to look at the mini-x-session or whatever its called, that just starts a simple app
Jun 21 15:42:01 <RP__> (hob)
Jun 21 15:42:08 <autif> oooh - i donot have that - I am on crownbay - version 1.2 - I am not sure what has changed since then - actually 1.2 (final) has been working _perfectly_ for me now - dont know about denzil
Jun 21 15:42:11 <autif> sory!
Jun 21 15:42:27 <autif> RP to the rescue :-)
Jun 21 15:42:42 <denisATeukrea> ok
Jun 21 15:48:49 <denisATeukrea> RP__, my main issue is that xserver-nodm expects x-window-manager and that matchbox exports x-session-manager
Jun 21 15:49:16 <denisATeukrea> but I'll look into mini-x-session very soon(as soon as the new image finishes do_rootfs)
Jun 21 15:50:21 <autif> BTW, 1.2 crownbay images do not have x-window-manager in xserver-nodm - this may have changed for denzil - I do not know, just a guess
Jun 21 15:50:33 <denisATeukrea> ok
Jun 21 15:50:43 <denisATeukrea> what's crownbay btw?
Jun 21 15:50:51 <denisATeukrea> a machine or a new branch?
Jun 21 15:50:57 <autif> machine
Jun 21 15:51:01 <RP__> denisATeukrea: isn't that from matchbox-session?
Jun 21 15:51:05 <autif> is denzil a branch?
Jun 21 15:51:10 <denisATeukrea> autif, yes
Jun 21 15:51:12 <autif> wow!
Jun 21 15:51:25 <autif> I guess I should read up, explore that
Jun 21 15:51:37 <denisATeukrea> autif, it's a released stable branch
Jun 21 15:51:40 <autif> its not the codename for 1.3. is it?
Jun 21 15:51:47 <denisATeukrea> 1.2 I think
Jun 21 15:51:59 <autif> oh - I am indeed using 1.2
Jun 21 15:52:23 <autif> just did not know it is called denzil
Jun 21 15:52:30 <denisATeukrea> ok
Jun 21 15:54:14 <denisATeukrea> autif, maybe you're using a tag and not a branch?
Jun 21 15:55:09 <autif> we switched to tar balls that were announced
Jun 21 15:55:22 <denisATeukrea> ok
Jun 21 15:56:51 <autif> denisATeukrea: on a very different note - long time ago when you released meta-chromium - we explored it and I think we exchanged a few emails - it saddens me to share that we will not be able to contribute x86 back - mostly because it was deemed that webkit based browser would be enough for our needs - there is no need to put resources on meta-chromium - Just thought that I should share this with you. Sorry!
Jun 21 15:57:00 <denisATeukrea> autif, I think the branches have bugfixes that the tarball lacks
Jun 21 15:57:14 <autif> cool - will check it out
Jun 21 15:57:44 <denisATeukrea> autif, about meta-chromium, did you share what you did already?
Jun 21 15:57:59 <denisATeukrea> and it's now called meta-browser....
Jun 21 15:58:59 <denisATeukrea> note that it works fine with gcc 4.6 but not 4.7 for chromium and firefox is broken for gcc 4.6 and 4.7 but works with gcc 4.5(which has been removed btw)
Jun 21 15:59:07 <denisATeukrea> (removed in master)
Jun 21 16:00:01 <denisATeukrea> let's see mini-x-session
Jun 21 16:00:44 <denisATeukrea> about the browser you mean something like midori
Jun 21 16:01:00 <denisATeukrea> because many browser are webkit based including midori and chromium
Jun 21 16:03:06 <denisATeukrea> I'll go, bye
Jun 21 16:03:21 <denisATeukrea> normally I'll be back tomorrow
Jun 21 17:36:48 <mranostay> gcoville: i see you :P
Jun 21 19:15:37 <fray> looking for docs or something.. I've made an SDK image.. how do I actually use it to build software?
Jun 21 19:16:11 <fray> it appears that you need to run some script against it to set it up, and then source some environment stuff as well.. but I'm not sure what I need to do.. and a quick google search with SDK only showed me how to run qemu w/ the SDK..
Jun 21 19:32:55 <seebs> So, I am looking at locale stuff, and I have concluded that there is a sort of strange conflict between the external toolchain stuff and eglibc-package/eglibc-locale.
Jun 21 19:33:30 <seebs> The manifestation is that the external toolchain pulls in eglibc-package.inc, which then moves stuff like localedef into /usr/include/eglibc-locale-internal-$MACHINESTUFF.
Jun 21 19:33:38 <seebs> eglibc-locale then knows to pull the stuff back from there.
Jun 21 19:33:58 <seebs> Thing is, this means that if something wants localedef, it ends up picking up the native eglibc-locale, which conflicts with some of the external-toolchain stuff.
Jun 21 19:34:46 <seebs> My vague thought is that perhaps the executable packages, as opposed to locale data, should be handled by eglibc proper, and not be stashing stuff in /usr/include at all.
Jun 21 19:35:06 <seebs> Question is, does anyone (kergoth especially) have strong opinions on this, or an explanation of why it is the way it is?
Jun 21 19:37:18 <kergoth> don't know much about that, last time i'd looked at eglibc before messing with external toolchain was before eglibc-locale even existed. figured we'd just do the same thing the actual eglibc recipe does and it'd at least be consistent between internal and external toolchains
Jun 21 19:37:27 * kergoth shrugs
Jun 21 19:38:59 <seebs> I may send out a proposed-fix which migrates a couple of things around, because right now, the best fix I've got for a case where something wants localedef and uses our prebuilt toolchain...
Jun 21 19:39:09 <seebs> well, I think I can summarize it all with "addtask do_undo_install_locale ..."
Jun 21 19:40:05 <seebs> My mission in life is to make the eyes of code reviewers bleed, and then destroy all hope in their souls when they realize that there are sound technical justifications.
Jun 21 19:42:41 <khem> seebs: why not let external toolchain provide eglibc-locale too
Jun 21 19:43:06 <khem> seebs: and cut the connection of packaging asking for internal eglibc-locale
Jun 21 19:43:15 <seebs> I think it does, but it doesn't provide localedef.  And the trick is, for it to provide localedef, it needs access to usr/bin/localedef -- which the required eglibc-package.inc has just moved into /usr/include.
Jun 21 19:43:31 <khem> ah, so localedef is not there at all ?
Jun 21 19:43:35 <khem> in CSL toolchain
Jun 21 19:43:37 <seebs> So my fix involves two things:  First, adding localedef to the PACKAGES += list in our eglibc.
Jun 21 19:43:49 <seebs> (And FILES_localedef = /usr/bin/localedef).
Jun 21 19:44:08 <seebs> Second, making a second task that runs after the eglibc-package do_install_locale, which moves localedef back from /usr/include into /usr/bin.
Jun 21 19:44:12 <khem> localedef is a native tool right ?
Jun 21 19:44:31 <seebs> There are many localedefs.  This is in reference to the target binary.
Jun 21 19:44:35 <fray> what actually puts it into /usr/include?
Jun 21 19:45:02 <khem> target localedef hmm ok so as I understand CSL does not provide this binary in toolchain blob
Jun 21 19:45:04 <seebs> The do_install_locale task in eglibc-package.  The external CSL toolchain is requiring eglibc-package.inc, because most of the rules there for packaging eglibc are useful and don't need to be duplicated.
Jun 21 19:45:18 <seebs> CSL does provide it.  Or at least, they do in the custom toolchain blobs they make for us.
Jun 21 19:45:42 <seebs> The problem is that eglibc-package.inc is moving usr/bin/localedef into a Completely Different Place, where eglibc-locale.inc then picks it up.
Jun 21 19:45:47 <fray> seebs, so do_install_locale is moving it to /usr/include, well something else in the (stock) toolchain also must be moving it to /usr/bin or it'd blow up
Jun 21 19:45:49 <khem> ok, so you need to stuff it into the intermediate staging
Jun 21 19:46:01 <seebs> Right.  In the stock toolchain:
Jun 21 19:46:06 <seebs> * localedef is built as part of eglibc
Jun 21 19:46:12 <seebs> * eglibc then moves it into a stash in /usr/include
Jun 21 19:46:25 <seebs> * eglibc-locale then moves it into *its* usr/bin, so it can package up target localedef.
Jun 21 19:46:54 <seebs> The problem is that this results in eglibc-locale being brought in if anyone asks for localedef, and that clashes with other parts of the external-csl-toolchain stuff.  (And probably with the newer -sourcery stuff, too.)
Jun 21 19:47:08 <fray> gotcha..
Jun 21 19:47:24 <seebs> My thought is that it might be simpler to have those packages that are for target binaries that were built as part of eglibc to be packaged up by eglibc-package.inc, rather than stashed, and not used at all by eglibc-locale.inc.
Jun 21 19:47:24 <fray> so the right answer is basically what you did.. move it back and package eglibc-locale in as part of it
Jun 21 19:48:09 <seebs> My sort of thought is that these packages, while related to locale data, make slightly more sense as part of the base eglibc package.
Jun 21 19:48:34 <fray> in the base thing the lcoales are optional which is why it's stuff off and done as a separate item
Jun 21 19:48:58 <khem> seebs: which part of code is stashing it into /usr/include
Jun 21 19:49:23 <seebs> the do_install_locale task in eglibc-package.inc.  (This is added with addtask, it's after install and before sysroot and package.)
Jun 21 19:49:41 <seebs> This took me the longest time to figure out, because I couldn't imagine why anyone would move binaries into /usr/include.
Jun 21 19:52:13 <khem> hmmm so actually stashing should only be done for locales and not for localedef itself
Jun 21 19:53:04 <seebs> well, that's the thing.  It's being done only for target binaries, so far as I can tell -- stuff like gconv and localedef.
Jun 21 19:53:24 <seebs> And I think the "right" answer is that they should be being packaged as part of eglibc-package.inc, rather than stashed for eglibc-locale to work on them.
Jun 21 19:53:30 <seebs> But I am not totally sure.
Jun 21 19:53:41 <khem> yes I wonder that too
Jun 21 19:54:09 <fray> if I remebmer right, it's doing it because the stuff gets packaged separetly..  it may not be the right approach?
Jun 21 19:54:25 <fray> the binaries for locales are seperate from the locales themselves..
Jun 21 19:55:25 <khem> oh this is to separate eglibc-locale into a separate recipe
Jun 21 19:55:47 <khem> same stuff we do with libgcc and other gcc friends
Jun 21 19:56:10 <fray> the seperation is due to build performance..
Jun 21 19:56:10 <khem> eglibc-locale is a separate recipe not only package
Jun 21 19:56:22 <fray> if the lcoales are generated at the same time as eglibc, it's a -huge- time sink..
Jun 21 19:56:24 <khem> I wonder
Jun 21 19:56:25 <seebs> Yeah.
Jun 21 19:56:35 <fray> break it into a seperate recipe, and they can be generated in parallel with all of the other things going on
Jun 21 19:56:41 <khem> it kind of decouple eglibc proper for locales
Jun 21 19:56:43 <seebs> My thought is that it is probably not correct to logically bundle "the target binaries for locale" and "the locale data".
Jun 21 19:56:48 <fray> yes
Jun 21 19:56:52 <khem> so stuff depending on eglibc can start building early
Jun 21 19:57:01 <fray> seebs, ya.. I'm wondering that
Jun 21 19:57:03 <seebs> I think the target binaries should be viewed as part of eglibc's toolkit, and the locale data should be separate.
Jun 21 19:57:18 <khem> yes agreed
Jun 21 19:57:28 <fray> well.. they should still be broken out.. cause if you don't need locales, you don't need (target) localedef...
Jun 21 19:57:38 <fray> but ya.. bundle w/ eglibc.. and the locales themsevles are external
Jun 21 19:58:16 <khem> actually I wonder why we did not just create independent recipes compeltely
Jun 21 19:58:29 <fray> no idea
Jun 21 19:58:39 <fray> I just know why it was broken into two components
Jun 21 19:58:40 <khem> hmmm it needs access to eglibc build tree otherwise I see
Jun 21 19:58:44 <khem> for locales
Jun 21 19:58:49 <fray> ahh ok
Jun 21 19:58:52 <fray> that makes sense
Jun 21 20:00:58 <khem> but I still wonder one thing if suppose you have locales enables they will be generated completely
Jun 21 20:01:04 <khem> before eglibc build completes
Jun 21 20:01:08 <khem> so how does it speed it up
Jun 21 20:01:16 <seebs> Well, doesn't affect us, because we're using precompiled ones.
Jun 21 20:01:33 <seebs> I *think* the idea is that the eglibc-locale package separates the generation out, so it doesn't need to happen as part of glibc.
Jun 21 20:01:39 <khem> I understand
Jun 21 20:01:48 <khem> this was done to speed up internal toolchain builds
Jun 21 20:01:59 <khem> so rather how much speedup do we get
Jun 21 20:02:21 <khem> addtask do_install_locale after do_install before do_populate_sysroot do_package
Jun 21 20:02:29 <khem> so it is being done before do_populate_sysroot
Jun 21 20:02:41 <seebs> yeah.  and all it does is move-or-copy some files into /usr/include.
Jun 21 20:02:45 <khem> all other packages waiting for eglibc to finish will have to wait
Jun 21 20:02:52 <seebs> Heck, if it were just a copy rather than a move I wouldn't care.
Jun 21 20:02:55 <khem> for all locales
Jun 21 20:04:04 <khem> eglibc-locale pretty much does is packaging the generated data
Jun 21 20:04:15 <khem> which can be quite long since you have so many packages to spit out
Jun 21 20:04:23 <seebs> yeah.
Jun 21 20:04:51 <khem> but do_package is performed after do_populate_sysroot
Jun 21 20:04:55 <seebs> I *think* it would still work comparably well if it only did the generated data, and we moved the target binaries back into eglibc proper.  Would certainly improve my life.
Jun 21 20:05:12 <khem> and other tasks waiting on eglibc should be free to run after do_populate_sysroot of eglibc has been done
Jun 21 20:05:14 <seebs> I might to a test run or two of this with that change and see whether it seems to work.
Jun 21 20:05:25 <khem> they dont have to wait for do_package which will then do fancy packaging
Jun 21 20:05:32 <khem> so I still dont understand the separation
Jun 21 20:05:39 <khem> may be I am missing some big point
Jun 21 20:05:54 <seebs> I *think* eglibc-locale is what actually does the non-trivial generation of locale data, too.
Jun 21 20:06:25 <khem> LOCALE_GENERATION_WITH_CROSS-LOCALEDEF = "1"
Jun 21 20:06:31 <khem> is set in recipe hmmm
Jun 21 20:06:32 <khem> ok
Jun 21 20:07:09 <khem> inherit libc-package
Jun 21 20:08:49 <kergoth> seebs: what exactly are you seeing as conflicting between eglibc-locale and the external toolchain stuff? the external toolchain recipe does not do any of the locale packaging.
Jun 21 20:09:00 <seebs> The behavior we get is:
Jun 21 20:09:17 <khem> localedef is a package spit out from eglibc-locale recipe
Jun 21 20:09:20 <seebs> If I don't fix this, the first time we try to do a build of our whole glibc_std filesystem, we get 100+ errors about locale.mumble being in PACKAGES more than once.
Jun 21 20:09:25 <kergoth> i've built a variety of images which include bits from eglibc-locale just fine
Jun 21 20:09:28 <seebs> Interestingly, rebuilds are fine.
Jun 21 20:09:47 <seebs> If I do change this so that localedef is coming from our local copy of external-csl-toolchain, there's no error.
Jun 21 20:10:02 <kergoth> i'd suggest finding and fixing the real root cause.
Jun 21 20:10:07 <kergoth> *why* is that ending up in packages more than once?
Jun 21 20:10:43 <khem> seebs: did you stuff external localedef into /usr/include stagign ?
Jun 21 20:11:00 <khem> I think if you do that then eglibc-locale:do_install will be happy i guess
Jun 21 20:11:28 <seebs> Yes, but that's the thing -- if eglibc-locale gets brought in to do that, we get the packaging list problem.
Jun 21 20:11:32 <khem> you need to break the dependence of eglibc-locales from eglibc
Jun 21 20:11:46 <khem> hmmm
Jun 21 20:11:51 <khem> ok
Jun 21 20:12:16 <khem> so csl toolchain has everything right it just needs to be packaged no data generation is needed right ?
Jun 21 20:12:27 <seebs> And I am not sure why, but it appears to be the case that, with the system as-is, if something asks for localedef (which is apparently not normally the case; it only seems to show up because of something extra that we're installing, I think), we end up with that error.  Once.  A rebuild doesn't show it.
Jun 21 20:12:28 <seebs> Yes.
Jun 21 20:12:53 <kergoth> khem: we set varaibles in the tcmode to avoid recompilation of the locale files
Jun 21 20:12:56 <seebs> So the problem *seems* to be that, if we don't have eglibc-locale or add localedef to our toolchain recipe, the system fails because it can't find a provider for localedef.
Jun 21 20:13:22 <seebs> If we have the eglibc-locale stuff, somehow it ends up clashing with Something Else, but (even weirder) only does so once.
Jun 21 20:13:35 <kergoth> localedef is just one of many packages that come from eglibc-locale. i'm sure you'd see this with any of them added to your image
Jun 21 20:13:36 <khem> seebs then add localedef to provided
Jun 21 20:13:57 <kergoth> so again, ignore localedef, find the real cause of the issue. tehre should be no problem building eglibc-locale and using any of its packages
Jun 21 20:14:00 <kergoth> afaict anyway
Jun 21 20:14:05 <khem> what pulling in eglibc-locales would be interesting bitbake -g can help here
Jun 21 20:14:15 <kergoth> could be wrong, i haven't touched any of this in weeks, just back from hawaii
Jun 21 20:14:36 <seebs> That does make sense.  I am not sure how to check which things have added a given thing to PACKAGES, though.
Jun 21 20:15:02 <kergoth> look at calls to do_split_packages, etc. thats how packages are added programmatically
Jun 21 20:15:05 <khem> seebs: post your .dot files from bitbake -g run somewhere
Jun 21 20:15:07 <kergoth> erm, do_split_locale
Jun 21 20:15:10 <khem> for the failing case
Jun 21 20:15:50 <khem> kergoth: as I understand with external toolchain eglibc-locale recipe should be completely ignored
Jun 21 20:16:00 <kergoth> khem: that's not my understanding.
Jun 21 20:16:06 <khem> hmm
Jun 21 20:16:06 <kergoth> how else are you going to get the locale packages split out?
Jun 21 20:16:14 <kergoth> the extenral toolchain recipes do not do this
Jun 21 20:16:21 <khem> kergoth hmm
Jun 21 20:16:26 <seebs> Huh.  That is an interesting point.  So we almost have to be loading it.  So now I'm even more confused.  :)
Jun 21 20:16:30 <halstead> sgw, I've deactivated several of the milestones and versions on https://bugzilla.yoctodev.org/ does it look better when updating bugs?
Jun 21 20:16:34 <khem> so why need a recipe
Jun 21 20:16:36 <kergoth> eglibc-locale splits them out, whether it *generates* them is a separate issue, controlled by GLIBC_INTERNAL_USE_BINARY_LOCALE
Jun 21 20:16:45 <khem> why not add a function in external toolchain recipe
Jun 21 20:16:52 <khem> inherit libc-package
Jun 21 20:16:54 <khem> or something
Jun 21 20:17:05 <seebs> Well, this is interesting.  I observe that on a successful build with my "fix" in place, there is NO reference to eglibc-locale.
Jun 21 20:17:07 <kergoth> i don't see why we'd want to duplicate what eglibc-locale is already doing
Jun 21 20:17:11 <kergoth> unless there's a real reason for it
Jun 21 20:17:22 <kergoth> but that's jsut my opinion
Jun 21 20:17:36 <seebs> So I don't think eglibc-locale is getting hit.  So now I'm even more confused.
Jun 21 20:17:44 <khem> kergoth: then we need to play by internal toolchain build rules
Jun 21 20:17:55 <kergoth> khem: i don't know what yo mean by that
Jun 21 20:17:57 <khem> which means stash the localedef into /usr/locale blah
Jun 21 20:18:03 <kergoth> we put the files in the same place the internal toolchain recipes do
Jun 21 20:18:03 <khem> err usr/includ
Jun 21 20:18:14 <khem> ok thats what I meant
Jun 21 20:18:35 <khem> so eglibc-locale package will then find the localedef from external toolchain correctly
Jun 21 20:18:47 * kergoth tests adding localedef to an image
Jun 21 20:18:52 <khem> and execute its do_install properly
Jun 21 20:19:35 <seebs> Yes.
Jun 21 20:19:40 <seebs> That part works.
Jun 21 20:19:44 <khem> ok
Jun 21 20:20:06 <seebs> So if I can figure out what's causing these clashes, maybe I can fix that.  I guess the thing that confuses me is that, if I move localedef into the toolchain recipe, I no longer see any reference to eglibc-locale.
Jun 21 20:20:20 <seebs> So far as I *know* we're still generating locale data.
Jun 21 20:20:29 <khem> that seems wrong then
Jun 21 20:20:31 <kergoth> that doesn't mean you necessarily are including the locale packages in your images
Jun 21 20:20:35 <kergoth> not all images do so, afaik
Jun 21 20:20:40 <kergoth> e.g. core-image-minimal dose not
Jun 21 20:21:00 <kergoth> also depends on the value of IMAGE_LINGUAS, iirc
Jun 21 20:21:06 <seebs> Yeah.  But if I don't make this change, we get it reported that they're present twice.  Which makes me *think* that we're including them.
Jun 21 20:21:30 <kergoth> why?
Jun 21 20:21:40 <kergoth> just because something is being put in PACKAGES doesn't mean you're putting it in an image
Jun 21 20:21:45 <seebs> Oh, point.
Jun 21 20:21:52 <khem> make sure that inputs to do_install_locale are available as it expects
Jun 21 20:22:09 <seebs> Yeah, do_install_locale is finding all the stuff it wants.  That part's fine, so far as I can tell.
Jun 21 20:22:27 <kergoth> clearly there's a bug, if that error is showing up, i'm just not sure we're chasing it in the right place
Jun 21 20:22:45 <seebs> It's just that when we get to the do_package phase for something (I think eglibc-locales, but I'm not sure), suddenly we get these huge piles of errors.
Jun 21 20:22:46 <khem> so it complains about packaging them then ?
Jun 21 20:22:48 * kergoth tries to repro
Jun 21 20:22:59 <khem> hmm
Jun 21 20:23:00 <seebs> And weirder still, simply re-running the build makes no errors.
Jun 21 20:23:21 <kergoth> khem: apparently eglibc-locale's packaging phase is saying certain things are lsited in its PACKAGES variable more than once
Jun 21 20:23:32 <kergoth> i remember seeing that once, but i thought it was resolved.. apparently not
Jun 21 20:23:52 <seebs> Except I'm not totally sure it was eglibc-locale, it might have been something else.  I need to find this.  Unfortunately, mostly I have "last N lines of errors" listings, which don't show what generated the errors.
Jun 21 20:24:05 <khem> PACKAGES_DYNAMIC makes me puke
Jun 21 20:24:25 <kergoth> seebs: man, i really want to add something to bitbake to inject task info into any log messages coming from a task
Jun 21 20:24:55 <seebs> Yeah.  That would be super handy.
Jun 21 20:25:15 <seebs> Huh.  It *looks* like what's actually biting me is task-core-basic-1.0-r4, task do_package.
Jun 21 20:25:22 <seebs> Wait, no.
Jun 21 20:25:23 <kergoth> hmm, odd
Jun 21 20:25:42 <seebs> Because the 150 lines of errors are followed bt "task-core-basic-1.0-r4: task do_package: Succeeded".
Jun 21 20:25:54 <kergoth> can you grep the do_package logs in the workdirs, rather than the server og?
Jun 21 20:26:39 <seebs> Probably, but I'll have to ask how I get to the build machine.
Jun 21 20:26:42 <kergoth> i need to remember to stop using core-image-minimal as a build test. need to start using core-image-base instead
Jun 21 20:26:44 <kergoth> ahh
Jun 21 20:26:52 <kergoth> hmm
Jun 21 20:29:13 <kergoth> as khem says, we could certainly add libc-pakage & the like to the recipe and avoid eglibc-loale e ntirely, but it seems like unnecessary duplication. also, i wasn't sure every external toolchain would have the precompiled locale files. haven't looked at any but sourcery for that
Jun 21 20:29:18 <kergoth> heh
Jun 21 20:31:03 <seebs> argh
Jun 21 20:31:12 <seebs> There are multiple packages running various phases at once.
Jun 21 20:31:22 <seebs> And I cannot figure out which phase of which package generated these messages.  :P
Jun 21 20:31:43 <seebs> Well, I can look at individual do_package logs.
Jun 21 20:32:30 <seebs> Wat.  This is crazy.  The last line of the log, after the 153 errors, is "... all succeeded."
Jun 21 20:35:40 <seebs> Okay, it is eglibc-locale-2.15-r20.
Jun 21 20:37:27 <seebs> Huh, that's odd.  About half the locale package names end with a period, others don't.
Jun 21 20:38:11 <kergoth> hmm
Jun 21 20:38:59 <seebs> oohhh
Jun 21 20:39:02 <seebs> hey that's interesting
Jun 21 20:39:38 <seebs> The list of errors is EXACTLY the list of packages with periods after their names.
Jun 21 20:39:59 <kergoth> the period, afaik, separates the base locale name from the character set
Jun 21 20:40:04 <kergoth> e.g. en_us vs en_us.utf-8
Jun 21 20:40:20 <seebs> yes.  And we have a bunch of packages with names like "locale-base-aa-dj."
Jun 21 20:40:23 <kergoth> so it's getting an empty sting for the charset, it seems
Jun 21 20:40:25 <seebs> With no character set.
Jun 21 20:40:29 * kergoth nods
Jun 21 20:40:34 <kergoth> interesting
Jun 21 20:40:54 <seebs> And we have 153 errors about package names ending in '.' being in the list twice.  And 146 packages with names ending in '.'.
Jun 21 20:41:49 <seebs> And a few of the packages are in the list of errors twice, but most aren't.
Jun 21 20:42:09 <seebs> And there's three of locale-base-zh-cn.
Jun 21 20:42:16 <kergoth> weird
Jun 21 20:42:42 <kergoth> iirc it pulls the list of locales/charsets from the SUPPORTED file, unless you specify the list of ones to generate
Jun 21 20:43:30 <seebs> hmm
Jun 21 20:43:43 <kergoth> though, i think it uses it even then, but just as a map of locale name to charset
Jun 21 20:43:58 <seebs> I am now starting to be highly suspicious that the eglibc-locale package list generation is buggy.
Jun 21 20:44:09 <kergoth> i had to change how that stuff worked a bit, because oe's recipes assume that non-suffixed locales are utf-8, ubt most desktps do not do that, and the sourcery toolchain does not do that either
Jun 21 20:44:15 <seebs> Because the ones that are being listed are things that have more than one character set.
Jun 21 20:44:34 <seebs> And zh-cn is listed as occurring multiply three times, and I think that is a language likely to have many character sets available.
Jun 21 20:46:12 <seebs> hmm.
Jun 21 20:46:33 <seebs> okay, locale-base-* is in PACKAGES_DYNAMIC, but how is the list actually getting generated, I wonder?
Jun 21 20:46:39 <kergoth> see line 120 down in libc-package.bbclass. even more specifically, see line 212 and lines 334 through 354
Jun 21 20:46:45 <fray> generated in the bbclass
Jun 21 20:47:13 <seebs> hmm
Jun 21 20:47:34 <fray> I think we need to understand the generation expectations and then match the binary to it
Jun 21 20:47:40 <kergoth> do_split_packages() takse patterns and wildcards and generates multiple packages based on what files exist,, adding those packages to PAckAGES
Jun 21 20:47:59 <seebs> hmm
Jun 21 20:48:44 <seebs> oh VERY suspicious
Jun 21 20:48:53 <seebs> ls | grep '\.' | wc -l => 155
Jun 21 20:49:07 <seebs> That's within two of being the number of failures, and whaddya know.  There's four zh_CN locales.
Jun 21 20:49:17 <seebs> Which would yield three occurs-multiple-times.
Jun 21 20:49:52 <seebs> Yeah.  Sure enough.  Anything there's three versions of, we got two multiple-times warnings.
Jun 21 20:49:57 <seebs> So I betcha the regex is wrong.
Jun 21 20:50:37 <kergoth> hmm, are you using the SUPPORTED file from the oe-core recipe, or your own?
Jun 21 20:50:48 <seebs> We're using the one that came with the CS toolchain, I think.
Jun 21 20:50:55 <seebs> Or with the old external-csl-toolchain.
Jun 21 20:52:27 <kergoth> hmm, is the tcmode setting GLIBC_INTERNAL_USE_BINARY_LOCALE ?
Jun 21 20:53:08 <seebs> I believe so.
Jun 21 20:53:15 <kergoth> k
Jun 21 20:53:43 <seebs> hmmm
Jun 21 20:53:59 <seebs> I am wondering whether I should be distrusting legitimize_package_name.
Jun 21 20:54:14 <seebs> Because if that were stripping the .* from the end of names, it would cause the kinds of problems we're seeing.
Jun 21 20:55:10 <seebs> Hmm.  I don't think so.  It's doing <Uxxxx>, and replacing _@,/ with -++-, but that shouldn't matter.
Jun 21 20:55:52 <seebs> ohhhh
Jun 21 20:55:54 <seebs> hang on.
Jun 21 20:56:28 <seebs> Okay, we have dot_re which is (.*)\.(.*)
Jun 21 20:57:16 <seebs> So if we get foo.bar, we end up calling output_locale('foo.bar', 'foo', supported['foo.bar]'), I think.
Jun 21 21:02:28 <seebs> I do not understand the SUPPORTED file.  It appears to be a 1-1 map from locale names to character sets, but our locale directory has multiple character sets for some locales.
Jun 21 21:06:46 <kergoth> hmm, yes, i don't think this file is right, at least for what we need out of it
Jun 21 21:07:19 <seebs> I honestly don't see how that matters, because it LOOKS as though it should be making a list of all the directories in the locale directory, and making a package named after each.
Jun 21 21:07:20 <kergoth> it needs to map the full name (e.g. en_US.UTF-8 or en_US) to charset, not the base name (en_US)
Jun 21 21:07:41 <kergoth> thats extremely nontrivial. thats what the code used to do, listdir on the locales dir
Jun 21 21:07:49 <kergoth> but how are you going to magically fix the naming mismatch?
Jun 21 21:07:52 <seebs> Hmm.
Jun 21 21:07:55 <kergoth> e.g. en-us vs en_US
Jun 21 21:08:03 <khem> kergoth both mean same
Jun 21 21:08:07 <seebs> Well, huh.  Now I'm more confused.
Jun 21 21:08:09 <kergoth> khem: and?
Jun 21 21:08:23 <seebs> locale-base-foo-bar is added to PACKAGES by output_locale.
Jun 21 21:08:27 <khem> so essential in this case _ = - and US = is
Jun 21 21:08:28 <khem> us
Jun 21 21:08:39 <seebs> Which adds MLPREFIX + locale-base- + legitimize_package_name(name) to PACKAGES.
Jun 21 21:09:11 <seebs> And this is done for everything in to_generate, and the raw names in to_generate are what are passed in as "name".
Jun 21 21:09:15 <khem> so it ends up wrong regexp expectations ?
Jun 21 21:09:21 <khem> I was lunching
Jun 21 21:09:47 <kergoth> when we call the tool to generate the locale from source, we need the proper names
Jun 21 21:09:50 <seebs> So the thing is.  If it does that once in each of to_generate, and to_generate is just keys(supported).
Jun 21 21:09:50 <kergoth> not the post-mangled names
Jun 21 21:10:05 <seebs> Then the set of locale-base-foo packages ought to be unambiguously unique.
Jun 21 21:10:05 <kergoth> that is, if not using precompiled
Jun 21 21:10:26 <seebs> ohhh
Jun 21 21:10:31 <seebs> Wait, no.
Jun 21 21:10:42 <seebs> If use_bin is precompiled, it's output_locale(locale, base, charset).
Jun 21 21:11:04 <seebs> Otherwise, it's either output_locale(base, base, charset) or output_locale('%s.%s' % (base, charset), base, charset)
Jun 21 21:11:13 <seebs> But we should be in the "precompiled" case.
Jun 21 21:11:21 <seebs> So we should be getting the unchanged names.
Jun 21 21:12:21 <seebs> But if GLIBC_GENERATE_LOCALES were set, rather than unset or 'all', that list could in theory have duplicates.
Jun 21 21:13:12 <khem> update me a bit, so the problem is naming convention used for pregenerated locales ?
Jun 21 21:13:21 <khem> and packaging not recognising it
Jun 21 21:13:22 <khem> right
Jun 21 21:13:37 <seebs> What *seems* to be at issue is that libc-package is generating a list of packages, based on either GLIBC_GENERATE_LOCALES or the SUPPORTED file, which duplicates names.
Jun 21 21:14:05 <seebs> It is interesting to note that every such package name ends in a period with no charset after it, and the number of errors corresponds to the number of distinct charsets which exist in our precompiled locales.
Jun 21 21:15:02 <khem> right yes it uses GLIBC_GENERATE_LOCALES
Jun 21 21:15:18 <seebs> I have not figured out where that's getting set.
Jun 21 21:15:40 <khem> GLIBC_GENERATE_LOCALES takes precedence over SUPPORTED
Jun 21 21:16:08 <khem>         if not to_generate or to_generate == 'all':
Jun 21 21:16:09 <khem>                 to_generate = supported.keys()
Jun 21 21:16:10 <seebs> Yeah.  I'm just trying to figure out whether we are setting that anywhere.
Jun 21 21:16:36 <khem> where to_generate = d.getVar('GLIBC_GENERATE_LOCALES', True)
Jun 21 21:17:08 <seebs> And I'm not finding anything setting GLIBC_GENERATE_LOCALES.
Jun 21 21:17:28 <khem> so if fall into if not to_generate
Jun 21 21:17:32 <seebs> So it should be unset, so we should be getting supported.keys().
Jun 21 21:17:41 <khem> right
Jun 21 21:17:54 <seebs> Which should mean that we get one package per base locale, and their names shouldn't have dots at the end.
Jun 21 21:17:59 <seebs> Which means one of my assumptions is wrong.  :)
Jun 21 21:21:22 <seebs> oohhh
Jun 21 21:21:24 <seebs> Found it!
Jun 21 21:21:55 <khem> m = re.match("(.*)_(.*)", name)
Jun 21 21:22:13 <seebs> in libc-package, right under setting use_bin.
Jun 21 21:22:31 <khem> what is GLIBC_INTERNAL_USE_BINARY_LOCALE set to
Jun 21 21:22:32 <seebs> if use_bin != "precompiled": we check GLIBC_GENERATE_LOCALES or the SUPPORTED file.
Jun 21 21:22:40 <seebs> It's precompiled.
Jun 21 21:22:43 <khem> ok
Jun 21 21:22:45 <seebs> So we are in the else case, where:
Jun 21 21:22:53 <seebs> os.listdir(full_bin_path).
Jun 21 21:23:28 <kergoth> seebs: you're using old code
Jun 21 21:23:32 <kergoth> current oe-core doesn't do any of that
Jun 21 21:23:32 <seebs> And we split everything on ., and if there's more than one component, we set something to component[0] + d + component[1].upper.
Jun 21 21:23:35 <seebs> Ahh, see.
Jun 21 21:23:35 <kergoth> which is why i changed it
Jun 21 21:23:37 <seebs> Yes, we are.
Jun 21 21:23:48 <seebs> We're on a frozen tree from a little while back.
Jun 21 21:23:52 <seebs> So that is probably the source of the problem.
Jun 21 21:24:40 <seebs> Unfortunately, it may be non-trivial to backport any large changes right now.  Ugh.
Jun 21 21:24:53 <kergoth> hmm
Jun 21 21:24:56 <khem> seebs: how old ?
Jun 21 21:25:01 <fray> 1.2.x
Jun 21 21:25:05 <fray> denzil
Jun 21 21:25:06 <khem> ups
Jun 21 21:25:31 <khem> commit 9c62f635ab82f56821fa10a5d3bd7490f9f97987
Jun 21 21:25:32 <khem> Author: Christopher Larson <kergoth@gmail.com>
Jun 21 21:25:32 <khem> Date:   Thu Apr 26 23:03:55 2012 -0500
Jun 21 21:25:32 <khem> libc-package: rework ''precompiled' locale handling
Jun 21 21:25:32 <fray> if you can point out the right commits, we can look at them and may be able to use them as-is.. but ya, if they're too large or distruptive it could be a problemf or us
Jun 21 21:25:37 <khem> do you have this ?
Jun 21 21:25:48 <seebs> We do not.
Jun 21 21:26:17 <seebs> Our most recent is the April 16th fix 380efadd.
Jun 21 21:26:37 <seebs> Huh.  So your fixes would be the next commit, which means it might be possible to just apply it.
Jun 21 21:26:54 <fray> ya
Jun 21 21:27:12 <kergoth> it's possible there's a better way to do this, but doing it that way seemed to avoid the issues i was hitting
Jun 21 21:27:16 <kergoth> heh
Jun 21 21:28:48 <khem> kergoth: the SUPPORTED file needs to be toolchain specific I assume ?
Jun 21 21:29:07 <khem> e.g. say someone wants to hook in a toolchain generated by ct-ng e.g.
Jun 21 21:29:49 <seebs> So SUPPORTED is a list of non-dotted locale names and the character sets they use, but doesn't affect names with dots?
Jun 21 21:29:58 <kergoth> khem: if you don't mind regenerating the locales, it shouldn't be needed. iirc the issue was we can't determine what charset was used by examining the compiled locale directory
Jun 21 21:30:35 <kergoth> and we needed the charset used to add the deps
Jun 21 21:30:42 <khem> kergoth: I see. I wish it was standardized
Jun 21 21:30:44 <kergoth> but i'm going largely from memory here
Jun 21 21:31:05 <kergoth> so yeah, i think my intent was that the external toolchain person would include a SUPPORTED file that corresponded to the generated locales in that toolchain, kyes
Jun 21 21:31:24 <seebs> So in cases where there's no entry in SUPPORTED, the charset is inferred from the stuff after the dot.  I think.
Jun 21 21:31:27 <khem> kergoth: so in some case en-us could mean utf8 and in some other case it could mean ascii ?
Jun 21 21:31:40 <seebs> Okay, I'm going to apply that patch, un-apply my previous "fix", and see whether that fixes the problem.
Jun 21 21:31:51 <kergoth> khem: right. in cases where multiple charsets are available, and the name isn't suffixed, we don't know which was used
Jun 21 21:32:01 <khem> hmmm
Jun 21 21:32:15 <khem> and is there some way to poke into the locale data and figure that out ?
Jun 21 21:32:47 <kergoth> maybe its possible, but i don't know anything about the format of the binary locale data
Jun 21 21:32:53 <kergoth> would be lovely if there was
Jun 21 21:33:54 <seebs> Note that none of this actually changes my vague feeling that the stashing binaries in /usr/include thing is sorta weird.  :P
Jun 21 21:35:03 <kergoth> seebs: i suspect the idea was we wanted to avoid the horribly slow locale package generation for builds that didn't need locale packages at all, but that's a guess, should check the git logs of the creation of eglibc-locale
Jun 21 21:35:07 <kergoth> heh
Jun 21 21:35:19 <seebs> ugh
Jun 21 21:35:36 <seebs> The sad thing is?  Like the FIRST THING I thought of was "I wonder if this code has been changed".
Jun 21 21:35:52 <seebs> And I looked at the logs for eglibc-locale.inc, and eglibc-package.inc.
Jun 21 21:35:59 <seebs> I did not look at the logs for libc-package.bbclass.
Jun 21 21:36:23 <seebs> I should have asked Helpy.
Jun 21 21:38:51 <kergoth> heh, iw as going to ask, but i assumed you'd have recent classes, if not the recipe metadata. oops
Jun 21 21:39:05 <kergoth> i wasn't sure until you mentioned specific code blocks i knew no longer existed :)
Jun 21 21:42:10 <seebs> Yeah.  And of course, the stuff I was looking at until fairly far in *was* all reasonably current.
Jun 21 21:46:42 <khem> seebs I have been thinking you are on top of master :)
Jun 21 21:46:55 <khem> otherwise this was resolved yesterday
Jun 21 21:47:01 <kergoth> hmm, the SUPPORTED file in oe-core doesn't match up 100% with what's in the toolchain. e.g. there's only one zh_CN, the unsuffixed one
Jun 21 21:47:30 <khem> kergoth: that supported file in OE-Core is essentially for CSL toolchain right
Jun 21 21:47:42 <kergoth> yeah, thats' why it's in the external-sourcery-toolchain/ dir
Jun 21 21:48:03 <kergoth> hmm
Jun 21 21:48:04 <khem> duh
Jun 21 21:48:05 <seebs> We have four zh_CN in our binaries.
Jun 21 21:48:10 <kergoth> yeah
Jun 21 21:48:23 <khem> seebs: you rebuild the CSL toolchains
Jun 21 21:48:28 <khem> or use the bins
Jun 21 21:48:57 <seebs> Binaries for now.
Jun 21 21:49:06 <seebs> We will eventually be providing recipes to rebuild them.
Jun 21 21:49:29 <khem> then why is yours different than kergoths arent they same releases
Jun 21 21:49:32 <seebs> Roughly 75% of work related to the toolchain is providing rebuild-toolchain rules for the binary toolchains, which have to produce basically identical toolchains.
Jun 21 21:49:37 <seebs> Not the same release.
Jun 21 21:49:46 <khem> k
Jun 21 21:49:53 <seebs> We have a custom release with different multilibs, various feature changes, local bug fixes, and so on.
Jun 21 21:50:27 <seebs> Which leads to endless trouble as end-users run 'gcc -v', and conclude that they need a "newer version", not realizing that we have the patch they're looking for already.
Jun 21 21:50:56 <khem> seebs: look into meta-linaro they have prebuilt as well as build from source recipes
Jun 21 21:55:33 <seebs> The tricky part is making sure that our build process duplicates the specific binary toolchains we get.
Jun 21 21:55:54 <khem> yes which will be hard I tell you
Jun 21 21:56:07 <khem> since gcc will have prerequisites
Jun 21 21:56:25 <khem> which probably are not same on CSL build servers
Jun 21 21:56:43 <khem> so you have a tough problem
Jun 21 21:56:45 <seebs> Yes.
Jun 21 21:57:18 <khem> I recently fixes a bug in our toolchain which was injected by the fact we used old bison
Jun 21 21:57:41 <khem> just preparing you for the battle :)
Jun 21 21:58:57 <khem> on a different note. My images on qemu are taking sooo long to execute stuff from cross environment
Jun 21 21:59:44 <khem> modus operandi is scp the binary into qemu target, execute using ssh; remove using ssh rm
Jun 21 21:59:57 <khem> its typical case of gcc cross testing
Jun 21 22:00:40 <seebs> wow, that sounds SO EFFICIENT.
Jun 21 22:01:04 <khem> it use to take around 30 hours but i ran it for 3 days and still was stuck half way
Jun 21 22:15:59 <kergoth> yikes
Jun 21 22:16:34 <khem> I wonder if its gcc 4.7
Jun 21 22:16:37 <khem> or something else
Jun 21 22:17:01 <khem> I bet its something else since I did run the tests successfully on 4.7.0
Jun 21 22:17:44 <khem> its not qemu as I see because results are same with 0.15.1 or latest qemu master
Jun 21 22:18:01 <khem> so something in image or prolly how we boot it up networking wise
Jun 21 22:38:29 <ant__> khem: I see packaging issues with libgcc
Jun 21 22:38:50 <ant__> http://paste.debian.net/175750/
Jun 21 22:38:59 <kergoth> seebs: did applying that commit bypass the issue?
Jun 21 22:39:24 <seebs> Seems to have!
Jun 21 22:39:33 <seebs> The build isn't done, but I think it's further than it used to get.
Jun 21 22:39:55 <seebs> So now the eglibc-locale package is being built, and the system is doing it without complaint.
Jun 21 22:41:05 <kergoth> cool
Jun 21 23:17:25 <khem> ant__: submit a patch
Jun 21 23:37:52 <Guest5838> Can someone let me know how to get rid of ERROR: QA Issue No GNU_HASH in the elf binary?
Jun 21 23:40:20 <seebs> Make sure your linker specifies --hash-style=gnu automatically, or fix packages that aren't passing it.
Jun 21 23:40:30 <seebs> In theory it is supposed to be passed by all packages, in practice it is not always so.
Jun 21 23:42:29 <Guest5838> Is this  --hash-style=gnu  specified in my recipe?
Jun 21 23:42:46 <seebs> It is in theory there by default, but your recipe has to not remove it.
Jun 21 23:43:07 <seebs> Casual web searching on packages and "QA Issue" "GNU_HASH" may give you some details or examples.
Jun 21 23:46:38 <kergoth> Guest5838: make sure the build of the project is obeying oe variables. in particular, LDFLAGS.
Jun 21 23:47:35 <Guest5838> I am not using any LDFLAGS in my recipe.
Jun 22 00:00:35 <Guest5838> I added these two lines.   It fixed the problem.  INSANE_SKIP_${PN} = "ldflags"  INSANE_SKIP_${PN}-dbg = "ldflags"
Jun 22 01:16:19 <kergoth> why do people assume that because something isn't defined in a recipe, it isn't used anywhere? either they're lazy, or we have a documentation problem
Jun 22 01:16:23 * kergoth rolls eyes at Guest5838
Jun 22 01:16:55 * mranostay hands kergoth a beer
Jun 22 01:17:10 <mranostay> just hide the problem what could possibly go wrong? :)
Jun 22 01:17:18 <kergoth> heh :)
Jun 22 01:49:24 <seebs> Side note:  I have noticed one way to guess with reasonable confidence something about locales with no specified character set.
Jun 22 01:49:35 <seebs> Which is that LC_COLLATE is about 1.2MB for UTF8, and <60K for everything else.
Jun 22 01:50:01 <seebs> I have learned this while discovering that the SUPPORTED list for the standard CSL toolchain omits tt_RU, which our toolchain has.
Jun 22 01:50:39 <seebs> No idea why my test build didn't blow up but a later one did.
Jun 22 02:51:56 <mranostay> seebs: assume everyone knows English? :)
**** ENDING LOGGING AT Fri Jun 22 02:59:59 2012

**** BEGIN LOGGING AT Fri Jun 22 02:59:59 2012
Jun 22 07:55:40 <ignus16> hello all, does anyone know if there is a correct way to disable the network sanity check?
Jun 22 07:57:29 <RP__> ignus16: clear the variable with the test urls in it
Jun 22 07:58:40 <ignus16> RP__: overwrite the list in poky.conf or elsewhere?
Jun 22 08:00:21 <ignus16> RP__: as in, can i just stick CONNECTIVITY_CHECK_URIS ?= "" in my local.conf or would that be the wrong way to do it?
Jun 22 08:47:01 <RP__> ignus16: You should be able to set that from local.conf (use an =, not ?=)
Jun 22 08:47:27 <RP__> ignus16: I have to question why you need to do that, BB_NO_NETWORK = "1" might be more appropriate I guess
Jun 22 08:57:26 <ignus16> RP__: im not sure why the sanity check fails in here - i assume its to do with the firewall/proxy setup. either way yocto works fine fetching all of the sources once the sanity check is disabled...
Jun 22 08:57:57 <RP__> ignus16: I'd guess the mirror fetching is working but probably not things like direct git:// access
Jun 22 09:06:54 <bluelightning> morning all
Jun 22 09:08:39 <ignus16> good morning
Jun 22 09:09:27 <ignus16> bluelightning: hows it going?
Jun 22 09:09:37 <bluelightning> ignus16: great, and you?
Jun 22 09:13:03 <ignus16> great yeah, trying to combine my two favorite things: yocto and buildbot :D
Jun 22 11:33:16 <RP__> ignus16: you've seen our autobuilder?
Jun 22 12:48:55 <ignus16> RP__: yeah, i have spoken to the main dev a few times. im hoping to reuse some of the code...
Jun 22 13:22:30 <denisATeukrea> hi, I've found why it executes x-window-manager:
Jun 22 13:22:32 <denisATeukrea> /etc/X11/Xsession.d/90xXWindowManager
Jun 22 13:22:50 <denisATeukrea> and that is part of xserver-common
Jun 22 13:28:51 <denisATeukrea> why idea on how to fix my problem?
Jun 22 13:58:39 <RP__> kergoth: have you looked at the way we set TOPDIR?
Jun 22 14:00:49 <RP__> kergoth: the bblayers.conf finding code is all well and good but TOPDIR will default to cwd :/
Jun 22 14:01:50 <denisATeukrea> maybe I've found a way to fix
Jun 22 14:02:02 <denisATeukrea> it seem that the oe-core version and the target version differ
Jun 22 14:07:42 <denisATeukrea> aha x11-common and xserver-common is not the same thing....
Jun 22 14:12:16 <denisATeukrea> hi JaMa
Jun 22 14:12:46 <denisATeukrea> do you know the difference between x11-common and xserver-common
Jun 22 14:13:02 <denisATeukrea> apart the fact that one is in meta-oe, and the other in oe-core
Jun 22 14:26:34 <JaMa> denisATeukrea: yes x11-common is using form-factor and doesn't use xinput-calibrator
Jun 22 14:31:33 <denisATeukrea> the problem is that xserver-common is what I got  and it's out of date
Jun 22 14:32:13 <denisATeukrea> because x11-common's /etc/X11/Xsession.d/90xXWindowManager doesn't check for x-session-manager
Jun 22 14:32:26 <denisATeukrea> oops
Jun 22 14:32:36 <denisATeukrea> because xserver-common's /etc/X11/Xsession.d/90xXWindowManager doesn't check for x-session-manager
Jun 22 14:32:44 <denisATeukrea> x11-common does
Jun 22 14:34:04 <denisATeukrea> beside xserver-common uses patches
Jun 22 14:38:37 <JaMa|Off> which I send to florian to apply upstream
Jun 22 14:38:57 <denisATeukrea> ah we're not the upstream for that
Jun 22 14:39:05 <denisATeukrea> that explains why there are patches then
Jun 22 14:39:40 <denisATeukrea> anyway what should I do, should I fix one of your patch?
Jun 22 14:39:47 <JaMa|Off> so yes.. would be nice to merge what we need to x11-common and drop xserver-common completely, but I'm not very motivated to do that, because xserver-common just works.. and I have better stuff to do
Jun 22 14:40:12 <denisATeukrea> I need matchbox working for work
Jun 22 14:40:19 <JaMa|Off> sorry gtg..
Jun 22 14:40:21 <denisATeukrea> or whatever X environment
Jun 22 14:40:34 <denisATeukrea> I tried enlightenment it segfaulted on startup in denzil
Jun 22 14:40:35 <denisATeukrea> ok
Jun 22 14:40:41 <denisATeukrea> I'll manage, no worries
Jun 22 14:40:54 <denisATeukrea> at worse I force x11-common
Jun 22 14:54:06 <ciupicri> is there a web page with the people working on this project and their IRC nicks?
Jun 22 14:58:37 <RP__> ciupicri: good question. There was a page for OE iirc, not sure about Yocto
Jun 22 14:58:59 <RP__> ciupicri: /whois <nickname> can give some hints
Jun 22 14:59:05 <ciupicri> OE as in Dell, Intel, Panasonic... ?
Jun 22 14:59:30 <ciupicri> RP__, I've started /whois-ing already :-)
Jun 22 15:00:12 <kergoth> RP__: usually not an issue for me, as my bblayers.conf always sets TOPDIR to the dir above the dir where bblayers.conf resides. heh
Jun 22 15:00:23 * kergoth goes to get coffee and breakfast
Jun 22 15:00:44 <RP__> kergoth: I think we should do that by default...
Jun 22 15:01:40 <RP__> ciupicri: OE as in OpenEmbedded (wiki.openembedded.org)
Jun 22 15:01:47 <ciupicri> ohhhh
Jun 22 15:30:31 <kergoth> RP__: that sounds reasonable
Jun 22 16:21:11 <seebs> Idle question:  Anyone interested in having a ppc476 tuning added to machine/include?  I ask because we have one that works with our prebuilt toolchain, and the lack of one in Yocto means that "try it with the other toolchain" stopped working.
Jun 22 16:21:41 <kergoth> seebs: fyi, i tested using a fully fleshed out SUPPORTED based on libc/localedata/SUPPORTED from eglibc svn trunk with sourcery and it seemed to work fine, and gave us e.g. all 4 zh_CN locale packages. going to test further then see about pushing that to oe-core, after testing against a few different toolchain versions
Jun 22 16:21:56 <seebs> Cool!
Jun 22 16:22:18 <seebs> I noticed a missing tt_RU entry in ours, with respect to our binary toolchain.
Jun 22 16:22:39 <seebs> I have not found any way to better infer character sets, except that if the COLLATE file is ~1.2MB, the character set is UTF8.
Jun 22 16:22:59 <kergoth> hehe, that's interesting
Jun 22 16:33:45 <seebs> It's really noticeable.  They're 20-40K or so, unless it's UTF8.
Jun 22 18:14:18 <chackal_sjc> how do I see the dependency? without using graphiz
Jun 22 18:14:29 <kergoth> bitbake -g -u depexp
Jun 22 18:15:28 <chackal_sjc> thx
Jun 22 18:15:44 <kergoth> the ui isn't perfect, and doesn't cover *everything*, but it's still useful
Jun 22 18:16:00 <kergoth> more often than not i just use -g and inspect/grep the .dot files directly
Jun 22 18:16:07 <kergoth> heh
Jun 22 18:16:24 <chackal_sjc> yeah, but its huge files.. its more difficult to find depedencies
Jun 22 18:16:33 <kergoth> grep :)
Jun 22 18:16:39 <kergoth> but agreed, it's a lot of info
Jun 22 18:17:24 <chackal_sjc> can u use grep with .dot?!
Jun 22 18:18:40 <kergoth> they're just text files
Jun 22 18:18:40 <chackal_sjc> im setting XSERVER = "xserver-xorg" for for x11-mini image task
Jun 22 18:18:42 <kergoth> you can read them
Jun 22 18:18:54 <chackal_sjc> but it always install kdrive instead of xorg
Jun 22 18:18:57 <kergoth> and grep works with any text
Jun 22 18:19:10 <kergoth> first step i'd suggest using bitbake -e to make sure its really set that way, and isn't being overridden elsewhere
Jun 22 18:19:39 <kergoth> 90% of the time when something seems not obeyed or behaves inexplicably, it's due to my assumptions not matching reality :)
Jun 22 18:19:40 <chackal_sjc> kergoth: i know, but if the text isn't readable, there is not much what you can do
Jun 22 18:20:15 <kergoth> it is readable. the lines are straightforward. e.g. in pn-depends.dot, it's lines like "ncurses -> eglibc" or whatever
Jun 22 18:20:25 <chackal_sjc> kergoth: i know that the x11-mini task sets XSREVER ?= "xserver-kdrive-fbdev" but it's ?= right?!
Jun 22 18:20:37 <chackal_sjc> ok
Jun 22 18:21:02 <kergoth> not pretty, but certainly possible for a person to parse :)
Jun 22 18:21:09 <kergoth> but i'd suggest using -e to check sanity, then depexp
Jun 22 18:21:18 <kergoth> and if depexp doesn't cover what you need, *then* read the .dot files
Jun 22 18:21:18 <chackal_sjc> just -e?
Jun 22 18:21:35 <kergoth> -e or -e <recipename>
Jun 22 18:21:41 <kergoth> | grep \^XSERVER=
Jun 22 18:21:49 <chackal_sjc> k
Jun 22 18:21:59 <chackal_sjc> i prefer ack ;)
Jun 22 18:23:23 <chackal_sjc> kergoth: yeah, XSERVER variable is good
Jun 22 18:23:58 <chackal_sjc> im gonna grep in a dot file
Jun 22 18:25:40 <kergoth> i prefer ack too usually :)
Jun 22 18:25:48 <kergoth> though i still | grep out of habit
Jun 22 18:27:32 <chackal_sjc> man, nothing is calling xserver-kdrive
Jun 22 18:27:50 <chackal_sjc> do you think it could be because of cache?\
Jun 22 18:28:01 <chackal_sjc> because I was using kdrive, and then I changed
Jun 22 18:28:28 <chackal_sjc> and I didn't cleaned the entire build, because, you know, it will take 1 hour to compile everything again
Jun 22 18:29:49 <kergoth> if XSERVER is used in a task, -c clean the task recipe and try again
Jun 22 18:30:10 <kergoth> course it shouldn't be needed, due to the use of basichash
Jun 22 18:30:16 <chackal_sjc> hm
Jun 22 18:30:19 <chackal_sjc> good
Jun 22 18:30:22 <kergoth> (metadata checksum chnages automatically result in re-run of affected tasks)
Jun 22 18:30:28 * kergoth shrugs
Jun 22 18:31:25 <chackal_sjc> lets see
Jun 22 18:32:23 * kergoth wonders if anyone has tried using a ct-ng toolchain with external-sourcery-toolchain or created a recipe for it
Jun 22 18:47:57 <chackal_sjc> kergoth: still not working
Jun 22 18:48:22 <chackal_sjc> kergoth: I used external-sourcery-toolchain, but i didn't like the support
Jun 22 18:48:29 <chackal_sjc> it breaks all the time
Jun 22 18:49:04 <kergoth> how so?
Jun 22 18:49:13 <chackal_sjc> because my compiler was a bit old
Jun 22 18:49:16 <kergoth> I've tested it with all 4 archs across 4+ csl toolchain versions
Jun 22 18:49:26 <kergoth> farthest back I've tested was 2010.09, but that was a while ago
Jun 22 18:49:30 <chackal_sjc> and a lot of configuration used in poky wasn't supported for my compiler
Jun 22 18:49:31 <kergoth> i can try retesting that if you'd like
Jun 22 18:49:39 <chackal_sjc> i tested 2009.09
Jun 22 18:49:44 <kergoth> ahh
Jun 22 18:49:50 <kergoth> definitely haven't tested that one :)
Jun 22 18:50:12 <chackal_sjc> yeah, but its the best for our kernel , at least is what the kernel guys here say
Jun 22 18:51:01 <chackal_sjc> kergoth: task x11 mini still using kdrive
Jun 22 18:51:05 <chackal_sjc> dont know what to do
Jun 22 18:55:12 <chackal_sjc> I had to change inside the task*.bb to make effect
Jun 22 19:34:11 <pinskia> hi
Jun 22 19:58:01 <msm> did the toolchain get multilib support in yocto 1.2 release?
Jun 22 23:22:59 <dvhart> sgw: if I want to see if you have a pull of mine queued up, which branch should I be looking at?
Jun 22 23:23:06 <dvhart> sgw: but seems to be rather old
Jun 22 23:23:12 <dvhart> sgw: mut even
Jun 23 00:15:34 <khem> dvhart: let me pick your brains a bit
Jun 23 00:15:56 <dvhart> sure, slim pickens on a friday at 5, but go for it :-)
Jun 23 00:16:02 <khem> dvhart: is there a way or ongoing effort to use devicetree on intel processors
Jun 23 00:17:46 <khem> second question is how can I hook in multiple i2c device knowledge into a generic x86 kernel
Jun 23 00:17:49 <dvhart> khem: ACPI is of course where most of the effort is going. There is some work going on in support of device tree, Grant Likely is probably the best contact for that. I believe he presented something on that at ELCE
Jun 23 00:18:06 <khem> so I want to use a generic image to boot bunch of different chassis
Jun 23 00:18:56 <dvhart> I'm looking at doing platform support for i2c now for the fri2 accel and gpio drivers. Thinking on how that would work for multiple platforms in the same kernel…. hrm...
Jun 23 00:19:12 <khem> ah cool.
Jun 23 00:19:35 <dvhart> What you could do, I think, is provide some platform data that says which devices a bus should probe for
Jun 23 00:19:51 <khem> as in device tree :)
Jun 23 00:19:59 <dvhart> so long as those busses have the detect function properly implemented, they should be able to just return ENODEV when not found
Jun 23 00:20:13 <dvhart> ah, I see the connection now :)
Jun 23 00:20:38 <dvhart> I was thinking in the platform data for the i2c bus as something that gets compiled in
Jun 23 00:20:41 <dvhart> hrm
Jun 23 00:20:47 <khem> i see
Jun 23 00:20:51 <dvhart> yes devtree seems the better option here compared to ACPI
Jun 23 00:21:06 <khem> so you mean acpi
Jun 23 00:21:28 <dvhart> I'm still learning the i2c system, so I'm probably missing some core bits.
Jun 23 00:21:57 <khem> I just got this dumped on me
Jun 23 00:22:06 <khem> so I am trying to scamper and see whats out there
Jun 23 00:22:10 <khem> and what can be done
Jun 23 00:22:20 <dvhart> If you want to send me some specs (if possible) I'd be happy to look at it a bit more closely
Jun 23 00:22:37 <khem> if I get some I will :)
Jun 23 00:22:40 <dvhart> meanwhile, I'd consider emailing LKML and cc'ing Grant on the proper path. I'd like to be on CC as well.
Jun 23 00:22:42 <dvhart> haha
Jun 23 00:22:48 <khem> I will try to get some more info
Jun 23 00:23:06 <dvhart> do you know if the various chassis are basically subsets of a greater superset?
Jun 23 00:23:32 <dvhart> also, there is some good docs on specifying devices in the linux/Documentation/i2c* docs
Jun 23 00:23:44 <khem> yeah going through those
Jun 23 00:23:46 <khem> too
Jun 23 00:24:05 <dvhart> I'll keep this in mind as I'm working on these drivers for FRI2 as well
Jun 23 00:24:12 <khem> its something I need to do some search about and just started on it
Jun 23 00:24:21 <khem> cool tht will help
Jun 23 00:24:35 <khem> btw. what happen to the boards that were promised during ELC
Jun 23 00:24:54 <khem> I hope it was not a scam to get my mailing address and email address
Jun 23 00:24:58 <khem> :)
Jun 23 00:25:17 <fray> I thought they got sent out?
Jun 23 00:25:34 <khem> I did not receive anything
Jun 23 00:25:34 <fray> maybe I'm thinking of something else..
Jun 23 00:25:40 <khem> hmm
Jun 23 00:25:48 <dvhart> they are coming, haven't been sent out yet. There was a … hiccup… in the manufacturing …. we can talk in person if you want to know more I think ;-)
Jun 23 00:25:59 <fray> ahh.. ok my info was wrong
Jun 23 00:26:11 * fray notes he really wants an FRI2..  ;)
Jun 23 00:26:21 <khem> dvhart: ok, so I can still expect to get one
Jun 23 00:26:23 <dvhart> fray: I have some MP2 units - MUCH better
Jun 23 00:26:27 <dvhart> khem, yes
Jun 23 00:26:33 <fray> not as "toaster-like"?
Jun 23 00:26:49 <fray> and does the 3G work on it.. thats really want I want it for
Jun 23 00:26:49 <khem> dvhart: any ETA
Jun 23 00:26:56 <dvhart> well… more like the USB port works better, the ESD issues on the MSD are resolved, etc
Jun 23 00:26:57 <khem> fray me too :)
Jun 23 00:27:09 <dvhart> fray: I tested the 3G and it does work
Jun 23 00:27:09 <fray> cool
Jun 23 00:27:21 <khem> I have some plans to hack on it
Jun 23 00:27:28 <khem> do some cool stuff
Jun 23 00:27:31 <fray> as lame as it is, I really want one to act as a backup network interface for my house..
Jun 23 00:27:33 <dvhart> fray: there are conn man issues, but it works
Jun 23 00:27:38 <khem> but only if I get the damn board :)
Jun 23 00:27:47 <fray> as long as I can establish the connection, and do basic routing.. it'll be everythign I want
Jun 23 00:27:53 <fray> (but I'm not on the list...)
Jun 23 00:27:59 <fray> least not the ELC list
Jun 23 00:28:04 <dvhart> khem we should be getting final hardware this week I think, I don't know the ETA
Jun 23 00:28:11 <dvhart> for shipping out
Jun 23 00:28:57 <fray> (if only I could find a -cheap- case for the blacksand I have..)
Jun 23 00:29:13 <fray> everything I've found comes with a power supply, or is really funky..  which means they're bothe xpensive
Jun 23 00:33:25 <dvhart> for all of you waiting on target module building, my first image has built and I'm off to test
Jun 23 00:33:32 <dvhart> should hopefully land next week
Jun 23 00:33:56 * fray almost has it so you can now build an SDK that matches an image
Jun 23 00:40:15 <dvhart> night all
**** ENDING LOGGING AT Sat Jun 23 02:59:58 2012

**** BEGIN LOGGING AT Sat Jun 23 02:59:58 2012
Jun 23 04:38:23 <sgw> Khem, you around?
**** ENDING LOGGING AT Sun Jun 24 02:59:58 2012

**** BEGIN LOGGING AT Sun Jun 24 02:59:58 2012
Jun 25 00:31:23 <ciupicri> where do I report small bugs in the documentation? a Fedora package mentioned on http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html doesn't exist on Fedora 16 x86_64; xsltproc is in the libxslt package
Jun 25 01:04:04 <ciupicri> never mind, I reported something on bugzilla
**** ENDING LOGGING AT Mon Jun 25 02:59:58 2012

**** BEGIN LOGGING AT Mon Jun 25 02:59:59 2012
Jun 25 08:08:01 <mckoan> good morning
Jun 25 09:04:13 <ciupicri> Bagder, is rockbox using yocto to build the itself?
Jun 25 09:20:56 <B4gder> ciupicri: no, rockbox has its own custom build setup
Jun 25 09:21:44 <ciupicri> ok, thanks
Jun 25 09:25:15 <B4gder> I intend to work on keeping my other projects yocto-friendly though
Jun 25 09:25:24 <B4gder> curl, libssh2 and c-ares primarily
Jun 25 09:29:01 <ciupicri> you mean you want curl, libssh2 etc. to provide the required metadata for yocto, so that they can be easily included in the Linux images generated with yocto?
Jun 25 09:31:15 <B4gder> nah, I mostly want them to get configured, built and tested in ways that are clean and fine
Jun 25 09:32:44 <ciupicri> ohhh this sounds more like a general purpose thing
Jun 25 09:32:56 <B4gder> right
Jun 25 09:33:08 <B4gder> it's more of "not doing things wrong" really
Jun 25 09:33:52 <bluelightning> morning all
Jun 25 09:35:12 <ciupicri> morning
Jun 25 09:37:52 <B4gder> morning? =)
Jun 25 09:44:56 <ciupicri> bluelightning, do you happen to know any projects using yocto? I'm still having a hard time understanding the purpose of yocto compared to a more regular distribution like Fedora or Ubuntu
Jun 25 09:45:31 <B4gder> ciupicri: yocto creates distributions
Jun 25 09:46:10 <bluelightning> ciupicri: so, there are at least two advantages over regular distros for embedded uses:
Jun 25 09:46:34 <bluelightning> ciupicri: 1) taking something very small and building up, rather than taking something quite large and cutting it down
Jun 25 09:46:39 <ciupicri> that's what I keep hearing, but why should I use yocto instead of selecting only some packages from a selected distro and adding my own custom packages
Jun 25 09:47:14 <B4gder> "a selected distro" often doesn't work on your random embedded device
Jun 25 09:48:23 <ciupicri> I wonder how the RasberryPi managed to use Fedora (and Debian if I remember correctly)
Jun 25 09:48:28 <bluelightning> ciupicri: 2) you can customise it from the very lowest levels, and you can keep your customisations when the underlying recipes (packages) get upgraded
Jun 25 09:48:39 <bluelightning> ciupicri: customised spins is how
Jun 25 09:50:40 <bluelightning> it's also worth mentioning that last I heard for fedora at least they don't believe in cross-compilation, so you have to have large farms of the real hardware in order to do builds
Jun 25 09:51:00 <B4gder> that's how debian works too
Jun 25 09:54:32 <ciupicri> so cross-compilation would certainly be an advantage
Jun 25 09:56:25 <ciupicri> what about those customizations? how easy it is for example to replace the tradition init with upstart (the one from Ubuntu) or systemd (the one from Fedora)
Jun 25 09:57:08 <bluelightning> people are successfully using systemd (although there are still some rough edges in the way it has been implemented)
Jun 25 09:58:05 <bluelightning> there was a suggestion that upstart might be made available by one of the webos developers, not sure of the status of that though
Jun 25 10:00:05 <ciupicri> and what are the rough edges? missing parts or small bugs of systemd or the integration with yocto?
Jun 25 10:08:28 <bluelightning> it's to do with the way the layer that introduces it has been put together
Jun 25 10:08:50 <bluelightning> there are a number of people working on tidying it up however
Jun 25 10:09:55 <ciupicri> I see. It seems that I should investigate those layers.
Jun 25 10:10:46 <ciupicri> another thing: is to me or in a way yocto or a part of it is similar to pkgsrc from the NetBSD project or the Gentoo build system?
Jun 25 10:12:16 <bluelightning> well, many years ago when bitbake/OE started some pieces were borrowed from gentoo
Jun 25 10:12:30 <bluelightning> the system has evolved a lot since then though
Jun 25 10:13:18 <bluelightning> I've not used netbsd so I can't really comment on pkgsrc
Jun 25 10:13:20 <ciupicri> he he
Jun 25 10:15:46 <ant_work> ciupicri: yes, there is still same DNA ;)
Jun 25 10:16:37 <ant_work> BSD ports -> portage -> bitbake /OE
Jun 25 10:17:16 <ciupicri> yeah'
Jun 25 14:03:38 <kergoth> with *very* slight tweaks, external-sourcery-toolchain seems to work fine with the crosstool-ng toolchain. cool. figured that'd be the case, but wanted to try it out
Jun 25 14:14:19 <bluelightning> kergoth: cool :) would it be worth having a tcmode-external-crosstool-ng which just requires tcmode-external-sourcery and makes those tweaks?
Jun 25 14:17:27 <fray> looking for an idea..  I'm working on code that allows you to generate an image and matching SDK in one operation...
Jun 25 14:17:50 <fray> but I'm getting stuck w/ deb and ipkg..  for instance in ipkg it generates the config file(s)  package_generate_ipkg_conf..
Jun 25 14:18:02 <fray> is there some way I can ensure this only gets done -once- per run?
Jun 25 14:18:24 <fray> (both do_rootfs and do_populate_sdk end up calling that function, which then leads to errors)
Jun 25 14:19:08 <fray> even if I checked that each entry was there or not, there is already a race that if both are running at the same time we're going to have probelms..
Jun 25 14:22:49 <fray> is there any way to say that do_populate_sdk needs to run -after- do_rootfs, but doesn't require do_rootfs?
Jun 25 14:31:13 <kergoth> bluelightning: that's what i was thinking :) will have to try it out
Jun 25 15:08:46 <kergoth> fray: when i've had to do that, i've had to just use anonymous python, check if do_rootfs exists, if so, add  the dep
Jun 25 15:08:50 <kergoth> not ideal, but..
Jun 25 15:55:42 <seebs> So, there's a gcc change, and the most explanatory doc I've found on it so far is: http://fedoraproject.org/w/index.php?title=UnderstandingDSOLinkChange
Jun 25 15:56:01 <seebs> And our prebuilt toolchain, which is 4.6-based, has this feature, but it seems as though yocto's native toolchain, which is 4.7-based, doesn't.
Jun 25 15:56:10 <seebs> Is that a change in gcc or a configuration change in yocto?
Jun 25 16:02:52 <kergoth> seebs: it's binutils (ld), not gcc, as far as i'm aware
Jun 25 16:03:00 <seebs> ohhh.
Jun 25 16:03:30 <seebs> You know, that totally makes sense.  It's just that I first saw it framed as "new gcc" and didn't remember that people usually mean "new <some toolchain thing>" when they say "new gcc".
Jun 25 16:03:35 <kergoth> beyond that, don't know. i'd thought the internal toolchain had that as well, but hadn't verified that
Jun 25 16:03:40 * kergoth nods
Jun 25 16:03:41 <dvhart> hrm, so I'm seeing "Your version of bblayers.conf was generated from an older version of bblayers.conf.sample..." so I compare the the files, add the BBPATH="${TOPDIR}" and inc the LCONF_VERSION... and the next bitbake command results in the same error
Jun 25 16:04:02 <dvhart> is there something I need to kick to get it to see that I've done the comparison/change?
Jun 25 16:04:08 <seebs> Well, I *think* it doesn't, because we have a package failing only with our toolchain. Although it could turn out this is actually caused by a race condition somewhere else or something.
Jun 25 16:04:31 <ant_work> sgw: anything more to check wrt ubi headers?
Jun 25 16:04:38 <kergoth> dvhart: afaik you shouldn't have to do anything else, but you could try wiping the parse cache, i suppose
Jun 25 16:05:16 <dvhart> kergoth, rm -rf tmp/cache ?
Jun 25 16:06:00 <kergoth> seebs: cd oe-core; git log --grep=dso\ link
Jun 25 16:06:10 <kergoth> dvhart: yeah. worth a try, anyway..
Jun 25 16:06:13 * kergoth shrugs
Jun 25 16:07:16 <kergoth> bah, ct-ng has glibc with the rpc headers removed
Jun 25 16:07:30 <seebs> ugh
Jun 25 16:07:47 <seebs> I think "let's remove rpc, pretty sure someone else has a working one" may not have been the best executive decision the glibc folks ever made.
Jun 25 16:08:04 <dvhart> kergoth, yeah, gave it a shot, no good. Just verified the LCONF_VERSION are indeed the same, and they are.
Jun 25 16:08:39 <dvhart> RP__, is there something else besides LCONF_VERSION that can trigger this bblayers.conf.sample version mismatch sanity check?
Jun 25 16:10:00 <RP__> dvhart: no, we just did the version though
Jun 25 16:10:15 <dvhart> yeah, I saw your commit for the empty BBPATH issue
Jun 25 16:15:02 <dvhart> ok, bitbake -e tells me LCONF_VERSION=5 and LAYER_CONF_VERSION=4
Jun 25 16:16:13 <RP__> dvhart: if you move tmp/cache out the way does that help?
Jun 25 16:16:25 <dvhart> no
Jun 25 16:16:28 <dvhart> but look:
Jun 25 16:16:30 <dvhart> meta/conf/sanity.conf:LAYER_CONF_VERSION ?= "4"
Jun 25 16:16:46 <dvhart> should that have been increased to 5 along with bblayers.conf.sample?
Jun 25 16:16:51 <RP__> dvhart: yes :/
Jun 25 16:16:59 <dvhart> want me to send a patch?
Jun 25 16:17:15 <RP__> dvhart: I can fix this directly...
Jun 25 16:17:18 <dvhart> ok
Jun 25 16:19:04 <dvhart> alright, good, now back to the "ERROR: Nothing PROVIDES 'update-modules-nativesdk'" failure
Jun 25 16:20:58 <RP__> dvhart: pushed
Jun 25 16:21:29 <dvhart> thanks RP
Jun 25 16:22:08 <sgw> ant_work: not sure, there still seems to be some problem with the udev not building and I want to look into that deeper before yanking those headers.  I understand what you are trying to accomplish, I just want to make sure we don't break the build.
Jun 25 16:22:24 <khem> RP__: can meta-toolchain be used for external modules development ?
Jun 25 16:23:05 <RP__> khem: Right now, no but if you package and install the kernel development source we put into the sysroot, it should work
Jun 25 16:23:43 <khem> RP__: ok, we do not have any existing target available to do that right ?
Jun 25 16:23:55 <RP__> khem: right now, no
Jun 25 16:24:03 <RP__> khem: just external modules within the main build
Jun 25 16:24:26 <khem> ok
Jun 25 16:24:35 <ant_work> sgw: there must be  a race somehow: I did notice the issue the single time when linux-libc-headers had not been overwritten by mtd-utils ones (probably after a linux-libc-headers update, on incremental build)
Jun 25 16:57:05 <bluelightning> fray: looks like in the process of fixing 2595 I might need to refactor the package listing/installation code, which may overlap with 2420
Jun 25 16:58:15 <fray> sounds good to me.. ;)
Jun 25 16:58:20 <fray> that code is crap..
Jun 25 16:58:25 <fray> it "works" but it's crap..
Jun 25 16:58:40 <fray> the way that it happens to work in deb and opkg isn't helping the situation either..
Jun 25 16:59:05 <fray> for the locale issue, it really should give us a way to simple list and set a series of suggested items as a large unit (or individually if necessary)
Jun 25 16:59:22 <fray> this list all of the items and iterate over each item to see if it's valid or not is not a good approach, even for opkg/deb
Jun 25 16:59:22 <bluelightning> fray: I can take some of the blame for that as I implemented it that way...
Jun 25 16:59:37 <fray> I wouldn't say blame at this point..
Jun 25 16:59:57 <fray> until rpm was there, it wasn't an issue.. but now that it is, and it's fairly maintstream.. the code simply needs refactoring
Jun 25 17:00:12 <fray> (note, mosto f the rpm code in there is complete crap to, and I'm guilty of many sins)
Jun 25 17:00:47 <fray> if I had endless time, I'd probably get zypper working finally and avoid all of the manual stuff that RPM has to do to work w/o a proper "external" package/update engine
Jun 25 17:01:30 <bluelightning> fray: do you have an idea of what's missing in order for zypper to work in that capacity?
Jun 25 17:01:57 <bluelightning> (presumably it's not as easy as just getting it building for -native?)
Jun 25 17:02:09 <fray> 1) my understanding of how zypper is supposed to work.. ;)
Jun 25 17:02:22 <bluelightning> heh ok
Jun 25 17:02:24 <fray> 2) recommends handling... (zypper has it, but I don't believe it's enabled for RPM5...
Jun 25 17:02:37 <bluelightning> ah ok
Jun 25 17:02:42 <fray> but #1 is the biggest issue.. I simply don't understand it well enough yet to know what to do..
Jun 25 17:02:51 <fray> the recommends, I think is a couple of days work to find the hooks and enable them
Jun 25 18:10:12 * kergoth tries building ct-ng with --enable-obsolete-rpc passed to eglibc
Jun 25 18:19:07 <fray> I have a task, which I'm adding to a recipe via "addtask <task_name>"
Jun 25 18:19:33 <fray> that task has dependencies set, but the dependencies are always processed for the recipe.. I only want them processed if you build that optional task
Jun 25 18:20:18 <fray> anyway way for bitbake to only evaluate the task dependencices if the task is going to be run?
Jun 25 18:31:46 <kergoth> you can programmatically add task dependencies. it's just a flag under the hood. see the 'deps' flag
Jun 25 18:32:08 <fray> this is what I have right now:
Jun 25 18:32:09 <fray>  do_populate_sdk[depends] = "${@' '.join([x + ':do_populate_sysroot' for x in d.getVar('SDK_DEPENDS', True).split()])}"
Jun 25 18:32:09 <fray>  do_populate_sdk[rdepends] = "${@' '.join([x + ':do_populate_sysroot' for x in d.getVar('SDK_RDEPENDS', True).split()])}"
Jun 25 18:32:23 <fray> but how do I know if the user wants to run the do_populate_sdk task or not before I add those
Jun 25 18:32:27 <msm> what do you mean by process deps? run the actually dependent steps or just make the stamps?
Jun 25 18:32:41 <fray> I have an addtask populate_sdk
Jun 25 18:32:56 <fray> that adds the task, but it doesn't get run in the normal event chain..
Jun 25 18:33:07 <msm> there is a default target
Jun 25 18:33:10 <msm> for recipes
Jun 25 18:33:14 <fray> but when I build the recipe, each of the items I put into the do_populate_sdk[depends] and [rdepends] is getting run
Jun 25 18:33:16 <fray> I don't want that..
Jun 25 18:33:22 <msm> it's like do_build
Jun 25 18:33:31 <fray> I only wants depends/rdepends for the do_populate_sdk task run, if and only if the user calls that task
Jun 25 18:33:32 <msm> you have to add the new task in that chain
Jun 25 18:33:41 <fray> I don't want the task in the chain.. it's optional
Jun 25 18:35:09 <msm> and it's running a dependent step for that recipe even if you don't invoke that task?
Jun 25 18:35:14 <fray> (I'm working on extending the image class to allow you to build a matching SDK... but the damned system keeps building all of the sdk components, I don't want that)
Jun 25 18:35:18 <fray> yes
Jun 25 18:35:43 <msm> maybe you would not a vardepsexclude?
Jun 25 18:36:11 <msm> well
Jun 25 18:36:18 <msm> that's not really helpful probably
Jun 25 18:36:25 <fray> thats only variable based..
Jun 25 18:36:30 <fray> what I want is the abiliuty for someone to do:
Jun 25 18:36:44 <fray> bitbake core-image-minimal ; bitbake -c populate_sdk core-image-minimal
Jun 25 18:36:57 <msm> i had the exact opposite problem the other day
Jun 25 18:37:00 <fray> the first will do what it does today, and if someone wants a matchign SDK they can get it.. and it should -then- build any additional deps
Jun 25 18:37:02 <msm> where i added a task, and it was not getting run
Jun 25 18:37:12 <msm> so i had to add it in the correct task chain
Jun 25 18:37:20 <msm> but im not sure about the dependent tasks, im not sure there were any
Jun 25 18:37:34 <fray> ya, it seems as soon as I put in the addtask, the dependencies for that task are promoted to be built as part of that recipe
Jun 25 18:37:37 <khem> fray: populate_sdk is not a generic image task
Jun 25 18:37:41 <kergoth> i don't see the problem. if you don't put the task 'before' something that's automaitcally run (BB_DEFAULT_TASK or indirect), it won't be run until you use -c
Jun 25 18:37:43 <fray> it is now.. ;)
Jun 25 18:37:47 <khem> fray: what are you trying to achive
Jun 25 18:37:48 <msm> if you are inheriting some baseline image.bbclass - are you sure something else is not adding this task automatically somewhere?
Jun 25 18:38:02 <fray> I need an SDK that matches an image..
Jun 25 18:38:24 <fray> building SDKs separately doesn't make any sense.. unless like the gmae stuff you have a specific set in mind for an external SDK
Jun 25 18:38:34 <khem> why
Jun 25 18:38:39 <fray> I'm not breaking any of the existing SDK work, but I'm allowing someone to build an image matching SDK
Jun 25 18:39:06 <fray> msm, it's not.. the dependencies getting included are all "nativesdk" items.. and they're -only- specified in the do_populate_sdk[rdepends]
Jun 25 18:39:07 <khem> images are for integrators and SDKs are for developers
Jun 25 18:39:23 <fray> and -i- need an SDK that matches my images
Jun 25 18:39:45 <fray> and SDK that doesn't match the image is really useless for my customers..  and they're not going to go and create a custom sdk for ever custom image they produce
Jun 25 18:40:05 <fray> I have everything working, except for these dependencies..
Jun 25 18:40:18 <khem> but that would mean you spin SDKs for each image you generate
Jun 25 18:40:24 <fray> yes
Jun 25 18:40:38 <fray> that is very typical for my customer set
Jun 25 18:41:02 <msm> fray: maybe look at bitbake-diffsigs on the stamps and see what's pulling in these sdk tasks (and if it's only your new task that is)
Jun 25 18:41:06 <fray> there is another set of customers who want a specific SDK, and htey can still do it using the meta-toolchain-* approach
Jun 25 18:42:00 <fray> the signatures aren't changing.. it's they're suddenly required..
Jun 25 18:43:05 <khem> fray: I think you can add sdk step after rootfs step in image.bbclass
Jun 25 18:44:42 <fray> no, still builds the nativesdk bits..
Jun 25 18:44:56 <fray> bitbake -c rootfs core-image-minimal builds all of the nativesdk stuff.. only the populate_sdk should require it
Jun 25 18:46:38 <khem> fray: so you want populate_sdk task to not appear in default dep chain ?
Jun 25 18:46:46 <fray> yes..
Jun 25 18:47:00 <fray> unless the task is going to be called, it's deps shouldn't be there..
Jun 25 18:49:19 <msm> i think you will have to debug ;)
Jun 25 18:49:29 <fray> well, it's something in bitbake..
Jun 25 18:49:43 <khem> fray: where is task being added
Jun 25 18:49:47 <fray> if I could tell if this task was going to be run, then I could do things w/ python if I needed to... but even that gets sketchy
Jun 25 18:50:03 <khem> you should break that dependency it must be doing addtask blah before/after step
Jun 25 18:50:31 <fray> it's not
Jun 25 18:50:33 <fray> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mhatle/sdk
Jun 25 18:51:00 <fray> image.bbclass can optionally included the populate_sdk_base class.. this class (at the very end) has an addtask populate_sdk in it..
Jun 25 18:51:08 <fray> not had a before or after specified for populate_sdk
Jun 25 18:51:51 <khem> do_populate_sdk[recrdeptask] = "do_package_write"
Jun 25 18:52:06 <khem> addtask populate_sdk before do_build after do_install
Jun 25 18:52:14 <khem> thats your problem
Jun 25 18:52:20 <fray> thats in populte_sdk.bbclass -- which is -not- being loaded
Jun 25 18:52:36 <khem> hmm are you sure of that ?
Jun 25 18:52:37 <fray> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/tree/meta/classes/image.bbclass?h=mhatle/sdk
Jun 25 18:52:41 <fray> lines 6-7
Jun 25 18:52:46 <msm> have you looked at all the modifiers for do_populate_sdk?
Jun 25 18:52:58 <msm> ahh, too late ;)
Jun 25 18:53:23 <fray> (this was unconditional.. but then it always included it...)
Jun 25 18:53:35 <fray> turning off the populate_sdk_base inherit stopped the things from coming in
Jun 25 18:53:53 <khem> what does bitbake -g meta-toolchain show in task lists
Jun 25 18:54:03 <khem> or whatever your image target is
Jun 25 18:54:45 <khem> inherit ${IMAGE_SDKINHERIT} replace it with inherit dummy
Jun 25 18:54:49 <khem> just for checks
Jun 25 18:56:27 <fray> khem, thats what the check does..
Jun 25 18:56:33 <fray> replaced w/ dummy, and nothing gets included
Jun 25 18:56:43 <khem> I know wanted to debug it
Jun 25 18:56:45 <fray> (or I should say none of the nativesdk get included)
Jun 25 18:57:04 <khem> ok
Jun 25 18:58:00 <fray> the package-depends.dot is full of all of the nativesdk dependencies (when built w/o the dummy entry)
Jun 25 18:59:21 <fray> "libxdmcp-nativesdk.do_build" [label="libxdmcp-nativesdk do_build\n1:1.1.1-r0\nvirtual:nativesdk:/home/mhatle/git/oss/oe-core/meta/recipes-graphics/xorg-lib/libxdmcp_1.1.1.bb"]
Jun 25 18:59:21 <fray> "libxdmcp-nativesdk.do_build" -> "gettext-nativesdk.do_package_write"
Jun 25 18:59:21 <fray> "libxdmcp-nativesdk.do_build" -> "gcc-cross-intermediate.do_package_write"
Jun 25 18:59:21 <fray> "libxdmcp-nativesdk.do_build" -> "libxdmcp-nativesdk.do_populate_sysroot"
Jun 25 18:59:24 <fray> intersting..
Jun 25 18:59:55 <khem> but nativesdk is needed for sdk bits
Jun 25 19:00:03 <fray> yes..
Jun 25 19:00:48 <fray> the task-depends.dot doesn't even have the populate_sdk in it
Jun 25 19:01:39 <fray> "core-image-minimal.do_rootfs" -> "beecrypt-native.do_package_write_rpm"
Jun 25 19:01:39 <fray> "core-image-minimal.do_rootfs" -> "curl-nativesdk.do_package_write_rpm"
Jun 25 19:01:50 <fray> so why is curl-nativesdk in do_rootfs?
Jun 25 19:03:16 <fray> I see no reason why do_rootfs would get any nativesdk dependencies
Jun 25 19:04:58 <fray> do_populate_sdk[depends] = "${@' '.join([x + ':do_populate_sysroot' for x in d.getVar('SDK_DEPENDS', True).split()])}"
Jun 25 19:04:59 <fray> #do_populate_sdk[rdepends] = "${@' '.join([x + ':do_populate_sysroot' for x in d.getVar('SDK_RDEPENDS', True).split()])}"
Jun 25 19:05:05 <fray> that works.. but swap it and it doesn't..
Jun 25 19:05:11 <fray> looks like a bug in the [rdepends] flag.. drat!
Jun 25 19:07:25 <khem> fray: rdepends did not work ?
Jun 25 19:07:39 <fray> when rdepends is used it seems that all of the tasks suddenly get the rdepends
Jun 25 19:08:12 <khem> can you print SDK_RDEPENDS ?
Jun 25 19:08:21 <khem> I bet its lot more than SDK_DEPENDS
Jun 25 19:08:26 <khem> which is expected
Jun 25 19:08:54 <fray> # SDK_RDEPENDS=${TOOLCHAIN_TARGET_TASK} ${TOOLCHAIN_HOST_TASK}
Jun 25 19:08:54 <fray> SDK_RDEPENDS="task-core-standalone-sdk-target task-core-standalone-sdk-target-dbg task-core-boot     task-sdk-host-nativesdk task-cross-canadian-i586"
Jun 25 19:09:08 <fray> that is where the nativesdk items come from..
Jun 25 19:09:26 <fray> ohh wait.. [depends] doesn't have any.. I thoguht it did..
Jun 25 19:09:43 * fray moves task-sdk-host-nativesdk there and see if the behavior repeats
Jun 25 19:11:07 <fray> ya, if [depends] gets a nativesdk item, then it seems to be likewise promoted to the who recipe
Jun 25 19:11:10 <fray> whole
Jun 25 19:46:03 <azertyu> hello there
Jun 25 19:46:10 <azertyu> anyone?
Jun 25 19:47:39 <azertyu> ppl are laughing when i talk about yacto project
Jun 25 19:48:10 <seebs> Does this mean you have some good Yocto jokes?
Jun 25 19:48:28 <azertyu> they say its something like an CMS
Jun 25 19:48:29 <seebs> I've been trying to come up with a good answer to "how many bitbake-based build systems does it take to change a lightbulb", but it really hasn't jelled for me.
Jun 25 19:49:20 <azertyu> w/o any use
Jun 25 19:49:44 <seebs> Well, I will freely admit that there are many millions of people who have no use at all for embedded build systems in general.  :)
Jun 25 19:53:18 <azertyu> so no one want to help me to build something using yocto
Jun 25 19:53:23 <azertyu> so i m here
Jun 25 19:54:23 <azertyu> well i got this tablet
Jun 25 19:54:25 <azertyu> archos 7 HT
Jun 25 19:54:40 <azertyu> i would like to put android on it
Jun 25 19:54:44 <azertyu> what ihave to do ?
Jun 25 19:56:05 <khem1> Android has its own build system
Jun 25 19:56:37 <azertyu> i would like to do that in bitbake ways
Jun 25 19:56:42 <khem1> yocto does not build android base system
Jun 25 19:56:44 <azertyu> is there anything wrong ?
Jun 25 19:56:45 <seebs> Yeah.  Yocto is not really aimed at "I want to put Linux on this single tablet I have".  That's not really what it's mostly *for*, I don't think.
Jun 25 19:57:00 <seebs> It's not a matter of right or wrong, just different tools for different goals.
Jun 25 19:57:10 <seebs> Yocto's solving a problem you don't have.  :P
Jun 25 19:57:39 <azertyu> what is the exact goal may i understand ?
Jun 25 19:57:52 <khem1> i think having support for android app development would not be as bad
Jun 25 19:57:54 <seebs> I would have a hard time articulating it.
Jun 25 19:58:17 <fray> problem with using bitbake for android development is not technical, it's political
Jun 25 19:58:31 <azertyu> well
Jun 25 19:58:36 <fray> the Android owners (primarily google) have their own build system and will not support any work done externally of that build system..
Jun 25 19:58:49 <fray> for the commercial developers (tabels, phones, settop boxes) this support is critical
Jun 25 19:58:52 <azertyu> android is based on linux
Jun 25 19:59:01 <khem1> it's been done though EA
Jun 25 19:59:12 <azertyu> ok cool
Jun 25 19:59:24 <azertyu> with the same device i would like to install ubuntu on it
Jun 25 19:59:30 <azertyu> what i have to do ?
Jun 25 19:59:51 <fray> talk with the ubuntu developers.. their model is differen the Yocto/OE/Android
Jun 25 20:00:46 <khem1> heh take ubuntu pen drive image and install it provided bootloader lets you do that
Jun 25 20:02:07 <khem1> best is to use a device which is supported by all something like beagleboard
Jun 25 20:02:26 <azertyu> well then how can you saying yocto solving a problem you don't have
Jun 25 20:02:36 <azertyu> for now yocto solving nothing
Jun 25 20:02:58 <khem1> using production device is always needing some attention
Jun 25 20:03:16 <seebs> That it doesn't do anything you personally need doesn't mean it doesn't do things other people need...
Jun 25 20:03:33 <seebs> I mean, outside of my work environment, I have no need for an embedded Linux build system at all, really.
Jun 25 20:04:07 <fray> Yocto is focused on enabling commercial and community developers to create an operating system specific to a device that they have extensive knowledge about..
Jun 25 20:04:17 <khem1> i dont know your problem but you are trying to use a build system when you already havr android buils system
Jun 25 20:04:19 <fray> this device may or may not be "commercial off the shelf".. it might be custom..
Jun 25 20:04:28 <fray> but in the end it's a tool to build an OS.. it is not an OS..
Jun 25 20:05:04 <fray> if you don't have a lot of technical knowledge of how a particular device works (and the hardware, bootloaders, etc) then you have a different problem.. you want an OS that runs on that device.. you don't want to "make" and OS for that device
Jun 25 20:06:21 <khem1> yocto/oe does propel certain distributions which can provide binary feeds
Jun 25 20:07:06 <azertyu> when you say yocto is design for every embeded device it is not true
Jun 25 20:07:23 <fray> I never said it was designed for every embedded device
Jun 25 20:07:50 <fray> there are a many devices Yocto isn't a good solution for, just as android, and Linux in general may not be a good solution
Jun 25 20:07:53 <azertyu> you not but yout community ppl
Jun 25 20:08:32 <fray> not that I know of.. the community has said that the Yocto Project solves a number of problems for Embedded Linux developers, and helps bring projects to "market"
Jun 25 20:10:02 <khem1> it can solve lot of problems provided one defines them clearly
Jun 25 20:10:46 <fray> The Yocto Project has more of a commercial focus as well.. Open Embedded has more of a community focus..
Jun 25 20:11:06 <fray> (community is both commercial, non-commercial and specifically "hobbiest")
Jun 25 20:11:31 <fray> but in the end the users of either Yocto or OE need to have specific knowledge about the devices they are targeting and how to interact with them at a specific software/technical level..
Jun 25 20:11:47 <fray> if you don't know how the device works, then you need a binary based distribution created by someone who does..
Jun 25 20:12:37 <fray> Yocto Project tools, and OpenEmbedded can give you a toolbox to construct your system.. but like giving someone a hammer, unless they have the specific knowledge required, they likely can't just go and build a house with that hammer
Jun 25 20:17:54 <seebs> Basically, if you are a manufacturer and you want to ship a few million of something, and you want to custom-build a Linux distro for it, Yocto might be a great head start on that.
Jun 25 20:18:03 <seebs> For a single user with a single device, it's not as attractive.
Jun 25 20:23:04 <azertyu> well
Jun 25 20:23:23 <azertyu> give me some example of project done by yocto ?
Jun 25 20:25:39 <fray> khem, the toolchain just reconfigured itself again.. (working w/ denzil and not master)
Jun 25 20:25:48 <fray> did you ever figure out what might have been causing that?
Jun 25 20:27:19 <khem> fray: never got a change to look into it
Jun 25 20:27:24 <fray> 'k
Jun 25 20:27:30 <khem> although with master I see it behaves better
Jun 25 20:27:46 <fray> ya, I wonder why it does it on a re-build, but not the first build
Jun 25 20:34:20 <khem> fray: reverse dependencies e.g. if you change eglibc recipes it pretty much guarntees toolchain rebuild
Jun 25 20:34:30 <khem> with basichash even more
Jun 25 20:34:54 <fray> ya... I'm not concerned with why it rebuilt (I expect that is correct).. it's more why did the rebuild trigger an autoreconf
Jun 25 21:37:22 <dvhart> is anyone else seeing issues building sato-sdk with the update-alternatives failing to set the reset link?
Jun 25 21:38:43 * fray hasn't tried that in a while...
Jun 25 21:38:56 <fray> look at the providers, it's possible one of them has an incorrect reset configuration
Jun 25 21:41:12 <chackal_sjc> guys
Jun 25 21:41:20 <chackal_sjc> I'm having a: ERROR: QA Issue: No GNU_HASH in the elf binary:
Jun 25 21:41:30 <chackal_sjc> in a binary that I is pre-build
Jun 25 21:41:41 <chackal_sjc> how to desable this isane test?
Jun 25 21:42:13 * fray forgets off hand..
Jun 25 21:42:24 <fray> give me a couple minutes and I'll look it up
Jun 25 21:42:30 <chackal_sjc> thx
Jun 25 21:43:51 <fray> INSANE_SKIP_<package> = "ldflags"
Jun 25 21:44:09 <fray> it's <package> not recipe
Jun 25 21:48:14 <chackal_sjc> hmm
Jun 25 21:48:37 <chackal_sjc> like this?
Jun 25 21:48:37 <chackal_sjc> INSANE_SKIP_${PN} += "ldflags"
Jun 25 21:51:01 <chackal_sjc> fray: I'm already doing this, but still getting the error =/
Jun 25 21:51:14 <fray> it's NOT ${PN}.. it's the package
Jun 25 21:51:26 <fray> you need one per package
Jun 25 21:51:37 <chackal_sjc> how to get the package name?
Jun 25 21:52:12 <chackal_sjc> NOTE: package xf86-video-mali-1.0-0: task do_package: Failed
Jun 25 21:52:20 <chackal_sjc> xf86-video-mali-1.0-0 is the package name?
Jun 25 21:52:31 <fray> what is the line w/ the actual error message?
Jun 25 21:53:10 <fray> I'm not sure if it lists the name or not
Jun 25 21:53:35 <chackal_sjc> could be ${PN}-${PV}-${PR} ?
Jun 25 21:53:45 <fray> no..
Jun 25 21:53:55 <fray> it'll be something like x86-video-mali
Jun 25 21:54:08 <fray> past the error line.. it probably has it
Jun 25 21:54:22 <chackal_sjc> ERROR: QA Issue: No GNU_HASH in the elf binary: '/home/felipe/projects/distro-creator/tmp/metadata-g2-poky/willow-yocto/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/xf86-video-mali-1.0-0/packages-split/xf86-video-mali/usr/lib/libMali.so'
Jun 25 21:54:25 <chackal_sjc> this is the actual lie
Jun 25 21:54:26 <chackal_sjc> line
Jun 25 21:54:43 <fray> inside the "packages-split" is each of the packages..
Jun 25 21:54:48 <fray> packages-split/xf86-video-mali
Jun 25 21:54:54 <fray> so the name of the "package" is xf85-video-mali
Jun 25 21:55:12 <fray> INSANE_SKIP_xf86-video-mali = "ldflags" should do it
Jun 25 21:55:47 <chackal_sjc> so, this is the ${PN} var anyway
Jun 25 21:56:05 <fray> it may be the same as ${PN}.. but it's not actually pn..
Jun 25 21:56:14 <fray> ${PN} is the recipe name.. which is often the package name..
Jun 25 21:56:21 <fray> sorry often the -first- package name
Jun 25 21:56:29 <fray> but it doesn't have to be..
Jun 25 21:56:44 <chackal_sjc> yes, but in this case, which they are the same, it still not working
Jun 25 21:56:49 <chackal_sjc> lemme try hardcode the name
Jun 25 21:56:59 <fray> look at meta/classes/insane.bbclass around like 660.. thats where the insane skip is used
Jun 25 21:57:16 <fray>     for package in packages.split():
Jun 25 21:57:16 <fray>         skip = (d.getVar('INSANE_SKIP_' + package, True) or "").split()
Jun 25 21:57:16 <fray>         if skip:
Jun 25 21:57:16 <fray>             bb.note("Package %s skipping QA tests: %s" % (package, str(skip)))
Jun 25 21:57:23 <fray> you should get a message it's going to skip it
Jun 25 21:57:48 <fray> if you don't see the message, something is wrong w/ the check
Jun 25 21:59:02 <chackal_sjc> yeah, i know whats going on
Jun 25 21:59:10 <chackal_sjc> I forget to commit my code ;)
Jun 25 21:59:20 <chackal_sjc> it should work
Jun 25 22:17:09 <khem> what is prerequisites for hob
Jun 25 22:17:15 <khem> is it documented some where ?
Jun 25 22:17:23 <khem> I am looking for kubuntu
Jun 25 22:22:02 <khem> sudo apt-get install python-gobject-2-dev python-gtk2-dev
Jun 25 22:22:24 <khem> may be it should be mentioned in some FAQ
Jun 25 22:34:48 <dvhart> khem, it most definitely should
Jun 25 22:35:24 <dvhart> khem, forwarding irc blurb to the docs master
Jun 25 22:36:26 <sgw> khem, are you going to resubmit the kconfig patch fixed up?
Jun 25 22:44:07 <ant__> sgw: do you need some udev config logs? I'll wipe tmpdir in a few mins...
Jun 25 22:45:24 <sgw> ant__: no, I am still not sure how I got that failure, I tried a couple different times here again cleaning sstate and just doing cleans of linux-libc-headers, mtd-utils (with and without your patch) and udev and could not reproduce the failure!
Jun 25 22:45:42 <ant__> ouch :/
Jun 25 22:45:42 <sgw> I am going to pull it with my next batch tomorrow likely.
Jun 25 22:46:43 <ant__> thx, I have a couple of patches depending on this
Jun 25 22:47:05 <sgw> I understand, I will get it there.
Jun 25 22:47:28 <ant__> np, I'll have to bump Koen a$$
Jun 25 22:47:32 <ant__> ;)
Jun 25 22:47:49 <ant__> he seems very busy atm
Jun 25 22:49:29 <ant__> sgw: btw now I do have a doubt.. is it right for klibc to depend on linux-libc-headers? We can assume those are provided, isn't?
Jun 25 22:50:50 <ant__> ah, I see, uclibc lists those, then ok
Jun 25 22:51:14 <sgw> ant__: glad I could help straighten that out ;-)
Jun 25 22:52:10 <ant__> imagine at the time of oe-classic we Gentoo builders were struggling for some strange race and had to ASSUME_PROVIDED the headers :)
Jun 25 23:09:17 * dvhart just successfully build hello-mod (kernel module) on the target with a modified core-image-sato-sdk image!
Jun 25 23:15:16 <chackal_sjc> im trying to compile xorg 1.10.4 and Im getting this on the configure
Jun 25 23:15:29 <chackal_sjc> checking for GL... no
Jun 25 23:15:29 <chackal_sjc> configure: error: Package requirements (glproto >= 1.4.10 gl >= 7.1.0) were not met:
Jun 25 23:15:30 <chackal_sjc> No package 'gl' found
Jun 25 23:15:50 <chackal_sjc> isn't glproto support to install opengl packages?
Jun 26 00:10:37 <khem> dvhart: so what did you change ?
Jun 26 00:10:45 <khem> dvhart: I might be doing something similar here
Jun 26 00:11:00 <khem> dvhart: did you change kernel packaging to install sources on target
Jun 26 00:11:12 <khem> or create a kernel-src package ?
Jun 26 00:12:43 <khem> sgw: eventually yes I will resubmit but its on backburner for now
Jun 26 00:15:00 <khem> my problem is that we enable CONFIG_HAVE_C_RECORDMCOUNT=y
Jun 26 00:15:28 <khem> which means that recordmount utility should be available in packed kernel sources when building external mod
Jun 26 00:15:50 <khem> recordmount is a host utility so all hell breaks when you want to package it up
**** ENDING LOGGING AT Tue Jun 26 02:59:58 2012

**** BEGIN LOGGING AT Tue Jun 26 02:59:58 2012
Jun 26 07:14:17 <mckoan> good morning
Jun 26 14:06:35 <ignus16> Hello all, does anyone know how to disable specific sanity checks in yocto? the umask check fails but I cant figure out why...
Jun 26 14:13:56 <Orre> Hello! Just wondered if anyone knows why the bblayers.conf location is hardcoded in the kernel.py file (row 40) /scripts/libs/bsp/
Jun 26 14:15:03 <Orre> Made me quite confused until I found out that I had to change said path if I wanted yocto-kernel to work
Jun 26 14:15:17 <Orre> This is for the poky-denzil-7.0 version*
Jun 26 15:02:18 <darknighte> hmmm
Jun 26 15:02:41 <darknighte> song you around?
Jun 26 15:02:58 <gcoville> The "operator" seemed nice, though.
Jun 26 15:03:05 <Jefro> Good morning all - engineering call starting
Jun 26 15:03:19 <gcoville> Is there new dialin information?
Jun 26 15:03:26 <sgw> Morning all, Saul's on.
Jun 26 15:03:39 <sgw> 1.972.995.7777 / 76994298
Jun 26 15:03:42 * RP__ is here
Jun 26 15:03:49 <fray> thanks.. was just going to ask the same thing.. ;)
Jun 26 15:03:51 * halstead is here.
Jun 26 15:03:54 <rburton> ross is here
Jun 26 15:03:57 * davest here
Jun 26 15:03:57 <darknighte> jefro: made it in
Jun 26 15:03:57 * bluelightning_ is here
Jun 26 15:03:58 <jmpdelos> polk is here
Jun 26 15:04:01 * tomz1 here
Jun 26 15:04:01 <dvhart> All, wait until song joins
Jun 26 15:04:07 <rburton> i was going to propose a #yocto-meeting room :)
Jun 26 15:04:16 <bluelightning_> rburton: I think that would be a good idea
Jun 26 15:04:22 <Jefro> Song is having trouble joining the room
Jun 26 15:04:33 <gcoville> Gilbert Coville is here
Jun 26 15:04:35 <Jefro> Collecting attendees
Jun 26 15:04:40 <darknighte> rburton: I 2nd that!
Jun 26 15:04:57 <fray> I'm here now
Jun 26 15:04:58 <halstead> rburton, bluelightning: this shows that our project is nice and active.
Jun 26 15:05:11 <dvhart> dvhart, I've joined
Jun 26 15:05:18 <denix> I'm here as well
Jun 26 15:05:25 <jzhang> jz
Jun 26 15:05:45 * sgw also
Jun 26 15:06:32 <fray> "who is gcoville?"  doesn't everyone know Gilbert?  ;)
Jun 26 15:07:27 * davest is the only one who doesn't know gcoville, apparently
Jun 26 15:07:34 * gcoville hardly knows
Jun 26 15:07:36 * RP__ doesn't/didn't either
Jun 26 15:07:49 <fray> (gcoville is the one who got me hired at MontaVista...)
Jun 26 15:08:03 * sgw would like to sync with fray later
Jun 26 15:08:05 <darknighte> heh, i didn't realize that gcoville was such a rock star
Jun 26 15:08:16 <fray> employee #2? at MV?
Jun 26 15:08:34 * Jefro asks: any open issues?
Jun 26 15:08:38 <RP__> no opens?
Jun 26 15:10:28 <darknighte> anyone have the link handy?
Jun 26 15:10:43 <davest> https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.3_Status
Jun 26 15:10:51 <fray> thanx
Jun 26 15:10:52 <darknighte> davest: thanks
Jun 26 15:14:02 <darknighte> I just noticed that there is a link that says Yocto_1.2_Schedule under the Milestone 1 Status.
Jun 26 15:14:26 <davest> darknighte: will mention
Jun 26 15:15:46 <davest> fray: knock knock
Jun 26 15:15:47 <darknighte> davest: I went ahead and updated the link.
Jun 26 15:15:51 <fray> here..
Jun 26 15:15:57 <fray> I see the prelink bug, we can release M1 with it
Jun 26 15:16:10 <fray> I won't haev time to work on it until wednesday or early next week..
Jun 26 15:16:10 <davest> darknighte: thanks
Jun 26 15:16:18 <fray> (I've got an internal release I'm on the hook for first)
Jun 26 15:18:01 <sgw> fray: I could use a few minutes to talk about pseudo issue I am having
Jun 26 15:18:08 <fray> yup..
Jun 26 15:18:15 <dvhart> zeddii, I said it would take a week to rebase to LTSI once we had a release from gregkh
Jun 26 15:18:20 <fray> I think you can set PSEUDO_DEBUG=<number>
Jun 26 15:18:33 <fray> then spawn a shell.. and it'll activate the debugging
Jun 26 15:18:34 <dvhart> zeddii, also committed to ltsi rebase during 1.3 (no risk of not making m5)
Jun 26 15:18:42 <dvhart> zeddii, speak up if you disagree ;-)
Jun 26 15:18:50 <sgw> fray before launching bitbake?
Jun 26 15:18:55 <fray> seebs is the one who would likely know what all of the debug messages mean.. start at level 1 and go up from there..
Jun 26 15:18:58 <fray> no in the devshell..
Jun 26 15:19:04 <fray> I -think- you can set it that way
Jun 26 15:19:15 <fray> if that doesn't work, you'll have to do it before launching bitbake..
Jun 26 15:19:27 <sgw> If it's seebs, then I will ping him also.
Jun 26 15:20:34 <darknighte> bug being discussed: https://bugzilla.yoctoproject.org/show_bug.cgi?id=2484
Jun 26 15:22:18 * fray needs more sleep..
Jun 26 15:22:35 <darknighte> fray: don't we all!?
Jun 26 15:23:02 * fray likes open sushi
Jun 26 15:23:06 <Jefro> I totally want sushi now
Jun 26 15:23:11 * darknighte wants sushi now.
Jun 26 15:23:15 <fray> Mmm.. breakfast sushi
Jun 26 15:23:18 * RP__ does not
Jun 26 15:23:18 <darknighte> of course, I had it yesterday.
Jun 26 15:23:28 <darknighte> fray: speak for yourself.  I've been up since 6am my time.
Jun 26 15:23:39 <darknighte> it's lunch sushi for me!
Jun 26 15:23:48 <rburton> pah, my son got me up at 0530
Jun 26 15:23:52 <Jefro> I think Sean Hudson and fray are in the same time zone (CST)
Jun 26 15:23:57 <rburton> "daddy, you really like coffee don't you"
Jun 26 15:24:16 <Jefro> rburton does he make you coffee as well? good life skill to teach
Jun 26 15:24:40 * davest woke at 4:45AM before the alarm went off
Jun 26 15:25:21 <fray> yup..  pending my internal work as well.. :(
Jun 26 15:30:02 <rburton> Jefro: sadly not
Jun 26 15:30:50 <davest> One of my daughters worked as a barrista at Starbucks for several years and she *still* doesn't make me coffee!
Jun 26 15:30:53 <fray> woohoo! M1 done
Jun 26 15:31:22 * darknighte cheers
Jun 26 15:32:40 <zeddii> dvhart, just back to my desk now. I picked a good meeting to miss.
Jun 26 15:32:45 <zeddii> well, I didn't pick it per-se.
Jun 26 15:32:59 <zeddii> I was NMId
Jun 26 15:33:08 <zeddii> but yes that number is fine :)
Jun 26 15:33:26 <darknighte> heh.  didn't realize that had become a verb zeddii
Jun 26 15:34:20 <dvhart> zeddii, ;-)
Jun 26 15:34:36 <zeddii> I can verb anything!
Jun 26 15:34:37 <dvhart> zeddii, when was the last sync you've had with gregkh?
Jun 26 15:34:59 <RP__> interrupted is a verb
Jun 26 15:35:00 <dvhart> We will have LTSId the linux-yocto kernel for the 1.3 release
Jun 26 15:35:05 <zeddii> couple of weeks ago, and then we had another information sync on a thread spawned from the kernel summit threads.
Jun 26 15:35:48 <dvhart> zeddii, great, thanks
Jun 26 15:36:40 <darknighte> zeddii: you in the call now?
Jun 26 15:38:00 <zeddii> no. but I could dial in if it is still going.
Jun 26 15:38:13 <zeddii> after half an hour, I time out my late joins :)
Jun 26 15:38:54 <darknighte> zeddii: nah, dvhart is covering/has covered for you.
Jun 26 15:39:12 <zeddii> ok. unplanned absence. sorry about that.
Jun 26 15:40:17 <dvhart> zeddii, tomz1, we need to schedule a time to talk this week about the kernel policy bug
Jun 26 15:40:35 <dvhart> zeddii, tomz1, I'd love to get that knocked out for M2 if at all possible, that one has really dragged
Jun 26 15:40:56 <kergoth> hmm, the ctng toolchain has no mag_IN locale
Jun 26 15:41:26 <tomz1> dvhart: sounds good, schedule something and i'll be there !
Jun 26 15:42:02 <zeddii> dvhart, did you see the patches/work we started on that (in my pull request from Monday) ? It's a starting point at least, and well tested at this point. I'm here all week .. next week, not so much.
Jun 26 15:42:34 <dvhart> great, will review (a bit out of pocket yesterday) and set something up for Thursday
Jun 26 15:47:53 * zeddii hunts for food
Jun 26 15:51:08 <darknighte> fray: sounds cool.
Jun 26 15:52:17 <fray> goal is to be able to do something like: bitbake -c populate_sdk core-image-basic
Jun 26 15:52:25 <fray> you should get an SDK that matches core-image-basic
Jun 26 15:53:39 <darknighte> I like the idea and will look for the patches
Jun 26 15:53:56 <fray> (poky-contrib  mhatle/sdk  for my work in progres...  subject to change of course)
Jun 26 15:54:17 <darknighte> thx
Jun 26 15:59:24 <dvhart> https://bugzilla.yoctoproject.org/show_bug.cgi?id=1614
Jun 26 16:04:52 <bluelightning> for reference, the web hob design posting from Friday: http://www.mail-archive.com/yocto@yoctoproject.org/msg07014.html
Jun 26 16:06:42 <khem> zeddii: will you have some time today ?
Jun 26 16:26:36 <JaMa> RP__: hi, does new bitbake require new MIRRORS/PREMIRRORS syntax or should old MIRRORS also work with newer fetcher2?
Jun 26 16:42:18 <JaMa> RP__: looks like 'http' is no longer matchinig 'https?$' see http://trac.shr-project.org/trac/attachment/ticket/2028/log.do_fetch.30883
Jun 26 16:57:00 <sgw> RP__: do_install question for you, is the -native do_install run under pseudo?
Jun 26 16:57:31 <fray> I think it is, but I'm not sure
Jun 26 16:57:35 <seebs> sgw: all pseudo issues are user error.  I have commanded it.
Jun 26 16:57:40 <fray> ha
Jun 26 16:57:54 <sgw> seebs thanks, that makes be much happier!
Jun 26 16:57:56 * fray sees seebs is awake.. ;)
Jun 26 16:58:55 <seebs> Lies!  Vile calumnies!
Jun 26 16:59:01 <seebs> I'll cop to "conscious".
Jun 26 17:00:35 <sgw> seebs: it's still strange, I have 2 builds one will run do_install fine with no error, but the second (non-gplv3) will fail, I am beginning to wonder if it's a library that PSEUDO is using that is older (because it's using the gplv2 version)
Jun 26 17:00:43 <seebs> hmm
Jun 26 17:01:08 <seebs> Trying to remember, I thought the only thing I linked against that was likely to matter was sqlite, which I believe is not gplv3.
Jun 26 17:01:46 <sgw> seebs: correct only 1 version of that recipe
Jun 26 17:01:56 <fray> ya, its only sql
Jun 26 17:02:09 <sgw> seebs: can I connect to the files or logs db and see what's going on?
Jun 26 17:02:37 <seebs> Oh, boy.
Jun 26 17:02:58 <seebs> Long story short:  There's a ton of debugging stuff, but the messages are pretty cryptic, and I've never gotten the time to go back and make them more comprehensible.
Jun 26 17:03:29 <seebs> If you run the pseudo daemon with "-l", it creates logs of everything that happens, which you can read with pseudolog.  This is per-state-dir.
Jun 26 17:03:56 <sgw> Ok how do I make bitbake fire up pseudo that way?
Jun 26 17:03:58 <seebs> If you have PSEUDO_DEBUG in the environment, you get more information.  Debug level 2 is ludicrously verbose, and the ever-louder-levels model sucks.
Jun 26 17:04:12 <seebs> ... I also don't know that.  I haven't done it in yocto, only in the old WR build system.
Jun 26 17:04:16 <fray> sgw, you should be able to hack up the PSEUDO vars
Jun 26 17:04:29 <fray> which I don't have a copy of at the moment.. look at bitbake.conf?
Jun 26 17:04:30 <seebs> We might want to have PSEUDO_DEBUG in the whitelist.  :)
Jun 26 17:04:33 <sgw> fray, that what I was figuring.
Jun 26 17:04:44 <fray> might be in the shell env setup though
Jun 26 17:04:56 <fray> it's whatever runs "pseudo"
Jun 26 17:05:21 <fray> wait.. I think pseudo is being auto run by the wrapper librry.. can the -l be enabled when that happens?
Jun 26 17:06:39 <sgw> This is when I wish I could turn off some of the hashing stuff so it does not try to rebuild the world when I change something
Jun 26 17:06:55 <fray> changing pseudo shouldn't change the hash.. if it does, we need another ignore
Jun 26 17:07:09 <sgw> add another ignore and you rebuild!
Jun 26 17:07:16 <fray> ;)  ya but only once
Jun 26 17:07:37 <sgw> until you add another!
Jun 26 17:27:06 <sgw> seebs: is this from pseudo: Intercept /intel/poky2/distro/scripts/native-intercept/chown: -R root:root /intel/poky2/builds/fetch/tmp/work/x86_64-linux/gnome-doc-utils-native-0.20.6-r8/image -- do nothing
Jun 26 17:27:26 <seebs> That doesn't look like anything I'm aware of.
Jun 26 17:27:58 <sgw> seebs: great! I find this happens on one build but on the other build I get a bunch of chown failures!
Jun 26 17:28:12 <fray> note the "native-intercept/chown"
Jun 26 17:28:13 <sgw> same machine same source base
Jun 26 17:28:21 <fray> there is a wrapper script someone generated somewhere!
Jun 26 17:28:38 <sgw> fray thanks was focusing on the wrong thing!
Jun 26 17:28:49 <fray> figured that.. ;)
Jun 26 17:35:35 <sgw> fray: well that's the problem!  The native-intercept is being added to the path AFTER the sysroots, and in one case the native chown seems to be installed and the other case not, now why not, I am not sure yet
Jun 26 17:35:47 <fray> odd
Jun 26 17:35:55 <sgw> your tell me!
Jun 26 17:43:23 <sgw> fray: tracked the bugger down!  coreutils_6.9 (gplv2 version) depends on coreutils-native, while the newer version of coreutils does not have the native self-depends, thus for non-gplv3, we get core utils installed in sysroot and since the native-intercept is after sysroot (and -native do not use pseudo) we go kaboom!
Jun 26 17:43:44 <fray> ahh
Jun 26 17:43:56 <sgw> no more like doh
Jun 26 17:44:26 <fray> heh
Jun 26 17:44:57 <sgw> I wonder what causes the self - dependency (first off) and secondly I need to fix the native-intercept location!
Jun 26 18:02:34 <fray> sgw -- BTW I spotted yesterday in toolchain-scripts.bbclass that the system is setting PKG_CONFIG_PATH=... the sysroot path.. thats actually not correct for two reasons..
Jun 26 18:03:18 <fray> I'm going through 3 sets of walls (and businesses) to the cafe
Jun 26 18:03:21 <fray> oos
Jun 26 18:03:25 <fray> oops
Jun 26 18:03:40 <sgw> fray: multi tasking are we?
Jun 26 18:03:59 <fray> na.. just complaining I can't sit and the town cafe and get onto my work wireless.. ;)
Jun 26 18:04:10 <fray> macbook sees the network, but the access point doesn't see the mac
Jun 26 18:04:23 <fray> (if I sit in one booth, it works...)
Jun 26 18:37:53 <sgw> zeddii: the mpc8315e-rdb kernel is failing to find a patch or branch or ???, can you take a look: http://autobuilder.yoctoproject.org:8010/builders/nightly-ppc/builds/448/steps/shell_126/logs/stdio
Jun 26 18:40:57 <zeddii> looks like a double include. I'll fix it.
Jun 26 18:41:06 <zeddii> is that with my latest patches queued ?
Jun 26 18:46:04 <sgw> yes and no (I have it in both cases)
Jun 26 18:51:01 <zeddii> cool. just checking, sparking up a build now.
Jun 26 18:53:45 <sgw> zeddii: not sure why I did not see it when I built mut earlier with your changes
Jun 26 18:54:03 <zeddii> me either. let me see if I can reproduce it here.
Jun 26 18:55:46 * zeddii checks master. ok not on there yet. I've pulled my changes to a clean builder.
Jun 26 19:32:49 <zeddii> sgw, bhaha!! easy fix. the old commits will stand, one more kernel meta branch commit for 3.0 will arrive in the next 30 mins or so.
Jun 26 19:33:14 <sgw> zeddii: thanks!
Jun 26 19:35:56 <khem> I am trying to divert a git fetch to local clone, but bitbake is not liking it
Jun 26 19:36:24 <khem> all I did is use file:///path/to/git/repo/on/local/disk;proto=git
Jun 26 19:36:37 <khem> infact any proto= does not work
Jun 26 19:36:55 <khem> anyone done something similar
Jun 26 19:44:37 <kergoth> might be 'protocol' rather than 'proto'
Jun 26 19:44:45 <khem> hmm
Jun 26 19:45:02 <khem> I think something like git:///path/to/git/repo/on/local/disk;proto=file might work
Jun 26 19:45:05 <khem> lemme try that
Jun 26 20:17:34 <zeddii> khem. my client wasn't showing your ping, sgw's ping superceeded it. sorry about that. I have to head rather quickly. I'll in all day tomorrow and can sync up on your request from last week .. it's now the top of my list. want to ping me in your morning ?
Jun 26 20:20:36 <kergoth> khem: yeah, protocol doesn't control what fetcher is used, only the url scheme does that
Jun 26 20:26:48 <seebs> Has anyone seen an issue with eglibc-2.13 packaging failing due to locale-base-tt-ru appearing more than once in PACKAGES?
Jun 26 20:27:08 <seebs> I found this and found a trivial fix (patching SUPPORTED), but I haven't actually seen it when using Yocto.
Jun 26 20:27:37 <seebs> I can send it out, but if it's only affecting us I don't suppose anyone cares.
Jun 26 21:08:02 <khem1> seebs on master eglibc 2.13 is gone so if you cam reproduce it on 2.15 then its interesting
Jun 26 21:08:36 <khem1> s
Jun 26 21:09:05 <khem1> zeddii will do
Jun 26 21:10:11 <khem1> kergoth the issue is use of -l option to git clone
Jun 26 21:11:31 <khem1> IMO thats wronh
Jun 26 21:12:13 <khem1> since now it will barf on hard linking across disks
Jun 26 21:28:05 <kergoth> didn't rihard recently send a patch to the list to stop using it?
Jun 26 21:28:12 <kergoth> pretty sure i saw something about that when getting caught up on email
Jun 26 21:33:01 <khem> could be I dont follow bitbake-dev so closelt
Jun 26 21:33:35 <khem> kergoth: we need to add --no-hardlinks there
Jun 26 21:33:38 <khem> and it will be fine
Jun 26 21:34:19 <khem> and as I read -l is default now
Jun 26 21:37:04 <khem> commit 3aeb268b2aaab4bb8b1cfff1450e0b76aa8ce855
Jun 26 21:38:13 <kergoth> it's git that uses it when necessary, the fetcher never passes -l anymore at all
Jun 26 21:38:16 * kergoth shrugs
Jun 26 21:40:03 <khem> kergoth: yes it does not
Jun 26 21:40:16 <khem> kergoth: but this commit is not cherry picked into poky
Jun 26 21:40:18 <khem> yet
Jun 26 21:40:21 <kergoth> ah
Jun 26 21:40:30 * kergoth rolls eyes
Jun 26 21:41:30 <khem> wait its there
Jun 26 21:41:36 <khem> freaking branch
Jun 26 21:41:49 <khem> never mind all sorted
Jun 26 22:35:38 <chackal_sjc> how to get the HEAD from the git repo instead using SRCREV?
Jun 26 22:36:00 <chackal_sjc> because everytime we update the gitrepo we need to change the SRCREV commit hash
Jun 26 22:50:42 <kergoth> SRCREV = "${AUTOREV}", but it's rarely the best idea
Jun 27 00:09:39 <mranostay> kergoth: ever :)
Jun 27 01:02:48 <chackal_sjc> whats the password for openssh ?!
Jun 27 01:02:53 <chackal_sjc> for a rootless environment
Jun 27 01:03:15 <chackal_sjc> not openssh, root's password
Jun 27 01:03:18 <chackal_sjc> im connecting via ssh
Jun 27 01:08:11 <mranostay> enter?
Jun 27 01:08:39 <mranostay> if you can
Jun 27 01:08:50 <mranostay> 't do su - then you don't have the password
Jun 27 01:16:40 <chackal_sjc> mranostay: enter doesn't work
**** ENDING LOGGING AT Wed Jun 27 02:59:58 2012

**** BEGIN LOGGING AT Wed Jun 27 02:59:58 2012
Jun 27 03:31:20 <evanp> anybody ever seen bitbake core-image-minimal fail because it tried to do_patch on gcc-cross-initial and libgcc simultaneously?
Jun 27 03:33:14 <evanp> it fails because they're racing hunk-by-hunk--one guy wins, the other complains that the patch can be reverse-applied
Jun 27 14:27:13 <FunkyPenguin> has anyone got decent pointers on how to create custom kernels with yocto? I need to use a specific 3.3 branch and also mainline
Jun 27 14:29:14 <br_hugo> Hi all!
Jun 27 14:30:24 <kergoth> hmm, anyone else hitting openjade-native build failures?
Jun 27 14:32:06 <br_hugo> I'm new on Yocto and I'm trying to build my custom image with libiconv, but some build failures occurs... Anyone help-me ?
Jun 27 14:33:05 <vmeson> br_hugo: what's the error? use pastebin if it's more than 3 lines.
Jun 27 14:33:50 <br_hugo> So, do_compile, do_install and do_populate_sysroot works fine...
Jun 27 14:34:13 <br_hugo> do_package fails...
Jun 27 14:34:14 <br_hugo> ERROR: QA Issue: package libiconv contains bad RPATH $ORIGIN/../lib:/home/omnimed/work/yocto/poky/build/tmp/work/i586-poky-linux/libiconv-1.14-r1/image/usr/lib in file /home/omnimed/work/yocto/poky/build/tmp/work/i586-poky-linux/libiconv-1.14-r1/packages-split/libiconv/usr/bin/iconv
Jun 27 14:34:15 <br_hugo> ERROR: QA run found fatal errors. Please consider fixing them.
Jun 27 14:34:15 <br_hugo> ERROR: Function failed: do_package_qa
Jun 27 14:34:15 <br_hugo> ERROR: Logfile of failure stored in: /home/omnimed/work/yocto/poky/build/tmp/work/i586-poky-linux/libiconv-1.14-r1/temp/log.do_package.13743
Jun 27 14:34:16 <br_hugo> NOTE: package libiconv-1.14-r1: task do_package: Failed
Jun 27 14:35:23 <bluelightning> FunkyPenguin: have you had a look at our kernel manual? http://www.yoctoproject.org/docs/current/kernel-manual/kernel-manual.html
Jun 27 14:36:05 <bluelightning> br_hugo: that's with the stock libiconv recipe?
Jun 27 14:36:25 <FunkyPenguin> bluelightning: ah thanks, i missed that entry in the documentation index - thanks for the pointer
Jun 27 14:37:37 <br_hugo> I'm using the recipe that's come with yocto... meta/recipes-support/libiconv/libiconv_1.14.bb
Jun 27 14:37:50 <bluelightning> ok
Jun 27 14:38:09 <bluelightning> so I'm surprised that this produces an rpath warning out of the box...
Jun 27 14:39:08 <bluelightning> oh, right, this is a little tricky
Jun 27 14:39:34 <bluelightning> br_hugo: do you actually need the libiconv provided by the libiconv recipe? or can you use the libiconv that comes with eglibc?
Jun 27 14:41:18 <br_hugo> Actually I write a recipe to build DCMTK lib. DCMTK lib needs libpng libiconv libxml2 openssl zlib tcp-wrappers tiff
Jun 27 14:41:54 <br_hugo> So, my recipe is using the libiconv recipe...
Jun 27 14:42:43 <br_hugo> But, I believe that the eglibc iconv lib works too..
Jun 27 14:43:48 <br_hugo> Can I use virtual/libiconv ?
Jun 27 14:45:59 <bluelightning> br_hugo: if that works, that's what I would suggest, yes
Jun 27 14:46:12 <bluelightning> that way it will use the libiconv selected by the distro
Jun 27 14:46:44 <br_hugo> Ok... I will try now...
Jun 27 14:47:24 <br_hugo> A moment..
Jun 27 14:51:15 <br_hugo> :( DCMTK fails...
Jun 27 14:54:14 <br_hugo> DCMTK uses explicitly libiconv with libxml2 to translate XML objects to DICOM objects
Jun 27 14:54:43 <bluelightning> br_hugo: does it fail because of iconv incompatibility though?
Jun 27 14:55:01 <br_hugo> yes
Jun 27 14:56:20 <br_hugo> or rather, I believe so, rs
Jun 27 14:57:30 <bluelightning> ok
Jun 27 14:58:02 <bluelightning> it's possible that we are not fully testing the separate libiconv recipe, which might explain why it produces a warning
Jun 27 14:58:14 <bluelightning> the warning may not be too difficult to fix
Jun 27 14:58:39 <bluelightning> sometimes it's as easy as specifying --disable-rpath or similar at configure time
Jun 27 14:59:19 <br_hugo> The error above is from bitbake libiconv...
Jun 27 14:59:25 <bluelightning> what I don't know is if it's OK to just set PREFERRED_PROVIDER_virtual/libiconv = "libiconv" - will eglibc be OK with that?
Jun 27 14:59:29 <bluelightning> yes, I know
Jun 27 14:59:38 <bluelightning> the recipe has an error that needs to be fixed
Jun 27 15:00:28 <br_hugo> Its strange, the yocto's libiconv recipe really has an error ?
Jun 27 15:00:42 <bluelightning> it's a warning which we interpret as an error
Jun 27 15:00:58 <bluelightning> as a workaround you can change it back to a warning
Jun 27 15:01:14 <br_hugo> Ok...
Jun 27 15:01:36 <br_hugo> If I send to you my dcmtk recipe, can you test him?
Jun 27 15:02:00 <bluelightning> you can edit meta-yocto/conf/distro/poky.conf and move "rpaths" to WARN_QA instead of ERROR_QA
Jun 27 15:02:21 <bluelightning> unfortunately I don't have time but if you do the above the error should turn into a warning and it won't stop the build anymore
Jun 27 15:02:29 <bluelightning> ultimately it will still need to be fixed though
Jun 27 15:04:36 <br_hugo> moving rpaths to WARN_QA, the libiconv recipe works
Jun 27 15:05:01 <br_hugo> Can I use WARN_QA_libiconv ?
Jun 27 15:16:52 <bluelightning> br_hugo: you can use WARN_QA_pn-libiconv and ERROR_QA_pn-libiconv yes
Jun 27 15:17:06 <bluelightning> (note pn-libiconv not pn_libiconv)
Jun 27 15:48:59 <bluelightning> br_hugo: I've filed bug 2669 to get the bug fixed in libiconv
Jun 27 16:10:38 <br_hugo> Ok! Thanks!
Jun 27 16:18:50 <evanp> hey everybody
Jun 27 16:20:23 <evanp> anybody ever had success with BB_NUMBER_THREADS=80 or so? not working for me (race condition)
Jun 27 16:20:46 <kergoth> if you find race issues, report them :)
Jun 27 16:20:58 * kergoth usually builds with 12 threads, -j16
Jun 27 16:22:08 <evanp> I'll contribute a patch if I can find a good workaround--I was hoping for some guidance.
Jun 27 16:22:31 <evanp> in particular, the problem is do_unpack of libgcc and gcc-cross-initial running concurrently
Jun 27 16:22:40 <evanp> but they share ${S}, so it blows up
Jun 27 16:23:31 <evanp> I tried adding do_fetch[depends] += "virtual/${TARGET_PREFIX}gcc" to the libgcc recipe, but it broke meta-toolchain
Jun 27 16:24:27 <evanp> I meant "...:do_populate_sysroot"
Jun 27 16:25:22 <kergoth> shared workdirs have special handling, i'd check that code
Jun 27 16:27:19 <evanp> where is that? base.bbclass? don't know my way around yet.
Jun 27 16:35:23 <kergoth> probably, dont' recall offhand, would have to do some grepping
Jun 27 16:53:00 <seebs> Huh, that's odd.
Jun 27 16:53:10 <seebs> We're using an external toolchain, but eglibc is getting built from source anyway.
Jun 27 16:56:51 <kergoth> odd indeed
Jun 27 16:57:07 <kergoth> time to bust out -g
Jun 27 16:57:25 <kergoth> | /bin/sed: can't read /home/kergoth/code/oe/ctng/build/sysroots/qemuarm/home/kergoth/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/lib/libstdc++.la: No such file or directory
Jun 27 16:57:30 <kergoth> | arm-poky-linux-gnueabi-libtool: link: `/home/kergoth/code/oe/ctng/build/sysroots/qemuarm/home/kergoth/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/lib/libstdc++.la' is not a valid libtool archive
Jun 27 16:57:33 <kergoth> hmm this is an odd one
Jun 27 16:57:57 <chackal_sjc> what x terminal should I install in my image?
Jun 27 16:58:01 <chackal_sjc> there is no xterm recipe
Jun 27 16:58:35 <chackal_sjc> and matchbox-terminal is crashing and the rxvt is not showing any fonts =/
Jun 27 17:02:25 <bluelightning> chackal_sjc: matchbox-terminal works as part of the build appliance, I think something unusual might be going on there...
Jun 27 17:02:30 <bluelightning> it's pretty minimal though
Jun 27 17:02:48 <chackal_sjc> I just added matchbox-terminal
Jun 27 17:02:54 <chackal_sjc> and I get crash
Jun 27 17:02:56 <chackal_sjc> segfalut
Jun 27 17:04:58 <chackal_sjc> lemme show you
Jun 27 17:05:07 <chackal_sjc> i will add matchbox-terminal to my image, just that
Jun 27 17:05:14 <chackal_sjc> sorry
Jun 27 17:05:19 <chackal_sjc> with matchbox-wm
Jun 27 17:05:21 <chackal_sjc> just both
Jun 27 17:06:18 <seebs> kergoth: the libstdc++.la thing sounds vaguely familiar, I think I had one of those that involved a file getting truncated somehow.
Jun 27 17:07:20 <kergoth> looks like at least the ct-ng toolchain includes .la files, i'm just going to try rm -f'ing them all and see if that does it
Jun 27 17:07:21 <kergoth> heh
Jun 27 17:17:30 <chackal_sjc> When I start matchbox-terminal I get
Jun 27 17:17:35 <chackal_sjc> Segmentation fault at address 0x18
Jun 27 17:18:25 <chackal_sjc> are you guys sure that the git version is not buggy?
Jun 27 17:23:38 <chackal_sjc> SRCREV = "${AUTOREV}"
Jun 27 17:23:53 <chackal_sjc> this suppose to get the latest commit from git, right?
Jun 27 17:24:25 <seebs> Oh, kergoth, update on that eglibc thing: It looks (still testing) like the issue is that the version of external-csl-toolchain we have doesn't PROVIDES a target localedef, so bitbake picks up eglibc-locale which picks up eglibc.  I think.
Jun 27 17:24:44 <seebs> I'm setting up a better test case to find out.
Jun 27 17:27:07 <kergoth> eglibc-locale shouldn't pull in eglibc, afaik..
Jun 27 17:27:13 <seebs> Hmm.
Jun 27 17:27:14 <kergoth> hmm
Jun 27 17:27:22 <seebs> Heh.  I tried to bitbake -g.
Jun 27 17:27:47 <seebs> I got "ERROR: Multiple .bb files are due to be built which each provide virtual/libc (...). This usually means one provides something the other doesn't and should.
Jun 27 17:28:02 <kergoth> heh, not good
Jun 27 17:28:26 <seebs> Okay, so, bitbake newbie question: How would I extract "the list of things that recipe X provides"?
Jun 27 17:28:42 <seebs> Or otherwise get bitbake to tell me what it thinks it's doing?
Jun 27 17:28:51 <kergoth> depends on what you mean by provides :)
Jun 27 17:28:53 <seebs> I guess I could just remove the eglibc .bb files and see what it says is missing.  :P
Jun 27 17:28:55 <kergoth> theres' both build time and run time to worry about
Jun 27 17:29:04 <seebs> What I mean by provides is "whatever caused that error message".
Jun 27 17:29:06 <kergoth> -g is really the best bet with or without -u depexp
Jun 27 17:29:23 <kergoth> we need better inspection tools
Jun 27 17:29:24 <seebs> -g is what gave me the diagnostic.
Jun 27 17:29:31 <kergoth> e.g. whatprovides, whatrprovides, whatdepends, blah
Jun 27 17:29:53 <seebs> hmm
Jun 27 17:30:14 <seebs> I do not entirely understand these *.dot files, but they seem informative.
Jun 27 17:30:36 <seebs> It seems to me that if I were to find all the things that claim to be coming from eglibc_2.15.bb, I would know what my toolchain doesn't seem to be providing.
Jun 27 17:30:51 <kergoth> again, depends on whether it's coming via dependency or runtime
Jun 27 17:30:57 <kergoth> check PACKAGES vs RDEPENDS and PROVIDES vs DEPENDS
Jun 27 17:31:48 <seebs> I am under the impression (possibly mistaken) that PACKAGES and PROVIDES are both things that can be generated by code while bitbake is running; how do I see their actual values as computed?
Jun 27 17:32:12 <seebs> Oh, this is interesting.
Jun 27 17:32:33 <seebs> I have some things that appear to think they depend explicitly on eglibc-dev, which apparently is not provided by the toolchain.
Jun 27 17:32:58 <seebs> Ugh. I would probably have a much easier time if I were using the current external toolchain stuff instead of the stuff from a while back.
Jun 27 17:33:10 <fray> the SDK requires 'eglibc'  (as do some of the other components in the system)
Jun 27 17:33:16 <kergoth> bitbake -e is your friend
Jun 27 17:33:29 <fray> so the rdepends either fails or triggers the actual glibc package to build
Jun 27 17:33:38 <kergoth> shouldn't those want ${TCLIBC} instead?
Jun 27 17:33:50 <fray> they are using tclibc AFAIK, which is eglibc AFAIK
Jun 27 17:33:54 <kergoth> ah, right
Jun 27 17:34:06 <fray> meta-environment maybe?
Jun 27 17:34:10 * fray tries to remember what it is
Jun 27 17:34:31 * kergoth decides to sit down and try building task-self-hosted with an external toolchain and see what all gets sucked in
Jun 27 17:35:23 <fray> ya, it's a lot of unexpected stuff.. I found this problem by enabling the blacklist class and then blacklisting the eglibc package..
Jun 27 17:35:34 <fray> suddenly the system gets a whole lot more helpful in explaing you can't build..
Jun 27 17:36:23 <seebs> You know.
Jun 27 17:36:29 <kergoth> good idea wrt blacklist
Jun 27 17:36:48 <seebs> A lot of the things it's grabbing from eglibc are also in the external-csl-toolchain package; I wonder if I can improve things by using more preferred_provider magic.
Jun 27 17:38:10 <fray> my local.conf:
Jun 27 17:38:14 <fray> INHERIT += "blacklist"
Jun 27 17:38:18 <fray> PNBLACKLIST[eglibc] = "Only use WR Toolchain!"
Jun 27 17:38:46 <fray> besides that, when you add the SDK to the mix.. it then falls back and starts building all of the crosssdk and nativesdk toolchain elements.. which is also likely not desired..
Jun 27 17:39:13 <fray> (turning off the nativesdk toolchain takes a whole lot of confirugration)
Jun 27 17:44:01 <fray> BTW one possible way to work with this is to add an rprovides to the toolchain packages of their corresponding "real" package.. but I'd rather them be named the same
Jun 27 17:45:19 <kergoth> right now the external toolchain leverages the eglibc packaging bits, which all use ${PN}, so the PN-based packages are named based on pn still, rather than emitting explicit 'eglibc', etc.
Jun 27 17:45:58 <fray> yup..
Jun 27 17:46:08 <fray> (and that is as far as I got before having to go this morning)
Jun 27 17:51:25 <kergoth> aside: <3 knotty2
Jun 27 18:20:43 <mranostay> kergoth: ping
Jun 27 18:27:31 <mranostay> nm i think
Jun 27 18:46:11 <fray> BTW.. "task-core-standalone-sdk-target" is one of the placed I'm getting this..
Jun 27 18:53:09 <khem> fray: sdk's use of eglibc-nativesdk can be provided by internal eglibc and it has to be unless you have native toolchain bits externally to hook in which is too excessive
Jun 27 18:53:32 <fray> I've disabled all of that crap.. this is the sdk-target, so target packages..
Jun 27 18:53:34 <khem> fray: for uclibc sdk e.g. the cross bits are uclibc but native bits are eglibc
Jun 27 18:53:39 <fray> it's the ${TCLIBC} dependency that is the issue
Jun 27 18:54:12 <khem> I really dont see your sdk to be functional without it
Jun 27 18:54:23 <khem> or if you are just using target part of sdk
Jun 27 18:54:33 <fray> the binary toolchain includes the libc..
Jun 27 18:54:37 <khem> then modify the class so that those two are different
Jun 27 18:54:52 <khem> yes that libc is for target applications
Jun 27 18:54:52 <fray> the problem is that it's not providing the eglibc functionality (by name) that the task requires
Jun 27 18:55:02 <khem> or do you include libc for sdkhost as well?
Jun 27 18:55:25 <fray> the sdkhost bits, I have all of that crap disabled..
Jun 27 18:55:28 <khem> hmmm, I thought you were tryng to shunt eglibc-nativesdk
Jun 27 18:55:39 <khem> hmm interesting
Jun 27 18:55:40 <fray> I'd paste it but it's about 20 lines of assume provided and blacklisting
Jun 27 18:56:06 <fray> (and some other config stuff).. the problem is completely within the external toolchain recipe and the -target- task requring eglibc
Jun 27 18:56:11 <fray> (and eglibc-dev)
Jun 27 18:57:36 <khem> ah target task should ask for virtual/libc
Jun 27 18:57:39 <khem> not eglibc directly
Jun 27 18:58:03 <fray> it needs the -dev stuff.. and AFAIK there is no virtual provides for that either
Jun 27 18:59:10 <khem> hmm
Jun 27 18:59:23 <khem> yes there is not
Jun 27 19:00:09 <khem> actually making external toolchain provide exactly same packages that eglibc provided internally would be the right thing here
Jun 27 19:00:20 <khem> I think there is some missing
Jun 27 19:00:23 <khem> and thats why
Jun 27 19:00:34 <fray> khem yes, exactly what we need..
Jun 27 19:00:54 <fray> the issues is to use the glibc locale processing code, the eglibc package is partially included and it assumes the ${PN} is "eglibc"
Jun 27 19:02:03 <khem> yeah case with eglibc is a bit complex
Jun 27 19:02:15 <khem> provided we do all dynamic package name generation etc.
Jun 27 19:02:15 <fray> I have a feeling the right answer is to set the PN value
Jun 27 19:03:20 <khem> hmmm PN in external toolchain recipe you mean ?
Jun 27 19:03:28 <fray> yup.. set the PN to eglib
Jun 27 19:03:31 <fray> 'er.. eglibc
Jun 27 19:03:46 <khem> I dont think thats the right thing
Jun 27 19:04:11 <khem> hmmm you could use TCLIBC var in locale processing
Jun 27 19:04:13 <fray> the issues is all with the way the eglibc locale and file processing is there..
Jun 27 19:05:12 <fray> packages-split form the external toolchain":
Jun 27 19:05:19 <fray> catchsegv                            external-csl-toolchain-locale-it            gdbserver
Jun 27 19:05:19 <fray> eglibc-extra-nss                     external-csl-toolchain-locale-ja            gdbserver-dbg
Jun 27 19:05:19 <fray> eglibc-extra-nss.shlibdeps           external-csl-toolchain-locale-ko            gdbserver.shlibdeps
Jun 27 19:05:19 <fray> eglibc-thread-db                     external-csl-toolchain-locale-locale.alias  ldd
Jun 27 19:05:19 <fray> eglibc-thread-db.shlibdeps           external-csl-toolchain-locale-lt            libcidn
Jun 27 19:05:19 <fray> external-csl-toolchain               external-csl-toolchain-locale-nb            libcidn.shlibdeps
Jun 27 19:05:20 <fray> external-csl-toolchain-dbg           external-csl-toolchain-locale-nl            libgcc
Jun 27 19:05:20 <fray> external-csl-toolchain-dev           external-csl-toolchain-locale-pl            libgcc-dev
Jun 27 19:05:21 <fray> external-csl-toolchain-doc           external-csl-toolchain-locale-pt-br         libgcc.shlibdeps
Jun 27 19:05:22 <fray> (and more)
Jun 27 19:05:36 <khem> yes thats wrong
Jun 27 19:05:41 <fray> all of the things that say "external-csl-toolchain" are matching the eglibc stuff.. so they should say eglibc-.....
Jun 27 19:05:46 <khem> the localegen code should have used TCLIBC
Jun 27 19:05:50 <khem> that would fit the bill
Jun 27 19:05:58 <fray> it's more then just the locales.. it's also the base files and such
Jun 27 19:06:44 <khem> may be then we could pass in PN as parameter to the locale munging code
Jun 27 19:06:57 <khem> instead of getting it from datastore
Jun 27 19:07:03 <fray> doesn't solve the main ${PN} processing though, but would fix the locale..
Jun 27 19:08:13 <khem> isnt that covered with PREFERRED_PROVIDER
Jun 27 19:08:39 <fray> preferred_provider sets the dependency resolution when there is a conflict.. but doesn't set the RDEPENDS/RPROVIDES
Jun 27 19:08:53 <khem> ideally it would be nice if there was a directive to denote conflicting recipes
Jun 27 19:09:01 <khem> syntactically
Jun 27 19:09:17 <khem> and ignore the ones you wanted
Jun 27 19:09:35 <khem> then the errors would be more straight forward
Jun 27 19:09:40 <khem> need to eat soemthing
Jun 27 19:09:42 <khem> bbl
Jun 27 19:58:34 <seebs> Huh. Well, one thing I have noticed is, my attempt to blacklist eglibc apparently failed.
Jun 27 19:58:39 <seebs> Because it got built anyway without complaint.
Jun 27 20:08:52 <seebs> fray, you're right about the $PN thing, and it just bit someone else, because there's no eglibc-debuginfo, just external-csl-toolchain-debuginfo, in what I'm producing.  Working on testing/fixing.
Jun 27 20:09:36 <seebs> My trivial fix is s/${PN}/${TCLIBC}/g in eglibc-package.inc.  If that works I can send it to the oe-core list too because I think it stays applicable with the new external toolchain stuff too.
Jun 27 20:14:15 <dvhart> halstead, I'm trying to do the same thing you do on the autobuilder (for ab01, etc) to access a machine behind my desktop fear
Jun 27 20:16:04 <halstead> NP dvhart.
Jun 27 20:31:45 <dvhart> halstead++
Jun 27 20:32:55 <halstead> Whee!
Jun 27 20:39:38 <RP__> seebs: can you please use an intermediate variable for that?
Jun 27 20:39:59 * RP__ doesn't fancy hardcoded TCLIBC everywhere
Jun 27 20:40:49 <seebs> Hmm. That is not a bad point. Come to think of it, perhaps eglibc-package should just do the same thing as eglibc-locale, and use $BPN which is set to eglibc. Since that's what it is.
Jun 27 20:51:37 <kergoth> hmm, PATH references STAGING_BINDIR_TOOLCHAIN which references TUNE_PKGARCH, so TUNE_PKGARCH is getting sucked into -native builds, afaict
Jun 27 20:52:00 <kergoth> was wondering why -native reuse wasn't happening across MACHINE change
Jun 27 20:52:00 <kergoth> heh
Jun 27 20:57:07 <RP__> kergoth: I thought we excluded PATH?
Jun 27 20:57:28 * RP__ is going slightly crazy staring at the recrdepends code :/
Jun 27 20:58:23 <kergoth> hmm, good point. /me digs further
Jun 27 21:42:27 <vmeson> how would people feel about adding a service script to initscripts? has that been proposed before?
Jun 27 21:43:08 <vmeson> I see no mention of it in the email logs for poky/yocto/oe-core.
Jun 27 21:44:17 <kergoth> "service script"?
Jun 27 21:45:07 <vmeson> /usr/sbin/service - I just noticed that it's in a package called sysvinit-utils in Ubuntu.
Jun 27 21:45:31 <vmeson>        service - run a System V init script
Jun 27 21:45:31 <vmeson> SYNOPSIS
Jun 27 21:45:31 <vmeson>        service SCRIPT COMMAND [OPTIONS]
Jun 27 21:45:47 <vmeson>  service runs a System V init script or upstart job in as predictable environment as possible, removing most environment variables and with current working directory set to /.
Jun 27 21:48:50 <seebs> Okay, I am having another newbie moment.
Jun 27 21:48:59 <seebs> I added INHERT += "blacklist" to local.conf. I did some tests.
Jun 27 21:49:04 <seebs> I have now removed it, but it's still running.
Jun 27 21:49:08 <seebs> Er, "INHERIT".
Jun 27 21:49:36 <seebs> Although it does seem the changes to the actual blacklist entries are effective. Maybe something else is inheriting blacklist and I just didn't realize it.
Jun 27 21:52:25 <vmeson> kergoth: I see now that ubu/debian just patches the samesysvinit-2.88dsf.tar.bz2 that is in oe-core , so I'll look at that.
Jun 27 21:53:00 * vmeson knew he should have done more digging before asking. :)
Jun 27 22:28:54 <kergoth> gah, i did a bitbake autoconf-native for two machines with an empty sstate-cache,and inspect the sstate-cache, there's *4* populate_sysroot tarballs for m4-native
Jun 27 22:29:02 * kergoth scratches head
Jun 27 22:29:48 * kergoth sighs
Jun 27 22:34:15 <kergoth> aha, go tit
Jun 27 22:37:45 <seebs> I am currently leaning towards a theory that the right solution for eglibc-package.inc is to just set PN=eglibc before including it.
Jun 27 22:38:09 <seebs> I will see whether this appears to actually work.
Jun 27 22:38:31 <hollisb> do I still need hacks to meta-texasinstruments for Pandaboard BSP, or have the Angstrom-specific dependencies been sorted out by now?
Jun 27 22:38:46 <kergoth> you can't set the external toolchain's pn permanently to eglibc, it'll break the ability to use preferred provider to select it. at best you'd have to set it, include, and set it back, and even then that'd only work if the .inc used := everywhere
Jun 27 22:39:19 <kergoth> hollisb: pretty sure you can build for it fine with just meta-ti, but haven't tested it recently personally
Jun 27 22:39:33 <hollisb> I'll give it a shot; thanks
Jun 27 22:42:49 <seebs> Oh, eww.
Jun 27 22:42:52 <seebs> You're right.  Ugh.
Jun 27 22:43:13 <seebs> So I guess I should do something in eglibc-package.inc that forces the generation of suitable package names.
Jun 27 22:43:49 <kergoth> that'd be ideal. at this point i'd punt and just add RPROVIDES for each ${PN} based package, just to get past the issues, and do the proper fix later, but that's me :)
Jun 27 22:44:12 <seebs> Hmm.  Problem is that sometimes when you include, you want to get the same logic with a different ${PN}, and sometimes you really mean "yes, I have a copy of eglibc, please package it for me".
Jun 27 22:44:22 <seebs> Hmm.
Jun 27 22:44:42 <seebs> So that'd be what, something like RPROVIDES_external-csl-toolchain-foo = "eglibc-foo" ?
Jun 27 22:44:55 <kergoth> s/external-csl-toolchain/${PN}/, but yeah, basically
Jun 27 22:45:12 <kergoth> there aren't *that* many pn based packages, really, so it's not as ugly as it seems
Jun 27 22:45:14 * kergoth shrugs
Jun 27 22:45:24 <seebs> Hmm. That makes sense.
Jun 27 22:46:29 <seebs> Hmm.
Jun 27 22:46:45 <seebs> Hang on. I see a bunch of lines with names like PKG_${PN}-doc = "eglibc-doc".
Jun 27 22:46:53 <seebs> Are those related to this?
Jun 27 22:47:48 <kergoth> oh, right, i forgot about those
Jun 27 22:47:53 <kergoth> that changes the package names directly
Jun 27 22:47:59 <kergoth> so it emits literally a 'eglibc-doc' package
Jun 27 22:48:10 <seebs> Huh.
Jun 27 22:48:10 <kergoth> i forgot i used that method to avoid this
Jun 27 22:48:19 <kergoth> so it should be a nonissue for everything but the locale packages, i'd think
Jun 27 22:48:23 <seebs> That leads me to wonder why that seemed to be Not Working.  I must investigate more.
Jun 27 22:48:27 * kergoth nods
Jun 27 22:48:52 <seebs> Because what started me on this was noticing tons of packages with names like external-csl-toolchain-dbg that appear to be misnamed eglibc-dbg.
Jun 27 22:56:56 <hollisb> kergoth: FYI: ERROR: ParseError at /mnt/poky.git/meta-ti/recipes-misc/payload/bonescript.bb:5: Could not inherit file classes/systemd.bbclass
Jun 27 22:57:11 <kergoth> ah, yes, forgot oyu need to bbmask that out
Jun 27 22:57:16 <kergoth> BBMASK = '/meta-ti/recipes-misc/'
Jun 27 22:57:24 <kergoth> afaik that's all that should be needed
Jun 27 22:58:32 <hollisb> kergoth: do I need a leading .*, as in BBMASK = ".*/meta-ti/recipes-misc/" ?
Jun 27 22:58:45 <kergoth> nope, it uses re.search(), not re.match()
Jun 27 22:58:48 <kergoth> afaik anyway
Jun 27 22:58:59 <hollisb> k
Jun 27 22:59:01 <kergoth> you'll find out quick enough if that's actually the case :)
Jun 27 22:59:06 <hollisb> uh huh :)
Jun 27 22:59:45 <chackal_sjc> guys I'm getting a GNU_HASH problem
Jun 27 22:59:57 <chackal_sjc> but I already added: INSANE_SKIP_${PN} += "ldflags"
Jun 27 23:00:15 <chackal_sjc> does anyone updated any code in the master repo?
Jun 27 23:00:24 <kergoth> are you sure it's the ${PN} package that's the issue? :) recipes emit more than one package, after all
Jun 27 23:01:09 <chackal_sjc> kergoth:  NOTE: package xf86-video-mali-1.0-0: task do_package: Failed
Jun 27 23:01:19 <chackal_sjc> it was working before
Jun 27 23:01:20 <kergoth> that doesn't tell me anything
Jun 27 23:01:34 <chackal_sjc> my PN is xf86-video-mali
Jun 27 23:02:27 <kergoth> still doesn't answer my question from before. there's one do_package run to emit many binary packages
Jun 27 23:02:38 <kergoth> just because do_package is failing doens't mean it's the PN package that's failing
Jun 27 23:02:43 <kergoth> the GNU_HASH lines would show that
Jun 27 23:05:33 <chackal_sjc> ok
Jun 27 23:05:36 <chackal_sjc> so how do i do?
Jun 27 23:05:40 <chackal_sjc> because it was working before
Jun 27 23:06:41 <darknighte> anyone seen michael halstead around today?
Jun 27 23:07:22 <darknighte> halstead: there's your nick.  you around?
Jun 27 23:10:30 <mranostay> heh
Jun 27 23:19:43 <chackal_sjc> kergoth: how to find out the package name?
Jun 27 23:20:00 <chackal_sjc> INSANE_SKIP_${PN} += "ldflags" should work, it was working before
Jun 27 23:20:02 <kergoth> read the GNU_HASH error messages
Jun 27 23:20:08 <kergoth> yes, you've said that like 4 times now
Jun 27 23:20:12 <kergoth> we heard oyu the first 3 times
Jun 27 23:22:08 <chackal_sjc> kergoth: good for you
Jun 27 23:22:58 <kergoth> you have two options, read the git logs to find the cause, or ignore the fact that it used to work, which is irrelevant in that context, and actually investigate the problem properly
Jun 27 23:23:16 <kergoth> in the first case, repeating it here is gaining you nothing, and in the latter case you're providing insufficient information to diagnose
Jun 27 23:23:33 <chackal_sjc> I saw the name
Jun 27 23:24:12 <chackal_sjc> how I suppose to know that somehow it started building a dev package
Jun 27 23:24:58 <kergoth> for the 3rd or 4th time, the GNU_HASH message tells you. the full path to the filename is under package-split/, which is broken up by binary package
Jun 27 23:25:45 <seebs> Huh, confirmed, I'm generating external-csl-toolchain-utils instead of eglibc-utils, not sure why.
Jun 27 23:25:47 <chackal_sjc> kergoth: I'm saying that the build just changed, since I pulled from the upstream
Jun 27 23:25:55 <seebs> I am going to think about this later because it is time for exercise.
Jun 27 23:26:08 <kergoth> chackal_sjc: yes, again, i heard you say that over and over already. I don't care.
Jun 27 23:26:22 <kergoth> do you really think repeating it a 5th time is going to magically change something?
Jun 27 23:26:27 <halstead> darknighte, how can I help?
Jun 27 23:26:32 <kergoth> read the git logs to check for changes to that code, or investigate the problem directly
Jun 27 23:26:58 <chackal_sjc> ok thank you for your help
Jun 27 23:27:42 <khem> with external toolchain if you know that SDK was not built with gnu hash just disable ldflags checks globally
Jun 27 23:27:47 <khem> it makes no sense
Jun 27 23:27:59 <darknighte> halstead: heads up, you will get a request from Ricardo re: eglibc mx records
Jun 27 23:28:16 <khem> darknighte: what is this problem ?
Jun 27 23:28:38 * reanguiano waves to darknighte and halstead 
Jun 27 23:28:45 <kergoth> khem: man, we really need _remove or whatever, an easier way to remove words from list variables without := and oe_filter_out or redefining the whole variable
Jun 27 23:28:49 <kergoth> heh
Jun 27 23:29:10 <halstead> darknighte & reanguiano , Okay. I'll watch for it. I'm traveling tomorrow so response time may be slow.
Jun 27 23:29:15 <khem> kergoth: thats a pandora box full of bugs
Jun 27 23:29:28 <khem> kergoth: delete operation is complex
Jun 27 23:29:32 <kergoth> khem: i know
Jun 27 23:29:39 <kergoth> but every other method is full of issues too :)
Jun 27 23:29:46 <khem> hmmm
Jun 27 23:29:57 <kergoth> oh well, soemday
Jun 27 23:30:09 <khem> I think we can add it as a last pass on variable processing
Jun 27 23:30:28 <khem> which means if you got a remove operation that will override no matter what
Jun 27 23:31:03 <khem> one thing I think will help here is if we can dump the variable journey in metadata
Jun 27 23:31:26 <kergoth> yeah, that's what seebs was mulling over. *must* be at the end of the parse. immediate is full of pain
Jun 27 23:31:35 <khem> so one can tell variable X was modified at location Y and then at Z and so on
Jun 27 23:31:49 <kergoth> khem: seebs implemented that, the patches are on the bitbake list
Jun 27 23:32:13 <khem> I think if we have such a thing then debugging delete operations will become lot easier
Jun 27 23:32:23 <kergoth> see "[PATCH 0/2] File inclusion and variable assignment tracking"
Jun 27 23:32:28 <kergoth> very handy
Jun 27 23:32:38 <kergoth> for those times when you have no clue where a value is coming from
Jun 27 23:32:39 <kergoth> heh
Jun 27 23:32:45 <khem> hmm, nice, I should read bitbake ml more carefully
Jun 27 23:32:52 <khem> there is too much to read in life
Jun 27 23:33:21 <kergoth> indeed
Jun 27 23:33:40 * kergoth is still trying to catch up after his trip
Jun 27 23:33:44 <khem> kergoth: another thing we can do in external-toolchain class is enquire the external SDK compiler for GNU_HASH and change something globally
Jun 27 23:34:01 <khem> kergoth: you went to Hawaii right ? which island
Jun 27 23:34:03 <kergoth> hmm, not a bad idea
Jun 27 23:34:28 <kergoth> went to oahu for 9 days and flew all our immediate family out, got married there, then went to maui for 5 days for the honeymoon
Jun 27 23:34:36 <khem> I have been to Maui and Honolulu
Jun 27 23:34:46 <khem> kergoth: eCongratulations !!
Jun 27 23:34:51 <kergoth> maui is so nice and laid back compared to honolulu. honolulu is like vegas, crazy
Jun 27 23:34:53 <kergoth> hehe
Jun 27 23:34:54 <kergoth> thanks
Jun 27 23:34:59 <khem> kergoth: welcome to club
Jun 27 23:35:36 <khem> yeah Honolulu is very busy
Jun 27 23:35:44 <kergoth> fun though
Jun 27 23:35:47 <kergoth> lots to do
Jun 27 23:35:51 <khem> correct
Jun 27 23:36:14 <khem> I loved it. Best trips I ever had was to islands
Jun 27 23:37:30 <khem> woglinde spoiled my soccer DVR today by telling me the results :(
Jun 27 23:37:40 <khem> Euro Semifinals
Jun 27 23:38:04 <kergoth> doh
Jun 27 23:38:05 <khem> I was trying hard to be cut off from media to know the results
Jun 27 23:38:22 <mranostay> khem: well you forgot irc
Jun 27 23:38:40 <khem> yeah and he mentioned my name there so it showed up in READ
Jun 27 23:39:14 <khem> tomorrow I will work from home and told boss that I will watch the second game live no bull crap :)
Jun 27 23:40:41 <khem> kergoth: I think I should trick my boss to let me work remotely from hawaii ;)
Jun 27 23:40:49 <kergoth> hehe, if only
Jun 27 23:41:04 <kergoth> i already checked craigslist to see what rentals cost on maui :)
Jun 27 23:41:40 <khem> nice.
Jun 27 23:41:42 <mranostay> khem: go Germany right? :)
Jun 27 23:42:04 <khem> mranostay: only if German Govt. will give my pension money back
Jun 27 23:42:31 <mranostay> yeah it doesn't work that way :)
Jun 27 23:43:13 <khem> mranostay: they instead told me to come back and start working there and they will start putting money on top
Jun 27 23:43:23 <khem> but they wont let me withdraw it
Jun 27 23:43:32 <mranostay> until what age?
Jun 27 23:43:57 <khem> until I retire which is decades away
Jun 27 23:44:16 <mranostay> or -ENEVER :)
Jun 27 23:44:37 <khem> yeah may be when I reach 65 the retirement agae will be like 90
Jun 27 23:44:42 <khem> then I am screwed
Jun 27 23:44:59 <khem> heh all of us will be
Jun 27 23:45:07 * khem derives sadistic pleasure
Jun 27 23:46:14 <khem> ideally in a successfully society you retire 1 day before you drop dead :)
Jun 27 23:46:31 <mranostay> ok catbert :)
Jun 27 23:47:00 <khem> heh
Jun 27 23:47:16 <khem> oh well I must motivate myself to get into 101 traffic somehow
Jun 27 23:48:28 <mranostay> at this hour? are you insane?
Jun 27 23:48:49 <hollisb> fray: around?
Jun 27 23:49:14 <khem> or may be work towards getting private chopper
Jun 28 00:00:47 <khem> kergoth: I am trying to make a clone of repo onto a local server
Jun 28 00:01:02 <khem> kergoth: I want to push the whole metadata first time from upstream repo
Jun 28 00:01:32 <khem> whakergoth whats the best way to fgo about it
Jun 28 00:07:39 <khem> I guess on my git server at git user I can do git clone --bare for once
Jun 28 00:28:11 <kergoth> git clone --mirror foo://bar; cd bar.git; git push --mirror bar://baz
Jun 28 00:34:56 <khem> kergoth: ok
Jun 28 00:35:11 <khem> I wonder bitbake -cfetchall world will get me sources of everything downloaded
Jun 28 00:35:27 <kergoth> probably need -k also
Jun 28 00:35:44 <khem> good idea
Jun 28 00:35:48 <kergoth> and that'll only get the current versions of things and the preferred instance of multiple providers, i think there's universe or somesuch that's even more inclusive than world
Jun 28 00:36:09 <kergoth> hmm
Jun 28 00:36:46 <khem> I think world is fine for now.
Jun 28 00:37:04 <khem> since I dont want sysadmin to puke on amount of crap
Jun 28 00:38:32 * kergoth nods
Jun 28 00:39:48 <pidge> khem: universe isn't overly large iirc. du'ing now. It will become large if you maintain it over a period
Jun 28 00:46:01 <khem> pidge: hmmm ok.
Jun 28 00:46:13 <khem> pidge I want the versions I am gonna use for now
Jun 28 00:46:24 <khem> and then slowly get in versions that I need
Jun 28 00:46:42 <khem> instead of getting everything and then spending weeks with legal to audit them
Jun 28 00:49:49 <pidge> khem: is this for floss compliance?
Jun 28 00:49:55 <seebs> Okay, now to try again to understand why PKG_csl-external-toolchain-utils = "eglibc-utils" does not seem to work.
Jun 28 00:52:59 <seebs> Okay, step one. I have confirmed that the value really is set as expected.
Jun 28 01:02:02 <khem> pidge: for now no but eventually it will
Jun 28 01:02:27 <khem> pidge: I will know soon but do you know what is space requirement to store downloads/ for universe or world
Jun 28 01:04:28 <pidge> khem: So, for the universe that I've been maintaining for the past year and half is 22G. Do realize that's with a lot of different versions. My guess is (and this is with no hard data) is that a world is around 4GB and a universe only slightly larger.
Jun 28 01:04:57 <pidge> khem: and of course, there is the archiver class, which would probably be what you want to use other than do_fetch
Jun 28 01:09:21 <seebs> ohhh
Jun 28 01:09:44 <seebs> I think I figured it out maybe. I am starting to suspect that in fact, the names in packages-split aren't the final names after the PKG_foo translations.
Jun 28 01:10:09 <kergoth> heh, checked deploy/ipk?
Jun 28 01:10:36 <darknighte> khem: no problem per se, just moving stuff around
Jun 28 01:11:39 <seebs> Looking around now trying to figure out where things would go. Thing is, I had been looking in the work directory because I thought the other eglibc package might be getting sucked in, in which case it might be providing these.
Jun 28 01:12:54 <kergoth> inspect the control metadata of the ipk, you'll be able to see what recipe it came from
Jun 28 01:13:17 <kergoth> opkginfo () { ar p $1 control.tar.gz | tar -zxO ./control }
Jun 28 01:13:33 <kergoth> for completeness: opkgfiles () { ar p $1 data.tar.gz | tar -tv }
Jun 28 01:14:00 <seebs> Oh, neat.
Jun 28 01:14:58 <seebs> Although I think we're using rpm, but same principle, I assume.
Jun 28 01:15:15 <kergoth> rpm -qf or somesuch i guess :)
Jun 28 01:16:41 <seebs> Yup, and that confirms that eglibc-utils.mumble came from external-csl-toolchain-2.15-r6.src.rpm. Which is a total lie, but an informative one.
Jun 28 01:26:06 <kergoth> indeed
Jun 28 01:29:12 <seebs> So it looks like in fact, the problems I've had are really:
Jun 28 01:29:19 <seebs> 1.  external-csl-toolchain wasn't packaging localedef.
Jun 28 01:29:36 <seebs> This caused the build system to go crazy and ultimately build all of eglibc in order to get a copy of localedef.
Jun 28 01:30:17 <kergoth> should look closer at that, that shouldn't be happening
Jun 28 01:30:30 <seebs> 2.  The generated locale files are all "external-csl-toolchain-locale-*.rpm", but since all they have is libc.mo, that's probably not helpful.
Jun 28 01:30:57 <kergoth> don't think that should be an issue, pretty sure those all provide locale-base-whatever
Jun 28 01:31:02 <kergoth> and things should dep on that
Jun 28 01:31:12 <kergoth> not sure, but think thats the case
Jun 28 01:32:28 <seebs> Doesn't look like it. Hmm. I thought something else had made me a bunch of locale-base.
Jun 28 01:32:45 <kergoth> hmm, maybe i'm remembering wrong then, all that locale stuff is rather twisty :)
Jun 28 01:32:48 <seebs> Nope.  Hmm.  Okay, I should fix those.
Jun 28 01:33:04 <seebs> I sort of want a PKG_ with wildcards.
Jun 28 01:33:27 <seebs> Well, I think I can fix this. The localedef thing is complicated a bit by the interaction with how eglibc-locale does it, but I think I have a working patch.
Jun 28 01:33:51 <kergoth> afaik eglibc-locale should provide localedef, and eglibc-locale shouldn't pull in eglibc, so something still seems a bit odd in how it's being pulled in
Jun 28 01:33:58 <kergoth> but i haven't reproduced, going by the descriptions in here
Jun 28 01:33:59 <kergoth> heh
Jun 28 01:34:32 <seebs> Well, I'll see if I can figure it out. Every time through this I pick up a little more of how I am supposed to figure out what's going on.
Jun 28 01:35:03 <kergoth> would be nice if things weren't quite so complex
Jun 28 01:35:03 <kergoth> heh
Jun 28 01:38:14 <seebs> It appears that just adding localedef to the toolchain is doing what I want. I'll remove it again and see whether the mysterious failure returns. And if it does, I may even finally know enough to figure it out.
Jun 28 01:39:11 <kergoth> hehe
Jun 28 01:39:29 <kergoth> if i remember to, i'll try adding localedef to an image and see if i get eglibc sucked in too
Jun 28 01:44:34 <seebs> It's mostly-easy to just add it to the toolchain, tricky bit is undoing the "stash these things elsewhere for eglibc-locale" part.
Jun 28 01:44:55 <kergoth> just added localedef, -g doesn't show eglibc coming in at all
Jun 28 01:45:03 <kergoth> just builds eglibc-locale and emits a localedef package
Jun 28 01:45:05 * kergoth shrugs
Jun 28 01:45:16 <seebs> huh.
Jun 28 01:45:25 <seebs> I wonder what was picking up eglibc then. Well, I can study it more.
Jun 28 01:45:41 <seebs> All my tests were based on misunderstanding $PN, so the crazy stuff where ldd wasn't being found was irrelevant.
Jun 28 01:52:00 <kergoth> jesus, eglibc-locale's do_package takes a long time for all locales, no wonder it was split out :)
Jun 28 01:52:06 * kergoth forgot just how slow that is
**** ENDING LOGGING AT Thu Jun 28 02:59:58 2012

**** BEGIN LOGGING AT Thu Jun 28 02:59:59 2012
Jun 28 03:37:04 <seebs> Robert Yang just did something amazing. He sent me a reproducer for a pseudo bug that wasn't user error.
Jun 28 03:37:22 <seebs> So there will likely be a patch coming out "soon" to fix coredumps in directories with long names.
Jun 28 03:37:48 <seebs> (The basic problem is a directory name over 256 characters being used as a chroot directory followed by evaluation of an absolute file name.)
Jun 28 07:57:05 <Orre> Does anyone here know what kind of value would KBRANCH be set to for a qemu/ARM BSP?
Jun 28 08:05:04 <RP__> Orre: recipes-kernel/linux/linux-yocto_3.2.bb:KBRANCH_qemuarm  = "standard/default/arm-versatile-926ejs" ?
Jun 28 08:07:24 <Orre> ok, that is what I have. Then that's not the error.
Jun 28 08:08:42 <Orre> I got a meta SRCREV error when using for Linux 3.0 SRCREV_meta_pn-linux-yocto_myqemu ?= "34e0d2b4b4e9778b31f9ea99ca43f0dc71a7ee23"
Jun 28 08:09:23 <Orre> Didn't find so many similar errors as I had through Google but saw one and he was answered that his KBRANCH may be wrong.
Jun 28 08:10:13 <RP__> Orre: recipes-kernel/linux/linux-yocto_3.0.bb:KBRANCH_qemuarm  = "yocto/standard/arm-versatile-926ejs"
Jun 28 08:10:22 <RP__> Orre: layout is different on 3.0
Jun 28 08:12:42 <Orre> KBRANCH_myqemu  = "yocto/standard/arm-versatile-926ejs/myqemu"
Jun 28 08:15:12 <Orre> error: Your local changes to the following files would be overwritten by checkout:
Jun 28 08:15:38 <Orre> fatal: refs is not a directory
Jun 28 08:18:45 <RP__> Orre: You're pointing at a local repository with your changes in with SRC_URI, right?
Jun 28 08:21:01 <Orre> I haven't changed the SRC_URI, it's still "file://myqemu-standard.scc \ [...]", I guess when reading that line I guess it's proper to change it to a better address? Missed it as it isn't mentioned in any manual :>
Jun 28 08:23:02 <Orre> Is there any rules of what SRC_URI should point on or is it any location on the computer?
Jun 28 08:29:55 <Orre> Oh, and now when I have someone answering questions, do you happen to know why the location of the build directory is hardcoded in kernel.py?
Jun 28 08:30:15 <Orre> Making you enable to create new BSP if you use another build directory then /build/?
Jun 28 08:30:20 <Orre> unable*
Jun 28 08:33:46 <Orre> ERROR: Function failed: do_patch (see /home/user/yocto-project/poky-denzil-7.0/build/tmp/work/myqemu-poky-linux-gnueabi/linux-yocto-3.0.24+git1+34e0d2b4b4e9778b31f9ea99ca43f0dc71a7ee23_2+8fd5a8eb4067c7032389e82d54f0e54e1e27f78c-r4.1/temp/log.do_patch.27951 for further information) ERROR: Logfile of failure stored in: /home/user/yocto-project/poky-denzil-7.0/build/tmp/work/myqemu-poky-linux-gnueabi/linux-yocto-3.0.24+git1+34e0d2b4b4e9778b
Jun 28 08:34:37 <Orre> [...]
Jun 28 08:49:36 <RP__> Orre: You added "myqemu" to KBRANCH_myqemu which means you must have your own repostory layout?
Jun 28 08:49:59 <RP__> Orre: If you didn't do that you need to use a standard branch which is in the main tree
Jun 28 08:50:23 <RP__> Orre: Its assumed for a different BSP, you would use a different MACHINE value and hence it would get built in a different location
Jun 28 08:50:39 <Orre> It was the default settings made by Yocto when I used yocto-bsp create. I am running a build now without myqemu in the KBRANCH to test it as I saw it myself a few minutes ago
Jun 28 08:51:17 <RP__> Orre: The bsp tooling is assuming you created your own bsp branch in a repository
Jun 28 08:51:28 <RP__> which you're clearly not doing :)
Jun 28 08:51:52 <Orre> Yes,  this build succeeded so you are right. Will add that to my personal manual. :p
Jun 28 08:52:06 <Orre> Thanks!
Jun 28 08:57:53 <awafaa> anyone able to advise on how i would build and append adtb for a custom kernel?
Jun 28 08:58:05 <awafaa> as in what entries need to be added to which files etc
Jun 28 09:00:01 <awafaa> err s/adtb/a dtb
Jun 28 09:09:19 <RP__> awafaa: You can grep the existing code for dtb references and that should give some clues. I don't know the details offhand
Jun 28 09:16:37 <Orre> I'm not able to build the myqemu after the baking is complete? When I use "runqemu myqemu" it says "Error: unable to classify arg [myqemu]", is there something particular I need to add for it to recognize myqemu? (I've also attempted "runqemu myqemu tmp/deploy/images/zImage-myqemu.bin tmp/deploy/images/core-image-minimal-myqemu.ext3")?
Jun 28 09:17:17 <RP__> awafaa: Specifically, look at the KERNEL_DEVICETREE variable
Jun 28 09:17:40 <RP__> Orre: It has internal expressions that look for the name "qemuarm"
Jun 28 09:17:53 <RP__> Orre: How do you expect it to know that "myqemu" is arm for example?
Jun 28 09:18:05 <awafaa> RP__: thanks, i'll have another dig then
Jun 28 09:20:46 <Orre> They say you can do it that way here: https://wiki.yoctoproject.org/wiki/Transcript:_Using_the_Yocto_BSP_tools_to_create_a_qemu_BSP
Jun 28 09:21:05 <Orre> How do I build the baked images if I don't use runqemu then?
Jun 28 09:21:44 <Orre> nvm
Jun 28 09:21:47 <Orre> I'm stupid.
Jun 28 09:24:43 <bluelightning> morning all
Jun 28 09:28:27 <Orre> hello
Jun 28 09:47:39 <Orre> I got nVidia running which causes qemu to segmentation fault at runqemu. If I run qemux86 I usually use LD_PRELOAD=/usr/lib/ligGL.so which doesn't work for a qemuarm, what should I use instead? Any tips?
Jun 28 11:09:53 <Orre> nvm
Jun 28 11:09:58 <Orre> don't answer my last question.
Jun 28 15:03:34 <awafaa> anyone know what could be causing http://paste.opensuse.org/33494755?
Jun 28 15:58:29 <kergoth> RP__: thoughts on adding convenience methods for datasmart like 'add_task'? these could do the real footwork, and thereby simplify the ast eval's, and would be a step toward making it easier to do anything programmatically which we can do from lines in parsed files
Jun 28 15:59:57 <RP__> kergoth: hmm, its not really an operation on the data and its turning the data object into something more. I can see the attraction though
Jun 28 16:00:17 <RP__> kergoth: I have wondered if we should have a parter in crime for d, such as c, the cooker or something
Jun 28 16:00:27 <kergoth> well, it's all done and stored in datasmart anyway :)
Jun 28 16:00:43 <kergoth> datasmart is arguably already more than just the metadata
Jun 28 16:00:47 <kergoth> but it's a good point
Jun 28 16:00:56 * kergoth ponders
Jun 28 16:01:43 <kergoth> course, there's the issue of timing, having a add_task that does the datasmart bits wouldnt' do squat if you ran it after the taskdata/runqueue operations, but there's no avoiding that sort of thing, i suspect
Jun 28 16:01:47 <kergoth> heh
Jun 28 16:02:13 <RP__> kergoth: I just worry its trending the wrong way to add more to data smart and we really need more objects floating around
Jun 28 16:02:24 <RP__> kergoth: taskdata/runqueue spring to mind too
Jun 28 16:02:33 <fray> (would be cool if you could arbitrarily add tasks...  but it certainly changes the expected behavior)
Jun 28 16:02:44 <fray> s/arbitrarily/dynamically/
Jun 28 16:04:52 <kergoth> hmmm
Jun 28 16:05:34 <fray> I can also see how dynamic tasks could/would be horribly abused
Jun 28 16:05:59 <kergoth> i don't think we'd want them entirely dynamic, but being able to add them from, say, a ConfigParsed event handler woudln't seem like a terribly bad thing
Jun 28 16:06:09 <fray> but you could do things like check if the system had the ability to do something.. and if it didn't, add a task that could build the missing component..
Jun 28 16:06:20 <fray> kind of an in-between between the assume_provided and building everything
Jun 28 16:06:30 <fray> ya..
Jun 28 16:06:50 <fray> do you have tar?  no.. ok we'll add it as a task....
Jun 28 16:07:19 <fray> (very simplistic example BTW)
Jun 28 16:07:44 <fray> kergoth BTW we're still fighting the external toolchain.. -slowly- making progress..
Jun 28 16:07:57 <fray> what I've observed is something the PKG_${PN} = "eglibc" doesn't seem to work..
Jun 28 16:08:14 <fray> but there were other problems, gconv, and charmaps, and such were not being generted properly.. (or at least compatibly)
Jun 28 16:08:55 <kergoth> gconv, charmaps, and locales have all seemed to generate fine for me
Jun 28 16:08:56 * kergoth shrugs
Jun 28 16:09:54 <kergoth> hmm
Jun 28 16:09:56 <fray> they were all being dumped into a single package here..
Jun 28 16:10:19 <fray> may be we are lacking some change you made..
Jun 28 16:10:49 <fray> what is bugging me is that sometimes the PKG_ doesn't seem to work.. but I've not been able to reproduce the failures...
Jun 28 16:10:54 <kergoth> not hereclarson@Config535VM0:/s/c/m/sb-585> ls build_mx6q_debug_multi-build/deploy/ipk/armv7a-vfp-neon/eglibc-gconv*|wc -l
Jun 28 16:10:57 <kergoth> 254
Jun 28 16:11:01 <kergoth> strange
Jun 28 16:11:18 <fray> I bet if you blacklist eglibc-locale you'll find it's using the real package and not the CSL version
Jun 28 16:11:19 <fray> :)
Jun 28 16:11:26 <fray> thats how I found this (and a few others)
Jun 28 16:11:44 <kergoth> what do you mean by 'real package'?
Jun 28 16:11:45 <fray> Added the following:
Jun 28 16:11:45 <fray> PNBLACKLIST[binutils] = "Only use WR Toolchain!"
Jun 28 16:11:45 <fray> PNBLACKLIST[gcc] = "Only use WR Toolchain!"
Jun 28 16:11:45 <fray> PNBLACKLIST[linux-libc-headers] = "Only use WR Toolchain!"
Jun 28 16:11:45 <fray> PNBLACKLIST[eglibc] = "Only use WR Toolchain!"
Jun 28 16:11:45 <fray> PNBLACKLIST[eglibc-locale] = "Only use WR Toolchain!"
Jun 28 16:11:46 <fray> PNBLACKLIST[gdb] = "Only use WR Toolchain!"
Jun 28 16:11:52 <fray> and suddenly a bunch of things broke
Jun 28 16:11:55 <kergoth> external-sourcery-toolchain puts the files into the place where eglibc-locale packages them
Jun 28 16:11:58 <kergoth> you shouldn't blacklist eglibc-locale
Jun 28 16:12:03 <kergoth> its required if you want those packages and localedef
Jun 28 16:12:14 <kergoth> from what i've seen, anyway
Jun 28 16:12:27 <fray> So the external toolchain is re-using the eglibc-locale?
Jun 28 16:12:30 <kergoth> eglibc-locale doesn't acuse a build of eglibc, it just packages what either eglibc or external-sourcery-toolchain put into place
Jun 28 16:12:33 <kergoth> vice versa.
Jun 28 16:12:39 <kergoth> s/acuse/cause/
Jun 28 16:12:49 <fray> Ok, that I didn't know
Jun 28 16:13:41 <kergoth> all the locale files get installed into the sysroot under usr/include/eglibc-locale-foo or somesuch, and eglibc-locale pulls the files from there and does the do_split_package, etc, to package gconv, etc
Jun 28 16:13:47 <kergoth> without eglibc-locale, nothing will packaeg those files
Jun 28 16:14:01 <fray> well my hacked up local copy is packaging them in the external version now
Jun 28 16:14:29 <fray> I'll go back and break out the changes again..
Jun 28 16:14:36 <fray> this all started because I was having failures finding gconv..
Jun 28 16:14:50 <kergoth> i thought about having the toolchain recipe do it, inherit libc-package and all, but eglibc-locale already does it, so there didn't seem much point in re-doing the same work there
Jun 28 16:15:27 <fray> thats fine.. I'll revert those bits of the changes and the blacklist entry..
Jun 28 16:15:36 <fray> and go back and reproduce theproblem I was having then
Jun 28 16:15:43 * kergoth nods
Jun 28 16:15:51 * kergoth mutters and goes to get caffeine before he falls asleep in his chair
Jun 28 16:17:41 <fray> wait, it was the i18n package!
Jun 28 16:17:46 <fray> that wasn't get created
Jun 28 16:17:55 <fray> anyway.. still going to try to get back to a reproducer (locally)
Jun 28 16:28:48 <mranostay> kergoth: i thought you quit coffee :)
Jun 28 16:29:01 <kergoth> mranostay: i quit coffee every few months.
Jun 28 16:29:04 <kergoth> it's a cycle
Jun 28 16:29:18 <mranostay> heh
Jun 28 16:29:41 <kergoth> wtf, certificate validation failure? I connected to the vpn fine yesterday
Jun 28 16:29:43 * kergoth sighs
Jun 28 16:30:39 <mranostay> kergoth: is it your one year expiree?
Jun 28 16:30:51 <kergoth> ugh, i hope not
Jun 28 17:08:23 <kergoth> mranostay: heh, doesn't expire for another 2 years. *eyeroll*
Jun 28 17:08:31 * kergoth busts out the ssh forwarding
Jun 28 17:08:49 <mranostay> don't tell the BoFH :)
Jun 28 17:47:29 <kergoth> RP__: Hmm, tasks dont' have their own prefuncs/postfuncs included in their vardeps. thoughts?
Jun 28 18:51:52 <seebs> I know no one's around right now, but for future reference:
Jun 28 18:52:56 <seebs> I am occasionally bitten by the clash of expectations between "$PN is the name of the package" and "$PN is the name of the recipe". We could improve this some by having a variable which is definitely the recipe name, so a recipe could set $PN to something else and computed package names (like locale packages) would reflect that.
Jun 28 18:53:08 <seebs> The most obvious change this would need would be adding RECIPEBLACKLIST to blacklist.bbclass.
Jun 28 18:55:49 <kergoth> PN is always the recipe name.
Jun 28 18:56:08 <fray> well according ot the docs,, PN is -based- on the recipe name..
Jun 28 18:56:08 <kergoth> by definition.
Jun 28 18:56:11 <fray> but it doesn't have to be
Jun 28 18:56:16 <hollisb> what does the "P" stand for?
Jun 28 18:56:20 <kergoth> no, it is the recipe name
Jun 28 18:56:23 <kergoth> it isn't the recipe *filename*
Jun 28 18:56:37 <kergoth> hollisb: probably 'package', its part of the gentoo/portage origins
Jun 28 18:56:41 <seebs> Well, the example that I care about which got me thinking originally.
Jun 28 18:56:54 <fray> PN[doc] = "PN holds the name of the package (Package Name). It is gathered from the bitbake-file filename"
Jun 28 18:56:59 <seebs> Consider the way in which we generate locale filenames for, say, the libc.mo file in the toolchain.
Jun 28 18:57:08 <fray> PN = "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE'),d)[0]...
Jun 28 18:57:22 <hollisb> kergoth: uh huh... :) maybe "RN" would be better ;)
Jun 28 18:57:26 <seebs> We clearly *mean* that we want that to be eglibc-locale-xx-yy.version.  Because that's the locale for the eglibc package that the toolchain file is creating.
Jun 28 18:57:36 <fray> the problem is, again this external toolchain thing.. by having the PN as "external-...." the debian rename code goes insane and can't renaming things properly
Jun 28 18:57:39 <seebs> But if we set $PN to eglibc, the PREFERRED_PROVIDER magic can't work anymore.
Jun 28 18:57:59 <fray> the PKG_${PN} = "eglibc" for instance won't don what we need.. because there is separate code that then changes it to libc6..
Jun 28 18:58:00 <seebs> And as fray discovered, PKG_foo = "bar" turns out to clash with other rename code.
Jun 28 18:58:09 <fray> then you've got runtime deps on eglibc, and they don't get renmaed..
Jun 28 18:58:10 <kergoth> hollisb: lots of things would be better if we didn't mind breaking compatibility, but we do mind
Jun 28 18:58:13 <seebs> Yeah.
Jun 28 18:58:22 <kergoth> seebs: if PKG_ isn't behavingas expected, it shouldb e fixed.
Jun 28 18:58:32 <fray> PKG_ is doing exactly what it is supposed to
Jun 28 18:58:34 <hollisb> kergoth: not a serious proposal... I'm just saying I think the source of the confusion is clear :)
Jun 28 18:58:37 <fray> look at the renaming mapping hook..
Jun 28 18:58:50 <fray> it does the mapping by looking fro PKG_<thing you are referncing> and using that value as the rename..
Jun 28 18:59:03 <fray> the problem is nothing is looking for PKG_external-csl-toolchain  -- things are looking for PKG_eglibc
Jun 28 18:59:10 <seebs> We sort of want a distinction between "I know exactly what I'm doing, use this name" and "pretend the name was this, but other things might want to rename us later".
Jun 28 18:59:47 <khem> fray: is there a way you can point back to preferred provider for a given dependency
Jun 28 19:00:01 <kergoth> can someone explain exactly what the problem is here? I'm still not seeing an actual bug
Jun 28 19:00:22 <fray> ok.. let me write this up quickly so I don't have to repeat myself to correct errors..
Jun 28 19:02:22 <seebs> I think this is one of the cases where no one part of the situation is obviously a bug, but the set taken as a whole makes certain package tasks hard or maybe impossible.
Jun 28 19:02:54 <seebs> In that for each problem, there exists a solution, but some solutions are "undo the solution to that other problem".  :)
Jun 28 19:03:05 <kergoth> is the issue that we have something depending on 'eglibc'? neither external-sourcery-toolchain (pre-debian-rename) or libc (post-debian-rename)?
Jun 28 19:03:12 <fray> <paste>
Jun 28 19:03:17 <fray> task-core-standalone-sdk-target  produces a package ${PN} that happens to have a runtime dependency on ${TCLIBC} (eglibc)
Jun 28 19:03:17 <fray> When eglibc is blacklisted, and the external toolchain is used, there is no PN = eglibc anywhere in the system.
Jun 28 19:03:17 <fray> PKG_${PN} = "eglibc"  is used to make the package change it's name to 'eglibc' instead of "${PN}".
Jun 28 19:03:17 <fray> --but-- there is a small chunk of code that looks and says eglibc should really be named libc6, so it sets PKG_${PN} = "libc6"..  the reference to 'eglibc' is now gone..
Jun 28 19:03:18 <fray> When evaluating the mapping rename hook, when generating task-core-standalong-sdk-target, eglibc is evaluated and there is no PKG_eglibc in the system, so it assumes the name is thus 'eglibc'.
Jun 28 19:03:19 <kergoth> so the mapping rename doesn't do the rename from eglibc -> libc6?
Jun 28 19:03:32 <fray> ....and so you end up with a image install failure, cause it an't find the 'eglibc' package
Jun 28 19:03:47 <kergoth> i'd think we could make the mapping rename code smarter wrt PKG usage
Jun 28 19:04:11 <khem> fray: that dependency should be virtual/libc really
Jun 28 19:04:15 <fray> kergoth, it doesn't do the map, but even it did it.. it couldn't
Jun 28 19:04:18 <khem> not ${TCLIBC}
Jun 28 19:04:33 <fray> I believ it's TCLIBC to ensure you get thr -right- libc
Jun 28 19:05:03 <khem> but thats a wrong assumption or say use of TCLIBC variable
Jun 28 19:05:03 <fray> but that is just one example.. I would expect other packages (right or wrong) have to inclusions of eglibc..
Jun 28 19:05:18 <fray> ${TCLIBC}-dev and ${TCLIBC}-dbg wouldn't be out of line either
Jun 28 19:05:33 <khem> virtual/libc was made for a reason
Jun 28 19:05:40 <khem> hmm
Jun 28 19:06:02 <kergoth> khem: virtual/libc is build time, not runtime, it's a runtime dep thats the issue
Jun 28 19:06:28 <khem> I think its buildtime
Jun 28 19:06:31 <kergoth> fray: i don't see why it couldn't, not if we emitted all PKG vars to the pkgdata.
Jun 28 19:06:39 <khem> his issue is eglibc recipes are being pulled in
Jun 28 19:07:08 <kergoth> khem: afaik his issue is that something rdeps on a 'eglibc' package, but no eglibc package exists anywhere, only external toolchain (pre-rename) and libc6 (post-rename)
Jun 28 19:07:18 <fray> def runtime_mapping_rename (varname, d):
Jun 28 19:07:19 <fray> ...
Jun 28 19:07:25 <kergoth> if such is the case, then virtual/libc is useless in this context
Jun 28 19:07:38 <fray>                 new_depend = get_package_mapping(depend, d)
Jun 28 19:07:48 <fray>         key = "PKG_%s" % pkg
Jun 28 19:07:48 <fray>         if key in data:
Jun 28 19:07:48 <fray>                 return data[key]
Jun 28 19:07:55 <fray> thats the whole rename in a nuthsell
Jun 28 19:08:04 <khem> kergoth: so package is mapped to recipes ?
Jun 28 19:08:06 <fray> all it has to look at is PKG_%s for a value..
Jun 28 19:08:29 <khem> kergoth: can there be something to denote that eglibc as a package is not coming from a different recipe
Jun 28 19:08:29 <fray> kergoth, yup thats the issue..
Jun 28 19:08:46 <fray> if I change the PN (at the top of the external-toolchain, then it blows up in other new and interesting ways)
Jun 28 19:09:05 <kergoth> khem: all you have to do to work around it is to set RPROVIDES for the external toolchain recipe ${PN} packages to the eglibc incarnations, but i think they're looking for a cleaner solution than that
Jun 28 19:09:13 <fray> I'm -this- close to writing a python chunk that remaps PACKAGES := "${@d.getVar(PACKAGES).replace('...', 'eglibc')}"
Jun 28 19:09:33 <fray> do the same for the RDEPENDS and RPROVIDES and RRECOMEMNDS and RSUGGESTS
Jun 28 19:10:23 <fray> maybe this problem is so specific to the toolchain that that is the right answer..
Jun 28 19:10:53 <khem> why not use RPROVIDES
Jun 28 19:10:58 <kergoth> i think rprovides is the best solution at this point, personally. lit's cleaner than the replace() method
Jun 28 19:11:06 <kergoth> if you arent' going to use a generic solution ,it seems the cleanest
Jun 28 19:11:17 <kergoth> and it doesn't seem like we have a clean generic solution at this point
Jun 28 19:11:45 <fray> RPROVIDES didn't work for some reason the first time I tried it.. I'll try again though
Jun 28 19:12:01 <khem> make sure you include all thats needed
Jun 28 19:12:14 <khem> since if you miss one then it would seem to be not working
Jun 28 19:13:26 <khem> on another point I am having issue with denzil and using BB_NO_NETWORK. I set up my local mirror with git tar balls
Jun 28 19:13:36 <khem> but it still wants to go out into www for cloning
Jun 28 19:13:40 <khem> anyone seen that
Jun 28 19:14:19 <fray> Hmm thought someone had fixed that already..
Jun 28 19:14:24 <fray> maybe it hasn't been pulled back to the rbanch
Jun 28 19:29:04 <darknighte> khem: i've seen a similar behavior before, where the fetcher seems to ignore the local mirror in favor of outside mirros.
Jun 28 19:47:14 <fray> working -- except for -dbg
Jun 28 19:47:15 <fray> Processing kernel-modules...
Jun 28 19:47:15 <fray> error: Failed dependencies:
Jun 28 19:47:15 <fray>         eglibc-dbg is needed by task-core-standalone-sdk-target-1.0-r7.x86_64
Jun 28 19:47:15 <fray> DEBUG: Python function do_populate_sdk finished
Jun 28 19:47:27 <fray> RPROVIDES_${PN}-dbg += "${LPN}-dbg"
Jun 28 19:47:34 <fray> LPN is == eglibc BTW
Jun 28 19:48:09 <fray> Provides: libc-dbg
Jun 28 19:48:25 <fray> thats what it got.. so something fishy is happening o the -dbg file
Jun 28 19:49:52 <fray>                 d.setVar('RPROVIDES_' + bpn + '-dbg', 'libc-dbg')
Jun 28 19:49:52 <fray>                 d.setVar('RCONFLICTS_' + bpn + '-dbg', 'libc-dbg')
Jun 28 19:49:52 <fray>                 d.setVar('RREPLACES_' + bpn + '-dbg', 'libc-dbg')
Jun 28 19:49:57 <fray> from libc-common.bbclass
Jun 28 19:50:02 <fray> d'oh.. it's not adding, it's hard coding
Jun 28 19:55:00 <kergoth> ugh, should fix that to appendVar
Jun 28 19:56:28 <fray> did in my local copy.. we'll see if it works.. :P
Jun 28 19:57:15 * kergoth crosses fingers
Jun 28 20:07:42 <fray> ohh progress.. it got past the target sdk task..
Jun 28 20:08:08 <kergoth> nice
Jun 28 21:11:37 <MysticPxW> having some issues with bitbake and the fsl-community-bsp tree, not sure if this is the place to ask
Jun 28 21:12:03 <MysticPxW> specifically, e2fsprogs-native-1.42.1 is failing, with errors about 'fallocate64'
Jun 28 21:51:57 <MysticPxW> think it's fixed after I upgraded my system glibc, did a clean on e2fsprogs-native, and retried
Jun 28 22:31:30 <seebs> If anyone checked out pseudo from git in the last half hour or so, you're going to have clashes with master, because I just fixed a wrong-bug-number typo in the commit log and replaced the last two commits.  Sorry.
Jun 28 23:12:43 <msm> did yocto 1.2 get support for building multilib toolchains?
Jun 28 23:24:48 <chackal_sjc> how to force the package to install a file from package A instead of package B?
Jun 28 23:25:18 <chackal_sjc> im using CONFFILE inside a recipe that I want but doesnt work
Jun 28 23:32:25 <MysticPxW> chackal_sjc: maybe something to do with the package priority? I'm not completely sure, just learning this myself
Jun 28 23:32:44 <chackal_sjc> MysticPxW: do you know how to set that?
Jun 28 23:33:09 <MysticPxW> are there two packages with the same name, in different layers, or what?
Jun 28 23:34:43 <MysticPxW> I mean maybe I'm completely wrong here. But I just had the manual open to the part about the BBFILE_PRIORITY option
Jun 28 23:35:17 <chackal_sjc> MysticPxW: no, different packages
Jun 28 23:35:30 <MysticPxW> ahh ok
Jun 28 23:35:37 <chackal_sjc> yeah, this woudnt work because they are in the same layer =/
Jun 28 23:36:42 <MysticPxW> ah ok. well good luck - I'm just trying to figure this out myself, I've used OE before but it was the angstrom build and used ipkg so things were a bit different from what I'm seeing here
**** ENDING LOGGING AT Fri Jun 29 02:59:58 2012

**** BEGIN LOGGING AT Fri Jun 29 02:59:59 2012
Jun 29 07:45:30 <mckoan> good morning
Jun 29 08:10:02 <ribalda> hello. Is there any problem with the git repository? I cannot clone
Jun 29 08:13:14 <halstead> ribalda: Yes.
Jun 29 08:13:41 <halstead> The Linux Foundation segment of the OSL network is above capacity.
Jun 29 08:14:38 <halstead> Our ISP has now been paged and they will look into the issue now.
Jun 29 08:14:52 <ribalda> wow, we broke the internet :)
Jun 29 08:14:54 <ribalda> thanks
Jun 29 08:15:37 <halstead> The problem is not likely due to Yocto Project but we are looking into it. :)
Jun 29 08:16:20 <ribalda> there is any known mirror for the git repos?
Jun 29 08:25:28 <halstead> ribalda: I don't think there are any git mirrors. The sources are mirrored at kernel.org
Jun 29 09:24:06 <halstead> The ISP and the NOC have been notified and are working on fixing the current network issue.
Jun 29 09:47:17 <Orre> Hello! Does anyone know if it's possible to use prior compiled kernels for Yocto projects, and if so, how?
Jun 29 10:12:36 <francois99> You don't really need that
Jun 29 10:12:50 <francois99> Yocto creates an RPM package (or another type) each time you compile a package
Jun 29 10:13:01 <francois99> So you wont have to recompile everything everytime, but just once
Jun 29 10:47:25 <Orre> Point is that I want to use my own kernel in the BSP and that it shouldn't spend time recompile it each time it's built.
Jun 29 10:48:24 <Orre> @francois99 So I need to know how to define Yocto to use a precompiled kernel instead of compiling again?
Jun 29 10:48:47 <Orre> fracois99 So I need to know how to define Yocto to use a precompiled kernel instead of compiling again? [Testing how to fire activity]
Jun 29 10:49:53 <francois99> It will reuse that automatically
Jun 29 10:50:01 <francois99> The first time it build packages in your large tmp directory
Jun 29 10:50:10 <francois99> the next time it will reuse precompiled packages
Jun 29 10:51:25 <Orre> Yes I do know that, but I need to use an already compiled kernel to build images to. Let's say that we have a hardware which contains a kernel that the manufacturers don't want to give away the source to. So as I can't use their source but want to build images for their hardware I need to use their already compiled kernel
Jun 29 10:51:36 <Orre> Do you happen to know how to do that?
Jun 29 10:52:20 <bluelightning> well, if it's the whole kernel, they aren't legally allowed to do that...
Jun 29 10:52:42 <bluelightning> assuming that's not just hypothetical
Jun 29 10:52:58 <Orre> There exist a few companies that does it though. Though it's just hypotethical. In this particular scenario I
Jun 29 10:53:13 <bluelightning> well, they aren't legally allowed to deny you access to the source if they have distributed to you the binary
Jun 29 10:53:29 <Orre> I'm working with is that I do not want Yocto to recompile my existing kernel
Jun 29 10:53:51 <bluelightning> well, it's technically possible - it's possible to package anything and have it go into the rootfs
Jun 29 10:53:57 <bluelightning> do we support it out of the box? no.
Jun 29 10:54:08 <Orre> oh, ok.
Jun 29 10:54:43 <Orre> So I can't create a compiled Linux kernel and add it to a BSP to use to produce images?
Jun 29 10:55:26 <bluelightning> like I said, it's technically possible, but you would have to do some extra work to make it work
Jun 29 10:55:34 <Orre> Ok, thanks!
Jun 29 11:00:14 <Orre> A problem I do have in case I should avoid doing it that way is that I'm having a specific made kernel where most of the packages doesn't exist upstream which currently is compiled by another build system. I also wanted to avoid the work to migrate all the different parts of said kernel to Yocto. Is there a simple way to solve this problem?
Jun 29 11:01:17 <bluelightning> what do you mean by "the packages" ?
Jun 29 11:01:45 <bluelightning> do you mean external modules?
Jun 29 11:03:22 <bluelightning> I guess in avoiding work to do the migration you'll be creating yourself some work to package the binary-only kernel and satisfy all of the requirements that we normally do when we build one
Jun 29 11:14:36 <ciupicri> how can I find out to which component of the project a command belongs? in my specific case it's runqemu
Jun 29 11:17:19 <Orre> Packages was probably the wrong word. Everything in the kernel is changed. All from how it's booted, drivers, partitions and so on, and those things aren't upstream. Is there a list of requirements that need to be satisifed somewhere?
Jun 29 11:19:05 <Orre> ciupicri Doesn't runqemu belong in bitbake?
Jun 29 11:19:21 <bluelightning> no, it's part of oe-core
Jun 29 11:19:22 <ciupicri> I have no idea, I've just started using yocto
Jun 29 11:19:30 <ciupicri> I'm still trying to figure out what's going on
Jun 29 11:21:14 <bluelightning> ciupicri: I guess my question is what are you needing to do that prompted the question?
Jun 29 11:21:36 <ciupicri> oh, I wanted to make a suggestion in bugzilla regarding runqemu
Jun 29 11:21:42 <bluelightning> ah, bugzilla
Jun 29 11:21:53 <ciupicri> I didn't have some packages on my system and runqemu failed to start
Jun 29 11:22:18 <ciupicri> it suggested to install libGL* on Fedora, that isn't enough. Installing libGL*-devel fixed the issue.
Jun 29 11:22:34 <ciupicri> s/that/but that/
Jun 29 11:23:07 <ciupicri> for Ubuntu it suggest installing the devel packages
Jun 29 11:23:41 <ciupicri> does it make sense what I'm saying?
Jun 29 11:24:10 <bluelightning> ciupicri: right, yes... I don't think the message mentions debian though does it?
Jun 29 11:26:37 <ciupicri> no, only Ubuntu and Fedora
Jun 29 11:27:26 <Orre> I'm curious, does "LD_PRELOAD=/usr/lib/libGL.so runqemu qemux86" work on Fedora without the devel package? Or do you need the devel as well to do that?
Jun 29 11:27:43 <ciupicri> Orre, let me try it
Jun 29 11:28:30 <Orre> And bluelightning, do you know if I can find the requirement lists required to use a kernel in Yocto?
Jun 29 11:29:07 <ciupicri> ERROR: ld.so: object '/usr/lib/libGL.so' from LD_PRELOAD cannot be preloaded: ignored.
Jun 29 11:29:17 <ciupicri> oops, let me first fix the path
Jun 29 11:29:46 <ciupicri> I have /usr/lib64/libGL.so.1 and /usr/lib64/libGL.so.1.2
Jun 29 11:30:02 <Orre> export OE_TMPDIR=/home/[USER]/poky-denzil-7.0/build/tmp
Jun 29 11:30:11 <Orre> and test both of them
Jun 29 11:30:18 <Orre> I have heard some that used the libGL.so.l
Jun 29 11:30:29 <Orre> libGL.so was the only thing that worked for me though
Jun 29 11:30:46 <ciupicri> LD_PRELOAD=/usr/lib64/libGL.so.1.2 runqemu qemux86 didn't work
Jun 29 11:31:56 <Orre> and neither did libGL.so.l?
Jun 29 11:33:33 <ciupicri> the same
Jun 29 11:33:49 <Orre> ok, sorry then for making you do more work. :(
Jun 29 11:34:23 <ciupicri> no problem, I've learned something new anyway. I had no idea about LD_PRELOAD
Jun 29 11:35:09 <ciupicri> it seems that the devel packages provide *.so (unversioned files) like /usr/lib64/libGLU.so
Jun 29 11:35:19 <Orre> ah
Jun 29 11:36:31 <ciupicri> so where should I report this suggestion?
Jun 29 11:37:10 <Orre> Send a message to bluelightning or to the mailinglists, I'm as clueless as you are about Yocto.
Jun 29 11:49:22 <ciupicri> I found another bug in the documentation http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#pushing-a-change-upstream create-pull-request does not support --help, it's -h :-)
Jun 29 13:13:00 <ciupicri> bluelightning, to which mailing list should I send my runqemu patch?
Jun 29 13:13:28 <bluelightning> ciupicri: openembedded-core@lists.openembedded.org
Jun 29 13:13:38 <bluelightning> sorry, was afk
Jun 29 13:13:42 <ciupicri> no problem
Jun 29 13:13:54 <ciupicri> I need to subscribe first, right?
Jun 29 13:14:11 <bluelightning> ciupicri: you may do, yes
Jun 29 13:14:54 <ciupicri> https://github.com/ciupicri/poky/commit/136c1408e196e33146cacc686cb61ac63f955c47 this is the patch
Jun 29 13:19:57 <bluelightning> ciupicri: sorry I missed that you were talking about Fedora, I thought you mentioned Debian...
Jun 29 13:20:28 <ciupicri> no, I use only Red Hat based distributions. I have never used Debian (or Ubuntu).
Jun 29 13:21:25 <bluelightning> ok :)
Jun 29 13:24:32 <ciupicri> as the Heineken commercial says, "now we wait" for the patch to be accepted :-) ( http://www.youtube.com/watch?v=x_iPvUWyzhE )
Jun 29 13:26:02 <bluelightning> haha, had not seen that before... :)
Jun 29 13:26:39 <ciupicri> an unrelated question: is there a device that uses yocto right now?
Jun 29 13:29:48 <bluelightning> it's kind of a difficult question... often people use a tool but they don't necessarily declare it up front
Jun 29 13:29:51 <ciupicri> I asked Monday someone here on channel if the rockbox project (firmware for music players) uses it and he said no, so I'm wondering who uses it
Jun 29 13:30:14 <B4gder> ciupicri: several embedded linux vendors use yocto
Jun 29 13:30:43 <ciupicri> I see. Like the various router vendors who use Linux, but don't say it in public.
Jun 29 13:30:50 <bluelightning> right
Jun 29 13:56:53 * zeddii apparently was disconnected for days and didn't notice.
Jun 29 13:58:08 <ciupicri> zeddii, you mean your irc client didn't give any errors?
Jun 29 16:48:58 <mranostay> zeddii: were you enjoying the real world in the meantime? :)
Jun 29 16:54:52 <sgw> halstead: you around for setting up and doing a Denzil 1.2.1 build?
Jun 29 17:24:17 <onoffon> zeddii around
Jun 29 17:47:41 <kergoth> hmm
Jun 29 17:51:17 <zeddii> khem1. pong.
Jun 29 18:00:49 <khem1> zeddii have been busy with cars last couple of days
Jun 29 18:01:16 <khem1> would you have some spare time today
Jun 29 18:02:17 <zeddii> khem1. I've got a bit, had a huge workload myself this week. And it's a long weekend for me this weekend .. so I'm trying to stay motivated ;)
Jun 29 18:03:00 <khem1> yeah canada day !
Jun 29 18:03:25 <zeddii> indeed! and then Independence day, so all of NA is out of whack for the week :)
Jun 29 18:03:38 <fray> ya!
Jun 29 18:30:40 * kergoth adds and tests 'tiny' packageconfig for nano
Jun 29 18:35:30 <khem> fray: what is the latest CGL certified kernel used by WR Linux
Jun 29 20:54:45 <ant__> zeddii: ping?
Jun 29 22:26:01 <MysticPxW> hrm... I have a rootfs that boots OK, but it doesn't have a /dev/dsp device
Jun 29 22:26:25 <MysticPxW> it has devices in /dev/snd
Jun 29 22:26:45 <MysticPxW> and if I look at dmesg, it sees an ALSA device on boot
Jun 29 22:27:18 <MysticPxW> not sure what I have to do to get /dev/dsp... maybe a kernel module I'm missing?
Jun 29 22:41:50 <MysticPxW> aha, figured out how to menuconfig. nevermind
Jun 29 23:57:29 <dvhart> I'm seeing a warning about /usr and /usr/src being installed but not added to any package, yet I have /usr/src/kernel in FILES_kernel-dev
Jun 29 23:57:50 <dvhart> what do I need to specify to avoid the WARNINGs ?
Jun 29 23:59:37 <MysticPxW> maybe it's whining because it's having to auto-create /usr and /usr/src
Jun 30 00:00:00 <MysticPxW> ? I recall something like this from working with bitbake on another distro
Jun 30 00:00:15 <dvhart> hrm, checking
Jun 30 00:00:37 <MysticPxW> had to specify the directories in the package, you couldn't just assume that they existed (even though they're pretty much guarenteed to exist)
Jun 30 00:01:22 <dvhart> I see an "install -d ${D}/usr/src/kernel" in do_install
Jun 30 00:01:55 <dvhart> Odd thing is /boot is never explicitly added to a FILES_ var, but it doesn't complain about that
Jun 30 00:02:22 <fray> dvhart -- INSANE_SKIP_<package> = "..."
Jun 30 00:02:43 <dvhart> fray, really? that's the "right" solution? just don't QA it?
Jun 30 00:02:58 <fray> is it being packaged?
Jun 30 00:03:06 <fray> ohh I read that wrong..
Jun 30 00:03:17 <fray> I thought the error was it was complaing you had source in a package, not that it was unpackaged..
Jun 30 00:03:46 <dvhart> ah, yeah it's complaining that /usr and /usr/src are "installed but not shipped"
Jun 30 00:04:02 <fray> not sure then
Jun 30 00:04:07 <dvhart> I have "FILES_<package> = ".... /usr/src/kernel"
Jun 30 00:04:23 <dvhart> do the basedirs need to be explicitly added?
Jun 30 00:04:32 <fray> honestly don't remember anymore
Jun 30 00:04:40 <dvhart> OK :-)
Jun 30 00:04:45 * dvhart greps mailing list
Jun 30 00:05:03 <fray> generating image matching SDKs from prebuilt binary toolchains is currently killing me
Jun 30 00:05:22 <dvhart> I'll take my problem thanks ;)
Jun 30 00:05:30 <fray> hh
**** ENDING LOGGING AT Sat Jun 30 02:59:58 2012

**** BEGIN LOGGING AT Sat Jun 30 02:59:59 2012
**** ENDING LOGGING AT Sun Jul 01 02:59:58 2012

**** BEGIN LOGGING AT Sun Jul 01 02:59:59 2012
Jul 01 14:08:49 <hedphelym> hello
Jul 02 02:30:25 <kergoth> god, the code in archiver.bbclass is terrible and error prone
Jul 02 02:30:32 <kergoth> hardly even know where to begin
Jul 02 02:35:26 * kergoth mutters
Jul 02 02:36:02 <kergoth> case in point:
Jul 02 02:36:03 <kergoth> +FILTER ?= '${@d.getVarFlag('ARCHIVER_MODE','filter') \
Jul 02 02:36:03 <kergoth> +           if d.getVarFlag('ARCHIVER_MODE', 'filter')!= 'none' else 'no'}'
Jul 02 02:36:17 <kergoth> clearly thats intended to result in 'no' when the flag isn't set, but that isn't what that logic does.
Jul 02 02:36:23 <kergoth> None is not == 'none'
Jul 02 02:36:36 <kergoth> so FILTER ends up set to 'None'
Jul 02 02:36:53 <kergoth> many instances of this sort of flawed logic, they didn't even seem to use bitbake -e to make sure it does what they thought it does
**** ENDING LOGGING AT Mon Jul 02 02:59:58 2012

**** BEGIN LOGGING AT Mon Jul 02 02:59:58 2012
Jul 02 08:15:18 <bluelightning> morning all
Jul 02 08:15:34 <Orre> morning
Jul 02 08:32:51 <Orre> Does anyone know if it is still possible to get linux-yocto 2.6.35 and if it's still compatible with the newest Yocto version?
Jul 02 09:45:37 <awafaa> could someone advise on what i need to do to fix http://paste.opensuse.org/3070419 please?
Jul 02 09:46:10 <awafaa> im trying to use a custom kernel and gcc
Jul 02 09:46:32 <awafaa> later has worked fine before but this is the first time im trying a custom kernel
Jul 02 09:52:18 <Orre> What changes did you make to use a custom kernel?
Jul 02 09:54:41 <Orre> Not sure of your problem, but someone has suggested "gksudo gedit /etc/apt/sources.list" and then "sudo apt-get update".
Jul 02 09:55:22 <Orre> Oh, and in the file you open, comment out the top few lines.
Jul 02 09:55:36 <Orre> before you do apt-getupdate
Jul 02 10:33:25 <awafaa> Orre: I created a recipes-kernel with a .bb and defconfig in the right directories
Jul 02 10:54:14 <Orre> awafaa: What are the "right directories"?
Jul 02 10:56:37 <awafaa> Orre: from what I can see http://paste.opensuse.org/38136867 should be right
Jul 02 11:07:22 <Orre> awafaa: When creating a BSP I have just used the yocto-kernel scripts which doesn't create any defconfig - but when I've looked on creating a customized Linux (as you have?) I haven't got so far yet, but haven't seen nay mentioning of a defconifg (for denzil 7.0) - userconfig though is used?
Jul 02 11:09:27 <Orre> nvm, I'm wrong.
Jul 02 11:09:33 <Orre> defconfig is correct
Jul 02 11:13:43 <Orre> awafaa: Shouldn't it be like this EXAMPLE: meta-linaro/recipes-kernel/linux/linux-linaro-2.6.35/beagleboard/defconfig
Jul 02 11:14:07 <Orre> so using upstream would be incorrect?
Jul 02 11:15:50 <awafaa> Orre: not sure atm, i'm pretty new to the whole Yocto way of things :)
Jul 02 11:16:16 <awafaa> your example matches my layout -  meta-linaro/recipes-kernel/linux/linux-upstream/qemuarmv7a/defconfig
Jul 02 11:16:51 <awafaa> the thing is, even that isn't suitable for me as I need to learn how to create a device tree enabled kernel with Yocto
Jul 02 11:17:05 <awafaa> but for now I'd be happy to get any custom kernel to build :)
Jul 02 11:17:42 <Orre> awafaa: Ah, sorry then. :> Well, then I don't know what the problem may be. If you see bluelightning login he maybe can answer you. Most of the yocto team otherwise login in about 4 hours.
Jul 02 11:17:57 <Orre> Though I have had a hard time to get answers about custom kernels tbh.
Jul 02 11:25:04 <awafaa> Orre: np, thanks
Jul 02 11:29:29 <Orre> awafaa: Have you created the configure task?
Jul 02 11:46:16 <awafaa> Orre: what configure task?
Jul 02 11:47:50 <Orre> awafaa: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#platdev-newmachine-kernel
Jul 02 12:18:40 <awafaa> Orre: afaik i'm doing that, but I don't see anywhere that explains how to add the configure task and in which file (I presume the .bb)
Jul 02 12:19:46 <awafaa> Orre: I believe I'm copying the defconfig correctly
Jul 02 12:20:19 <Orre> awafaa: I'm not sure if this is a good idea, but you can try: "make oldconfig" in the same location as the defconfig is?
Jul 02 12:20:34 <Orre> make sure you have a copy of the defconfig first
Jul 02 12:21:10 <awafaa> Orre: you mean in the "SRC_URI =" variable?
Jul 02 12:21:17 <ant_work> hi, pls have a look at http://cgit.openembedded.org/openembedded-core/tree/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
Jul 02 12:21:40 <ant_work> (remove last line  require recipes-kernel/linux/linux-tools.inc)
Jul 02 12:26:30 <awafaa> ant_work: would that affect the creation of the rootfs? I'm hitting http://paste.opensuse.org/3070419
Jul 02 12:26:48 <awafaa> from what I can see I had everything as mentioned
Jul 02 12:27:55 <ant_work> can say about dpkg, I'm using still ipk's
Jul 02 12:27:59 <ant_work> *can't
Jul 02 12:28:50 <awafaa> would package manager have that big an issue? if i dont try my own kernel, but keep using the linaro gcc it all builds and runs fine
Jul 02 12:29:03 * awafaa tries changing from .deb to .ipk
Jul 02 12:45:04 <awafaa> ant_work: many thanks for that, looks like the issue is .deb - .ipk & .rpm work fine
Jul 02 12:45:17 <ant_work> :)
Jul 02 12:45:51 <ant_work> let's ask bluelightning if there is already an open bug... ^^
Jul 02 12:46:50 <awafaa> ant_work: any tips for creating a device tree based kernel? i couldn't see anything in the docs that explained it
Jul 02 12:47:08 <awafaa> ideally something like the link you posted would be great with real example :)
Jul 02 12:51:12 <ant_work> I'm sorry, not yet moved to devicetree...
Jul 02 12:59:25 <awafaa> :(
Jul 02 13:00:40 <ant_work> btw google has a lot of hits wrt xilinx dts kernel
Jul 02 13:01:10 <ant_work> http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/tree/classes/xilinx-kernel.bbclass
Jul 02 13:02:30 <ant_work> awafaa: OMG
Jul 02 13:02:35 <ant_work> we missed that:  http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-kernel/linux/linux-dtb.inc
Jul 02 13:02:42 <ant_work> ^^ obviously read this :)
Jul 02 13:04:14 <awafaa> ant_work: doh!, many thanks
Jul 02 13:05:49 <ant_work> just define KERNEL_DEVICETREE in your kernel recipe
Jul 02 13:06:16 <ant_work> and include linux-dtb.inc
Jul 02 13:06:43 <ant_work> (if it's not already done, pls chekc that)
Jul 02 13:07:21 <ant_work> it is: require linux-dtb.inc
Jul 02 13:13:18 <awafaa> yup, thanks very much for that!
Jul 02 14:20:01 <awafaa> ant_work: i dont suppose you if i have a repo for a kernel, and a different repo for the dtb file can i add them both to the kernel recipe
Jul 02 14:20:18 <awafaa> and add the .dtb in the same way as the defconfig?
Jul 02 16:37:49 <khem> intel BSP guys what machine should I use for say a common pc (64bit and 32bit) ?
Jul 02 16:38:02 <khem> most of BSPs in linux-yocto seems to be atom'ish
Jul 02 16:40:07 <khem> I need for wolfdale/xeon class. I should start of with common-pc-64/base I guess
Jul 02 16:54:56 <fray> khem the qemu ones should be fine
Jul 02 17:17:58 <khem> fray: yes thats what i thought
Jul 02 17:18:16 <khem> I need to tweak them but seems a good base to start
Jul 02 17:18:37 <khem> fray: btw. what kernel do you support with CGL 5.0
Jul 02 17:20:55 <fray> when we get to that point I suspect it'll be 3.4.x
Jul 02 17:21:02 <fray> thats the Yocto/LTSI kernel AFAIK
Jul 02 17:22:53 <khem> fray: hmm I thought LTSI was 3.2
Jul 02 17:23:06 <khem> atleast thats what was meant in ELC
Jul 02 17:24:42 <fray> 3.2 is an initial version of LTSI, but not one that I'm aware anyone has committed to..
Jul 02 17:24:56 <fray> the 3.4 version people have..  (but I'm not a kernel guy so I very well could be wrong on the version numbers0
Jul 02 17:54:19 <khem> fray: ok
Jul 02 17:54:28 <khem> may be zeddii has more information
Jul 02 17:55:40 <fray> ya he may..
Jul 02 17:56:22 <Bagder> 3.0 was the initial LTSI
Jul 02 17:56:33 <Bagder> and 3.4 is the new one afaiu
Jul 02 18:01:03 <fray> ya that sounds familiar..
Jul 02 18:01:23 <fray> AFAIK we don't plan to track 3.0 since there is little commercial interest in it from our customers..
Jul 02 18:01:30 <fray> 3.4 though (and beyond) has a -lot- of interest
Jul 02 18:04:06 <Bagder> and this is from customers who also know what they actually want? =)
Jul 02 18:04:30 <Bagder> I find a lot of customers talk kernel versions without really knowing exactly what they want from their versions
Jul 02 18:04:57 <fray> semis and customers.. and yes they really 'want' it.. i.e. they won't buy unless you sell that version
Jul 02 18:05:09 <fray> if they need it or not is completely different..
Jul 02 18:05:23 <Bagder> hehe, yeah
Jul 02 18:05:25 <fray> but customers buy based on requirement sheets.. and 3.4 LTSI is a requirement that is appearing
Jul 02 18:05:34 <fray> I've -not- seen 3.0 anywhere
Jul 02 18:05:56 <fray> (I have seen 3.0 or newer, with no mention of LTSI)
Jul 02 18:06:50 <Bagder> I can agree with that, I don't find many customers asking about ltsi
Jul 02 18:12:32 * Bagder works for Enea btw, I figure that might not be obvious here
Jul 02 19:15:40 <ciupicri> is there a Darren Hart here?
Jul 02 19:18:52 <seebs> So, idle question for folks: How interested would you be in optional performance improvements in pseudo that had fewer guarantees about data integrity or recovery, but made it noticably faster?
Jul 02 19:19:23 <khem> seebs: such a feature would be nice
Jul 02 19:19:44 <khem> seebs: I am thinking more of quantifying time pseudo is taking can be more evident
Jul 02 19:22:06 <seebs> It's certainly expensive. I'd guess a LOT of time is going into the db stuff.
Jul 02 19:22:16 <seebs> Especially because I think sqlite is going to flush transactions to disk no matter what.  :P
Jul 02 19:25:44 <fray> since the lifespan of a pseudo DB is however long it takes to complete the tasks of a recipe..  at worst if something "goes wrong" you need to clean and rebuild the recipe
Jul 02 19:25:51 <seebs> Yeah.
Jul 02 19:26:06 <seebs> The pseudo design reflects, in part, the LDAT design at the time.
Jul 02 19:26:26 <seebs> Which included a single database which persisted through the whole life of the project, and which all packages used.
Jul 02 19:26:28 <fray> (the only thing if there could be data loss, there has to be a way to detect it to trigger a fault to tell the user that a full recipe rebuild is needed)
Jul 02 19:26:52 <fray> ....but if data loss isnt expected then what we have now is fine...
Jul 02 20:59:29 <challinan> hey folks, what is a reasonably well-tested 64-bit host for building current poky?
Jul 02 20:59:47 <fray> I use centos 6.x
Jul 02 21:00:17 <fray> 6.2 currently
Jul 02 21:03:50 <bluelightning> centos 6.2 here also
Jul 02 21:04:41 <challinan> any guesses as to a default login name for publicly available EC2 AMIs (I'm a ubuntu guy, those are all ubuntu@)
Jul 02 21:06:10 <challinan> ah! ec2-user
Jul 02 21:06:58 <jwessel> bluelightning: Question for you if you are still around.
Jul 02 21:07:15 <jwessel> I see that if I run "hob" it is doing a full reparse, and I am not sure if it is should or not...
Jul 02 21:07:50 <jwessel> Something must be a bit different with that vs the typical invocation. :-)
Jul 02 21:16:26 <bluelightning> jwessel: hi, yep I'm here
Jul 02 21:17:06 <bluelightning> jwessel: it is a bit of a special case vs. the command line UI, though I've no doubt it can be improved
Jul 02 21:35:16 <silverfish_> bluelightning: I see you've forked djwillis / meta-raspberrypi.  Does your meta-raspberrypi generate an SD card image correctly?
Jul 02 21:42:46 <MysticPxW> would anyone be able to point me to some info on the proper alternative to the "legacy" staging? I'm trying to port some packages with devel headers but I don't want those headers in the runtime image
Jul 02 21:43:53 <bluelightning> silverfish_: the fork was just for the purposes of submitting a pull request
Jul 02 21:44:18 <bluelightning> silverfish_: to answer your question, sort of... but someone else was working on the same functionality in parallel
Jul 02 21:44:42 <bluelightning> silverfish_: long story short, his implementation should be being merged soon
Jul 02 21:45:05 <bluelightning> after some feedback from myself and others
Jul 02 21:45:37 <bluelightning> MysticPxW: the devel headers should just get installed as normal and then they can go into the -dev package
Jul 02 21:45:47 <bluelightning> in this way, they will also get staged
Jul 02 21:48:40 <MysticPxW> bluelightning: ah, OK. This package has both binary dynamic libs and headers; for the binaries (which I want in the runtime image) I use "oe_libinstall -so libname ${D}${libdir}" and it seems to work. So for the headers I should just use "install someheader.h ${D}{incdir}/" or something like that?
Jul 02 21:49:01 <MysticPxW> (probably minus the trailing /)
Jul 02 21:49:38 <jwessel> bluelightning: Where I see it spending a pile of time is not in the UI.
Jul 02 21:49:45 <jwessel> It is "getting to the ui".
Jul 02 21:50:01 <jwessel> Because it does a parse to build the pseudo etc...
Jul 02 21:50:12 <jwessel> And it doesn't re-use the bitbake -p that was already done.
Jul 02 21:50:53 <jwessel> The only different I see is that the hob script changes two things. BB_ENV_EXTRAWHITE and DISABLE_SANITY_CHECKS
Jul 02 21:51:10 <jwessel> I am thinking that perhaps the BB_ENV_EXTRAWHITE is actually hashed.
Jul 02 21:52:07 <jwessel> And it might be the case that we have no choice but to hash it, but if this is the case, then settings the hob is using to extend the BB_ENV_EXTRAWHITE should be the default.
Jul 02 21:52:57 <silverfish_> Thanks bluelightning.  I'm just learning my way around git and github...
Jul 02 21:53:44 <silverfish_> and for that matter, Yocto, bitbake, and hob...
Jul 02 22:02:40 <bluelightning> MysticPxW: yes, that's correct - see other recipes for examples
Jul 02 22:03:25 <bluelightning> jwessel: it won't be able to use the bitbake -p at least, since it does not use the same config structure that the command-line UI does
Jul 02 22:03:42 <bluelightning> silverfish_: np
Jul 02 22:04:05 <kergoth> MysticPxW: do note that if the project provides a makefile or something, that's much preferred over oe_libinstall usage
Jul 02 22:06:29 <jwessel> bluelightning: I added DISABLE_SANITY_CHECKS BB_ENV_EXTRAWHITE  to BB_HASHCONFIG_WHITELIST, and it used the initial parse result.
Jul 02 22:06:47 <jwessel> It seems to me that this is probably not the right thing to do though.
Jul 02 22:07:28 <bluelightning> jwessel: hmm... well, it may be worth opening a bug about improving the hob parsing performance and making a note of that in it
Jul 02 22:28:57 <jwessel> I filed it as defect 2680
Jul 02 22:36:53 <MysticPxW> bluelightning, kergoth: thanks :)
Jul 03 01:18:56 <chackal_sjc> guys
Jul 03 01:19:10 <chackal_sjc> I have 2 packages that installs the same file
Jul 03 01:19:22 <seebs> put them in an arena, give them axes
Jul 03 01:19:25 <chackal_sjc> and one is overwriting the other.. how can I fix that?
Jul 03 01:19:30 <chackal_sjc> huahauha
Jul 03 01:19:33 <chackal_sjc> lol
Jul 03 01:19:45 <chackal_sjc> perhaps can I ser some kind of priority?
Jul 03 01:19:47 <seebs> for the most part, I would tend to argue that the solution is not to have two packages install the same file.
Jul 03 01:20:01 <seebs> Because if they do, no matter which one wins, the other has failed to be installed as designed.
Jul 03 01:20:08 <seebs> Which strikes me as evidence that something is broken.
Jul 03 01:20:22 <chackal_sjc> yeah, but in my case, its controlled
Jul 03 01:21:25 <seebs> Well, I don't have a solution that I can think of other than "make one of the packages rename the file".
Jul 03 01:22:30 <chackal_sjc> seebs: what you mean?
Jul 03 01:22:53 <seebs> Edit one of the packages, and alter its do_install rule so that the file which would clash is renamed.
Jul 03 01:22:56 <seebs> e.g.
Jul 03 01:22:56 <chackal_sjc> the problem is that the package that I want to be overwritten is overwriting
Jul 03 01:23:13 <seebs> mv ${D}${bindir}/prog ${D}${bindir}/prog-${PN}
Jul 03 01:23:38 <chackal_sjc> hm
Jul 03 01:23:46 <chackal_sjc> the problem is that the package is Qt4
Jul 03 01:23:50 <seebs> No. The problem is not that the wrong package is overwriting. The problem is that two packages both think they own the same file. What that means is that it is ABSOLUTELY INEVITABLE that the wrong one will win sometimes.
Jul 03 01:24:04 <chackal_sjc> hmm
Jul 03 01:24:05 <chackal_sjc> i see
Jul 03 01:24:07 <seebs> Because users can do stuff like manually install an RPM.
Jul 03 01:24:26 <seebs> So the only thing that will prevent the overwriting is to make sure that you don't have to packages trying to install different files under the same name.
Jul 03 01:24:33 <seebs> ... That said, I still say go with the axes.
Jul 03 01:28:59 <chackal_sjc> ok
Jul 03 01:29:04 <chackal_sjc> seebs: perhaps you can help me
Jul 03 01:29:23 <chackal_sjc> I'm trying to ssh my board.. but it always ask for root's password
Jul 03 01:29:35 <khem> you can divert calle is binary.package1 binary.package2
Jul 03 01:29:37 <chackal_sjc> and blank password doesnt work(even thought the password is empty)
Jul 03 01:29:58 <khem> and then create alternative symlining binary to whateevr you prefert
Jul 03 01:31:41 <seebs> I think ssh's default is to never allow logins to an account without a password defined. There's a difference between no defined password and an empty password.
Jul 03 01:33:29 <chackal_sjc> seebs: yeah, but the debug-tweaks suppose to let you ssh without password, right
Jul 03 01:33:47 <seebs> No clue.
Jul 03 01:37:29 <kergoth> yeah afaik debug-tweaks is supposed to do that, but afaik right now only dropbear obeys it in that way, openssh doesn't
Jul 03 01:37:32 <kergoth> see http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/tree/recipes/openssh/openssh_6.0p1.bbappend
Jul 03 01:37:38 <kergoth> haven't had a chance to submit that yet
Jul 03 01:37:58 <kergoth> so it depends onw hat ssh daemon you're using
Jul 03 01:39:17 <chackal_sjc> kergoth: why do you do this: FILESEXTRAPATHS_prepend := "${THISDIR}:" ?
Jul 03 01:39:26 <chackal_sjc> im using openssh
Jul 03 01:39:38 <kergoth> it's not needed, its a remnant from when i had a local sshd_config in that layer also
Jul 03 01:39:50 <chackal_sjc> ok
Jul 03 01:56:45 <khem> kergoth: do you work with some fsl boards ?
Jul 03 01:57:28 <kergoth> khem: for work, yeah
Jul 03 01:57:43 <khem> kergoth: p5020 ?
Jul 03 01:57:59 <kergoth> hmm, not sure on that one. i know we have p4080, I can check tomorrow
Jul 03 01:58:04 <khem> kergoth: how do you enable ethernet on that do you know
Jul 03 01:58:15 <kergoth> don't, but i can ask the guys at work tomorrow
Jul 03 01:58:23 <khem> ok that wud help
Jul 03 01:58:26 <kergoth> or you could pester msm ;)
Jul 03 01:58:34 <khem> I could yea
Jul 03 01:58:36 <khem> heh
**** ENDING LOGGING AT Tue Jul 03 02:59:57 2012

**** BEGIN LOGGING AT Tue Jul 03 02:59:58 2012
Jul 03 07:28:04 <mckoan> good morning
Jul 03 08:11:48 <awafaa> morning, is there a way of building a fdt kernel using two git repos - one for the kernel source & ine for the .dts?
Jul 03 08:44:12 <Orre> When using a external toolchain everyone says we need to use /opt/poky, but isn't that a part of the ADT? If in that case, do we require to install ADT to be able to use any external toolchains?
Jul 03 09:06:51 <bluelightning> morning all
Jul 03 09:13:40 <Orre> morning
Jul 03 09:15:48 <mckoan> bluelightning, Orre: hi
Jul 03 09:23:14 <Orre> When using an external toolchain, after you have added it to /opt/poky , what is the next step as to be able to use it? Should I specify that toolchain in the ~/poky-denzil-7.0/meta/conf/distro/defaultsetup.conf or does it find it automaticly? Should I do a bitbake- k <toolchain> or just do a simple bitbake -k core-image-minimal ?
Jul 03 09:24:27 <likewise> gm
Jul 03 09:31:00 <Orre> morning
Jul 03 09:40:04 <Orre> If I download the http://downloads.yoctoproject.org/releases/yocto/yocto-1.2/toolchain/x86-64/poky-eglibc-x86_64-i586-toolchain-gmae-1.2.tar.bz2 put it in /opt/poky/ and then do a " bitbake -k i586-poky-linux " I get a "ERROR: Nothing PROVIDES 'i586-poky-linux' ". What am I missing for to be able to use said external toolchain?
Jul 03 09:40:29 <bluelightning> Orre: I'm not sure we really support using our own provided toolchains for building within bitbake
Jul 03 09:40:40 <bluelightning> Orre: they are intended for external compilation
Jul 03 09:41:06 <bluelightning> Orre: you're better off just allowing the build system to build the toolchain as part of the normal process
Jul 03 09:41:37 <Orre> bluelightning: I Just read a old guide from a few years back that suggested to use bitbake. So I just need to use bitbake -k core-image-minimal and it should be fine?
Jul 03 09:41:51 <bluelightning> yep no problem there
Jul 03 09:41:56 <Orre> Thanks! :)
Jul 03 09:42:04 <bluelightning> although -k may not be what you want
Jul 03 09:42:12 <bluelightning> that tells bitbake not to stop if an error occurs
Jul 03 09:43:05 <Orre> I forgot. Started using it during testing of how to get through proxies when I started using Yocto and then forgot to stop using -k
Jul 03 09:44:35 <bluelightning> there's nothing wrong with it per se, it's just that if you're working on a local machine on a particular issue you probably want it to stop on errors
Jul 03 09:44:45 <Orre> bluelightning: When I used bitbake -k core-image-minimal it used Yocto's own toolchain, it just used the cache instead of rebuilding with the new toolchain. Is it because I need to use bitbake -cleansstate or is it because I have forgotten a setting somewhere?
Jul 03 09:45:08 <bluelightning> it will use what was previously built yes
Jul 03 09:45:15 <bluelightning> why would you not want that in this case?
Jul 03 09:45:50 <Orre> Just wanted to see if I am using the external toolchain or not and didn't want to spend a few hours building just because I changed toolchain
Jul 03 09:50:12 <Orre> So after a cleansstate and then bitbaking again, is there any way to see if the new toolchain actually is used - or if it is just using Yocto's own toolchain?
Jul 03 09:55:24 <Orre> And what is the difference between putting a toolchain in /opt/poky and creating a new tcmode whic gets specified by defaultsetup.conf ?
Jul 03 10:05:54 <bluelightning> Orre: just putting the toolchain in /opt/poky will not make the build system use it, if that's what you're expecting
Jul 03 10:08:34 <Orre> I didn't expect that would be enough; it just doesn't state anywhere what to do except "unpack it in /opt/poky and then you can find it's environment settings withint the tar" in all the different manuals. As there's nothing else stated I am trying to find out what to do, or else just amazingly bitbake core-image-minimal would be enough. :(
Jul 03 10:10:02 <Orre> bluelightning: Am I supposed to create a tcmode, which point to the unpacked tar, specify it in defaultsetup.conf and then I'm done? Or is it something completely different?
Jul 03 10:12:35 <bluelightning> you would need to do that but the question is why?
Jul 03 10:12:52 <bluelightning> I can understand if you want to use a manufacturer-supplied external toolchain
Jul 03 10:13:57 <Orre> Similar to today's mailinglist posts: https://lists.yoctoproject.org/pipermail/yocto/2012-July/009897.html I want to be able to use an external toolchain, but it doesn't state anything else then "unpack the tar" in the manuals nor on the mailinglists
Jul 03 10:14:12 <Orre> Which is probably why others ask the same question to the mailing lists
Jul 03 10:14:32 <bluelightning> right, and as that thread says, the toolchains are provided for applications development outside of the build system
Jul 03 10:15:02 <bluelightning> if you want to re-use the toolchain and other native pieces between separate builds, we have shared state which will take care of that
Jul 03 10:15:41 <Orre> And to specify a external toolchain (for example manufacturer-supplied) to do the build we do the tcmode?
Jul 03 10:17:11 <Orre> (the external toolchain which we wanted in this case "re-use the toolchain and other native pieces between separate builds")
Jul 03 10:18:47 <bluelightning> if the manufacturer-supplied toolchain is codesourcery-compatible it can be used with TCMODE = "external-sourcery" (or "external-csl" in released versions)
Jul 03 10:19:46 <bluelightning> but if it's one of our toolchains, well, you're better off using shared state - i.e. preserve/share SSTATE_DIR between builds
Jul 03 10:20:52 <Orre> I'm just looking at the possibility to use a manufacturer-supplied toolchain - I'm already using shared state. Thanks a lot for the help! Have been looking a few hours for find somewhere/someone to state how you are supposed to do it in Yocto! :D
Jul 03 11:39:05 <elmi82> Hi, can anyone tell me under which license the buildscripts of the yocto documentation at git://git.yoctoproject.org/yocto-docs are licensed?
Jul 03 11:39:13 <elmi82> Is it Creative Commons as the documentation itself? Or is it BSD as stated in yocto's terms of service on the website?
Jul 03 12:03:48 <Orre> When using tcmode it can't find the location of the toolchain to be used. I've set the EXTERNAL_TOOLCHAIN to the right address and even went in and set TARGET_PREFIX to the right value, but somewhere it still adds a bin? '/opt/poky/1.2/sysroots/x86_64-pokysdk-linux/usr/bin/i586-poky-linux/bin/i586-poky-linux-gcc -v'
Jul 03 12:04:20 <Orre> Where in the code is the last bin in that line added which causes the ERROR: Failed to obtain CodeSourcery toolchain version ?
Jul 03 12:09:37 <likewise> Do we have a recipe in Yocto for the vanilla upstream kernel?
Jul 03 12:10:20 <likewise> ~seen msm
Jul 03 12:11:59 <Orre> likewise: msm? You find it in the recipes-kernel/linux
Jul 03 12:15:15 <Crofton|work> people use vanilla upstream kernels? :)
Jul 03 12:15:15 <Orre> elmi82: The license is described in the documents? In the kernel-manual.xml it's stated "Creative Commons Attribution-Share Alike 2.0 UK: England "
Jul 03 12:16:18 <likewise> Crofton|work: when anything else fails :)
Jul 03 12:16:41 <Orre> Anyone here used the external_toolchain?
Jul 03 12:16:48 <Orre> external toolchain*
Jul 03 12:20:44 <Orre> nvm, found it in csl_versions.inc
Jul 03 12:59:12 <Orre> As the external-csl.inc lacks the files needed to be built, can I get the files, and in such case, where do I get the files for that toolchain, so I can build with it?
Jul 03 13:05:12 <bluelightning> Orre: what toolchain do you have?
Jul 03 13:07:09 <Orre> bluelightning: Tried to use the i586-poky-linux (downloaded form Yocto) but it seems to just not work. First it's got another directory system then required and if I fix it then it complains about other things
Jul 03 13:07:46 <bluelightning> Orre: as I stated above we do not support using our own toolchains as external toolchains, that's not what they're provided for
Jul 03 13:08:44 <Orre> bluelightning: I know, but when I tried to just use the given files, just changed defaultsetupid to the external it still complains. Is there any way I can test any external toolchain?
Jul 03 13:09:05 <Orre> bluelightning: Given files I ment the ones included in poky-denzil-7.0
Jul 03 13:09:07 <Orre> *
Jul 03 13:09:27 <bluelightning> Orre: if you actually have an external toolchain to use that we support, e.g. a codesourcery based one, then by all means use it
Jul 03 13:09:36 <bluelightning> otherwise I really don't understand what you are trying to achieve
Jul 03 13:10:46 <Orre> bluelightning: You support all codesourcery versions?
Jul 03 13:11:04 <bluelightning> I think that's unlikely, we probably only support a specific version
Jul 03 13:11:09 <bluelightning> but I don't know what that is
Jul 03 13:11:38 <bluelightning> my question would be though if you don't already have the toolchain to use then why not just let the build system build an appropriate toolchain for you?
Jul 03 13:15:59 <Orre> bluelightning: I just wanted to see if using an external toolchain that's not included in Yocto is possible. Trying to create some kind of manual that can be used for making decision if to use Yocto by others.
Jul 03 13:18:32 <bluelightning> Orre: I see
Jul 03 13:21:43 <Orre> bluelightning: We mostly have experience with buildbot earlier so we are quite excited over Yocto, but I feel like quite a newbie trying to figure everything out. Is there some way I can find out which codesourcery version is supported?
Jul 03 13:26:00 <B4gder> it seems a little backwards, trying to come up with a use for an external toolchain to build yocto with
Jul 03 13:32:55 <Orre> Well, we have been using a external toolchain for buildbot earlier and the question is if it's possible to one day export it to Yocto - and in such case - what changes will be needed to be made.
Jul 03 13:33:31 <Orre> So the most urgent knowledge is to know is it possible to have an external toolchain and then what are requirements of said toolchain
Jul 03 13:34:55 <Orre> B4gder: So if you have any solutions to those questions and point me to how to easily test them you would save me a lot of effort! :)
Jul 03 13:36:15 <B4gder> yocto builds a linux distribution for you
Jul 03 13:36:38 <B4gder> it's not very similar to just build buildbot or similar
Jul 03 13:37:17 <B4gder> so no, I don't have any answer to that as I've never considered your use case - and I still don't get it
Jul 03 13:40:16 <likewise> msm: ping
Jul 03 13:41:37 <Orre> B4gder: Well, consider it like this, we have built our own hardware before uboot and that kind of stuff existed. This hardware therefor is a bit strange and demands various requirements from the images it uses. To fullfill said requirements we are using a specialised toolchain. If we are to use a build system we are required to be able to convert said toolchain so it can be used by said build system. Else we need to scrap the idea of usi
Jul 03 13:42:37 <Orre> Or at least figure out how to adapt Yocto's toolchain to handle partition and memory handling.
Jul 03 13:42:56 <B4gder> imho, the yocto way would be to make sure your build produces a good toolchain, with all your own perks included
Jul 03 13:43:15 <bluelightning> that's likely to be the most future-proof option
Jul 03 13:43:50 <B4gder> partitioning and memory handling in the toolchain?
Jul 03 13:45:25 <Orre> I am mostly involved in the more abstract parts of buildbot and as we considered buildbot to be a bit primitive these days I thought Yocto sounded fun and wanted to use it. Partitioning / memory handling was their description, I have no idea about the specifics. They just asked me to find out how to use an external toolchain in Yocto and what the requirements for that was.
Jul 03 13:46:54 <B4gder> Orre: if you would go back to them and explained what yocto is and how it is nothing at all like buildbot then maybe you could start to clear things up
Jul 03 13:47:34 <bluelightning> Orre: if you must use your custom toolchain, then you just need to copy the tcmode-external-sourcery (or -csl as appropriate) and adapt it as needed
Jul 03 13:48:36 <Orre> bluelightning: Yes, I figured that out, so I wanted to test that it worked so I can actually say "Yes, I have even tested it myself". Though all my attempts has until now failed as I can't find any external toolchains to use.
Jul 03 13:48:59 <bluelightning> Orre: that approach won't work though
Jul 03 13:49:11 <bluelightning> Orre: you can't just grab any old toolchain and adapt to that
Jul 03 13:49:41 <bluelightning> Orre: you need to be adapting to your actual custom toolchain, because surely that's all that matters in your current situation...
Jul 03 13:51:14 <Orre> bluelightning: Yes, but we are expecting an adaption of our custom toolchain may take 1-2 years, so we want to be sure we actually dan do said adapation first and it's just not feature which never was implemented. btw, even "bitbake meta-toolchain" won't work.
Jul 03 13:52:55 <bluelightning> Orre: what I mean is, you should get hold of the actual toolchain you currently have, then set up a tcmode file that works with that
Jul 03 13:53:01 <bluelightning> that won't take years
Jul 03 13:53:18 <Orre> All right, should see what can be done!
Jul 03 13:53:26 <B4gder> yes, there's hardly any point in finding a third toolchain to download from somewhere
Jul 03 13:54:51 <elmi82> Orre: Thanks. So also the Makefile is covered by the CCA-SA license?
Jul 03 15:01:54 * RP__ is here
Jul 03 15:02:01 <jmpdelos> jmpdelos is here
Jul 03 15:02:01 * sgw is online
Jul 03 15:02:04 <bluelightning> paul is here
Jul 03 15:02:41 * zeddii got an operator message
Jul 03 15:03:00 <jkridner_> hi, I'm in the meeting.
Jul 03 15:03:02 <bluelightning> RP__: you mean hash yocto ;)
Jul 03 15:03:02 * halstead is having trouble with the passcode.
Jul 03 15:03:07 <jkridner_> This is Jason Kridner.
Jul 03 15:03:26 <RP__> halstead: did you notice it changed in the last couple of meetings?
Jul 03 15:03:26 <zeddii> hmm. did I miss a bridge/passcode email ?
Jul 03 15:03:34 <zeddii> aha
Jul 03 15:03:35 * zeddii hunts
Jul 03 15:03:36 <scottrif> Scott Rifenbark was on and is re-dialing in
Jul 03 15:03:37 <jzhang> jessica joined
Jul 03 15:04:13 <halstead> RP__, I see two. I tried the new one and the old one. Waiting on an operator now.
Jul 03 15:05:08 <adamian> hi guys
Jul 03 15:05:13 <Guest35546> Participant passcode: 	76994298 Dial-in number: 	1.972.995.7777  US Toll Free number: 	1.877.561.6828
Jul 03 15:05:15 <zeddii> woo.
Jul 03 15:05:20 <Guest35546> nick/ Song
Jul 03 15:05:35 <halstead> Okay. I'm in.
Jul 03 15:05:55 <bluelightning> Guest35546: Paul's here
Jul 03 15:06:20 * sgw is Saul
Jul 03 15:06:41 <RP__> Guest35546:  /nick Song
Jul 03 15:07:17 <darknighte> hey, all, I'm on the call.
Jul 03 15:07:21 <jmpdelos> Jeff Polk is here
Jul 03 15:07:43 <bluelightning> Guest35546: Jim is also here in the room
Jul 03 15:08:14 <sgw> jmpdelos: still have all your house guests?
Jul 03 15:08:26 * RP__ open: recursive dependencies
Jul 03 15:08:57 * darknighte things that at the very least, doing a role call on IRC will force him to remember people's nicks
Jul 03 15:09:14 <msm> oh song's on irc
Jul 03 15:09:47 <darknighte> he is Guet35546, I think.
Jul 03 15:10:03 <sgw> RP thanks, I will start a master build on that (or do you have more coming before you bug out after tech meeting?)
Jul 03 15:10:20 <RP__> sgw: probably not
Jul 03 15:10:41 <zeddii> or an "ii" !!
Jul 03 15:10:44 <zeddii> ;)
Jul 03 15:10:50 <sgw> Ok master getting started
Jul 03 15:11:04 <RP> halstead: I can use RP too :)
Jul 03 15:11:07 <jkridner_> Guest35546: you did try putting the / before nick, right?
Jul 03 15:11:15 <zeddii> open: initramfs
Jul 03 15:11:58 * halstead tips his hat to RP.
Jul 03 15:14:26 * fray is having technical problems... (phone issues here)
Jul 03 15:15:57 <zeddii> fray. pull the can backwards. if the string is taught, the sound is better
Jul 03 15:16:02 * zeddii is here to help.
Jul 03 15:16:13 <fray> thanx
Jul 03 15:16:19 <zeddii> np
Jul 03 15:17:24 <RP> fray: dampening the string can help too
Jul 03 15:17:31 <fray> thanx..
Jul 03 15:17:51 <likewise> VOS technology?
Jul 03 15:25:00 * scottrif has to drop for a doctor appt.
Jul 03 15:43:10 * sgw has a sharing
Jul 03 15:44:12 <kergoth> RP: http://blog.vene.ro/2012/07/02/more-on-memory-benchmarking/ looks interesting
Jul 03 15:44:26 <awafaa> chaps, i appreciate there's a meeting going on, but.... is it possible to use 2 git trees to build one kernel?
Jul 03 15:45:05 <awafaa> what i mean is one git tree has the kernel source, the other tree has the .dts to build a device tree based kernel
Jul 03 15:48:32 <ant_work> awafaa: I'd say yes, check this out  http://lists.linuxtogo.org/pipermail/openembedded-core/2011-September/009279.html
Jul 03 15:49:37 <RP> kergoth: interesting, might have to play with that
Jul 03 15:49:50 <RP> kergoth: python memory profiling sucks...
Jul 03 15:49:55 <kergoth> indeed
Jul 03 15:50:21 <sgw> halstead:  autobuilder is running very slow, not responding, anything going on?
Jul 03 15:50:27 <RP> awafaa: Just put two git urls in SRC_URI
Jul 03 15:50:40 <RP> awafaa: It should work
Jul 03 15:51:23 <halstead> sgw, Nothing unusual in the performance monitor. How is the slowness presenting?
Jul 03 15:51:55 <darknighte> halstead: is bugzilla down?
Jul 03 15:52:12 <sgw> halstead: taking a very long time to respond to a refresh of waterfall
Jul 03 15:52:34 <sgw> halstead: bugzilla also
Jul 03 15:53:09 <darknighte> sgw: halstead: I just tried to open https://bugzilla.yoctoproject.org/ in a new window
Jul 03 15:54:08 <darknighte> halstead: sgw: back up now
Jul 03 15:54:35 <awafaa> ant_work / RP many thanks
Jul 03 15:56:24 <awafaa> do i need to stipulate file:// for both defconfig and .dts or just file://defconfig & KERNEL_DEVICTREE_foo="/bar/foo.dts?
Jul 03 15:57:19 <RP> darknighte: jzhang
Jul 03 15:57:54 <sgw> Guest35546: thanks
Jul 03 15:57:56 <halstead> sgw, Looks like we had a bandwidth soft ceiling set too low for the autobuilder. Raised to 60mbit now.
Jul 03 15:58:23 <Guest35546> Technical team meeting ends, thank you everyone!
Jul 03 15:58:55 <darknighte> jzhang: where were you looking for feedback on webhob?
Jul 03 15:59:33 <darknighte> jzhang: ml, I assume?
Jul 03 16:05:26 <msm> ok - so im trying to build a perl module
Jul 03 16:05:41 <msm> and it's failing because of sstate-cache, it's refering a sysroot from another system
Jul 03 16:05:53 <msm> however, it's not in the bitbake -e output
Jul 03 16:06:07 <msm> anyone know where cpan perl module might be pulling this in from?
Jul 03 16:07:24 <RP> msm: somewhere in the sysroot?
Jul 03 16:07:51 <msm> im grepping now
Jul 03 16:08:04 <msm> there are lots of references to the old paths… so im trying to filter down to perl relevant ones
Jul 03 16:08:15 <msm> perl modules to be more specific
Jul 03 16:09:31 <msm> what are the config-heavy*.pl scripts used for?
Jul 03 16:42:04 <RP> msm: we should have run sed against anything that is text based
Jul 03 16:53:17 <chackal_sjc> kergoth: your http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/tree/recipes/openssh/openssh_6.0p1.bbappend doesnt work
Jul 03 16:54:14 <chackal_sjc> it only works if I generate the key in my host and then cat to authorized keys in server
Jul 03 17:26:55 <msm> RP: i'd suggest not looking at the sysroot then
Jul 03 17:27:16 <msm> RP: well i take that back, im on an older version still things could be better on master
Jul 03 17:27:22 <msm> but there are lots of references to the other sysroots
Jul 03 18:50:51 <msm> so I've found the issue with the perl module and sstate-cache
Jul 03 18:51:28 <msm> MakeMaker (e.g perl Makefile.PL) does not progagate info such as CC LD etc down to "subprojects"
Jul 03 18:51:36 <msm> https://rt.cpan.org/Public/Bug/Display.html?id=28632
Jul 03 18:51:55 <msm> is it preferred to do some one off fixes for the recipes that have subprojects such as libxml-parser-perl
Jul 03 18:52:00 <msm> or… something else?
Jul 03 19:06:55 <msm> what are the default local file paths searched for files in SRC_URI
Jul 03 19:06:56 <msm> ?
Jul 03 19:07:04 <msm> I see FILESEXTRAPATHS but is there any other places it looks for?
Jul 03 19:54:37 <kergoth> msm: see FILESPATH. FILESEXTRAPATHS just gets added to that. the real variable used by bitbake is FILESPATH
Jul 03 20:00:00 * mranostay pokes in
Jul 03 20:07:50 <msm> kergoth: ah, thanks
Jul 03 22:12:43 <khem> using devshell for busybox I try to run make and it barfs in devshell
Jul 03 22:12:50 <khem> /bin/sh: x86_64-poky-linux-gcc: command not found
Jul 03 22:13:05 <khem> and I see that env has CC set correctly
Jul 03 22:13:20 <khem> but cross compiler is not in path
Jul 03 22:13:53 <khem> is it right expectation to just do make in the devshell and expect something similar to do_compile ?
Jul 03 23:36:38 <ant__> khem: ping
Jul 03 23:49:48 <sgw> fray: you still around by any chance?
Jul 04 00:40:34 <chackal_sjc> can I use SRC_URI with ssh?
Jul 04 00:41:06 <chackal_sjc> like SRC_URI = "ssh://192.168.1.1/file;user=foo" ?
**** ENDING LOGGING AT Wed Jul 04 02:59:58 2012

**** BEGIN LOGGING AT Wed Jul 04 02:59:58 2012
Jul 04 08:22:03 <mckoan> good morning
Jul 04 08:31:50 <Orre> Good morning
Jul 04 08:32:58 <Orre> General remark: CmdError used in csl-versions.inc in the function csl_version_handler is never defined which at lack of proper files causes quite bad error messages.
Jul 04 08:33:27 <Orre> And of course my general remark of strange hardcoded values at strange locations in the code.
Jul 04 08:39:57 <bluelightning> morning all
Jul 04 08:40:37 <Orre> morning!
Jul 04 09:22:10 <Orre> Comment: You change between American and British English in the code. Look at ast.py and siggen,py, maybe keep to a better standard. And you have lots and lots of variations of "finalise" which you use with eachother, you should probably try to rename those functions to something more verbose
Jul 04 09:23:46 <Orre> nvm, that was bitbake I've accidently crawled into :>
Jul 04 11:36:32 <likewise> gm
Jul 04 11:36:35 <likewise> msm: ping.
Jul 04 11:47:31 <Orre> gm
Jul 04 14:03:19 <likewise> How can I debug why my addtask doesn't seem to end up correctly?
Jul 04 14:05:40 <RP> likewise: What do you need to debug exactly? Does -g help (look at task-depends.dot)?
Jul 04 14:06:11 <likewise> RP: I have a task that needs to run inbetween unpack and patch, but runs afterwards.
Jul 04 14:06:46 <RP> likewise: "addtask foo before patch after unpack" doesn't work?
Jul 04 14:06:57 <RP> maybe with some "do_" in there
Jul 04 14:07:35 <likewise> RP: well, that last point is interesting; what is the exact syntax? addtask foo after do_unpack before do_patch
Jul 04 14:07:55 <RP> likewise: I think so
Jul 04 14:08:23 <likewise> RP: I have seen known metadata layers where addtask do_foo ... is used when the function is called foo. I think that one doesn't work.
Jul 04 14:08:41 <likewise> RP: will try -g thanks
Jul 04 14:20:56 <RP> likewise: the function needs to be do_xxx, that much is certain
Jul 04 14:21:39 <likewise> RP: agreed, that goes for the function name.
Jul 04 14:26:57 <likewise> RP: ok, stupid user error, bblayers pointed to an old copy. However, I have tested several combinations of do prefixes.
Jul 04 14:27:10 <likewise> RP: with function do_foo, "addtask foo before do_a after do_b" works.
Jul 04 14:27:18 <likewise> RP: with function do_foo, "addtask do_foo before do_a after do_b" *also* works.
Jul 04 14:27:31 <likewise> RP: with function do_foo, "addtask * before a after b" does not work.
Jul 04 14:28:10 <likewise> RP: so the metadata where I saw addtask do_foobar and addtask foobar seem to both work, and are ok.
Jul 04 14:28:11 <RP> likewise: That kind of makes sense to me given the code
Jul 04 14:28:38 <RP> likewise: The code handling this adds in the missing prefix in the first option if its not present
Jul 04 14:28:54 <RP> I just wasn't sure if it was the first option or all the options
Jul 04 14:30:12 <likewise> RP: thanks.
Jul 04 16:23:42 <msm> likewise: ?
Jul 04 16:24:26 <khem> msm: I still did not figure out the net on that box
Jul 04 16:26:30 <msm> khem: does it work in uboot?
Jul 04 16:26:52 <khem> hmm lemme check.
Jul 04 16:34:25 <alcoheca> hi i have problems bitbaking eglibc-2.13-r28+svnr15508 in stable yocto (denzil). ld complains  "eglibc-2.13-r28+svnr15508/build-i586-poky-linux/elf/rtld.os: file not recognized: File truncated" wondering if anyone knows how to tackle this?
Jul 04 16:34:46 <alcoheca> i've cleared ccache incase something was lingering there
Jul 04 16:35:11 <RP> alcoheca: Did you run out of diskspace?
Jul 04 16:36:06 <alcoheca> RP not at all
Jul 04 16:36:44 <alcoheca> but you think it's something weird with my setup rather than a configuation issue?
Jul 04 16:37:01 <RP> alcoheca: what filesystem is it on? You could try "bitbake eglibc -c clean" and see if it helps
Jul 04 16:37:09 <alcoheca> ext4
Jul 04 16:37:16 <alcoheca> I've cleaned already
Jul 04 16:37:20 <RP> alcoheca: ext4 should be fine...
Jul 04 16:37:38 <RP> alcoheca: high parallel make settings?
Jul 04 16:37:59 <alcoheca> originally bitbake thread 4 and make -j4 but I reduced them to 1. then cleaned then rebuilt
Jul 04 16:38:04 <alcoheca> no improvement
Jul 04 16:38:07 <JaMa> hmm todays pull seems to cause more harm then missing buildall task.. I was used to bitbake rebuilding image even when no package was changed, now it just says: NOTE: Tasks Summary: Attempted 501 tasks of which 499 didn't need to be rerun and all succeeded.
Jul 04 16:38:18 <RP> JaMa: I'm on this
Jul 04 16:38:21 <JaMa> and only executed task is do_build
Jul 04 16:38:44 <JaMa> ah, ok thanks
Jul 04 16:40:27 <RP> JaMa: pull from bitbake and this should be fixed
Jul 04 16:42:15 <RP> alcoheca: I don't know then :(
Jul 04 16:47:03 <JaMa> RP: thanks, looks better now
Jul 04 16:47:20 <RP> JaMa: sorry about the hiccup!
Jul 04 16:47:47 <RP> we need a better test suite for bitbake...
Jul 04 16:47:51 * RP is trying...
Jul 04 16:55:13 <Crofton|work> RP, work harder!
Jul 04 17:02:42 <JaMa> RP: about that usecase for buildall I guess it was usefull to squeeze one more task at the very end of task change (after build before buildall) but I don't really use it anymore and it was just left over in my local.conf IIRC
Jul 04 17:04:29 <RP> JaMa: ok, I was thinking it was mainly a leftover. You can do that with BB_DEFAULT_TASK iirc like rm_work does
Jul 04 17:13:29 <Crofton|work> I'm seeing a do patcjh failure in gcc-cross-intial and libgcc
Jul 04 17:14:05 <JaMa> Crofton|work: cleansstate and start again
Jul 04 17:15:02 <Crofton|work> how do you do that?
Jul 04 17:15:07 <Crofton|work> for the failing packages?
Jul 04 17:15:11 <Crofton|work> this was from a clean start
Jul 04 17:17:56 <Crofton|work> looks like I need to do them one at a time
Jul 04 17:20:19 <JaMa> it sometimes fails like this and restarting build is sometimes enough, cleansstate + build restart was always enough (sofar) for me
Jul 04 17:20:42 <Crofton|work> I had to build gcc-cross-initial by itself
Jul 04 17:21:50 <bluelightning> did anyone report this bug?
Jul 04 17:21:59 <bluelightning> (other than just now, that is)
Jul 04 17:22:02 <Crofton|work> :)
Jul 04 17:22:08 <Crofton|work> I just stumbled over it
Jul 04 17:28:58 <JaMa> I've seen it few times together with other gcc related issues and I'm reporting it on every gcc upgrade patch thread..
Jul 04 17:29:38 <JaMa> if it's 100% reproducible for you then even better, in my case it's only 1 in 5 builds or so..
Jul 04 17:40:23 <alcoheca> RP: human error - I wasn't aware that there's a local ccache folder in tmp!, I found the rogue empty object files in there. swiftly moving along now, thanks.
Jul 04 17:43:45 <b1gtuna> i can't build gcc-cross-inital
Jul 04 17:44:14 <b1gtuna> hm it looks like i am not the only one who's having that issue
Jul 04 17:59:06 <Crofton|work> remind me where image features are defined :)
Jul 04 17:59:29 <Crofton|work> b1gtuna, the cleanstate worked for me
Jul 04 18:07:17 <b1gtuna> Crofton, how do i use that command? sorry i'm a noob =P
Jul 04 18:08:12 <Crofton|work> bitbake -c cleansstate gcc-cross-initial
Jul 04 18:08:22 <Crofton|work> for whatever recipes failed
Jul 04 18:08:27 <Crofton|work> then build then one at a time
Jul 04 18:08:31 <Crofton|work> and you should be ok
Jul 04 18:09:02 <b1gtuna> i see thank you!
Jul 04 19:02:46 <khem> ERROR: Fetcher failure for URL: 'http://www.chiark.greenend.org.uk/~sgtatham/puzzles/puzzles-r9561.tar.gz'. Checksum mismatch!
Jul 04 19:02:50 <khem> File: '/home/kraj/work/openembedded-core/build/../../downloads/puzzles-r9561.tar.gz' has md5 checksum 4ffd5eaead1ffba8b865c83b93fb4709 when c86695aebfc95efe1d6241863849101b was expected
Jul 04 19:02:54 <khem> File: '/home/kraj/work/openembedded-core/build/../../downloads/puzzles-r9561.tar.gz' has sha256 checksum 35e79befa04c61df850384ff6c07b4d154412240b81f637275de383cb7d542d0 when 2c20a45189387e3de8804a58bdb4e47ac4bb0f890001a509dfbdc015b5a84b95 was expected
Jul 04 19:02:58 <khem> ERROR: Function failed: Fetcher failure for URL: 'http://www.chiark.greenend.org.uk/~sgtatham/puzzles/puzzles-r9561.tar.gz'. Unable to fetch URL from any source.
Jul 04 19:03:07 <Crofton|work> heh
Jul 04 19:03:09 <khem> sgw seeing it ?
Jul 04 19:03:17 <Crofton|work> I am not getting output in tmp/deploy myself
Jul 04 19:03:25 * Crofton|work goes to ride his bike
Jul 04 19:04:52 <khem> Crofton|work: I did 27 miles other day
Jul 04 19:04:58 <Crofton|work> awesoem
Jul 04 19:05:01 <khem> today only 13
Jul 04 19:05:17 <khem> I have to pick up family from SFO
Jul 04 19:05:45 <Crofton|work> strava says 25 yesterday
Jul 04 19:05:50 <khem> hills almost killed me but I kept pressing
Jul 04 19:06:04 <Crofton|work> heh, nothing buut hills here
Jul 04 19:06:20 <Crofton|work> http://app.strava.com/rides/12373595
Jul 04 19:06:44 <Crofton|work> bad set of elevation daatt in there though
Jul 04 19:06:44 <khem> yeah the road goes straight up I dont know if folks in CA knew how to design hilly roads
Jul 04 19:12:27 <khem> Crofton|work: https://maps.google.com/maps/ms?msid=213325238746288147305.0004c405c9d29d51e647b&msa=0&ll=37.474586,-121.829796&spn=0.097544,0.181789&iwloc=0004c405c9d51f6183b7f
Jul 04 19:14:02 <RP> alcoheca: That is an interesting point. We should make clean remove that. Fancy filing a bug?
Jul 04 19:19:31 <alcoheca> RP I'll file one tomorrow
Jul 04 19:19:42 <alcoheca> off to cinema
Jul 04 19:22:28 <alcoheca> first build completed successfully.. now to break stuff :)
Jul 04 19:33:43 <seebs> ...
Jul 04 19:33:54 <seebs> I... was that guy. I sent a patch out under *** SUBJECT HERE ***.
Jul 04 19:34:10 <seebs> I try so hard not to be that guy. Because I know that YOUR NAME HERE is really protective of his project domain.
Jul 04 19:36:20 <khem> heh
Jul 04 19:36:54 <seebs> Most of the time, thanks to the configuration of one of our internal developer tools, he spends his time working on INSERT TEN WORD SUMMARY HERE.
Jul 04 19:37:29 <seebs> Luckily, the testers have an automated script to DESCRIBE TESTING PROCEDURE HERE.
Jul 04 19:42:53 <seebs> That said: Should I re-send that pull request, or should I just trust that people will look beneath the surface impression of a half-baked submission and note an actual patch for a pseudo bug which was *not* user error?
Jul 04 19:59:45 <khem> too much automation
Jul 04 20:29:24 <sgw> khem: that sounds like he updated puzzles again, he does not keep the older versions around, you have to get them from the mirror
Jul 04 20:30:12 <sgw> Crofton|work: it was a 10K race for me this morning 43:17, first time, bike ride is tomorrow.
Jul 04 20:33:58 <RP> Any automake experts around?
Jul 04 20:35:15 <Bagder> I've at least used it a lot, let me try
Jul 04 20:36:46 <RP> I'm specifically wondering why make appears to be recursing into things and somehow hanging with high values of -j
Jul 04 20:37:15 <RP> make all-recurse seems to trigger a make all in various directories which in turn ends up with a make all-recurse
Jul 04 20:38:42 <Bagder> are you saying that is a general automake problem in more than one project?
Jul 04 20:39:00 <RP> Bagder: no, I don't know what the problem is :(
Jul 04 20:40:52 <RP> I also just appear to have removed the code I though was causing the problem and its still hanging
Jul 04 20:41:18 <Bagder> debugging make -j problem is really annoying
Jul 04 20:41:23 <Bagder> problems
Jul 04 20:41:27 <RP> the software in question is gthumb
Jul 04 20:42:19 <Bagder> and I take it they don't do anything special in their Makefile.am file?
Jul 04 20:43:33 <RP> Bagder: Just that its a recursive makefile at the top level. I'm removing the more exotic bits
Jul 04 20:45:37 <RP> Bagder: It is the code I think it is. Once I remove all of it, it "works"
Jul 04 20:46:42 <RP> Bagder: http://git.gnome.org/browse/gthumb/tree/gthumb/Makefile.am - anything with a GLIB_MKENUMS in it
Jul 04 20:49:37 <Bagder> and GLIB_MKENUMS seems to come from the configure script as it isn't set within that file
Jul 04 20:51:36 <Bagder> right, it is supposed to be the path to glib-mkenums
Jul 04 20:51:42 <RP> Bagder: Its a command, that is fine
Jul 04 20:52:00 <RP> Bagder: the question is why it seems to want to run this command twice in two different make processes
Jul 04 20:52:03 <RP> which can race
Jul 04 20:52:47 <RP> Seeing it twice in the output is the only clue I've got about what might be going wrong
Jul 04 20:54:32 <Crofton|work> anyone know why I do not get tmp/deploy when buidling an image
Jul 04 20:54:42 <Bagder> the header gth-enum-types.h appears twice in the gthumb_SOURCES list, I wonder if that is related
Jul 04 20:55:26 <ant__> RP: I got yet a single failure, -c cleanall did fix that (OSError: [Errno 12] Cannot allocate memory)
Jul 04 20:55:31 <ant__> http://paste.debian.net/177752/
Jul 04 20:55:58 <ant__> this after pull of yesterday
Jul 04 20:56:00 <RP> ant__: your system ran out of memory?
Jul 04 20:56:07 <ant__> no way, 8GB
Jul 04 20:56:37 <RP> ant__: can you run top in the background, see if memory usage explodes for something?
Jul 04 20:56:45 <RP> (while running that build)
Jul 04 20:56:50 <ant__> sure, just I could not reproduce it
Jul 04 20:56:57 <ant__> anymore
Jul 04 20:57:02 <RP> ant__: ah, it was a one off? :/
Jul 04 20:57:18 <RP> ant__: I suspect something on the system was using a lot of memory at that point?
Jul 04 20:57:20 <ant__> seems heisenberg bug
Jul 04 21:23:08 <Crofton|work> I must have checked out bitbake right before the commit that fixed my problem went it
Jul 04 22:45:07 <seebs> So I had this great idea that it would be super useful to make siteinfo explain what went wrong when spewing many copies of the "unable to determine endianness of INVALID" message.
Jul 04 22:45:47 <seebs> But this doesn't actually solve the Other Problem, which is huge lists of other error messages and failures, all of which are irrelevant because they are fallout from that initial problem.
Jul 04 22:46:23 <seebs> Sort of a low-priority cosmetic task, but I am thinking about it because it turns out to result in me spending more time than I'd like reviewing bug reports that turn out to be of the form "none of the errors you quoted are relevant, MACHINE was set wrong".
Jul 05 00:06:02 <b1gtuna> Is anyone else having issues bitbaking strace?
Jul 05 00:06:40 <b1gtuna> I get a bunch of "error: request for member '[some variable name]' in something not a structure or union"
Jul 05 00:07:43 <seebs> huh, that's an odd message to get from a package that presumably built at some point.
Jul 05 00:11:56 <b1gtuna> odd message that i rather not see xD
**** ENDING LOGGING AT Thu Jul 05 02:59:58 2012

**** BEGIN LOGGING AT Thu Jul 05 02:59:58 2012
Jul 05 07:48:28 <Orre> If anyone reads this: Can't you at this error: "FetchError: Fetcher failure: SRCREV was used yet no valid SCM was found in SRC_URI" add so that it says SRC_URI="<GIVEN URI PATH>" ?
Jul 05 08:05:58 <Orre> nvm, seems like another bitbake problem.
Jul 05 08:31:00 <Orre> Using a custom kernel I get the error message while bitbaking an core-image-minimal: ERROR: Nothing PROVIDES 'x-load'  x-load was skipped: incompatible with machine MYMACHINE (not in COMPATIBLE_MACHINE) ERROR: Required build target 'core-image-minimal' has no buildable providers.  Missing or unbuildable dependency chain was: ['core-image-minimal', 'x-load']
Jul 05 08:50:36 <Orre> nvm, found it
Jul 05 09:16:48 <Orre> If I want to use a local kernel in my custom BSP by adding said local kernel SRC_URI git location to the linux-yocto_3.2.bbappend, what do I need to do more? As when I bitbake I get a DEBUG: Mirror fetch failure for url http://downloads.yoctoproject.org/mirror/sources/git2_.home.user.GIT.mainline.tar.gz;nocheckout=1;protocol=file;name=machine;branch=standard/default/arm-versatile-926ejs/MYMACHINE (original url: git:///home/user/GIT/mainl
Jul 05 09:16:56 <Orre> 1;protocol=file;name=machine;branch=standard/default/arm-versatile-926ejs/MYMACHINE (original url: git:///home/user/GIT/mainline;protocol=file;nocheckout=1;branch=standard/default/arm-versatile-926ejs/MYMACHINE;name=machine)
Jul 05 09:17:34 <Orre> Which means that it of some reason still believe I am using yoctos mirrors when I thought I was only specifying a local mirror.
Jul 05 09:17:50 <Orre> Is there a "require local_build.conf" I should put somewhere?
Jul 05 09:43:52 <Orre> The reason was that I lacked bareclone=1 in the SRC_URI
Jul 05 09:44:03 <Orre> So - solved.
Jul 05 10:19:18 <ainch> Hi all
Jul 05 10:19:53 <ainch> i'm trying to use edison on beagleboard xm an remains on Uncompressing Kernel
Jul 05 10:20:26 <ainch> I just followed steps of quick guide
Jul 05 10:20:31 <ainch> any hint?
Jul 05 10:20:36 <ainch> thanks in advance
Jul 05 10:23:54 <exosyst>  /join #fedora
Jul 05 10:25:13 <bluelightning> ainch: any reason you're not using denzil (the latest release?)
Jul 05 11:32:58 <Orre> In this custom kernel the arm/arch/ has been renamed to arm/ark/ so when bitbaking it doesn't find the makefile arm/arch/Makefile. Where is said link specified so I can change it to arm/ark?
Jul 05 11:33:12 <Orre> Or how do I add a patch which does said change?
Jul 05 12:01:17 <Orre> Seems I was logged out, did I get an answer or no one knows how to tell Yocto how to build the kernel?
Jul 05 12:06:53 <bluelightning> Orre: well when we build the kernel we more or less just run make and expect it to be able to find things... where is it actually failing?
Jul 05 12:10:56 <Orre> bluelightning: I begin consider it may be I whom have done a error. Though, the errors were: grep: arch/arm/Makefile: No such file or directory ERROR: required features were not found. aborting task 984 of the core-image-minimal.
Jul 05 12:11:26 <Orre> Task 984 of the core-image-minimal I added at the end of that sentence myself*
Jul 05 12:17:02 <bluelightning> Orre: there are a number of references to arch/ in the kernel compilation code... AFAICT it's somewhat atypical to have renamed a directory within the kernel source like that
Jul 05 12:17:23 <bluelightning> Orre: honestly I think the simplest thing to do would be to just 'ln -s arch ark' in do_configure_prepend and then that stuff should just work
Jul 05 12:17:47 <bluelightning> er, actually ln -s ark arch
Jul 05 12:32:34 <Orre> Seemed to be logged out again... :/
Jul 05 12:32:36 <Orre> bluelightning: Should I change the do_configure_prepend in a specific file or should I just create a new bbappend with do_configure_prepend?
Jul 05 12:32:51 <bluelightning> Orre: in a bbappend yes
Jul 05 12:47:00 <Orre> bluelightning: When I fixed that, I got: WARNING: checkpoint tag not found, creating ..  WARNING: addon feature "features/netfilter" was not found WARNING: addon feature "features/taskstats" was not found WARNING: addon feature "cfg/smp" was not found ERROR: required features were not found. aborting ERROR: Task 481 (/home/user/poky-denzil-7.0/meta/recipes-kernel/linux/linux-yocto_3.2.bb, do_patch) failed with exit code '1'
Jul 05 12:47:25 <Orre> Do you happen to know what that means?
Jul 05 12:50:40 <RP> Orre: its looking for some features the recipe specifies and not finding them
Jul 05 12:52:17 <bluelightning> if you're not building a linux-yocto style kernel I wonder if it would be easier to use a more traditional kernel recipe
Jul 05 12:52:58 <bluelightning> Orre: what version of the kernel is this based on?
Jul 05 12:59:44 <Orre> It's an 2.6.35 which should be upgraded mostly up to 3.2 though differ a bit.
Jul 05 13:00:33 <bluelightning> ok, not too old then
Jul 05 13:18:48 <Orre> I tested to just remove said KERNEL_FEATURES which was described in the linux.bb but then I get: meta/cfg/master/master/master/master/config_frag.txt: No such file or directory
Jul 05 13:18:58 <Orre> Which I have no idea what may cause it
Jul 05 13:19:29 <Orre> mv: target `2.6.35' is not a directory
Jul 05 13:19:40 <Orre> creation of pre-processed config data failed
Jul 05 13:21:21 <bluelightning> zeddii: ping
Jul 05 13:22:08 <Orre> May it be caused by lacking a meta branch?
Jul 05 13:22:46 <bluelightning> typically for a linux-yocto based kernel you would have a meta branch I think yes
Jul 05 13:23:01 <bluelightning> but I wonder if that's the most appropriate course for your situation
Jul 05 13:23:22 <bluelightning> I'm hoping zeddii will be able to advise better than me
Jul 05 13:24:58 <Orre> *holding my thumbs* will be present here the next 1.5 hours so I hope he gets online earlier than that. I get time to get online after that sometime tommorow at earliest.
Jul 05 13:28:20 <ant_work> I guess you should first have a look at linux-yocto-custom
Jul 05 13:30:26 <ant_work> Orre: try to base your .bbappend on this instead
Jul 05 13:30:28 <ant_work> http://cgit.openembedded.org/openembedded-core/tree/meta-skeleton/recipes-kernel/linux
Jul 05 13:31:51 * zeddii reads
Jul 05 13:32:31 <zeddii> if you aren't actually using a linux-yocto repo as your base, then you'd want the -custom, create a meta branch and/or clobber those KERNEL_FEATURE lines
Jul 05 13:32:41 * zeddii tosses out three options in one blast :)
Jul 05 13:35:23 <Orre> ant_work: Will try and see if it works!
Jul 05 13:35:58 <zeddii> if it is unclear, you can ask me here or via email, linux-yocto-custom is also my spawn :)
Jul 05 13:36:12 <Orre> zeddii: -custom?
Jul 05 13:36:46 <zeddii> the link from ant_work points at the skeleton linux-yocto-custom recipe that I put in meta-skeleton.
Jul 05 13:37:00 <ant_work> zeddii: I can't imagine the config processing would cope well btw 2.6 and 3.x kernels...
Jul 05 13:38:34 <zeddii> yah. not something I've personally tested. I can't think of any big dependencies, but it may just go boom.
Jul 05 13:39:41 <ant_work> the new fragment rework will be done for 3.4, isn't?
Jul 05 13:43:03 <zeddii> ant_work, you mean the cleanup of the configuration options, and buckets + the normal tooling evolution ? if so, yes, I'm just finishing up more changes now.
Jul 05 13:44:12 <Orre> Directly copying the custom, forcing it to use the linux the custom points to works fine with the BSP. I've built a core-image-minimal that way now. Created a meta branch on my local linux rep and will try to use that one instead next.
Jul 05 14:20:07 <kergoth> hmm, wonder why PACKAGECONFIG wasn't used for perl/python bindings in perf.. guess they did a bit more than that could handle
Jul 05 14:21:41 <awafaa> sorry to ask again, but how can i build a kernel using 2 git repos - 1 for source and 1 for .dts?
Jul 05 14:21:44 <RP> kergoth: I wanted to suggest it but decided right know there was enough else going on
Jul 05 14:21:59 <awafaa> my kernel .bb looks like http://paste.opensuse.org/20911301
Jul 05 14:28:49 <awafaa> the error i get from bitbake is http://paste.opensuse.org/22089850, and i have to kill each bitbake process manually
Jul 05 14:30:12 <kergoth> RP: heh, fair enough, and agreed
Jul 05 14:31:39 <Orre> Erm, shouldn't a bitbake linux-yocto -c cleansstate be enough to make the bitbake notice that I have changed settings in the .bbappend file?
Jul 05 14:32:24 <bluelightning> Orre: if you have done that there's no way it can be keeping anything from the previous build
Jul 05 14:32:39 <bluelightning> not for linux-yocto, at any rate
Jul 05 14:33:21 <Orre> I used the custom bbappend linked above and now when I have changed the repository it doesn't rebuild any of the files - even after a bitbake linux-yocto -c cleansstate
Jul 05 14:34:31 <Orre> nvm, my fault, seemed to been an error during the cleansstate which I missed
Jul 05 14:45:12 <Orre> ERROR. meta data not found, check upstream repo for tags and branches
Jul 05 14:45:39 <Orre> I create a branch named "meta", does it need to be named something different?
Jul 05 14:47:01 <zeddii> no, in fact it must be named meta (for now). what branch of yocto are you using ?
Jul 05 14:47:10 <Orre> Denzil 7.0
Jul 05 14:47:18 <Orre> 1.2
Jul 05 14:48:48 <zeddii> ok. there are some changes in master that made meta data detection easier. If you aren't on master, I do recommend just keeping the meta data (that you'd put in the meta branch) in recipe space, and only if using the full linux-yocto repositories worry about adding meta data in tree.
Jul 05 14:50:07 <Orre> Ok, will see what to do... Though have to go on a meeting so won't be able to test it until tommorow. :> aw well, thanks a lot for the help!
Jul 05 14:53:01 <zeddii> Orre, sounds good. I'm finishing up a change that has me distracted (annoyed, stubborn), but I'll be around to help tomorrow as well.
Jul 05 15:25:05 <zenlinux> question for folks regarding setting a custom root password - my understanding is the proper way to do this would be in a custom image by setting a sed command to substitute the encrypted root password string in /etc/shadow during a rootfs postinstall
Jul 05 15:25:21 <zenlinux> how does one generate the new root password string?
Jul 05 15:26:04 <zenlinux> I don't see a passwd option to display a generated encrypted password to the command line
Jul 05 15:26:25 <zenlinux> so would I really need to crate the password hash in my host's local shadow file and then copy and delete it from that file?
Jul 05 15:26:29 <zenlinux> seems awfully obtuse
Jul 05 15:28:01 <Crofton> I have a random git repo I need to turn into a kernel recipe
Jul 05 15:28:12 <Crofton> cp linux-yocto-custom and start editing?
Jul 05 15:30:47 <bluelightning> zenlinux: it might be nice if we had some functionality to make that process a bit easier
Jul 05 15:31:04 <bluelightning> Crofton: I think that's the recommended method judging from the above
Jul 05 15:31:16 <zenlinux> bluelightning, yes, I'm thinking this is an embarrassing process to have to explain to a user
Jul 05 15:32:17 <zenlinux> fortunately we do have patched shadow utils that can write to a passwd and shadow file in a sysroot, so maybe we can modify them further to help automate custom password generation in images
Jul 05 15:33:11 <fray> Hmm for some reason i thought that already worked
Jul 05 15:33:29 <fray> (using passwd from the shadow-utils to affect the sysroot)
Jul 05 15:33:39 <ciupicri> bluelightning, do you happen to know if Scott Rifenbark hangs around here?
Jul 05 15:35:15 <bluelightning> ciupicri: he's just joined :)
Jul 05 15:35:23 <zenlinux> fray, it does work, we just need to define a clear process for using it for this purpose correctly
Jul 05 15:36:10 <fray> ahh ok..
Jul 05 15:36:33 <fray> I figured you could add a class and then the post_image... something or another to change the values
Jul 05 15:37:53 <bluelightning> you mean call your custom procedure from ROOTFS_POSTPROCESS_COMMAND ?
Jul 05 15:38:14 <fray> ya, thats hte one
Jul 05 15:38:24 <bluelightning> indeed, that's what I'd do
Jul 05 15:39:03 <Crofton> what does the nochekout option do?
Jul 05 15:54:26 <bluelightning> fray: seebs: you guys know anything about selinux and pseudo interaction?
Jul 05 15:54:43 <seebs> Very very little.
Jul 05 15:54:49 <fray> selinux (and apparmor) on the host tend to prevent ld_preloads..
Jul 05 15:54:58 <seebs> I should warn you, I have a sort of long-standing personal grudge against selinux. :P
Jul 05 15:55:02 <bluelightning> heh
Jul 05 15:55:15 <fray> they're generally considered a security concern cause, well you can intercept things and change their actions.. not like we want pseudo to do anything like that.. :P
Jul 05 15:55:27 <bluelightning> well I've never experienced serious problems and have managed to do many successful builds with selinux enabled
Jul 05 15:55:28 <fray> for development machines I generally disable selinux, or set it as permissive as possible..
Jul 05 15:55:48 <fray> apparmour (the one time I used it) I had to disable to get pseudo to work.. since it simply prevented the ld_preload
Jul 05 15:56:25 <bluelightning> however, I am currently noticing when building with deb packaging that the ${IMAGE_ROOTFS}/var/lib/dpkg/status file appears to have no security context within do_rootfs, and sed -i complains of this, but when I check outside it's fine
Jul 05 15:56:51 <fray> the context information from within pseudo is disabled..
Jul 05 15:57:04 <fray> there is no effective way to capture the context and process it.. :(
Jul 05 15:57:11 <fray> not sure why sed is complaining though
Jul 05 15:57:24 <bluelightning> no, I don't know why sed complains and nothing else does
Jul 05 15:57:35 <fray> seebs, this sounds like the context issue we hit a while back where the host context was leaking through..
Jul 05 15:59:51 <fray> i.e. the xattr stuff..
Jul 05 16:00:09 <fray> if you can figure out how sed is trying to read/set the context (I assume xattr) then we might have a missing value or something
Jul 05 16:00:50 <fray> ya, I think all of the xattr stuff returns -ENOTSUP in psuedo context..
Jul 05 16:12:30 <sgw> halstead: can we tweak the media wiki bugzilla css settings?
Jul 05 16:12:43 <sgw> halstead: more specificly can I do it and if so where?
Jul 05 16:15:20 <sgw> seebs: have you created the updated pseudo tarball?
Jul 05 16:15:34 <sgw> seebs: we need to get it into the downloads area
Jul 05 16:15:50 <seebs> Yes, and I already asked pidge to do that.
Jul 05 16:15:56 <seebs> I think it should be there already.
Jul 05 16:17:30 <sgw> seebs: hmm, maybe did not happen before she left, can you point me at the binary and I will get it there, I am getting a fetch failure
Jul 05 16:17:49 <seebs> ftp://ftp.windriver.com/pub/pseebach/pseudo-1.3.1.tgz <-- I think
Jul 05 16:20:35 <sgw> seebs: since you have it as a bz2 can you regenerate as a bz2 so I am not tainting it.
Jul 05 16:21:13 <fray> sgw -- usually pidge just gunzip / bzip2 the tarball.. you won't taint the tar archive then
Jul 05 16:21:55 <sgw> fray: would be great to get it in that format so we don't have to do the extra step in the future
Jul 05 16:21:55 <seebs> I should probably change pseudo's tarball rule to use bz2.
Jul 05 16:23:03 <sgw> seebs: hate to ask this, but how did you test the final recipe if the tarball was not there?
Jul 05 16:23:56 <sgw> seebs: for example now the checksums are not correct
Jul 05 16:25:47 <seebs> I think I tested it with git, and then modified the version-based recipe. I may have done this incorrectly.
Jul 05 16:26:16 <sgw> fray: have you seen the problem with multi-lib issue, and are you working on sorting it (as RP might say)
Jul 05 16:26:47 <sgw> seebs: I will expect a v2 that has been correctly updated.
Jul 05 16:26:59 <fray> sgw, what problem?
Jul 05 16:27:52 <seebs> Have you put the bz2 up so I can check the recipe against it?
Jul 05 16:27:54 <sgw> fray: I am sure I sent you email, onthe oe-core list about the changes you send (and we applied) that we are failing in multi-lib build on the AB
Jul 05 16:27:58 <sgw> seebs: yes
Jul 05 16:29:09 <sgw> fray: see http://autobuilder.yoctoproject.org:8010/builders/nightly-multilib/builds/143/steps/shell_23/logs/stdio
Jul 05 16:29:12 <fray> it wasn't tagged to me for some reason..
Jul 05 16:29:14 <fray> I found it though
Jul 05 16:30:01 <sgw> fray: failing rootfs not finding lib32-task-core-boot
Jul 05 16:30:30 <fray> from your log, that recipe's type isn't in the list being scanned by rpm
Jul 05 16:30:42 <fray> if it's not in the list, it's not available.. etc..
Jul 05 16:30:48 <fray> nothing i changed should have changed this behavior
Jul 05 16:33:26 <sgw> fray: I bisected it down to your change, so something in your change does change the behavior
Jul 05 16:34:25 <fray> taek out the inherit populate_sdk_base and see if that fixes it for you.. if so there is a class that I didn't find..
Jul 05 16:34:38 <fray> the locks have nothing to do with the processing, so they shouldn't be an issue..
Jul 05 16:35:40 <sgw> Ok, since I have the setup here I will try it.
Jul 05 16:36:49 <fray> I'm running a build now.. but it'll take a while..
Jul 05 16:36:56 <fray> I don't have any x86-64 multilib builds handy
Jul 05 16:37:02 <fray> (least none on oe-core master)
Jul 05 16:37:35 <kergoth> hmm
Jul 05 16:37:36 <kergoth> |   CC    qapi/qmp-registry.o
Jul 05 16:37:36 <kergoth> | cc1: error: unrecognised debug output level "0-march=i486"
Jul 05 16:37:47 * kergoth checks for missing spaces
Jul 05 16:42:13 <sgw> fray: confirmed, I have the build here, I commented out that inherit and it builds OK, but uncomment I can get the failure quickly.
Jul 05 16:42:53 <fray> ok.. so it's most likely a conflict w/ something in the populate_sdk_base
Jul 05 16:43:04 * fray goes to look for anything obvious
Jul 05 16:43:50 <fray> can you restore the inherit.. and then at the top of populate_sdk_base disable the two inherits?
Jul 05 16:43:59 <sgw> sure
Jul 05 16:44:05 <fray> I don't see anything obvious in the _base to cause this problem
Jul 05 16:44:38 <fray> nor in toolchain-scripts....
Jul 05 16:44:50 <fray> not in meta..
Jul 05 16:45:20 <fray> populate_sdk_rpm may have something...... looking further
Jul 05 16:45:22 <sgw> I guess I can just binary search through this, I will follow it down since I have the build available.
Jul 05 16:45:34 <sgw> seems that succeeded
Jul 05 16:47:10 <fray> populate_sdk_rpm and rootfs_rpm may have conflicting python () definitions... Hmm
Jul 05 16:47:25 <fray> I thought they were the same, but they're not
Jul 05 16:48:23 <sgw> fray: it is related to populate_sdk_rpm.bbclass
Jul 05 16:49:14 <fray> restore the inherits.. comment out the python () at the end of populate_rpm_base....
Jul 05 16:52:21 <sgw> fray, that's it
Jul 05 16:52:29 <sgw> fray: passed commented out.
Jul 05 16:53:10 <fray> ok...  What I suspect is needed is to remove that code from the _base version.. and then copy the corresponding chunk of code from rootfs_rpm into the populate_sdk.bbclass so it's available for the standalone SDKs..
Jul 05 16:53:24 <fray> I suspect this is all an artifact of the standalone SDKs not supporting mulitlibs properly..
Jul 05 16:53:51 <sgw> Ok, can you get a patch together, once you have a build the rootfs testing goes quickly (as you have seen).
Jul 05 16:54:06 <fray> ya.. will do..
Jul 05 16:54:19 <sgw> fray: I have other bugs to deal with!
Jul 05 16:58:05 <fray> Hmm.. not quite as easy as I was thinking..
Jul 05 16:58:09 <fray> still looking into it
Jul 05 17:16:24 <Crofton|work> so with linux-yocto-custom, can I just add a defconfig file and expect it to do the right thing?
Jul 05 17:16:31 <Crofton|work> and does it have device tree support
Jul 05 17:26:21 <sgw> msm: regarding your email and sed version, I am running on OpenSUSE 11.4 with sed v4.2.1
Jul 05 17:30:13 <Crofton|work> urg
Jul 05 17:30:22 <Crofton|work> how do I do FILESPATHPKG_prepend = "linux-usrp-e1xx-git:" in oe-core?
Jul 05 17:31:52 <seebs> sgw: I am apparently having a Bad Caffeine Day.  What is the URL I should be using for the pseudo tarball?
Jul 05 17:35:44 <kergoth> Crofton|work: oe-core never got the filespathbase/pkg/etc separation. you can directly modify filespath, or use filesextrapaths
Jul 05 17:36:46 <Crofton|work> FILESEXTRAPATHS = "linux-usrp-e1xx-git:" then
Jul 05 17:36:49 <sgw> seebs: the url in your recipe?
Jul 05 17:37:33 <seebs> That was what I thought, but I got 404 from www.yoctoproject.org/downloads/pseudo/pseudo-1.3.1.{tar.bz2,tbz2}
Jul 05 17:37:48 <seebs> Actually, what I got was a 302 that redirected to a 402.
Jul 05 17:37:48 <kergoth> Crofton|work: nope. grep for existing usage, that isn't how the variable works
Jul 05 17:37:50 <seebs> er, 404.
Jul 05 17:38:00 <Crofton|work> k
Jul 05 17:38:34 <sgw> seebs: .tar.bz2 as defined in your SRC_URI of the recipe, hmm it worked for me but gave me checksum issues
Jul 05 17:38:41 <seebs> Hmm.
Jul 05 17:39:39 <seebs> Huh. I get a 404, body text:
Jul 05 17:39:40 <seebs> The requested URL /releases/pseudo/pseudo-1.3.1.tar.bz2 was not found on this server.
Jul 05 17:42:33 <Crofton|work> kergoth, thanks lokos like I got it now
Jul 05 17:45:01 <msm> sgw: ill look at that
Jul 05 17:48:17 <bluelightning> damn it, mail-archive.com now has flash ads stitched into the messages themselves (!!!!)
Jul 05 17:48:24 <sgw> msm Ok
Jul 05 17:49:37 <sgw> seebs: wget  -t 2 -T 30 -nv --passive-ftp --no-check-certificate -P /tmp 'http://downloads.yoctoproject.org/mirror/sources/pseudo-1.3.1.tar.bz2'
Jul 05 17:49:37 <sgw> 2012-07-05 10:48:02 URL:http://downloads.yoctoproject.org/mirror/sources/pseudo-1.3.1.tar.bz2 [103797/103797] -> "/tmp/pseudo-1.3.1.tar.bz2.1" [1]
Jul 05 17:49:37 <sgw> sgw@yujin:/intel/poky2/builds/fetch$ echo $?
Jul 05 17:49:37 <sgw> 0
Jul 05 17:50:24 <sgw> seebs: I put it in the wrong place, just realized, let me fix it
Jul 05 17:50:59 <seebs> Ah, okay.
Jul 05 17:53:58 <sgw> seebs: I see what happened now, I put it in mirrors and Beth had installed the tgz file in the correct place, just not converted it to bz2 (which is why I asked for it in bz2 from you).
Jul 05 17:54:09 <seebs> Ahh!
Jul 05 17:54:10 <sgw> seebs: fixed now.
Jul 05 17:56:19 <seebs> thx, testing my update.
Jul 05 18:04:48 <halstead> sgw: I'll get you set up to tweak the bugzilla CSS.
Jul 05 18:14:24 <halstead> sgw, You can connect to bugzilla.yp and find the CSS in /var/www/bugzilla/skins/standard
Jul 05 18:16:54 <sgw> halstead: thanks, there was also a discussion on the oe-core list about list settings and replys, I know things have been working, but I wonder why that person is having issues.
Jul 05 18:17:41 <halstead> I'll try to locate the thread.
Jul 05 18:18:07 <sgw> I think it has util-linux in the subject in the last 48 hours or so
Jul 05 18:49:26 <msm> sgw: i tried the same command with sed 4.2.1 it's not failing… hmmm
Jul 05 19:12:53 <msm> sgw: nvm, i figured it out
Jul 05 19:12:56 <msm> v2 coming soon
Jul 05 19:19:31 <sgw> msm: what was it?
Jul 05 19:21:55 <msm> '/' in the variable subst
Jul 05 19:22:03 <msm> so i changed the sed delimeter to : instead
Jul 05 19:22:08 <msm> i don't know how I did not catch this
Jul 05 19:22:35 <msm> but i had your error, and this v2 fixed it
Jul 05 19:22:39 <msm> sgw: ^
Jul 05 19:25:51 <sgw> msm: thanks
Jul 05 20:10:49 <halstead> sgw, Is this the e-mail you were referring to http://lists.linuxtogo.org/pipermail/openembedded-core/2012-July/024998.html ?
Jul 05 20:32:42 <sgw> halstead: yes there were a couple more on that thread I think
Jul 05 21:28:18 <sgw> halstead: what drives the coloring of the bugzilla / wikimedia interfaces?
Jul 05 21:28:40 <sgw> fray: any news on the multilib patch?
Jul 05 21:29:54 <halstead> sgw, The bugzilla base skin and the mediawiki base theme are what we currently use as far as I know.
Jul 05 21:31:00 <halstead> sgw, We could copy these into custom skins/themes and modify from there.
Jul 05 21:31:53 <sgw> where is the mediawiki stuff, I want to change the minor to not be bold
Jul 05 21:32:24 <halstead> sgw currently on www.yoctoproject.org itself.
Jul 05 21:32:49 <halstead> sgw,  At /var/www/wiki.yoctoproject.org/wiki
Jul 05 21:33:54 <halstead> sgw, Specifically at /var/www/wiki.yoctoproject.org/wiki/skins/monobook/main.css
Jul 05 21:36:08 <halstead> sgw, or /var/www/wiki.yoctoproject.org/wiki/extensions/BugzillaReports/skins/bz_main.css for bugzilla included data.
**** ENDING LOGGING AT Fri Jul 06 02:59:58 2012

**** BEGIN LOGGING AT Fri Jul 06 02:59:58 2012
Jul 06 08:03:11 <awafaa> is there some sort of black magic needed to use 2 git trees for a kernel?
Jul 06 08:03:44 <awafaa> if i have 2 trees in my kernel.bb bitbake fraks out, if i disable one of them it happily builds
Jul 06 08:04:07 <awafaa> problem is i need the 2 as the second contains the .dts and .dtsi files
Jul 06 08:24:15 <Orre_> No idea. If you are happening to use local git repositories for your kernels, how do you specify their location at the SRC_REV?
Jul 06 08:51:02 <awafaa> i add a name= tag at the end. http://paste.opensuse.org/63590459 is my full .bb
Jul 06 08:56:18 <Orre_> You shouldn't use FILESDIR but FILESPATH AFAIK?
Jul 06 09:00:25 <bluelightning> morning all
Jul 06 09:00:47 <bluelightning> Orre_: FILESEXTRAPATHS
Jul 06 09:00:56 <bluelightning> if you're adding to it
Jul 06 09:02:19 <Orre_> good morning! awafaa was setting the FILESDIR in his bbappend and I think it should be FILESPATH in that case right?
Jul 06 09:03:36 <awafaa> so s/FILESDIR/FILESEXTRAPATHS/ ?
Jul 06 09:06:28 <bluelightning> should be FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}"
Jul 06 09:06:57 <bluelightning> well, you can change ${PN} to whatever subdirectory you wish to add
Jul 06 09:10:34 <awafaa> is there a description for all the variables available?
Jul 06 09:11:42 <bluelightning> awafaa: in the reference manual there is an appendix with a list of variables and descriptions, yes
Jul 06 09:13:24 <awafaa> bluelightning: most appreciated, thanks
Jul 06 09:13:31 <awafaa> oh and thanks Orre_ too :)
Jul 06 09:16:22 <Orre_> no worries, even if I maybe wasn't so helpful. :p
Jul 06 09:18:28 <awafaa> hmm, ok so if i read bitbake's error correctly my issue now is with parsing S
Jul 06 09:19:25 <awafaa> i currently have S = "${WORKDIR}/git", i've also tried S = "${WORKDIR}/${PN}-${PV}"
Jul 06 09:38:46 <bluelightning> awafaa: it must match where your source code gets extracted
Jul 06 09:39:40 <bluelightning> which is entirely dependent on whether the source code is being fetched from a git repo, or if it's a tarball what the structure of that tarball is
Jul 06 09:39:52 <awafaa> bluelightning: if i use only one git repo then S = "${WORKDIR}/git" works fine. my issue is when i add 2 repos
Jul 06 09:41:36 <bluelightning> awafaa: have you set destsuffix for each git URI? that will allow you to tell it to put each git repo in a separate dir
Jul 06 09:41:43 <bluelightning> (IIRC)
Jul 06 09:42:42 <awafaa> bluelightning: as in name= at the end of the git line?
Jul 06 09:43:10 <bluelightning> specified in a similar manner as name yes
Jul 06 09:50:46 <Orre_> btw, I would like to use a local git repository specified as SRC_REV="file:////path/settings/" or SRC_REV="/path/settings", though it demands me to currently use SRC_REV="git://path/settings" if to not throw any error.
Jul 06 09:51:15 <Orre_> Is there any way to get past this?
Jul 06 10:14:41 <bluelightning> Orre_: I think you want git:///path/settings;protocol=file
Jul 06 10:14:53 <bluelightning> Orre_: you may wish to look at externalsrc.bbclass as well
Jul 06 10:18:56 <awafaa> bluelightning: sorry, do you mean i have to set DESTDIR for each repo?
Jul 06 10:19:22 <bluelightning> awafaa: destdir, not DESTDIR... i.e.
Jul 06 10:19:38 <Orre_> bluelightning: As no hostname is specified then a normal clone with "git clone git:///path/settings;protocol=file" gives me "fatal: Unable to look up  (port 9418) (No address associated with hostname)". Using localhost isn't working as the firewall I think blocks connections through 9418.
Jul 06 10:19:43 <bluelightning> well, destsuffix
Jul 06 10:19:58 <bluelightning> SRC_URI = "git://git.firsturl.org;destsuffix=first \
Jul 06 10:20:09 <bluelightning>         git://git.secondurl.org;destsuffix=second"
Jul 06 10:20:46 <bluelightning> Orre_: I thought protocol=file was supposed to stop that; if it doesn't, then sorry I don't know
Jul 06 10:21:02 <bluelightning> Orre_: externalsrc.bbclass is one alternative at least
Jul 06 10:24:05 <Orre_> Trying to understand how to use externalsrc.bbclass but can't figure out how it would help? ${B}?
Jul 06 10:30:06 <awafaa> bluelightning: sorry to be a pita, but i'm not sure what i've done wrong here - http://paste.opensuse.org/67421427
Jul 06 10:55:32 <bluelightning> awafaa: so what does 'ls tmp/work/*/linux-*/' show ?
Jul 06 10:56:36 <bluelightning> this is a kernel recipe so I think it's supposed to handle S by itself
Jul 06 10:57:19 <bluelightning> Orre_: the idea is you inherit externalsrc in the recipe and then set S to point to your local source dir
Jul 06 10:58:36 <awafaa> bluelightning: it shows http://paste.opensuse.org/10256087 which to me shows only the source repo not the dts repo
Jul 06 11:01:19 <bluelightning> awafaa: it kind of looks like destsuffix is being ignored completely
Jul 06 11:01:42 <bluelightning> awafaa: which is not what the code I'm looking at suggests the behaviour should be... what version are you using again?
Jul 06 11:03:14 <awafaa> bluelightning: im https://wiki.linaro.org/KenWerner/Sandbox/OpenEmbedded-Core as my template and adding to it (my kernel mainly)
Jul 06 11:18:57 <bluelightning> awafaa: there's a mistake in that recipe - you have a continuation at the end of SRC_URI and then another SRC_URI = line below it
Jul 06 11:21:07 <awafaa> so i need to terminate after defconfig and add the second SRC_URI?
Jul 06 11:23:17 <bluelightning> awafaa: no, you just add the second URI on the next line without SRC_URI = " in front of it
Jul 06 11:23:20 <bluelightning> it's all one string
Jul 06 11:23:36 <bluelightning> or, it should be
Jul 06 11:24:49 <bluelightning> it will need a closing quote at the end, naturally
Jul 06 11:25:00 <awafaa> yup
Jul 06 11:25:49 <awafaa> ok that gets me further, still fails to build though "ERROR: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher failure: The SRCREV_FORMAT variable must be set when multiple SCMs are used"
Jul 06 11:26:17 <bluelightning> awafaa: right, so it's now telling you it needs you to tell it how to compose SRCPV given that multiple git repos are involved
Jul 06 11:27:07 <bluelightning> typically it's SRCREV_FORMAT = "name1_name2"
Jul 06 11:27:23 <bluelightning> which would mean you need to add ;name=something to each git URI
Jul 06 11:28:26 <awafaa> so after destsuffix= add name=, and add SRCREV_FORMAT = "name1_name2" ?
Jul 06 11:29:49 <bluelightning> awafaa: right
Jul 06 11:30:07 <bluelightning> (with a semicolon ; between)
Jul 06 11:30:54 <awafaa> awesome, thanks. that's hurdle one out of the way
Jul 06 11:31:47 <awafaa> my next hurdle is to work out how to cat the dtb onto the zImage
Jul 06 11:33:20 <awafaa> weird, it now errors out saying it can't make oldconfig, even though the defconfig is specified
Jul 06 11:33:39 <bluelightning> this is moving out of my area of expertise, I'm afraid...
Jul 06 11:34:03 <bluelightning> zeddii might be able to advise more ably than myself
Jul 06 11:34:04 <awafaa> this worked with a single git repo (source) but adding the dts repo is causing all sorts of issues
Jul 06 12:01:07 <Orre_> bluelightning: If I used a SSH clone of the repository (ssh://path/settings)  the localpath and basename are never set in __init__.py . If I inherit the externalsrc in the bbappend, remove the SRC_URI and set S to the path it will instead throw an error "Fetcher failure: SRCREV was used yet no valid SCM was found in SRC_URI" as there is no SRC_URI link to be added to the scm list and thereby the scm will be empty, which causes said exce
Jul 06 12:01:14 <Orre_> Any idea which way to go?
Jul 06 12:03:51 <Orre_> (when localpath & basename are never set they throw a AttributeError as rfind is attempted on None values)
Jul 06 12:08:22 <Orre_> Oh, and if you happen to know: how is Yocto using Buildbot?
Jul 06 12:24:06 <bluelightning> Orre_: yes we use buildbot for the autobuilder
Jul 06 12:24:31 <bluelightning> Orre_: does setting SRCREV="" help?
Jul 06 12:25:14 <bluelightning> I'm sorry I've never used externalsrc.bbclass but I do know it was designed to allow you to have your sources locally and be able to modify and build them from the same tree
Jul 06 12:28:00 <Orre_> bluelightning: No difference, you need to have a SRC_URI which can be split and checked if they can be used as a method to avoid the failure to be thrown. How does autobuilder use Buildbot? Is Yocto using the Buildbot's frontend, database and Yocto only doing the make by itself or does it only put Yocto's stuff into a BuildBot frontend?
Jul 06 12:28:34 <bluelightning> Orre_: I'm no expert but it seems to me we just use buildbot as a frontend
Jul 06 12:29:51 <Orre_> bluelightning: Oh right, that will make quite a few people over here quite sad. Is there someone I can get in touch with to get more information of how autobuilder uses Buildbot?
Jul 06 12:34:04 <bluelightning> Orre_: yes, our buildbot expert is Elizabeth Flanagan (nick "pidge" when she's on IRC)
Jul 06 12:34:10 <bluelightning> Orre_: she's on holiday atm though
Jul 06 12:34:27 <Orre_> bluelightning: When is she back?
Jul 06 12:35:57 <bluelightning> Orre_: some time next week I think
Jul 06 12:36:41 <Orre_> bluelightning: Cheers! :) About the issues with local repository or using SSH as protocol, whom should I ask about that?
Jul 06 12:37:03 <bluelightning> Orre_: probably something to just post to the mailing list I would imagine
Jul 06 12:38:04 <Orre_> bluelightning: I have some issues adding myself to the mailing lists, I never get any mail back after registering, have tried it twice and I don't seem to get any e-mail back - nor anything has come up in my spam folder neither.
Jul 06 12:38:26 <bluelightning> Orre_: which mailing lists are these, the yocto ones?
Jul 06 12:38:48 <Orre_> yes
Jul 06 12:40:19 <bluelightning> Orre_: email Michael Halstead ( michael at yoctoproject.org ) or talk to him here (nick: halstead) and he might be able to help trace the issue from our server end
Jul 06 12:45:18 <Orre_> bluelightning: Seem to been an mail issue, tried my hotmail address from many years back and it seem to worked now.
Jul 06 15:21:17 <msm> what's the situation with running tasks again that cause failures (on denzil)?
Jul 06 15:21:40 <msm> something like this:
Jul 06 15:21:40 <msm> https://gist.github.com/3060838
Jul 06 15:22:24 <msm> errr
Jul 06 15:22:29 <msm> nevermind, this is the recipe being bad
Jul 06 16:11:05 <khem> seebs: pseudo on arm :) is is intended to work ?
Jul 06 16:16:06 <seebs> Well, uhm.
Jul 06 16:16:15 <fray> I think it builds.. ;)
Jul 06 16:16:25 <seebs> I seem to recall that someone tried it and it worked on PPC.  It was definitely not planned/tested.
Jul 06 16:16:27 <fray> but until someone tries it and debugs it.. I wouldn't expect it to work yet
Jul 06 16:16:37 <fray> seebs, ahh maybe I'm thinking PPC then
Jul 06 16:16:49 <seebs> In theory, as long as the client and server agree on sizes, it probably SHOULD work.
Jul 06 16:19:01 <msm> it works on ppc32
Jul 06 16:19:03 <khem> no it does not build
Jul 06 16:19:03 <msm> not ppc64 atm
Jul 06 16:19:15 <msm> (unless that's been fixed at some point)
Jul 06 16:19:21 <khem> since it use -m32 and -m64 gcc options unconditionally
Jul 06 16:19:26 <khem> and those are not there on arm
Jul 06 16:19:40 <khem> it build on ppc,x86
Jul 06 16:19:42 <seebs> Ohhh
Jul 06 16:19:46 <khem> but not on arm and mips
Jul 06 16:19:55 <seebs> You know, I think I have patches sitting around for that, but never got them cleaned up.
Jul 06 16:20:09 <seebs> The "no -m32" thing is Oddly Familiar.
Jul 06 16:20:33 <khem> yeah you have to add knowledge of cross compilation and architecture to it
Jul 06 16:20:49 <khem> and may be you can pass some flags from env if you like
Jul 06 16:20:57 <khem> like ARCH= etc.
Jul 06 16:21:07 <khem> and take action in makefile accordingly
Jul 06 17:31:49 <bluelightning> fray: quick question - rpm with the -Uvh and --replacepkgs options is installing things at are already installed (since they're listed in the manifest); if I remove --replacepkgs nothing gets installed at all. Is there a happy medium where it will only add what's not already there?
Jul 06 17:32:22 <fray> that is actually what replacepkgs does
Jul 06 17:32:44 <fray> it shows status, but it doesn't acutally change what is installed -- other then validates it's on the disk as expected
Jul 06 17:34:49 <fray> best I can suggest is query the db.. and remove all entries that are already installed
Jul 06 17:35:03 <fray> (replace though can reset configuration files, which may not be what you want)
Jul 06 17:38:25 <bluelightning> fray: it appears to be reinstalling packages that are already installed though (like busybox)
Jul 06 17:38:34 <bluelightning> which is not really desirable
Jul 06 17:39:18 <bluelightning> maybe it's only verifying and re-running the postinsts, it's hard to tel
Jul 06 17:39:19 <bluelightning> tell
Jul 06 17:40:10 <fray> ya that is what it's doing.. (plus resetting configuration files)
Jul 06 18:24:52 <likewise> msm: Hi, can you explain how git://git.yoctoproject.org/meta-fsl-ppc and http://git.freescale.com/git/cgit.cgi/ppc/sdk/meta-fsl-ppc.git/  relate, or not?
Jul 06 18:26:10 <msm> i recently sent an email to the list explaining  this
Jul 06 18:26:36 <likewise> msm: I have a hard time finding out what layer branch corresponds to which yocto release. Ah ok, thanks, missed that one. Looking through the Yocto ML...
Jul 06 18:27:02 <msm> https://lists.yoctoproject.org/pipermail/yocto/2012-July/009936.html
Jul 06 18:27:03 <likewise> msm: A btter place would be the README (or RELEASE) I think
Jul 06 18:29:09 <likewise> msm: one regression I have is that the Silicon Image PCIe SATA controller doesn't work anymore on the Yocto meta-fsl-ppc.git. on P2020RDB.   So I was looking for more recent trees first, before I start dissecting or debugging myself.
Jul 06 18:29:36 <likewise> hi flo_lap , eh florian :)
Jul 06 18:29:54 <msm> likewise: sounds like an linux issue ;)
Jul 06 18:30:35 <likewise> msm: yes, so I wanted to figure out what FSL uses as their most recent Linux kernel. I would like to stick with FSL "tested" kernels as closely as possible.
Jul 06 18:31:00 <likewise> msm: I fixed that SATA controller like five times in the last year, on Freescale...
Jul 06 18:31:05 <florian> re
Jul 06 18:31:08 <florian> hey likewise
Jul 06 18:32:04 <florian> likewise: heh... so I now who to ask about it ;) I have a TX53 with LVDS/SATA adapter on my desk and wondered what would be involved to make use if SATA :-)
Jul 06 18:32:37 <likewise> florian: i.MX53 has SATA on-chip.
Jul 06 18:32:47 <florian> likewise: yep
Jul 06 18:33:11 <florian> likewise: the referencde baseboard for that TX53 does not have SATA
Jul 06 18:33:16 <likewise> florian: ah
Jul 06 18:33:32 <likewise> florian: I use the FSL i.MX53 QSB, it has.
Jul 06 18:33:37 <florian> but they made an adapter for LVDS and SATA... looks a little bit scary :)
Jul 06 18:33:58 <likewise> msm: Is the SDK version older / newer than what's being done in the Yocto layer?
Jul 06 18:34:07 <florian> cute little board... only the usb+ethernet plug is ugly
Jul 06 18:35:18 <likewise> florian: yes, apparantly a tower stack was chosen because of board space...
Jul 06 18:36:01 <msm> git.freescale.com version is the forked verion that works for our SDK release
Jul 06 18:36:15 <msm> its older or newer depending on the day
Jul 06 18:36:31 <likewise> msm: ok, thanks
Jul 06 18:36:31 <msm> its likely to start to get older from here on out as we refcous on upstream for the time being
Jul 06 18:36:49 <msm> but its also more likely to work
Jul 06 18:37:11 <likewise> msm: ok, with upstream you mean upstream kernel also?
Jul 06 18:37:37 <msm> same basically applies to the kerne
Jul 06 18:37:45 <msm> the kernel on git.freescale.com is v3.0
Jul 06 18:37:48 <msm> so its already old
Jul 06 18:37:56 <msm> it just has stuff the upstream one does not
Jul 06 18:38:02 <likewise> msm: as always :)
Jul 06 18:38:28 <msm> the yocto/oe-core situation is really the same as the kernel situation as well
Jul 06 18:38:30 <likewise> msm: If I tell the libata guys that the Sil3124 doesn't work for PPC Linux 3.0, zero chance for support.
Jul 06 18:38:35 <msm> although a lot less dramatic
Jul 06 18:38:53 <msm> use an upstream kernel then ;)
Jul 06 18:39:13 <likewise> msm: likely something else breaks, but I will.
Jul 06 18:39:32 <likewise> msm: last known good is my OpenEmbedded Classic / Core 2.6.35 version....
Jul 06 18:39:52 <msm> if you use the freescale tree, you can likely ask freescale for support
Jul 06 18:40:12 <likewise> msm: ok, and that's based off Yocto 1.1.1, right?
Jul 06 18:40:17 <msm> yea
Jul 06 18:41:03 <likewise> msm: how can I find out which Yocto version is used? (I think I found a presentation mentioning it, but I couldn't find it documented)
Jul 06 18:42:23 <likewise> msm: I found distro.conf: DISTRO_NAME = "Yocto (Built by Poky 6.0)"   -- That should be it.
Jul 06 18:44:43 <msm> or just look at the git history/tags
Jul 06 18:45:03 <msm> its actually an abberation
Jul 06 18:45:08 <msm> its 1.1.1 + most of 1.1.2
Jul 06 18:56:40 <likewise> florian: we designed a FPGA add-on board for the cute i.MX53: http://www.lancero.eu.com/trisendo-video-board/
Jul 06 18:58:57 <florian> likewise: nice
Jul 06 18:59:36 <florian> likewise: oh... this looks like quite some throughput
Jul 06 19:00:24 <likewise> florian: what interface you mean?
Jul 06 19:00:34 <likewise> florian: you mean you are testing SATA?
Jul 06 19:01:18 <florian> likewise: heh no... the twelve lvds lines mostly
Jul 06 19:01:58 * florian is at a local hacker meeting and left the freescales at home
Jul 06 19:03:41 <florian> right now I'm trying to convince quemu to get me a flexible emulation for all sorts of screen sizes on an arm9 cpu
Jul 06 19:04:01 <likewise> florian: so you can use the LVDS lines directly from the i.MX53 IPU? or how can you access them? Instead of the SATA?
Jul 06 19:04:27 <likewise> florian: that would be useful on qemu indeed
Jul 06 19:05:31 <florian> likewise: lvds... not sure, would have to check with the *cough* manual. but the combination with sata is likely to be a random one - just one adapter for two missing interfaces on the baseboard
Jul 06 19:06:25 <florian> likewise: the easiest solution I found was to hack the clcd driver :-)
Jul 06 19:09:48 <likewise> florian: not sure what you mean? You hacked the LVDS IPU display port driver of the i.MX53?
Jul 06 19:11:10 <likewise> florian: never mind, I am confusing our two discussions (LVDS/SATA versus QEMU). I get it now.
Jul 06 19:32:51 <likewise> bluelightning: hi there
Jul 06 20:30:07 <Crofton|work> anyone familair with linux-dtb.inc?
Jul 06 21:53:31 <khem> msm: I am building an image using meta-fsl-ppc on top of poky/master seems to be progressing after those 3 patches I posted
Jul 06 21:59:36 <bluelightning_> hi likewise, khem
Jul 06 21:59:46 <khem> hello bluelightning
Jul 06 22:00:56 <likewise> hi khem, bluelightning
Jul 06 22:01:05 <khem> likewise: howdy
Jul 06 22:01:08 <khem> long time
Jul 06 22:01:23 <likewise> yeah, learning systemverilog programming for a change :)
Jul 06 22:01:47 <khem> hmm cool
Jul 06 22:01:50 <likewise> although I got a lot of OpenEmbedded projects going and coming up.
Jul 06 22:02:02 <khem> thats good news :)
Jul 06 22:02:31 <khem> OE has come of age now. its quality stuff
Jul 06 22:03:40 <likewise> It's more stable, reliable, but mixing layers can be a challenge
Jul 06 22:03:57 <khem> hmm yes, something to look out for always
Jul 06 22:04:33 <khem> I have some plans to put for some testing of lot of layers kind of integration stuff
Jul 06 22:04:43 <khem> angstrom is good point to start
Jul 06 22:04:55 <khem> only if I have time
Jul 06 22:06:15 <likewise> Intel should ask you to work for Yocto (hint). ;)
Jul 06 22:07:22 <khem> heh,
Jul 06 22:08:21 <likewise> I find myself submitting less and less to OpenEmbedded, simply because the stuff is more stable, and I am mostly a OE user rather than OE developer these days.
Jul 06 22:08:43 <khem> lot of credit goes to yocto
Jul 06 22:09:00 <likewise> likewise: I remember in the past (2005+) I always had to add new recipes and versions because stuff was missing that we needed in Embedded devices.
Jul 06 22:10:03 <khem> true
Jul 06 22:11:02 <khem> now in OE-Core you can do bitbake world and it works
Jul 06 22:15:52 <msm> khem: i plan on apply those
Jul 06 22:15:57 <msm> khem: im just busy on denzil at the moment
Jul 06 22:16:04 <khem> msm: cool.
Jul 06 22:16:23 <khem> msm: I will let you know how it goes.
Jul 06 22:16:41 <khem> btw. are there any fsl specific gcc/eglibc patches you are having ?
Jul 06 22:16:47 <msm> for master?
Jul 06 22:16:50 <msm> not yet...
Jul 06 22:17:01 <msm> we dont have stuff for denzil yet either
Jul 06 22:17:09 <msm> waiting for folks to provide those patches to me
Jul 06 22:18:53 <sgw> msm: khem: so what's the deal with libgomp, is there closure on that one, will there be a v2?
Jul 06 22:19:24 <khem> sgw. I think its ok
Jul 06 22:19:46 <khem> sgw: keep an eye on say non ppc build if it complains about empty packages
Jul 06 22:19:54 <sgw> khem: the original as it stands or after the tweak you suggested?
Jul 06 22:20:15 <sgw> khem, I will built it out with the eglibc set over the weekend then.
Jul 06 22:20:33 <khem> original
Jul 06 22:21:14 <khem> msm: master would be interesting. We are using gcc 4.7 there
Jul 06 23:28:50 <MysticPxW> hi... I'm still trying to figure out how exactly yocto handles staging of dynamic libraries between packages, no matter what I do I keep getting "undefined reference" errors from my application code
Jul 06 23:29:35 <MysticPxW> the issue is that the dynamic libs are in another package - which I have built previously
Jul 06 23:30:48 <MysticPxW> and if I search for them in the tmp/ tree of my yocto build dir, I find them in tmp/sysroots/imx233-olinuxino-maxi/lib
Jul 06 23:31:18 <MysticPxW> but I just can't seem to get the cross-compiler to find them to use during the app package compile
Jul 06 23:31:54 <MysticPxW> I know the solution to this in the older versions of OE was to use the "staging" directory and copy the libs there so other packages would use them
Jul 06 23:32:09 <MysticPxW> and now that doesn't seem to exist
Jul 06 23:32:23 <MysticPxW> so I'm kind of at a loss here, any pointers would be appreciated
Jul 06 23:35:04 <MysticPxW> do I need to create a .la file for my library or something like that? seems to be a lot of those in the usr/lib output dir
Jul 06 23:37:03 <MysticPxW> I'm trying to look at existing packages to see how they do it, but most all of them use autotools (and I don't) so it's hard to compare
Jul 06 23:39:48 <kergoth> MysticPxW: sysroot *is* staging.
Jul 06 23:40:00 <kergoth> .la files are useless and unnecessary, adn buy you nothing
Jul 06 23:41:28 <MysticPxW> kergoth: ok, but if the dynamic lib files are there why can't bitbake see them?
Jul 06 23:43:39 <kergoth> "bitbake" sees them just fine.
Jul 06 23:43:53 <kergoth> you just aren't ensuring your project's buildsystem is obeying the metadata variables like CC, CFLAGS, and LDFLAGS
Jul 06 23:43:54 <MysticPxW> ok ok ok I mean the cross-compiler
Jul 06 23:46:00 <MysticPxW> well do I have to add anything to those? I mean in the recipe, the final link line in do_compile() is
Jul 06 23:46:01 <MysticPxW> ${CC} ${CFLAGS} ${LDFLAGS} -lmylib -lm
Jul 06 23:46:01 <MysticPxW>         ${WORKDIR}/utils/log4c.o \
Jul 06 23:46:01 <MysticPxW>         ${WORKDIR}/drivers/serial.o \
Jul 06 23:46:01 <MysticPxW> 		...
Jul 06 23:46:01 <MysticPxW> 		${WORKDIR}/main-app.o -o main-app
Jul 06 23:46:31 <MysticPxW> and this worked on an older version of the OE build tree
Jul 06 23:47:26 <kergoth> that will work just fine, and does for everyone else
Jul 06 23:48:16 <MysticPxW> so I can see what that expands to in the log.do_compile
Jul 06 23:48:36 <MysticPxW> and the only relevant option it appears to feed the compiler is the --sysroot=
Jul 06 23:51:19 <MysticPxW> and this seems like it should work, and the library feature was added in ld v2.16 but I'm using v2.20.x so w/e
Jul 06 23:57:51 <MysticPxW> do I possibly need a .a format instead? reading the gcc docs seems to indicate that
Jul 07 00:09:22 <MysticPxW> well now if I specify the libxx.so files explicitly in the recipe link step, it at least avoids those errors
Jul 07 00:09:55 <MysticPxW> seems that the -l option just no longer actually works the way it used to...
**** ENDING LOGGING AT Sat Jul 07 02:59:58 2012

**** BEGIN LOGGING AT Sat Jul 07 02:59:58 2012
Jul 07 07:43:36 <kishore> hello
Jul 07 07:43:55 <kishore> am new to yocto and facing build errors
Jul 07 07:44:18 <kishore> Summary: 2 tasks failed:   /home/kishore/project/yocto/poky-denzil-7.0/meta/recipes-devtools/gcc/gcc-cross-initial_4.6.bb, do_configure   virtual:native:/home/kishore/project/yocto/poky-denzil-7.0/meta/recipes-devtools/elfutils/elfutils_0.148.bb, do_compile Summary: There was 1 WARNING message shown. Summary: There were 2 ERROR messages shown, returning a non-zero exit code. kishore@kishore-workststion:~/project/yocto/poky-denzil-7.
Jul 07 07:44:30 <kishore> could someone help?
Jul 07 07:44:42 <kishore> iam on ubuntu 10.10
Jul 07 12:01:04 <Crofton|work> RP, you touched the code that messes with thsi last :)
Jul 07 12:01:06 <Crofton|work> ERROR: kernel-devicetree is listed in PACKAGES multiple times, this leads to packaging errors.
Jul 07 15:24:14 <Crofton> ah linux-dtb was also included by linux-yocto.inc
Jul 07 19:03:02 <JaMa|Off> khem: hi.. gcc from git is good idea, but +git in PV sorts lower then +svn.. so rootfs fails with a lot of unsatisfied libgcc1 (>= 4.7.1+svnr188658) * libstdc++6 (>= 4.7.1+svnr188658)
Jul 07 20:10:50 <khem> JaMa|Off: hmm
Jul 07 20:11:03 <khem> JaMa|Off: I dont think we can do much there
Jul 07 20:11:40 <khem> will removing +{$SRCPV} completely help ?
Jul 07 20:12:07 <JaMa|Off> no, but we can bump PE or wait with switch to git for 4.7.2
Jul 07 20:12:26 <JaMa|Off> I've rebuild about 100 packages already to fix rootfs
Jul 07 20:12:46 <khem> hmmm
Jul 07 20:12:53 <khem> I dont like PE
Jul 07 20:14:08 <JaMa|Off> neither do I
Jul 07 20:15:09 <khem> and putting SRCPV in PV is not good atleast for kind of releases gcc has
Jul 07 20:15:41 <khem> I wish it was zit and not git
Jul 07 20:15:47 <khem> then problem was solved
Jul 07 20:15:49 <khem> :)
Jul 07 20:16:17 <JaMa|Off> cannot we stay with svn until 4.7.2 is released and then switch with PV increment?
Jul 07 20:21:01 <pinskia> GCC does have a git ...
Jul 07 20:36:07 <JaMa|Off> khem: complete list of recipes which need rebuild (PR bump) after gcc "downgrade" - http://pastebin.com/daAKd57p and it still doesn't fix upgrade path for gcc target packages themselves
**** ENDING LOGGING AT Sun Jul 08 02:59:58 2012

**** BEGIN LOGGING AT Sun Jul 08 02:59:59 2012
Jul 08 17:01:47 <khem> :
Jul 08 22:51:19 <msm> sgw: any reason why i did not see those QA errors?
Jul 09 02:59:29 <sgw> msm: they might have shown up as WARNINGS, I have a patch to get ERRORS, so I can find those kind of regressions. Also multiple builds on multiple arches, not sure why you did not see them.
Jul 09 02:59:52 <msm> ah, WARN -> ERROR explains it
**** ENDING LOGGING AT Mon Jul 09 02:59:58 2012

**** BEGIN LOGGING AT Mon Jul 09 02:59:58 2012
Jul 09 03:02:41 <sgw> msm: this is bad, what are we doing working on a Sunday evening!
Jul 09 03:04:09 * sgw flees again, will publish a consolidated pull for RP to peruse later
Jul 09 04:15:07 <msm> sgw: im just reading your email ;) not going to fix it until later ;)
Jul 09 06:10:12 <ciupicri> tomz1, is it to me or you're sending patches (to open-embedded) in the weekend, too?
Jul 09 08:20:42 <bluelightning> morning all
Jul 09 08:38:57 <RP> morning all
Jul 09 08:43:26 <florian> good morning
Jul 09 08:47:37 <bluelightning> hi RP, florian
Jul 09 13:51:11 <awafaa> could someone explain what http://paste.opensuse.org/98848504 means please?
Jul 09 13:54:59 <RP> awafaa: PATH in your environment contains "." or and empty section
Jul 09 13:56:55 <awafaa> RP: yes but what PATH in which environement? my workstation works fine but my laptop refuses to erroring with the above
Jul 09 13:59:43 <RP> awafaa: PATH set in your default shell
Jul 09 14:00:01 <RP> awafaa: try running "echo $PATH"
Jul 09 14:02:34 <bluelightning> opensuse helpfully includes . by default :/
Jul 09 14:04:18 <JaMa> time to install /tmp/ls -> /bin/rm there by default too :)
Jul 09 14:06:55 <bluelightning> heh, quite
Jul 09 14:07:38 <rburton> bluelightning: . by default? that's stupid.
Jul 09 14:07:49 <bluelightning> rburton: yes, it is :/
Jul 09 14:08:17 <rburton> i might make a new sj release and ship a "ls" in the tarball that does rm -rf ~/
Jul 09 14:09:32 <rburton> awafaa: another good reason not to use suse ;)
Jul 09 14:33:16 <RP> rburton: You can understand why bitbake just complains loudly and exits when it notices this ;-)
Jul 09 14:42:29 <awafaa> strange as it all worked fine until i did a re-install to encrypt the hard drive (same release etc)
Jul 09 14:43:38 <awafaa> rburton: if fedora used zypper i would consider it
Jul 09 14:43:52 <rburton> you can install zypper on fedora, can't you?
Jul 09 14:43:59 <rburton> anyway, they both suck arse
Jul 09 14:44:04 <rburton> zypper just sucks quicker
Jul 09 14:44:33 <awafaa> rburton: go on then what pray tel does squire recommend?
Jul 09 14:44:40 * xxiao wonders why people use redhat :)
Jul 09 14:44:41 <awafaa> err tell even
Jul 09 14:44:44 <rburton> awafaa: debian, obviously ;)
Jul 09 14:45:13 <awafaa> ok so how do i remove . from my path?
Jul 09 14:45:21 <rburton> awafaa: find out what puts it there, and remove it
Jul 09 14:45:29 <rburton> from what bluelightning said, something in /etc
Jul 09 14:45:33 <rburton> i'd start with /etc/profile
Jul 09 14:46:32 <bluelightning> temporarily you can always export PATH="...path with . removed..."
Jul 09 14:47:06 <rburton> you might also have a double-colon sequence
Jul 09 14:47:39 <rburton> which is also bad and needs to be removed, but also harder to find as it's normally there accidentely when extending PATH
Jul 09 14:49:27 <awafaa> well something has added it as by default . isnt included in $PATH
Jul 09 14:49:33 <awafaa> checked on 3 other systems
Jul 09 14:49:37 <rburton> is there a :: sequence?
Jul 09 14:50:02 <rburton> probably good to paste your $PATH where bitbake moans
Jul 09 14:50:26 <awafaa> not that i can see
Jul 09 14:56:49 <awafaa> um, not entirely sure what happened, but after rebooting due to a kernel upgrade everything works now
Jul 09 14:57:12 <rburton> maybe that terminal got a trashed $PATH in?
Jul 09 14:57:34 <rburton> i expect to see a retraction on twitter :)
Jul 09 15:38:45 <awafaa> rburton: my public statement stands ;) im still trying to get a custom dt kernel built and that is confounding me somewhat
Jul 09 16:02:41 <zeddii_home> sgw's consolidated pull has broken all my clients. so odd.
Jul 09 16:04:22 <sgw> zeddii_home: how so?
Jul 09 16:04:37 <sgw> Is it packaging related?
Jul 09 16:04:55 <zeddii_home> only half got delivered to my windriver address, and none to my gmail. I have no idea where they went! I see 3 or 5 and Ross' reply .. but nothing else.
Jul 09 16:05:10 <zeddii_home> I'm blaming crappy infrastructure.
Jul 09 16:05:31 <rburton> zeddii_home: the second half of it just arrived in my gmail
Jul 09 16:06:00 <zeddii_home> I got a grand total of zero. i have no idea what's going on. My only heads up is RPs reply and yours.
Jul 09 16:06:10 <fray> zedd_ii I got them all
Jul 09 16:06:14 <fray> so it jut you.. ;)
Jul 09 16:06:25 * zeddii_home dislikes flaky email.
Jul 09 16:07:08 <zeddii_home> aha
Jul 09 16:07:16 <zeddii_home> sgw: my google thinks you are a spammer.
Jul 09 16:07:25 <bluelightning> fray: just wondering what to do with TOOLCHAIN_TARGET_TASK_ATTEMPTONLY with my rework - those package groups no longer exist (installing those is handled later on) - any suggestions?
Jul 09 16:07:31 <zeddii_home> quit selling me that 'stuff'
Jul 09 16:07:55 <bluelightning> zeddii_home: but it's really shiny... :)
Jul 09 16:08:02 <zeddii_home> hehe
Jul 09 16:08:50 <zeddii_home> and this explains why I only saw half the perf email.
Jul 09 16:08:51 <zeddii_home> #@$
Jul 09 16:09:00 <sgw> zeddii_home: great just what I need
Jul 09 16:31:14 <bluelightning> sgw / RP: re bug 2531, do we want staticdev packages to be installed in all/some of the -sdk images by default?
Jul 09 16:32:16 <RP> bluelightning: good question. We used to have that before we split things out into staticdev. I guess we probably should be default for now? or should be make a conscious decision not to?
Jul 09 16:32:53 <bluelightning> RP: I guess I'm not entirely clear on why staticdev packages were split out in the first place...
Jul 09 16:34:13 <sgw> bluelightning: finer gain control and space although for -sdk images they are pretty large.
Jul 09 16:34:38 <bluelightning> sgw: given that, any opinions on the above then?
Jul 09 16:34:39 <sgw> bluelightning: RP: should it be a flags to enable it not everyone needs/wants static libraries?
Jul 09 16:35:01 <bluelightning> sgw: I've created another IMAGE_FEATURES item (staticdev-pkgs)
Jul 09 16:35:05 <sgw> bluelightning: maybe jzhang needs to weigh in from the tools side.
Jul 09 16:35:15 <bluelightning> sgw: the question is should we be providing that by default anywhere
Jul 09 16:35:29 <bluelightning> if yes, I'll do it, if not, great, I don't need to do anything more ;)
Jul 09 16:35:58 <sgw> bluelightning: ah the IMAGE_FEATURES sounds right, let me review where the bug was from again.
Jul 09 16:36:12 <sgw> and yes a bug bot would be great in here just about now!
Jul 09 16:36:20 <sgw> halstead: hint hint ^^^^
Jul 09 16:36:21 <bluelightning> https://bugzilla.yoctoproject.org/show_bug.cgi?id=2531
Jul 09 16:38:10 <sgw> bluelightning: I would do a quick poll on the community unless jzhang has a strong opinion one way or the other, you might be done with the I_F bits and let it be a distro policy
Jul 09 16:46:12 * jzhang just got in, road work, catching up the thread
Jul 09 16:46:12 <halstead> sgw, Would the bot help in this case by having announced recent activity?
Jul 09 16:48:09 <jzhang> bluelightning, sgw: I don't think we need it by default as long as we can easily turn it on with IMAGE_FEATURE
Jul 09 16:49:15 <sgw> halstead: no I am thinking about a bot that auto-links bugzilla numbers (if that is even possible), I thought I heard about that before
Jul 09 16:49:21 <bluelightning> ok, noted
Jul 09 16:49:23 <sgw> jzhang: thanks for the input
Jul 09 16:49:25 <bluelightning> we can always change our minds later
Jul 09 16:49:41 <bluelightning> fray: ping
Jul 09 16:50:12 <RP> bluelightning: I'm leaning towards not having it by default - keep the sdk smaller
Jul 09 16:50:23 <bluelightning> RP: ok
Jul 09 16:50:35 <RP> bluelightning: it is (now) easily enabled
Jul 09 16:51:48 <halstead> sgw, There is a plugin that would follow links to bugs, look up the description, and how many times it's been mentioned. It shouldn't be too hard to make it try to format any integer as a bugzilla link and check if it leads to an open bug.
Jul 09 16:58:51 <RP> halstead: Can that plugin also search bugzilla and return the results as a private message?
Jul 09 16:58:58 <RP> halstead: I seem to remember one that could...
Jul 09 17:04:18 <Crofton|work> Tracey outght to read the oe-core/yocto lists to get an idea of how people new to the project use the word "Yocto"
Jul 09 17:04:58 <halstead> RP, I'll check. I'm looking at this plugin  http://code.google.com/p/supybot-bugzilla/
Jul 09 17:05:39 <sgw> fray: you around, a couple questions for you 1) patches that require Upstream-Status 2) SDK changes for dep and ipk roots?
Jul 09 17:05:55 <onoffon> i am trying to package kernel sdk and i need to ship prebuilt host tools under scripts dir
Jul 09 17:06:48 <onoffon> i know we now have kernel-dev package which cant take cross bins
Jul 09 17:07:24 <onoffon> so we prune them
Jul 09 17:07:32 <onoffon> but i need it
Jul 09 17:50:35 <khem> zeddii: newer kernels are adding more and more tooling and we strip the tools now from kernel-dev
Jul 09 17:51:06 <khem> zeddii: I am wondering if its possible that we can install these tools in bin dir on SDK
Jul 09 17:51:19 <khem> can kernel build system use it from there ?
Jul 09 17:51:25 <khem> when building external mods
Jul 09 17:51:59 <khem> zeddii: this is cross building the module not on device module builds
Jul 09 17:52:05 <Crofton|work> khem, is gcc from oe-core any good for cortex-a9? or is there something better to use?
Jul 09 17:52:21 <khem> Crofton|work: yes it should be pretty good
Jul 09 17:52:47 <Crofton|work> is rpm default for oe-core?
Jul 09 17:52:51 <khem> Crofton|work: you can alternatively use gcc 4.7 from meta-linaro
Jul 09 17:53:06 <Crofton|work> and if so, what is the command to see what rpms are on the rootfs ....
Jul 09 17:53:07 <khem> Crofton|work: no its opkg
Jul 09 17:53:29 <Crofton|work> for some reason I have rpm not opkg
Jul 09 17:53:38 <Crofton|work> and rpm -qa returns nothing
Jul 09 17:53:40 <khem> so you must be using yocto/poky
Jul 09 17:53:44 <Crofton|work> np
Jul 09 17:53:45 <Crofton|work> no
Jul 09 17:53:47 <Crofton|work> oe-core
Jul 09 17:53:52 <khem> hrmm
Jul 09 17:53:56 <Crofton|work> no meta-yocto
Jul 09 17:54:06 <khem> its pure OE-Core ?
Jul 09 17:54:16 <Crofton|work> + my bsp
Jul 09 17:55:08 <khem> what does PACKAGE_CLASSES is local.conf look like ?
Jul 09 17:55:22 <zeddii_home> khem: when doing external module builds it makes sense to have the scripts/tools available, I had to save more for perf recently.
Jul 09 17:55:51 <khem> zeddii: It was Derren's changes which screwed me totally
Jul 09 17:56:16 <khem> I think for intent to package it for target now we run _mrproper_scripts
Jul 09 17:56:21 <Crofton|work> looks liek the ipk choice
Jul 09 17:56:31 <Crofton|work> PACKAGE_CLASSES ?= "package_ipk"
Jul 09 17:56:44 <khem> Crofton|work: then you should have ipk for OPM
Jul 09 17:56:44 <zeddii_home> khem: that's what I was just checking
Jul 09 17:56:51 <Crofton|work> this is oe-core configured by the oe-initi script
Jul 09 17:56:55 <zeddii_home> so it was darren's recent changes. hmm.
Jul 09 17:56:57 <Crofton|work> from oe-core
Jul 09 17:57:03 <khem> zeddii_home: yes
Jul 09 17:57:04 <Crofton|work> well
Jul 09 17:57:14 <Crofton|work> experieince suggets otherwise :)
Jul 09 17:57:17 <kergoth> damnit, bitbake is really confused, claiming this recipe emits a runtime package that it doesn't
Jul 09 17:57:20 <kergoth> hmm
Jul 09 17:57:29 <khem> zeddii_home: so now my option is to copy the tree before its munged
Jul 09 17:57:48 <khem> Crofton|work: what does opkg list installed shows ?
Jul 09 17:58:22 <zeddii_home> can we just restore the tools to the -dev package ? I'm looking at his change now from that angle.
Jul 09 17:58:23 <khem> zeddii_home: we have two use cases one it for on device module builds and one is cross module builds
Jul 09 17:58:40 <khem> zeddii: packages cant contain cross-arch components
Jul 09 17:58:57 <zeddii_home> aha. yes.
Jul 09 17:58:59 <khem> zeddii: these tools are built for host machine as you know
Jul 09 17:59:17 <Crofton|work> opkg not on image
Jul 09 17:59:18 <khem> we can make an exception but I dont think that will fly
Jul 09 17:59:45 <Crofton|work> weird weird
Jul 09 17:59:53 <khem> Crofton|work: bitbake -e <your_image> | grep -e "^PACKAGE_CLASSES"
Jul 09 17:59:59 <zeddii_home> but we do need to be able to build out of tree modules on the host with the tools. that's a primary use case for me as well.
Jul 09 18:00:00 <Crofton|work> jsut did
Jul 09 18:00:01 <zeddii_home> hmmm
Jul 09 18:00:10 <Crofton|work> PACKAGE_CLASSES="package_ipk"
Jul 09 18:00:24 <Crofton|work> Maybe I'll try nuking it and trying again
Jul 09 18:01:28 <Crofton|work> where are the opkg log files stored in the image?
Jul 09 18:03:21 <Crofton|work> looks like it is made from ipks, but opkg not installed
Jul 09 18:03:26 <Crofton|work> and rpm is installed
Jul 09 18:08:13 <khem> Crofton|work: so you probably disable OPM
Jul 09 18:08:23 <Crofton|work> hmm
Jul 09 18:08:41 <Crofton|work> I did this by copying core-image and adding some stuff
Jul 09 18:09:01 <khem> IMAGE_FEATURES += "package-management"
Jul 09 18:09:05 <khem> and you must be set
Jul 09 18:09:14 <khem> or better IMAGE_FEATURES_pn-<yourimage>
Jul 09 18:09:16 <Crofton|work> ah
Jul 09 18:09:20 <Crofton|work> ok
Jul 09 18:09:25 <Crofton|work> that makes sense
Jul 09 18:09:39 <Crofton|work> still weird rpm ends up in the image
Jul 09 18:09:54 <Crofton|work> I think I remember this coming up on the list
Jul 09 18:09:59 <bluelightning> Crofton|work: it's really in the image?
Jul 09 18:10:03 <bluelightning> or just built?
Jul 09 18:10:10 <khem> yes thats strange but you must have messed up something
Jul 09 18:10:14 <Crofton|work> you are not asking some newbie :)
Jul 09 18:10:23 <bluelightning> I ask because it's very unusual
Jul 09 18:10:36 <Crofton|work> root@sekrit:/var/lib/opkg# rpm
Jul 09 18:10:36 <bluelightning> so I want to be sure I understand correctly...
Jul 09 18:11:41 <Crofton|work> seriously the image is made from ipks, but imcludes rpm in the image
Jul 09 18:11:59 <bluelightning> Crofton|work: does 'bitbake -e | grep rpm' show anything interesting?
Jul 09 18:13:10 <msm> sgw: did you miss my cramfs_cvs fix?
Jul 09 18:13:35 <msm> sgw: nevermind, that's meta-oe
Jul 09 18:14:33 <Crofton|work> bluelightning, nothing jumps out
Jul 09 18:15:30 <bluelightning> Crofton|work: hmm, well one approach would be to enable buildhistory and then look at the depgraphs that get produced
Jul 09 18:15:54 <Crofton|work> yeah, I seem to remember this coming up already
Jul 09 18:15:57 <bluelightning> https://wiki.yoctoproject.org/wiki/Buildhistory
Jul 09 18:17:30 <Crofton|work> thanks, I need to sort out what dragon to slay next :)
Jul 09 18:18:02 <bluelightning> ok... I'm heading home but will be back on later
Jul 09 18:18:12 <bluelightning> I'm interested to hear the end of this mystery... :)
Jul 09 18:22:29 <khem> zeddii_home: http://paste.ubuntu.com/1083216/
Jul 09 18:22:37 <khem> zeddii_home: thats something we can live with
Jul 09 18:26:58 <zeddii_home> khem: I recall RP didn't want the entire kernel in the sys root.
Jul 09 18:27:18 <khem> its not entire kernel
Jul 09 18:27:26 <khem> its copied after running make clean
Jul 09 18:27:42 <zeddii_home> but it's all the source, right ?
Jul 09 18:28:05 <zeddii_home> that's why I saved only tools/llib for standalone perf build
Jul 09 18:28:34 <khem> yes
Jul 09 18:28:44 <khem> no worried I can copy that find|rm
Jul 09 18:29:23 <khem> I dont think you will need that if we staged a different copy
Jul 09 18:29:33 <khem> than the one thats packaged for on device modules
Jul 09 18:30:08 <zeddii_home> right. what you propose covers that case +
Jul 09 18:30:45 <zeddii_home> I'm @ home with people hammering in my ear, so I'm not thinking very fast.
Jul 09 18:30:56 <zeddii_home> I'm back to looking at darren's commit now.
Jul 09 18:31:27 <fray> zeddii, I'd suggest you move a little further away, so they are only hammering on your toes
Jul 09 18:31:37 <zeddii_home> :P
Jul 09 18:33:38 <khem> zeddii_home: http://paste.ubuntu.com/1083234/
Jul 09 18:34:24 <zeddii_home> khem: why can't I see the mrproper call in darren's commit. argh. my laggy access is killing me.
Jul 09 18:34:31 <khem> zeddii_home: do we need sources in tools dir ?
Jul 09 18:34:42 <msm> do we just delete files we don't want installed to avoid the QA warning?
Jul 09 18:34:49 <khem> msm: yes
Jul 09 18:34:59 <msm> khem: k thanks
Jul 09 18:35:09 <khem> well not only that there are binaries which are meant for other hosts
Jul 09 18:37:32 <khem> whats the way to cherry pick whole branch into your working branch
Jul 09 18:37:45 <khem>  dont want 1 patch at a time
Jul 09 18:38:03 <zeddii_home> khem: sources in the tools dir .. I'd say we want them, that's how we build perf. or am I thinking of something else ?
Jul 09 18:39:09 <khem> zeddii_home: ok
Jul 09 18:43:35 <zeddii_home> khem: aha.
Jul 09 18:43:53 <zeddii_home> I thought you meant darren's recent change, you were talking about the one from March ? I see the mrproper in there.
Jul 09 18:44:20 <fray> khem, do you know if the oe-core list is moderated?
Jul 09 18:44:38 <zeddii_home> subscriber only last i checked
Jul 09 18:44:48 <fray> thats what I thought..
Jul 09 18:44:56 <khem> yes its subscriber only
Jul 09 18:44:58 * zeddii_home knows what fray is looking for
Jul 09 18:45:12 <zeddii_home> khem: so this has been broken for a bit.
Jul 09 18:45:19 <msm> khem: how do you suggest deleting unwanted files for libgomp in gcc-runtime?
Jul 09 18:45:49 <khem> msm: are those .h ?
Jul 09 18:45:53 <msm> add a new var to track files per library or just a blanket rm -f at the end od the do install?
Jul 09 18:46:02 <msm> its a info file and a directory
Jul 09 18:46:16 <msm> and it's creating a warning
Jul 09 18:46:22 <msm> the .h is in the -dev package
Jul 09 18:46:36 <khem> msm: I think you can use the variable we have to define RUNTIMETARGETS in recipe
Jul 09 18:46:47 <khem> and take action if its libgomp and so on
Jul 09 18:50:05 <msm> ok
Jul 09 18:52:47 <khem> zeddii_home: http://paste.ubuntu.com/1083261/
Jul 09 18:52:53 <khem> this one keeps the tools srcs
Jul 09 18:54:08 * zeddii_home reads again.
Jul 09 19:00:18 <khem> uts untested
Jul 09 19:02:07 <zeddii_home> ok. so at least now that I have the on-target module build changes out of my head .. the patch make sense to me.
Jul 09 19:04:40 <zeddii_home> khem: I lost my IRC history. what's the end goal here ?
Jul 09 19:04:50 <zeddii_home> the hammering has stopped .. I can think better now.
Jul 09 19:05:03 <khem> zeddii_home: heh
Jul 09 19:05:32 <khem> end goal is that we do not clean the working bits and move it away into a separate dir
Jul 09 19:05:45 <khem> and thats the dir which is sysrooted and is used for cross dev
Jul 09 19:06:08 <khem> then we go ahead and prune it even more and have the directory suitable for packaging into kernel-dev
Jul 09 19:06:22 <khem> which then is suitable for on device
Jul 09 19:06:57 <zeddii_home> and the working bits that you are particularly interested in are the binary tools, right ?
Jul 09 19:06:58 <khem> I also have a patch which copies the kernel dir from sysroot into a tar file and can be shipped with say meta-toolchain
Jul 09 19:07:04 <khem> yep
Jul 09 19:07:23 <khem> so I have third sysroot called $MACHINE
Jul 09 19:07:33 <khem> and all those go under there on installed SDK
Jul 09 19:07:37 <khem> works great
Jul 09 19:07:47 <khem> and I can have multiple machine sysroots
Jul 09 19:07:47 <zeddii_home> ok. that's what the patch tells me, since you do the copy after the pruning of the source
Jul 09 19:08:03 <khem> yep
Jul 09 19:08:37 <zeddii_home> yah. the mrproper is the kicker if you need the binary parts.
Jul 09 19:08:45 <khem> correct
Jul 09 19:08:55 <khem> and since the SDK is ro
Jul 09 19:08:57 <zeddii_home> otherwise, we'd just be able to package it up differently.
Jul 09 19:09:03 <khem> means they can be generated layer
Jul 09 19:09:35 <zeddii_home> and we get QA errors if we leave them in -dev
Jul 09 19:09:41 * zeddii_home is thinking faster now.
Jul 09 19:10:39 <zeddii_home> yah, so I can't think of anything better. alternatives all fall down in different ways (i.e. just don't run mrproper for all use cases, package differently, etc, etc).
Jul 09 19:10:59 <zeddii_home> s/better/different/
Jul 09 19:13:57 <zeddii_home> aka. acked-by me on that if you want to propose it to the list :)
Jul 09 20:49:03 <sgw> fray: is it possible to have multiple update-alternative pointing to the same target, but with the same name (/bin/ip & /sbin/ip -> /sbin/ip.iproute2
Jul 09 21:32:03 <msm> hrmm, the python from the meta-toolchain is missing optparse so it can't run bitbake itself!
Jul 09 21:32:06 <msm> oh the irony!
Jul 09 21:34:33 <bluelightning> hmm, that is unfortunate
Jul 09 21:34:58 <bluelightning> I'm assuming we ensure that module is available for the build appliance
Jul 09 21:35:05 <bluelightning> fray: ping
Jul 09 21:38:53 <msm> somehow i suppose ;)
Jul 09 21:39:04 <msm> i wonder if im based off an older metea-toolchain
Jul 09 21:39:06 <msm> let me double chekc
Jul 09 21:39:14 <msm> err need to type slower ;)
Jul 09 21:39:59 <msm> yea, im just require'ing 'meta-toolchain.bb'
Jul 09 21:41:34 <msm> i looks like gdb-cross-canadian depends on python now.. and it's not adding python-textutils
Jul 09 21:42:00 <msm> however, now when i source my environement-setup from the meta-toolchain tarball the python from the tarball overrides my local python and makes bitbake stop working
Jul 09 21:46:28 <msm> do the yocto lists have patchworks anywhere?
Jul 09 21:59:39 <alephan> Hello everybody.
Jul 09 22:00:17 <alephan> sgw: I had a talk with you a while ago about having hwclock as a machine feature.
Jul 09 22:00:33 <alephan> It makes sanse as this is a hardware feature a board may have.
Jul 09 22:00:43 <alephan> In the rpi case - there is no hardware clock.
Jul 09 22:01:48 <alephan> So having a machine feature like this an installing init script based on it would avoid an error on machine without hwclock.
Jul 09 22:01:55 <alephan> and*
Jul 09 22:02:06 <sgw> alephan: I will take your word on the chat, I am not recalling it right now.
Jul 09 22:03:50 <alephan> hm... hope i'm not wrong about it :)
Jul 09 22:05:16 <sgw> alephan: probably not, I have a mind like a steel sieve, and way too many balls in the air at any given time!
Jul 09 22:05:36 <bluelightning> I have seen this topic come up before definitely
Jul 09 22:06:12 <bluelightning> seems like a reasonable idea, the question is how do we introduce an rtc machine feature without breaking existing machines
Jul 09 22:06:29 <alephan> Indeed that would be the next q. :
Jul 09 22:06:53 <bluelightning> one possibility would be to add a mechanism like the one I added for DISTRO_FEATURES
Jul 09 22:06:56 <alephan> Well my first thing that came into my mind was: have a machine feature named - nohwclock. :)
Jul 09 22:07:05 <bluelightning> yeah that's nasty though
Jul 09 22:07:15 <alephan> Indeed.
Jul 09 22:07:25 <alephan> COuld you develop your idea in DISTRO_FEATURES?
Jul 09 22:07:29 <alephan> on*
Jul 09 22:08:33 <bluelightning> the mechanism is DISTRO_FEATURES_BACKFILL
Jul 09 22:08:59 <bluelightning> see OE core rev 738658d9d5ddef026d2929188744aa225324bf26
Jul 09 22:09:24 <alephan> checking...
Jul 09 22:11:56 <alephan> Hmmm... don't understand how this works...
Jul 09 22:14:42 <bluelightning> alephan: the idea is, items added to DISTRO_FEATURES_BACKFILL will be added to DISTRO_FEATURES unless they are present in DISTRO_FEATURES_BACKFILL_CONSIDERED
Jul 09 22:15:45 <bluelightning> alephan: so we can add a new item to DISTRO_FEATURES that controls existing functionality that is currently enabled, and it will remain enabled unless the distro decides to opt-out of it by adding it to DISTRO_FEATURES_BACKFILL_CONSIDERED
Jul 09 22:16:18 <bluelightning> which is exactly what we need to do for this rtc feature, except we'd need this mechanism to be available for MACHINE_FEATURES
Jul 09 22:16:38 <alephan> Ok. I will prepare patches for this.
Jul 09 22:16:51 <alephan> Thank you very much for clarifying this commit.
Jul 09 22:17:00 <bluelightning> np
Jul 09 22:21:17 <alephan> Have a good night.
Jul 09 22:21:32 <bluelightning> and you :)
Jul 09 22:43:11 <msm> i have a problem
Jul 09 22:43:31 <msm> there is no override for meta-toolchain that is for the ARCH
Jul 09 22:43:45 <msm> e.g. no _powerpc or _powerpc64 override
Jul 09 22:44:08 <msm> the translated_target_arch is a target, but it's x86_64 for a meta-toolchain targetting powerpc
Jul 09 22:44:22 <msm> i have TUNEs defined, but that's less than ideal it seems like
Jul 09 22:54:20 <khem> msm: hmm you should have TARGET_ARCH
Jul 09 22:55:02 <msm> TARGET_ARCH = x86 on meta-toolchain
Jul 09 22:56:03 <msm> the MACHINE overrides contian the TUNEs
Jul 09 22:56:09 <khem> hmm
Jul 09 22:56:12 <msm> i can switch to e500v2, e500mc, etc from powerpc
Jul 09 22:56:23 <msm> seems reasonable, but not quite ideal
Jul 09 22:56:28 <msm> since i went from two lines to several ;)
Jul 09 22:56:39 <khem> # TRANSLATED_TARGET_ARCH=${@d.getVar('TARGET_ARCH', True).replace("_", "-")}
Jul 09 22:56:40 <khem> TRANSLATED_TARGET_ARCH="mips"
Jul 09 22:56:43 <msm> maybe being more specific for libgomp is more ideal
Jul 09 22:56:45 <khem> thats what it shows for me
Jul 09 22:57:01 <khem> bitbake -e meta-toolchain | grep "TRANSLATED_TARGET_ARCH="
Jul 09 22:57:28 <khem> bitbake -e meta-toolchain | grep "OVERRIDES="
Jul 09 22:57:54 <khem> # OVERRIDES=${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:${CLASSOVERRIDE}:forcevariable${LIBCOVERRIDE}
Jul 09 22:57:57 <khem> OVERRIDES="linux:mips:build-linux:pn-meta-toolchain:qemumips::class-target:forcevariable:libc-glibc"
Jul 09 22:58:14 <khem> are you on master ?
Jul 09 22:58:46 <msm> denzil
Jul 09 22:59:03 <msm> try a specific task
Jul 09 22:59:07 <msm> bitbake gcc-runtime-nativesdk
Jul 09 22:59:19 <msm> # OVERRIDES=${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:forcevariable${LIBCOVERRIDE}:virtclass-nativesdk
Jul 09 22:59:19 <msm> OVERRIDES="linux:x86-64:build-linux:pn-gcc-runtime-nativesdk:p1022ds:e500v2:fsl:forcevariable:virtclass-nativesdk"
Jul 09 22:59:54 <msm> my meta-toolchain works OK - it's like yours
Jul 09 23:00:47 <khem> oh ok
Jul 09 23:00:47 <khem> its bnativesdk
Jul 09 23:00:48 <khem> you should not make nativesdk package depend on target arch
Jul 09 23:01:27 <msm> but TUNE is OK?
Jul 09 23:01:42 <msm> I'm fine with it, just seems like a wider net would be cleaner for some things ;)
Jul 09 23:01:49 <khem> thaswhat are you trying to do
Jul 09 23:01:59 <msm> this is about libgomp
Jul 09 23:02:12 <msm> im trying to build for all my targets by default
Jul 09 23:02:24 <msm> i can do RUNTIMETARGET_powerpc for nativesdk
Jul 09 23:02:27 <msm> CANT*
Jul 09 23:02:58 <khem> why do you need libgomp on sdkhost
Jul 09 23:03:18 <khem> you just need it on target
Jul 09 23:03:33 <khem> so why chage nativesdk package at all
Jul 09 23:03:46 <msm> to link against it?
Jul 09 23:03:54 <msm> when we ship a toolchain tarball
Jul 09 23:04:10 <khem> ok, so you ship the target libgomp
Jul 09 23:04:17 <khem> why ship a host libgomp
Jul 09 23:04:21 <msm> we ship both
Jul 09 23:04:22 <khem> is there any use ?
Jul 09 23:04:36 <msm> this is the powerpc lib we are talking about
Jul 09 23:04:39 <msm> or wait
Jul 09 23:04:43 <msm> im seeing your point
Jul 09 23:04:45 <msm> ugh
Jul 09 23:04:50 <msm> i've just realized what is going on
Jul 09 23:04:58 <khem> alright :)
Jul 09 23:05:08 <msm> i forgot about the cross tools for x86
Jul 09 23:05:18 <khem> nativesdk is not native sdk
Jul 09 23:05:25 <msm> so i was incorrectly assuming this was for my toolchain
Jul 09 23:05:27 <khem> I know naming is confusing but thats the best we have
Jul 09 23:05:32 <msm> but the error is from the native toolchain
Jul 09 23:05:35 <msm> yea, its ok
Jul 09 23:05:37 <msm> got it now
Jul 09 23:05:38 <msm> thanks
Jul 09 23:05:53 <khem> yes, for host let it build with out gomp
Jul 09 23:06:05 <khem> so if you do RUNTIMETARGET_powerpc = "..."
Jul 09 23:06:09 <khem> that should be fine
Jul 09 23:06:53 <khem> msm: btw. look at my eglibc-2.16 branch I have updated e5500 support for gcc/binutils/glibc in there
Jul 09 23:07:13 <khem> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/eglibc-2.16
Jul 09 23:07:19 <khem> you might be interested I thought
Jul 09 23:09:03 <khem> with those meta-fsl-ppc patches I posted I am able to build stuff for ppce5500 now using master
Jul 09 23:10:42 <msm> i saw your patch ;)
Jul 09 23:10:54 <msm> i was going to apply your patches, but could not find a yocto ml
Jul 09 23:10:59 <msm> to fetch the patches
Jul 09 23:11:04 <msm> now i need to download them from my mailer ;)
Jul 09 23:11:20 <khem> oh, may be we should hook yocto ml to patchworl
Jul 09 23:11:23 <khem> patchwork
Jul 09 23:11:50 <khem> msm: I can push a tree to contrib if you like
Jul 09 23:12:34 <khem> msm: btw. http://git.freescale.com/git/cgit.cgi/ppc/sdk/linux.git/
Jul 09 23:12:50 <khem> is the latest lnx git tree that is recommended ?
Jul 09 23:13:08 <msm> on git.freescale.com?
Jul 09 23:13:13 <khem> yes
Jul 09 23:13:31 <msm> ya
Jul 09 23:13:49 <msm> i guess master on meta-fsl-ppc is still point at old ones?
Jul 09 23:14:00 <khem> I see that there are mirrors of poky and other layers there
Jul 09 23:14:37 <khem> SRC_URI = "git://git.freescale.com/ppc/sdk/linux.git \
Jul 09 23:14:52 <khem> is that old ?
Jul 09 23:15:03 <msm> that's the latest
Jul 09 23:15:13 <khem> ok so master is good
Jul 09 23:15:13 <msm> master on meta-fsl-ppc contains is point to hte right sha
Jul 09 23:15:21 <khem> its at rev 1e3e8ed15249d73a066ddfe2e80882935c35dcb7
Jul 09 23:15:36 <msm> ya
Jul 09 23:15:45 <msm> http://git.freescale.com/git/cgit.cgi/ppc/sdk/linux.git/tag/?id=fsl-sdk-v1.2
Jul 09 23:16:09 <msm> im almost done with denzil
Jul 09 23:16:15 <msm> then ill spend some time on master
Jul 09 23:16:40 <khem> may be using fsl-sdk-v1.2 is better
Jul 09 23:16:45 <khem> yeah there we go
Jul 09 23:18:41 <khem> SRCREV = "fsl-sdk-v1.2" should work
Jul 09 23:19:01 <khem> and PV = "3.0.34"
Jul 09 23:19:31 <msm> its the same right now though ;)
Jul 09 23:21:06 <khem> ah yes
Jul 09 23:21:51 <khem> OK I have changed it, I can push my tree to github if thats easy for you
Jul 09 23:22:00 <khem> to pick patches
Jul 09 23:24:29 <msm> pushing to github would be helpful ;)
Jul 09 23:24:57 <khem> k
Jul 09 23:25:29 <khem> 0001-compiler.h-Undef-before-redefining-__attribute_const.patch
Jul 09 23:25:29 <khem> add-no-error-array-bounds.patch
Jul 09 23:25:29 <khem> add-no-unused-but-set-variable.patch
Jul 09 23:25:37 <khem> these 3 patches are on master
Jul 09 23:25:41 <khem> are they needed still ?
Jul 09 23:26:06 <khem> I dont see them applied to recipes on meta-fsl-ppc on fsl git
Jul 09 23:26:41 <msm> hmm, where did they come from?
Jul 09 23:26:51 <msm> meta-fsl-ppc ? which branch?
Jul 09 23:26:56 <khem> master
Jul 09 23:27:24 <msm> on git.yocto or git.fsl?
Jul 09 23:27:29 <msm> git.freescale.com is purely for the SDK
Jul 09 23:27:48 <msm> i thought i removed the patches for denzil and master branches
Jul 09 23:28:03 <msm> the toolchain patches
Jul 09 23:28:12 <khem> both have them
Jul 09 23:28:23 <khem> I am talking about meta-fsl-ppc on yp.org
Jul 09 23:28:48 <khem> those are kernel patches btw.
Jul 09 23:28:57 <msm> ah kernel patches
Jul 09 23:29:06 <khem> can I remove them ?
Jul 09 23:29:09 <msm> those were old toolchain fixes i think
Jul 09 23:29:13 <msm> i think they are no longer needed
Jul 09 23:29:13 <khem> ok
Jul 09 23:29:22 <khem> thats what i thought
Jul 10 02:27:53 <khem> msm: around ?
Jul 10 02:28:04 <msm> ya
Jul 10 02:28:12 <khem> msm: here is the github tree https://github.com/kraj/meta-fsl-ppc
Jul 10 02:28:39 <khem> msm: master branch has my commits
Jul 10 02:29:15 <msm> k thanks
Jul 10 02:30:01 <msm> i might get to it tonight
Jul 10 02:30:10 <khem> sure thanks
Jul 10 02:30:18 <khem> msm: btw. I replied to your gcc patch,
Jul 10 02:30:24 <khem> I am carrying similar patch locally
Jul 10 02:30:50 <khem> but if you make the change I requested then we are at par
Jul 10 02:31:21 <khem> msm: btw. whats the relation between meta-fsl-ppc layer on git.fsl.com and git.yp.org ?
Jul 10 02:31:46 <khem> which one is upstream if they are related or not ?
Jul 10 02:31:47 <khem> I wonder
Jul 10 02:32:20 <msm> im going to submit that shortly
Jul 10 02:32:22 <msm> with your change
Jul 10 02:32:28 <msm> the SYSTEMLIBS one
Jul 10 02:32:34 <msm> fsl.com is for SDK currently
Jul 10 02:32:40 <msm> yp.org is for commmunity
Jul 10 02:33:02 <msm> so if random customer wants to use SDK they get the master branch with a known working SDK
Jul 10 02:33:20 <msm> whereas community has all the branches for edison/denzil/master and it could be broken at any point in time
Jul 10 02:33:31 <msm> fsl.com won't be updated until the next release
Jul 10 02:34:08 <khem> I see
Jul 10 02:34:25 <khem> so fsl.com is downstream
Jul 10 02:34:37 <msm> maybe not ideal but there is only so many ways to handle it
Jul 10 02:34:44 <msm> its really a known working fork
Jul 10 02:34:56 <khem> k
Jul 10 02:35:02 <msm> yp.org is intended to be the primary development location
Jul 10 02:35:29 <khem> ok
Jul 10 02:35:51 <khem> I think 1.3 will look ok for ppc stuff
Jul 10 02:36:26 <khem> if you have time can you verify if you can boot the kernel built with gcc 4.7 ?
Jul 10 02:36:37 <khem> since its 3.0
Jul 10 02:36:39 <msm> heh boot test things?
Jul 10 02:36:46 <msm> that sounds like a step i usually skip
Jul 10 02:36:47 <khem> kernel, I am not sure if there are some kinks
Jul 10 02:36:55 <khem> lol
Jul 10 02:37:45 <msm> i need more build machines
Jul 10 02:38:09 <msm> ive been spending too much time waiting to test last two gcc changes
Jul 10 02:38:19 <khem> I think intel will like yocto become build system of choice :).
Jul 10 02:38:32 <msm> hah
Jul 10 02:38:33 <khem> it will boost the sale
Jul 10 02:38:41 <msm> too low volume ;)
Jul 10 02:39:13 <khem> think if aunt poly is building an app for her refrigirator and she has to use yocto underneath :)
Jul 10 02:40:04 <khem> she will run to frys and buy a faster pc first
Jul 10 02:41:36 <msm> lol
Jul 10 02:41:43 <msm> ive added your changes
Jul 10 02:41:46 <msm> to master
Jul 10 02:41:57 <msm> and running builds tests no
Jul 10 02:41:59 <msm> now*
Jul 10 02:42:36 <msm> i need to take a closer look at denzil and master and see if i need anything else from edison
Jul 10 02:46:40 <khem> yeah that would be cool if you can forward port edison changes to master and then trickle them into denzil if needed
Jul 10 02:47:00 <khem> btw. you need a patch for eglibc 2.15 for denzil/ppc64
Jul 10 02:49:07 <khem> shit I dont know where that patch went
Jul 10 02:50:48 <msm> yes ive seen the build errors
Jul 10 02:50:58 <msm> but denzil uses 2.13 by default?
Jul 10 02:51:11 <msm> im not sure what our toolchain folks will want to use officially yet either
Jul 10 02:51:59 <khem> msm: push for 4.7/2.16
Jul 10 02:52:16 <khem> since thats what we will use in yp for 1.3
Jul 10 02:52:25 <msm> by the time we get to yp 1.3 we might be on that
Jul 10 02:52:39 <khem> and force them to use 4.7 from yocto please
Jul 10 02:52:39 <msm> i think the next one is yp 1.2 based w/ eglibc 2.15 and gcc 4.6.x
Jul 10 02:52:43 <msm> i think
Jul 10 02:52:48 <msm> these are not my decisions
Jul 10 02:52:54 <khem> ok
Jul 10 02:53:07 <khem> stick to 2.13 with denzil
Jul 10 02:53:09 <msm> however, im happy to carry patches that keep all versions working
Jul 10 02:53:27 <msm> so if master we need some stuff for 4.7 we can try to figure out what we need and add it in
Jul 10 02:54:31 <khem> you mean master of meta-fsl-ppc ?
Jul 10 02:56:09 <msm> well
Jul 10 02:56:38 <msm> i'd like each of the branches (releases) of meta-fsl-ppc to work with 1) the compiler/libc fsl choose and 2) the compiler/libc oe-core chooses
Jul 10 02:56:51 <msm> you saw how I did it in edison branch?
Jul 10 02:57:21 <msm> its kinda weird and im not sure how I feel about it, but we can override the compiler if we choose to fsl distro
Jul 10 02:57:39 <msm> (its fairly trivial and just going back to a baseline compiler + known patches)
Jul 10 02:57:45 <msm> its really just about reproducibility
Jul 10 02:57:53 <msm> and it all gets quite tedious
**** ENDING LOGGING AT Tue Jul 10 02:59:58 2012

**** BEGIN LOGGING AT Tue Jul 10 02:59:58 2012
Jul 10 03:25:05 <khem> ideally it will be nice if both were in sync
Jul 10 03:37:55 <msm> yea, tell that to the people who work on the toolchain
Jul 10 03:37:56 <khem> msm: yocto compiler is fairly tested, I dont know how is fsl's internal compiler testing done
Jul 10 03:38:07 <msm> they dont really care about about anything
Jul 10 03:38:15 <msm> even though we are their *only* customer ;)
Jul 10 03:38:29 <khem> heh strange really
Jul 10 03:38:38 <msm> yea, i've tried to tell them yocto itself tests your compiler
Jul 10 03:38:42 <msm> its *really* neat
Jul 10 03:38:49 <msm> i dont have time to deal with it all though
Jul 10 03:38:58 <khem> linaro is using OE for doing exactly same
Jul 10 03:39:09 <khem> but in this case they test their own compiler
Jul 10 03:39:16 <msm> i think yp 1.3 + is won't build on my build machine anymore ;(
Jul 10 03:39:36 <khem> fsl could use the compiler from OE-Core and develop their patches on top but as you say it may be a hard sell
Jul 10 03:39:41 <msm> | /local/jenkins/jobs/yocto-upstream/workspace/label/master/machine/p4080ds/poky/master/tmp/work/x86_64-linux/rpm-native-5.4.9-r45/rpm-5.4.9/tools/dbconvert.c:126: warning: the use of `tempnam' is dangerous, better use `mkstemp'
Jul 10 03:39:41 <msm> | dbconvert.o: In function `main':
Jul 10 03:39:41 <msm> | dbconvert.c:(.text+0x923): undefined reference to `htobe32'
Jul 10 03:39:41 <msm> | dbconvert.c:(.text+0xaa4): undefined reference to `htole32'
Jul 10 03:39:41 <msm> | dbconvert.c:(.text+0xac9): undefined reference to `htole32'
Jul 10 03:39:50 <khem> ugh
Jul 10 03:40:09 <khem> whats your host
Jul 10 03:40:09 <msm> this is CentOS release 5.6 (Final)
Jul 10 03:40:18 <msm> nice and old ;)
Jul 10 03:40:59 <khem> ping fray
Jul 10 03:41:05 <khem> I think he should help here
Jul 10 03:41:56 <khem> can you upgrade to say 5.8
Jul 10 03:42:07 <khem> 5.x is still maintained so I think we should support it
Jul 10 03:42:12 <msm> yea
Jul 10 03:42:17 <msm> ive tried to yum update recently
Jul 10 03:42:19 <msm> and got some weird errors
Jul 10 03:42:25 <khem> hmm
Jul 10 03:42:35 <msm> some nash conflicts
Jul 10 03:43:05 <msm> need to look closer
Jul 10 03:43:28 <khem> you are not alone http://comments.gmane.org/gmane.comp.package-management.rpm.user/740
Jul 10 03:44:31 <khem> Don't build dbconvert.c would be my suggestion.
Jul 10 03:44:36 <khem> is the key takeaway
Jul 10 03:44:53 * msm sigh
Jul 10 03:44:58 <msm> back to denzil? heh
Jul 10 03:45:13 <khem> you can patch rpm
Jul 10 03:45:25 <msm> i probably need to just get the yum update working
Jul 10 03:45:28 <khem> just rename dbconvert.c to dbconvert.sh
Jul 10 03:46:46 <khem> msm: may be file a bug in yp bigz
Jul 10 03:46:49 <khem> bugz
Jul 10 03:49:40 <msm> plenty of choices for now
Jul 10 03:49:53 <khem> msm: ok I can give you a patch for rpm
Jul 10 03:49:58 <khem> hang on
Jul 10 03:49:59 <msm> lol
Jul 10 03:50:07 <msm> let me see if update centos fixes it first
Jul 10 03:53:07 <msm> khem: looks like i need your master fixes for e5500?
Jul 10 03:54:08 <msm>   git://http://git.openembedded.org/openembedded-core-contrib kraj/eglibc-2.16?
Jul 10 03:55:31 <msm> or is there a 2.15 version too?
Jul 10 03:57:01 <khem> msm: http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/misc&id=8ba2b11ee14c0366990a51fb7b13902c77a5aef6
Jul 10 03:57:16 <khem> msm: yes you need those but I did not fix 2.15
Jul 10 03:57:27 <khem> since that eglibc 2.15 will go away
Jul 10 03:57:47 <khem> msm: that patch might fix your issue try it out
Jul 10 03:57:51 <khem> I did not test it
Jul 10 03:58:58 <msm> ill test against 2.16 if master will be base on that
Jul 10 04:01:10 <khem> yes master will rebase on 2.16, I just did not make a switch since eglibc upgrades needs to be well tested
Jul 10 04:01:21 <msm> for yp 1.3?
Jul 10 04:01:24 <msm> or later?
Jul 10 04:01:25 <khem> so once we are confident that all is well we will punt 2.15 out
Jul 10 04:01:33 <khem> 1.3 I am planning on
Jul 10 04:01:37 <msm> ok
Jul 10 04:01:50 <msm> i cherry-picked your patches in
Jul 10 04:01:53 <msm> let's try again
Jul 10 04:01:59 <khem> sure
Jul 10 04:02:14 <msm> you did not bump EGLIBCVERSION?
Jul 10 04:02:21 <khem> no
Jul 10 04:02:33 <khem> you change that in your local.conf
Jul 10 04:02:38 <khem> for now
Jul 10 04:02:47 <khem> there will be a flag day
Jul 10 04:03:00 <msm> k
Jul 10 04:03:25 <msm> i managed to fix my yum update problem too
Jul 10 04:03:34 <msm> yum remove mkinitrd.i386 (this is a 64-bit machine)
Jul 10 04:03:44 <msm> somehow i had both
Jul 10 04:09:32 <msm> hmm
Jul 10 04:09:49 <msm> python build on master causes dependent recipe builds to croak
Jul 10 04:09:50 <msm> | python: error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No suc
Jul 10 04:09:59 <msm> this was for curl
Jul 10 04:12:43 <msm> grr, subversion now
Jul 10 04:13:03 <msm> oh master
Jul 10 04:16:54 <khem> whats up with subversion
Jul 10 04:19:58 <msm> | /usr/bin/install -c -m 644 /local/home/mattsm/git/poky/build/tmp/work/x86_64-linux/subversion-native-1.7.2-r1/subversion-1.7.2/subversion/include/svn_dso.h /local/home/mattsm/git/poky/build/tmp/work/x86_64-linux/subversion-native-1.7.2-r1/image/local/home/mattsm/git/poky/build/tmp/sysroots/x86_64-linux/usr/include/subversion-1/svn_dso.h
Jul 10 04:19:58 <msm> | /usr/bin/ld: cannot find -lsvn_delta-1
Jul 10 04:19:58 <msm> | collect2: ld returned 1 exit status
Jul 10 04:19:58 <msm> | x86_64-linux-libtool: install: error: relink `libsvn_ra_neon-1.la' with the above command before installing it
Jul 10 04:19:58 <msm> | make: *** [install-neon-lib] Error 1
Jul 10 04:19:59 <msm> | make: *** Waiting for unfinished jobs....
Jul 10 04:21:03 <khem> hmm thats stragnge eror
Jul 10 04:21:15 <khem> may be its looking for some dependency on your host
Jul 10 04:22:28 <msm> yea, need to look closer
Jul 10 04:22:44 <msm> time to stop for now though
Jul 10 04:23:30 <msm> i think people have slowed down in older distros
Jul 10 04:23:41 <msm> ubuntu 12.04 lts is chugging right alot
Jul 10 04:23:44 <msm> the others have all failed
Jul 10 04:23:58 <msm> fedora 13 and centos 5.x
Jul 10 04:24:25 <khem> alright gnight
Jul 10 04:24:36 <khem> yeah 12.04 will work since thats my machine too :)
Jul 10 04:50:04 <msm> khem: updating centos did not fix my issue
Jul 10 04:50:13 <msm> khem: looks like i will need to patch rpm
Jul 10 05:10:08 <khem> k
Jul 10 05:10:41 <khem> i kind of expected that since its a interface/headers issue in glibc and usually they dont update glibc between point release
Jul 10 08:25:03 <RP> morning all
Jul 10 08:27:54 <Orre> morning
Jul 10 09:49:55 <bluelightning> morning all
Jul 10 09:50:06 <JaMa|Off> morning
Jul 10 09:50:32 <JaMa|Off> bluelightning: any luck with tracking runtime package name in buildhistory?
Jul 10 09:50:47 <bluelightning> JaMa|Off: I haven't even looked at it I'm afraid
Jul 10 09:50:55 <JaMa|Off> ok
Jul 10 09:51:20 <bluelightning> still working on rootfs stuff (2595, 2614, etc.)
Jul 10 09:51:35 <ant_work> JaMa|Off: btw, about psplash, we have to change the rotation. What is better from the 'feed maintainer' POV? If we add a runtime-check we can let the recipe arch-specific otherwise at build time that would render it machine-specific.Add to this the PR increment done in layer...would that survive to an ipkg upgrade?
Jul 10 09:51:39 <bluelightning> hopefully I will have some time to get back to buildhistory next week though
Jul 10 09:54:20 <JaMa|Off> ant_work: I'm not using psplash, but with separate arch recipe providing common functionality and machine arch recipe providing image with right rotation and scale seems like best to me
Jul 10 10:07:25 <ant_work> bluelightning: the kind of answer I would not have
Jul 10 10:07:43 <ant_work> bluelightning: asking Koen as well now...
Jul 10 10:08:26 <awafaa> chap(s/esses), if possible could someone have a look at a layer for me please?
Jul 10 10:08:55 <awafaa> my intention is to add a custom kernel, as well as use Linaro's GCC (which is from another layer)
Jul 10 10:09:08 <awafaa> I'm not sure if I've done it correctly though
Jul 10 10:09:22 <awafaa> the layer in question is https://github.com/awafaa/meta-vexa15
Jul 10 10:10:35 <awafaa> my intention is to use a fdt kernel, but I'm struggling to understand how to do that - considering my device just requires the dtb to be cat'ed to the zImage
Jul 10 10:22:47 <bluelightning> I'm not sure about the kernel specifically, but usually one wouldn't have a recipe and an append for it in the same layer
Jul 10 10:24:09 <bluelightning> also your readme tells people to run qemu-system-arm directly - I'd recommend using runqemu as it's much easier to deal with
Jul 10 10:26:09 <ag_> Hello.
Jul 10 10:27:20 <ag_> Any reason why bitbake is now in ignore list?
Jul 10 10:27:39 <ag_> I wanted to commit something for bitbake_devel... and guess what? Can't. :)
Jul 10 10:32:23 <bluelightning> ag_: it is annoying yes... I guess it's because oe-core and bitbake are used independent of poky and in that instance you want the ignore
Jul 10 10:32:47 <bluelightning> ag_: I assume RP wanted to keep the same .gitignore for both repos
Jul 10 10:33:19 <ag_> bluelightning: I somehow understand... but i have to agree that it is annoying. Anyway i can -f.
Jul 10 10:34:29 <bluelightning> awafaa: ^^ and also, why are you encouraging people to bitbake -c cleansstate world ?
Jul 10 10:34:53 <ag_> :) to make a better world.  :)
Jul 10 10:36:06 <awafaa> bluelightning: ah ok, i think i was getting confused with the append so left it in there
Jul 10 10:36:43 <awafaa> the reason for running qemu-system-arm directly is that it uses a custom qemu machine that linaro have created
Jul 10 10:37:24 <awafaa> also the cleanstate is taken from Linaro's recommendation
Jul 10 10:37:44 * awafaa is a noob at yocto stuff and has been thrown in somewhat at the deep end :)
Jul 10 10:38:22 <ag_> :)
Jul 10 10:38:54 <RP> bluelightning: I actually want to change the one in poky. I just need to update my scripts and make it happen
Jul 10 10:39:58 <ag_> Are there any bzr:// SRC_URIs in the work?
Jul 10 10:40:06 <ag_> world*
Jul 10 10:40:28 <bluelightning> awafaa: surely you can specify the machine on the runqemu command line...
Jul 10 10:40:47 <RP> ag_: There have been
Jul 10 10:41:02 <ag_> RP: I guess none left...
Jul 10 10:41:04 <awafaa> bluelightning: dunno, not tried it, but will do
Jul 10 10:41:43 <awafaa> bluelightning: so if i remove the append does everything else seem sane?
Jul 10 10:41:58 <RP> ag_: yes, most people use git now
Jul 10 10:42:38 <bluelightning> the ubuntu folks are still fairly keen on bzr it seems
Jul 10 10:42:54 <B4gder> yeah, launchpad seems very bzr
Jul 10 10:43:04 <ag_> confirmed
Jul 10 10:44:24 <bluelightning> awafaa: from my cursory glance over with the above comments, yes
Jul 10 10:44:36 <bluelightning> awafaa: but I haven't looked into each file
Jul 10 10:45:03 <awafaa> bluelightning: ok, i'll give it a whirl and see, thanks very much
Jul 10 10:45:45 <awafaa> btw, are there any tutorials for the n00b wanting to learn the way of the Yocto?
Jul 10 10:46:00 <awafaa> preferably something with examples etc :)
Jul 10 10:46:25 <bluelightning> awafaa: depends how new you are... for absolute newbies we have an instructional video, but I think you're already past that
Jul 10 10:46:55 <bluelightning> awafaa: otherwise all we have are the manuals really (which are fairly extensive and do contain examples)
Jul 10 10:49:22 <awafaa> hmm, ok thanks. i need to revist them then, i didn't see any walkthrough
Jul 10 10:50:40 <bluelightning> we should have step-by-step instructions on creating a BSP for example
Jul 10 10:51:06 <bluelightning> if you see anything missing feel free to raise it on the yocto mailing list
Jul 10 10:52:57 <awafaa> will do, thanks
Jul 10 10:53:22 <awafaa> so wrt to my append, should i merge the contents into the actual bb?
Jul 10 10:57:49 <ag_> Day of questions. Why are we supporting hg fetcher as long as we don't have mercurial-native?
Jul 10 10:57:58 <ag_> Is this in another layer or something?
Jul 10 10:59:15 <JaMa> ag_: it's in meta-oe
Jul 10 11:00:22 <ag_> JaMa: Thanks. I will use it from the host for testing purposes.
Jul 10 11:00:54 <bluelightning> awafaa: yes
Jul 10 11:01:10 <awafaa> thanks
Jul 10 11:02:21 <ant_work> JaMa: so, following the discussion, there isn't any valid alternative to a pslash-custom in meta-hh ?
Jul 10 11:04:03 <ant_work> last option could be some machine-specific post-install deploying /etc/rotation
Jul 10 11:04:15 <ant_work> in another helper package
Jul 10 11:05:45 <ant_work> or better, the recipe in oe-core should get the right rotation from formfactor
Jul 10 11:06:22 <JaMa> machine specific recipe with correct config for it (e.g. /etc/rotation), right?
Jul 10 11:07:32 <JaMa> and psplash-config added to SIGGEN_EXCLUDERECIPES_ABISAFE so it doesn't changes psplash checksums because of rdependency
Jul 10 11:11:44 <ant_work> JaMa: well, we have DISPLAY_ORIENTATION=270 in formfactor. I'd use that info and extend formfactor recipe instead, to prove /etc/rotation
Jul 10 11:15:04 <Orre> good day :)
Jul 10 11:19:00 <Orre> I got a git server with a repository. Said repository has a branch named meta and a rev for a commit. When in a new bsp I set SRC_URI="git://localhost/path;bareclone=1;branch=meta" to said repo, in linux-yocto-3.2.bbappend and SRC_REV="<COMMIT REVISION>". I still get the error:
Jul 10 11:19:04 <Orre> | ERROR. meta data not found, check upstream repo for tags and branches NOTE: package linux-yocto-3.2.11+git2+7e4f76a49c6e2c436ca2174a658fab88292a04b8-r0.1.1: task do_patch: Failed ERROR: Task 481 (/home/user/poky-denzil-7.0/meta/recipes-kernel/linux/linux-yocto_3.2.bb, do_patch) failed with exit code '1'
Jul 10 11:19:13 <Orre> any ideas of what may still be wrong?
Jul 10 11:20:51 <ag_> Orre: Use SRCREV not SRC_REV
Jul 10 11:21:07 <Orre> ag_: Mispoke, using SRCREV
Jul 10 11:21:39 <ag_> Give us some more output.
Jul 10 11:21:58 <ag_> Use Use gist or something.
Jul 10 11:24:32 <Orre> I didn't get that much information:
Jul 10 11:24:35 <Orre> ERROR: Function failed: do_patch (see /home/user/poky-denzil-7.0/build/tmp/work/temp-poky-linux-gnueabi/linux-yocto-3.2.11+git2+7e4f76a49c6e2c436ca2174a658fab88292a04b8-r0.1.1/temp/log.do_patch.20436 for further information) ERROR: Logfile of failure stored in: /home/user/poky-denzil-7.0/build/tmp/work/temp-poky-linux-gnueabi/linux-yocto-3.2.11+git2+7e4f76a49c6e2c436ca2174a658fab88292a04b8-r0.1.1/temp/log.do_patch.20436
Jul 10 11:24:43 <Orre> Log data follows: | ERROR: Function failed: do_patch (see /home/user/poky-denzil-7.0/build/tmp/work/temp-poky-linux-gnueabi/linux-yocto-3.2.11+git2+7e4f76a49c6e2c436ca2174a658fab88292a04b8-r0.1.1/temp/log.do_patch.20436 for further information) | ERROR. meta data not found, check upstream repo for tags and branches
Jul 10 11:24:50 <Orre> NOTE: package linux-yocto-3.2.11+git2+7e4f76a49c6e2c436ca2174a658fab88292a04b8-r0.1.1: task do_patch: Failed ERROR: Task 481 (/home/user/poky-denzil-7.0/meta/recipes-kernel/linux/linux-yocto_3.2.bb, do_patch) failed with exit code '1' NOTE: Tasks Summary: Attempted 1286 tasks of which 1281 didn't need to be rerun and 1 failed.
Jul 10 11:24:58 <Orre> Summary: 1 task failed:   /home/user/poky-denzil-7.0/meta/recipes-kernel/linux/linux-yocto_3.2.bb, do_patch Summary: There was 1 WARNING message shown. Summary: There was 1 ERROR message shown, returning a non-zero exit code.
Jul 10 11:25:46 <ag_> You will have to understand the way yocto kernel repo are structured.
Jul 10 11:26:19 <ag_> I have to go. But i hope somebody can help you around.
Jul 10 11:26:33 <Orre> So the error is in the structure of the kernel?
Jul 10 11:26:39 <Orre> Thanks for trying!
Jul 10 11:26:40 <RP> any cmake experts around?
Jul 10 11:41:22 <Orre> Solved, Added in bbappend: YOCTO_KERNEL_META_DATA=""
Jul 10 11:41:34 <Orre> Now I only get a compile error so will see if I will need to ask again later...
Jul 10 12:00:05 <Orre> |   GEN     /home/user/poky-denzil-7.0/build/tmp/work/temp-poky-linux-gnueabi/linux-yocto-3.2.11+git2+7e4f76a49c6e2c436ca2174a658fab88292a04b8-r0.1.1/linux-temp-standard-build/Makefile |   CHK     include/linux/version.h |   CHK     include/generated/utsrelease.h | "2.6.35Error: kernelrelease not valid - run make prepare to update it" exceeds 64 characters
Jul 10 12:01:16 <Orre> It's the problem mainly from that I was testing around using 3.2 as a basis when I should've gone from something earlier? Should in such case 2.6.37 work? Or can I do some other change to solve the problem, editing some rows somewhere?
Jul 10 12:15:54 <Orre> nvm, just changed to 2.6.37 and it worked.
Jul 10 13:20:09 <awafaa> if i have a layer that has numerous kernels within it, how do i specify which one is to be used?
Jul 10 13:21:25 * awafaa thought it was in meta-foo/conf/machine/foo.conf with PREFERRED_PROVIDER
Jul 10 13:29:41 <bluelightning> awafaa: PREFERRED_PROVIDER_virtual/kernel
Jul 10 13:30:11 <bluelightning> awafaa: then as long as you don't add a DEPENDS on a specific kernel recipe (use virtual/kernel instead if needed) then that should work
Jul 10 13:31:28 <awafaa> bluelightning: yup, i've got linux-upstream and linux-ael in my layer, and the conf has PREFERRED_PROVIDER_virtual/kernel ?= "linux-ael" and  PREFERRED_PROVIDER_kernel-base ?= "linux-ael"
Jul 10 13:31:38 <awafaa> yet the image ends up with linux-upstream
Jul 10 13:31:41 <ag_> bluelightning: I will modify your python function to be able to be used with other variables as well.
Jul 10 13:31:54 <ag_> bluelightning: Talking about that backfill with FEATURES.
Jul 10 13:31:56 <awafaa> could that be because the version of -upstream is higher than ael?
Jul 10 13:32:08 <ag_> bluelightning: backfill = (d.getVar(var+"_BACKFILL", True) or "").split()
Jul 10 13:32:15 <bluelightning> ag_: ah, there was someone called alephan in here last night promising to do the same...
Jul 10 13:32:25 <ag_> :)
Jul 10 13:32:35 <ag_> The other me.
Jul 10 13:32:42 <bluelightning> ag_: ah, that was you?
Jul 10 13:32:59 <ag_> bluelightning: Yes. I logged in from web interface.
Jul 10 13:33:14 <bluelightning> ag_: ah ok... saul and I were both a little confused :)
Jul 10 13:33:25 <ag_> bluelightning: Me too now. :)
Jul 10 13:33:37 <bluelightning> heh
Jul 10 13:33:48 <bluelightning> awafaa: it's unlikely
Jul 10 13:34:39 <bluelightning> awafaa: what do you get if you do bitbake -e | grep PREFERRED_PROVIDER_virtual/kernel
Jul 10 13:36:20 <awafaa> bluelightning: erm, somewhat surprisingly i get PREFERRED_PROVIDER_virtual/kernel="linux-yocto"
Jul 10 13:36:27 <awafaa> not what i was expecting
Jul 10 13:36:57 <bluelightning> awafaa: right, because you are doing ?=, something else (probably the distro config) is doing = afterwards
Jul 10 13:37:24 <bluelightning> awafaa: it should be ok to just do = for these PREFERRED_PROVIDER lines in the machine config
Jul 10 13:37:43 <bluelightning> not sure if you need the kernel-base one...
Jul 10 13:37:45 <awafaa> bluelightning: i'll try that, thanks
Jul 10 14:05:38 <awafaa> hmm, im still getting linux-yocto as my kernel and not one of my own, even after specifying it in machine.conf
Jul 10 14:07:03 <stuk_gen> what is the difference from yocto and angstrom?
Jul 10 14:08:27 <khem> angstrom is a distribution based on OE, Yocto project is collection of projects supporting embedded linux ecosystem
Jul 10 14:09:09 <khem> in those projects one is embedded linux build system which is names poky, and poky is also based on OE
Jul 10 14:10:30 <stuk_gen> like bitbake from angstrom?
Jul 10 14:11:01 <khem> bitbake is task executor which is core of OE
Jul 10 14:11:18 <khem> so yes anyone who uses OE,uses bitbake as well
Jul 10 14:11:37 <stuk_gen> mmm ok... so yocto is not a distribution,
Jul 10 14:14:00 <khem> its is not but it has one
Jul 10 14:15:33 <stuk_gen> khem: isn't a demo image for beagleboard xM?
Jul 10 14:16:19 <bluelightning> awafaa: you are now using = instead of ?=  ?
Jul 10 14:16:40 <awafaa> bluelightning: yup
Jul 10 14:17:25 <bluelightning> awafaa: do you still get the same when you do bitbake -e | grep PREFERRED_PROVIDER_virtual/kernel
Jul 10 14:18:23 <khem> stuk_gen: ?
Jul 10 14:18:50 <awafaa> bluelightning: yes, is there anyway of asking bitbake where it is pulling PREFERRED_PROVIDER_virtual/kernel from?
Jul 10 14:19:16 <stuk_gen> kenws: is there a demo image to boot on a begleboard xM?
Jul 10 14:19:20 <bluelightning> awafaa: we do not have variable tracking features yet, though some patches to add that were proposed
Jul 10 14:19:35 <bluelightning> awafaa: you can usually find these things pretty easily using "git grep"
Jul 10 14:20:31 <stuk_gen> khem: is there a demo image to boot on a begleboard xM?
Jul 10 14:21:40 <khem> stuk_gen: angstrom does have some images check angstrom website or ml
Jul 10 14:23:00 <stuk_gen> khem: ok but angstrom..not yocto
Jul 10 14:23:41 <khem> yes
Jul 10 14:25:36 <awafaa> bluelightning: the only other instance i can see in the 4 layers im using is meta/conf/machine/include/qemu.inc:PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
Jul 10 14:25:49 <awafaa> i thought = trumps ?=
Jul 10 14:26:25 <bluelightning> awafaa: it does, always... so that cannot be it
Jul 10 14:28:06 <awafaa> should i have "inherit kernel" in my recipe? or is that only if im appending?
Jul 10 14:29:14 <bluelightning> awafaa: you definitely want that yes
Jul 10 14:29:47 <awafaa> ok, i wasn't sure if that was what would be pulling in the yocto kernel
Jul 10 14:33:07 <Crofton|work> khem poky is oe-core + meta-yocto :)
Jul 10 14:34:07 <Crofton|work> hmm, maybe meta-yocto would be better called meta-poky ....
Jul 10 14:35:36 <JaMa> that would be even more confusing with poky repo IMHO
Jul 10 14:35:49 <bluelightning> awafaa: I just tried to make your layer work but I'm struggling...
Jul 10 14:38:10 <awafaa> bluelightning: somehow im not overly surprised :(
Jul 10 14:39:31 <bluelightning> awafaa: it would help if you didn't mandate a random OE-Core revision
Jul 10 14:39:48 <bluelightning> awafaa: I realise that's what kenws is doing in his instructions and it's just as wrong there IMHO
Jul 10 14:40:24 <awafaa> bluelightning: yup, there is a way to use master from all parties - https://wiki.linaro.org/KenWerner/Sandbox/OpenEmbedded-Core has been updated
Jul 10 14:41:20 <bluelightning> awafaa: er, no wonder this is not working
Jul 10 14:41:38 <awafaa> bluelightning: oh?
Jul 10 14:41:50 <bluelightning> awafaa: you recommend setting MACHINE = "qemuarmv7a", yet your custom machine config file is called "vexa15"
Jul 10 14:42:06 <bluelightning> so naturally that file is never read
Jul 10 14:44:28 <bluelightning> assuming you want to use the vexa15 machine you will need to fully specify the machine.conf as well
Jul 10 14:45:10 <awafaa> or rename the machine config?
Jul 10 14:45:13 <bluelightning> what I mean is, currently vexa15.conf is a little empty
Jul 10 14:46:02 <bluelightning> awafaa: the question is what are you trying to do? are you trying to introduce a new machine or override an existing one?
Jul 10 14:47:12 <awafaa> bluelightning: well, more like override i suppose
Jul 10 14:48:51 <awafaa> bluelightning: i want to reuse the qemuarmv7a machine but use my kernel
Jul 10 14:49:33 <bluelightning> awafaa: it's probably easiest to just instruct people to set PREFERRED_PROVIDER_virtual/kernel in their local.conf in that case
Jul 10 14:52:31 <awafaa> ah excellent
Jul 10 14:53:21 <awafaa> bluelightning: thanks for that, it "appears" to be working. all i need to do now is work out how to do device tree
Jul 10 14:55:12 <bluelightning> brb switching networks
Jul 10 14:59:30 * davest is on the technical team meeting
Jul 10 14:59:56 * halstead is on the technical team meeting.
Jul 10 15:00:23 * RP__ is there too
Jul 10 15:00:33 * pidge is on the technical team meeting
Jul 10 15:00:37 * rburton too
Jul 10 15:00:45 * sgw Saul is on ttm
Jul 10 15:00:52 * tomz1 too
Jul 10 15:00:55 * Jefro is here too
Jul 10 15:01:12 <bluelightning_> Paul and Jim are here
Jul 10 15:01:18 * zenlinux ScottG is here
Jul 10 15:01:34 * nitink is on TTM too
Jul 10 15:01:57 * zeddii_home needs to change locations and won't be on the call
Jul 10 15:01:59 * zeddii_home flees
Jul 10 15:02:02 <jmpdelos> polk is here
Jul 10 15:02:09 <Song_> YPTM: The Yocto Project Technical Meeting is starting now. Please let me know who joined the call
Jul 10 15:02:13 <nitink> yttm
Jul 10 15:02:24 <nitink> YPTM
Jul 10 15:02:29 <halstead> YTTM: Michael Halstead present.
Jul 10 15:04:36 <RP> davest: in the case of pidge, it won't as she's hiding her real name -)
Jul 10 15:04:55 <davest> RP: good point
Jul 10 15:05:17 <bluelightning> davest: or you where it says "purple" ;)
Jul 10 15:05:52 * darknighte is dialing in to the tech meeting
Jul 10 15:06:25 <davest> bluelightning: but everyone knows who davest is... :-)
Jul 10 15:06:31 * darknighte can't find the dial ininfo...
Jul 10 15:06:53 <davest> 1.972.995.7777x76994298#
Jul 10 15:07:08 <davest> darknighte: above is the phone / pass code
Jul 10 15:07:15 <bluelightning> davest: right :)
Jul 10 15:07:26 <Crofton|work> telecons suck
Jul 10 15:07:58 <darknighte> davest: thx.  having trouble
Jul 10 15:08:38 <darknighte> dialing in, that is.
Jul 10 15:08:44 <Crofton|work> oops, forgot the :)
Jul 10 15:09:01 <davest> YTTM is hard to remember...
Jul 10 15:09:09 <davest> :-)
Jul 10 15:09:17 <RP> Song_: YPTM: Master Status
Jul 10 15:09:18 <Song_> YPTM: any opens for the technical team meeting?
Jul 10 15:09:30 * darknighte makes rude noises at google voice
Jul 10 15:20:29 <msm> fray: around?
Jul 10 15:24:38 <davest> YTFM: lots of clicking on the bridge?
Jul 10 15:26:40 <darknighte> davest: I am getting a lot of clicks/pops.
Jul 10 15:27:10 <bluelightning> YPTM: Jim and I just rejoined, some room conflict
Jul 10 15:28:15 <davest> YPTM: Turns out pidge was the clicker... she went on mute. Her boss needs to buy her a decent phone
Jul 10 15:29:27 <bluelightning> davest: ah, so it wasn't the authorities wiretapping us then
Jul 10 15:29:55 <davest> bluelightning: shhhh - Patriot Act
Jul 10 15:30:29 <Song_> YPTM: https://wiki.yoctoproject.org/wiki/Yocto_1.3_Schedule#M2_.28June_11.2C_2012_to_July_27.2C_2012_--_7_weeks:_planning_done_in_week_1.2C_development_week_1-4.2C_stabilization_week_5-7.2C_release:_week_7.29
Jul 10 15:30:44 <darknighte> RP: you were quite faint.  what were you looking for volunteers for?
Jul 10 15:31:24 <RP> darknighte: SWAT Team - helping look after the autobuilder and ensure someone works on failures
Jul 10 15:32:13 <darknighte> RP: thx.
Jul 10 15:32:20 <pidge> davest: the clicking was only happening when my boss was talking.
Jul 10 15:35:24 <bluelightning> FYI it's my turn on the SWAT team this week
Jul 10 15:36:18 <ccssnet> swat team eh?
Jul 10 15:42:58 * darknighte cringes at that last audio jump
Jul 10 15:43:01 * nitink 's voice did not go through
Jul 10 15:44:16 <RP> nitink: no, didn't hear you
Jul 10 15:44:53 <pidge> ccssnet: yes. basically build failure triage. see: bit.ly/MfVDwS
Jul 10 15:45:00 <nitink> RP: looks like my VOIP setup has some issue
Jul 10 15:46:07 <bluelightning> YPTM: actually the fix for 2595 is fairly self-contained, that could possibly go in
Jul 10 15:46:38 <ccssnet> pidge: interesting
Jul 10 15:47:31 <ccssnet> welll ill be back later. bike time
Jul 10 15:47:48 <darknighte> bluelightning: is it being held out?
Jul 10 15:48:28 <bluelightning> darknighte: it's currently together in a series Richard was saying which isn't appropriate to pull in
Jul 10 15:48:50 <bluelightning> hmm sentence a bit mangled there sorry
Jul 10 15:49:03 <darknighte> I got the gist.
Jul 10 15:49:26 <darknighte> no worries.  I am having particularly bad audio today, so I am not getting everything.
Jul 10 15:53:26 <Song_> YPMTM: https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.3_Status#Milestone_2
Jul 10 15:56:54 <darknighte> halstead: moved DNS too.
Jul 10 15:58:08 * halstead nods.
Jul 10 15:58:24 <halstead> Song_, Did we rotate SWAT?
Jul 10 15:58:42 <Song_> YPTM: thanks for joining the meeting, guys. Bye
Jul 10 15:59:37 <Song_> halstead: yes, we did. From Jessica to Nitin
Jul 10 15:59:47 <Song_> Nitin: are you here?
Jul 10 16:00:16 <halstead> Thank you Song_ I just missed it in my notes.
Jul 10 16:00:24 <bluelightning> Song_: I thought I already agreed to take it last week...
Jul 10 16:00:50 <bluelightning> (since Jessica filled in for me last week)
Jul 10 16:01:27 <Song_> bluelightning: ok, so you will be on for the SWAT team this week?
Jul 10 16:01:39 <bluelightning> Song_: that's what I'd assumed yes
Jul 10 16:02:09 <Song_> bluelightning: great. Thank you. I'll send an email to Nitin to clarify this
Jul 10 16:06:36 <sgw> RP: you still around?  Do we need to sync on what's in master, I guess I need to create a paired down MUT for RC1 (tomorrow morning)
Jul 10 16:08:54 <RP> sgw: I am
Jul 10 16:11:25 <bluelightning> RP: do you want me to send out the fix for 2595 alone for M2?
Jul 10 16:11:27 <bluelightning> RP: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=paule/rootfs2&id=dd919af7ec7b54e382415d0118ca628e85a171d0
Jul 10 16:12:11 <bluelightning> the inner patch looks complicated but all it does is enclose the existing config loading code in a conditional
Jul 10 16:12:51 <RP> bluelightning: might as well
Jul 10 16:22:57 <bluelightning> done
Jul 10 16:38:43 <sgw> bluelightning: are you the keeper of meta-baryon or is it getting "self maintained", meaning anyone can push to it?
Jul 10 16:39:08 <bluelightning> sgw: I'd prefer to be the one to push changes to it
Jul 10 16:39:26 <bluelightning> I hope to have some time to work on it in M3/M4
Jul 10 16:39:33 <sgw> Ok, just checking, not sure if you saw Kevin's changes, he is updating it
Jul 10 16:39:35 <RP> bluelightning: thanks, I pulled that in
Jul 10 16:40:01 <bluelightning> sgw: er, no, I did not see those...
Jul 10 16:40:34 <bluelightning> sgw: when were those posted?
Jul 10 16:43:42 <sgw> bluelightning: got stuck in the moderator queue and then disappear after I approved it!
Jul 10 16:43:53 <sgw> I saw it in the moderator queue!
Jul 10 16:44:10 <bluelightning> ah, well that explains why I did not see it...
Jul 10 16:56:56 <RP> sgw: I update oe-core and poky master-next with nitin's latest changes
Jul 10 17:06:13 <sgw> RP: thanks
Jul 10 17:18:44 <strassek> sgw: should I try to resend that patch?
Jul 10 17:19:26 <sgw> strassek: yes please
Jul 10 17:19:39 <sgw> strassek: seems to have gotten stuck someplace
Jul 10 17:21:00 <strassek> sgw: ok it should be on its way
Jul 10 17:23:35 <sgw> strassek: have you added your self to that list yet?
Jul 10 17:25:26 <mranostay> sometimes the tubes get a little clogged
Jul 10 17:27:26 <strassek> sgw: I added my linux.intel.com account. I'll start sending from there.
Jul 10 17:27:39 <sgw> strassek: that would make the difference!
Jul 10 17:36:59 <bluelightning> sgw / strassek: ok, now I see it
Jul 10 17:38:25 <bluelightning> merged
Jul 10 17:39:38 <sgw> bluelightning: my understanding is that strassek is going to be updating the recipes of meta-baryon to 1.3 (correct)?  Was there any addition work/bugs needed ?  maybe you 2 should sync up.
Jul 10 17:40:56 <bluelightning> sgw: yes that sounds like a good idea
Jul 10 17:47:39 <pidge> sgw: Yes, that's correct.
Jul 10 18:47:25 <khem> ERROR: Function failed: Fetcher failure for URL: 'http://download.savannah.gnu.org/releases/quilt/quilt-0.60.tar.gz'. Checksum mismatch!
Jul 10 18:47:28 <khem> File: '/home/kraj/poky/build/downloads/quilt-0.60.tar.gz' has md5 checksum 7f784328f2616ca71e8ff76889acba5f when 058a08a9b626bdec9ec8c519dc92158c was expected
Jul 10 18:47:31 <khem> File: '/home/kraj/poky/build/downloads/quilt-0.60.tar.gz' has sha256 checksum 8d6adbcc202e3ecc01c129e424fa2f34188b349157e7987326e0889a7c3757f6 when 3d72a292e432beb9a73f9d0acfe3a77c9b4d7e42209919bb244e9958c7cfe64b was expected
Jul 10 18:47:35 <khem> ERROR: Logfile of failure stored in: /home/kraj/poky/build/tmp/work/x86_64-linux/quilt-native-0.60-r0/temp/log.do_fetch.2455
Jul 10 18:47:38 <khem> anyone seeing it ?
Jul 10 18:50:07 <khem> seeems removing tar helped
Jul 10 18:50:19 <khem> this was fresh build btw. no dldir present
Jul 10 19:01:21 <sgw> khem: maybe a bad download?
Jul 10 19:03:35 <mranostay> gamma rays hit the tranmission line? :)
Jul 10 19:58:09 <Jefro> Here is a question that comes up occasionally:  say I want to use a different kernel with my own configuration. I create the kernel config & sources, and write a recipe for it.  What is the best way to tell BitBake to use my kernel instead of the "normal" one? Do I need to create a layer?
Jul 10 19:59:59 <msm> PREFERRED_PROVIDER_virtual/linux = "your-recipe-for-kernel"
Jul 10 20:00:31 <Jefro> msm awesome, thanks
Jul 10 20:01:08 <kergoth> virtual/kernel
Jul 10 20:02:08 <Jefro> would there be any advantage workflow-wise to creating a layer instead?
Jul 10 20:04:14 <msm> yes, you might still create a layer and add PREFERRED_PROVIDER_virtual/kernel to your local.conf
Jul 10 20:04:20 <msm> the layer would be for your kernel recipe
Jul 10 20:04:29 <msm> if you needed to add one
Jul 10 20:12:12 <msm> sgw: im being nice… i made a branch on poky-contrib
Jul 10 20:12:18 <msm> mattsm/master
Jul 10 20:12:24 <msm> with these patches i've been sending
Jul 10 20:21:38 <sgw> msm, that's great thanks.
Jul 10 20:30:55 <Jefro> msm & kergoth - thanks for the info. I have updated the FAQ: https://wiki.yoctoproject.org/wiki/FAQ
Jul 10 20:31:10 <Jefro> will need a separate usage FAQ soon
Jul 10 20:42:40 <ag_> sgw: Hello.
Jul 10 20:42:56 <sgw> ag_: Hi there
Jul 10 20:43:39 <sgw> fray: you around at all this week?
Jul 10 20:43:46 <ag_> sgw: Any idea why RP asked me if i want to have busybox machine specific? We concluded that that script should be installed only if rtc is present in MACHINE_FEATURES>
Jul 10 20:44:54 <ag_> that the*
Jul 10 20:45:11 <Crofton|work> any thoughts on why libtool will not build in oe-core?
Jul 10 20:57:46 <khem> ag_: yes that makes the recipe machine specific
Jul 10 21:08:29 <bizhanMona> What is git info for Ivy bridge/Sandy Bridge ? and whether Q77 chipset is supported?
Jul 10 21:13:17 <Crofton|work> hmm restarting build solves libtool build fail
Jul 10 21:14:17 <darknighte> msm: quick question.  does meta-fsl on git.yoctoproject.org have the latest sdk 1.2 bits?
Jul 10 21:14:40 <msm> darknighte: im actually syncing up meta-fsl-ppc w/ all release
Jul 10 21:14:57 <msm> darknighte: with one patch (the multi-dtb patch) it should work on the denzil branch
Jul 10 21:16:37 <darknighte> msm: so, what additional stuff is avaible on git.freescale.com, if any?
Jul 10 21:19:15 <bizhanMona>  What is git info for Ivy bridge/Sandy Bridge ? and whether Q77 chipset is supported?
Jul 10 21:20:30 <msm> darknighte: nothing really
Jul 10 21:20:39 <msm> darknighte: nothing that's trying to be hidden anyways
Jul 10 21:20:50 <msm> the ISO release (not on git) contains more stuff
Jul 10 21:20:58 <msm> the meta-fsl-ppc-private layer
Jul 10 21:21:02 <ag_> khem: Indeed. Why is this wrong?
Jul 10 21:21:49 <khem> ag_: there has to be lot of reasons for making a package machine specific
Jul 10 21:22:47 <ag_> khem: I realize that this is not a machine specific package but i don't see any other way to install the script taking MACHINE_FEATURES into consideration.
Jul 10 21:24:05 <khem> is it possible to strip this out into a separate package which just install script
Jul 10 21:26:12 <ag_> khem: Yes it is possible as this script is installed via local directory.
Jul 10 21:26:49 <ag_> But as well this script should be in only if busybox is configured with hwclock.
Jul 10 21:27:47 <ag_> So busybox should rdepend on the new package only if is configured with hwclock.... hmmm... ok. It's reasonable.
Jul 10 21:40:18 <ag_> khem: Well... another option would be to add this scripts in initscripts package.
Jul 10 21:40:22 <ag_> WOuld that be better?
Jul 10 21:40:46 <ag_> script*
**** ENDING LOGGING AT Wed Jul 11 02:59:58 2012

**** BEGIN LOGGING AT Wed Jul 11 02:59:58 2012
Jul 11 07:45:23 <stuk_gen> i'm trying getting psplash from oe, but i get error ERROR: Function failed: Fetcher failure for URL: 'git://git.yoctoproject.org/psplash-angstrom;procotol=git" Unable to fetch URL from any source
Jul 11 07:51:58 <stuk_gen> there isn't downloads.yoctoproject.org/mirror/sources/git2_git.yoctoproject.psplash-angstrom.tar.gz
Jul 11 08:44:40 <RP> stuk_gen: That would be something to ask the angstrom people about
Jul 11 08:44:41 <ant_work> RP: about psplash/rotation maybe   http://pastebin.com/VH4099K2
Jul 11 08:44:57 <ant_work> RP: It's ok as .bbappend but maybe is worth in oe-core? With more checks (for headless devices) ofc.
Jul 11 08:46:23 <stuk_gen> RP: or to change definitly the distro
Jul 11 08:46:28 <RP> ant_work: Its certainly something we need to look at...
Jul 11 09:20:18 <ant_work> RP: even better  sed -n 's/^[ \t]DISPLAY_ORIENTATION[ \t]*//p' ${S}/machconfig | tr -dc '[0-9]' > ${S}/rotation  catches all whitespaces issues (beg,mid,end)
Jul 11 09:20:39 <ant_work> I'll send an RFC + patch for oe-core
Jul 11 09:21:58 <RP> ant_work: My only convern was I think the idea in formfactor was to try and avoid 101 files for things like this...
Jul 11 09:22:54 <ant_work> I'v struggled trying to avoid a new recipe machine-specific in layer. The .bbappend is fine, though.
Jul 11 09:26:12 <ant_work> RP: it can as well be parsed at runtime from cmdline  (fbcon=rotate:1)
Jul 11 09:27:12 <ant_work> but well, we have machine-specific formfactor and it's better done at build time imho
Jul 11 09:28:30 <ant_work> again, not much hassle to add a .bbappend for formfactor which doesn't change frequently
Jul 11 09:34:44 <ant_work> RP: or you make psplash DEPEND on formfactor and do the check directly on machconfig (get rid of /etc/rotation)
Jul 11 10:12:17 <ag_> Hello everybody!
Jul 11 10:13:03 <ag_> Any tests done on COMPRESS_CMD_xz? Something's fishy there...
Jul 11 10:16:41 <ant_work> ag_: I'm using it for kernel and cpio
Jul 11 10:16:56 <ant_work> don't see issues
Jul 11 10:18:08 <ant_work> (XZ_COMPRESSION_LEVEL = "-2e" here)
Jul 11 10:19:22 <ag_> I'm talking about using it with image_types.
Jul 11 10:19:33 <ant_work> ok, INITRAMFS_FSTYPES ?= "cpio.gz cpio.lzma"
Jul 11 10:19:56 <ag_> COMPRESS_CMD_xz = "xz -f -k -c ${XZ_COMPRESSION_LEVEL} --check=${XZ_INTEGRITY_CHECK} ${IMAGE_NAME}.rootfs.${type}"
Jul 11 10:20:08 <ag_> ant_work: You are using the same command above?
Jul 11 10:20:25 <ant_work> if th eone in oe-core, yes
Jul 11 10:21:09 <ag_> Fair. Then i have two problems here / misunderstandings.
Jul 11 10:21:13 <ant_work> hm... in fact I'm doing lzma
Jul 11 10:21:19 <ag_> 1. why -c ?
Jul 11 10:21:34 <ag_> This will make the output on stdout.
Jul 11 10:21:55 <ag_> So no compressed file will be available after this.
Jul 11 10:22:32 <ag_> 2. why -k and then rm?
Jul 11 10:23:51 <ag_> ant_work: lzma has different command. Didn't test that.
Jul 11 10:24:43 <ant_work> ag_: http://cgit.openembedded.org/openembedded-core/commit/meta/classes/image_types.bbclass?id=419ddab8266ecfd6da1841d38a451a9fc5be49b0
Jul 11 10:25:08 <ag_> In fact i was searching for otavio.
Jul 11 10:25:17 <ag_> But that commit is just adding a -f.
Jul 11 10:25:24 <ant_work> seems he has tested it, then
Jul 11 10:25:27 <ag_> uh sorry and -c
Jul 11 10:25:45 <ag_> no. -c was there before
Jul 11 10:26:03 <ant_work> I mean, he tested -c and added -f afterwards :)
Jul 11 10:26:56 <ag_> Doesn't work. :)
Jul 11 10:27:01 <ag_> otavio: Ping. :)
Jul 11 10:32:03 <ant_work> ag_: anyway, -c pairs with      > ${IMAGE_NAME}.rootfs.${type}.gz
Jul 11 10:32:17 <ant_work> or am I wrong?
Jul 11 10:32:30 <ag_> Should be. But don't see anything like that/
Jul 11 10:32:57 <ant_work> heh
Jul 11 10:33:13 <ag_> ant_work: But the easy way would be to remove -c.
Jul 11 10:33:29 <ag_> That will just append xz to the filename.
Jul 11 10:33:43 <ant_work> seems so, as I said I only deploy cpio.lzma so it's a bit different
Jul 11 10:33:47 <ag_> ant_work: Wanna know the behavior now?
Jul 11 10:33:58 <ag_> ant_work: The whole compressed data ends up in.... log :)
Jul 11 10:34:18 <ant_work> Otavio will be online later I think
Jul 11 10:34:31 <ag_> ant_work: I know. No worries.
Jul 11 10:35:03 <ant_work> this class has been repeatedly wrecked, though ;)
Jul 11 10:35:17 * ant_work heading for a sandwich
Jul 11 10:35:30 <ag_> :)
Jul 11 11:04:55 <RP> ant_work: "repeatedly wrecked"?
Jul 11 11:05:13 <RP> ant_work: If something is broken, please do file a bug...
Jul 11 11:24:08 <ant_work> RP: I was referring to some commits of mine ;)
Jul 11 11:25:42 <ag_> :)
Jul 11 11:30:56 <ag_> RP: Don't know is a bug creation is needed. The fix is simple and i will submit patch.
Jul 11 11:31:00 <ag_> if*
Jul 11 11:31:15 <RP> ag_: that is fine, I was more referring to ant_work's comments
Jul 11 11:32:14 <ag_> RP: ant helped me a bit.
Jul 11 11:39:57 <ant_work> RP: ag_: all started with 38334ac when with my patch we imported Otavio's work from OE
Jul 11 11:45:20 <ant_work> then b7e4ed4 introduced the issue (and -I realize now- modified cpio.lzma so that it doesn't use XZ_COMPRESSION_LEVEL anymore)
Jul 11 11:46:26 <ant_work> (factor of compression 7 happens to be ok even for 32MB RAM devices so I never noticed it...)
Jul 11 11:48:02 <ant_work> ag_: while you're on it, pls verify both xz and lzma, please. Nowaday kernel supports xz so lzma is indeed obsolete for cpio's, I know :)
Jul 11 12:17:24 <Orre> I know there is a bug which stops us from using MIPS Little endian in poky-denzil-7.0 - is there any issues if I use ARM little endian or is that fine?
Jul 11 12:47:48 <otavio> ag_: ant_work: hi
Jul 11 12:49:35 <ag_> otavio: I confirmed with you that this is a problem. So patch is coming tonight.
Jul 11 12:50:49 <Orre> ag_: Was that a comment to me or was it to otavio? If it wasn't to me, do you happen to know if there are any issues to use ARM little endian in Yocto 1.2 poky-denzil-7.0?
Jul 11 13:03:20 <Orre> Also, does anyone know if there are any examples of a recipe for an external toolchain?
Jul 11 13:10:10 <seebs> Heya.
Jul 11 13:10:15 <seebs> There is an external toolchain recipe in oe-core.
Jul 11 13:10:23 <seebs> For the Mentor Graphics/Code Sourcery toolchain.
Jul 11 13:10:31 <seebs> We are using a hacked-up and slightly older variant of it.
Jul 11 13:10:42 <Orre> oe-core?
Jul 11 13:11:08 <Orre> It's included in the OE core repo?
Jul 11 13:11:51 <ag_> Orre: Was intended for otavio. Anyway i'm not aware any issues with little endian... sorry.
Jul 11 13:12:07 <denisATeukrea> hmmm hi
Jul 11 13:12:32 <denisATeukrea> what's the difference between U:320x240d-60 and U:320x240p-60 in /sys/class/graphics/fb0/modes
Jul 11 13:12:33 <Orre> ag_: You weren't aware of the issues with little endian on ARM or weren't you aware of any issues with little endian at all - not even on MIPS?
Jul 11 13:15:04 <ag_> RP: What will be the next poky version? Will it be another branch or a tag?
Jul 11 13:15:19 <ag_> Orre: on ARM
Jul 11 13:15:31 <Orre> ag_: Thanks!
Jul 11 13:16:35 <denisATeukrea> Orre, all the machines I know are ARM little endian, it's big endian that is rather uncommon in ARM
Jul 11 13:16:48 <B4gder> or even very uncommon =)
Jul 11 13:17:36 <ag_> confirm
Jul 11 13:17:52 <RP> ag_: well, the next milestone release is 1.3 M2
Jul 11 13:19:03 <ag_> RP: Thanks.
Jul 11 13:19:18 <ag_> RP: I found the calendar in the meanwhile. Thanks again.
Jul 11 13:19:35 <Orre> denisATeukrea: There are issues with little endian on MIPS and some places it was stated that there are issues with "Little endian" - so before I continued I wanted to make sure there's no issues with ARM little endian and the error is solely for MIPS little endian.
Jul 11 13:20:07 <B4gder> rumours say x86 works rather fine in little endian too =)
Jul 11 13:21:09 <denisATeukrea> Orre, what error do you have?
Jul 11 13:21:53 <Orre> denisATeukrea: The MIPS error is that if you bake a MIPS little endian it still become a big endian, according to the mailing list.
Jul 11 13:22:40 <denisATeukrea> just look at the errors you have, else it's endless.....
Jul 11 13:25:24 <Orre> I just need to know what I can't use as it's pointless if I would be forced to build custom linux, custom toolchain, bake the image, change the image and then try to use it on a custom board and then see that I can't use said custom board - forcing me to do everything again.
Jul 11 13:26:56 <Orre> Oh, and do anyone know when Pidge get online?
Jul 11 13:29:43 <rburton> Orre: she's in -0800, so I wouldn't expect for a few more hours
Jul 11 13:29:59 <rburton> (pidge is beth, right?)
Jul 11 13:30:11 <rburton> morning walters
Jul 11 13:30:55 <Orre> yes, I believe she is beth. Thanks, will see if I can be online later tonight or if I will have to use the mailing list to reach her.
Jul 11 13:34:26 <awafaa> could someone point me to docs to build a dtb with yocto please? i've looked at both the bsp guide and kernel manual but can't work it out
Jul 11 13:34:55 <awafaa> my dts and dtsi live in a sperate git tree to the kernel source, just for added fun
Jul 11 13:40:28 <Orre> When "$bitbake meta-toolchain" I get that it can't find the user and then: "tar (child): /home/user/poky-denzil-7.0/build/tmp/deploy/sdk/poky-eglibc-x86_64-arm-toolchain-1.2.tar.bz2: Cannot open: Permission denied" on task 1829. Anyone happen to know what to do? I tried to chmod the tar but that didn't help.
Jul 11 13:42:21 <walters> hi rburton
Jul 11 13:43:21 <rburton> Orre: sounds like you passwd is bust, or something.
Jul 11 13:43:23 <walters> rburton, btw when you get a chance, i'd be pretty curious to hear your thoughts on ostree; have you seen it?  the perspective of someone who has about equally long experience with gnome as me, plus you have more yocto experience
Jul 11 13:43:40 <rburton> walters: i've heard about it, and it sounds crazy in a good way :)
Jul 11 13:44:07 <walters> it's not too hard to actually install, except if you have grub2
Jul 11 13:44:43 <rburton> i've got crypto rootfs, i'm not touching my boot loader, and that's old grub :)
Jul 11 13:44:58 <walters> oh grub1 is easy, it's just another line in grub.conf
Jul 11 13:50:40 <Orre> rburton: Any specific way to fix that or a least see if passwd is bust or not?
Jul 11 13:51:18 <rburton> Orre: well, what's moaning about the user
Jul 11 13:51:24 <rburton> if you run whoami, what happens?
Jul 11 13:51:46 <Orre> The user which Yocto couldn't find during the build.
Jul 11 13:52:05 <Orre> And I have the group which Yocto couldn't find during the build
Jul 11 13:53:01 <rburton> how odd
Jul 11 13:53:16 <RP> rburton: keep in mind pseudo is involved in that tarball creation
Jul 11 13:53:40 <RP> Orre: what was the earlier error about "can't find a user"?
Jul 11 13:53:58 <Orre> I can make a ordinary bitbake core-image-minimal, it gets problematic when applied to the tarball - probably because the tarball is made with root. Though I can't bitbake as root as obvious reasons.
Jul 11 13:54:24 <rburton> RP: i still need to look up why pseudo is better than fakeroot ...
Jul 11 13:54:35 <RP> Orre: There is something called pseudo which should let things emulate root. You should never need to build as root
Jul 11 13:54:59 <RP> rburton: We save state between tasks. fakeroot can't cope with that
Jul 11 13:55:04 <Orre> RP: "warning: user <user> does not exist - using root", "warning: group <group> does not exist - using root"
Jul 11 13:55:19 <rburton> RP: fair enough, thanks
Jul 11 13:55:22 <RP> rburton: massive simplification but pseudo is light years ahead
Jul 11 13:56:36 <bluelightning> rburton: https://github.com/wrpseudo/pseudo/wiki/WhyNotFakeroot
Jul 11 13:56:52 <RP> Orre: what is odd is that the main rootfs is created using a similar approach so for rootfs to work but not the toolchain is odd
Jul 11 13:58:13 <rburton> bluelightning: ah, thanks
Jul 11 13:59:03 <RP> rburton: Subsequent to that being written, there were also "bitbake" specific optimisations made to pseudo such as being able to load into memory as a preload disabled, then come to life
Jul 11 14:17:17 <Orre> Hadn't heard of pseudo earlier, so read up on it, sounds quite nice. Though I can't find any way to get it? It's not included in debian repository - does it follow with the poky distro?
Jul 11 14:22:31 <sgw> RP: just want to check in quickly, looks like we are closing in on an RC1 build once we get the kernel srcrev's from zeddii, correct?
Jul 11 14:30:46 <RP> sgw: yes, waiting on those really. I did pull in some bugfixes
Jul 11 14:30:53 <RP> sgw: been testing them locally
Jul 11 14:32:52 <sgw> RP: yup, saw that.
Jul 11 14:33:23 <kergoth> hmm, this low overhead python profiler from dropbox is interesting
Jul 11 14:34:27 <sgw> bluelightning: looking at that tar packaging issue and it's strange there is a "rmdir ${D}${bindir}/" in a do_install_append(), I wonder if the trailing '/' is goofing something up, doing a test build now.
Jul 11 14:35:41 <bluelightning> sgw: it is surprising this has only come up now too
Jul 11 14:36:05 <sgw> bluelightning: exactly, I am trying to figure out what's happening.
Jul 11 14:36:29 <bluelightning> sgw: if this is MUT (I can't recall), is it at all related to the automake upgrade?
Jul 11 14:36:54 <sgw> hmm, possibly yes it was MUT since it was marked with an Error
Jul 11 14:37:29 <sgw> bluelightning: what about the unistring error on ppc this morning, I missed that last night as I thought most of the failures where perf related.
Jul 11 14:38:16 <bluelightning> sgw: I thought that was one of the recipes patched by nitin's latest patch series; did that go into MUT already?
Jul 11 14:41:20 <sgw> bluelightning: yes, in mut, sorry my confusion, your nightly-x86 for MUT email leapfrogged the master nightly failure so I thought I it was in master (I did not see the am/pm times)
Jul 11 14:47:27 <bluelightning> sgw: I'm thinking we ought to actually include the branch or some reference to it in the actual title of the message, I keep getting mixed up too
Jul 11 14:50:27 <rburton> Orre: poky will built pseudo when it first starts up
Jul 11 14:57:49 <sgw> zeddii zeddii_home: is a beagleboard SRCREV missing?
Jul 11 14:58:01 * sgw -> Dr appt
Jul 11 15:05:29 <Crofton> bluelightning, wrt to the rpm converstaion yesterday
Jul 11 15:05:32 <Crofton> task_core_basic -> task_core_rpm;
Jul 11 15:05:36 <Crofton> wtf
Jul 11 15:06:19 <bluelightning> Crofton: did you by chance do a build with rpm and then switch to ipk?
Jul 11 15:13:25 <pidge> Orre: You rang?
Jul 11 15:18:05 <msm> fray: did you see my rpm patch?
Jul 11 15:18:46 <bluelightning> Crofton: ah, now I get it
Jul 11 15:18:57 <bluelightning> Crofton: task-core-basic is for LSB, which mandates rpm
Jul 11 15:19:16 <bluelightning> it should probably be renamed to make that more clear, I'll add that to my todo list
Jul 11 15:20:13 <bluelightning> mystery solved...
Jul 11 15:21:46 <ag_> Anybody seen this: rm: cannot remove `<Image-name>': Value too large for defined data type
Jul 11 15:21:50 <ag_> ?
Jul 11 15:26:09 <Crofton> this comes from core-image-minimal
Jul 11 15:26:13 <Crofton> seems not so minimal
Jul 11 15:26:23 <Crofton> lsb sounds dumb
Jul 11 15:28:19 <Crofton> feels like we should have core-image-minimal and core-image-lsb
Jul 11 15:33:31 <bluelightning> Crofton: core-image-minimal is definitely not supposed to be referring to that in any way
Jul 11 15:33:40 <bluelightning> Crofton: if it is, it's an unintentional bug
Jul 11 15:33:49 <Crofton> I'll have to go back an dlook what I did
Jul 11 15:35:10 <bluelightning> Crofton: does your dependency graph indicate what pulled in task-core-basic ?
Jul 11 15:35:35 <bluelightning> it may not if it came in via a variable that ended up in IMAGE_INSTALL though
Jul 11 15:36:40 <Crofton> no
Jul 11 15:37:07 <Crofton> is there a task-core-basic wo the rpm thing?
Jul 11 15:37:18 <Crofton> it seems like a usefiul task otherwise
Jul 11 15:37:55 <Crofton> this lsb thing has come up before
Jul 11 15:38:27 <bluelightning> Crofton: is task-base-extended along those lines?
Jul 11 15:38:46 <sgw> RP: you around to pull the kernel changes?  Then we can have pidge branch M2rc1
Jul 11 15:38:56 <bluelightning> Crofton: reworking tasks is something I'm supposed to be doing this cycle, haven't done anything on it yet though
Jul 11 15:39:18 <bluelightning> Crofton: concrete suggestions would be appreciated if you have any
Jul 11 15:39:29 <bluelightning> (I should probably send out an RFC)
Jul 11 15:39:35 <Crofton> from a quick skim, it loks like task_core_basic does a lot of useful things
Jul 11 15:39:38 <Crofton> yeah
Jul 11 15:39:46 <Crofton> have a seperate lsb task :)
Jul 11 15:40:26 <Crofton> or at least one for annoying lsb features
Jul 11 15:41:54 <bluelightning> hmm
Jul 11 15:43:03 <RP> sgw: yes, I'm here
Jul 11 15:46:40 <RP> sgw: I've pulled it in along with the update to 3.4 for the mpc machine
Jul 11 15:47:55 <sgw> RP: thanks, I will work with pidge to get a branch created and then we can get master moving again
Jul 11 15:48:13 <RP> sgw: well, we should probably autobuild test this
Jul 11 15:48:37 <sgw> RP: yes she will on the branch
Jul 11 16:24:00 <ag_> sgw: Any chance to have connman 1.2 soon?
Jul 11 16:24:13 <ag_> I would need it for genivi bit.
Jul 11 16:27:45 <pidge> M2 off and running.
Jul 11 16:28:02 <sgw> ag_: I will talk with the maintainer, I know we just updated to 1.0 not to long ago and there were some issues
Jul 11 16:28:32 <ag_> sgw: I sent him an email about this - to Cristi.
Jul 11 16:29:33 <ag_> sgw: Is Friday an unrealistic time-frame even if i'm offering myself to do it tomorrow?
Jul 11 16:30:07 <halstead> sgw, Is now good?
Jul 11 16:35:45 <sgw> halstead: probably not for you, you are going to have to reset the AB missed a kernel update
Jul 11 16:36:00 <sgw> pidge: halstead: can you stop the AB for M2, we have another missed pull
Jul 11 16:36:12 <halstead> sgw, Sure.
Jul 11 16:37:06 <pidge> sgw: in a meeting right now. halstead, you got this?
Jul 11 16:37:14 <halstead> pidge, Yes.
Jul 11 16:39:46 <halstead> sgw, Let me know when we are ready to start again.
Jul 11 16:40:41 <sgw> halstead: will do
Jul 11 16:40:51 <sgw> halstead: we are working on it.
Jul 11 16:41:18 <halstead> sgw, I'm also available to sync up when you are.
Jul 11 16:45:14 <ag_> sgw: Gotta go now.
Jul 11 16:50:20 <sgw> halstead: OK you can restart master for round 2 of M2rc1
Jul 11 16:50:32 * halstead starts.
Jul 11 17:33:52 <khem> do we have an option to prune DL_DIR
Jul 11 17:36:26 <sgw> khem: check if the cleanup-workdir script will work for you!
Jul 11 17:36:40 <khem> sgw: ok thanks I will check that out
Jul 11 17:36:58 <sgw> khem: it was updated recently based on some input from the list.
Jul 11 17:37:05 <khem> ok
Jul 11 18:21:26 <mranostay> can i use git submodules in a recipe?
Jul 11 18:33:45 <khem> mranostay: multiple repos but no submodules
Jul 11 21:05:54 <msm> when is 1.1.2 schedule to be released?
Jul 11 21:39:20 <khem> zeddii or zeddii_home around ?
**** ENDING LOGGING AT Thu Jul 12 02:59:58 2012

**** BEGIN LOGGING AT Thu Jul 12 02:59:58 2012
Jul 12 08:45:23 <bluelightning> morning all
Jul 12 08:56:30 <Orre> good morning bluelightning! :)
Jul 12 09:06:02 <bluelightning> hi Orre
Jul 12 10:02:10 <Orre> If I want to use the local mirror with Yocto packages, is there any way to get tar files which I can upload to a local mirror? Do "bitbake -c fetchall <image>" get all the tar files I need for said image, or do I need to do something else?
Jul 12 10:19:46 <bluelightning> Orre: that will do the job yes
Jul 12 10:25:51 <Orre> bluelightning: Where does the tars end up? I can't find all the 77 tars that should exist in a core-image-minimal anywhere?
Jul 12 10:30:31 <bluelightning> Orre: by default it's the downloads directory under your build directory
Jul 12 10:31:04 <bluelightning> otherwise, it's whatever DL_DIR is set to in your configuration
Jul 12 11:16:03 <Orre> Thanks bluelightning!
Jul 12 11:57:08 <ag_> Hello. Anybody can help me by pointing an image which includes x11-sato?
Jul 12 11:58:32 <ag_> Hmmm... lame question. core-image-sato it is. :)
Jul 12 13:00:22 <Orre> How up to date is this: http://www.crashcourse.ca/wiki/index.php/Yocto_FAQ#How_can_I_set_up_a_local_mirror_of_tarballs_to_save_download_time.3F and should INHERIT+="own-mirrors"  actually be that value or does "own-mirror" reflect something else?
Jul 12 13:01:40 <sd_> Hello. I need to use kernel 3.4. Shall I backport linux-yocto3.4 to denzil or use the master branch of yocto project? How stable is the master branch?
Jul 12 13:03:16 <Orre> If you just use denzil 7.0 shouldn't you easily be able to use a customized recipe which use 3.4 as kernel?
Jul 12 13:05:38 <sd_> Orre: the vanilla kernel works fine. But if I want to use the yocto-kernel with the meta branch and so.... It crashed during compilaton
Jul 12 13:08:39 <Orre> I haven't tested linux-yocto 3.4 so I don't know what the issue may be. Is there a reason you don't want to use the vanilla 3.4?
Jul 12 13:09:48 <sd_> I wanted to give a try to the meta brach on a real product
Jul 12 13:09:54 <sd_> it look like a good idea
Jul 12 14:21:06 <exosyst> Are there any tools for searching available recipes?
Jul 12 14:22:05 <exosyst> In my case, I want the modinfo tool - what would be the correct way to find the name or do I just add IMAGE_INSTALL_append=" modinfo " to my local.conf or is there a preferred way?
Jul 12 14:27:22 <bluelightning> exosyst: that should be provided by module-init-tools (or kmod in master) out of the box
Jul 12 14:28:25 <exosyst> bluelightning, So that's the package name I add to my IMAGE_INSTALL_append? How does one find that package? (modinfo was missing from my build btw)
Jul 12 14:29:23 <exosyst> bluelightning, For example, on fedora I can do yum provides modinfo and get some helpful output, is there anything similar for yocto (or even an online list)?
Jul 12 14:29:28 <bluelightning> exosyst: remind me, what version of the metadata are you using?
Jul 12 14:30:24 <exosyst> bluelightning, How do I find that?
Jul 12 14:30:51 <bluelightning> exosyst: I mean, edison/denzil/master ; tarball of a release, etc.
Jul 12 14:30:57 <exosyst> It was git
Jul 12 14:31:11 <bluelightning> so, you are using latest master then? or a branch/tag?
Jul 12 14:32:28 <exosyst> It was master at d4e26566 which was in April
Jul 12 14:34:03 <bluelightning> exosyst: are you using ubuntu as your host at all?
Jul 12 14:34:18 <exosyst> bluelightning, No. Fedora.
Jul 12 14:34:24 <bluelightning> ok
Jul 12 14:35:31 <bluelightning> hmm, well we had already moved to kmod at that point
Jul 12 14:35:53 <bluelightning> exosyst: are you building an image with package-management in IMAGE_FEATURES?
Jul 12 14:36:34 <exosyst> bluelightning, No, my image_features just has ssh-server-dropbear selected
Jul 12 14:36:50 <bluelightning> ok, so you can't query the packaging system at runtime then...
Jul 12 14:37:50 <exosyst> bluelightning, Oh no, nothing that fancy. I am thinking from the image provider side of things - I want to know what recipes I need to add in, to provide certain executables etc.
Jul 12 14:38:16 <exosyst> For example modinfo, I had no idea I had to install kmod to provide it - how would a layperson know that?
Jul 12 14:38:39 <bluelightning> exosyst: so kmod isn't installed at all?
Jul 12 14:38:54 <exosyst> bluelightning, It wasn't. I just added it to my IMAGE_INSTALL_append
Jul 12 14:39:08 <bluelightning> ok, right
Jul 12 14:39:10 <Crofton> any clues on fetching from a repo where I need to use a key passphrase?
Jul 12 14:39:25 <bluelightning> Crofton: ssh-agent ?
Jul 12 14:39:30 <exosyst> bluelightning, The only mod* function I had was modprobe. Kinda weird really for an embedded platform right?
Jul 12 14:39:46 <bluelightning> exosyst: presumably that was the one provided by busybox
Jul 12 14:39:50 <Crofton> hmm, didn't think about that
Jul 12 14:40:27 <bluelightning> Crofton: another alternative would be not to use a key passphrase, of course...
Jul 12 14:41:20 <exosyst> bluelightning, Yeah, modprobe is the busybox version
Jul 12 14:41:50 <Crofton> this is the classic fetcher, and I am also having url issues
Jul 12 14:41:56 <Crofton> need to stop wacthing the tour :)
Jul 12 14:44:43 <Crofton> also, protocol=file :)
Jul 12 14:44:45 <Crofton> hopefully
Jul 12 14:46:55 <exosyst> bluelightning, kmod did the trick. But ideally it should be something I can query right? Otherwise it becomes a query on a forum/IRC everytime? Can I grep something? Is there a tool to show what provides a binary/library?
Jul 12 14:58:08 <bluelightning> exosyst: we do have an online package querying tool, packages.yoctoproject.org
Jul 12 14:58:28 <bluelightning> unfortunately it does not allow querying by default output contents
Jul 12 14:58:41 <bluelightning> also it appears to be broken atm, I believe someone is working on it though
Jul 12 14:59:24 <exosyst> bluelightning, That's a shame as I imagine the information is out there. Is there a bug open for it? It'd be a good mini project to work on - I'm sure my boss would sign off on helping (time permitting)
Jul 12 15:00:13 <exosyst> bluelightning, If it could do something like 'yum provides foo' it would be amazing, hell I'd slap together a command line tool to do it if I knew the information sources!
Jul 12 15:01:28 <bluelightning> exosyst: the tricky thing is information about the content of the output packages is obviously only available after you've done a build, so it can only be collected from the output of an autobuilder really
Jul 12 15:04:16 <exosyst>  bluelightning That sucks a bit - is there not a build server somewhere that would generate that information as part of its daily work?
Jul 12 15:05:02 <exosyst> bluelightning, I mean, that can't be the only way to know that kmod provides modinfo for example?
Jul 12 15:05:27 <bluelightning> exosyst: yes I definitely think we could use the yocto project autobuilder for that
Jul 12 15:06:57 <bluelightning> I guess it's just one of those things where kmod has replaced module-init-tools and that's where *mod* tools were traditionally provided
Jul 12 15:07:12 <bluelightning> I agree though it's less than obvious
Jul 12 15:07:31 <exosyst> bluelightning, Are there any pointers on how someone could get started on helping? I can't do BSP stuff as I don't work for a vendor but the project surely could do with some manhours on other things?
Jul 12 15:08:24 <bluelightning> exosyst: in terms of general "getting started" type tasks we have the "janitor" bugs in the yocto project bugzilla
Jul 12 15:09:07 <exosyst> bluelightning, I'll have a look and see if there's anything to do with the package info side of things I can help with
Jul 12 15:22:10 <msm> anyone aware of a bbappend that adds a device tree somewhere?
Jul 12 15:22:20 <msm> looking for a quick example for someone so i dont have to work it all out myself ;) lazy me
Jul 12 15:23:39 <bluelightning> msm: someone else was asking the very same thing just the other day, so I think our docs might be lacking in that regard...
Jul 12 15:32:09 <msm> hmm, ok
Jul 12 15:32:17 <msm> maybe i will mail something the list
Jul 12 15:37:42 <ignus> Hello all, can anyone tell me if it would be possible to remove bash from core-image-minimal? usbutils seems to be the only thing which depends on it...
Jul 12 15:55:06 <bluelightning> ignus: hi
Jul 12 15:55:32 <bluelightning> ignus: how are things?
Jul 12 15:55:51 <bluelightning> ignus: it ought not to be in core-image-minimal at all - that's supposed to be busybox-based
Jul 12 15:56:10 <bluelightning> may be machine-dependent though
Jul 12 15:56:46 <ignus> bluelightning: hi, great thanks! how are you doing?
Jul 12 15:56:56 <bluelightning> ignus: great! :)
Jul 12 15:57:36 <ignus> bluelightning: it looks like bash is in our rootfs and seems to be making it quite a lot bigger than it should be..
Jul 12 15:58:52 <bluelightning> ignus: I believe all it takes is for a shell script to be present that starts with #!/bin/bash for a dependency on bash to be added (thanks to rpmdeps)
Jul 12 15:59:18 <ignus> bluelightning: any idea how i could find out if it _needs_ to be in there? "bitbake -g" seems to tell me that its just usbutils requires bash but i could be reading it incorrectly...
Jul 12 16:01:03 <bluelightning> ignus: I tend to rely on the depgraphs produced from buildhistory for some of this as they can pick up these kinds of dependencies that may be added at package time
Jul 12 16:02:12 <bluelightning> ignus: have you moved up to denzil or are you sticking with edison?
Jul 12 16:03:31 <ignus> bluelightning: yeah, we are on denzil. could i send you a dependency graph to take a look at? it might make more sense to you...
Jul 12 16:03:39 <bluelightning> ignus: sure thing
Jul 12 16:12:16 <ignus> bluelightning: do you turn those .dot files into a graphic or just use them as they are?
Jul 12 16:14:47 <bluelightning> ignus: usually they're too large to visualise although i did find "xdot" which can handle viewing some of the large graphs a bit better than dot + an image viewer: http://code.google.com/p/jrfonseca/wiki/XDot
Jul 12 16:16:12 <khem> bluelightning: have you played with systemd patches ?
Jul 12 16:16:44 <ignus> bluelightning: did you get those files?
Jul 12 16:16:47 <bluelightning> khem: I haven't, no... I could do if it comes to it but the thing is I don't know a lot about systemd
Jul 12 16:17:09 <bluelightning> ignus: yes, I'm just looking through them now
Jul 12 16:17:16 <khem> bluelightning: I think we need to create that layer quickly
Jul 12 16:17:25 <bluelightning> khem: I definitely agree
Jul 12 16:17:26 <khem> so people can start using it on top of OE-Core
Jul 12 16:17:38 <khem> and thereby test it and refine it
Jul 12 16:23:53 <khem> bluelightning: I am looking into hooking the SDK into eclipse, I am sure yp has docs on how to do that somewhere
Jul 12 16:24:09 <bluelightning> khem: yeah, that should all be covered in the ADT manual
Jul 12 16:27:24 <bluelightning> ignus: ok, couple of things
Jul 12 16:27:58 <bluelightning> ignus: here I don't get usbutils installed in core-image-minimal; it might be config/machine dependent though
Jul 12 16:28:36 <bluelightning> ignus: there is a dependency on bash from usbutils here though and it's caused by the usr/bin/usb-devices script which starts with #!/bin/bash
Jul 12 16:29:15 <bluelightning> ignus: it's not a big script so I would imagine it could be fairly easily patched to be non-specific to bash
Jul 12 16:30:17 <ignus> bluelightning: i might have to have a look at that tomorrow because removing bash could cut our rootfs size down by 40%
Jul 12 16:32:47 <ignus> bluelightning: is it the usbutils recipe installing that script or is it coming from elsewhere?
Jul 12 16:36:02 <bluelightning> ignus: it's the usbutils recipe yes
Jul 12 16:36:21 <bluelightning> ignus: when I build core-image-minimal, usbutils gets built but only usbutils-ids (a sub-package) gets installed
Jul 12 16:36:35 <bluelightning> that does not depend on bash
Jul 12 16:36:40 <bluelightning> but the main usbutils package does
Jul 12 16:37:18 <bluelightning> another quick solution would be for you to just rm that script in a bbappend if you didn't need it
Jul 12 16:38:10 <khem> http://www.yoctoproject.org/docs/current/adt-manual/adt-manual.html
Jul 12 16:38:21 <khem> bluelightning: read it full :) now I know a lot more
Jul 12 16:38:52 * bluelightning has to admit he has not read it in full
Jul 12 16:39:35 <khem> bluelightning: I had to, I wont be using it myself
Jul 12 16:39:41 <khem> err will be using
Jul 12 16:40:03 <khem> for experimentation before I write a workflow doc :)
Jul 12 16:41:22 <bluelightning> khem: cool... if you have suggestions about the ADT manual I'm sure Scott R will be happy to have them...
Jul 12 16:44:22 <ignus> bluelightning: apologies if this seems like a silly question but how do yocto know that because the script requires /bin/bash that the package should be installed?
Jul 12 16:45:06 <bluelightning> ignus: there are no silly questions :)
Jul 12 16:45:18 <bluelightning> ignus: we make use of a part of rpm which analyses the content going into the package and adds RDEPENDS as appropriate
Jul 12 16:45:53 <bluelightning> that gets called as part of do_package
Jul 12 16:47:57 <ignus> so it might be a good idea to grep the rest of /etc to see if there is anything else that requires /bin/bash?
Jul 12 16:48:12 <bluelightning> (it's functionality provided by rpm but it's actually a separate process from doing the actual packaging)
Jul 12 16:49:26 <bluelightning> ignus: you can always check but I'm fairly sure you won't find anything there from the core metadata
Jul 12 16:49:38 <bluelightning> ignus: eglibc-dev does have one though, that is somewhat annoying
Jul 12 16:49:52 <bluelightning> I guess you're not using eglibc though so you shouldn't hit that one...
Jul 12 16:51:13 <ignus> and will it be easy to write a .bbappend file to delete that script? its something i have never had to do so far...
Jul 12 16:53:34 <bluelightning> ignus: yep, trivial -  just put a do_install_append() in it which deletes the script
Jul 12 16:54:18 <ignus> bluelightning: fantastic, ill have a go at it tomorrow morning :D
Jul 12 16:54:19 <bluelightning> I can walk you through the specifics if you like
Jul 12 16:54:23 <bluelightning> cool
Jul 12 16:55:31 <ignus> it would be great to get the size down - every meg counts for us...
Jul 12 16:57:26 <ignus> i think its time to go home...
Jul 12 16:57:43 <ignus> bluelightning: thanks for your help! much appreciated :D
Jul 12 16:58:01 <bluelightning> ignus: no problem :) have a good evening
Jul 12 16:58:24 <ignus> bluelightning: you too, take it easy.
Jul 12 17:36:05 <msm> is there an guarantee what order bbappends are done?
Jul 12 17:36:15 <msm> is it by the layer order in conf/bblayers.conf?
Jul 12 17:37:01 <mranostay> msm: priority level in the layers
Jul 12 17:38:20 <msm> ok, thanks
Jul 12 17:44:11 <bluelightning> correct
Jul 12 17:44:49 <bluelightning> in the case where the layer priority is the same for two layers it will be the order in which they appear in bblayers.conf
Jul 12 17:45:06 <bluelightning> hopefully that situation does not come up too often though
Jul 12 17:45:13 <sgw> halstead: There is an issue with the packages.yp.org, can you you pm for some webdev help
Jul 12 17:50:40 <xxiao> opkg-target can install pkgs into SDK easily, how can adt-install do that? is it able to at all?
Jul 12 17:51:19 * xxiao read somewhere saying adt-install is making meta-toolchain/opkg-target obsolete!
Jul 12 17:51:58 * xxiao hopes that's wrong...
Jul 12 17:54:32 <bluelightning> xxiao: it may serve a similar purpose but it's highly unlikely meta-toolchain is going away any time soon
Jul 12 17:55:22 <kergoth> loving the proto vs protocol spam now
Jul 12 17:55:31 * kergoth mutters and adds a bunch of bbappends
Jul 12 17:55:57 <sgw> khem: you had had some concerns about the cpan.bbclass change that Pascal offered, are they addresed?
Jul 12 17:56:27 <onoffon> sgw yes
Jul 12 17:57:05 <sgw> onoffon: confused me for a minute, thanks!
Jul 12 17:59:14 * onoffon is khem on phone
Jul 12 19:25:57 <jstashluk> Where do I tell oe to do a "make nitrogen6x_defconfig" instead of using the defconfig in the old recipe directory?
Jul 12 19:33:28 <msm> sgw: that patch is confused to me too ;)
Jul 12 19:34:10 <sgw> When I first looked at I went Huh, Ok let me try it, then I fooled around with a couple of things to make sure.
Jul 12 20:02:09 <ag_> sgw: Do you think you can take a look over connman 1.3? I would be greatefull if i could have it in tomorrow.... :) i knowi
Jul 12 20:02:28 <ag_> grateful*
Jul 12 20:02:48 <ag_> I know i do push things a little right now...
Jul 12 20:04:03 <ag_> sgw: Genivi wants that on tomorrow. And we were announced yesterday...
Jul 12 20:05:09 <sgw> ag_: it looks good, but RP is out tomorrow, so not likely until next week, I am getting it under test right now along with the eglibc, automake changes, so there's alot pending
Jul 12 20:05:43 <ag_> sgw: Ok. No problem. Thank you anyway for support.
Jul 12 20:10:07 <sgw> ag_: how did you gerneate your xz results for Memory?  I know you used time, but was there something else?
Jul 12 20:11:02 <ag_> I replied to that. :) It was an unhappy output. The Memory results are from gnome-system-monitor
Jul 12 20:11:08 <sgw> ag_: also what image did you use for your 1.9G file?
Jul 12 20:11:32 <sgw> ag_: just noticed that, IRC is on the top of my desktop email is buried!
Jul 12 20:11:34 <ag_> sgw: I used a modified image from rpi layer.
Jul 12 20:13:12 <sgw> ag_: I need to get me one of those!  Also one for my 14yr old son!
Jul 12 20:13:40 <ag_> sgw: Didn;t you preorder?
Jul 12 20:13:53 <sgw> ag_: no dumb me.
Jul 12 20:14:06 <ag_> sgw: I spent 4 months waiting :)
Jul 12 20:29:37 <ag_> sgw: That fotowall bug... drove me crazy...
Jul 12 20:36:02 <ag_> sgw: Gone to sleep.
Jul 12 20:36:12 <ag_> Good night all / day?
Jul 12 20:56:37 <khem> bluelightning: is buildstat vieable in browser
Jul 12 20:57:16 <bluelightning> khem: do you mean buildstats or buildhistory?
Jul 12 21:00:52 <khem> buildstats
Jul 12 21:01:38 <bluelightning> well we record them on the autobuilder into a git repo, but there's no auto-generated graphs from that if that's what you mean
Jul 12 21:04:23 <khem> bluelightning: yes
Jul 12 21:04:41 <khem> bluelightning: is there some way to visualize it
Jul 12 21:05:49 <bluelightning> nothing out of the box that I'm aware of, but it wouldn't be hard to throw together a script to throw the data into rrdtool or something like that I would think
Jul 12 21:20:29 <sgw> bluelightning: in case your still here, just know that I am running a MUT on the AB, so you do not have triage the failures, I will do that.
Jul 12 21:20:48 <bluelightning> sgw: ok, thanks for the heads up
Jul 12 21:56:50 <sgw> hi khem, seems that the gcc git is either really slow /big, it's been going for quite some time now on the fetch.
Jul 12 21:57:13 <khem> sgw: its big :(
Jul 12 21:57:38 <khem> I used the github which is actually faster than the original git that gcc.gnu.org has
Jul 12 21:58:10 <sgw> khem, the git seems to be slower than the older version, good think we don't need to update that fetch too often!
Jul 12 21:58:22 <khem> sgw: but since you are doing it first time its slow. Rest of them will just download it from yp.org so should be fast
Jul 12 21:58:29 <khem> yes
Jul 12 21:59:07 <khem> gcc has tonnes of branches and history
Jul 12 21:59:25 <khem> and you know not all branches are converted to git lot of older cruft is left out
Jul 12 21:59:29 <khem> but still its big
Jul 12 22:00:46 <ant____> sgw: any problem with that innocent psplash-logo patch? My comment was abrupted: I meant that one single vga-centered logo can serve the qvga-rotated and vga displays. It's the same aliased logo we use for kernel boot so there is a nice continuity on boot.
Jul 12 22:01:36 <sgw> ant____: not really, just we are in the middle of doing a Milestone check point, so things have slowed on the uptake
Jul 12 22:02:22 <ant____> khem: sgw about xz, please note the memory requirements for *decompressing* are very high increasing the compression level. More thread would only need more memory...be careful with that
Jul 12 22:02:49 <ant____> sgw: I see, thx
Jul 12 22:03:36 <sgw> ant____: thanks for that, I am going to do some tests with -T0 on a 24core machine, we will see what happens
Jul 12 22:04:14 <ant____> khem: in real life, I had to lower the lzma (is xz now) compression to 7 to decompress 1mb kernel on 32MB device
Jul 12 22:05:36 <rburton> sgw: its bigger than you could ever imagine
Jul 12 22:05:47 <rburton> sgw: iirc 1.3G for a full clone
Jul 12 22:05:56 <sgw> rburton: just finished!
Jul 12 22:06:21 <sgw> wow, that's going to be painful on slower nets
Jul 12 22:06:24 <rburton> when i was fixing connman on new automake i ended up filtering out the gcc changes
Jul 12 22:06:34 <rburton> i got very bored after 300M :)
Jul 12 22:06:49 <ant____> khem: note how level -8 for xz corresponds to level 9 in lzma-utils ( man xz )
Jul 12 22:17:51 <khem> ant____: more than 1 thread is better
Jul 12 22:18:02 <khem> ant____: so its improvement in general
Jul 12 22:18:38 <ant____> khem: 674 MB each thread are oo much imho
Jul 12 22:19:17 <khem> yes it is
Jul 12 22:19:19 <ant____> default -6 uses just 94MB (indicative) each
Jul 12 22:19:39 <khem> I think we need a balance here for general case
Jul 12 22:19:55 <khem> and then if you have memory then tweak the local.conf to increase it
Jul 12 22:20:25 <ant____> yes, like BB_THREADS
Jul 12 22:26:38 <rburton> could just reuse BB_THREADS instead of adding more parallelism options
Jul 12 22:26:44 <rburton> but anyway, time for bed
Jul 12 22:29:48 <ant____> BB_NUMBER_THREADS  for the sake of precision, sorry
Jul 12 22:43:28 <sgw> ant____: how are you determining memory usage?
Jul 12 22:45:20 <ant____> pls see man xz
Jul 12 22:46:49 <ant____> and for me, the kernel was not booting because could not decompress the cpio.lzma on 32MB
Jul 12 22:56:40 <hollisb> with a fresh poky clone, my first "bitbake devel-image" gets errors like these:
Jul 12 22:56:52 <hollisb> ERROR: No recipes available for:
Jul 12 22:56:52 <hollisb>   /mnt/poky.git/meta-yocto/recipes-kernel/linux/linux-yocto_3.2.bbappend
Jul 12 22:57:02 <hollisb> (about 30 lines worth)
Jul 12 22:57:16 <hollisb> never seen this before; have I done something wrong?
Jul 12 22:59:28 <sgw> hollisb: checking now
Jul 12 22:59:53 <hollisb> I am on the "master" branch, FWIW
Jul 12 23:00:16 <sgw> hollisb: do you have any additional recipes or layers?
Jul 12 23:00:29 <hollisb> yes, I added meta-ti to BBLAYERS
Jul 12 23:00:46 <hollisb> but only two of the bbappend errors come from meta-ti
Jul 12 23:00:53 <hollisb> most come from meta-yocto
Jul 12 23:01:06 <bluelightning> hollisb: there are no errors before that?
Jul 12 23:01:08 <hollisb> I can pastebin the whole thing if that would help
Jul 12 23:01:14 <hollisb> oh!
Jul 12 23:01:30 <hollisb> bluelightning: poor reading skills :)
Jul 12 23:01:31 <hollisb> ERROR: ParseError at /mnt/poky.git/meta-ti.git/recipes-misc/payload/bonescript.bb:5: Could not inherit file classes/systemd.bbclass
Jul 12 23:02:24 <bluelightning> we really should not be printing the bbappend nonsense, I might take a look into that tomorrow
Jul 12 23:03:06 <hollisb> bluelightning, sgw: working happily now. thanks!
Jul 12 23:03:12 <hollisb> I'd typoed my BBMASK
Jul 12 23:03:22 <hollisb> since that's *still* needed to use meta-ti...
Jul 12 23:04:43 <hollisb> ... except for a netbase.bbappend error, but it looks like that one has enough clues on google for me to hack
**** ENDING LOGGING AT Fri Jul 13 02:59:58 2012

**** BEGIN LOGGING AT Fri Jul 13 02:59:59 2012
Jul 13 08:06:01 <ignus> Hi all, can anyone tell me if there is a way to have a nightly build happen if there is a change to one of several git repos but have it ignore the checkin id of the change? as in a checking to one repo should cause (wtih onlyIfChanged) and build using another repo...
Jul 13 08:08:02 <ignus> oops, wrong channel, please ignore...
Jul 13 13:02:04 <sd__> Hello. Do you know if somebody is working on backporting linux-yocto_3.4 to denzil?
Jul 13 13:02:27 <sd__> I need to use linux 3.4 but I do not want to use the master branch
Jul 13 13:18:00 <bluelightning> sd__: we don't normally introduce new kernel versions in maintenance releases, so I would doubt it
Jul 13 14:28:08 <ag_> Is there any way i can append EXTRA_OECONF but just for target package (not native)
Jul 13 14:28:12 <ag_> ?
Jul 13 14:28:31 <ag_> The same question for depends
Jul 13 14:31:30 <bluelightning> ag_: use _class-target override
Jul 13 14:32:42 <ag_> bluelightning: thank you. this was what i was looking for
Jul 13 14:55:41 <sgw> ag_: did you see the email about connman failure, I know you tested it, seems connman did not start on the mips arch.
Jul 13 15:02:53 <bluelightning> sgw: I think rburton was looking into it...
Jul 13 15:03:50 <rburton> sgw: I've got the mips image, just copying it to a machine where qemu works as i speak
Jul 13 15:04:02 <rburton> agreed, for some reason its not starting
Jul 13 15:05:21 <sgw> rburton: ah ok, I was not sure if ag_ would resolve, thanks for looking into it.
Jul 13 15:09:21 <ag_> sgw: Didn't see / receive the email
Jul 13 15:09:33 <ag_> sgw: I got one with: ack
Jul 13 15:10:11 <rburton> sgw: just force-pushed a revised webkit branch which should build.  I suspect it was using tools on the build host to succeed before
Jul 13 15:11:22 <sgw> ag_: Hmm, summary: connman fails to run on mips, rburton is looking into it currently.
Jul 13 15:11:47 <ag_> sgw: Only on mips?
Jul 13 15:12:02 <sgw> ag_: apparently
Jul 13 15:12:34 * sgw gotto go back shortly
Jul 13 15:13:30 <rburton> not only on mips
Jul 13 15:13:32 <rburton> but not on all
Jul 13 15:18:33 <ag_> rburton: What did you test?
Jul 13 15:18:46 <rburton> ag_: still trying to get the ab image to boot :)
Jul 13 15:19:02 <rburton> turns out my qemu doens't have mips support
Jul 13 15:19:06 <rburton> which is going to be a problem
Jul 13 15:19:33 <ag_> rburton: if you can't i can try it
Jul 13 15:19:45 <ag_> rburton: Or i can test on other machines...
Jul 13 15:19:57 <ag_> rburton: I tested only x86 qemu
Jul 13 15:21:00 <rburton> lies, it's totally installed
Jul 13 15:21:03 * rburton kicks hardware
Jul 13 15:21:32 <bluelightning> totally something at any rate ;)
Jul 13 15:21:36 <rburton> mips in qemu over x over ssh over wifi
Jul 13 15:21:37 <rburton> superfast!
Jul 13 15:22:01 <rburton> oh god even the console scrolling is 2fps
Jul 13 15:22:17 <rburton> maybe i should just turn the monitor on
Jul 13 15:22:30 <ag_> rburton: So it could be from you setup?
Jul 13 15:23:11 <rburton> ag_: the failure was the autobuilder test suite, so that's unrelated to me.  i've got hopefully the same image booting here so we'll see.
Jul 13 15:23:32 <ag_> rburton: Understood.
Jul 13 15:26:06 <rburton> yeah it's segfaulting
Jul 13 15:26:15 <rburton> and on ppc too iirc
Jul 13 15:26:43 <ag_> ... i will have a mipsr build tonight to see it with my eyes :)
Jul 13 15:26:47 <ag_> mips*
Jul 13 15:28:40 <rburton> ag_: the autobuilder nightly output image crashes if you want to see it now :)
Jul 13 15:29:18 <rburton> ag_: i'll be disappearing soon so you are welcome to have a look at it later, but i've just reported this in #connman
Jul 13 15:29:37 <ag_> rburton: Ok.
Jul 13 15:30:20 <ag_> rburton: http://autobuilder.yoctoproject.org/pub/nightly/CURRENT/?
Jul 13 15:30:40 <rburton> yeah
Jul 13 15:30:41 <rburton> http://autobuilder.yoctoproject.org/pub/nightly/CURRENT/machines/qemu/qemumips/
Jul 13 15:31:12 <rburton> you'll want the sato-dev or sdk image i guess
Jul 13 15:31:37 <rburton> i got the plain sato image as its quicker for me to rebuild than download 1.6G, so i can't attach a gdb yet
Jul 13 15:34:44 <ag_> downloading
Jul 13 15:59:06 <ag_> rburton: Do you have a fast qemu like to boot that image?
Jul 13 16:19:16 <sorvats> hello. I am building a custom image, and  although i have IMAGE_INSTALL+=ncurses, the build system doesnt seem to be including ncurses shared libs in my image. All that i can find in the rootfs are ncurses5-config scrpits
Jul 13 16:20:29 <bluelightning> sorvats: what does bitbake -e your-image | grep IMAGE_INSTALL report?
Jul 13 16:23:24 <sorvats> IMAGE_INSTALL="task-core-boot ncurses mtd-utils u-boot-fw-utils libftdi tslib ppp wireless-tools wpa-supplicant run-postinsts"
Jul 13 16:23:57 * sgw is back
Jul 13 16:24:10 <bluelightning> sorvats: where did you put that IMAGE_INSTALL += ?
Jul 13 16:24:33 <bluelightning> oh wait, ncurses is in there
Jul 13 16:24:55 <sorvats> :)
Jul 13 16:25:19 <sorvats> in fact, i put ncurses not with += but in the image recipe
Jul 13 16:25:36 <bluelightning> well, my first port of call would be to look at what the ncurses package actually contains
Jul 13 16:25:40 <sorvats> amongst the actual "definition" of IMAGE_INSTALL
Jul 13 16:25:51 <sorvats> ehm, ok, checking
Jul 13 16:26:46 <sgw> bluelightning: your build finished, not sure if you saw that
Jul 13 16:27:05 <bluelightning> sgw: yes, I replied to the failure report...
Jul 13 16:27:41 <rburton> ag_: the normal qemu-system-mips that poky built (runqemu qemumips vmlinux core-image-sato...)
Jul 13 16:28:25 <bluelightning> sgw: I'm not entirely sure how to proceed from here... it might suggest that function needs to be broken up perhaps
Jul 13 16:29:30 <ag_> rburton: Just wanted to avoid a mips build env
Jul 13 16:29:50 <rburton> the qemu is built for you by default
Jul 13 16:33:02 <sorvats> well, the contents of the package tmp/work/armv5te-poky-linux-gnueabi/ncurses-5.9-r8.1/deploy-ipks/armv5te/ncurses_5.9-r8.1_armv5te.ipk are consistent with what gets installed
Jul 13 16:33:46 <sorvats> in fact, now i can see which packages are the ones which should get installed
Jul 13 16:34:15 <sgw> bluelightning: just got through the pipes, not sure I have any suggestions, you can't reproduce it on your system?  Do you have an LSB build?
Jul 13 16:34:16 <sorvats> i.e tmp/work/armv5te-poky-linux-gnueabi/ncurses-5.9-r8.1/deploy-ipks/armv5te/libncurses5_5.9-r8.1_armv5te.ipk
Jul 13 16:34:27 <bluelightning> sorvats: typically you should not have to install libraries explicitly... if your software that needs them is built from a recipe, that will be handled automatically
Jul 13 16:34:49 <bluelightning> sgw: nope, doesn't happen here... I don't have an LSB build no
Jul 13 16:35:39 <sorvats> well, there is a particular piece of software which will be included in the distro that is not to be built with yocto and which requires ncurses
Jul 13 16:35:56 <sgw> bluelightning: I know its the end of your day, maybe set one up and build over the weekend, I am only half day today for me.
Jul 13 16:36:15 <bluelightning> sorvats: even if it's built externally you can still package it and that will still handle shared library dependencies
Jul 13 16:36:29 <bluelightning> sorvats: s/package/use a recipe to package/
Jul 13 16:37:52 <bluelightning> sgw: hmm, I missed that it was poky-lsb... shouldn't make a difference but I'll take your suggestion and try it here
Jul 13 16:38:55 <sgw> bluelightning: remember to set DISTRO
Jul 13 16:39:05 <bluelightning> sgw: right, yep
Jul 13 16:43:17 <sorvats> bluelightning: well, that seems fair enough, although (and pardon my ignorance) why intentionally installing a single library wouldnt be supported by just manipulating the image recipe
Jul 13 16:44:59 <sorvats> bluelightning: s/why/i don't see why/
Jul 13 16:45:01 <sorvats> :P
Jul 13 16:45:13 <ag_> Is there anyway fast way to avoid do_populate_sysroot in a package as i don't want anything in sysroot from it
Jul 13 16:45:25 <kergoth> ag_: do_populate_sysroot[noexec] = "1"
Jul 13 16:45:29 <kergoth> it's the method used by the image recipes
Jul 13 16:45:47 <kergoth> but i doubt it'd make much difference in build perforamnce
Jul 13 16:45:50 <bluelightning> sorvats: it is definitely supported... I'm just suggesting an alternative
Jul 13 16:45:54 <ag_> kergoth: thanks
Jul 13 16:46:13 <sorvats> ah, ok, ty :)
Jul 13 16:46:57 <sorvats> how could i delete sstate files for a package so that ncurses will get totally rebuilt?
Jul 13 16:47:10 <ag_> -c cleansstate
Jul 13 16:47:23 <sorvats> ag_: thanks :)
Jul 13 16:47:45 <ag_> sorvats: np
Jul 13 16:54:29 <kergoth> hmmmmm.. anything using prefuncs/postfuncs to do work, or equivalent, against a particular task, won't be run when using shared state.. guess this needs consideration on a case by case basis, but as one example buildhistory doesn't record package info when pulling from shared state
Jul 13 16:54:56 <kergoth> which means a cahnge to the buildhistory features from image to package won't result in population of hte package data without doing a wip eof shared state
Jul 13 16:55:01 <kergoth> bluelightning: thoughts?
Jul 13 16:56:45 <kergoth> as another example, archiver.bbclass stuff won't happen for recipes pulled from sstate, and no sstate archives are created for its content, since its written out in pre/post funcs not in its own task (copyleft_compliance doesn't have this problem), unless i'm missing something
Jul 13 16:56:59 <kergoth> that reminds me, i don't think prefuncs/postfuncs get included in checksums for the variable
Jul 13 16:57:05 <kergoth> hrm
Jul 13 16:57:21 <kergoth> i guess that'd be the solution, if those were included, those tasks would be forced to rerun
Jul 13 16:57:24 * kergoth ponders
Jul 13 16:58:17 <sgw> kergoth: interesting, you mean that the archiver does not run when we go from sstate?  That does not sound good, maybe we need a sstate source archive.
Jul 13 16:59:03 <kergoth> i haven't verified it 100%, but it makes sense given its design and knowing taht prefunc/spostfuncs aren't in checksums
Jul 13 16:59:30 * kergoth tests
Jul 13 16:59:46 <sgw> kergoth: yeah, when you said that I went Oh yeah that would make sense also.  Please file a bug if that's indeed the case.
Jul 13 17:00:36 <bluelightning> kergoth: hmm, well on the buildhistory issue it's intended that changing BUILDHISTORY_FEATURES won't force a re-package of everything
Jul 13 17:00:57 <bluelightning> kergoth: but the general issue does seem like an oversight
Jul 13 17:01:46 <kergoth> bluelightning: i dont' necessarily want it to repackage everything, ideally it'd be able to do its thing using the bits included in the sstate archives, if possible
Jul 13 17:01:53 * kergoth thinks
Jul 13 17:02:06 <kergoth> bluelightning: any time i'm basically forced to wipe sstate, this seems like a sign of a bug :)
Jul 13 17:02:10 <kergoth> even if it was by design at the time
Jul 13 17:02:13 <kergoth> heh
Jul 13 17:02:20 <bluelightning> kergoth: I agree on the latter
Jul 13 17:02:33 <kergoth> i'll do some more testing and open bugs if appropriate
Jul 13 17:02:41 <kergoth> also going to prototype including prefuncs/postfuncs in task checksums
Jul 13 17:02:44 <bluelightning> re the former, it might be technically possible
Jul 13 17:03:01 <bluelightning> ok, cool
Jul 13 17:03:17 <kergoth> my concern is whether there are any cases where prefuncs/postfuncs don't *want* to be in the checksums, but vardepsexclude could be used if such was the case. also, you could use event handlers in that case
Jul 13 17:03:25 * kergoth dives in
Jul 13 18:58:33 <khem> kergoth: I want to disable inherting prelink class for 1 arch but let it be in there for others
Jul 13 18:58:41 <kergoth> good luck
Jul 13 18:58:45 <kergoth> :)
Jul 13 18:58:46 <khem> kergoth: standard override seems not to work :)
Jul 13 18:59:00 <kergoth> you could always create an anonymous python function which does hte parse of the class under a conditional
Jul 13 18:59:01 <khem> oh something cant be done
Jul 13 18:59:08 <kergoth> see e.g. how i implemented assume.bbclass
Jul 13 18:59:46 <kergoth> it might not be pretty, and there could be issues if prelink.bbclass implements its own anonymous python functions
Jul 13 19:00:00 <kergoth> due to when finalization happens, the fact that its parsed during hte middle of finalization
Jul 13 19:00:16 <kergoth> there used to be some issues with amend.inc usage of anonfuncs as a result
Jul 13 19:00:36 <kergoth> but one option might be to use variable references in the inherit line, but i'm not sure if bitbake can handle a noop inherit line
Jul 13 19:00:40 <kergoth> e..g inherit ${FOO}
Jul 13 19:00:42 <kergoth> FOO ?= ""
Jul 13 19:00:46 <kergoth> FOO_bar = "baz"
Jul 13 19:01:00 <kergoth> i suspect that might cause an error
Jul 13 19:01:09 <kergoth> but you could create an empty class by a different name
Jul 13 19:01:16 <kergoth> FOO ?= "noop-prelink"
Jul 13 19:01:19 <kergoth> heh
Jul 13 19:01:22 <kergoth> none of the options are pretty, really
Jul 13 19:01:28 <kergoth> if at all possible, find another way :)
Jul 13 19:08:22 <onoffon> or make prelink work for ppc64
Jul 13 19:08:50 <kergoth> :)
Jul 13 19:22:39 * mranostay yawns
Jul 13 20:28:07 <khem> kergoth: there already is a dummy.bbclass
Jul 13 20:58:10 <khem> kergoth: this is INHERIT
Jul 13 20:58:20 <khem> so I think I am grossly out of luck
Jul 13 21:21:30 <hollisb> meta-ti is just not kept in a very poky-compatible state, is it?
Jul 13 21:21:46 <hollisb> I thought people were working on merging it completely with poky months ago
Jul 13 22:11:30 <Crofton|work> bug denix
Jul 13 23:04:55 <kergoth> khem: i dont see why. FOO = dummy, FOO_bar = baz, INHERIT += ${FOO}
Jul 13 23:06:04 <khem> kergoth: this happens in local.conf and overrides are not there yert
Jul 13 23:06:24 <khem> I fixed it in image-prelink class
Jul 13 23:06:36 <khem> to not do prelinking when ppc64
Jul 13 23:12:20 <khem> jelly bean is definitely better than icecream sandwich
Jul 13 23:12:35 <khem> I can feel the graphics is spiffier
Jul 13 23:12:45 <khem> but battery is draining faster :(
Jul 13 23:13:15 <khem> will android folks fix power consumption ever
Jul 13 23:13:39 <khem> or may be time to create meta-android and do it in my own way
Jul 14 00:04:13 <phil92> trying to use hob under kubuntu - does not work, just start regular bitbake cmd line. any idea ?
Jul 14 01:19:21 <halstead> We are having network errors on downloads.yoctoproject.org. It will be back shortly.
Jul 14 01:21:13 <halstead> We are back. If anyone was downloading sources you may need to restart your downloads.
**** ENDING LOGGING AT Sat Jul 14 02:59:58 2012

**** BEGIN LOGGING AT Sat Jul 14 02:59:59 2012
Jul 14 18:56:06 <LinuxUser777> Hello! I had built qemuarm image and now I trying to run it on PXA270 ARM processor. How to modify /etc/inittab to get serial console on ttyS0 working? Yocto's inittab is very strange, I tried many variant of getty lines - no success! I just need  to be able to login on ttyS0 port. The only lines I see now: "VFS: Mounted root (ext3 filesystem). Freeing init memory: 120K" and nothing more.
Jul 14 21:18:54 <halstead> sgw, Are you around.
Jul 14 21:25:29 <halstead> sgw, I'm just running a new build with clean sstate after some NFS issues.
Jul 14 21:41:52 <LinuxUser777> halstead, please, could you help me?
**** ENDING LOGGING AT Sun Jul 15 02:59:59 2012

**** BEGIN LOGGING AT Sun Jul 15 02:59:59 2012
**** ENDING LOGGING AT Mon Jul 16 02:59:57 2012

**** BEGIN LOGGING AT Mon Jul 16 02:59:58 2012
Jul 16 06:06:08 <mckoan> good morning
Jul 16 08:33:57 <bluelightning> morning all
Jul 16 08:34:08 <JaMa> morning
Jul 16 08:35:12 <bluelightning> hi JaMa
Jul 16 08:35:23 <bluelightning> JaMa: did you enjoy your holiday?
Jul 16 08:35:38 <JaMa> yup :)
Jul 16 08:35:49 <JaMa> short but goo
Jul 16 08:35:50 <JaMa> d
Jul 16 08:38:11 <bluelightning> JaMa: they're always too short ;)
Jul 16 09:18:20 <JaMa> sgw: Hi, your patch for s/proto=/protocol=/g missed meta/recipes-core/eglibc/cross-localedef-native_2.15.bb and meta/recipes-multimedia/tremor/tremor_20120314.bb
Jul 16 09:18:37 <JaMa> khem: ^ and meta/recipes-core/eglibc/cross-localedef-native_2.16.bb in your eglibc-2.16 branch
Jul 16 09:21:09 <bluelightning> meta-systemd split has been done! :)
Jul 16 10:24:46 <ignus> hi all, can anyone tell me what would be the best way to get debugfs mounted on boot?
Jul 16 10:30:10 <rburton> bluelightning: oh, yay
Jul 16 10:31:23 <rburton> bluelightning: does it still think that systemd can be an image-time choice?
Jul 16 10:31:56 <bluelightning> rburton: I think the next step is to sort that kind of thing out
Jul 16 10:32:35 <bluelightning> ignus: hi
Jul 16 10:32:49 <bluelightning> ignus: does putting it in fstab not work?
Jul 16 10:34:47 <ignus> bluelightning: hey, hows it going?
Jul 16 10:35:06 <bluelightning> ignus: great, and you?
Jul 16 10:35:28 <ignus> bluelightning: yeah, that would work, just not sure where the fstab is coming from. as in is it generated or is it just a static file?
Jul 16 10:35:51 <ignus> bluelightning: im good yeah, very relaxing weekend :D
Jul 16 10:36:56 <ignus> bluelightning: ah, found the fstab, thanks!
Jul 16 10:37:15 <bluelightning> base-files I think
Jul 16 10:42:48 <ignus> bluelightning: so, i should be able to just overwrite that one file (fstab) in my layer without messing anything else in base-files up right?
Jul 16 10:46:30 <bluelightning> ignus: yep
Jul 16 10:46:51 <FunkyPenguin> rburton: sent my email to yocto ml, does that explain it as well as what i mentioned to you last night?
Jul 16 10:47:12 <rburton> yes :)
Jul 16 10:47:39 <FunkyPenguin> yay, thanks.
Jul 16 11:01:06 <rburton> FunkyPenguin: what happens if you change the order of the git urls?
Jul 16 11:01:14 <rburton> maybe you need to override S
Jul 16 11:01:36 <rburton> or use full paths in the dts filename
Jul 16 11:09:30 <FunkyPenguin> just trying reordering now, needed to do a clean up
Jul 16 11:15:08 <FunkyPenguin> well reordering fails too - http://paste.opensuse.org/27543427
Jul 16 12:37:42 <FunkyPenguin> rburton: when you say use full paths in the dts filename do you mean something like KERNEL_DEVICETREE_rtsm_ve-cortex_a15x2.dts = "arm-dts/fast_models/rtsm_ve-cortex_a15x2.dts"?
Jul 16 12:38:00 <FunkyPenguin> that doesnt seem to work as do_configure still yaks
Jul 16 12:46:10 <rburton> FunkyPenguin: i guess the problem is i know really nothing about how the kernels are constructed :)
Jul 16 12:55:44 <FunkyPenguin> :)
Jul 16 13:35:05 * zeddii received a truly grotesque amount of email over the weekend.
Jul 16 13:48:13 <ant_work> zeddii: oh, I was cooking something for you, better postponing :)
Jul 16 14:35:22 <khem> JaMa: I have closed that pull request will fix it in followup if no one else does
Jul 16 14:36:20 <JaMa> ok, fine
Jul 16 16:28:51 <sgw> khem: question about your eglibc branch, you have a mkelfimage patch against the svn version, but we have a git version in oe-core, what's up with that?
Jul 16 17:03:55 <khem> sgw: I mentioned it in commit.
Jul 16 17:04:05 <khem> sgw: git version checks out more than needed
Jul 16 17:04:21 <khem> officially its hosted on svn only
Jul 16 17:06:59 <khem> current SRC_URI is picked from gerrit which is kind of iffy
Jul 16 17:13:33 <sgw> khem, missed the commit message on that one, sorry should have read it
Jul 16 18:22:11 <chackal_sjc> guys
Jul 16 18:22:37 <chackal_sjc> yocto 1.2 is crashing with a base-passwd recipe
Jul 16 18:22:45 <chackal_sjc> allways get an error when unpack
Jul 16 18:24:46 <sgw> chackal_sjc: can you pastebin the error you are getting?
Jul 16 18:26:06 <walters> rburton, i'm seeing some stuff go by for installing tests, e.g. "	[OE-core] [PATCH] dbus-glib: support unit tests compile and install"
Jul 16 18:26:33 <walters> rburton, that's something i'd really like to drive in gnome too...some sort of standard place to put installed tests, a configure option to enable it, etc
Jul 16 18:27:33 <walters> it may even make sense to patch automake to support it
Jul 16 18:32:01 <walters> hacking up project's makefiles leads to the "rebase occasionally" model which means you can't have continuous integration
Jul 16 18:39:28 <chackal_sjc> sgw_afk: ok
Jul 16 18:46:37 <chackal_sjc> sgw_afk: http://paste.kde.org/518564/
Jul 16 19:09:19 <chackal_sjc> yocto 1.2 is crashing with a base-passwd recipe
Jul 16 19:09:25 <chackal_sjc> always get an error when unpack
Jul 16 19:09:31 <chackal_sjc> http://paste.kde.org/518564/
Jul 16 19:12:57 <sgw> chackal_sjc: looks like you might have a corrupted file since you are getting a gunzip failure, could you try a "bitbake -c cleanall base-passwd"
Jul 16 20:12:24 <chackal_sjc> sgw: i will try ity
Jul 16 20:13:01 <kergoth> seebs: whatever happened to your bitbake variable tracking / include tracking patchset, did richard ever decide whether your most recent patchset should get merged?
Jul 16 20:13:04 * kergoth lost track of it
Jul 16 20:25:01 <ag_> rburton: Hello.
Jul 16 20:28:12 <ag_> rburton: I managed to strace /gdb a mips build with coonnan. It seems like there are at least two problems. If i run connmand as daemon it fails in  main() - daemon()from unistd. It i avoid this it crashes in  __connman_service_init from service.c while g_hash_table_new.
Jul 16 20:28:37 <ag_> rburton: sgw Any ideas about this.
Jul 16 20:28:39 <ag_> ?
Jul 16 20:31:07 <sgw> ag_: what's different between the startup code in 1.2 and 1.0?  if you build 1.0 does it fail in the same way, I would be looking along those lines?
Jul 16 20:33:18 <ag_> sgw: Ok. deal.
Jul 16 20:37:19 <chackal_sjc> sgw: still getting the same error
Jul 16 20:40:45 <sgw> chackal_sjc: can you check the contents of that file in your download dir?
Jul 16 20:40:59 <ag_> sgw: code above daemon() in main() is absolutely identical....
Jul 16 20:41:18 <seebs> kergoth: I have no idea. I resubmitted it a while back, and didn't hear back.
Jul 16 20:41:27 <sgw> ag_: could you build and run the 1.0 version OK on mips?
Jul 16 20:41:34 <ag_> sgw: Yes...
Jul 16 20:41:35 <kergoth> seebs: k, figured that might be the case
Jul 16 20:41:36 <seebs> I would really love to see that stuff make it in, because I pretty much rely on it now in our branch.
Jul 16 20:41:56 <ag_> sgw: No problems with 1.0
Jul 16 20:41:58 <sgw> with the branch you are testing your 1.3 changes?  Can you try and use gdb
Jul 16 20:42:14 <kergoth> seebs: i don't need it that often, but more than once in teh past week i've wanted to tell people who are asking me questions to use it, heh
Jul 16 20:42:20 <seebs> Also, I have an oe-core submission to improve bitbake -e handling in the case of sanity checks, which I can't submit to our tree until I've submitted it to oe-core, which I can't do until the tracking changes are in bitbake, because it presupposes those tracking changes.
Jul 16 20:42:27 <chackal_sjc> sgw: sure
Jul 16 20:42:49 <kergoth> seebs: what submission, out of curiosity?
Jul 16 20:43:16 <seebs> It suppresses the sanity-check abort if the data object has tracking enabled.
Jul 16 20:43:41 <seebs> This is actually a pretty lame way to do it, and I fully expect it to be rejected, along with an explanation of a non-stupid way in which I could avoid blowing up "if we are running -e".
Jul 16 20:43:58 <ag_> sgw: I am using gdb. This is how i managed to find the function that crashes. I'm using master + connman 1.3 update.
Jul 16 20:44:31 <chackal_sjc> sgw: yeah, its corrupt.. i try to open and cant
Jul 16 20:44:39 <sgw> ag_: did you try to compare the config.log?  Could there be some flag or switch?
Jul 16 20:45:19 <ag_> sgw: i checked and didn't see anything obvious.
Jul 16 20:45:33 <ag_> sgw: Anyway i will keep looking into this.
Jul 16 20:45:53 <kergoth> seebs: i already suggested a workaround or that which upstream has already merged  -- sanity checks are now run at BuildStarted, not ConfigParsed. since -e doesn't start a build, its n ot a problem
Jul 16 20:46:01 <kergoth> seebs: so you shouldn't have to worry about that anymore
Jul 16 20:46:02 <seebs> Oh!
Jul 16 20:46:14 <seebs> That's awesome. I will ask people to merge it locally, it's way better than mine.
Jul 16 20:46:23 <sgw> chackal_sjc: Ok, is it a text file instead?  Can you check if there are any errors or warnings in the tmp/work/<your arch>/base-passwd-3.5.23-r0/temp/log.do_fetch file?
Jul 16 20:47:24 <chackal_sjc> yeah
Jul 16 20:47:28 <sgw> ag_: any setting files?  did you try strace on both and compare that (I know it's alot to slog through)
Jul 16 20:47:38 <chackal_sjc> what you mean text file intesad?
Jul 16 20:47:42 <chackal_sjc> its a .tar.gz
Jul 16 20:48:01 <ag_> sgw: The strace diff was something to do.
Jul 16 20:48:44 <sgw> chackal_sjc: that's what I mean is it really a .tar.gz file, if you do a "file" on the base-passwd.....tar.gz what do you get?
Jul 16 20:49:12 <kergoth> seebs: it also sidestepped another potential concern -- since we have no event handler dependencies, it was possible to add a ConfigParsed handler that modified the metadata, but which ran after the sanity checks, which meant the checks could be run against a non-final form of the metadata. heh
Jul 16 20:49:22 <sgw> chackal_sjc: sometimes it contains a 404 error message or something like it moved, that's why I wanted you to check the log.do_fetch
Jul 16 20:49:28 <chackal_sjc> sgw: http://paste.kde.org/518666/
Jul 16 20:49:34 <chackal_sjc> oh ok
Jul 16 20:49:58 <chackal_sjc> yeah, its wrong
Jul 16 20:50:02 <chackal_sjc> try to access http://snapshot.debian.net/archive/pool/b/base-passwd/base-passwd_3.5.24.tar.gz
Jul 16 20:51:05 <sgw> looks like they might have re-organized it
Jul 16 20:51:18 <sgw> chackal_sjc: http://snapshot.debian.org/package/base-passwd/3.5.24
Jul 16 20:55:08 <chackal_sjc> sgw: 404
Jul 16 20:56:05 <sgw> chackal_sjc: do you use the mirrors or premirrors?
Jul 16 20:56:44 <chackal_sjc> sgw: don't know.. what's that?
Jul 16 20:57:44 <sgw> chackal_sjc: setting PREMIRROR=<some uri> lets you say get everything from there as a mirror
Jul 16 20:59:49 <ag_> sgw: The only difference seems to be this:
Jul 16 20:59:49 <ag_> fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
Jul 16 20:59:49 <ag_> old_mmap(NULL, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x77844000
Jul 16 21:00:59 <sgw>  chackal_sjc: are you using oe-core standalone or with meta-yocto, meta-yocto sets PREMIRRORS to point at the downloads.yoctoproject.org for mirroring before going to the upstream site.
Jul 16 21:01:38 <sgw> ag_: interesting, which is which and what's the fstat trying to stat?
Jul 16 21:01:56 <ag_> Those line are in the new version.
Jul 16 21:02:14 <ag_> sgw: The old one doesn't have it.
Jul 16 21:03:19 <ag_> line*
Jul 16 21:03:21 <ag_> lines*
Jul 16 21:03:22 <sgw> ag_: so clearly it's doing something different before it hits the daemon() code
Jul 16 21:03:42 <ag_> Yeah... God knows where :)
Jul 16 21:04:11 <ag_> sgw: The problem actually is not a segfault.
Jul 16 21:04:38 <ag_> It just doesn't come out of daemon()
Jul 16 21:08:16 <chackal_sjc> sgw: I'm using yocto 1.2... which is poky only
Jul 16 21:08:21 <chackal_sjc> im not sure about that
Jul 16 21:17:11 <sgw> chackal_sjc: seems like a fetcher problem, not translating the mirrors or ??  We just tested the 1.2.1 release and did not any issue like this.  Have you made any other changes to your local.conf file?  Or is it a straight setup?
Jul 16 21:24:11 <chackal_sjc> sgw: I just made a workaruond with a .bbappend
Jul 16 21:24:32 <chackal_sjc> sgw: well, minor changes in my confs
Jul 16 21:26:10 <sgw> chackal_sjc: did you change MIRRORS at all?  I just tried it locally and I had it get the file from yoctoproject mirror correctly
Jul 16 21:27:23 <chackal_sjc> sgw: no..
Jul 16 21:27:43 <chackal_sjc> I downloaded the poky 7.0 in yocto downloads page
Jul 16 21:28:01 <sgw> can you past your full do_fetch file, it should have more that what you pasted before
Jul 16 21:28:02 <chackal_sjc> and ran my own conf(which uses the basic one with different distro and kernel configs)
Jul 16 21:28:19 <chackal_sjc> sgw: no, that was the entire file
Jul 16 21:28:23 <sgw> Ah, different distro, which will change the mirrors list possibly
Jul 16 21:28:34 <chackal_sjc> sgw: but my distro doesnt change any mirros
Jul 16 21:28:54 <sgw> chackal_sjc: bitbake -e base-passwd | grep ^MIRROR
Jul 16 21:29:11 <chackal_sjc> sgw: net-base also cant unpack
Jul 16 21:29:19 <chackal_sjc> k
Jul 16 21:31:21 <chackal_sjc> sgw: all debians related packages are broken
Jul 16 21:31:26 <sgw> probably similar issue because of DEBIAN_MIRROR, somehow the mirroring fetch is not working correctly.
Jul 16 21:31:59 <chackal_sjc> sgw: http://paste.kde.org/518696/
Jul 16 21:34:37 <sgw> chackal_sjc: interesting, since the fetch log does not show it attempting to look at the mirrors
Jul 16 21:34:54 <chackal_sjc> yeah
Jul 16 21:34:55 <chackal_sjc> brb
Jul 16 21:35:58 <sgw> chackal_sjc: meta-yocto adds the downloads.yoctoproject.org to the front of the list also
Jul 16 21:37:01 <sgw> you might try adding the following lines to your distro config file and see if that helps:
Jul 16 21:37:04 <sgw> MIRRORS =+ "\
Jul 16 21:37:04 <sgw> ftp://.*/.*      http://downloads.yoctoproject.org/mirror/sources/ \n \
Jul 16 21:37:04 <sgw> http://.*/.*     http://downloads.yoctoproject.org/mirror/sources/ \n \
Jul 16 21:37:04 <sgw> https://.*/.*    http://downloads.yoctoproject.org/mirror/sources/ \n"
Jul 16 21:43:28 <ag_> sgw: Bad news... i realized that those line were from a forgotten printf....
Jul 16 21:43:51 <ag_> sgw: Now i have 2 identical straces... 2 identical main functions...
Jul 16 21:44:16 <ag_> sgw: One survives out of clone() one doesn't...
Jul 16 21:44:31 <sgw> ag_: something must be different other wise they would both run!
Jul 16 21:44:52 <sgw> I know I am probably stating the obvious!
Jul 16 21:45:22 <ag_> :) obvious is a good thing to remind sometime ....
Jul 16 21:45:57 <sgw> ag_: I could try digging into it also, but have alot of stuff on my plate currently
Jul 16 21:46:20 <ag_> sgw: No worries. Thank you anyway.
Jul 16 21:49:19 <sgw> ag_: thanks for digging into it, I am sure we will get it figured out (hopefully sooner rather than later), check with rburton, he might also have some ideas, best during your day since his UK based and probably at home now.
Jul 16 21:50:00 <ag_> He is -1 from me. I am home as well.
Jul 16 21:50:31 <sgw> ag_: I figured you where home also.
Jul 16 21:51:05 <ag_> sgw: I will ask if he had any time to spend on this.
Jul 16 21:51:15 <walters> kind of offtopic, but i wish someone would just take all the tarball dependencies and import them into git
Jul 16 21:51:31 <walters> then you could sensibly clone/mirror them etc
Jul 16 21:51:44 <walters> get incremental downloads on updates...
Jul 16 21:52:29 <ag_> sgw: One more thing to tell you. As this is very very strange
Jul 16 21:52:40 <ag_> i replaced the main.c code with the one from 1.0
Jul 16 21:52:53 <ag_> it compiles ok... but guess what? still not working :)))
Jul 16 21:53:00 <ag_> this is strange...
Jul 16 21:53:13 <ag_> But i will figure it out somehow.
Jul 16 21:53:24 <sgw> ag_: different headers again this points to maybe configure issues.
Jul 16 21:53:54 <ag_> config.log are identical
Jul 16 21:54:32 <sgw> ag_: OK, you might just get me to try this now as it sounds pretty crazy, maybe later in my day (or tonight, like you )
Jul 16 21:55:18 <ag_> sgw: Ok. It's 1am here so i need sleep. I will get on this again tomorrow.
Jul 16 21:56:44 <ag_> I managed to compile and deploy dbus tests on board. Somebody was asking on mailinglist about this. Cannot remember who and my trash is empty.
Jul 16 22:31:58 <khem> zeddii: around
Jul 16 22:41:52 <msm> sgw: when's your next push to poky occur?
Jul 16 22:42:19 <msm> sgw: usually once i see those CONSOLIDATED PULLS they are in master ;)
Jul 16 22:42:23 <msm> sgw: just curious workflow wise
Jul 16 22:42:30 <sgw> msm: probably tomorrow
Jul 16 22:42:50 <msm> mk
Jul 16 22:43:05 <sgw> I should have sent the message last night, but did not have all my testing finished.
Jul 16 22:43:19 <msm> should'nt have?
Jul 16 22:54:58 <khem> is meta-networking up somewhere ?
Jul 16 23:02:44 <bluelightning> khem: discussions are ongoing I think
Jul 16 23:03:06 <khem> bluelightning: OK, I was thinking if its sampled somewhgere
Jul 16 23:11:25 <ag_> sgw: I found the issue...
Jul 16 23:12:12 <ag_> Anybody with some strong gdb knowledge?
Jul 16 23:12:42 <mranostay> don't ask to ask
Jul 16 23:13:22 <ag_> I have a binary from many sources. In one of these sources i have a local function called only locally. How can i gdb inside that local function.
Jul 16 23:13:23 <ag_> ?
Jul 16 23:13:33 <ag_> mranostay: I was writing the q already.
Jul 16 23:13:58 <khem> ag_: depends on how optimized your code is
Jul 16 23:14:20 <ag_> khem: Right...
Jul 16 23:14:23 <khem> generally if you say break <filename>:<funcname>
Jul 16 23:14:31 <khem> it should set the breakpt
Jul 16 23:14:33 <khem> on that function
Jul 16 23:14:34 <ag_> khem: Nope. It doesn't help.
Jul 16 23:14:49 <ag_> It stays at the point where the function is called.
Jul 16 23:14:52 <khem> so it means it has been inlined and gone
Jul 16 23:14:52 <ag_> Doesn't go inside.
Jul 16 23:15:03 <ag_> khem: y.
Jul 16 23:15:23 <khem> its a typical case of leaf function that gcc can inline
Jul 16 23:15:35 <khem> is it declared static
Jul 16 23:15:46 <ag_> yes :)
Jul 16 23:17:03 <khem> thats a sitting duck for compiler optimizers then
Jul 16 23:17:05 <khem> sorry
Jul 16 23:17:12 <bluelightning> khem: this may be of interest: https://github.com/joeythesaint/meta-networking/commits/joeythesaint/meta-networking-migration-3
Jul 16 23:17:21 <bluelightning> very preliminary
Jul 16 23:17:55 <ag_> thank you kem
Jul 16 23:18:02 <ag_> khem*
Jul 16 23:18:09 <khem> bluelightning: ok
Jul 16 23:18:11 <khem> thx
Jul 16 23:22:11 <khem> ag_: if you are hell bent on debugging it you can add this option -fno-inline-functions-called-once
Jul 16 23:22:20 <khem> just for debugging it thouhg
Jul 16 23:22:29 <khem> I dont want to see it in  a patch on mailing list tomorrow
Jul 16 23:25:42 <ag_> khem: thanks. Promise not going to do it! :0
Jul 16 23:25:44 <ag_> :)
Jul 16 23:32:20 <khem> good. since I dont peruse all patches shit gets in sometimes
Jul 16 23:36:11 <ag_> khem: Hope wasn't me
Jul 17 00:38:00 <ag_> sgw: The problem is here: gchar **connman_storage_get_services(). It seems that str is null and g_free ends up with invalid pointer...
**** ENDING LOGGING AT Tue Jul 17 02:59:58 2012

**** BEGIN LOGGING AT Tue Jul 17 02:59:58 2012
Jul 17 04:13:32 <seebs> Someday, there should be a pretty commonplace test which is to set the compiler up to emit "Hi, I'm a compiler!" to stderr whenever it is invoked in any way for any reason.
Jul 17 04:14:09 <seebs> Because I have spent just about enough time finding and fixing "compiler bugs" that are actually packages assuming that "this compile failed" and "there was output to stderr" are precisely equivalent claims.
Jul 17 04:15:52 <kergoth> heh, seen that before
Jul 17 04:15:55 <kergoth> silly buildsystems
Jul 17 04:16:34 <seebs> It bites me because the 4th law of thermodynamics is "seebs cannot remember to throw in the dummy get_feature binary for the license check that some customer once demanded we add to the compiler".
Jul 17 06:40:04 <ohmi> hi, i'm using to build an image. I receive the following error : unable to fetch ftp://ftp.de.debian.org/debian/pool/main/m/mklibs/mklibs_0.1.33.tar.gz which does not exists. what can I do ?
Jul 17 06:48:07 <Orre> What image did you try to bake?
Jul 17 06:49:13 <ohmi> core-image-base
Jul 17 06:51:02 <ohmi> sorry I missed a word in my previous sentence. I'm using hob to build the image
Jul 17 07:40:08 <mckoan> good morning
Jul 17 07:43:52 <Orre> ohmi: I  don't recognise the error I have built the core-image-base quite a few times. Do you use your own mirrors?
Jul 17 07:43:59 <Orre> good morning mckoan!
Jul 17 07:44:33 <ag_> Orre: That links is down.
Jul 17 07:45:02 <Orre> ah_: Ah, ok. Then nvm ohmi, I was wrong.
Jul 17 07:45:31 <ag_> Orre: And he is not around anymore. :)
Jul 17 07:51:13 <Orre> :(
Jul 17 07:55:58 <Orre> ag_: I get some problems trying to bake meta_toolchain - though if I just want to bake the toolchain for baking a core-image-basic for a qemux86 machine so it can be used for a shared state, is there another toolchain I can attempt to bake?
Jul 17 08:25:59 <bluelightning> morning all
Jul 17 08:31:02 <ag_> cheers
Jul 17 08:32:30 <bluelightning> hi ag_
Jul 17 08:38:24 <Orre> morning
Jul 17 09:07:23 <ag_> Orre: It should work just as it is. Anyway i didn't play with meta toolchain lately... so maybe someone else can reply to that.
Jul 17 09:08:56 <Orre> ag_: It's a problem with not finding users or groups which are needed. Likely caused by company security protection on the computer? So hoped that there are another toolchain that can be used?
Jul 17 09:10:30 <Orre> Or at least that could be tested if I could bake it to see if it's the same issue on all toolchain bake.
Jul 17 09:22:30 <seebs> If you are using security stuff which actually prevents yocto from doing its fake user ID stuff, the answer is "nothing is gonna work".
Jul 17 09:22:41 <seebs> If you aren't, then you shouldn't need any special privileges or permissions.
Jul 17 10:37:41 <rburton> anyone doing poky with gnu make 3.82? i've a package that needs a test build...
Jul 17 10:40:04 <bluelightning> rburton: 3.81 here I'm afraid...
Jul 17 10:40:30 <rburton> everyone sensible has .81 it appears, apart from my old  build machine
Jul 17 10:40:52 <ag_> rburton: what package?
Jul 17 10:40:54 <rburton> .82 changed a lot of behaviour for a point release
Jul 17 10:40:56 <rburton> ag_: ahem, webkit
Jul 17 10:41:16 <JaMa> I'm building it with 3.82 right now
Jul 17 10:41:22 <ag_> rburton: I thought connman ;)
Jul 17 10:41:29 <rburton> JaMa: you want the branch i'm about to push :)
Jul 17 10:41:58 <JaMa> so openembedded-core/meta/recipes-sato/webkit/webkit-gtk_1.8.1.bb should fail?
Jul 17 10:43:28 <ag_> Anybody with a mips core-image-sato-sdk baked?
Jul 17 10:43:39 <rburton> ag_: funnily enough, yes :)
Jul 17 10:43:45 <rburton> ag_: connman bloody works in it though
Jul 17 10:44:03 <ag_> rburton: I found the issue
Jul 17 10:44:32 <rburton> JaMa: oh RP merged it already.  remove the PARALLEL_MAKE line first
Jul 17 10:44:34 <ag_> rburton: WOuld you please tell me what Filesystem features it has?
Jul 17 10:44:56 <rburton> ag_: EXTRA_IMAGE_FEATURES = "debug-tweaks tools-sdk tools-debug dev-pkgs dbg-pkgs"
Jul 17 10:45:08 <ag_> Filesystem features
Jul 17 10:45:16 <ag_> debugfs /dev/hda
Jul 17 10:45:32 <rburton> ah
Jul 17 10:45:35 <rburton> let me boot it
Jul 17 10:45:41 <ag_> rburton: Thanks a lot.
Jul 17 10:46:10 * rburton lets the bitbake run finish, should be done in a few
Jul 17 11:05:42 * ag_ is staring at at NOTE: package qt4-x11-free-4.8.1-r44.1
Jul 17 11:06:06 <JaMa> ag_: do you need coffee or book? :)
Jul 17 11:06:25 <ag_> JaMa: Both. :)
Jul 17 11:07:03 * ag_ is dreaming at a computer which bakes qt in 10 minutes...
Jul 17 11:08:48 <RP> rburton: sorry, didn't see your comment until it was too late
Jul 17 11:09:16 <ag_> rburton: Finished? I want to go to the office so i have to switch my computer on sleep.
Jul 17 11:14:57 * ag_ Be right back...
Jul 17 12:14:04 <rburton> ag_: oh crap, i've forgotten what the features were
Jul 17 12:14:10 <rburton> ag_: needs_recovery and something_journal i think
Jul 17 12:14:50 <ag_> rburton: Thank you.
Jul 17 12:17:08 <ag_> rburton: Have you ever seen a situation when d->d_type is always 0?
Jul 17 12:19:09 <ag_> 0 = DT_UNKNOWN
Jul 17 13:02:12 <rburton> ag_: isn't that something that happens with xfs/reiserfs?
Jul 17 13:02:34 <ag_> rburton: and with ext3 apparently....
Jul 17 13:02:44 <ag_> with some of them
Jul 17 13:02:54 <rburton> hm, i thought ext3 didn't do that. i've just used all of my kernel knowledge though :)
Jul 17 13:03:39 <ag_> rburton: I had a talk on connman irc. This is reported but not debugged yet.
Jul 17 13:03:54 <ag_> rburton: I got to the root of the problem in connman.
Jul 17 13:04:05 <rburton> ag_: comically, i can;t get the crash in gdb
Jul 17 13:04:17 <ag_> rburton: I know.
Jul 17 13:04:25 <ag_> rburton: This is because it detaches.
Jul 17 13:04:35 <ag_> rburton: Use run -n
Jul 17 13:04:38 <rburton> yes, i did
Jul 17 13:04:50 <rburton> and connman is happily running
Jul 17 13:04:54 <ag_> 1.3?
Jul 17 13:05:03 <ag_> on mips?
Jul 17 13:05:18 * ag_ gotta see this.... :|
Jul 17 13:05:39 <rburton> well on mips it crashed but wasn't useful at all -- there's a mail on the connman moderation queue with my gdb output
Jul 17 13:05:46 <rburton> apparently it will never be moderated though
Jul 17 13:06:00 <rburton> ppc its not starting on boot, but if i run it in a gdb it works
Jul 17 13:06:30 <ag_> rburton: Do you have a couple of minutes to test a patch on ppc as well?
Jul 17 13:06:39 <rburton> sure
Jul 17 13:07:57 * ag_ is commiting change
Jul 17 13:11:40 <ag_> rburton: https://gist.github.com/b15754a3468d484f87da
Jul 17 13:11:51 <ag_> rburton: Can you see this. I made it private by mistake... :(
Jul 17 13:12:32 <rburton> yes
Jul 17 13:18:07 <rburton> ag_: oh, special. first boot on ppc doesn't work, subsequent boots do
Jul 17 13:18:40 <ag_> rburton: With that patch?
Jul 17 13:18:48 <rburton> without that patch
Jul 17 13:19:12 <ag_> rburton: Uh. Didn't check ppc as i don't have a ppc build.
Jul 17 13:21:05 <rburton> ag_: why would it crash without your patch?
Jul 17 13:21:31 <rburton> or is it unrelated to the crasher
Jul 17 13:22:14 <ag_> rburton: g_string_append_printf(result, "%s/", d->d_name); this is never used becase d_type is always 0.
Jul 17 13:22:32 <ag_> str = g_string_free(result, FALSE);
Jul 17 13:22:39 <ag_> So str will be null
Jul 17 13:22:52 <ag_> g_free(str); - invalid pointer error
Jul 17 13:24:51 <rburton> just move the g_free inside the if (str) block
Jul 17 13:25:15 <ag_> sadly that doesn't work
Jul 17 13:25:25 <ag_> but that is a workaround
Jul 17 13:25:25 <rburton> that's a separate and valid fix from any DT_UNKNOWN issues
Jul 17 13:25:43 <rburton> no, hang on
Jul 17 13:25:49 <rburton> g_free(NULL) is a no-op
Jul 17 13:26:39 <ag_> ...
Jul 17 13:27:09 <ag_> no operation?
Jul 17 13:27:24 <rburton> g_free(NULL) is documented as being safe and doing nothing
Jul 17 13:27:28 <rburton> (so is free())
Jul 17 13:27:56 <ag_> if you have a build just br the line with free
Jul 17 13:28:15 <ag_> trust me it triggers invalid pointer
Jul 17 13:28:41 <rburton> sure, but it's not because of a null
Jul 17 13:28:55 <ag_> hm...
Jul 17 13:28:57 <rburton> the abort I was seeing on mips was a totally invalid pointer
Jul 17 13:29:10 <ag_> that was the error
Jul 17 13:30:47 <ag_> Of so it was not allocated.
Jul 17 13:30:55 <rburton> it should be NULLs all the way to the end
Jul 17 13:31:06 <ag_> it seems like the address is not null but the memory is empty
Jul 17 13:31:10 * rburton walk dog, back shortly
Jul 17 13:31:47 <rburton> result is a valid gstring, with NULL content. if nothing happens in the while, result is freed and str should become NULL
Jul 17 14:03:57 <jstashluk> I've created a new kernel module and put it in the defconfig, but I can't seem to get it into modules-$(VERSION)-r3-$(MACHINE).tgz.  What controls this?
Jul 17 14:13:24 <zeddii> jstashluk, are you getting other modules, and just not the new one ? or none at all ?
Jul 17 14:14:58 <jstashluk> I am getting other modules, just not the new one.
Jul 17 14:19:13 <zeddii> ok. and how many .. ? I'm trying to see if you have kernel-modules in your IMAGE_INSTALL or RRDEPENDS, if you do, it really should get repackaged and appear. if not, you need to individually require the module.
Jul 17 14:19:56 <ag_> rburton: yes. But when result is freed str gets ownership of the buffer which is empty.
Jul 17 14:20:16 <ag_> rburton: So str will point to an empty location.
Jul 17 14:20:24 <rburton> hm
Jul 17 14:20:28 <ag_> rburton: That's why g_free dies.
Jul 17 14:20:37 <rburton> i thought that but decided that it should be returning NULL
Jul 17 14:20:39 <rburton> time for a test :)
Jul 17 14:20:50 <ag_> rburton: Wait a sec.
Jul 17 14:21:03 <ag_> rburton: I added and extra check that i forgot.
Jul 17 14:21:10 <rburton> ag_: so why doesn't it break on intel?
Jul 17 14:21:24 <ag_> rburton: Hmmm... hard to say... :)
Jul 17 14:21:27 <rburton> (not arguing with you, just curious if you'd worked that out)
Jul 17 14:22:02 <ag_> rburton: I managed to see the problem in connman. For here on there is a problem in... kernel / fs / whatever.
Jul 17 14:22:15 <ag_> rburton: Here is a hint: http://sources.redhat.com/bugzilla/show_bug.cgi?id=226
Jul 17 14:22:21 <jstashluk> zeddii:  I have quite a few modules that get packaged, including some in the drivers/media/video/mxc/capture/ where my new module is.
Jul 17 14:22:48 <ag_> rburton: That's why i asked for fs features.... but it seems it 's not the case...
Jul 17 14:26:11 <rburton> ag_: ok, so new gstring / free results in the char* being a valid empty string
Jul 17 14:26:19 <rburton> i.e. \0
Jul 17 14:28:18 <ag_> rburton: Somehow.
Jul 17 14:28:33 <rburton> ag_: because that's what the code does
Jul 17 14:28:42 <rburton> ag_: NULL input transforms into empty valid string
Jul 17 14:29:07 <ag_> rburton: Come again?
Jul 17 14:33:31 <ag_> rburton: Indeed. result is a valid empty string but the problem seems to be when transfering ownership to str.
Jul 17 14:33:47 <rburton> ag_: figured it out, see #connman
Jul 17 14:54:01 <FunkyPenguin> is it possible to provide dts files statically rather than via a git repo?
Jul 17 14:54:12 <ag_> FunkyPenguin: Yes.
Jul 17 14:54:15 <ag_> file://
Jul 17 14:54:40 <ag_> Nevermind. Didn't read the whole question :)
Jul 17 14:55:33 <FunkyPenguin> ag_: so is that a no then? :)
Jul 17 15:00:11 <scottrif> Scott Rifenbark has joined the YP Technical Team meeting
Jul 17 15:00:21 * fray is about to dial in
Jul 17 15:00:39 * rburton too
Jul 17 15:01:20 * sgw Saul is dialed in
Jul 17 15:01:25 * denix| joined the call as well
Jul 17 15:01:30 <jmpdelos> Jeff P as well
Jul 17 15:01:31 <zenlinux> ScottG is on the call
Jul 17 15:01:39 <bluelightning> Paul Eggleton is on the call
Jul 17 15:01:43 * fray is on
Jul 17 15:01:43 <tomz2> tomz on the call
Jul 17 15:01:49 <sgw> fray: your back!  Can I get some of your time today?
Jul 17 15:01:53 <gcoville> Gilbert Coville (from Mentor) is on the call
Jul 17 15:02:01 <fray> ya..  I'm back for the day, then I'm off to a meeting tomorrow..
Jul 17 15:02:08 * RP is on the call
Jul 17 15:02:10 * fray was at Comic-Con SD
Jul 17 15:02:10 <halstead> YTTM: Michael Halstead present.
Jul 17 15:02:15 <zeddii> BruceA is on the call.
Jul 17 15:02:17 <Guest67134> YPTM: hi all, let's start the technical team meeting now
Jul 17 15:02:25 * rburton is on
Jul 17 15:02:35 <zenlinux> YTTM: ScottG present
Jul 17 15:02:57 <rburton> YPTM: ross burton present
Jul 17 15:03:08 <joshuagl> YPTM: Joshua is here
Jul 17 15:03:09 <fray> YPTM: I'm here
Jul 17 15:03:17 <zeddii> YPTM: Bruce Ashfield is on.
Jul 17 15:03:41 <denix|> YTTM/YPTM...
Jul 17 15:03:58 <RP> Guest67134: YPTM: Richard is on the call
Jul 17 15:04:07 <darknighte> YPTM: sean hudson dialing in
Jul 17 15:04:42 <sgw> Guest67134: should use /nick to nickname himself YPTM
Jul 17 15:04:48 <Guest67134> YPTM: let's collect some opens now
Jul 17 15:05:27 <jzhang> YPTM: Jessica's on the call
Jul 17 15:05:59 <denix|> YPTM: no opens from me - was on vacation for few weeks...
Jul 17 15:06:09 <darknighte> denix: welcome back
Jul 17 15:06:20 <denix|> thx
Jul 17 15:06:38 <nitink> YPTM: nitin is here
Jul 17 15:07:18 <sgw> YPTM: I will have a status update/open about package updating
Jul 17 15:07:36 <RP> Can people please mute as there is a horrible echo
Jul 17 15:07:41 <sgw> Guest67134: there's a really bad echo
Jul 17 15:08:15 <fray> much better
Jul 17 15:08:16 <sgw> Much better here
Jul 17 15:08:17 <gcoville> is there a special code to mute?
Jul 17 15:08:19 <darknighte> thank you song.  much better.
Jul 17 15:08:26 <dvhart> *6
Jul 17 15:08:32 <dvhart> gcoville, ^
Jul 17 15:08:36 <gcoville> thx
Jul 17 15:08:39 <darknighte> gcoville: same as our system
Jul 17 15:08:40 <fray> *6 unmute as well?
Jul 17 15:08:44 <bluelightning> yep
Jul 17 15:08:46 <dvhart> song: darren has joined
Jul 17 15:08:49 <fray> 'k..
Jul 17 15:09:09 <darknighte> I thought it was *7 to unmute.  that explains why no one can hear me.
Jul 17 15:09:12 <darknighte> ;)
Jul 17 15:10:12 <dvhart> :)
Jul 17 15:12:21 <msm> sgw: did you see my followup fix for libgomp QA issue
Jul 17 15:12:23 <msm> it's in
Jul 17 15:12:24 <msm> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mattsm/master
Jul 17 15:13:02 <sgw> msm: catching up this morning!
Jul 17 15:13:03 <msm> ;)
Jul 17 15:13:09 <msm> no worries, just checking
Jul 17 15:13:21 <msm> i rebase that tree just now
Jul 17 15:14:09 <darknighte> msm: you on the tech call?
Jul 17 15:14:21 <msm> no
Jul 17 15:14:29 <msm> we have this other meeting at 10am on tues...
Jul 17 15:14:34 <msm> its tough to make those now
Jul 17 15:14:35 <darknighte> just curious.
Jul 17 15:15:57 <joshuagl> msm: your feedback on 1.1.2 release readiness has been requested before we push forward with a release
Jul 17 15:16:35 <msm> joshuagl: did you change your nick?
Jul 17 15:16:53 <joshuagl> msm: oh, yeah :-)
Jul 17 15:17:05 <msm> joshuagl: i've found that single issue with older CentOS 5.x distros I've been trying to find the root cause
Jul 17 15:17:13 <msm> joshuagl: that's why i never see you online anymore...
Jul 17 15:17:26 <joshuagl> msm: I'm rarely on Freenode atm
Jul 17 15:17:43 <joshuagl> I will try and repro the Centos 5.x issue and get back to you today
Jul 17 15:17:50 <msm> joshuagl: ok just for the call then
Jul 17 15:18:04 <msm> joshuagl: running "bitbake eglibc-locale -c cleanall; bitbake eglibc-locale"
Jul 17 15:18:13 <msm> on a mpc8315e-rdb seems to show the issue
Jul 17 15:18:21 <joshuagl> LaurentiuSerban: do you know if 1.1.2 was tested on CentOS 5,x ?
Jul 17 15:18:32 <msm> make sure the centos box is up to date (or if it's not test it on the older centos first before upgraded)
Jul 17 15:19:28 <msm> i was emailing LaurentiuSerban on yocto ml
Jul 17 15:21:17 <joshuagl> yeah, I was just trying to prompt a response :-)
Jul 17 15:22:53 <darknighte> Guest67134: YPTM: I have to drop.
Jul 17 15:23:46 <fray> YPTM: I've been on vacation for the past week.. so I have nothing to report
Jul 17 15:24:52 <fray> I will be around today
Jul 17 15:25:19 <sgw> fray sounds your going to be popular, I have both update-alternative question and we need to look at your RPM/Zypper issues
Jul 17 15:25:28 * RP has been working on build stabilisation and bug fixing, I think this next week is more of the same
Jul 17 15:25:29 * davest just joined the technical team meeting
Jul 17 15:25:55 <davest> YPFM: had a conflicting meeting which just ended
Jul 17 15:26:07 <fray> ya, I'll be traveling for work the rest of this week, but will be on email and probably IRC for at least some of it each day
Jul 17 15:26:10 <sgw> fray: also a opkg issue similar to your RPM issue with the populate_sdk
Jul 17 15:26:22 <fray> (just going to colorado for meetings, so it's not going to be radically different for timezone)
Jul 17 15:26:26 <fray> ok
Jul 17 15:26:28 <RP> halstead: we can't hear you
Jul 17 15:26:49 <RP> halstead: that was better
Jul 17 15:27:57 <fray> this large directory problem is something that we had observed as well..
Jul 17 15:28:16 <RP> fray: yes, we need to fix it. Lets file a bug and get it done
Jul 17 15:28:26 <fray> Hmm I thought I had before.. perhaps not
Jul 17 15:28:30 <sgw> fray: there is a script called sstate-cache-management.sh, but that's after the fact clean up,
Jul 17 15:28:32 * fray goes to look
Jul 17 15:28:48 <fray> what we saw was based on a world build.. not even multiple builds
Jul 17 15:28:59 <fray> significant filesystem slow down due to number of files in a single directory
Jul 17 15:29:40 <sgw> yeah, that's what the AB was seeing over NFS
Jul 17 15:29:45 * nitink 's voice is not going through
Jul 17 15:29:56 * fray had fun at Comic-Con San Diego  ;)
Jul 17 15:30:06 <davest> Did we decide to release 1.2.1 ?
Jul 17 15:30:17 <bluelightning> fray: did you get any autographs?
Jul 17 15:30:17 <RP> davest: subject to CCB, yes
Jul 17 15:30:17 <fray> (more fun then working w/ the Yocto Project -- at least for the 4 days)
Jul 17 15:30:18 <davest> eh?
Jul 17 15:30:23 <davest> yes I am
Jul 17 15:30:30 <fray> bluelightning na, not into autographs..  but attended a lot of events and such..
Jul 17 15:31:24 <fray> my kid was doing celebrity spotting constantly.. she gets a huge grin on her face..  (if anyone watched Vampire Diaries..  the "brother" of the female lead was playing video games on the floor and she spotted him.. nobody else did.. as she says "he's hot")  hahahaha
Jul 17 15:33:34 <Guest67134> YPTM: that was a short meeting! Thanks for joining the meeting, you all have nice day or night :)
Jul 17 15:50:59 <rburton> halstead: there?
Jul 17 15:55:52 <sgw> nitink: I think rburton was looking for you
Jul 17 15:56:11 <rburton> nitink: i was, but it doesn't matter now
Jul 17 15:56:19 <rburton> thanks though sgw
Jul 17 15:56:30 <nitink> sgw rburton: ok
Jul 17 15:56:40 <nitink> time to sleep here
Jul 17 15:59:56 <rburton> nitink: g'night
Jul 17 16:06:03 <ag_> nitink: G night
Jul 17 16:14:04 <halstead> rburton, Yes.
Jul 17 16:14:52 <rburton> halstead: seeing a problem with the builder, thought you might be able to help: https://bugzilla.yoctoproject.org/show_bug.cgi?id=2781
Jul 17 16:19:11 <ag_> rburton: Good job with the princ :)
Jul 17 16:39:29 <ag_> sgw: Please don't kill me and let me send another patch set with connman update... i am soooo tired and i messed up things....
Jul 17 16:45:06 <halstead> rburton, It will have to wait for pidge. I don't have access to check on nas02 or ab07 at the moment.
Jul 17 16:45:27 <sgw> ag_: can you also pull in rburton's changes so there's one connman change set to apply
Jul 17 16:45:41 <sgw> ag_: you really need to take a break if your that tired.
Jul 17 16:46:11 <ag_> sgw: I know. I will pull in his patch and pull req the whole pack.
Jul 17 16:47:11 <sgw> ag_: he has 2 patches, but I think the automake one RP is going to pull now because 1.0 connman will break without it.
Jul 17 16:47:52 <ag_> sgw: Give me a link to the archive where is the patch you want me to pull in
Jul 17 16:48:53 <sgw> ag_: see rburton's email following your this morning on the oe-core list, you can also check contrib/ross/connman (I think)
Jul 17 16:49:51 <ag_> sgw: So you want only this: connman: fix crashes on startup on PPC/MIPS
Jul 17 16:52:28 <sgw> ag_: yeah, rburton, correct?
Jul 17 16:53:05 <ag_> sgw: rburton: Here it is contrib/ag/connman1.3
Jul 17 17:11:03 <sgw> rburton: AB nightly launched, I will be tending it during the day, and might launch a MUT following it's completion.
Jul 17 17:15:43 * ag_ takes a break not before thanking rburton and sgw.
Jul 17 17:17:21 <sgw> ag_: many thanks to you on getting that patch
Jul 17 17:17:33 * sgw just missed him!
Jul 17 18:28:47 <jstashluk> zeddii: there was something in sstate-cache/sstate-linux-imx-imx6qsabrelite-..._deploy.tgz that kept getting used even though I changed the kernel SRC_URI.
Jul 17 18:49:09 <zeddii> jstashluk, aha. that would explain it. were you enabling it via menuconfig or from scratch in your defconfig ?
Jul 17 18:49:29 <joshuagl> msm: are you around to talk Edison?
Jul 17 18:50:31 <msm> sort of
Jul 17 18:50:39 <joshuagl> better by email?
Jul 17 18:50:40 <msm> joshuagl: have a meeting in 10 minutes
Jul 17 18:50:54 <joshuagl> ping me when you get back?
Jul 17 18:50:56 <msm> either is fine, just have to go for a bit at 2
Jul 17 18:50:57 <msm> ok
Jul 17 18:52:26 <Crofton|work> um meetings
Jul 17 18:58:26 <onoffon> zeddii do you know what will next ltsi version
Jul 17 18:58:50 <zeddii> it is suppose to be 3.4, but nothing is official until Greg actually sends something out :)
Jul 17 18:58:55 <zeddii> s/suppose/supposed/
Jul 17 18:59:10 <onoffon> zeddii ok
Jul 17 19:06:20 <chackal_sjc> how to install .ttf font files ??
Jul 17 19:28:33 <msm> joshuagl: im back
Jul 17 19:30:51 <jstashluk> zeddii: menuconfig from my local copy of the kernel repo, then copied over to the yocto kernel package directory
Jul 17 19:31:24 <zeddii> jstashluk. ok, so that make sense as well. sstate wouldn't have been invalidated.
Jul 17 19:31:50 <jstashluk> zeddii: how do you make sure sstate gets invalidated?
Jul 17 19:32:34 <zeddii> if you run menuconfig within bitbake it will happen automatically, but bitbake -c cleansstate should also work (I don't think that removes anything but state).
Jul 17 19:34:44 <jstashluk> bitbake -c menuconfig virtual/kernel never worked for me
Jul 17 19:35:35 <zeddii> oh really ? it works here. what did it do for you ?
Jul 17 19:36:30 <jstashluk> ERROR: Unable to spawn terminal auto: Execution of 'gnome-terminal --disable-factory -t "linux-imx Configuration" -x make menuconfig' failed with exit code 1:
Jul 17 19:36:47 <JaMa> menuconfig doesn't work very well here since May 31.. http://lists.linuxtogo.org/pipermail/openembedded-core/2012-June/024199.html
Jul 17 19:37:33 <zeddii> ah yes. I looked into that from a report here @ work as well .. it didn't work for one person, but worked on my desktop, same tree. It must be env/locale that is triggering it.
Jul 17 19:38:11 <JaMa> 2 persons and both had this problem only after referenced commit..
Jul 17 19:38:35 <zeddii> agreed that the commit is somehow related, but it isn't universal.
Jul 17 19:38:43 <zeddii> all my trees have that, none have problems with menuconfig.
Jul 17 19:38:46 <zeddii> but yet others do.
Jul 17 19:40:00 <joshuagl> msm: hey, so I just wanted to see if I have understood things correctly. It reads to me like you would like to upstream your changes to the Edison branch of Poky but are indifferent as to whether there's an official release made with those changes in?
Jul 17 19:40:47 <zeddii> jstashluk, have you tried changing your OE_TERMINAL to screen ?
Jul 17 19:41:14 <jstashluk> zeddii: seems to have something to do with running inside of a terminal multiplexer (byobu).  It works inside of a normal gnome-terminal
Jul 17 19:41:54 <jstashluk> zeddii: should that go inside of local.conf or site.conf?
Jul 17 19:42:36 <zeddii> I have it in my local.conf
Jul 17 19:46:53 <jstashluk> zeddii: that works.  Thanks.
Jul 17 19:48:17 <zeddii> cool.
Jul 17 19:48:24 <joshuagl> msm: which Python are you using on CentOS 5.x?
Jul 17 19:49:07 <msm> joshuagl: $ /opt/python2.6/bin/python2.6 --version
Jul 17 19:49:07 <msm> Python 2.6.4
Jul 17 19:49:29 <msm> im not recalling where we got it either
Jul 17 19:49:31 <joshuagl> I meant to ask how you installed it?
Jul 17 19:49:40 <joshuagl> ah, okey dokes
Jul 17 19:52:05 <msm> joshuagl: sidemessage
Jul 17 21:23:57 <kergoth> joshuagl: i suggest getting python2.6 from epel - http://fedoraproject.org/wiki/EPEL
Jul 17 21:24:01 <kergoth> thats what i do, anyway
Jul 17 21:24:41 <joshuagl> kergoth: yup, I just did so
Jul 17 21:24:44 <joshuagl> thanks
**** ENDING LOGGING AT Wed Jul 18 02:59:58 2012

**** BEGIN LOGGING AT Wed Jul 18 02:59:59 2012
Jul 18 03:14:13 <nitink> Good Morning !
Jul 18 08:04:28 <bluelightning> morning all
Jul 18 08:05:00 <Orre> morning bluelightning!
Jul 18 08:05:10 <JaMa> moin
Jul 18 08:05:12 <bluelightning> hi Orre
Jul 18 08:05:16 <bluelightning> hi JaMa
Jul 18 08:08:21 <Orre> Does all Yocto packages use automake? Do some use autoconf? Is there other ways Yocto keep packages up to date?
Jul 18 08:09:46 <bluelightning> Orre: er, we use autotools when the package being built uses autotools; it has no uses for package updating...
Jul 18 08:10:37 <Orre> Erm, used the wrong words. Wrote that in a hurry... :(
Jul 18 08:10:55 <Orre> Meant kept packages autogenerated
Jul 18 08:11:20 <Orre> Is there other ways that autotools that you use?
Jul 18 08:12:28 <Orre> Meant "than autotools". Noticing I've had too little coffee today, seems I can't write properly on a keyboard any more.
Jul 18 08:21:19 <bluelightning> Orre: I'm still confused, are you able to restate the question?
Jul 18 08:27:27 <Orre> bluelightning: We wanted to know how the packages are prepared so they can be portable as to know if they would be portable to our systems. We use automake/autoconf so we haven't got any issues with continued use of such tools, but if you are using other ways to make the packages portable we would need to know which ones as to learn how to use those tools.
Jul 18 08:28:16 <bluelightning> Orre: ok, so my answer stands - if the upstream source of a particular piece of software uses autotools then that's what we use to build the software
Jul 18 08:28:26 <bluelightning> if they use something like cmake, then we use that
Jul 18 08:28:45 <bluelightning> each piece of software is different
Jul 18 08:28:55 <bluelightning> some just have plain makefiles
Jul 18 08:29:25 <Orre> bluelightning: Thanks, just wanted to know if you adapted the packages in any way for Linux-Yocto. :)
Jul 18 08:31:52 <bluelightning> not really, no... it's much easier to just go with whatever upstream uses
Jul 18 08:35:59 <RP> Orre: In general its easier if something uses autotools since we have a lot of experience with it and it generally "just works"
Jul 18 08:36:25 <RP> Orre: Not that I like autotools, it is just the devil we know
Jul 18 09:21:09 <Orre> Thanks at least. :) Do you guys happen to know where the sourced packages ends up after a bake? poky-denzil-7.0/build/tmp/work/???
Jul 18 09:23:15 <bluelightning> Orre: that's where we extract the source to in order to build it
Jul 18 09:23:42 <bluelightning> Orre: we have a different mechanism for source distribution for license compliance, if that's what you're asking about
Jul 18 09:24:38 <Orre> Just wanted to know where the source which is used for a build is extracted if I baked a for example "core-image-basic".  :)
Jul 18 09:25:10 <Orre> I can't find any sourced packages under poky-denzil-7.0/build/tmp/work/core-image-basic-1.0-r0 are they located somewhere else?
Jul 18 09:25:55 <bluelightning> Orre: they don't get extracted under the image name, they are extracted under their own names
Jul 18 09:26:35 <Orre> bluelightning: Below which folder at work?
Jul 18 09:27:24 <bluelightning> Orre: depends on what the specific recipe is being built for - the host machine (native), target arch, target machine etc.
Jul 18 09:27:36 <bluelightning> you'll notice subdirectories corresponding to each of those
Jul 18 09:28:28 <Orre> Ah, so they are divided properly between the different directories.
Jul 18 09:30:57 <bluelightning> Orre: yes
Jul 18 09:40:17 <JaMa> btw: yocto bugzilla should have Component: classes or something like that for Product: OE-Core
Jul 18 09:40:52 <JaMa> bluelightning: Should I fill buildhistory feature request for you (the one about runtime package names)?
Jul 18 09:47:53 <bluelightning> JaMa: it's already on my internal todo list but feel free to create an enhancement bug
Jul 18 09:50:04 <JaMa> bluelightning: done
Jul 18 09:53:27 <bluelightning> JaMa: thanks
Jul 18 10:57:41 <rburton> michael: "we have a variable for that" - yocto
Jul 18 10:57:41 <rburton> michael: new strapline for you
Jul 18 10:58:02 <rburton> (quote from michael)
Jul 18 11:07:34 <bluelightning> that's michael wood, not halstead ;)
Jul 18 11:17:16 <rburton> bluelightning: good point
Jul 18 11:17:54 <rburton> is anyone else seeing "/usr/bin/install: cannot remove `/usr/include/limits.h': Permission denied" when building eglibc-initial (oe-core,master)
Jul 18 11:19:09 <JaMa> rburton: I can confirm webkit-gtk building fine without PARALLEL_MAKE and with make-3.82
Jul 18 11:20:01 <rburton> JaMa: what host distro?
Jul 18 11:20:47 <JaMa> gentoo
Jul 18 11:27:19 <rburton> cool
Jul 18 11:27:27 <rburton> so it works with .82 on debian and gentoo
Jul 18 11:27:37 <rburton> maybe my failure on my old f16 machine was actually something else
Jul 18 11:38:11 <rburton> khem: there?
Jul 18 12:14:37 <JaMa> rburton: in your last email about eglibc it's not clear to which version you've reverted from which version :)
Jul 18 12:14:45 <rburton> heh
Jul 18 12:14:51 <rburton> i went from 3.82 to 3.81
Jul 18 12:57:05 <Orre> The x-load which is asked for when creating an ARM image - is it a 2nd stage booting device to boot up U-boot or is it a graphical view of the system load?
Jul 18 13:05:02 <bluelightning> Orre: http://beagleboard.org/project/X-Loader/
Jul 18 13:09:43 <Orre> Thought that one was correct, though couldn't be sure as it's named x-load in the Yocto settings while it's named X-Loader by Beagleboard. :)
Jul 18 14:05:16 <Orre> When I have baked a meta-toolchain, where does said toolchain end up? deploy/images? What is its new name?
Jul 18 14:14:04 <JaMa> Orre: deploy/sdk probably
Jul 18 14:14:44 <JaMa> rburton: your webkit patches were already pushed by RP.. so no need to repush your webkit branch :)
Jul 18 14:15:04 <JaMa> rburton: the same with sanity patch
Jul 18 14:15:08 <JaMa> rebase them both :)
Jul 18 14:15:54 <rburton> JaMa: yeah just discovered RP already merged
Jul 18 14:18:40 <Orre> Thanks Jama
Jul 18 14:21:55 <Orre> hmm, if I set tcmode to the tcmode-external-csl and set external-toolchain to the generated meta-toolchain it throws an error as the structure obviously doesn't fit. Is there any simple way to use the baked meta-toolchain as an external toolchain?
Jul 18 14:26:05 <bluelightning> Orre: no, it's not designed to be used that way
Jul 18 14:44:17 <JaMa> rburton: have you tried upgrading webkit-gtk to 1.9.*?
Jul 18 14:44:28 <rburton> JaMa: no
Jul 18 14:44:34 <JaMa> rburton: I would need to upgrade libsoup-2.4 to 2.39.4 for webkit-efl
Jul 18 14:45:00 <JaMa> rburton: so for now I've upgraded only to older rev which should work with your libsoup-2.4
Jul 18 14:45:26 <rburton> hmm development releases, what fun
Jul 18 15:02:03 <rburton> humpf, gtk3 from meta-oe doesn't configure
Jul 18 15:06:01 <JaMa> why?
Jul 18 15:06:18 <JaMa> http://patchwork.openembedded.org/patch/32333/ ?
Jul 18 15:33:08 <rburton> JaMa: no, but that would be useful :)
Jul 18 15:33:24 <rburton> JaMa: "HAVE_INTROSPECTION does not appear in AM_CONDITIONAL"
Jul 18 15:33:31 <rburton> need g-i m4, at a guess
Jul 18 15:33:54 <JaMa> I haven't seen this one yesterday..
Jul 18 15:35:26 <walters> i should probably just put introspection.m4 in gtk-doc-stub too
Jul 18 15:39:27 <kergoth> Hmm, from what i can tell, the only thing that actually relies on running at do_package time in buildhistory is the bit that inspects pkgdest.. so a slightly modified version could run in a posthook on do_package_write_setscene or something but actually looks inside the packages in DEPLOY_DIR instead of in pkgdest.. ugh, then we'd have to have  mechanism of inspecting package archives or all package types.. maybe its more trouble than its worth to gen
Jul 18 15:39:33 * kergoth thinks
Jul 18 15:40:42 <rburton> walters: that would be a very good move
Jul 18 15:41:00 <rburton> walters: you do that, i'll put gtk-doc-stub into my oe-core branch, and together we'll win!
Jul 18 15:44:17 <walters> rburton: care to test http://pastebin.mozilla.org/1707381 ?
Jul 18 15:44:40 <rburton> walters: i certainly can when i've got gtk-doc-stub in oe-core
Jul 18 15:44:43 <walters> ok
Jul 18 15:44:49 <rburton> walters: unless you already have a package for it?
Jul 18 15:45:07 <walters> nope, it's built in my no-packages-here build system
Jul 18 15:45:26 <walters> http://git.gnome.org/browse/gnome-ostree/tree/gnomeos-3.6.json#n46
Jul 18 15:46:40 <rburton> suspected as much
Jul 18 15:46:59 * kergoth thinks about including the package buildhistory data in the package sstate archive for the recipe
Jul 18 16:02:50 <rburton> walters: now gtk configure is moaning about old pango, so it looks like your patch is good enough to get configure running at least
Jul 18 16:04:24 * walters adds a tested-by and pushes
Jul 18 16:12:54 <rburton> walters: thanks
Jul 18 16:13:06 <rburton> 0: gtk+3-3.2.3-r0 do_compile (pid 23721)
Jul 18 16:13:08 <rburton> hooray
Jul 18 16:14:21 <walters> related to gnome and m4...i'm still unhappy with the current trajectory of the @PYTHON@ approach, and think we should find a fix that works for all 3 cases without patching
Jul 18 16:15:02 <walters> the current @PYTHON@ thing is actually breaking my build system too, i have a hardcoded build path but want target
Jul 18 16:16:19 <rburton> huh
Jul 18 16:16:21 <rburton> | make[4]: Entering directory `/data/poky-master/tmp/work/i586-poky-linux/gtk+3-3.2.3-r0/gtk+-3.2.3/gtk'
Jul 18 16:16:21 <rburton> | /data/poky-master/tmp/work/i586-poky-linux/gtk+3-3.2.3-r0/image/usr/share/themes/Raleigh/gtk-3.0
Jul 18 16:16:21 <rburton> | /bin/bash: /data/poky-master/tmp/work/i586-poky-linux/gtk+3-3.2.3-r0/image/usr/share/themes/Raleigh/gtk-3.0: No such file or directory
Jul 18 16:16:39 <JaMa|Off> rburton: for that you need that patch from patchwork..
Jul 18 16:16:44 <rburton> JaMa|Off: result, thanks
Jul 18 16:16:49 <rburton> JaMa|Off: i forgot about that :)
Jul 18 16:29:45 <Daemon404> does anyone plan on maintaining the meta-x32 layer?
Jul 18 16:36:38 <RP> Daemon404: There are a couple of people who should be looking after it between them
Jul 18 16:36:51 <RP> Daemon404: I know there are some open bugs at the moment :(
Jul 18 16:39:03 <Daemon404> at least one url is completely invalid in it
Jul 18 16:39:09 <Daemon404> and itt fails to link against its own libc
Jul 18 16:39:15 * Daemon404 shrugs
Jul 18 17:11:14 <RP> Daemon404: Did you try HEAD~1 against denzil?
Jul 18 17:11:31 * RP believes that should work (and I did ask yesterday a denzil branch was created)
Jul 18 17:30:54 <khem> rburton: now yes whats up ?
Jul 18 17:31:12 <khem> rburton: when you pinged it was 4am here I just went to sleep then ;)
Jul 18 17:31:39 <khem> RP: what  are our qemu upgrade plans
Jul 18 17:32:02 <Daemon404> RP, it wouldnt work
Jul 18 17:32:05 <khem> RP: some crashes that I see with 0.15 and dont see with 1.x
Jul 18 17:32:10 <Daemon404> url is still busted in the layer itself
Jul 18 17:32:25 <Daemon404> (i had to manually track down the correct url myself)
Jul 18 17:32:29 <mranostay> khem: you are allowed to sleep?
Jul 18 17:32:39 <RP> khem: I need to get an answer about this. I didn't get a reply from my last email :(
Jul 18 17:32:47 <RP> khem: droping gl pass through is likely
Jul 18 17:33:52 <RP> Daemon404: please file a bug in the bugzilla, this needs to get fixed
Jul 18 17:34:02 <Daemon404> sure
Jul 18 17:34:05 <Daemon404> whats the url to it?
Jul 18 17:34:24 <Daemon404> https://bugzilla.yoctoproject.org/ ?
Jul 18 17:34:48 <RP> Daemon404: yes please
Jul 18 17:35:24 <khem> RP: cool ok
Jul 18 17:36:18 <khem> RP: I have got meta-java functioning idependent of meta-oe besides that 1 giflib dep
Jul 18 17:36:32 <khem> RP: I think we could add it to OE-Core whats your say ?
Jul 18 17:36:32 <RP> khem: great! :)
Jul 18 17:36:50 <RP> khem: I'd say we're starting to have a case for that
Jul 18 17:36:57 <khem> RP: I will eventually move kernel.bbclass out of way too
Jul 18 17:37:07 <khem> so meta-oe can overlay nicely on top of oe-core
Jul 18 17:37:20 <RP> khem: that would be good
Jul 18 17:37:30 <khem> I have figured out 2 differences
Jul 18 17:37:38 <khem> 1. is kernel_pr
Jul 18 17:37:45 <khem> 2. is uboot image generation
Jul 18 17:37:57 <khem> kernel pr will become a new class in meta-oe
Jul 18 17:38:19 <khem> uboot image generation will be added as optional to oe-core
Jul 18 17:38:26 <khem> which can be turned on with a var
Jul 18 17:38:49 <khem> that should resolve all conflicts we have and provide the functionality that consumers of meta-oe kernel bbclass need
Jul 18 17:39:17 <khem> I will also punt out some more classes like blacklist from meta-oe
Jul 18 17:39:32 <khem> s/will/wiil have to
Jul 18 17:39:35 <RP> khem: sounds good
Jul 18 17:40:20 <khem> RP: I have a strange case two recipes both RPROVIDE_${PN} = "foo"
Jul 18 17:40:44 <khem> and then I do PREFERRED_PROVIDER_foo = "recipeA"
Jul 18 17:41:00 <khem> but bb still whines about multiple providers
Jul 18 17:41:10 <khem> any hints
Jul 18 17:41:18 <kergoth> prefered provider uses recipes, not packages
Jul 18 17:41:19 <khem> I looked into task dep dot files
Jul 18 17:41:31 <khem> kergoth: hmmm
Jul 18 17:41:32 <kergoth> PREFERRED_PROVIDER_somerecipe = "somerecipe" will do it
Jul 18 17:41:38 <kergoth> there's no PREFERRED_RPROVIDER, sadly
Jul 18 17:41:47 <bluelightning> khem: then we have a bunch of overlayed and bbappended recipes which still need to be cleaned up
Jul 18 17:41:48 <khem> thats what I thought
Jul 18 17:41:54 <bluelightning> khem: (in meta-oe)
Jul 18 17:41:55 <kergoth> it implicitly relies on the build time preferences
Jul 18 17:42:11 <khem> bluelightning: yes, thats true, one hack at a time :)
Jul 18 17:42:31 <bluelightning> khem: indeed, great progress has been made already
Jul 18 17:42:32 <khem> kergoth: it means somehow both recipes are being pulled in
Jul 18 17:42:40 <khem> so I have to curb the depchain
Jul 18 17:42:47 <khem> so that one of them is excluded
Jul 18 17:43:04 <kergoth> that's not necessarily what's happening, at least according to the message you talked about above
Jul 18 17:43:07 <bluelightning> bbl
Jul 18 17:43:32 <khem> kergoth: NOTE: multiple providers are available for runtime java2-runtime (jamvm, openjdk-6-jre)
Jul 18 17:43:35 <khem> NOTE: consider defining a PREFERRED_PROVIDER entry to match java2-runtime
Jul 18 17:43:58 <khem> java2-runtime is RPROVIDED by jamvm and openjdk-6-jre
Jul 18 17:44:44 <khem> in my local.conf I have PREFERRED_PROVIDER_java2-runtime = "openjdk-6-jre"
Jul 18 17:44:52 <khem> but as u said this wont work
Jul 18 17:45:10 <Daemon404> RP, ill try updating the url and using denzil instead of git master
Jul 18 17:45:15 <Daemon404> and see how it goes.
Jul 18 17:46:08 <khem> kergoth: now that you are here, can you also share your experience of using repo
Jul 18 17:46:27 <khem> kergoth: how do you use it and any recommendations ?
Jul 18 18:39:19 <rburton> khem: whatever i wanted you for, i've forgotten :)
Jul 18 18:41:05 <hollisb> kergoth: I have POKYMODE = "external-csl-toolchain" in my local.conf. I also specified a bad path for EXTERNAL_TOOLCHAIN, but yocto built anyways without error
Jul 18 18:41:21 <hollisb> kergoth: how can I tell what happened, i.e. what toolchain was actually used?
Jul 18 18:44:47 <kergoth> i have no idea what 'pokymode' even is
Jul 18 18:45:03 <kergoth> remant of old versions i'm sure
Jul 18 18:45:08 <kergoth> current master doesnt' use that at all
Jul 18 18:45:10 <kergoth> set TCMODE to external-sourcery-toolchain
Jul 18 18:45:13 <kergoth> erm
Jul 18 18:45:16 <kergoth> TCMODE to external-sourcery
Jul 18 18:46:22 <hollisb> ah! thanks :)
Jul 18 19:58:26 <Daemon404> the kernel.org mirror for denzil throws a 404
Jul 18 19:58:56 * mranostay catchs the 404
Jul 18 19:59:19 <Daemon404> can you catch what isnt there?
Jul 18 19:59:25 <Daemon404> this seems to be a philosophical question
Jul 18 20:13:06 <Daemon404> hummm, does denzil require a specific python version?
Jul 18 20:13:59 <bluelightning> Daemon404: 2.6+, but that's no different from previous versions
Jul 18 20:14:14 <Daemon404> im on 2.7
Jul 18 20:14:20 <Daemon404> and bitbake just dumps a stack trace
Jul 18 20:14:31 <bluelightning> Daemon404: can you pastebin it?
Jul 18 20:15:33 <Daemon404> http://pastebin.com/FdxDzXdv
Jul 18 20:16:22 <bluelightning> why would os.unsetenv return EINVAL?
Jul 18 20:16:26 <bluelightning> strange
Jul 18 20:16:34 <Daemon404> i have no idea.
Jul 18 20:16:42 <Daemon404> im on ubuntu 12.04 lts if it matters
Jul 18 20:16:49 <bluelightning> so am I here
Jul 18 20:17:08 <bluelightning> hmm, apparently unsetenv can return EINVAL if the name supplied to it contains an =
Jul 18 20:20:46 <bluelightning> looking at the code now...
Jul 18 20:21:30 <bluelightning> Daemon404: can you please pastebin the output of "env" ?
Jul 18 20:21:59 <Daemon404> just checked
Jul 18 20:22:09 <Daemon404> DBUS_SESSION_BUS_ADDRESS and PERL_MM_OPT have = in them
Jul 18 20:22:17 <Daemon404> PERL_MM_OPT=INSTALL_BASE=/home/derekb/perl5
Jul 18 20:22:21 <Daemon404> ^ as so
Jul 18 20:22:59 <Daemon404> unsetting them does not fix it.
Jul 18 20:24:05 <bluelightning> Daemon404: if you run python, import os, then print os.environ.keys()  - what do you get?
Jul 18 20:24:27 <bluelightning> we use that function to get the values we pass to os.unsetenv
Jul 18 20:25:07 <Daemon404> well it runs under env -i
Jul 18 20:25:12 <Daemon404> so it's deifnitely an env issue
Jul 18 20:26:23 <Daemon404> http://pastebin.com/1CNwnEBs
Jul 18 20:26:24 <Daemon404> my env
Jul 18 20:26:58 <bluelightning> what's that = at line 13?
Jul 18 20:27:06 <Daemon404> i have not a clue
Jul 18 20:27:09 <Daemon404> and cant figure out how to unset it
Jul 18 20:27:16 <bluelightning> I would bet that's the culprit...
Jul 18 20:27:20 <Daemon404> likely
Jul 18 20:28:42 <bluelightning> well os.unsetenv doesn't like a blank environment variable name either so that's definitely it
Jul 18 20:30:36 <Daemon404> indeed
Jul 18 20:34:39 <bluelightning> Daemon404: well, I'm puzzled as to how you ended up in that situation...
Jul 18 20:34:53 <bluelightning> google doesn't have any advice
Jul 18 20:34:56 <Daemon404> yeah i dont know
Jul 18 20:35:00 <Daemon404> this terms been open for a week
Jul 18 20:36:32 <bluelightning> Daemon404: if you log out and back in is it still there?
Jul 18 20:36:42 <Daemon404> i will try this later
Jul 18 20:36:47 <Daemon404> once build is done
Jul 18 20:39:58 <Daemon404> configure: error: cannot compute suffix of object files: cannot compile
Jul 18 20:40:04 <Daemon404> well that's a new one.
Jul 18 20:40:07 * Daemon404 probes
Jul 18 20:52:26 <hollisb> kergoth: trying TCMODE = external-sourcery yields http://fpaste.org/JFzO/
Jul 18 20:52:53 <hollisb> looks like a conflict with the eglibc recipe, though I haven't explicitly chosen that anywhere
Jul 18 20:59:58 <hollisb> AFAICS my only TCLIBC choices are eglibc or uclibc
Jul 18 21:00:39 <hollisb> so if eglibc conflicts with tcmod-external-sourcery.bb, TCMODE=external-sourcery just won't work
Jul 18 21:01:15 <kergoth> working on that exact issue as we speak
Jul 18 21:01:21 <hollisb> oh! :)
Jul 18 21:01:33 <kergoth> if you add meta-mentor, it should bypass it, even if you don't change DISTRO, but i can't figure out why it changes the behavior
Jul 18 21:01:53 <hollisb> hmm ok
Jul 18 21:02:42 <kergoth> looks like its related to our image/kernel class changes
Jul 18 21:02:53 <kergoth> in particular, the use of module-init-tools-cross rather than kmod-native
Jul 18 21:04:37 <kergoth> oh, i see. if i update those classes to the current oe-core versions, even with the kmod/m-i-t-c changes applied, then we hit the same issue
Jul 18 21:04:44 <kergoth> so must be related to recent image/kernel bbclass changes
Jul 18 21:06:14 * kergoth digs
Jul 18 21:06:24 <kergoth> that explains why you only get those messages when you try to build an image
Jul 18 21:06:31 <kergoth> if you bitbake task-core-base, you don't see them
Jul 18 21:08:12 <kergoth> it's the inherit of populate_sdk_base. adding that inherit results in eglibc being sucked into the build of the image.
Jul 18 21:16:13 <kergoth> toolchain-scripts.bbclass pulls in ${TCLIBC} explicitly rather than virtual/libc.
Jul 18 21:19:33 <kergoth> hollisb: line 139 of toolchain-scripts.bbclass, s/\${TCLIBC}/virtual\/libc/
Jul 18 21:19:40 <kergoth> hollisb: that should fix it. does here.
Jul 18 21:19:42 <hollisb> looking
Jul 18 21:20:00 <kergoth> though i've never tried using a PROVIDES entry in a depends flag before
Jul 18 21:20:03 <kergoth> doesn't explode
Jul 18 21:23:10 <hollisb> kergoth: since I just switched toolchains, I'll have a while before I get my complete image, but it's looking good so far
Jul 18 21:23:20 * kergoth nods
Jul 18 21:23:51 <hollisb> well, except for "ERROR: Function failed: do_install (see /mnt/poky.git/panda/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/external-sourcery-toolchain-Preview-r7/temp/log.do_install.16921 for further information)", but I expect that's a different problem
Jul 18 21:25:22 <hollisb> recipe expects my toolchain contains a /etc, and it doesn't
Jul 18 21:25:57 <kergoth> heh, easy enough to work around, make it only grab it if it exists
Jul 18 21:28:33 <hollisb> kergoth: remind me how to find the recipe that generates this package (external-sourcery-toolchain-Preview-r7)?
Jul 18 21:29:01 <kergoth> 'find'?
Jul 18 21:29:22 <kergoth> or ack -g, or git ls-files, or any number of other trivial methods
Jul 18 21:29:29 <kergoth> oe-core/meta/recipes-core/meta/external-sourcery-toolchain.bb
Jul 18 21:30:39 <hollisb> oh ok. I could see the "Preview" part of the package name was generated, so I wasn't sure how much of the package name was in the recipe file name
Jul 18 21:33:10 <kergoth> that wasn't part of the package name.
Jul 18 21:33:18 <kergoth> that directory is ${PN}-${PV}-${PR}
Jul 18 21:33:37 <kergoth> 'Preview' is what gcc --version is emitting
Jul 18 21:34:12 <hollisb> ok
Jul 18 21:34:51 <kergoth> also, that wasn't the 'package name'
Jul 18 21:35:01 <kergoth> all dirs in workdir are recipe name, version, revision
Jul 18 21:35:05 * kergoth gets food
Jul 18 21:42:49 <Daemon404> ERROR: Function failed: Fetcher failure for URL: 'git://git.kernel.org/pub/scm/devel/gdb/hjl/x86.git;protocol=git;branch=hjl/x32'. Unable to fetch URL from any source.
Jul 18 21:42:52 <Daemon404> ah there it goes.
Jul 18 22:43:00 <Daemon404> | /home/derekb/p/poky-denzil-7.0/build/tmp/sysroots/x86_64-linux/usr/libexec/x86_64_x32-poky-linux-gnux32/gcc/x86_64-poky-linux-gnux32/4.6.4/ld: skipping incompatible /home/derekb/p/poky-denzil-7.0/build/tmp/sysroots/qemux86-64/usr/libx32/libc.so when searching for -lc
Jul 18 22:43:05 <Daemon404> ^ where i died last time
Jul 18 22:43:07 <Daemon404> no idea how to fix it
Jul 18 22:43:10 <Daemon404> | /home/derekb/p/poky-denzil-7.0/build/tmp/sysroots/x86_64-linux/usr/libexec/x86_64_x32-poky-linux-gnux32/gcc/x86_64-poky-linux-gnux32/4.6.4/ld: skipping incompatible /home/derekb/p/poky-denzil-7.0/build/tmp/sysroots/qemux86-64/usr/libx32/libc.a when searching for -lc
Jul 18 22:43:14 <Daemon404> | /home/derekb/p/poky-denzil-7.0/build/tmp/sysroots/x86_64-linux/usr/libexec/x86_64_x32-poky-linux-gnux32/gcc/x86_64-poky-linux-gnux32/4.6.4/ld: cannot find -lc
Jul 18 22:58:06 <ant__> zeddii: around?
Jul 18 23:00:15 <hollisb> kergoth: I'm getting "No GNU_HASH" errors now too. following the recent thread on yocto@, why is INSANE_SKIP needed? is this a recipe bug that happens to be exposed by the external toolchain?
Jul 18 23:00:59 <kergoth> hollisb: the oe internally built toolchain is configured to set the gnu hash bits the way yocto wants them
Jul 18 23:01:02 <kergoth> this isn't always the case for external
Jul 18 23:01:14 <kergoth> this is why we override WARN_QA and ERROR_QA in mel.conf to make that error a warning
Jul 18 23:01:24 <kergoth> ideally we'd have a better solution to this
Jul 18 23:01:32 <kergoth> i'd be interested in any thoughts on the subject
Jul 18 23:01:43 <hollisb> can it be overridden in external-sourcery-toolchain ?
Jul 18 23:02:16 <kergoth> those variables are distro policy, not a function of the toolchain, though i could see filtering out ldflags specficically in a anonymous python function or something
Jul 18 23:03:06 <kergoth> hollisb: if the upstream buildsystem obeys our LDFLAGS, its also a nonissue, as iirc we pass it explicitly in there, so its just the buildsystems that don't that can see the issue. those should probably be fixed, rather than sidestepped by changing the toolchain defaults
Jul 18 23:03:11 <kergoth> but /me shrugs
Jul 18 23:03:49 <hollisb> IOW, INSANE_SKIP should go into the perl recipe until such time as it obeys our LDFLAGS?
Jul 18 23:05:02 <kergoth> perhaps, but it may be nontrivial due to the programmatically generated packages
Jul 18 23:08:19 <kergoth> hollisb: testing code to adjust the ldflags in *_QA in the tcmode now
Jul 18 23:08:23 <kergoth> heh
Jul 18 23:08:28 <hollisb> :)
Jul 18 23:12:24 <kergoth> perl's a good one to test, had forgotten about that
Jul 18 23:13:29 <kergoth> hollisb: we're using https://github.com/MentorEmbedded/meta-sourcery at mentor now, rather than the upstream versions, due to the -te500v2, etc sourcery arguments that need to be passed. course this means now i have to keep them mostly in sync..
Jul 18 23:13:31 * kergoth rolls eyes
Jul 18 23:15:03 <hollisb> doesn't -te500v2 need to be used in vanilla Yocto too when using CodeBench?
Jul 18 23:15:29 <kergoth> it does, but it's tough to make that happen in a way that won't break things for everyone else
Jul 18 23:15:40 <kergoth> would have to hardcode it in the tcmode, overriding the tune files or so
Jul 18 23:15:50 <kergoth> i'm thinking it might be time to just move the sourcery bits out of oe-core entirely
Jul 18 23:16:01 <hollisb> the tweak can't be done in external-sourcery-toolchain?
Jul 18 23:16:01 <kergoth> thats what the windriver folks do, they have a separate toolchain layer
Jul 18 23:16:06 <hollisb> huh
Jul 18 23:16:10 <kergoth> [16:15:39] <kergoth> would have to hardcode it in the tcmode, overriding the tune files or so
Jul 18 23:16:29 <kergoth> doable, but not ideal, reeks of a hack
Jul 18 23:16:54 <kergoth> i'd thought we could avoid it, but the problem is the argument doesn't just select the libc sysroot, it also selects which multilib versions of the gcc libs are used
Jul 18 23:16:58 <kergoth> and those don't get pulled into the oe sysroot
Jul 18 23:17:12 <kergoth> so you can get e.g. hard float vs soft float mismatches if you pass the component arguments but not the main one
Jul 18 23:17:19 <kergoth> afaict anyway
Jul 18 23:17:27 <kergoth> so we're stuck passing them
Jul 18 23:17:52 <hollisb> maybe I'm misunderstanding, but those -t options are already handled in meta/conf/distro/include/tcmode-external-sourcery.inc
Jul 18 23:18:03 <kergoth> no, they're only passed when extracting hte sysroot path
Jul 18 23:18:08 <kergoth> not when building
Jul 18 23:18:11 <hollisb> oh
Jul 18 23:18:18 <kergoth> so its isolated right now
Jul 18 23:18:35 <kergoth> still not pretty, but more so than overriding the tunes :\
Jul 18 23:19:16 <kergoth> https://github.com/MentorEmbedded/meta-sourcery/blob/master/conf/machine/include/tune-ppce500v2.inc#L6
Jul 18 23:21:19 <hollisb> I guess it's not too inconvenient to say "if you want to build with CodeBench, use meta-mentor." the trick will be how people find out about that requirement
Jul 18 23:22:05 <hollisb> oh, meta-sourcery is something separate? hrmmm...
Jul 18 23:30:59 <hollisb> makes sense, but right now using meta-sourcery gets me "cannot find crt1.o: No such file or directory" the very first time gcc is invoked :(
Jul 18 23:38:16 <kergoth> hollisb: yeah, i dont intend for people using codebench to have to use meta-mentor. that shouldn't and won't be the case.
Jul 18 23:38:25 <kergoth> dunno, i have upstream builds with meta-sourcery going right now
Jul 18 23:38:26 * kergoth shrugs
Jul 18 23:38:41 <kergoth> using it to test the perl/ldflags workaround
Jul 18 23:56:55 <kergoth> hollisb: about to push a workaround for the ldflags thing to meta-sourcery
Jul 18 23:57:06 <kergoth> (that is, the gnu_hash error)
Jul 18 23:58:27 <hollisb> kergoth: nice. so since meta-sourcery exists (I didn't know about it before), I guess you're right that it doesn't make sense to also have external-sourcery-toolchain.bb
Jul 18 23:58:37 <hollisb> especially since the latter doesn't work anyways...
Jul 18 23:58:55 <kergoth> the main thing i see it as useful for in oe-core, even in a non-perfect state, is as a starting point for folks who want to support their own toolchains
Jul 18 23:59:05 <kergoth> but the seperate layer could do that too if stuff points at it
Jul 18 23:59:10 <hollisb> yup
Jul 18 23:59:21 <kergoth> in particular the yocto documentation, if it was a layer on yoctoproject.org
Jul 18 23:59:27 <kergoth> i haven't had a chance to email the list to talk about it
Jul 18 23:59:37 <kergoth> just punted and created the layer to keep us moving internally
Jul 18 23:59:37 <kergoth> heh
Jul 18 23:59:41 * kergoth adds to todo
Jul 19 00:00:38 <hollisb> yeah, no shortage of issues
Jul 19 00:00:54 <kergoth> fyi, discovered it only takes some slight tweaks to get this tcmode and recipe to work with crosstool-ng built toolchains
Jul 19 00:00:59 <kergoth> need to sit down and create a tcmode for that..
Jul 19 00:01:00 <kergoth> heh
Jul 19 00:01:55 * kergoth mutters and wanders off
Jul 19 01:53:31 <kergoth> otavio: ooh, i didn't know about the sync-j option in the manifest. <3
**** ENDING LOGGING AT Thu Jul 19 02:59:58 2012

**** BEGIN LOGGING AT Thu Jul 19 02:59:59 2012
Jul 19 03:13:59 <nitink> Good Morning !
Jul 19 05:57:59 <khem> how often is http://downloads.yoctoproject.org/mirror/sources/ updated
Jul 19 05:58:18 <khem> new gcc-git tars are not there
Jul 19 05:58:36 <khem> can someone put it up there
Jul 19 05:58:43 <khem> cloning git is painful
Jul 19 06:09:41 <ynezz> wget http://gcc.gnu.org/git/?p=gcc.git;a=snapshot;h=7df951489618b262d1669a606fda43ea5f5b4585;sf=tgz
Jul 19 06:11:28 <khem> ynezz: I have tree local for that matter thanks
Jul 19 06:12:07 <ynezz> ah, now I understand what do you mean
Jul 19 09:21:51 <bluelightning> morning all
Jul 19 09:54:17 <Orre> morning bluelightning!
Jul 19 09:54:49 <bluelightning> hi Orre
Jul 19 11:06:42 <Orre> If using the OE-core toolchain external-sourcery-toolchain.bb it tries to cp /etc/./<PACKAGES> which doesn't exist and therefor throws error as permission denied. What's the suggested way to solve this?
Jul 19 11:33:29 <RP> Orre: did you set the location of the external toolchain?
Jul 19 11:35:43 <Orre> RP: Yes, but I'm not fully sure which external toolchain I should use?
Jul 19 11:36:59 <Orre> RP: Tried to use our custom toolchain currently, but if there is one that's standard to use with external-sourcery I would be ecstatic if I get to know where I can get it!
Jul 19 11:37:26 <RP> Orre: somewhere on the codesourcery website?
Jul 19 11:38:11 <Orre> RP: I tried to download the one they provided but it didn't work. So have tried to figure out which versions of the ones on Codesourcery website you support?
Jul 19 11:38:30 <RP> Orre: someone like kergoth would probably have a better idea
Jul 19 11:39:19 <Orre> RP: He is only online when I'm asleep though, so sadly I'm only able to read his discussions when I wake up the next morning - not actually able to have an discussion with him.
Jul 19 11:40:26 <RP> Orre: I can only really suggest asking on the mailing list then. I don't know the answers to your questions and have not used an external csl toolchain in a long time
Jul 19 11:40:40 <RP> (about 2007 iirc)
Jul 19 11:41:27 <Orre> RP: Have you used any external toolchain recently which I could attempt to use? I read one post on the mailing list that I should be able to use the meta-toolchain, though bluelightning has stated it can't be used that way.
Jul 19 11:42:48 <Orre> It would be appreciated if someone prioritised to give some documentation how to use your own external toolchain during the next few months - seems to be some people asking about it every night.
Jul 19 11:43:44 <Orre> Currently only the TCMODE and a pre-edison 6.0 documentation of what files to look on which exists.
Jul 19 11:43:48 <Orre> Which isn't enough.
Jul 19 11:44:23 <Orre>  :(
Jul 19 11:47:42 <RP> Orre: I don't have anything precanned I can give you doc wise but I've been asked to write some docs and will try and do so soon
Jul 19 11:48:11 <Orre> RP: Thanks a lot! Appreciated!
Jul 19 13:04:48 <otavio> kergoth: yaeh it helps a lot during the checkout
Jul 19 14:34:36 <kergoth> Orre: 'external-sourcery' is intended for use with the sourcery g++ toolchain from mentor graphics (formerly from codesourcery). tweaking will almost certainly be needed to use it with anything else
Jul 19 14:35:12 <kergoth> otavio: yeah, especially when using av ery large number of repositories.. heh
Jul 19 14:36:31 <khem> bitbake -cfetchall isnt working as expected for me, only the prerequisites it needs to build gets downloaded
Jul 19 14:36:39 <khem> and everything else just completes
Jul 19 14:36:46 <khem> without downloading
Jul 19 14:36:52 <khem> anyone seen it,
Jul 19 14:36:58 <JaMa> yup there are still some issues with runqueue..
Jul 19 14:37:14 <kergoth> it used to work fine, but i haven't tested it since richard's changes to the recr flags
Jul 19 14:37:17 <kergoth> :\
Jul 19 14:37:27 <khem> hmm
Jul 19 14:37:33 <JaMa> for me it was even like this: bitbake -c cleansstate virtual/kernel; bitbake virtual/kernel -> and nothing was built, it said that no task was needed
Jul 19 14:37:35 <khem> bitbake is this sand castle
Jul 19 14:37:43 <kergoth> for i in $(find . -name \*.bb); do bitbake -b $i -c fetch; done ?
Jul 19 14:37:45 <kergoth> heh
Jul 19 14:38:01 <kergoth> i'm still very tempted to try a rewrite, but lack sufficient motivation
Jul 19 14:38:45 <khem> kergoth: its possible but we dont have much specs for bitbake and bb language
Jul 19 14:38:54 <khem> so it will be a long journey
Jul 19 14:39:22 <kergoth> there are all these implicit dependencies in the metadata on bitbake behavior :|
Jul 19 14:39:49 <khem> exactly
Jul 19 14:40:29 <khem> JaMa: so how did you fix that ?
Jul 19 14:41:19 <kergoth> i'd like to see us start moving in a direciton where recipes don't add tasks, or even set controlling flags unless absolutely necessary. define variables, inherit classes, define core functions. make sure none try to change *how* bitbake behaves in any way. it'd be a start..
Jul 19 14:41:21 <JaMa> khem: cleaned and built right kernel recipe with -b :/
Jul 19 14:41:40 <khem> are these issues reported ?
Jul 19 14:42:27 * kergoth ponders
Jul 19 14:43:45 <kergoth> does anyone else think bumping bitbake's version a tiny 'micro' number for a change which breaks parse compatibility with layers was a bit.. not ideal?
Jul 19 14:43:54 <kergoth> i'd think a compat change would at least require a minor version bump
Jul 19 14:43:54 <JaMa> khem: not by me.. I've reported it with normal images and it was fixed immediately after that by RP.. with virtual/kernel I wanted to debug why it behaves diffferent
Jul 19 14:44:05 <JaMa> khem: but other issues take all my time..
Jul 19 14:44:07 <kergoth> RP: see above
Jul 19 14:44:50 <RP> kergoth: I guess. I'm a bit confused over what our version numbers mean now :/
Jul 19 14:44:55 * kergoth too
Jul 19 14:45:07 <JaMa> kergoth: as long as oe-core forces you to upgrade this tiny micro number, then it's ok, but I see your point
Jul 19 14:45:12 <kergoth> need to sit down and document a policy
Jul 19 14:45:21 <kergoth> JaMa: true
Jul 19 14:46:06 * kergoth shrugs
Jul 19 14:47:23 <RP> kergoth: I was torn when I made the change earlier. The more important thing is we did do something with the number I guess...
Jul 19 14:47:38 <kergoth> yeah, not a big deal, but something to think about for the future
Jul 19 14:48:01 <kergoth> i'm thinking in terms of like a library.. when you break abi/api compat its time to bump the minor/major version, largely because those are in the soname usually, but still..
Jul 19 14:48:12 <kergoth> heh
Jul 19 14:53:05 <khem> RP: fetchall does not work as expected now
Jul 19 14:53:30 <RP> khem: in what way?
Jul 19 14:53:32 <khem> RP: have you seen this issue
Jul 19 14:53:53 <khem> RP: it fetches only the recipes its building
Jul 19 14:54:11 <khem> RP: so the prerequisites are fetched but nothing else
Jul 19 14:54:25 <khem> if I build some image then it fetches the remaining tats
Jul 19 14:54:27 <khem> tars
Jul 19 14:54:41 <RP> khem: file a bug explaining that please
Jul 19 14:54:44 <khem> that was with no sstate mirror no dl mirror
Jul 19 14:54:51 <RP> khem: I'm not aware of their being issues
Jul 19 14:55:23 <khem> it worked fine couple of weeks back
Jul 19 14:55:29 <khem> so something recent broke it
Jul 19 14:57:03 <RP> khem: there were changes in bitbake in that area
Jul 19 14:58:24 <khem> yes runqueue related, I filed a bug
Jul 19 14:59:14 <kergoth> RP: you happen to know if there's an issue for the '0 of 0' setscene task count in knotty, offhand?
Jul 19 14:59:23 <kergoth> a bug open, that is
Jul 19 14:59:30 * kergoth wasn't quite sure what to search for
Jul 19 15:01:02 <RP> kergoth: there is a patch on the list from Jason for it
Jul 19 15:01:16 <RP> kergoth: I've not merged it as its tangled in a lot of other stuff I've not got to :(
Jul 19 15:01:29 <kergoth> ahh, k
Jul 19 15:01:36 <kergoth> np, just a minor thing
Jul 19 15:01:42 <kergoth> just wanted to make sure it was on the radar
Jul 19 15:02:29 <RP> khem: was that with the latest bitbake?
Jul 19 15:24:26 <JaMa> khem: btw.. gcc builds seem failing even more now with git SRC_URI :/
Jul 19 15:26:02 <JaMa> khem: seems like paralel do_unpack to work-shared (e.g. just now from gcc-crosssdk-intermediate_4.7.bb when gcc-crosssdk-initial_4.7.bb was already in do_compile
Jul 19 15:26:38 <JaMa> khem: log http://pastebin.com/7tJyWnZi
Jul 19 15:47:53 <JaMa> hmm fetcher doesn't check checksums again? I have recipe without checksums and it fetch + unpack it fine
Jul 19 15:52:04 <bluelightning> JaMa: does .done already exist?
Jul 19 15:52:34 <JaMa> no it was new recipe version
Jul 19 15:52:41 <JaMa> so downloaded for first time
Jul 19 15:52:44 <bluelightning> not sure then, it should...
Jul 19 15:53:07 <JaMa> that could be caused by white space shufle..
Jul 19 15:53:54 <kergoth> unlikely
Jul 19 15:54:57 <JaMa> kergoth: it was working about 2 days ago
Jul 19 15:55:05 <kergoth> bisect
Jul 19 15:55:08 <kergoth> :)
Jul 19 15:55:08 <JaMa> kergoth: that's why I don't know what else could
Jul 19 15:55:17 <kergoth> git bisect is extremely helpful
Jul 19 15:55:30 <JaMa> hmm and now it failed
Jul 19 16:09:03 <sorvats> I am working with denzil. I have already managed to add a machine, build a distro image for it, and add a custom kernel recipe for my machine. In some cases, I would like my image to be included in my kernel as an initramfs
Jul 19 16:10:12 <sorvats> I am thinking about adding a new kernel recipe for this, which should depend on my original image, or something like that. Is there some kind of standard way of doing that?
Jul 19 16:10:39 <zenlinux_> anyone know of uclibc still uses SuS v3?
Jul 19 16:11:01 <zenlinux_> khem, ^^
Jul 19 16:11:35 <zenlinux_> s/of/if/
Jul 19 16:12:50 <msm> sgw: can you try a build with my patch disabled?
Jul 19 16:14:09 <sgw> msm, we have pidge did that yesterday.
Jul 19 16:14:19 <JaMa> bluelightning: now with required bitbake version bumped, can you apply http://patchwork.openembedded.org/patch/32087/ ?
Jul 19 16:14:21 <msm> sgw: and my patch is causing this issue?
Jul 19 16:14:50 <sgw> msm: apparently yes
Jul 19 16:15:56 <bluelightning> JaMa: sure
Jul 19 16:16:30 <msm> sgw: i don't see any connection
Jul 19 16:16:43 <msm> we are building a standalone dbconvert program vs. not building it
Jul 19 16:17:52 <msm> sgw: in fact
Jul 19 16:18:04 <msm> without my patch we still explicitly rm -rf the binary!
Jul 19 16:18:05 <msm> meta/recipes-devtools/rpm/rpm_5.4.9.bb: rm -f ${D}/${libdir}/rpm/dbconvert.sh
Jul 19 16:18:05 <msm> meta/recipes-devtools/rpm/rpm_5.4.9.bb: rm -f ${D}/${libdir}/rpm/bin/dbconvert
Jul 19 16:18:13 <msm> so if we build it or not it's deleted!
Jul 19 16:18:19 <sgw> msm: I know it seemed strange to me also, but unless it's hiding something else.
Jul 19 16:18:21 <bluelightning> JaMa: done
Jul 19 16:18:28 <msm> sgw: are you sure it's not corrupt sstate-cache or something?
Jul 19 16:18:35 <sgw> msm, let me try again here in the background.
Jul 19 16:18:39 <msm> sgw: some back packaging of rpm or a depedency
Jul 19 16:18:46 <sgw> No we started a build from scratch
Jul 19 16:18:46 <msm> on the autobuilder systems
Jul 19 16:19:00 <msm> sgw: with and without the patch?
Jul 19 16:19:51 <sgw> yes, I am going try again and see what happens, back with you in an hour or so, I am also at a confernce.
Jul 19 16:21:07 <JaMa> bluelightning: thanks
Jul 19 17:08:16 <AdityaGandhi> Hi is anyone there?
Jul 19 17:10:59 <mranostay> nope
Jul 19 17:11:00 <seebs> No.
Jul 19 17:11:13 <AdityaGandhi> Lol, I modifed a kernel config
Jul 19 17:11:23 <seebs> (IRC FAQ: Never ask whether people are around. Ask your question, and stay logged in in case it's hours before someone notices and responds.)
Jul 19 17:11:30 <AdityaGandhi> I need to rebuild only the kernel, could you help
Jul 19 17:12:07 <AdityaGandhi> I used bitbake -c menuconfig linux-yocto to modify the cnfig
Jul 19 17:47:59 <Aditya> Hi, can you redirect me to a guide where I can modify the kernel for a bsp package (Crownbay), and add patches
Jul 19 20:36:38 <ant__> zeddii: still @work?
Jul 19 23:16:03 <Desert> so i've been watching the yocto vimeo videos, you convinced me, seems yocto is far easier than openembedded
Jul 19 23:16:55 <Desert> i have a few questions, can i create a beagleboard image with DSP acceleration  and recent kernel? is there an easy way?
Jul 19 23:17:19 <Desert> and can i include opencv and other libs into the rootfs but also into the toolchain and SDK ?
Jul 19 23:47:37 <khem> RP: whats out story on udev update
Jul 19 23:47:44 <khem> we still are at 164
Jul 19 23:47:50 <khem> in OE-Core
Jul 19 23:47:59 <khem> people are asking for newer features
Jul 19 23:50:06 <bluelightning> khem: alexandru sent a patch just the other day to update it...
Jul 19 23:50:43 <khem> bluelightning: ah cool
Jul 19 23:50:50 <khem> I am behind on ml
Jul 19 23:51:07 <khem> bluelightning: do you have pw url handy
Jul 19 23:51:12 <khem> and which version is it
Jul 19 23:52:26 <bluelightning> khem: 182
Jul 19 23:52:28 <bluelightning> khem: http://patchwork.openembedded.org/patch/32241/
Jul 19 23:52:44 <khem> bluelightning: thanks
Jul 19 23:55:09 <khem> it has some feedback
Jul 19 23:55:16 <khem> and I have some too
Jul 19 23:55:21 <khem> so I will reply as well
**** ENDING LOGGING AT Fri Jul 20 02:59:59 2012

**** BEGIN LOGGING AT Fri Jul 20 02:59:59 2012
Jul 20 03:01:36 <nitink> Good Morning !
Jul 20 04:11:30 <msm> sgw: any update on that createrepo issue?
Jul 20 04:51:18 <sgw> msm: no, very frustrating, we can't reproduce it, we think it might be sstate related now, but I need to wait for the current build to finish so I can test directly on that machine.
Jul 20 05:08:18 <msm> sgw: weird...
Jul 20 05:30:37 <Prowell> is the yocto project old enough to have ever done anything with the 2.4 kernel?
Jul 20 05:37:16 <nitink> Prowell: not that old
Jul 20 05:43:20 <Prowell> oh, well.  Was hoping for an easy migration path for some old stuff that really needs ported up to 2.6, but has a fairly large program tied way to tightly with the old kernel.
Jul 20 05:46:42 <nitink> prowell: yoctoproject also has moved on to 3.x now
Jul 20 05:48:00 <Prowell> I saw, from what I've seen 2.6 and 3.0 aren't that different from a device driver stand-point.
Jul 20 05:48:10 <nitink> Prowell: sooner or later that program will need moving to new kernel
Jul 20 05:48:49 <nitink> Prowell: we still have v3.0 kernel recipes in the tree
Jul 20 09:27:39 <ohmi> Hi, I've generated a core-image-cdv-media-sdk-cedartrail image, put this image on an usb key. When booting I receive the message No DEFAULT ou UI configuration directive found! Can anyone help. thanks
Jul 20 10:28:32 <nitink> ohmi: I never saw such kind of message yet
Jul 20 11:29:49 <ant_work> bluelightning: about hard times with Kconfig...heh, Linus in person says "And it's
Jul 20 11:29:49 <ant_work> really hard to figure out - even for somebody like me - what a minimal
Jul 20 11:29:49 <ant_work>  usable kernel is.
Jul 20 11:29:49 <ant_work> "
Jul 20 11:30:01 <bluelightning> heh
Jul 20 11:30:31 <ant_work> here if you missed that  https://lists.yoctoproject.org/pipermail/linux-yocto/2012-July/000022.html
Jul 20 14:19:02 <shoragan> which udev is one supposed to use when combining yocto denzil with meta-oe?
Jul 20 14:19:22 <shoragan> it seems neither 164 nor 182 works right
Jul 20 15:25:24 <blloyd_> I'm curious: is there an easy way to get the list of sources used to produce a distribution?  What's the easy way to meet the GPL source redistribution requirement when using yocto?
Jul 20 15:55:28 <seebs> Hey, uhm.
Jul 20 15:55:40 <seebs> This is gonna end badly, I know, but... I have a question about pseudo.
Jul 20 15:56:05 <seebs> Which is that some of our testers are reporting that pseudo fails to build for non-x86 targets. Which is true, it does.
Jul 20 15:56:27 <seebs> Hmm.
Jul 20 15:56:47 <seebs> You know, it may be simplest for me to make a pseudo 1.4 that is expected to at least compile for ARM/MIPS/etc.
Jul 20 16:03:47 <fray> I can't find an example of saying a recipe only works for a given set of architectures..
Jul 20 16:03:54 <fray> I see a COMPATIBLE_MACHINE and COMPATIBLE_HOST
Jul 20 16:03:58 <seebs> Okay, option #1: pseudo updated to build on a broader range of targets, by adding a --arch to its configure.
Jul 20 16:04:15 <seebs> Option #2: recipe fixed to be -native only, probably by renaming it to pseudo-native.bb.
Jul 20 16:04:34 <seebs> Option #3: Track down everyone shipping a non-x86 CPU and kill them. Problem goes away.
Jul 20 16:18:46 <msm> seebs: are you building from a non-x86 machine?
Jul 20 16:19:27 <seebs> No, but someone tried a bitbake world for an ARM target and pseudo failed because it tried to use -m32.
Jul 20 16:19:49 <seebs> I am currently planning to give pseudo's configure a --cflags= which trumps the x86ish defaults.
Jul 20 16:20:49 <msm> xcompile psuedo for arm basically?
Jul 20 16:21:54 <seebs> Yeah.
Jul 20 16:22:04 <seebs> And just in general, there's no reason pseudo shouldn't be able to run on other targets.
Jul 20 16:22:19 <seebs> I mean, sure, it'll probably get people to report new bugs, because I am pretty careless.
Jul 20 16:22:22 <seebs> But it SHOULD work.
Jul 20 16:22:54 <seebs> Ugh. I just realized I was looking at old pseudo, I already started to fix this.
Jul 20 16:22:58 <seebs> In a way which was stupid.
Jul 20 16:23:50 <RP__1> fray: COMPATIBLE_HOST is what you want
Jul 20 16:25:05 <RP__1> blloyd_: yes, there are various ways to do that and its one of the advantages of the project that we allow that kind of thing easily
Jul 20 16:26:52 <seebs> Fundamentally, pseudo should never have tried to set its own CFLAGS for architectures/bits. I have no idea what I was thinking.
Jul 20 16:27:16 <seebs> But clearly, I wrote it because I wanted it to do something. So it was user error. *nods wisely*
Jul 20 16:40:39 <seebs> Hmm.  This may not be as practical as I thought. I don't see a general mechanism for nativesdk stuff for extracting "what flags would I be using if this were a 32-bit build".
Jul 20 16:41:35 <seebs> Also, while I am at it: Is TUNE_CCARGS available for -native packages? I am looking for "the flags we are using for native builds". (Or do native builds always assume they don't need special flags?)
Jul 20 16:42:08 <seebs> The reason I ask is that in at least one case, I know that WR uses a compiler which defaults to 32 bit compilation for x86, and uses -m64 when using it on 64-bit hosts.
Jul 20 16:42:41 <kergoth> BUILD_CFLAGS is probably what you're looking for
Jul 20 16:42:53 <seebs> Sounds likely.
Jul 20 16:42:56 <seebs> Hmm.
Jul 20 16:43:19 <seebs> I am not sure I can fix this for the native build case for a hypothetical non-x86 host which is 64-bit but where we need a 32-bit version of libpseudo also.
Jul 20 16:45:44 <seebs> But I bet I can fix the target case. And then I can try to play with pseudo on the target and see whether it actually works. I'm told someone's been using it on ARM successfully.
Jul 20 16:54:40 <seebs> Huh.
Jul 20 16:54:58 <seebs> That's odd. I may be doing this wrong. Because my patch didn't apply, and looking at it, it seems that pseudo's not getting patched.
Jul 20 16:55:03 <seebs> So the symver.patch isn't applying either.
Jul 20 16:55:23 <seebs> Oh, wait. That's in -nativesdk only.
Jul 20 17:06:13 <seebs> Hmm.
Jul 20 17:06:31 <seebs> Is there a value that is BUILD_CFLAGS in -native and TUNE_CCARGS in target packages?
Jul 20 17:09:52 <kergoth> you mean like 'CFLAGS'?
Jul 20 17:10:03 <kergoth> erm, maybe thats not right
Jul 20 17:10:07 <kergoth> just check bitbake.conf
Jul 20 17:10:13 <kergoth> its trivial to follow the variable references
Jul 20 17:10:43 <seebs> It is a twisty maze of variable assignments, all different.  :P
Jul 20 17:11:41 <kergoth> not particularly. look at the ones which are exported, which you know flow into the builds, and track backward from there
Jul 20 17:11:48 <kergoth> e.g. CC, CFLAGS, LDFLAGS< ..
Jul 20 17:12:06 <seebs> Ahh, I see.  native.bbclass does CFLAGS=${BUILD_CFLAGS}
Jul 20 17:12:12 <kergoth> yep
Jul 20 17:12:36 <seebs> There we go. Okay, that is much more obvious than I thought it was.  :P
Jul 20 17:12:58 <kergoth> heh
Jul 20 17:13:19 <kergoth> more people need to take the time to read bitbake.conf and the core classes, it makes things much clearer :)
Jul 20 17:13:25 <seebs> Yeah.
Jul 20 17:14:47 <seebs> Okay, so here's one for you:  Does there exist a spelling for "the flags I would use for this build, except force a 32-bit build"?
Jul 20 17:17:50 <kergoth> ${whatever} -m32?
Jul 20 17:18:08 <kergoth> hehe
Jul 20 17:18:12 <kergoth> not really, i have no idea
Jul 20 17:22:55 <seebs> Problem is that there are architectures where -m32 is wrong.
Jul 20 17:23:23 <seebs> I think I'm just gonna write that off to "we will solve this when someone tries to run -nativesdk and -native packages on a non-x86 64-bit host with 32-bit binaries also present".
Jul 20 17:24:52 <seebs> So, while I'm talking about pseudo-related stuff: I did a couple of tests, and I think I am going to be adding a "use in-memory database" feature to pseudo.
Jul 20 17:25:16 <seebs> I did a test of "tar cpf - . | (cd elsewhere; tar xpf -)" under pseudo with files.db renamed to :memory:.
Jul 20 17:25:30 <seebs> On my laptop, it was 20 minutes with the pseudo database on disk, 5 minutes with it in memory.
Jul 20 17:25:37 <seebs> That is a large enough change for me to explore this.
Jul 20 17:51:45 <khem> RP__1: using sstate suppose I deleted the whole tmp dir and then rebuilt the image and everything comes from sstate, it does not populate the sysroot and directly generates the image. whats recommended practice here
Jul 20 17:52:03 <khem> sometimes the sysroot is needed for rebuilding some kernel mods
Jul 20 17:56:41 <kergoth> i'd say don't use the sysroot directly. build meta-toolchain or similar, or create a recipe for the kernel mods
Jul 20 17:56:45 * kergoth shrugs
Jul 20 17:58:10 <hollisb> I want to remove a single package (busybox-httpd) from an image. can I just filter IMAGE_INSTALL in my image.bb?
Jul 20 17:58:14 <bluelightning> yes, don't use the sysroot as a bogotoolchain
Jul 20 17:58:42 <kergoth> hollisb: most likely, yes
Jul 20 17:59:02 <hollisb> ok thanks
Jul 20 18:00:02 <seebs> The "sysroot is needed" thing is sort of why we are working on toolchain wrappers.
Jul 20 18:00:08 <seebs> Although that turned out to be harder than I thought.  :)
Jul 20 18:26:59 <khem> fray: any idea about these errors http://pastebin.com/TXzH12UE ?
Jul 20 18:28:57 <fray> looking
Jul 20 18:29:32 <fray> the ls bit is likely unrelated -- it's some kind of packaging thing, likely sstate?
Jul 20 18:30:04 <fray> the dependency one is interesting though. it's saying ther eis a hard requirement that isn't provided..  so something didn't provide (or no package name) of virtual-locale-en-gb, but libuser-locale-en-gb requried it
Jul 20 18:30:18 <khem> fray: yes its using sstate
Jul 20 18:30:21 <khem> but clean tmp
Jul 20 18:30:44 <khem> same stuff works ok for qemux86_64
Jul 20 18:30:47 <khem> same set of packages
Jul 20 18:30:53 <fray> I suspect you need a couple cleansstate calls.. and rebuild both libuser, dbus, kernel libacl1.. and whatever the virtual-locale-en-gb comes from
Jul 20 18:31:02 <fray> something went wrong during the buuild, and this is the fall out..
Jul 20 18:31:08 <fray> disk full?
Jul 20 18:31:40 <khem> no, but build died few times I fixed stuff continued etc.
Jul 20 18:31:48 <khem> lemme try that
Jul 20 18:33:24 <khem> bitbake -ccleansstate libuser dbus virtual/kernel eglibc attr
Jul 20 18:45:19 <khem> cleaning eglibc was not a good idea
Jul 20 18:45:28 <khem> its rebuilding quite a few bits now
Jul 20 18:45:33 <khem> lets see what I end up with
Jul 20 20:05:39 <seebs> Anyone want to have a look at a proposed pseudo change before I update pseudo to let it run on targets?
Jul 20 20:08:56 <khem> seebs: are patches on ml
Jul 20 20:09:02 <khem> I will take a look over
Jul 20 20:09:14 <seebs> Not yet, still doing some testing before I'm ready to submit them.
Jul 20 20:38:04 <hollisb> hmm... does configure --with-sysroot not do what I think it does? I'm using it, but it doesn't seem to be using my sysroot directory in any gcc invocations
Jul 20 20:38:23 <hollisb> and therefore gcc can't find the headers this project needs
Jul 20 21:04:21 <khem> hollisb: --with-sysroot seems like a autoconf option
Jul 20 21:04:31 <hollisb> yup
Jul 20 21:04:34 <khem> hollisb: I think what you are talking about is compiler option
Jul 20 21:04:40 <hollisb> actually no
Jul 20 21:04:50 <khem> so you are changing gcc build
Jul 20 21:04:53 <hollisb> I was trying to build a package (lighttpd) that uses autoconf
Jul 20 21:04:59 <khem> ok
Jul 20 21:05:17 <khem> you dont need sysroot there
Jul 20 21:05:18 <hollisb> and I wanted to say "build lighttpd but use this sysroot when testing for features (e.g. zlib)"
Jul 20 21:05:42 <hollisb> so configure --with-sysroot *seemed* right... but apparently isn't
Jul 20 21:06:02 <khem> well eventually --sysroot=<sysrootdir>
Jul 20 21:06:09 <khem> is what should be passed down to compiler
Jul 20 21:06:29 <hollisb> yeah, "CFLAGS=--sysroot=<sysrootdir> ./configure" seems to be working
Jul 20 21:06:43 <hollisb> but I have no idea what "./configure --with-sysroot" is supposed to do then
Jul 20 21:10:23 <khem> it it not default option in autoconf
Jul 20 21:10:27 <khem> you have to add code for it
Jul 20 21:10:44 <khem> did you modify lighttpd configure to have the new option ?
Jul 20 21:10:52 <khem> or was this option already available ?
Jul 20 21:12:11 <hollisb> oh, hmm. it was already available
Jul 20 21:12:31 <hollisb> doesn't appear in configure.ac though
Jul 20 21:12:35 <khem> lighttpd has this option already ?
Jul 20 21:12:44 <hollisb> yes
Jul 20 21:13:12 <khem> well CFLAGS in OE pass a default --sysroot= as well
Jul 20 21:13:27 <hollisb> ok...
Jul 20 21:13:27 <khem> I wonder if lighttpd's is adding its sysroot before that
Jul 20 21:13:35 <khem> what does cmdline look like
Jul 20 21:16:45 <hollisb> khem: http://fpaste.org/Up5r/
Jul 20 21:17:03 <hollisb> hmm, that didn't wrap nicely
Jul 20 21:17:18 <hollisb> but you can see there's no --sysroot gcc flags
Jul 20 21:19:21 <hollisb> I mean, I can get by with hacking CFLAGS
Jul 20 21:19:50 <hollisb> I was just wondering wtf --with-sysroot is supposed to do (and it's not in lighttpd's configure.ac, so I think it's created by autotools)
Jul 20 21:20:13 <kergoth> i've never heard of such an option
Jul 20 21:20:33 <kergoth> its likely some macro that lighttpd is calling. the fact that you dont see it directly in configure.ac doesn't mean its coming from autoconf proper
Jul 20 21:20:40 <kergoth> check aclocal.m4 and the component macros tha tflowed into it
Jul 20 21:21:31 <hollisb> hmm, true
Jul 20 21:23:44 <hollisb> coming from m4/libtool.m4, and looking at the test I still have no idea what it's trying to do :)
Jul 20 21:24:37 <hollisb> ah, I think it's used for ac_compile (only)
Jul 20 21:25:17 <hollisb> well, that's enough M4 for one day ;)
Jul 20 21:46:04 <khem> hollisb: I think you might be confusing libtool sysroot
Jul 20 21:46:35 <hollisb> I must be
Jul 20 21:47:07 <hollisb> I would say autoconf was confusing me
Jul 20 21:47:26 <hollisb> but what I wanted was gcc --sysroot, and configure did not give it to me :)
Jul 20 21:56:46 * mranostay pokes in
Jul 20 22:39:13 <khem> fray: I rebuilt all from scratch and I still see that sysroot creation problem
Jul 20 22:42:57 <khem> WARNING: Variable gnu_efi_arch contains tabs, please remove these (meta-intel/common/recipes-bsp/gnu-efi/gnu-efi_3.0m.bb
Jul 20 22:43:07 <khem> is someone seeing it as well
Jul 20 23:00:07 <ant__> khem: | arm-oe-linux-gnueabi-ld: cannot find libgcc.a: No such file or directory
Jul 20 23:05:28 <khem> ant__: ?
Jul 20 23:05:43 <ant__> NOTE: package klibc-2.0-r0.0: task do_compile: Failed
Jul 20 23:08:00 <ant__> http://paste.debian.net/180042/
Jul 20 23:08:14 <ant__> checking now how it was built before today's pull
Jul 20 23:08:21 <ant__> (for other machine)
Jul 20 23:10:06 <ant__> khem
Jul 20 23:11:10 <ant__> │/libgcc-4.7.1+svnr188658-r5  vs.  /libgcc-4.7.1.0+git1+d07e24f4ab59f264d68d21838795349faab5dede-r7                                                │   4096│Jul 21 01:0
Jul 20 23:12:20 <ant__> hm.. both packages libgcc.a in /usr/lib
Jul 20 23:12:37 <ant__> s/packages/are packaging/
Jul 20 23:20:55 <ant__> khem: it seems klibc must depend on libgcc, explicitely
Jul 20 23:21:21 <ant__> I'm building now libgcc
**** ENDING LOGGING AT Sat Jul 21 02:59:58 2012

**** BEGIN LOGGING AT Sat Jul 21 02:59:58 2012
Jul 21 19:24:34 <msm> khem: did you get qemu working within yocto for ppc stuff?
Jul 21 21:41:53 <Daemon404> bah.. has anyone actually -gotten- meta-x32 to compile a toolchain?
Jul 22 02:14:20 <khem> msm: I got it to work for e500v2/p2020
Jul 22 02:14:38 <khem> msm: but not for e5500
**** ENDING LOGGING AT Sun Jul 22 02:59:59 2012

**** BEGIN LOGGING AT Sun Jul 22 02:59:59 2012
Jul 22 04:26:38 <blloyd> besides just digging in and reading source, is there anything to help with the steep startup learning curve for yocto?
Jul 22 04:36:57 <strassek> blloyd: have you looked at the documentation?
Jul 22 05:02:07 <blloyd> yes
Jul 22 05:02:44 <blloyd> both quick-start and the full development guide
Jul 22 05:07:53 <blloyd> following the quickstart looks to give you a i686 machine to play with.  I'm after a i586 based distro (hardware is i686 without CMOV or PAE), but don't know where to look for what to base off of or where to find what is what to start making changes.
Jul 22 05:15:06 <strassek> well I'm assuming there is a bsp for what you are using. What kind of board is it?
Jul 22 05:19:38 <blloyd> eBOX-3350MX
Jul 22 05:19:51 <blloyd> And haven't found one.  :(
Jul 22 05:21:34 <blloyd> thus, getting to do both hardware side and applications side.  On flip side, I need to learn the hardware anyways because I need this for a custom board we make anyways.
Jul 22 08:04:39 <aavello> anyone spanish speaker ?
Jul 22 08:06:17 <aavello> i'll try later ..
Jul 22 08:07:00 <aavello> exit
Jul 22 19:35:06 <Jake9xx> hello, is there anyone who could help me out with omap4 and GLES with yocto ?
Jul 22 20:04:55 <aavello> anyone ?
Jul 22 20:58:04 <alvaro> ping
Jul 22 21:03:43 <alvaro> quit
Jul 22 21:04:08 <Jake9xx> responding to myself. Pull stuff from git://git.linaro.org/people/rsalveti/pvr-omap4.git
Jul 22 21:04:47 <Jake9xx> per request I can show my recipe.
Jul 22 21:04:51 <Jake9xx> thank you and good night.
Jul 23 02:36:02 <aavello> anyone ?
**** ENDING LOGGING AT Mon Jul 23 02:59:58 2012

**** BEGIN LOGGING AT Mon Jul 23 02:59:58 2012
Jul 23 07:56:24 <bluelightning> morning all
Jul 23 08:01:10 <Henrik_> morning
Jul 23 08:04:36 <Henrik_> If I create a file named task-core-graphicstask.bb and then add the tasks task-custom-graphictools it throws no error. Though if I also add the tasks task-custom-graphictools-dbg and task-custom-graphictools-dev it does throw errors (but the bake is successful anyway). Why?
Jul 23 08:05:27 <Henrik_> The errors are: "ERROR: task-custom-graphictools-dbg is listed in PACKAGES multiple times, this leads to packaging errors. " and "ERROR: task-custom-graphictools-dev is listed in PACKAGES multiple times, this leads to packaging errors. ".
Jul 23 08:08:36 <seebs> Honestly, I don't know, but I *speculate* that when you add something to the task list, it goes and finds a recipe for it. So if you add two things that the same recipe provides, that recipe gets added twice.
Jul 23 08:11:23 <Henrik_> It's the way that it's suggested in the tutorial though. They added both -dbg and -dev in task-core-boot.bb as well?
Jul 23 08:14:17 <Henrik_> Found the reason. It throws error if you use "inherit task", it does not throw  error if you use "ALLOW_EMPTY = "1""
Jul 23 08:21:18 <Henrik_> Using a custom BSP with a custom kernel and you want to give custom configs to the kernel, is the preferred way to use the user-config or formfactor's machconfig?
Jul 23 08:39:17 <ant_work> afaik there are no bindings between formfactor and kernel. Formfactor is just for Xserver and in fact we abuse of it for psplash as well, with minor issues.
Jul 23 08:42:39 <Henrik_> Thanks! I wanted to be sure as the current dev-manual states that you should use machconfig in formfactor when adding configurations to the kernel, but the BSP manual states that you should use the user-config. :)
Jul 23 08:44:03 <ant_work> hm, interesting :)
Jul 23 08:45:00 <ant_work> imagine that formfactor is not built for X-less images while kernel ofc is
Jul 23 08:45:46 <ant_work> but I never dug deeply in the docs...
Jul 23 08:47:49 <Henrik_> The docs are often not up to date or even wrong, so I shouldn't take the dev-manual too serieus if you think it's wrong.
Jul 23 08:48:39 <ant_work> I can't say that, I've never seen relationship btw kernel and formfactor though
Jul 23 08:49:25 <ant_work> I'm using some custom kernel built with linux-yocto btw
Jul 23 09:05:50 <ant_work> Henrik_: in theory the kernel could make good use of the info in formfactor at build time (presence of screen, keyboard,...) but KERNEL_FEATURES are used instead
Jul 23 09:08:00 <Henrik_> ant_work: Does in theory mean that if you put the info in formfactor's machconfig it will use it, or that it could potentially had used it though it don't?
Jul 23 09:09:01 <ant_work> Can't exclude, but  I don't see such code in oe-core
Jul 23 09:09:55 <Henrik_> Thanks
Jul 23 09:10:32 <ant_work> yw, maybe others can further comment
Jul 23 11:50:09 <Henrik_> If I want to GDB the QEMU I have baked I thought I could do a simple: runqemu -s -S qemux86 though I noticed that it doesn't work as it doesn't recognize -s nor -S. What's the proper way to just use GDB on qemu?
Jul 23 12:12:21 <bluelightning> Henrik_: maybe you want runqemu qemuparams="-s -S" qemux86
Jul 23 12:12:42 <bluelightning> qemuparams are passed through directly to qemu
Jul 23 12:28:22 <Henrik_> Thanks bluelightning for the command qemuparams, it worked as a way to add the params when starting the qemu. Though it didn't start the gdb as it stopped my whole machine and had to restart it... Any tips of how to gdb a qemu?
Jul 23 12:28:54 <bluelightning> Henrik_: never needed to do that myself I'm afraid, sorry
Jul 23 12:29:06 <Henrik_> np, will continue looking
Jul 23 12:30:29 <br_hugo> Hi all!
Jul 23 12:30:37 <Henrik_> hi
Jul 23 12:30:54 <br_hugo> I'm writing a recipe to compile my custom app...
Jul 23 12:31:16 <br_hugo> And I need some custom libs too.
Jul 23 12:32:49 <br_hugo> And when I'm writing the recipe to build my app, some doubt appears...
Jul 23 12:33:20 <br_hugo> What's the difference between inherit a bbclas and BBEXTENDS
Jul 23 12:33:25 <br_hugo> ?
Jul 23 12:42:20 <Henrik_> No idea what the difference is
Jul 23 13:00:40 <bluelightning> br_hugo: with BBCLASSEXTENDS bitbake creates a "virtual" copy of the recipe which inherits from the specified class(es)
Jul 23 13:01:12 <bluelightning> br_hugo: so when you do BBCLASSEXTENDS += "nativesdk" for example you get normal (for the target) and nativesdk versions
Jul 23 13:01:29 <bluelightning> without having to write a separate recipe that inherits nativesdk
Jul 23 13:04:09 <br_hugo> Hmm... Ok... If the process to compile my custom package (a .so lib for example) is the same for the target and sdk, use BBCLASSEXTENDS is more practical...
Jul 23 13:05:36 <br_hugo> bitbake will compile the source two times, right? One for sdk and one for target?
Jul 23 13:07:02 <bluelightning> br_hugo: yes that's correct
Jul 23 13:15:29 <br_hugo> Ok! Thanks!
Jul 23 13:18:35 <br_hugo> If my .so lib package is used by an application that will be built by sdk created by yocto, this sdk should contain this lib, right?
Jul 23 13:27:39 <mla__> Hi, one question: For GPL software you need to provide the sourcecode. Is there a recipe, which collects all sourcecode used and puts it in some directory so that you can either burn this on CD or sync it to an FTP server?
Jul 23 13:33:25 <br_hugo> Hi mla_... You can backup your "downloads" directory on build dir...
Jul 23 13:43:16 <mla__> but there are also git repos there.
Jul 23 13:49:40 <mla__> And i want to distribute the specific version and no the complete git repo. my download currently is > 4.5 GB.
Jul 23 14:03:07 <mla__> found it. looks like the archive class does what i want. need to test it out.
Jul 23 14:11:46 <marcbalcells> hello
Jul 23 14:15:20 <marcbalcells> do you guys know any simple way to create a recipe from a pypi package? I've used the cpan class before to create perl packages and I wondered if there is something simmilar for python
Jul 23 14:46:06 <bluelightning> mla__: there is functionality for that yes
Jul 23 14:46:39 <bluelightning> mla__: have a look at meta/classes/archive*.bbclass
Jul 23 14:46:48 <bluelightning> not sure if we have it documented yet
Jul 23 14:47:15 <bluelightning> marcbalcells: I don't know of anything like that I'm afraid, sounds like it would be useful though
Jul 23 14:48:13 <marcbalcells> bluelightning I've seen that using the "setuptools" class packages get built but no dependencies are checked :-)
Jul 23 14:58:05 <bluelightning> marcbalcells: indeed we do not have any automatic python dependency handling
Jul 23 15:12:27 <bluelightning> fray: btw, I'm nearly done with this rootfs work, just testing it now
Jul 23 15:12:41 <bluelightning> fray: I did want to ask you a couple of things though
Jul 23 15:12:44 <fray> cool.. if there is anything you want me to look at let me know..
Jul 23 15:12:44 <fray> sure
Jul 23 15:13:50 <bluelightning> fray: there's a whole section in package_install_internal_rpm for handling recommends, but it appears that it is never run...
Jul 23 15:14:06 <fray> it should be.. Hmm
Jul 23 15:14:06 <bluelightning> fray: do we still need that code?
Jul 23 15:15:05 <fray> looking
Jul 23 15:16:13 <fray> hmm...
Jul 23 15:17:29 <marcbalcells> thks bluelightning
Jul 23 15:18:18 <marcbalcells> do you guys know how to solve the "error: option --single-version-externally-managed not recognized" with some python pypi packages? I've been googling a bit but no clear solution
Jul 23 15:18:26 <fray> bluelightning is there a way to run the suggests install in deb or opkg installs?
Jul 23 15:19:11 <bluelightning> fray: ah right, I've misunderstood what that's for I think
Jul 23 15:23:35 <fray> this looks incomplete to me.. like I wrote the code and never finished it (allowed someone to enable the suggests behavior)
Jul 23 15:27:18 <bluelightning> fray: hmm, ok... now I understand what it's supposed to be doing it seems logical that it's disabled by default
Jul 23 15:30:42 <fray> ya, I'm just surprised that it's disabled like that, and isn't able to be activated by a bitbake variable
Jul 23 15:32:15 <aavello> ping
Jul 23 15:39:05 <blloyd_> I seem to be missing a step.  I've tried both with qemux86 and atom-pc so far, and they create ext3 and tar.gz files.  They don't create the hddimg file I see reference in the documentation.  Where do I enable making that file?
Jul 23 15:43:18 <bluelightning> blloyd_: how are you building the image exactly?
Jul 23 15:46:14 <blloyd_> Right now, I have a git repo, poky, with meta-yocto and poky-extras git repos in it.  Sourcing the oe... setup script, then I've tried both hob and bitbake.  bitbake I've done both core-image-sato and core-image-minimal.  End machine will eventually boot from an SD card.
Jul 23 15:47:01 <bluelightning> it sounds like for whatever reason the live image type was not enabled
Jul 23 15:47:08 <bluelightning> it ought to be by default for atom-pc at least
Jul 23 15:47:42 <bluelightning> in hob, check that you have the live image type enabled under Settings
Jul 23 15:48:52 <blloyd_> THANK YOU.  I knew it wasn't something easy/stupid.
Jul 23 15:50:05 <bluelightning> puzzling that you would have to enable that manually...
Jul 23 15:50:25 <blloyd_> *was
Jul 23 15:54:33 <blloyd_> can you tell me what exactly the live image is?  Is it USB centric?
Jul 23 16:08:44 <bluelightning> blloyd_: it's designed for booting from USB
Jul 23 16:09:14 <bluelightning> blloyd_: I don't have all the details for a full description I'm afraid, but you can have a look at classes/image_live.bbclass if you want the full details
Jul 23 16:09:44 <bluelightning> IIRC it uses an initramfs and then mounts an image file containing the real rootfs
Jul 23 16:15:43 <bluelightning> ericben: ping
Jul 23 16:32:51 <blloyd_> thanks, suspected it would be a lot more work at bootup than is strictly required.  Think I've found what's missing so I can make a bootable HD image.
Jul 23 16:39:36 <bluelightning> fray: here's what I have at the moment: http://cgit.openembedded.org/openembedded-core-contrib/log/?h=paule/rootfs2
Jul 23 17:10:29 <aavello> Hi guys, i'm having issues building a custom kernel
Jul 23 17:10:51 <aavello> I've successfully built a core-image-sato for a n450 board.
Jul 23 17:11:26 <aavello> But as i have an intel 4965agn wifi card, i decided to build a custom kernel to include the kernel modules for that card
Jul 23 17:13:00 <aavello> as the manual says
Jul 23 17:13:05 <aavello> bitbake linux-yocto -c menuconfig
Jul 23 17:13:26 <aavello> and everything was fine
Jul 23 17:15:33 <aavello> but after building the new version of core-image-sato , the static modules are not in the booted image
Jul 23 17:29:14 <otavio> RP__1: about shadow fix you want me to extend commit log and resend it?
Jul 23 17:31:12 <sgw> otavio: I think that would be best to update the commit message and resend please & thanks
Jul 23 17:31:34 <otavio> sgw: the bash fixes; have you taken them?
Jul 23 17:32:39 <sgw> otavio: looks like they are in my pending queue.
Jul 23 17:32:49 <otavio> sgw: ok, nice
Jul 23 17:38:12 <otavio> sgw: sent; check if it is clear enough please
Jul 23 17:57:22 <msm> im having this issue with edison: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=554657
Jul 23 17:57:29 <msm> when building for atom-pc
Jul 23 17:57:51 <msm> there are some related commits since edison that seem likely fixes for this issue
Jul 23 17:57:53 <msm> can anyone comment?
Jul 23 19:03:00 <AdityaGadhi> I am trying to get a distribution for my board, want to start with default poky sato build for crownbay, but modify the kernel, I managed to do the kernel config for the crownbay bsp using commands "bitbake linux-yocto -c menuconfig" in the build directory for Crownbay, but when I build it , it does not rebuild the kernel, need help with it, very new to yocto project management
Jul 23 19:17:44 <AdityaGandhi> Need help applying kernel patches, in yocto, its been suggested no to modify code directly , please help
Jul 23 19:50:44 <AdityaGandhi> I have a problem applying patches,
Jul 23 19:50:50 <AdityaGandhi> yocto-kernel patch add crownbay <path to patch>
Jul 23 19:51:05 <AdityaGandhi> gives an error Couldn't determine the kernel for this BSP, exiting.
Jul 23 20:01:12 <dvhart> AdityaGandhi, are you following a particular example?
Jul 23 20:01:33 <dvhart> AdityaGandhi, I need to understand whatever state you might be in
Jul 23 20:04:52 <AdityaGandhi> Okay I downloaded the poky version 7.0 denzil
Jul 23 20:05:01 <AdityaGandhi> and the crownbay BSP from the website,
Jul 23 20:05:17 <AdityaGandhi> wated to add a patch for the in the kernel
Jul 23 20:06:01 <AdityaGandhi> But am unable to do so suing yocto tools, it says couldn't determine  found for your bSP
Jul 23 20:06:40 <dvhart> did you create a BSP layer using yocto-bsp first?
Jul 23 20:07:00 <dvhart> are you following any particular guide?
Jul 23 20:07:35 <AdityaGandhi> dvhart , what other details do you want, I have added the paths to my bblayers.cong, I am abl to build a the default distribution, modify using hob
Jul 23 20:07:42 <AdityaGandhi> No just the quick start guide
Jul 23 20:08:10 <AdityaGandhi> And this guide https://wiki.yoctoproject.org/wiki/Transcript:_Using_the_Yocto_BSP_tools_to_manage_kernel_patches_and_config_items
Jul 23 20:11:55 <dvhart> AdityaGandhi, note the first line of the last document
Jul 23 20:12:13 <dvhart> the yocto-kernel tool is meant to be used on a BSP layer created with the yocto-bsp tool
Jul 23 20:12:26 <dvhart> not an existing BSP (at least that is my understanding)
Jul 23 20:13:06 <dvhart> afk for a couple minutes
Jul 23 20:14:28 <AdityaGandhi> dvhart I will research more on that, but till then could you suggest another way to get this patch in using yocto tools, or should I do it manually
Jul 23 20:14:41 <AdityaGandhi> afk for lunch
Jul 23 20:28:04 * dvhart returns
Jul 23 20:28:47 <dvhart> AdityaGandhi, for a single patch, I would create a linux-yocto*.bbappend file and add a single SRC_URI += "file://mypatch" line.
Jul 23 20:29:02 <dvhart> just like you would do with any other recipe
Jul 23 21:27:33 <AdityaGandhi> thanks dvhart
**** ENDING LOGGING AT Tue Jul 24 02:59:58 2012

**** BEGIN LOGGING AT Tue Jul 24 02:59:58 2012
Jul 24 03:10:47 <nitink> Morning !
Jul 24 07:08:31 <mckoan> good morning
Jul 24 08:30:28 <zib_> According to current poky-ref manual (5.2.2.1) then if I bitbake gdb-cross then a file should  be created tmp/sysroots/<host-arch>/usr/bin/<target-abi>-gdb though there is none after bitbake and I can't find any proper file with -gdb ending. Has the way to start a remote GDB server changed or has the location of said file changed?
Jul 24 11:10:23 <likewise> gm
Jul 24 11:24:24 <likewise> Can someone point me to a out-of-kernel module build recipe. I am trying to see why the OE Classic recipes fail with OE-Core/Yocto.
Jul 24 11:29:15 <likewise> Solved. Added export KERNELDIR = "${STAGING_KERNEL_DIR}" fixed it.
Jul 24 11:31:55 <bluelightning> likewise: sadly I cannot find documentation on how to build out-of-tree modules, I thought we had something on that
Jul 24 11:32:26 <likewise> bluelightning: I thought so too. I think it was a scribble on OE Classic then.
Jul 24 11:34:22 <likewise> bluelightning: I also remember someone putting up a repo with minimal examples. Lost that ref too. I will Google a bit.
Jul 24 11:35:01 <bluelightning> likewise: ah, that I do know - it's meta-skeleton, which is included in the OE-Core repo
Jul 24 11:35:08 <bluelightning> it has a hello-mod example
Jul 24 11:35:45 <likewise> bluelightning: thanks.
Jul 24 11:42:28 <likewise> KERNELDIR was changed to KERNEL_SRC. So I rather change my Makefile than my recipe. http://git.yoctoproject.org/cgit.cgi/poky/plain/meta/recipes-kernel/lttng-2.0/lttng-modules/lttng-modules-replace-KERNELDIR-with-KERNEL_SRC.patch
Jul 24 12:11:56 <likewise> bluelightning: will you visit ELCE this year?
Jul 24 13:05:32 <bluelightning> likewise: it's likely yes
Jul 24 13:07:39 <bluelightning> likewise: and you?
Jul 24 13:21:27 <likewise> bluelightning: yes, will be there.
Jul 24 13:21:36 <bluelightning> cool :)
Jul 24 13:21:37 <likewise> bluelightning: so let's remember to meet. :)
Jul 24 13:21:43 <bluelightning> likewise: definitely!
Jul 24 14:05:06 <zib_> If using ~/poky-denzil-7.0/build/tmp/sysroots/x86_64-linux/usr/bin/i586-poky-linux/i586-poky-linux-gdb I get: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory.
Jul 24 14:05:26 <zib_> Anyone know where that may come from?
Jul 24 14:07:02 <bluelightning> zib_: I think libtinfo is provided by ncurses
Jul 24 14:07:31 <bluelightning> zib_: but you're not really supposed to run things directly from the sysroot like that - you should use/create an SDK
Jul 24 14:07:59 <bluelightning> (assuming you are running it directly)
Jul 24 14:10:18 <zib_> I have unpacked the sato-SDK.tar.bz2 which I baked and have another sato-SDK running gdbserver on a QEMU. I'm already using libncurses5-dev, doesn't that provide ncurses?
Jul 24 14:10:41 <zib_> The gdb I linked to is within the unpacked sato-sdk
Jul 24 14:11:55 <zib_> bluelightning: Maybe require a symlink?
Jul 24 14:12:54 <bluelightning> zib_: the path you posted above isn't...
Jul 24 14:13:41 <bluelightning> that's a path into the sysroot which we create for use during the build
Jul 24 14:14:30 <zib_> Tried to not show $HOME. Whole path: $HOME/poky-denzil-7.0/build/tmp/work/i586-poky-linux/gdb-cross-7.4-r8.0/sysroot-destdir/$HOME/poky-denzil-7.0/build/tmp/sysroots/x86_64-linux/usr/bin/i586-poky-linux/i586-poky-linux-gdb
Jul 24 14:16:04 <zib_> I unpacked it within a temp directory within the images directory, would that upset it?
Jul 24 14:16:25 <bluelightning> zib_: that's a path into the workdir of gdb-cross, that's also not supposed to be run directly
Jul 24 14:17:08 <bluelightning> sysroot-destdir is where the files get put before they are copied into the sysroot during the build
Jul 24 14:17:19 <zib_> So the gdb which I am supposed to run, where does it get located after a bitbake of the gdb-cross?
Jul 24 14:20:51 <bluelightning> zib_: I'm not entirely sure, but I do know how you're attempting to do it above won't work - when you run it from there, there is no way for gdb to find the libraries it needs
Jul 24 14:22:12 <zib_> Thanks. I did a search for all files which ended with -gdb, as that was how it was described in the manual even if the manual's path was wrong, and that was the one I found. Maybe it's named something else.
Jul 24 14:23:07 <bluelightning> hmm, actually our documentation does tell you to grab gdb from that location
Jul 24 14:23:11 <bluelightning> not ideal IMO
Jul 24 14:23:51 <zib_> So what's wrong in case that is the correct file?
Jul 24 14:24:16 <bluelightning> it's the correct file it would seem, but I'm just not sure it's practical to run directly
Jul 24 14:24:25 <zib_> So how should it be run?
Jul 24 14:24:56 <bluelightning> I haven't done cross-debugging with gdb I'm afraid...
Jul 24 14:25:10 <zib_> Is there anyone that I can ask about that?
Jul 24 14:25:27 <bluelightning> hopefully someone else here can advise on the best method
Jul 24 14:25:33 <zib_> Thanks
Jul 24 14:25:43 <bluelightning> I'm guessing if you built meta-toolchain it would include all of the required libraries as part of the toolchain
Jul 24 14:28:36 <jstashluk> otavio: I see you pushed some xserver stuff for mx6.  Do you have a imx-firmware recipe or archive updates that allow targets besides core-image-minimal?
Jul 24 14:29:12 <otavio> jstashluk: those are not yet public
Jul 24 14:29:56 <otavio> jstashluk: but the image for mx6 shouldn't need those for basic work
Jul 24 14:30:00 <otavio> jstashluk: let me check it
Jul 24 14:30:24 <bluelightning> zib_: FWIW, I've filed a bug to improve the documentation
Jul 24 14:31:31 <otavio> jstashluk: what build error you had?
Jul 24 14:32:13 <jstashluk> otavio: ERROR: imx-firmware was skipped: incompatible with machine imx6qsabrelite (not in COMPATIBLE_MACHINE)
Jul 24 14:34:37 <zib_> Thanks bluelightning!  If I get the tools with meta-toolchain, how can I use them?
Jul 24 14:38:16 <bluelightning> zib_: meta-toolchain produces a toolchain tarball you can extract; there is an environment setup script you can run and then the tools will be in your path
Jul 24 14:38:45 <otavio> jstashluk: i am checking it now
Jul 24 14:41:34 <zib_> bluelightning: So with these tools that I would setup with the script, is one of them the gdb and I would from there access that one? Or how would I properly start the host GDB so I access the gdbserver?
Jul 24 14:42:11 <bluelightning> zib_: I believe so, but I haven't actually used gdb in that context
Jul 24 14:42:32 <zib_> Thanks, baking meta-toolchain now. :)
Jul 24 14:43:30 <jstashluk> otavio: meta-fsl-arm/recipes-bsp/imx-firmware/imx-firmware_0.1.bb:12
Jul 24 14:44:28 <otavio> jstashluk: http://paste.debian.net/180484/
Jul 24 14:44:34 <otavio> jstashluk: try this patch
Jul 24 14:51:24 <jstashluk> otavio: thanks, baking...
Jul 24 14:51:33 <otavio> jstashluk: works?
Jul 24 14:52:01 <jstashluk> otavio: I'll let you know if core-image-base works in a moment.
Jul 24 14:52:04 <otavio> jstashluk: you won't have vpu and ipu but rest ought to work
Jul 24 14:53:03 <jstashluk> otavio: any idea when IPU will be make public?  or should I lean on my FAE harder?
Jul 24 14:53:22 <otavio> jstashluk: I am under NDA ;-)
Jul 24 14:53:24 <jstashluk> ^make^made
Jul 24 14:54:29 <jstashluk> otavio: great, now I have to go down to see the lawyers to see what our NDA covers <shudder>.
Jul 24 15:02:33 <Song_> YPTM: Hi guys, let's start the technical team meeting now
Jul 24 15:02:40 <Song_> YPTM: who's on the call?
Jul 24 15:02:42 <halstead> Song_, YPTM: Michael Halstead present.
Jul 24 15:02:42 <bluelightning> YPTM: Paul Eggleton joined
Jul 24 15:02:47 <davest> YPTM: davest is on the bridge
Jul 24 15:03:01 <sgw> YPTM: Saul is here
Jul 24 15:03:05 <RP__> YPTM: Richard is on the bridge
Jul 24 15:03:36 <strassek> YPTM: Kevin is on the bridge
Jul 24 15:03:54 <jmpdelos> YPTM: Jeff Polk is here
Jul 24 15:04:02 <rburton> YPTm: Ross Burton here
Jul 24 15:04:26 <darknighte> YPTM: dialin in now
Jul 24 15:05:04 * darknighte gets a busy signal
Jul 24 15:05:22 <bogdanm> YPTM: Bogdan is on the bridge
Jul 24 15:05:34 * nitink is not able to get on the bridge
Jul 24 15:05:40 <scottrif> Scott Rifenbark Joined the call
Jul 24 15:05:48 <dvhart> song, Darren Hart has joined the call
Jul 24 15:06:06 <bluelightning> nitink: have you tried skype btw?
Jul 24 15:06:19 <nitink> will try
Jul 24 15:06:31 * darknighte has joined the YPTM, no opens
Jul 24 15:06:52 <bogdanm> YPTM: no opens
Jul 24 15:06:55 <RP__> YPTM: no opens thanks
Jul 24 15:06:58 <davest> YPTM: no opens
Jul 24 15:06:59 <bluelightning> YPTM: no opens
Jul 24 15:07:02 <darknighte> Song_ is asking for opens from IRC.
Jul 24 15:07:07 <Song_> YPTM: Please let me know if you have any opens or anything you would like to add for the meeting
Jul 24 15:07:13 <strassek> YPTM: no opens
Jul 24 15:07:36 <dvhart> YPTM: no opens
Jul 24 15:07:53 * nitink joined via skype
Jul 24 15:08:05 * nitink voice has gone bad
Jul 24 15:08:17 <nitink> song: alright
Jul 24 15:08:20 <darknighte> it looks like he'll have to!
Jul 24 15:08:22 <sgw> nitink: you sounded much deeper
Jul 24 15:08:40 <nitink> sgw: yes my throat is hurting :-/
Jul 24 15:09:29 <darknighte> Link: https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.3_Status#Milestone_2
Jul 24 15:09:29 <Song_> https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.3_Status#Milestone_2
Jul 24 15:09:33 <rburton> oh, the us number is toll-free
Jul 24 15:09:34 <Song_> YPTM: https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.3_Status#Milestone_2
Jul 24 15:11:06 * fray is dialing in right now..
Jul 24 15:12:01 <likewise> I would like to rise one point, however I am not in the call: Yocto ML: May 11th: "[yocto] kernel rebuild and bitbake -c menuconfig"  The last remark by Bruce Ashfield was "Definitely something we'll fix up during the worklow streamlining being done as part of 1.3." -- However I missed if this is an issue being tracked?  Note that this issue is different from bug https://bugzilla.yoctoproject.org/
Jul 24 15:12:03 <likewise> show_bug.cgi?id=2256 which is RESOLVED.
Jul 24 15:12:35 <likewise> YPTM: ^^
Jul 24 15:13:37 <darknighte> likewise: I brought it up.
Jul 24 15:14:32 <dvhart> likewise, yes 2256 should be closed - are you still having an issue with this?
Jul 24 15:17:01 <likewise> dvhart: no 2256 is fixed, but the other point (ML Topic) is about deploy dependency after source change/compile rather than make menuconfig. I was hitting it today again.
Jul 24 15:17:29 <dvhart> ilooking
Jul 24 15:19:18 <fray> yup.. planning on that -today-
Jul 24 15:19:31 <sgw> fray: sorry about that!
Jul 24 15:19:42 <fray> thats fine..  I'm finally back at the office..
Jul 24 15:20:00 <sgw> fray: for all of 3 minutes ;-)
Jul 24 15:20:25 <likewise> dvhart:  Sorry, I have to run.
Jul 24 15:20:49 <Song_> YPTM: https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.3_Status
Jul 24 15:20:55 <dvhart> like|logging, ping me when you get back
Jul 24 15:23:20 <kergoth> damnit, i keep missing the call due to it not being on my calendar, anyone able to resend/forward me a calendar invite?
Jul 24 15:23:38 <darknighte> kergoth: will do
Jul 24 15:25:46 <darknighte> sgw: what version of eglibc was that?
Jul 24 15:26:09 <sgw> 2.16
Jul 24 15:26:14 <darknighte> thx
Jul 24 15:26:17 <sgw> We are currently on 2.15
Jul 24 15:26:52 <darknighte> sgw: audio obliterated the ver # and I just wanted to make sure
Jul 24 15:27:00 <nitink> me /yes
Jul 24 15:27:22 <sgw> darknighte: is my audio that bad?  If so I need a new BT headset
Jul 24 15:27:36 <darknighte> nah, I think it's on my end.
Jul 24 15:27:41 <dvhart> halstead, poke - would it be possible to get some help text for the Whiteboard field here: https://bugzilla.yoctoproject.org/page.cgi?id=fields.html#bug_file_loc
Jul 24 15:28:46 <halstead> dvhart, Sure. What should it say?
Jul 24 15:29:02 <dvhart> halstead, I'll follow up with you on Thursday after I get the text
Jul 24 15:29:14 <dvhart> halstead, I wasn't sure as it doesn't have a link like the other fields do
Jul 24 15:30:54 * fusman1 just dialed into the meeting
Jul 24 15:31:41 <halstead> dvhart, I can easily change the text on the page you linked. I can probably add a hover with help text like the other fields have without too much trouble.
Jul 24 15:32:13 <dvhart> OK, I have to discuss with Song_  and will get back to you.
Jul 24 15:45:18 <Song_> YPTM: thank you all for the joining the meeting. You all have a nice day
Jul 24 17:52:57 <blloyd_> Anyone know an easy way to disable CMOV?  I know the kernel uses it, and I suspect gcc uses it instead of the expanded two instructions to test and branch.
Jul 24 17:56:01 <fray> you need to configure for a non i586? CPU.. there are CPU optimization flags to pass to get older behavior..
Jul 24 17:56:31 <fray> I don't know if you can simply disable it for the kernel, but for GCC I believe -mcpu=i586 might... -mcpu=i486 or i386 should
Jul 24 18:01:35 <blloyd> fray: technically, CMOV was optional in i586...
Jul 24 18:01:53 <fray> yes.. thats why I believe i586 disables it
Jul 24 18:02:02 <fray> i686 uses it..
Jul 24 18:02:17 <blloyd> ok, I'm building for i586 but when booting on the device, it blows up needing CMOV.
Jul 24 18:02:18 <fray> there used to be an i586mmx option (I don't know if there still is) that would also enable CMOV
Jul 24 18:02:28 <fray> then you'll have to fall back to i486
Jul 24 18:02:30 <apinski> is this a C3?
Jul 24 18:02:35 <fray> sounds like it is
Jul 24 18:02:41 <fray> there is a C3 tuning that should work
Jul 24 18:03:12 <apinski> note there are two different C3's
Jul 24 18:03:18 <apinski> one with CMOV and one without
Jul 24 18:03:56 <fray> TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "c3", "-march=c3 -mtune=c3", "", d)}"
Jul 24 18:04:06 <fray> I suspect the -march/-mtune c3 disables CMOV
Jul 24 18:04:20 <fray> if you aren't using the c3 tunings, you should start there..
Jul 24 18:04:26 <apinski> -march=c3 does disables cmov's
Jul 24 18:05:15 <blloyd> what's c3?
Jul 24 18:05:24 <fray> Cyrix3 processor
Jul 24 18:05:39 <fray> VIA C3, VIA Cyrix III or other markings
Jul 24 18:05:42 <blloyd> PMX-1000.  (Vortex86MX)
Jul 24 18:05:47 <fray> fairly ancient thing..
Jul 24 18:05:56 <blloyd> Brand spanking new thing
Jul 24 18:06:21 <blloyd> (ok, chipset is still manufactured, might not be the hottest item made)
Jul 24 18:06:28 <fray> sounds like it's broken if it doesn't icnlude CMOV.. :P
Jul 24 18:06:34 <fray> it's not like it's a new instruction
Jul 24 18:07:00 <sgw> khem: ping regarding the eglibc locale issue
Jul 24 18:07:02 <apinski> http://en.wikipedia.org/wiki/Vortex86
Jul 24 18:07:13 <bluelightning> sgw: I was referring to khem's comments on bug #2824
Jul 24 18:07:42 <sgw> I get soo much bugzilla mail I do not typically read, I will go check it now!
Jul 24 18:08:01 <bluelightning> sgw: I imagine you would, yeah... fair enough
Jul 24 18:08:34 <fray> good chance the C3 tunings are compatible, otherwise you are stuck w/ i486 -- or vendor specific toolchain patches..
Jul 24 18:08:47 <fray> I don't know of another way to disable CMOV... (there used to be another switch, but I don't know it)
Jul 24 18:09:36 <sgw> bluelightning: ah that also partly answers my -locale-locale question.
Jul 24 18:10:09 <bluelightning> sgw: yeah; it's a bit nasty, but expected without adding extra mangling to eglibc-locale
Jul 24 18:10:46 <bluelightning> sgw: it's the RDEPENDS on eglibc-locale which ends up empty which is causing the problem I would think
Jul 24 18:10:48 <sgw> I guess that's what is going to be needed
Jul 24 18:12:27 <sgw> bluelightning: that's something that your change effectively does?
Jul 24 18:13:08 <bluelightning> sgw: I don't think that is possible; it's just that we may now be installing that package where we were not previously
Jul 24 18:14:05 <bluelightning> IMAGE_LINGUAS contains en-gb so it's not unexpected
Jul 24 18:14:36 <bluelightning> (that eglibc-locale-locale-en-gb would be installed if it exists)
Jul 24 18:14:49 <msm> halstead: seen this before https://gist.github.com/3171602
Jul 24 18:15:39 <sgw> msm: we see that from time to time, it's safe to run the git prune
Jul 24 18:16:10 <sgw> generally it means people have deleted branches and it helps to clean up your local side also.
Jul 24 18:16:52 <bluelightning> I tend to run "git fetch --all -p" so I guess that's why I haven't seen that here
Jul 24 18:16:52 <msm> oh
Jul 24 18:16:57 <msm> that's about my local side?
Jul 24 18:17:05 <bluelightning> yes
Jul 24 18:17:11 <msm> hah, silly me ;)
Jul 24 18:17:17 <halstead> I haven't seen that message but yes you should be able to prune locally.
Jul 24 18:18:22 <msm> ok, i thought it was a message about the server side… moving on now
Jul 24 18:21:00 <sgw> bluelightning: interesting, I can't specify eglibc-locale, eglibc-locale-locale or eglibc-locale-locale-en-bg as a CORE_IMAGE_EXTRA_INSTALL item, the later 2 give me nothing RPROVIDES, while the first gets to do_rootfs and then fails to find the eglibc-locale package (that might be part of the hint here)
Jul 24 18:32:07 <bluelightning> sgw: eglibc-locale-locale definitely won't be valid, no
Jul 24 18:32:35 <bluelightning> sgw: eglibc-locale-locale-en-gb (not -bg) should be present though in this instance
Jul 24 18:34:39 <sgw> bluelightning: yeah, I had -gb, just typed it wrong
Jul 24 18:37:02 <bluelightning> sgw: that package is valid here..
Jul 24 18:38:12 <sgw> bluelightning: for a C_I_E_I?  I get:ERROR: Nothing RPROVIDES 'eglibc-locale-locale-en-gb' (but /srv/ssd/sgw_ab/yocto-autobuilder/yocto-slave/nightly-ppc/build/meta/recipes-core/images/core-image-minimal.bb RDEPENDS on or otherwise requires it)
Jul 24 18:38:32 <sgw> bluelightning: that's without your change btw
Jul 24 18:38:47 <bluelightning> sgw: let me just try it... the package file exists at least
Jul 24 18:39:00 <sgw> yes, agreed the package file does exist
Jul 24 18:40:58 <khem> sgw: fray reworked the naming when he did that sdk work recently
Jul 24 18:41:07 <khem> sgw: it seemingly is fallout of that
Jul 24 18:41:28 <khem> I am not sure if it was well tested with internal toolchain
Jul 24 18:41:33 <sgw> fray: can you take a quick look at bug 2824?
Jul 24 18:41:54 <khem> eglibc package class overwrote PN
Jul 24 18:42:02 <khem> and he changed it to append to it or something in that order
Jul 24 18:43:17 <fray> in a sec.. have to finish something quick)
Jul 24 18:43:54 <bluelightning> sgw: hmm... I don't think those packages are installable that way since the RPROVIDES aren't registered until packaging time :/
Jul 24 18:44:45 <khem> bluelightning: which packages ?
Jul 24 18:44:59 <bluelightning> sgw: the eglibc-locale-locale-* packages
Jul 24 18:45:14 <khem> that package is wrong as it seems to me
Jul 24 18:45:26 <khem> there should only be eglibc-locale-*
Jul 24 18:45:33 <bluelightning> khem: I agree
Jul 24 18:45:36 <sgw> bluelightning: yes, I am also a little (maybe a lot) confused by where the -locale packages are getting added to the PACKAGES list since eglibc-locale.inc uses "=" for PACKAGES and PACKAGES_DYNAMIC
Jul 24 18:45:42 <fray> sgw -- I've seen a similar bug before, but I've never been able ot track it down
Jul 24 18:46:18 <bluelightning> sgw: the fact remains, as far as do_rootfs is concerned the package file exists and is valid to install; we're just being more thorough about installing locale packages for every package that is installed than we were previously
Jul 24 18:46:26 <sgw> fray: well we are hitting it hard now with bluelightning change, it's not eglibc 2.16 related, but it will block the update
Jul 24 18:47:00 <bluelightning> I can understand it being a blocker for merging my changes though naturally
Jul 24 18:47:06 <khem> 6cb13874ecc6bba6adfbb113f8899f6a3ac173a6 might have brought it to fore
Jul 24 18:47:41 <fray> that shouldn't have
Jul 24 18:47:51 <fray> and I saw problems like that before that patch went in
Jul 24 18:48:12 <khem> indeed it should not have
Jul 24 18:49:25 <fray> Ya, I have no idea as to the cause..  my guess is something should have either a rprovide or the rdepends is invalid, but still being included...
Jul 24 18:49:31 <fray> I'm not even sure how to track it down
Jul 24 18:50:41 <bluelightning> the problem is almost certainly within do_package
Jul 24 18:50:48 <bluelightning> perhaps that's an obvious statement...
Jul 24 18:51:10 <bluelightning> but it should just be a case of instrumenting what is going on there until it's tracked down
Jul 24 18:51:27 <khem> OK explain to me how it is caused
Jul 24 18:51:36 <khem> and I can see something pops out
Jul 24 18:52:21 <bluelightning> I can't explain it, that's the problem...
Jul 24 18:53:20 <bluelightning> perhaps the first thing is to solve the eglibc-locale-locale- naming and then worry about the dependency nastiness
Jul 24 18:54:36 <fray> bluelightning that one I did find....
Jul 24 18:55:00 <khem> fray: ok shed some light
Jul 24 18:55:08 <fray> there is an assumption that locales (in packages.bbclass?) start with ${PN}.. the ${PN} in the case of eglibc-locale is well the whole string.
Jul 24 18:55:38 <fray> so if the glibc-locale package has a: PN = glibc   it would fix it
Jul 24 18:55:49 <sgw> I landed on a call back in 15
Jul 24 18:55:50 <fray> but I'm really not sure that is a valid fix
Jul 24 18:56:05 <bluelightning> fray: that seems likely to result in other breakage...
Jul 24 18:56:23 <khem> fray: it has BPN set
Jul 24 18:56:26 <fray> as far as I could tell it wouldn't.. but I never had the time to try to fix it
Jul 24 18:56:26 <khem> if that matters
Jul 24 18:56:55 <fray> approx line 389 of package.bbclass
Jul 24 18:57:28 <khem> look at libc-package.bbclass
Jul 24 18:57:34 <khem> thats the one invoked
Jul 24 18:58:01 <fray> from my exploring before, it wasn't
Jul 24 18:58:11 <fray> the stuff in libc-package.bbclass was run, but not exclusively
Jul 24 18:58:39 <fray> ya, it's package_do_split_locales  from do_package work that does it..
Jul 24 18:58:48 <fray> it runs -after- the stuff in libc-package from what I remember..
Jul 24 18:59:36 <khem> hmm
Jul 24 18:59:36 * bluelightning -> home, will be back later
Jul 24 19:02:24 <khem> its operating on PN and PN is derived from BPN
Jul 24 19:02:39 <khem> eglibc-locale sets BPN=eglibc
Jul 24 19:03:17 <fray> PN may already be set by that point
Jul 24 19:03:36 <fray> I'm not sure how quickly it's a fixed value.. but -e should be able to tell
Jul 24 19:04:19 <khem> I think package.bbclass is not needed for eglibc
Jul 24 19:04:31 <khem> all work is being done in libc-package.bbclass already
Jul 24 19:04:50 <fray> it's needed because it handles the debug info splits, and a number of other things.. but I agree, the locale stuff may not be needed
Jul 24 19:05:11 <khem> then we have to avoid the locale separation stuff out
Jul 24 19:05:32 <khem> since that bit it conflicting with libc package
Jul 24 19:05:47 <fray>     if (d.getVar('PACKAGE_NO_LOCALE', True) == '1'):
Jul 24 19:05:47 <fray>         bb.debug(1, "package requested not splitting locales")
Jul 24 19:05:47 <fray>         return
Jul 24 19:06:11 <khem> thats if you dont have locale at all
Jul 24 19:06:16 <khem> thats not the case here
Jul 24 19:06:30 <fray> no.. that only skips the apckage_do_split_locales
Jul 24 19:06:40 <fray> if you already have the rest of the locale packaging done elsewhere.. skip it
Jul 24 19:06:53 <fray> that is the -only- place that is used in the system
Jul 24 19:07:01 <khem> ok so if we do the right thing in libc-package supposedly then we can disable it
Jul 24 19:07:06 <fray> yes
Jul 24 19:09:12 <AdityaGandhi> Hi I have a quick question, I want to ass a kernel patch using  linux-yocto*.bbappend file, I have a crownbay BSP. Where shall I put this file, there is one  linux-yocto*.bbappend already in ~/Yocto/meta-intel/meta-crownbay/recepies-kernel/linux
Jul 24 19:09:39 <AdityaGandhi> should I add the patch line to it using  SRC_URI += "file://mypatc
Jul 24 19:09:58 <AdityaGandhi>  SRC_URI += "file://mypatch*
Jul 24 19:10:09 <AdityaGandhi> Or could you suggest where to put this file
Jul 24 19:10:33 <fray> you should create your own layer, add it to your own linux-yocto*.bbappend file.. with the SRC_URI += ...
Jul 24 19:10:40 <fray> multiple bbappend files are used
Jul 24 19:11:19 <fray> you should avoid modifying upstream items, unless you intend to push the changes back upstream.. (then modify it locally and send it using that layers mechanisms)
Jul 24 19:12:03 <AdityaGandhi> Hey fray thanks a lot
Jul 24 19:12:27 <khem> fray: as I see it defers the splitting biz to package.bbclass
Jul 24 19:12:44 <khem> so in a way it should be ok
Jul 24 19:12:48 <khem> flow wise
Jul 24 19:12:52 <AdityaGandhi> I will get back if I have any a problem with it
Jul 24 19:13:06 <fray> then it should be the PN value..  does -e show glibc-locale or glibc?
Jul 24 19:13:22 <fray> I suspec the PN is := evaluated early, and so not only should BPN be set, but likely also PN
Jul 24 19:14:08 <khem> BPN="eglibc"
Jul 24 19:14:14 <khem> PN="eglibc-locale"
Jul 24 19:14:18 <khem> thats the problem
Jul 24 19:14:24 <khem> hmmm
Jul 24 19:14:51 <khem> q
Jul 24 19:16:00 <khem> PN=${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE'),d)[0] or 'defaultpkgname'}
Jul 24 19:16:17 <khem> I was having wrong impression that PN is derived from BPN
Jul 24 19:25:03 <fray> PN is modified though w/ the virtclass stuff..
Jul 24 19:25:33 <fray> for one fo the packages I did.. I did something like PN := ${@... PN substitute original BPN, w/ new BPN }
Jul 24 19:25:58 <sgw> fray: Khem: I assume you guys are looking into that issue, so I am going to back out and work on other issues that need my attention.
Jul 24 19:26:29 <fray> sgw -- I'm still trying to get to the list of patches you want me to ammend.. but I think I'm finally there
Jul 24 19:26:52 <sgw> fray: I can send you a script hang on
Jul 24 19:28:35 <sgw> fray: just realized you will need to run that in the top level, but you will also need to create a patch_list directory
Jul 24 19:36:41 <fray> 'k.. I still have your original list, so I should be good
Jul 24 20:11:18 <msm> anyone recall issues were bitbake does not fetch items with '*' in their SRC_URI?
Jul 24 20:13:46 <kergoth> msm: that handling is special cased, i know we've had issues with it in the past, but don't know the current state
Jul 24 20:15:59 <msm> its failing on my machine
Jul 24 20:17:07 <msm> i can list out each file OK
Jul 24 20:17:23 <msm> https://gist.github.com/3172384
Jul 24 20:17:43 <msm> and the fix: https://gist.github.com/3172386
Jul 24 20:17:53 <msm> but it seems weird that it exists if no one sees it
Jul 24 20:18:05 <msm> maybe no one builds libpam normally?
Jul 24 20:18:34 <msm> well lots of things depend on it ;)
Jul 24 20:18:57 <msm> but it seems to be a distro feature
Jul 24 20:19:02 <msm> so maybe people don't build it recently
Jul 24 20:19:02 <kergoth> the problem with wildcards is the unclear semantics imo
Jul 24 20:19:21 <kergoth> not that that means much, since it is supposed to work
Jul 24 20:19:35 <kergoth> i'm just of the personal opinion the whole notion should go away
Jul 24 20:22:42 <kergoth> hmm
Jul 24 20:22:51 <fray> proxy issue?
Jul 24 20:22:58 <fray> I've seen proxies break wildcardingbefore
Jul 24 20:23:29 <msm> fray: it's a local file in the repo
Jul 24 20:23:49 <msm> … local/home/mattsm/git/poky-upstream/meta/recipes-extended/pam/libpam/./pam.d/*
Jul 24 20:23:52 <fray> no idea
Jul 24 20:28:34 <kergoth> i'd double check the unpack logic
Jul 24 21:24:13 <blloyd> about how many weeks/months should I expect it to take to learn bitbake and yocto?  I feel like I haven't even scratched the surface.
Jul 24 21:24:52 <kergoth> depends on the person and what level of expertise you're trying to acquire
Jul 24 21:25:22 <fray> to do basic things (primarily configure/build and basic recipe integration) it's taken my coworkers 1-2 weeks on average..
Jul 24 21:25:33 <fray> (but that is with someone there who they can ask on how to do things)
Jul 24 21:26:04 <fray> for more advanced concepts like working on bbclass's, non-standard configurations, and adding new features to bitbake/oe-core.. this is significantly more time required.. on the order of 30-45 days
Jul 24 21:28:22 <kergoth> I've noticed that some folks have had trouble wrapping their heads around the big picture even after much longer than that, for some reason
Jul 24 21:28:29 * kergoth isn't entirely sure why this seems to happen from time to time
Jul 24 21:28:42 <fray> I think it's a combination of scope and background
Jul 24 21:28:51 <fray> if you are new to embedded Linux, it will take longer as well..
Jul 24 21:29:31 <fray> mostly though, new users need to get comfortable with configuration settings (most of which are defined), and recipe integration, and image generation techniques..
Jul 24 21:30:00 <fray> (and if anyone is having problems with those, they should be a focus for us to revise or better document.... as that is the largest set of OE-Core users, AFAIK)
Jul 24 21:30:58 <khem> fray: I am dumping rpm --info -ql
Jul 24 21:31:10 <khem> fray: I dump --requires and --provides
Jul 24 21:31:22 <khem> for say eglibc-locale-locale-en-gb
Jul 24 21:31:29 <khem> requires
Jul 24 21:31:35 <khem> eglibc-locale-locale
Jul 24 21:31:36 <khem> en-gb-translation
Jul 24 21:31:36 <khem> eglibc-locale-locale-en-gb = 2.16-r21
Jul 24 21:31:36 <khem> eglibc-locale-locale
Jul 24 21:31:36 <khem> en-gb-translation
Jul 24 21:31:38 <khem> eglibc-locale-locale-en-gb = 2.16-r21
Jul 24 21:31:54 <khem> err the above is list of PROVIDES
Jul 24 21:31:59 <khem> then I dump REQUIRES
Jul 24 21:32:06 <khem> eglibc-locale-locale
Jul 24 21:32:06 <khem> en-gb-translation
Jul 24 21:32:06 <khem> eglibc-locale-locale-en-gb = 2.16-r21
Jul 24 21:32:06 <khem> eglibc-locale
Jul 24 21:32:06 <khem> virtual-locale-en-gb
Jul 24 21:32:46 <khem> whats the point of package providing and requiring itself
Jul 24 21:33:42 <fray> that is automatic within RPM, the package always provides itself
Jul 24 21:34:03 <khem> plus it lists it twice in --provided
Jul 24 21:34:21 <fray> if it's twice, then somehow it's being fed to RPM twice
Jul 24 21:34:32 <fray> check the .spec file, that will list anything being passed into RPM
Jul 24 21:34:37 <khem> and rpm can  not differentiate ?
Jul 24 21:34:50 <fray> that comes directly from bitbake
Jul 24 21:34:55 <fray> what do you mean?
Jul 24 21:35:04 <khem> yes I could day provides = a a a
Jul 24 21:35:11 <khem> and a will appear 3 time s?
Jul 24 21:35:22 <fray> yes, but that to me is a bug in oe
Jul 24 21:35:34 <khem> I see it a bug in rpm
Jul 24 21:35:36 <fray> RPM is only doing what you tell it to do.. providing it multiple times is not a bug
Jul 24 21:35:44 <fray> it's just unnecessary
Jul 24 21:35:46 <khem> where it can not uniquify the package names
Jul 24 21:36:02 <khem> hmm
Jul 24 21:36:04 <fray> not a bug, it's perfectly acceptable, just bad practice
Jul 24 21:36:16 <khem> there must be a reason to accept it
Jul 24 21:36:20 <khem> do you know
Jul 24 21:36:26 <fray> when you ask for a match (resolving or otherwise) it will gather the list of packages that provide the item, and only return one entry
Jul 24 21:36:44 <fray> there isn't a reason to not allow it... but as I said, it is effectively a no-op
Jul 24 21:37:05 <khem> understood that bit however I was thinking yous said its not a bug
Jul 24 21:38:02 <fray> if it's a bug, it's in OE.. things should check if what they are adding to the dependency list is already present or not
Jul 24 21:38:04 <khem> so --provides is essentially dumping me what in OE would be RPROVIDES right  ?
Jul 24 21:38:21 <fray> plus any automatic provide, I think
Jul 24 21:38:30 <fray> the .spec file in the tmp directory is the place to look
Jul 24 21:38:38 <khem> I differ on that bit, I would expect rpm to uniquify since its the last tool which has all info
Jul 24 21:38:40 <fray> that will have the explicit list of what was passed into the system
Jul 24 21:39:01 <khem> you are effectively asking compiler to emit info that linker can effectively provide
Jul 24 21:39:07 <khem> as an analogy
Jul 24 21:39:15 <fray> OE has all of the info as well.. when constructioning a RPROVIDES_${PN} you know what already exists there..  many of the places I've work on already check that the item you are reviewing is not in that list
Jul 24 21:42:28 <khem> lets say other packaging backends take care of duplicacy except rpm
Jul 24 21:42:54 <fray> do they?
Jul 24 21:43:13 <khem> yes atleast opkg seems to
Jul 24 21:43:14 <khem> eglibc-locale-locale-be
Jul 24 21:43:24 <fray> last time I checked, both deb and opkg just passed the raw RPROVIDES/RDEPENDS values
Jul 24 21:43:27 <khem> requires eglibc-locale
Jul 24 21:43:33 <khem> hmmm
Jul 24 21:44:54 <khem> and eglibc-locale is empty
Jul 24 21:45:17 <khem> I guess keeping aside eglibc-local-locale naming issue for a moment
Jul 24 21:45:36 <khem> a locale package is depening on an emptry non existing rpm
Jul 24 21:45:44 <fray> and that is a bug
Jul 24 21:46:02 <khem> so either we create an empty package
Jul 24 21:46:03 <fray> if it recommends (suggests) it, that is fine.. but it can't require it.. require is fatal
Jul 24 21:46:07 <khem> or remove the dependency
Jul 24 21:46:34 <fray> removing the dep makes the most sense to me..  the problem might simply be the automatic dependency generation from package.bbclass is wrong in this case, and we need to manually specify all dependencies
Jul 24 21:46:50 <fray> I believe it's INHIBIT_INHERITED_DEPS or something like that turns that stuff off..
Jul 24 21:47:08 <blloyd> and thanks for all the help to date fray: unfortunately, around here I'm the expert.  Makes it hard when going into new areas, and I'm definitely new to yocto.
Jul 24 21:47:09 <fray> it still runs per-package deps (which we want, but may be no-ops in this case), but it does not bring in inherited deps
Jul 24 21:47:30 <khem> %package -n eglibc-locale-locale-en-gb
Jul 24 21:47:31 <khem> Summary: eglibc-locale version 2.16-r21 - en_GB translations
Jul 24 21:47:31 <khem> Group: base
Jul 24 21:47:31 <khem> Requires: eglibc-locale
Jul 24 21:47:31 <khem> Requires: virtual-locale-en-gb
Jul 24 21:47:33 <khem> Provides: eglibc-locale-locale
Jul 24 21:47:35 <khem> Provides: en-gb-translation
Jul 24 21:47:59 <fray> that looks reasonable
Jul 24 21:48:06 <khem> %package -n locale-base-en-gb
Jul 24 21:48:06 <khem> Summary: eglibc-locale version 2.16-r21
Jul 24 21:48:06 <khem> Group: base
Jul 24 21:48:06 <khem> Requires: eglibc-binary-localedata-en-gb
Jul 24 21:48:06 <khem> Provides: virtual-locale-en-gb
Jul 24 21:48:09 <khem> Provides: virtual-locale-en
Jul 24 21:48:16 <khem> so locale-base-en-gb is providing virtual-locale-en-gb
Jul 24 21:48:20 <khem> which is good too
Jul 24 21:48:28 <blloyd> I think I'll be OK when I figure out where to find the documentation of which you speak.  Seems the documents I have found go with do this and magic happens.  Then I get to scratch my head when magic doesn't happen.
Jul 24 21:48:41 <khem> but eglibc-locale is only provided by eglibc-locale package which essentially is empty
Jul 24 21:49:00 <fray> bbloyd as of right now, best docs are the ones on the yocto project document site.. start with the getting started walk though, and then when you can't figure it out, search the other documents..
Jul 24 21:49:15 <fray> take notes, for confusing things.. please let us know.. we want to improve the docs
Jul 24 21:49:31 <fray> khem, and if empty packages aren't packaged.. then it get thrown away
Jul 24 21:50:28 <fray> I'd like to know where the eglibc-locale dependency comes in from.. I suspect it's the package.bbclass locale chunk
Jul 24 21:50:38 <blloyd> ok, where do you want notes for confusing things?  However, seems I have that unusual things for my first case headache.  :(  Finding where i586 is requiring CMOV, but CMOV is an i686 feature.
Jul 24 21:50:48 <khem> d.setVar('RDEPENDS_' + pkg, '%s %svirtual-locale-%s' % (pn, mlprefix, ln))
Jul 24 21:51:02 <khem> that pn should be punted may be
Jul 24 21:51:10 <fray> blloyd the yocto project list is the usual place..  yocto@yoctoproject.org
Jul 24 21:51:49 <fray> blloyd, ya you are coming in the deepend first..  since you have to come up with a tuning that matches your board..
Jul 24 21:51:59 <fray> (tunings are definitely in the advanced category)
Jul 24 21:52:28 <fray> khem, I suspect it's there because normally it doesn't amke sense to say install the locales for bash, w/o bash
Jul 24 21:52:30 <khem> fray: that logic of creating RDEPEND on PN in generic
Jul 24 21:52:35 <khem> usually PN wont be empty
Jul 24 21:52:44 <fray> but I'm not really sure if bash is 'required' for bash-locales.. maybe recommends is better?
Jul 24 21:53:15 <khem> yeah we can have rrecommend but then will locales work with out bash
Jul 24 21:53:18 <fray> or maybe in this case becasue the locals are seperate from glibc, the 'pn' needs to be changed to 'glibc' to fix it
Jul 24 21:53:24 <khem> if they will then rrecommend is logically ok
Jul 24 21:53:43 <fray> locales don't 'fail' without bash, but they certainly won't do anything..
Jul 24 21:54:06 <fray> the requires vs recommends on the -dbg and -locale stuff has bugged be for a while.. but I haven't had time to truely consider the ramifications of changing things
Jul 24 21:54:37 <khem> hmmm
Jul 24 21:55:16 <khem> fray: yes in this case we could hack in a check to see if pn == "eglibc-locale" then treat pn = "eglibc" logic
Jul 24 21:55:19 <khem> this would fix the issue
Jul 24 21:55:44 <khem> but I think its better to find if rrecommends is better and make that change
Jul 24 21:56:17 <fray> is there a reason we can't just do PN = 'glibc' in the glibc-locale recipe?  the BPN is already set, just do the same for the PN..(with the multilib stuff if necessary of course)
Jul 24 21:56:50 <khem> then nothing will provide eglibc-locale and there will be two providers for same package
Jul 24 21:56:57 <khem> and it will chose one over other
Jul 24 21:57:07 <fray> khem, two issues.. first is lets get it to work -- second lets fix it for the future..  I see the first as temporary and the Pn = glibc case.. the second as how should we fix it ( and potentially other cases )
Jul 24 21:57:19 <fray> no..
Jul 24 21:57:25 <fray> PN = 'eglibc'
Jul 24 21:57:32 <fray> PROVIDES = 'eglibc-locale'
Jul 24 21:57:49 <Shiz> Anyone know how to replace the shared lib busybox with a static busybox?  I'm working with core-image-minimal.
Jul 24 21:58:01 <fray> Shiz, configuration file..
Jul 24 21:58:15 <khem> fray: that might work however will end in multiple providers for eglibc
Jul 24 21:58:29 <khem> so we have to choose it in defaultdistrovar conf file
Jul 24 21:58:34 <khem> let me try it
Jul 24 21:58:46 <Shiz> I'm not using eglibc or ulibc.
Jul 24 21:58:46 <fray> shiz, I think you can do bitbake -c menuconfig busybox
Jul 24 21:59:06 <khem> adding a check in package_do_split_locales might be ok too
Jul 24 21:59:06 <Shiz> Ah, okay.  I'll try that.
Jul 24 21:59:27 <fray> khem, I don't believe you will end up with multilib glibc provides, if you do the manual PROVIDES = 'eglibc-locale' vs a += provides..
Jul 24 22:00:00 <fray> INHIBIT_DEFAULT_DEPS = "1"
Jul 24 22:00:04 <fray> that may also be needed..
Jul 24 22:01:17 <fray> that might be specific to the compiler though.. and not something here..
Jul 24 22:05:22 <khem> INHIBIT_DEFAULT_DEPS="1" is already sey
Jul 24 22:05:28 <khem> ok so let me see
Jul 24 22:07:01 <khem> fray now if I do bitbake -cclean eglibc-locale it cleans up eglibc :)
Jul 24 22:07:06 <khem> I told you
Jul 24 22:07:07 <fray> ok.. so that should be fine then.. ya the PN shouldn't affect the PROVIDES.. if it does then I'm at a bit of a loss..
Jul 24 22:07:14 <Shiz> Fray, one more question.  How dost one 'touch' a single package so that it will be rebuilt?
Jul 24 22:07:17 <fray> there is a secondary setting for the workdir you need
Jul 24 22:07:38 <khem> fray: I thought i set it
Jul 24 22:07:50 <khem> ah no
Jul 24 22:07:57 <fray> bitbake -C compile <recipe>
Jul 24 22:08:09 <Shiz> ok, thanks!
Jul 24 22:08:16 <fray> # WORKDIR=${TMPDIR}/work/${MULTIMACH_TARGET_SYS}/${PF}
Jul 24 22:08:24 <fray> # PF=${PN}-${EXTENDPE}${PV}-${PR}
Jul 24 22:08:27 <khem> yeah
Jul 24 22:08:41 <fray> so ya, redefine PF should work..
Jul 24 22:09:06 <fray> I've got to run..  maybe back later..
Jul 24 22:09:12 <fray> (otherwise in the morning)
Jul 24 22:09:32 <khem> ok that did it
Jul 24 22:11:23 <khem> ERROR: Multiple .bb files are due to be built which each provide eglibc (/home/kraj/yocto/poky/meta/recipes-core/eglibc/eglibc-locale_2.16.bb /home/kraj/yocto/poky/meta/recipes-core/eglibc/eglibc_2.16.bb). This usually means one provides something the other doesn't and should.
Jul 24 22:11:27 <khem> ERROR: Multiple .bb files are due to be built which each provide eglibc-2.16 (/home/kraj/yocto/poky/meta/recipes-core/eglibc/eglibc-locale_2.16.bb /home/kraj/yocto/poky/meta/recipes-core/eglibc/eglibc_2.16.bb).
Jul 24 22:11:31 <khem> :)
Jul 24 22:11:41 <khem> so now we need a preferred provider
Jul 24 22:12:56 <khem> PROVIDES=${P} ${PF} ${PN} virtual/libc-locale${PKGSUFFIX} eglibc-locale
Jul 24 22:13:08 <khem> I wonder who adds that ${P}
Jul 24 22:13:46 <khem> PROVIDES = "virtual/libc-locale${PKGSUFFIX} eglibc-locale"
Jul 24 22:13:48 <khem> is what I have
Jul 24 22:13:50 <khem> in recipe
Jul 24 22:16:25 <khem> bitbake.conf:PROVIDES_prepend = "${P} ${PF} ${PN} "
Jul 24 22:16:26 <khem> hmmm
Jul 24 22:34:40 <khem> fray: I beat it into submission but I think it will break sstate
Jul 24 22:34:54 <khem> since whole sstate operates on PN
Jul 24 22:54:15 <blloyd> ok, are I remember stumbling over a pdf version of a guide, but don't remember where.  I'm out of screen real estate and could use something to bleed on.
Jul 24 22:54:30 <blloyd> anyone know where I can find them?
Jul 24 23:24:55 <blloyd> found them.  Don't see links for pdfs but change the .html to .pdf and the server serves up the pdfs.  :)
Jul 25 00:42:18 <AdityaGandhi> while building xf86-input-evdev I get an error ERROR: oe_runconf failed, has this been patched / fixed
Jul 25 00:42:29 <AdityaGandhi> I read something but I am not sure if this is a problem
Jul 25 00:42:38 <AdityaGandhi> in the build system or my end
**** ENDING LOGGING AT Wed Jul 25 02:59:58 2012

**** BEGIN LOGGING AT Wed Jul 25 02:59:58 2012
Jul 25 03:39:34 <khem> sgw: around ?
Jul 25 03:40:13 <khem> sgw: my branch pull has a fix for locale problem
Jul 25 03:40:26 <khem> since I could not reproduce it locally I want you to try it
Jul 25 03:40:45 <khem> and see if it fixes the problem you were seeing
Jul 25 03:40:51 <khem> the branch is http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/misc-updates
Jul 25 03:41:05 <khem> all patches in there are ready for merge infact
Jul 25 03:41:12 <khem> in this branch
Jul 25 04:21:32 <seebs> Okay, silly question. If I look through all the logs of a build, even a successful build, I find a ton of warnings about being unable to load libpseudo.so.
Jul 25 04:21:43 <seebs> Is that me doing something wrong, or is that a known side-effect?
Jul 25 04:21:56 <seebs> It seems to me that eliminating those would certainly make for higher confidence in the output of the build.  :)
Jul 25 05:26:24 <seebs> Next time khem is around: gcc-runtime uses "-nostdlib++" (specified in gcc-configure-runtime.inc). Our compiler actually rejects this as an invalid argument.
Jul 25 05:26:38 <seebs> However, I have looked and looked, and tried experiments with gcc -v and g++ -v.
Jul 25 05:26:47 <seebs> And I have concluded that no version of gcc available to me actually *USES* that argument.
Jul 25 05:27:12 <seebs> Either it produces a diagnostic that it is an unrecognized argument, or it has no effect. By contrast, -nostdlib works on both gcc and g++.
Jul 25 05:27:22 <seebs> This is different from the behavior of -nostdinc/-nostdinc++.
Jul 25 08:56:41 <bluelightning> morning all
Jul 25 09:07:32 <shoragan> when i run hob it fails during parsing after selecting a machine with an empty error window
Jul 25 09:07:40 <shoragan> how do i find out what the problem is?
Jul 25 09:07:46 <shoragan> are there any logs?
Jul 25 09:09:04 <bluelightning> shoragan: that is unfortunately a bug I've seen
Jul 25 09:09:18 <bluelightning> shoragan: you could try running a similar configuration on the command line in the mean time
Jul 25 09:09:41 <shoragan> it works fine on the command line
Jul 25 09:09:47 <bluelightning> hmm
Jul 25 09:09:57 <bluelightning> it would be difficult to figure out without debugging I suspect
Jul 25 09:10:12 <shoragan> it prints nothing on the console either
Jul 25 09:10:51 <shoragan> how can it reproduce what hob does after the machine selection on the command line?
Jul 25 09:12:45 <bluelightning> shoragan: it should be as trivial as MACHINE=machinename bitbake -p
Jul 25 09:13:00 <bluelightning> (assuming you have not hard-set MACHINE in your local.conf)
Jul 25 09:15:21 <shoragan> it seems that hob does not honor the settings from conf/local.conf
Jul 25 09:15:26 <shoragan> where i have a BBMASK
Jul 25 09:17:49 <shoragan> how can i set that for hob?
Jul 25 09:18:31 <bluelightning> shoragan: it does not, no
Jul 25 09:18:58 <bluelightning> shoragan: additional variable values can be set in the Settings screen on the last tab
Jul 25 09:19:09 <shoragan> i tried using that
Jul 25 09:19:13 <bluelightning> not sure if they are set early enough for BBMASK though
Jul 25 09:19:28 <shoragan> but it's not written for local-default.conf
Jul 25 09:23:37 <bluelightning> I think this is an omission, aside from the error message bug
Jul 25 09:23:52 <bluelightning> it ought to be possible to set BBMASK via hob
Jul 25 09:24:08 <bluelightning> (using a proper configuration option rather than just adding it to the list, ideally)
Jul 25 09:24:57 <bluelightning> I'll file a bug
Jul 25 09:32:20 <shoragan> how can i enable console output in hob?
Jul 25 09:33:38 <bluelightning> I don't know that you can
Jul 25 09:36:25 <bluelightning> shoragan: which version are you using btw?
Jul 25 09:36:32 <shoragan> yocto 1.2
Jul 25 09:37:16 <shoragan> when i use bitbake -p with hob's bblayers-default and local.conf copied to build/conf/, it parses fine
Jul 25 09:37:24 <bluelightning> the 1.2 release version and not 1.2.1?
Jul 25 09:39:42 <shoragan> yesx
Jul 25 09:39:44 <shoragan> yes
Jul 25 09:39:58 <shoragan> so i should update?
Jul 25 09:43:30 <bluelightning> shoragan: there were a number of fixes including fixes to hob, so I would recommend it yes
Jul 25 09:46:38 <shoragan> the corresponding git tag is http://git.yoctoproject.org/cgit/cgit.cgi/poky/tag/?id=denzil-7.0.1 ?
Jul 25 09:50:27 <bluelightning> shoragan: that's correct
Jul 25 09:52:10 <shoragan> ok
Jul 25 09:52:20 <shoragan> also is using systemd possible?
Jul 25 09:52:33 <shoragan> the meta-oe denzil branch already includes it
Jul 25 09:54:14 <bluelightning> shoragan: we're getting closer; unfortunately meta-systemd still cannot be used without meta-oe, which does make some unrelated changes to packages
Jul 25 09:54:37 <bluelightning> s/packages/recipes/
Jul 25 10:29:40 <shoragan> bluelightning, will meta-systemd be compatible with yocto-1.2.x?
Jul 25 10:30:31 <bluelightning> shoragan: it has a denzil branch and it is compatible already; it just has some issues still
Jul 25 10:30:45 <shoragan> ok
Jul 25 10:41:18 <bluelightning> shoragan: let me know if you still get the blank error message with 1.2.1
Jul 25 10:43:09 <shoragan> bluelightning, i'll only have time to do the update around ~ 2. august
Jul 25 10:43:27 <shoragan> do you have a link to the bug report already?
Jul 25 10:44:24 <bluelightning> shoragan: I couldn't actually reproduce the error with master, which suggests the problem has been fixed already
Jul 25 10:44:30 <shoragan> k
Jul 25 10:45:06 <bluelightning> well, that's to say, when hob did actually enable the layer I get the expected parse failure in the dialog box instead of it being blank
Jul 25 10:45:33 <bluelightning> BBMASK is another story though, that may need a bug report... let me do some further testing
Jul 25 13:19:46 <ynezz> ~/window 11
Jul 25 15:37:39 <blloyd> Is it common for hob to leave the bitbake.lock file?  And just how likely is it that sstate-cache and tmp are (at least for a noob) unrecoverably messed up when it happens?  I have had it happen like 6 times in last few days.
Jul 25 15:38:12 <blloyd> ls
Jul 25 16:00:45 <blloyd> my hob breaks are also throwing Hob Exception - EOL while scanning string literal.  Any hints on how to find what is causing this?
Jul 25 16:15:18 <ag_> Hello.
Jul 25 16:15:33 <ag_> Can anybody help me with a strange ntpd behavior?
Jul 25 16:16:23 <ag_> My board starts with year 1970 and it seems like ntpd is working ok but not updating anything... that's annoying.
Jul 25 16:59:20 <kergoth> hmm, forgot about https://gist.github.com/2788410.. /me ponders
Jul 25 17:16:22 <blloyd> Anyone have any ideas how to debug hob when it gives "Hob Exception - EOL while scanning string literal (<string>, line 1)"
Jul 25 18:10:09 <blloyd> what is the VERSION = "20120530" line in the template-default.hob file for?  Comment it out and hob starts working again.
Jul 25 18:46:30 <seebs> kergoth or khem: either of you around and able to offer a second opinion on what -nostdlib++ is doing in gcc-runtime?
Jul 25 19:22:13 <Shiz> Anyone know how to use bitbake to rebuild a package without reconfiguring it?  I just want to do a (clean, make), but no configure.
Jul 25 19:28:19 <RP__> kergoth: I've just put a patch out to make sstate more tolerant of paths in the url to the sstate file. I've also tweaked bitbake's local fetcher to help. I'm working towards making things like lsb-release a first class citizen as part of the sstate path
Jul 25 19:28:39 <RP__> kergoth: and fix the large directory problem at the same time
Jul 25 19:29:06 <blloyd> bitbake -b ???.bb -c clean   for clean, then bitbake -b ???.bb   not do what you want?  Thought build would start where it left off.
Jul 25 19:30:09 <RP__> Shiz: you'd have to empty out the configure task, you can't clean then skip to compile
Jul 25 19:30:46 <RP__> seebs: aren't you building libstdc++ in there?
Jul 25 19:30:54 <RP__> seebs: so you don't want to link to it
Jul 25 19:31:39 <seebs> So far as I can tell, no version of gcc available to me actually HAS an option "-nostlib++".
Jul 25 19:31:46 <seebs> Some reject it as an unrecognized option, some just ignore it.
Jul 25 19:31:53 <RP__> seebs: we patch it in
Jul 25 19:31:59 <seebs> Ah-hah!
Jul 25 19:32:18 <RP__> seebs: trying to build libstdc++ separately turned out to be a little tricky
Jul 25 19:32:20 <seebs> That is the source of the mystery. This bit us because someone tried to use that recipe with our external compiler, which of course doesn't have that option.
Jul 25 19:32:25 <seebs> You're telling me!
Jul 25 19:32:35 <seebs> (We have a very very special script which does it from a gcc source tree.)
Jul 25 19:33:35 <RP__> seebs: in the end I gave in and added that option since it was the simplest way out of the problem
Jul 25 19:35:17 <seebs> Interesting. In my test, it seemed that -nostdlib had the effect you probably intended.
Jul 25 19:35:25 <seebs> Although I tested this pretty late, so I might have been hallucinating.
Jul 25 19:36:20 <RP__> seebs: I needed to link libc but not libstdc++
Jul 25 19:36:29 <seebs> Oh.
Jul 25 19:36:41 <seebs> Huh.
Jul 25 19:36:55 <RP__> seebs: I think anyway, I did this a few years ago
Jul 25 19:37:02 <seebs> Okay, thinking about this... That would be an awesome feature to have upstream, but I could see it being a hard sell to them.
Jul 25 19:37:16 <seebs> What confused me is that I have older gcc which don't recognize the option, but accept it silently, and newer gcc which reject it.
Jul 25 19:37:33 <blloyd> RP__ manual link to libc and use -nostdlib?  -nostdlib keeps from automatically linking in the standard libraries, but doesn't stop explicit linking to them.
Jul 25 19:38:17 <Shiz> I'm just trying to rebuild the busybox package to be static.  Hence, did a bitbake -c menuconfig busybox to change to static.  Then tried bitbake -c clean busybox, followed by bitbake -c compile -f busybox.
Jul 25 19:38:31 <fray> Shiz, the clean removed your change
Jul 25 19:38:36 <fray> what you want is:
Jul 25 19:38:42 <fray> bitbake -c menuconfig busybox (make your changes)
Jul 25 19:38:48 <fray> bitbake -C compile busybox
Jul 25 19:39:07 <RP__> blloyd: I could have explicitly linked I guess but adding in that option was easier. I think there were some cases I needed to link, some where I didn't and I didn't want to go through and do manual markup
Jul 25 19:39:10 <fray> the -C is relatively new syntax and may not yet be documented
Jul 25 19:39:31 <Shiz> Terrific.  Will give a quick try.
Jul 25 19:40:20 <blloyd> it's not fray.  I'm looking at the bitbake manual now.  No mention of it under usage and syntax.
Jul 25 19:41:35 <Shiz> No such option -C in my bitbake.
Jul 25 19:42:03 <Shiz> I'm using the git yocto/poky.
Jul 25 19:42:09 <fray> use master bitbake, not denzil/poky version
Jul 25 19:42:35 <Shiz> Ah, okay.  Will do.
Jul 25 19:42:43 <fray> (spam)
Jul 25 19:42:43 <fray>   -c CMD, --cmd=CMD     Specify task to execute. Note that this only executes
Jul 25 19:42:43 <fray>                         the specified task for the providee and the packages
Jul 25 19:42:43 <fray>                         it depends on, i.e. 'compile' does not implicitly call
Jul 25 19:42:43 <fray>                         stage for the dependencies (IOW: use only if you know
Jul 25 19:42:43 <fray>                         what you are doing). Depending on the base.bbclass a
Jul 25 19:42:43 <fray>                         listtasks tasks is defined and will show available
Jul 25 19:42:44 <fray>                         tasks
Jul 25 19:42:44 <fray>   -C INVALIDATE_STAMP, --clear-stamp=INVALIDATE_STAMP
Jul 25 19:42:45 <fray>                         Invalidate the stamp for the specified cmd such as
Jul 25 19:42:45 <fray>                         'compile' and run the default task for the specified
Jul 25 19:42:46 <fray>                         target(s)
Jul 25 19:43:04 <Shiz> Yep, this is exactly what I need.
Jul 25 19:43:06 <fray> -c and -C work the same way, generally speaking.. but -C also (as it says) invalidates the stamp, so that the later options are run
Jul 25 20:10:53 <Shiz> fray, I switched to bitbake master, and using to build denzil/poky core-image-minimal.  It's saying that Nothing provides 'core-image-minimal'.
Jul 25 20:11:22 <fray> ten your config is messed up
Jul 25 20:11:35 <fray> be sure to replace the bitbake in poky w/ the master version...
Jul 25 20:11:59 <fray> (the poky version of bitbake used to be slightly different then the upstream version... so using poky - master is likely the right answer)
Jul 25 20:12:06 <Shiz> I just setup a symlink pointing to the bitbake master version.
Jul 25 20:12:24 <fray> not sure if that will work.. I've not used a symlink like that before
Jul 25 20:12:38 <Shiz> And I re-ran the oe-init-build-env script.
Jul 25 20:12:43 <fray> (I am using the master poky version of bitbake w/ the poky denzil version of the repo... so I know it works)
Jul 25 20:13:40 <Shiz> <nod>, I'm using the poky denzil version of the repo too.
Jul 25 20:14:28 <Shiz> I'll try avoiding the symlink.
Jul 25 20:16:08 <jwessel> RP__: Are there patches pending on the oe-core side to deal with the new white space warnings introduced in the bitbake master?
Jul 25 20:23:11 <RP__> jwessel: I thought we'd dealt with oe-core now?
Jul 25 20:23:27 <RP__> jwessel: its possible you're using some class we've missed though?
Jul 25 20:23:43 <jwessel> I have a branch off of it and perhaps something is out of date.
Jul 25 20:23:48 <jwessel> I'll hunt a bit more.
Jul 25 20:24:01 <RP__> jwessel: I don't see any warnings here, let me put it that way
Jul 25 20:24:03 <jwessel> It might also have to do with using the denzil branch.
Jul 25 20:24:11 <jwessel> + the bitbake master.
Jul 25 20:24:22 <RP__> jwessel: denzil doesn't have the whitespace fixups
Jul 25 20:24:46 <fray> (well denzil plus cherry-picked changes)
Jul 25 20:24:58 <fray> if there is a set in master we can cherry-pick back, that would help
Jul 25 20:25:02 <RP__> jwessel: you can comment out that warning and it will behave just as before, we just wanted to get those issues dealt with once and for all
Jul 25 20:25:26 <jwessel> Given that I have some in our code to I want them to all go away.
Jul 25 20:26:01 <jwessel> I have been burned by the append problem once already so I absolutely agree with the patch.  :-)
Jul 25 20:29:43 <jwessel> WARNING: Variable do_package_write_rpm_setscene contains tabs, please remove these (oe-core/meta/recipes-core/images/core-image-base.bb)
Jul 25 20:29:56 <jwessel> I suppose there is no way to get it to tell you the problem is actually in ./meta/classes/core-image.bbclass
Jul 25 20:33:08 <jwessel> Actually that is one I cannot find at all...
Jul 25 20:35:00 <jwessel> It appears to come from: meta/classes/populate_sdk_rpm.bbclass
Jul 25 20:35:05 <jwessel> Which definitely has tabs.
Jul 25 20:35:53 <jwessel> That is why I was asking if this was actually fixed or not, because I just assumed there were parallel commits in the oe side to match the bitbake side.
Jul 25 20:41:11 <khem> seebs: nostdlibc++ is OE specific gcc option
Jul 25 20:41:31 <khem> seebs: you should not hit it if you are using external toolchain anyway
Jul 25 20:41:48 <khem> since you are supposedly providing all the gcc runtime artifacts
Jul 25 20:44:04 <seebs> yah. Someone tried to build gcc-runtime, and I can't tell whether we need to provide something else it provides or just blacklist it.
Jul 25 20:45:10 <fray> assume provide it in the external cs toolchain is the right answer..
Jul 25 20:45:17 <fray> (provide and default provider that is)
Jul 25 20:45:21 <fray> 'er.. preferred provider
Jul 25 20:45:57 <blloyd> RP__: i get warnings about whitespace from the meta-intel branch.  Anyone working to get those resolved?
Jul 25 20:47:00 <RP__> blloyd: I'm sure they'll get fixed sooner or later, not sure if anyone has looked at it yet
Jul 25 20:47:54 <blloyd> so where should I send patches?  yocto mailing list or somewhere else?
Jul 25 20:47:59 <seebs> Well, the test case was "bitbake gcc-runtime". I am not sure whether I need to do anything but blacklist that.
Jul 25 20:49:08 <blloyd> so, does hob expose any way to clean things, or is it command line for that?
Jul 25 20:55:35 <RP__> blloyd: yocto mailing list
Jul 25 20:56:06 <RP__> seebs: with an external toolchain you should be able to assume its provided
Jul 25 20:56:24 <RP__> blloyd: hob doesn't no
Jul 25 20:56:46 <RP__> blloyd: in theory if you change something, its sstate checksum changes and it should rebuild anything needed
Jul 25 20:57:36 <fray> RP__ we're using blacklists to prevent people from building components we know are untested/unsupported.. (i.e. the OE toolchain, instead of using the WR provided toolchain)
Jul 25 20:57:47 <fray> (if the user decides they don't want to use our toolchain, then it reverts back to typical OE behavior)
Jul 25 20:58:22 <RP__> fray: that one is a good one to blacklist then
Jul 25 20:58:50 <blloyd> I've had the joy of a failure of the disk (filled) that left partial .o files.  :(  There's also the fun of having 20 some odd images in a folder that has a DO NOT DELETE THESE readme in it.
Jul 25 21:00:56 <bluelightning> blloyd: if you read that file what it means is don't delete files in that directory and expect all of them to be rebuilt and replaced automatically
Jul 25 21:01:05 <bluelightning> blloyd: doesn't mean you can never delete stuff in there at all
Jul 25 21:01:35 <bluelightning> more applicable to the kernel, bootloaders, etc. rather than images
Jul 25 21:03:30 <blloyd> had read it.  Was worried about state referencing them from some other location.  If that's not the case, rm works well.
Jul 25 21:03:30 * RP__ notes another vote for disk space warning in local.conf by default
Jul 25 21:03:47 <RP__> blloyd: images are safe, kernel is not
Jul 25 21:04:00 <bluelightning> blloyd: nothing ever refers to files in deploy/images, only symlinks within it
Jul 25 21:04:04 <bluelightning> FYI
Jul 25 21:04:35 <blloyd> RP__: so what should I do about kernel images in there?  They don't run on my machine, so I don't need them.
Jul 25 21:05:04 <bluelightning> blloyd: feel free to delete, but if you do need one of them again you'll have to force it to be redeployed as described in that file
Jul 25 21:05:24 <RP__> blloyd: well, if you run a build which wants something there and it isn't there you'll hit a failure. You delete things at your own risk
Jul 25 21:05:48 <RP__> blloyd: reality is the kernel is only wanted by some of the combination image types so if you don't build those you'll probably be ok
Jul 25 21:07:57 <blloyd> I do appreciate the hand holding.  Learning git (subversion makes so much more sense to me), yocto, bitbake, and kernel-3.0+ (I know 2.2, 2.4, and 2.6) is hurting my head.
Jul 25 21:09:23 <blloyd> syntax question: I read somewhere that += "somevalue" should be += " somevalue" as it doesn't place the space.  Is this true, as a lot of the files I am looking at don't bother with that leading space.
Jul 25 21:09:57 <jwessel> blloyd: += adds the space for you.
Jul 25 21:10:21 <jwessel> val = "stuff"
Jul 25 21:10:21 <jwessel> val += "more"
Jul 25 21:10:23 <sgw1> khem: you around?  I tracked down the perf issue to a change in wait.h that removed sys/resource.h, the only comment I can find is less then helpful: +       * posix/sys/wait.h: Include <sys/resource.h> only for waitid.  (it really removed that header not added it!)
Jul 25 21:10:27 <jwessel> val is now "stuff more"
Jul 25 21:10:59 <sgw> khem: I guess the only real solution right now is to patch it back in, thoughts?
Jul 25 21:11:06 <blloyd> thank you for the clarification.
Jul 25 21:14:00 <bluelightning> blloyd: that is true for _append however, that does not add a leading space
Jul 25 21:15:09 <blloyd> see, I read: just too much in too short of a time.  Maybe what I remembered was for _append.
Jul 25 22:26:31 <blloyd> I read somewhere about REQUIRES and INCLUDE, but can't find it again.  What exactly is the difference between these?  An index sure would be helpful (at the very least for the COMMAND REFERENCE documentation).
Jul 25 22:27:39 <bluelightning> blloyd: I guess you mean require and include
Jul 25 22:28:04 <bluelightning> include includes a file optionally (i.e. no error will be produced if the specified file doesn't exist)
Jul 25 22:28:42 <bluelightning> require includes the file and if it does not exist, produces an error
Jul 26 00:55:57 <sgw> khem: around?  are you working on the eglibc-locale-locale issue still?
**** ENDING LOGGING AT Thu Jul 26 02:59:58 2012

**** BEGIN LOGGING AT Thu Jul 26 02:59:58 2012
Jul 26 06:42:41 <tavish3> hi, how do i change the default kernel command line for arm build? i changed the ones in a patch but it doesnt seem to reflect in the final build
Jul 26 06:44:56 <tavish3> oh, i have to recompile the imx-bootlets recipe
Jul 26 09:06:01 <bluelightning> morning all
Jul 26 09:16:16 <likewise> gm
Jul 26 11:40:29 <zib> | NOTE: make -e MAKEFLAGS= | Makefile:16: *** missing separator (did you mean TAB instead of 8 spaces?).  Stop. | ERROR: oe_runmake failed
Jul 26 11:40:56 <zib> Is there any standard reasons for this error during a do_compile of a package?
Jul 26 11:57:31 <hrw> hi
Jul 26 11:57:42 <hrw> Connecting to downloads.yoctoproject.org (downloads.yoctoproject.org)|140.211.169.118|:80... failed: No route to host. - any idea why?
Jul 26 11:58:08 <JaMa> halstead: you're probably right person to ping ^
Jul 26 12:36:33 <halstead> JaMa Thanks for the ping.
Jul 26 12:37:22 <hrw> halstead: thanks for working on it
Jul 26 12:39:39 <halstead> hrw, It's back online.
Jul 26 12:39:54 <hrw> thanks halstead
Jul 26 12:40:08 <halstead> There were nagios alerts but I didn't hear them.
Jul 26 12:40:18 <hrw> now I can add more tasks to jenkins
Jul 26 13:06:51 <hrw> have a nice day
Jul 26 14:06:19 <blloyd> what's the easiest way to find what is actually used to build a package?  I'm seeing a claim of i586 for the system and yet i686 instructions are in the end product.
Jul 26 14:26:08 <sgw> fray: around?
Jul 26 15:31:08 <kergoth> ooh, RP__ just implemented the sstate dir structure mentor is using, but without the sad moving and symlinking of the archives
Jul 26 15:31:24 * kergoth tries it out
Jul 26 15:43:26 <kergoth> RP__: the third patch in that series doesn't seem to apply, here. 3 rejected patch hunks
Jul 26 15:44:09 <RP__> kergoth: http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=rpurdie/t1 you probably need my other sstate.bbclass patch
Jul 26 15:44:17 <RP__> kergoth: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t1&id=cedb0c39f82f43750567673c2a99ae75dc7bdbf9
Jul 26 15:44:53 <RP__> kergoth: That one enables generic path components, the second one adds in an lsb-release one
Jul 26 15:44:54 <kergoth> ah, k, thanks
Jul 26 15:45:23 <RP__> kergoth: dealing with two problems, halstead should appreciate the first one :)
Jul 26 15:45:34 * kergoth nods
Jul 26 16:00:31 <kergoth> RP__: minor gripe, the set of NATIVELSBSTRING in oe_import is a bit odd. at least should probably be moved to the ConfigParsed event handler after the oe_import call
Jul 26 16:01:28 <RP__> kergoth: true
Jul 26 16:05:43 <kergoth> hmm, this might be a minor pain to use with centos/rhel if i want the user to not have to postprocess their sstate_dir. specifically, i'd have to add a *lot* of subdirs to my sstate mirrors for all the compatible hosts. centos 5.4/5.5/5.6/5.7/5.8, rhel5.x.. this is why i was using the lsb distro identifier adjustment hook, to cheat and just make them all not just read from but also write to the same place
Jul 26 16:05:49 * kergoth thinks
Jul 26 16:06:44 <kergoth> http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/tree/conf/distro/include/sstate.inc
Jul 26 16:06:55 * kergoth wanders off to run some errands and will dig into this when he gets back
Jul 26 16:09:04 <RP__> kergoth: I did leave that hook support ni
Jul 26 16:22:09 <msm> who maintains owl-video?
Jul 26 16:24:43 <bluelightning> msm: meta-yocto/conf/distro/include/maintainers.inc says Valentin Popa
Jul 26 16:26:29 <msm> is that just the recipe itself or the project?
Jul 26 16:27:37 <bluelightning> msm: well, the recipe... as far as the piece of software is concerned I'm not sure anyone is actively maintaining it
Jul 26 16:28:10 <msm> that's sort of what i though
Jul 26 16:28:15 <msm> so I should just send this patch in
Jul 26 16:28:15 <msm> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=mattsm/master&id=f719b34d5f33f4d1ef1f97fc13b5b5d3d4366ce1
Jul 26 16:28:23 <msm> im not really sure it's correct or ideal
Jul 26 16:31:05 <msm> i guess i'll send it in and see what others say
Jul 26 16:31:29 <bluelightning> msm: yeah that's what I'd suggest
Jul 26 16:47:36 <likewise> msm: I noticed the denzil branch on fsl-ppc is not fully in sync with denzil poky. Two bbappends are using the wrong version, failing any build.
Jul 26 16:48:58 <likewise> msm:  recipes-append/libxml/libxml2_2.7.8.bbappend |    3 +++  recipes-append/libxml/libxml2_2.8.0.bbappend |    3 ---    recipes-append/netbase/netbase_4.47.bbappend |   10 ++++++++++   recipes-append/netbase/netbase_5.0.bbappend  |   10 ----------
Jul 26 16:49:22 <Crofton|work> darknighte, ping
Jul 26 16:49:35 <likewise> Crofton|work: working on Zynq?
Jul 26 16:49:55 <Crofton|work> :)
Jul 26 16:50:04 <darknighte> Crofton|work: yo
Jul 26 16:50:07 <Crofton|work> yes, but trying not to be to obvious
Jul 26 16:50:16 <likewise> Crofton|work: nice. :-) How's the X BSP?
Jul 26 16:50:23 <Crofton|work> darknighte, so does this webex stuff work on xilinx
Jul 26 16:50:38 <darknighte> um, on xilinx?
Jul 26 16:50:46 <Crofton|work> jesus
Jul 26 16:50:48 <Crofton|work> linux
Jul 26 16:50:53 * Crofton|work is addled
Jul 26 16:51:02 * darknighte noticed
Jul 26 16:51:10 <darknighte> I think it requires java, so YMMV
Jul 26 16:51:54 <darknighte> crap, you know, I moved my work laptop to linux too, so I better check it.
Jul 26 16:52:03 <Crofton|work> hmm
Jul 26 16:52:11 <Crofton|work> can we test?
Jul 26 16:52:22 <darknighte> sure
Jul 26 16:52:54 <darknighte> I just started the meeting.  Feel free to join
Jul 26 16:53:17 <darknighte> I'll start the audio conference now
Jul 26 16:55:31 <Crofton> how do I enable java?
Jul 26 16:55:53 <Bagder> darknighte: did you? it claims no chair person for me...
Jul 26 16:55:55 <Crofton> in firefox
Jul 26 16:56:02 <Bagder> ah now
Jul 26 16:56:26 <Crofton> damn it, I am an embedded developer not a manager
Jul 26 16:57:13 <darknighte> Crofton, seriously?
Jul 26 16:58:27 <Crofton> I think no javs, no no pugin
Jul 26 16:59:30 <likewise> Crofton: you have to keep up with the cool kids. Install Java :-]
Jul 26 16:59:50 <Crofton> openjdk is installed
Jul 26 17:00:08 <darknighte> Crofton: did you just trying opening the link?
Jul 26 17:00:34 <Crofton> yeah
Jul 26 17:00:38 <Crofton> it is whining no java
Jul 26 17:00:49 <Crofton> and when I go tools plugins I seeno jav
Jul 26 17:01:00 <Crofton> I am use the "telephone"
Jul 26 17:01:06 <likewise> Crofton: http://gotoelango.blogspot.nl/2010/05/webex-on-ubuntu-1004.html
Jul 26 17:01:23 <likewise> Crofton: WebEx might work on Sun's ^W Oracle's Java only.
Jul 26 17:01:40 <Crofton> what is this "ubuntu" you speak off :)
Jul 26 17:02:04 <likewise> Crofton: Well fix it for your own hat. :)
Jul 26 17:05:10 <blloyd> anyone have any suggestions for why when I do a bitbake -c menuconfig linux-yocto the window comes up with ^@ and trash in gnome terminal but if I run make menuconfig directly it works in gnome terminal.
Jul 26 17:12:02 <Crofton|work> do we have a pdf of slides for the ab meeting?
Jul 26 17:12:12 <Crofton|work> hmm wait, I have this windows machine
Jul 26 17:20:21 <Crofton|work> my windows machine just says connecting and never gets to anything like a webex
Jul 26 17:20:29 <Crofton|work> darknighte, shut up!
Jul 26 17:20:41 <darknighte> Crofton|work: what?
Jul 26 17:20:50 <Crofton|work> dont confuse things :)
Jul 26 17:21:05 <Crofton|work> this webex stuff isnt working from my windows machine
Jul 26 17:21:08 <Crofton|work> weird
Jul 26 17:21:16 <darknighte> heh... you're not having a good day.
Jul 26 17:22:03 <Crofton|work> heh
Jul 26 17:23:28 <Crofton|work> is there a meeting password
Jul 26 17:23:48 <msm> likewise: what tree are you using?
Jul 26 17:24:15 <darknighte> it works fine from my iPad, Linux laptop, AND my windows VM.
Jul 26 17:24:16 <darknighte> ;)
Jul 26 17:24:27 <darknighte> yes, YoctoAB.
Jul 26 17:25:24 <pidge> status of 1.1.2?
Jul 26 17:26:13 <Crofton|work> #fail
Jul 26 17:27:31 <likewise> msm: git://git.yoctoproject.org/meta-fsl-ppc
Jul 26 17:27:56 <likewise> msm: against git://git.yoctoproject.org/poky.git
Jul 26 17:28:03 <likewise> msm: both on denzil tag
Jul 26 17:29:19 <msm> likewise: i've done builds of these
Jul 26 17:29:27 <msm> likewise: you might try my poky branch
Jul 26 17:29:28 <msm> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mattsm/denzil
Jul 26 17:30:49 <msm> but even the denzil proper should work
Jul 26 17:30:58 <msm> are you sure your tree does not have extra files laying aorund?
Jul 26 17:31:01 <msm> your meta-fsl-ppc
Jul 26 17:31:36 <likewise> msm: yes I'm sure, clean checkout. same for poky
Jul 26 17:31:51 <likewise> msm: let me point you to the denzil tree files for both and show the mismatch.
Jul 26 17:33:35 <msm> meta-yocto        = "denzil:15392b6fc248a86b29761cad963cc9c909051eee"
Jul 26 17:33:36 <msm> meta-fsl-ppc      = "denzil:0c2324cd1f5de04cb57bd7a03faa7c76df409ed3"
Jul 26 17:33:49 <msm> those build for me w/o complaining about bbappends
Jul 26 17:35:36 <likewise> msm: then I must have something messed up here.
Jul 26 17:35:58 <msm> can you run git clean in your meta-fsl-ppc?
Jul 26 17:37:48 <likewise> msm: I messed up. Somehow I have gotten in the situation where I have a local branch denzil not actually tracking remote denzil...
Jul 26 17:38:19 <likewise> msm: thanks for your time.
Jul 26 17:39:10 <msm> likewise: im about to start cleaning up the denzil branch
Jul 26 17:39:21 <msm> and "suggesting" patches for poky denzil branch
Jul 26 17:47:54 <likewise> msm: ok, I just proposed the "bounds.h" fix to Saul for poky denzil. I'm just hitting it. It's non-fsl related.
Jul 26 17:48:45 <likewise> ttyl, bye all
Jul 26 17:50:00 <msm> like|logging: its no saul who picks patch for denzil
Jul 26 17:50:22 <msm> like|logging: its zenlinux (Scott Garman)
Jul 26 17:50:40 <like|logging> msm: ok thanks, I cannot keep up with all the ml's lately.
Jul 26 17:50:42 <zenlinux> hello
Jul 26 17:50:49 <like|logging> zenlinux: hi
Jul 26 17:51:26 <zenlinux> just thought I'd poke my head up since I heard my name
Jul 26 17:52:01 <like|logging> zenlinux: msm explained you are the person picking patches for Denzil inclusion. I didn't know yet.
Jul 26 17:52:41 <zenlinux> yep, I'm the 1.2.x release maintainer. Do let me know if you're running into Denzil issues and have some fixes you'd like merged
Jul 26 17:53:15 <zenlinux> We won't be able to accept anything that breaks compatibility, but bugfixes will be seriously considered.
Jul 26 17:54:13 <like|logging> zenlinux: what is the proper way to request a merge / cherry pick?
Jul 26 17:54:52 <zenlinux> like|logging, generally submit a pull request to the oe-core mailing list, and mention denzil in the cover letter's subject
Jul 26 17:57:30 <like|logging> zenlinux: thanks, will do so tomorrow. gotta run. cya.
Jul 26 17:57:56 <zenlinux> laters
Jul 26 18:17:09 <kergoth> RP__: you left it in the function, but there's no variable or mechanism by which you can get it passed into your distro_identifier() call that's in base.bbclass. I'd suggest adding a variable for it, similar to http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/tree/classes/sstate-reuse.bbclass#n23
Jul 26 18:18:02 <kergoth> RP__: alternatively, it's easy enough to add a custom ConfigParsed handler to setVar() it to an alternative instead of using a var, so what's there isn't bad, just a question of the semantics by which one utilizes the hook
Jul 26 18:18:22 <kergoth> RP__: doesn't matter much to me, i don't mind using a configparsed handler to override the var
Jul 26 18:21:55 * kergoth tests that out
Jul 26 18:36:56 <kergoth> RP__: thought about adding a default SSTATE_MIRRORS to let it pick up the files in the previous locations before the sstate reorg? course, cleansstate could interact with that, not removing the 'mirror' sstate archives..
Jul 26 18:37:00 * kergoth thinks
Jul 26 18:37:41 <kergoth> oh, wait.. /me rereads sstate.bbclass
Jul 26 18:42:57 <joshmarinacci> hi saul
Jul 26 18:50:58 <sgw> joshmarinacci: Hi back
Jul 26 18:51:37 <sgw> joshmarinacci: did you get your fetching issue resolved?
Jul 26 18:51:50 <joshmarinacci> it seems so. i have no idea what the issue was.
Jul 26 18:52:00 <joshmarinacci> it's now downloading the world successfully
Jul 26 18:52:11 <sgw> joshmarinacci: great
Jul 26 18:52:19 <joshmarinacci> i'll just let it run for an hour and give you a progress update. sorry to be such a bother. :)
Jul 26 18:52:23 <blloyd> can anyone point me to documention for bitbake?  Like how to enable more logging and where log files go.  It does stuff for me, I don't know what, but I don't like the end product and can't figure out where things are going wrong.
Jul 26 18:52:37 <joshmarinacci> btw. what does bitbake -n do?
Jul 26 18:52:48 <sgw> joshmarinacci: no bother at all, we want to see people succeed and it sucks when you into problems
Jul 26 18:53:13 <sgw> joshmarinacci: the -n is kind of like make -n , dry run, will list all the tasks that it will execute
Jul 26 18:53:19 <joshmarinacci> wow. gcc-cross-initial is large.
Jul 26 18:54:04 <sgw> joshmarinacci: if your on master then it's doing a git clone of the gcc repo, yes, kind of big
Jul 26 18:57:50 <joshmarinacci> k. heading to the hardware store. ttyl
Jul 26 18:58:19 <joshmarinacci> need a new hacksaw for the aluminum extrusions project
Jul 26 19:01:16 <pinskia> GCC sources are large because of java class files ...
Jul 26 19:01:19 <RP__> kergoth: We might as well add a variable for the distro_identifier() call. I'd meant to go back and do that once it was working. The code probably needs a few tweaks here and there but I think the general principle is heading the right way which is what I was trying to do
Jul 26 19:01:51 * kergoth nods
Jul 26 19:02:07 <pinskia> 166M in libjava alone
Jul 26 19:02:39 <pinskia> another 165M in the testsuite
Jul 26 19:02:47 <kergoth> RP__: the slight abuse of BB_HASHFILENAME isn't the prettiest, but it's far less ugly than the alternative. overall, nicely done
Jul 26 19:04:11 <chackal_sjc> guys
Jul 26 19:04:17 <chackal_sjc> using tag in git is not working
Jul 26 19:04:33 <chackal_sjc> im using like this: git://repo.git;tag=x
Jul 26 19:04:39 <chackal_sjc> it suppose to work, right?
Jul 26 19:08:47 <RP__> kergoth: Yes, I wasn't happy about that... I couldn't think of any other sensible alternative that didn't involve API changes :/
Jul 26 19:09:08 * kergoth nods, agreed
Jul 26 19:09:36 <RP__> kergoth: three steps forward, one step back or something like that :)
Jul 26 19:10:08 <RP__> kergoth: The sstate APIs are still a bit rough and ready at the moment :/
Jul 26 19:10:45 <kergoth> heh, baby steps
Jul 26 19:10:47 <kergoth> we'll get there
Jul 26 22:37:22 <blloyd> anyone tried to use the menuconfig under yocto recently?
Jul 26 22:37:50 <JaMa|Off> yes
Jul 26 22:38:40 <blloyd> anything special needed to set it up?  I get an unusable ui any time I try a bitbake -c menuconfig linux-yocto
Jul 26 22:40:42 <JaMa|Off> looking like this? http://lists.linuxtogo.org/pipermail/openembedded-core/2012-June/024199.html
Jul 26 22:40:47 <JaMa|Off> then reply to that thread
Jul 26 22:42:19 <blloyd> thank you.  Did you know about it or what should I have searched for?
Jul 26 22:43:22 <bluelightning> blloyd: JaMa|Off is the one who replied to the original poster
Jul 26 22:56:16 <blloyd> I've subscribed to yocto and yocto-bsp already.  What other lists are good looks like oe-core is another, so any others?
Jul 26 23:03:18 <blloyd> so, how do I reply to a message I never got myself?
Jul 26 23:13:24 <blloyd> what's the difference between the denzil branch and the master?  As a really green user, which should I be using?
Jul 26 23:21:33 <halstead> blloyd, I think denzil will only receive bug fixes at this point so it's more stable. Master is for Yocto project 1.3 and is receiving new feature work.
Jul 27 02:36:05 <blloyd> Well, I've finally figured out how I can get a CMOV operation in a program compiled for the 586.  embedded assembler.  What I haven't been able to figure out is how exactly is the .config file generated.  How can I find all the 'snippets' that make up the .config file and what pulls them in?  Obviously, there is one somewhere that adds a CONFIG_X86_CMOV=y to the file.
**** ENDING LOGGING AT Fri Jul 27 02:59:58 2012

**** BEGIN LOGGING AT Fri Jul 27 02:59:59 2012
Jul 27 03:24:34 <blloyd> is there a way to undefine a variable using the yocto kernel configuration system?
Jul 27 03:38:21 <thaytan> sgw: ping
Jul 27 03:43:23 <sgw> thaytan: pong, good evening
Jul 27 03:45:11 <thaytan> sgw: did I pick the right nick?
Jul 27 03:45:20 <thaytan> I'm doing a yocto build for my rpi atm :)
Jul 27 03:45:57 <sgw> thaytan: Yes, you did, this is indeed Saul.
Jul 27 03:46:41 <thaytan> good stuff
Jul 27 03:46:42 <sgw> thaytan: how's the build going so far, Ok I hope, like I said, mine is coming in September.
Jul 27 03:47:02 <thaytan> sgw: pretty seamless
Jul 27 03:47:24 <thaytan> the only problem I had was the build not wanting to start because it couldn't hit the test git:// url from inside the corporate network
Jul 27 03:47:50 <sgw> thaytan: some pretty good improvements since the wild west days!
Jul 27 03:48:11 <thaytan> yes, it's a nice clean file layout
Jul 27 03:48:23 <thaytan> and nice improvements to the build itself
Jul 27 03:49:41 <sgw> You can disable that test, or a get a simple script/program to possibly use socks (if you have that).
Jul 27 03:50:04 <thaytan> I just disabled the test for now
Jul 27 03:50:30 <thaytan> so far, it didn't actually need any git checkouts for the rpi build
Jul 27 03:53:04 <sgw> since your using poky with meta-yocto and meta-rpi, I think the PREMIRRORS might kick in enough to get you tarballs of the gits
Jul 27 03:55:55 <thaytan> ahr, that's a nice trick too
Jul 27 03:56:35 <sgw> yup, it smooths out some of the hiccups when upstreams go away
Jul 27 03:58:45 <zubraj> I started compiling Yocto for qemuX86, but its failing with some error status...
Jul 27 03:59:14 <sgw> zubraj: can you be more specific, or paste the failure someplace
Jul 27 03:59:28 <zubraj> the error messages are
Jul 27 03:59:36 <zubraj> make: *** [compat/obstack.o] Error 1 | make: *** Waiting for unfinished jobs.... | ERROR: oe_runmake failed NOTE: package git-native-1.7.7-r2: task do_compile: Failed ERROR: Task 272 (virtual:native:/home/lukup/Desktop/poky-denzil-7.0.1/meta/recipes-devtools/git/git_1.7.7.bb, do_compile) failed with exit code '1' NOTE: Tasks Summary: Attempted 247 tasks of which 82 didn't need to be rerun and 2 failed.  Summary: 2 tasks failed:   /ho
Jul 27 04:01:25 <sgw> zubraj: so your git-native compilation task is failing, you should have a log file in the tmp/work/x86-64-linux/git-native-1.7.7-r2/temp/log.do_compile, please paste your favorite pastebin type of site.
Jul 27 04:02:04 <zubraj> does that mean that it has stopped from generating a root and kernel image..
Jul 27 04:03:14 <sgw> zubraj: yes, git-native is part of the dependency chain and it stop, what Distro are you building on?
Jul 27 04:03:40 <zubraj> ubuntu 10.04
Jul 27 04:04:17 <sgw> And which yocto version? Master or ?
Jul 27 04:05:58 <sgw> 10.04.4 LTS is a tested distro, so it should work if you have all the correct packages installed.
Jul 27 04:08:00 <zubraj> I don't know exactly i have a downloaded a source code  "poky-denzil-7.0" as specified  in the video by scoot garman
Jul 27 04:08:13 <zubraj> i mean Scott Garmen
Jul 27 04:08:56 <zubraj> i have git installed on Ubuntu..
Jul 27 04:12:09 <sgw> zubraj: the git installed on Ubuntu may not have all the support needed which is why we build a git-native to ensure the correct version of the native tools are available, it would be interesting to see your compile log to try and figure out what failed.
Jul 27 04:13:21 * thaytan bets hard disk full
Jul 27 04:13:59 * sgw thinks thaytan has been there before and hopes he has enough free disk space
Jul 27 04:14:32 <zubraj> maybe .. cause there was a warning yesterday less memory , how much of free space do i need for this compilation
Jul 27 04:14:40 <thaytan> sgw: 16G free before I need to start deleting stuff ;)
Jul 27 04:14:55 <thaytan> zubraj: did you check the compile log file sgw mentioned?
Jul 27 04:15:07 <sgw> zubraj: git-native it pretty early on and not know to fail very often, so disk space is possibility you need 100G or so unless you use the INHERIT += "rm_work"
Jul 27 04:15:28 <zubraj> whcih compile log  where is it I'll send it..
Jul 27 04:15:39 <sgw> the build appliance is configured with 40G of free space for a sato build and uses rm_work
Jul 27 04:15:50 <zubraj> the one whcih comes up ion terminal or ther's something specific
Jul 27 04:16:06 <sgw> zubraj: I listed it above from the git-native temp directory
Jul 27 04:16:35 <sgw> zubraj: are you running on a x86 or x86-64 machine and I will give you an accurate path
Jul 27 04:19:09 <zubraj> it is x86-64
Jul 27 04:20:03 <sgw> tmp/work/x86_64-linux/git-native-1.7.7-r2/temp/log.do_compile is the file I am looking for
Jul 27 04:24:17 <zubraj> and how do i send it ...
Jul 27 04:25:06 <sgw> have you ever used pastebin.com before?  you can copy and paste it there and then paste the url here
Jul 27 04:25:24 <zubraj> ok
Jul 27 04:25:37 <sgw> zubraj: did you check if you where low on disk space?
Jul 27 04:26:17 <zubraj> yes disk space is very low ..
Jul 27 04:27:03 <sgw> zubraj that might be your problem then, you need at least 40G free and you should add the line INHERIT += "rm_work" to your local.conf file
Jul 27 04:27:27 <blloyd> I found the 'easy' way to recover from that is to delete tmp and sstate-cache before going again.  And free at least 50G before doing SATO, 35 for minimal.
Jul 27 04:27:57 <blloyd> (I died with the 40GB)
Jul 27 04:28:32 <sgw> blloyd: that sounds about right if you have rm_work enabled, I have the buildappliance image set up with 45G (4 of which is the a pre-loaded DL_DIR)
Jul 27 04:28:47 <zubraj> the pastebin.com doesn't open up , I guess there's some problem  ... newayz where do i have to add this line  "INHERIT += "rm_work"" i mean whcih part of local.conf
Jul 27 04:29:03 <sgw> zubraj: at the end
Jul 27 04:29:23 <sgw> http://pastebin.com/ no problem for me here
Jul 27 04:29:43 <blloyd> seems to be very forgiving.  I put it near the top without issues.
Jul 27 04:30:11 <sgw> it can go anywhere, there is no section in local.conf
Jul 27 04:30:15 <zubraj> can i use github .com
Jul 27 04:30:23 <sgw> I just stick all my changes at the bottom
Jul 27 04:31:13 <blloyd> I need a bigger disk.  Oh, the days when a 1GB disk would be "more disk than you ever need".
Jul 27 04:31:38 <sgw> 1GB, heck 32Meg was huge
Jul 27 04:32:03 <zubraj> ok then i'll try with cleaning some disk space and recompiling..
Jul 27 04:32:06 <sgw> now a 2Tb drive gets filled, but then I am doing all sorts of builds all the time.
Jul 27 04:32:20 <blloyd> (1994, local computer shop didn't want to sell it cause I was just wasting money.  You'll never need that much...)
Jul 27 04:32:30 <thaytan> zubraj: try pastebin.ca
Jul 27 04:35:56 <zubraj> sorry idbin.ca not working maybe it is not available in my country..
Jul 27 04:36:14 <blloyd> http://codepad.org/
Jul 27 04:37:29 <zubraj> its working.. here are the log messages
Jul 27 04:38:41 <blloyd> You should get a very short url from the site you can paste here for us to look at them.
Jul 27 04:43:42 <thaytan> *sigh*
Jul 27 04:43:48 * thaytan still has money on disk full
Jul 27 04:44:32 <sgw> thaytan: based on what he said, I think your right, I also have to call it a night, I have been working on some clean-ups that I will post shortly.
Jul 27 04:44:50 <blloyd> back in a min.  Crashed my cd writer.  :(
Jul 27 04:44:52 <thaytan> sgw: night!
Jul 27 04:45:01 <zubraj> here's the log message
Jul 27 04:45:01 <thaytan> sgw: thanks for the preso today :)
Jul 27 04:45:04 <zubraj> http://codepad.org/LT5DUIHy
Jul 27 04:46:09 <thaytan> hooray! that's completely useless :)
Jul 27 04:46:19 <sgw> zubraj: is that from the console log or the log.do_compile (pretty usless)
Jul 27 04:46:47 <zubraj> it s from log.do_compile
Jul 27 04:47:07 <sgw> zubraj: you ran out of space as thaytan believes
Jul 27 04:47:17 <sgw> your df will show that.
Jul 27 04:47:48 <thaytan> hooray! what did I win? free stuff?
Jul 27 04:48:00 <zubraj> I guess thaytan is right as of now I don't have enough even to save a txt file also..
Jul 27 04:48:31 <zubraj> I'll fix that and try  .. thanks for the help..
Jul 27 04:48:40 <sgw> thaytan: yocto running on an rpi!
Jul 27 04:49:42 <thaytan> sgw: \o/
Jul 27 04:51:48 <blloyd> what's an rpi?
Jul 27 04:52:55 <sgw> Raspberry Pi
Jul 27 04:53:24 * sgw is really going now , back in the morning.
Jul 27 04:54:08 <thaytan> sgw: cya :)
Jul 27 07:20:24 <blloyd> documentation is driving me batty.  I can read it, but then when trying to refer back I can't find it.  I know one place discussing kernel configuration (I can point to 3 that don't have what I want) gave what to do to invalidate state.  What's the command to invalidatestate before running menuconfig?
Jul 27 07:34:08 <blloyd> anyone available to help with kernel configuration headaches?
Jul 27 07:37:07 <sgw> blloyd: I am back again, what's up?
Jul 27 07:37:44 <sgw> I am not a kernel guy but may be-able to summons one!, nitink you around?
Jul 27 07:38:39 <blloyd> It should be so easy.  It's driving me batty.  I have a .config that is perfect except it has 2 lines I don't want.  I have no idea what is pulling them in, and I don't know how to remove them.
Jul 27 07:39:24 <blloyd> needless to say, I can't use menuconfig as one of the two isn't exposed in menuconfig.  I can search and see it, but no edit location.
Jul 27 07:39:45 <blloyd> Manual editing of the .config of course gets overriden.
Jul 27 07:40:24 <sgw> blloyd: which base kernel recipe are you using?
Jul 27 07:40:51 <blloyd> linux-yocto-3.2
Jul 27 07:40:58 <JaMa|Off> sgw: 2,5 hours of sleep is way too short, and starting day with kernel defconfig is even worse :)
Jul 27 07:41:40 <sgw> hmm, need to stock up my jelly beans!
Jul 27 07:42:11 <sgw> JaMa|Wrk: you want to take this on, fine with me!
Jul 27 07:42:26 <JaMa|Wrk> not really I'm not using linux-yocto
Jul 27 07:42:38 <blloyd> what are you using JaMa?
Jul 27 07:42:40 <JaMa|Wrk> but jelly beans are fine with me
Jul 27 07:42:44 <sgw> blloyd: do you have a .bbappend file or how are you modifiy the config?
Jul 27 07:42:52 <blloyd> .bbappend
Jul 27 07:42:58 <JaMa|Wrk> blloyd: good old linux.inc based recipes
Jul 27 07:43:07 <sgw> JaMa|Wrk: I do sugar not caffeine
Jul 27 07:43:22 <sgw> blloyd: can you pastebin it?
Jul 27 07:45:43 <blloyd> http://pastebin.com/nwn1kWBU
Jul 27 07:47:57 <blloyd> and the cfg file is at http://pastebin.com/KE8TjHw0
Jul 27 07:48:35 <sgw> yeah, you reach my limit as user space guy!  nitink or zeddii should be able to help you, zeddii will be on line in 6+ hours not sure where you are
Jul 27 07:48:55 <blloyd> when it builds, I get an uncommented CONFIG_X86_32 and CONFIG_X86_CMOV.
Jul 27 07:49:47 <blloyd> why oh why do I have to hit all the corner cases?
Jul 27 07:50:29 <blloyd> guess I'll go get some sleep and try to ping nitink in a few hours.
Jul 27 07:51:10 <blloyd> (or zeddii)
Jul 27 07:51:13 <sgw> blloyd: ok also check with zeddii he is the maintainer of that code and should help.
Jul 27 07:51:18 <blloyd> thanks for looking sgw.
Jul 27 07:51:33 <sgw> sorry I can't be more helpful in that space.
Jul 27 07:53:22 <blloyd> did what you could.  The documentation definitely needs to be better.  It's annoying there are multiple places that discuss kernel development, including setting up two repositories.  Only one that actually discusses using those 2 repositories (I read it once), but of course that one isn't easy to find, even if you know it exists somewhere.
Jul 27 08:05:55 <nitink> bollyd: hi
Jul 27 08:11:59 <nitink> blloyd: ping me when you are online
Jul 27 08:14:30 <likewise> gm
Jul 27 08:21:22 <bluelightning> morning likewise, all
Jul 27 08:52:55 <florian> hi bluelightning
Jul 27 08:53:27 <bluelightning> hi florian
Jul 27 12:16:19 <gotan> hi
Jul 27 12:16:43 <gotan> question: is there a recipie that creates a multiple partition image?
Jul 27 12:16:58 <gotan> i want something like /boot /root /data
Jul 27 12:57:44 <gotan> hi again - missed answer to last question
Jul 27 12:57:51 <gotan> question - are there poky specific variables for creating a multiple partition target image?
Jul 27 13:08:18 <bluelightning> gotan: it's something that's being worked on; at the moment you have to kind of create something yourself
Jul 27 13:08:43 <bluelightning> gotan: but you can look at meta/classes/bootimg.bbclass for an example I think
Jul 27 13:09:11 <bluelightning> gotan: actually, meta/classes/boot-directdisk.bbclass
Jul 27 13:16:06 <gotan> @bluelightning:  i seem to remember routerstationpro has some parition settings.
Jul 27 14:36:03 <likewise> Hmmm, we still use quilt for patches in the SRC_URI, right?
Jul 27 14:36:22 <kergoth> generally yes, though a couple cases override this using PATCHTOOL
Jul 27 14:36:38 <kergoth> (e.g. you can choose to use git apply/am or just 'patch')
Jul 27 14:37:59 <likewise> kergoth: thanks. This is a kernel that I'm building, let's see.
Jul 27 14:45:52 <blloyd2> ping zeddii
Jul 27 14:59:38 <zeddii> blloyd2 pong
Jul 27 15:03:53 <blloyd2> if you look up there are two urls from me.  Was told you may be able to help with my understanding of the kernel build system.
Jul 27 15:05:24 <blloyd2> (me also being blloyd)
Jul 27 15:05:31 <zeddii> I have the URLs, but rather than re-reading the conversation, can you restate the question for me :)
Jul 27 15:16:07 <blloyd2> sure.  Sorry about long delay.  Anyways, I am trying to remove two lines from .config that I don't know where they come from.  How do I go about it?
Jul 27 15:17:06 <zeddii> what two lines ?
Jul 27 15:17:10 <zeddii> i.e. which options ?
Jul 27 15:17:21 <blloyd2> CONFIG_X86_CMOV and CONFIG_X86_32
Jul 27 15:17:33 <zeddii> if another Kconfig is selecting them, then you need to find that Kconfig and turn it off.
Jul 27 15:17:57 <zeddii> in the fragment you posted, what you have wouldn't turn off the CONFIG_X86_32
Jul 27 15:18:05 <zeddii> you need # CONFIG_X86_32 is not set
Jul 27 15:18:18 <zeddii> for it to have a chance of working, but it can still be clobbered by Kconfig itself.
Jul 27 15:18:23 <blloyd2> oh, that turns it off?
Jul 27 15:18:30 <zeddii> correct.
Jul 27 15:18:51 <zeddii> spacing is also important "# CONFIG_X86_32 is not set" literally.
Jul 27 15:18:59 <zeddii> those spaces, that capitalization.
Jul 27 15:20:00 <blloyd2> seen that line often enough.  Put it in.
Jul 27 15:20:43 <zeddii> ./arch/x86/Kconfig.cpu is triggering X86_CMOV, since it is def_bool y
Jul 27 15:20:57 <zeddii> so the same thing as the other option should turn it off.
Jul 27 15:21:14 <blloyd2> did both at same time hoping it would work.  :)
Jul 27 15:21:27 <zeddii> I can try configuring it here to see.
Jul 27 15:22:38 <blloyd2> I was just missing a little understanding of the kernel configuration system.  3 documents talk about it, but more do this and it works.  No explanation I have found of how to find things, or where to look when things go wrong.
Jul 27 15:23:16 <blloyd2> (and of course, all examples are for setting items, it's not intuitive that unset is available too)
Jul 27 15:23:27 <zeddii> we are adding some quick start items to 1.3 to (attempt) to adress this.
Jul 27 15:23:37 <zeddii> we have a CONFIG_SMP example buried in the docs.
Jul 27 15:23:50 <zeddii> it used to set CONFIG_SMP=y and then we made it the default, so now it turns it off :)
Jul 27 15:23:53 <blloyd2> for turning it on.  Not off that I saw.
Jul 27 15:24:07 <zeddii> that's probably in the 1.3 docs or pending somewhere.
Jul 27 15:24:12 <blloyd2> goodie.
Jul 27 15:24:58 <zeddii> just so I'm clear, you were trying the "is not set" and it didn't work ? I don't want to fire up a build if you are good now :)
Jul 27 15:25:07 <zeddii> IRC is sometimes a random medium :P
Jul 27 15:25:33 <blloyd2> nothing indicates how smart the tool is, and how much parsing it does.  After all # CONFIG_X86_32=y would turn it off (assuming no uncommented version) when done directly in .config.
Jul 27 15:26:09 <zeddii> the tools themselves aren't doing anything with the config files, they are fed directly to lkc
Jul 27 15:26:21 <blloyd2> I'm testing now.  Takes a min to build zeddii.  Didn't find syntax for is not set and was missing KConfig role in things.
Jul 27 15:26:47 <zeddii> if  # CONFIG_X86_32=y  is turning it off in your manual edit, you are triggering something .. different .. in lkc if that managed to work.
Jul 27 15:27:10 <zeddii> I guess that would work to clobber the default.
Jul 27 15:27:14 <zeddii> (when editing).
Jul 27 15:27:31 <blloyd2> until the file gets overwritten again.  It's just a C header file after all.  :)
Jul 27 15:28:03 <zeddii> absolutely. it's all transient :P
Jul 27 15:28:05 <blloyd2> 884/890 done.
Jul 27 15:28:45 <blloyd2> and I think I'm going to go google lkc.
Jul 27 15:29:48 <zeddii> it probably won't hit. that's just short hand for linux kernel configurator .. you have to help google a bit :)
Jul 27 15:30:01 <zeddii> s/configurator/configuration/
Jul 27 15:30:07 <zeddii> s/configurator/config/
Jul 27 15:30:09 <zeddii> .. etc.
Jul 27 15:30:51 <zeddii> aka "the confusing and bizarre world of Kconf". I'll stop now :)
Jul 27 15:32:34 <blloyd2> hehe, already made it all the way to Kconfig.
Jul 27 15:45:35 <blloyd2> what is the proper way to ensure settings changes take affect?  Looks like it just rebuilt the kernel with none of my new changes.
Jul 27 15:47:42 <zeddii> that's probably sstate getting in the way, I'm far from the expert on that. I cleansstate before building should take care of it.
Jul 27 15:52:00 <blloyd2> thank you.  Keep losing that (it's mentioned somewhere in docs and can't find when I want it).  Added it to my cheatsheat this time.
Jul 27 15:55:48 <msm> ok
Jul 27 15:55:57 <msm> so i have more recipes that are failing with '*' in the SRC_URI on denzil
Jul 27 15:56:04 <msm> is anyone else seeing this? it can't be just me
Jul 27 15:56:33 <msm> zenlinux: ping do you see this issue on your denzil branch? man and libpam are example recipes
Jul 27 16:07:41 <msm> i think it's some subtle fetcher issue
Jul 27 16:08:47 <RP__> msm: Its probably because people have merged a selection of the fetcher changes :/
Jul 27 16:09:26 <RP__> msm: The fetcher is a rather subtle nightmare for things like this, I'm doing my best to untangle it when I can. Might be worth trying the test suite against that version of bitbake
Jul 27 16:13:16 <msm> RP__: not sure if it's worth it for denzil, or just list of the files manually and move on ;)
Jul 27 16:13:30 <msm> RP__: im curious what would be acceptable here...
Jul 27 16:15:12 <RP__> msm: well, I'm worried if the fetcher starts breaking in the stable branch
Jul 27 16:15:29 <msm> RP__: right, good point
Jul 27 16:15:34 <msm> RP__: this is all i've seen so far ;)
Jul 27 16:15:35 <RP__> msm: That would be a contra-indication for merging the fetcher changes at all to be honest
Jul 27 16:16:12 <msm> RP__: right… i think khem merged the fetcher stuff ;)
Jul 27 16:16:19 * msm hides
Jul 27 16:17:02 <RP__> zenlinux: you might want to note the above
Jul 27 16:18:05 <msm> i'll look at it a bit more
Jul 27 16:18:18 <msm> but not sure how familiar i want to get with the fetcher code
Jul 27 16:18:28 <msm> we probably just need to add another patch
Jul 27 16:18:49 * RP__ wishes he didn't have anything to do with that code
Jul 27 16:29:43 <kergoth> hmm, think the bounds.h change broke builds for 2.6 kernels
Jul 27 16:31:29 <likewise> kergoth: why? cp is unconditional?
Jul 27 16:33:00 <zenlinux> msm, RP__: noted. Yes, I took a pull request from khem that included some fetcher changes, they're in my sgarman/denzil-1.2.2 branch, not in the official denzil branch yet
Jul 27 16:33:19 <kergoth> likewise: yeah. looks like the file is in linux/ not generated/ in 2.6, and it doesn't test to see if it exists
Jul 27 16:33:22 <zenlinux> msm, I assume you're seeing this in my branch, not the official denzil branch, yes?
Jul 27 16:33:59 <blloyd> netink, you still online?
Jul 27 16:35:01 <likewise> kergoth: I thought we had all of this fixed in OE Classic last year, looking.
Jul 27 16:35:21 <likewise> kergoth: I was just about to propose this fix for denzil inclusion, at it fixes out-of-tree module builds
Jul 27 16:39:24 <likewise> kergoth: we fixed this multiple times, I am sure this topic has cost us a $100000 in total of person man hours so far :) http://lists.linuxtogo.org/pipermail/openembedded-core/2011-May/002028.html
Jul 27 16:39:28 <kergoth> gah, i think my grub do_compile has hung entirely during the autogen.. either that or it takes >15mins for a single autogen command
Jul 27 16:40:15 <kergoth>  \_ [sh] <defunct>
Jul 27 16:40:17 * kergoth sighs
Jul 27 16:40:26 <likewise> ah well, I'm stuck on a kernel bug for three days already.    /me <defunct>
Jul 27 16:41:41 <likewise> bisecting is a real pain, when you need different toolchains / toolchain options for -W for all the different versions
Jul 27 16:44:17 <msm> zenlinux: RP__: im using your branch
Jul 27 16:44:42 <zenlinux> ok
Jul 27 16:45:10 <zenlinux> RP__, should I be able to run your bitbake test suite with what I have - I seem to recall you made some additional patches to bitbake to enable the test infrastructure?
Jul 27 16:46:51 <kergoth> aand i'm out of disk space in this vm again
Jul 27 16:46:52 * kergoth grumbles
Jul 27 16:47:09 <blloyd2> zeddii: went over what happened with last build.  I get a configuration mismatch showing it at least looked at the new config (it says it didn't take).  I added the # CONFIG_X86_32 is not set and # CONFIG_X86_CMOV is not set  but both are still set.
Jul 27 16:48:26 <RP__> zenlinux: its pretty standalone
Jul 27 16:48:47 <RP__> zenlinux: copy in the tests directory and bitbake-selftest and see what happens
Jul 27 16:52:36 <blloyd2> what is auto.conf?
Jul 27 16:55:05 <khem> RP__: what is usual way to set a given default non empty root password we use
Jul 27 16:55:15 <khem> in the final image
Jul 27 16:56:00 <RP__> khem: https://bugzilla.yoctoproject.org/show_bug.cgi?id=2799 - did you check if that patch was applied?
Jul 27 16:56:35 <RP__> khem: use an image post process command
Jul 27 16:59:11 * RP__ -> afk
Jul 27 17:06:29 <likewise> cya all
Jul 27 18:13:33 <chackal_sjc> what is a native package for?
Jul 27 18:14:07 <kergoth> non-crosscompiled. tools built on the bubild machine to be run on the ubild machine
Jul 27 18:26:07 <chackal_sjc> kergoth: ok
Jul 27 18:26:40 <chackal_sjc> some library needs other library
Jul 27 18:26:46 <chackal_sjc> how do I add this dependency
Jul 27 18:27:01 <chackal_sjc> so the compiler knows where to look for this foo.so
Jul 27 18:27:35 <chackal_sjc> kergoth: btw, there is any tutorial or doc that shows how to use the native.bbclass?
Jul 27 18:38:58 <chackal_sjc> how do I install libraries at in my target device(${D}) and in ${STAGING_LIBDIR} ?
Jul 27 19:13:11 <kergoth> create a do_install and install your files into ${D}. done.
Jul 27 19:13:21 <kergoth> read pretty much every recipe that exists anywhere for an example.
Jul 27 19:13:31 <kergoth> population of the sysroot/staging is automatic, you don't need to do anything else
Jul 27 20:09:36 <sgw> fray: you around?  I want to chat with you able the U-A patchset I sent last night
Jul 27 20:16:17 <seebs> I have an update for pseudo, and the first step in an update is to have pidge upload the file, I think. Only, there is no pidge.
Jul 27 20:16:46 <seebs> I suspect fray's not-around.
Jul 27 20:17:03 <seebs> Because he mentioned earlier doing some updates on a laptop, and I believe his IRC session is in a window that he only looks at from the laptop.
Jul 27 20:18:57 <sgw> seebs: first step I think is to get the git updated, then provide the recipe update and I think that will cause the new tarball to get generated in the mirror, if we publish a pseudo release tar ball, then pidge or halstead could help
Jul 27 20:19:19 <seebs> Oh, that might be better.
Jul 27 20:19:57 <seebs> I had been doing it by just updating the tarball-based recipe, in the past. I could update the git recipe first. Only, thing is, in this case I think the update changes the invocation arguments in a way which would break the shared pseudo.inc.
Jul 27 20:20:17 <seebs> Basically, I got sick of getting reports about pseudo not building on other architectures, and I believe I've now fixed that.
Jul 27 20:20:57 <sgw> Ah, there is a tarball needed for a versioned recipe, I thought pseudo was all git based, so yes we need to publish a tarball first, do you create that or does beth or maybe halstead can
Jul 27 20:21:15 <seebs> In the past, I create it, put it somewhere, and notify pidge.
Jul 27 20:21:45 <halstead> seebs,  I can put it in place on the public builders when she's offline.
Jul 27 20:21:47 <sgw> Ok, you could notify halstead since he can put it where it needs to go also, a .bz2 this time (I think we had issues last time)
Jul 27 20:22:03 <seebs> Okay. And yes, one of the other changes is that pseudo now generates a bz2.
Jul 27 20:22:54 <seebs> Hmm. Is it significant to anyone whether it's ".tbz2" or ".tar.bz2"?
Jul 27 20:22:58 <sgw> seebs: awesome one less failure step!
Jul 27 20:23:18 <seebs> I'd just gone with .tbz2, but it occurs to me that the longer form seems pretty common, and it's no skin off my nose to standardize.
Jul 27 20:23:20 <sgw> seebs: yes, the recipe calls for .bz2 and I think that fetcher handles that differently.
Jul 27 20:23:26 <seebs> k
Jul 27 20:24:38 <seebs> Hmm.
Jul 27 20:24:49 <seebs> I would really like to kill that symver.patch difference between upstream and poky.
Jul 27 20:25:24 <seebs> But I am sort of concerned about putting something so very specific into the general-case pseudo.
Jul 27 20:25:48 <seebs> I think next time I have free time I am going to try to come up with a General Solution which allows us to specify that at configure time.
Jul 27 21:18:34 <khem> jwessel: around ?
Jul 27 21:18:49 <khem> jwessel: I wanted to to know about the unfs boot
Jul 27 21:19:03 <khem> I think there is a kernel patch that is needed am I right ?
Jul 27 21:19:20 <khem> if yes then is the patch applied in upstream linux
Jul 27 21:20:16 <zenlinux> khem, yes, some patches needed to be applied to the kernel to support low port numbers, I think. As such they are not upstreamed.
Jul 27 21:20:51 <khem> zenlinux: ok. I assume these patches are already in linux-yocto
Jul 27 21:21:11 <zenlinux> khem, yep
Jul 27 21:21:33 <khem> zenlinux: do you have pointers to commits ?
Jul 27 21:21:41 <zenlinux> looking
Jul 27 21:21:45 <khem> I would need them for another kernel tree
Jul 27 21:24:09 <zenlinux> khem, I'm not sure where they are, zeddii or fray know more, as this was a WindRiver feature we ended up adopting in yocto
Jul 27 21:26:11 <khem> zenlinux: ok.
Jul 27 21:26:34 <khem> zenlinux: have you or anyone else you know tried to use it on real hardware
Jul 27 21:26:40 <khem> I know it works on qemu
Jul 27 21:27:57 <pidge> seeb: ping
Jul 27 21:29:09 <pidge> seeb: nm, see halstead got to it. thank you halstead
Jul 27 21:29:38 <halstead> Thanks.
Jul 27 21:29:44 * halstead grabs a food.
Jul 27 21:33:46 <zenlinux> khem, I haven't tried it personally, don't see any reason why it shouldn't work on real hw
Jul 27 21:37:44 <seebs> Hey, pidge, welcome back.
Jul 27 21:38:34 <pidge> seebs: ty
Jul 27 22:11:48 <sgw> thaytan: how did your build do?
Jul 27 22:31:34 <blloyd> zeddii here?
Jul 27 22:34:32 <sgw> blloyd: probably close to done for the day, he's east coast.
Jul 27 22:41:51 <blloyd> appreciate that info.  Thanks.  i'm central.  where is nitink?
**** ENDING LOGGING AT Sat Jul 28 02:59:59 2012

**** BEGIN LOGGING AT Sat Jul 28 02:59:59 2012
Jul 28 11:24:29 <Net147> how come a minimal image build takes so much disk space and time?
Jul 28 12:30:14 <likewise> gm
**** ENDING LOGGING AT Sun Jul 29 02:59:58 2012

**** BEGIN LOGGING AT Sun Jul 29 02:59:59 2012
Jul 29 09:22:13 <JaMa> hi, downloads down again? noticed while building pseudo.. http://www.yoctoproject.org/downloads/pseudo/pseudo-1.4.tar.bz2
Jul 29 09:22:18 <JaMa> halstead: ^
Jul 29 09:23:16 <JaMa> hmm and it's not on source mirror http://downloads.yoctoproject.org/mirror/sources/ too, where is autobuilder source stash?
Jul 29 09:23:35 <seebs> I sent out a patch for that, and I had tested the patch locally and built with it before I sent it out to the list.
Jul 29 09:23:40 <bluelightning> JaMa: worked here, although slow starting
Jul 29 09:24:34 <JaMa> bluelightning: STDERR: Read error (Connection timed out) in headers.
Jul 29 09:24:42 <JaMa> bluelightning: I'll try few more times
Jul 29 09:27:09 <JaMa> ok downloaded manually with longer timeout for wget
Jul 29 09:43:04 <JaMa> bluelightning: any idea why now rootfs want's to install nonexistent locale package?
Jul 29 09:43:36 <JaMa> I guess it's related to 72d1048a8381fa4a8c4c0d082047536727b4be47
Jul 29 09:47:46 <JaMa> bluelightning: 1) oe-pkgdata-util glob ${TMPDIR}/pkgdata ${TARGET_VENDOR}-${TARGET_OS} ${WORKDIR}/installed_pkgs.txt "$GLOBS" > ${WORKDIR}/complementary_pkgs.txt doesn't have TARGET_VENDOR defined for me :/
Jul 29 09:49:16 <bluelightning> I didn't think that patch was merged yet...
Jul 29 09:50:57 <bluelightning> JaMa: looks like RP__ just merged it... try with the patch I posted this morning
Jul 29 09:51:26 <RP__> bluelightning: I just did, yes :)
Jul 29 09:51:37 <RP__> bluelightning: you couldn't sleep this morning?
Jul 29 09:52:14 <bluelightning> RP__: went to bed really early last night as I wasn't feeling well
Jul 29 09:52:24 <bluelightning> RP__: consequently I woke up at 3:30 AM...
Jul 29 09:52:31 <RP__> bluelightning: :( Hope you're feeling a bit better now
Jul 29 09:52:43 <JaMa> bluelightning: the problem for me http://pastebin.ca/2175584
Jul 29 09:52:45 <bluelightning> RP__: I am, thanks
Jul 29 09:53:15 <JaMa> bluelightning: which patch from this morning?
Jul 29 09:53:19 * RP__ decided to ignore the fact I felt worn out and did some things yesterday. I'm in pain today :(
Jul 29 09:53:33 * RP__ wishes he knew what was going on :/
Jul 29 09:53:36 <bluelightning> RP__:  :(
Jul 29 09:53:52 <JaMa> RP__: please merge that D_P patch to libdrm_git before someone breaks his binary feed
Jul 29 09:55:04 <RP__> JaMa: done
Jul 29 09:55:06 <bluelightning> JaMa: http://lists.linuxtogo.org/pipermail/openembedded-core/2012-July/026787.html
Jul 29 09:55:32 <bluelightning> JaMa: I'm not sure it will help in your situation, but it will at least mean stale pkgdata won't cause any issues anymore
Jul 29 09:55:39 <RP__> JaMa: you might need to force eglibc-locale to run do_package again after that
Jul 29 09:56:04 <JaMa> RP__: efreet do_package, right?
Jul 29 09:56:50 <RP__> JaMa: the problem was that we changed eglibc-locale's packaging recently to fix a bug. Some issues persisted due to not cleaning that directory
Jul 29 09:57:02 <RP__> JaMa: so it is really only eglibc-locale
Jul 29 09:57:27 <JaMa> http://pastebin.ca/2175584 shows similar problem in efreet IMHO
Jul 29 09:57:45 * JaMa checking if it's resolved by this patch too
Jul 29 09:58:11 <bluelightning> JaMa: if the problem is still present after applying that patch and forcing efreet do_package then we'll dig into it
Jul 29 10:00:49 <JaMa> still checking but after -c cleansstate and build I still have OE qemux86-64@shr ~/shr-core $ grep efreet-locale tmp-eglibc/pkgdata/x86_64-oe-linux/efreet
Jul 29 10:00:52 <JaMa> PACKAGES: efreet-mime efreet-trash efreet-themes efreet-dbg efreet-staticdev efreet-dev efreet-doc efreet efreet-tests efreet-locale-cs efreet-locale-de efreet-locale-el efreet-locale-es efreet-locale-fr efreet-locale-it efreet-locale-ja efreet-locale-ko efreet-locale-nl efreet-locale-pt efreet-locale-ru efreet-locale-sl
Jul 29 10:01:17 <JaMa> and no libefreet-locale-* packages
Jul 29 10:06:53 <JaMa> bluelightning: package_split creates empty efreet-locale packages which don't result in any .ipk files , because those locale files are incorectly packaged in efreet-tests :/
Jul 29 10:07:06 <JaMa> http://pastebin.ca/2175589
Jul 29 10:07:18 <bluelightning> JaMa: it should be capable of handling that...
Jul 29 10:07:37 <bluelightning> JaMa: does it still fail at do_rootfs?
Jul 29 10:09:27 <JaMa> yes
Jul 29 10:09:41 * JaMa fixing efreet packaging to resolve that
Jul 29 10:10:51 <JaMa> bluelightning: here is part of log.do_rootfs http://pastebin.ca/2175590
Jul 29 10:16:10 <bluelightning> JaMa: packaging shouldn't matter... we have numbers of recipes that produce empty locale packages, that is supposed to work
Jul 29 10:16:50 <bluelightning> JaMa: oe-pkgdata-util does not look at the main file you grep above
Jul 29 10:17:07 <bluelightning> only runtime/* and runtime-reverse/*
Jul 29 10:17:11 <JaMa> agreed.. but that packaging was broken so I've fixed it too, to resolve do_rootfs for me
Jul 29 10:17:26 <bluelightning> that's not good enough, I want to know why it failed here
Jul 29 10:17:29 <bluelightning> it should not have
Jul 29 10:17:44 <bluelightning> (sorry)
Jul 29 10:19:15 <JaMa> mmt I'll pastebin those runtime* dirs
Jul 29 10:19:35 <JaMa> here is *after* fixing packaging http://pastebin.ca/2175591
Jul 29 10:21:32 <JaMa> and here from different arch where it wasn't packaged http://pastebin.ca/2175592
Jul 29 10:21:48 <JaMa> and correctly locale packages don't have .packaged suffix
Jul 29 10:26:09 <bluelightning> JaMa: hmm, it looks like I should be checking for .packaged file and I'm not currently...
Jul 29 10:26:17 <JaMa> hmm I don't see packaged suffix used in oe-pkgdata-util or image.bbclass
Jul 29 10:26:24 <JaMa> yes
Jul 29 10:26:33 <bluelightning> right, I'll try to fix that now
Jul 29 10:28:13 <JaMa> btw: does that patch from morning reall remove e.g. tmp-eglibc/pkgdata/x86_64-oe-linux/runtime/efreet-locale-cs.packaged file if newer version of efreet doesn't package it again?
Jul 29 10:28:57 <JaMa> or it cleans only directory in workdir?
Jul 29 10:33:51 <bluelightning> JaMa: it cleans the directory in the workdir, but my understanding is that sstate is supposed to remove the files from the main TMPDIR/pkgdata directory
Jul 29 10:34:32 <JaMa> ok I'll test that
Jul 29 10:35:07 <JaMa> because if foo-1.0 provides locale-cs and foo-2.0 doesn't we need that cleaned otherwise do_rootfs will fail again as soon as someone upgrades foo to 2.0
Jul 29 11:06:03 <bluelightning> JaMa: yes, indeed
Jul 29 11:16:16 <bluelightning> bbl
Jul 29 11:16:36 <bluelightning> (testing fix on my build machine in the mean time)
Jul 29 11:40:40 <JaMa> ok removing those files from pkgdata works http://pastebin.ca/2175602
Jul 29 11:44:43 <Net147> is there a command show a list of what packages will be built when building?
Jul 29 12:23:59 <halstead> JaMa, pseudo-1.4.tar.bz2 won't be in sources until the autobuilder uses that version.
Jul 29 12:24:44 <halstead> downloads.yoctoproject.org is seeing some slowness but we haven't seen any downtime yet.
Jul 29 12:24:44 <JaMa> halstead: I was expecting that stuff is built on autobuilder before merging..
Jul 29 12:25:08 <JaMa> halstead: it worked later when I've used wget outside bitbake fetcher (with longer timeout)
Jul 29 12:25:48 <halstead> JaMa, It's in http://downloads.yoctoproject.org/releases/pseudo/ but I don;t think master or MUT is using it yet.
Jul 29 12:29:14 <halstead> I am working on the limited bandwidth for downloads.yoctoproject.org.
Jul 29 12:31:25 <JaMa> libxcb/xcb-proto still broken after python-native changes? are http://patchwork.openembedded.org/patch/31987/ http://patchwork.openembedded.org/patch/31977/ still valid?
Jul 29 12:33:55 <JaMa> fails like this http://pastie.org/4352949
Jul 29 12:46:56 <JaMa> and works with those 2 applied
**** ENDING LOGGING AT Mon Jul 30 02:59:58 2012

**** BEGIN LOGGING AT Mon Jul 30 02:59:59 2012
Jul 30 05:05:42 <zubraj> i have freed some space and tried to compile as on the video by scott garmen , last time there was less disk space, so i have done disk cleaning and got some 76 Gb of free space but still my poky qemux86 build is throwing error
Jul 30 05:06:36 <zubraj> error on http://codepad.org/D8FnCs83
Jul 30 05:11:03 <zubraj> i have freed some space and tried to compile as on the video by scott garmen , last time there was less disk space, so i have done disk cleaning and got some 76 Gb of free space but still my poky qemux86 build is throwing error [10:35] <zubraj> error on http://codepad.org/D8FnCs83
Jul 30 05:11:43 <zubraj> @snkt::::http://codepad.org/D8FnCs83
Jul 30 05:14:21 <snkt> zubraj, clean your pkgconfig using "bitbake -c clean pkgconfig" and once again build
Jul 30 05:15:59 <zubraj> sorry seems to be not working..
Jul 30 05:16:59 <zubraj> http://codepad.org/HU6mWM2W
Jul 30 05:50:25 <zubraj> snkt:: qemu x86 not built --->http://codepad.org/HU6mWM2W
Jul 30 05:58:30 <snkt> zubraj, "gzip: stdin: not in gzip format" packages has been corrupted....
Jul 30 05:58:56 <snkt> zubraj, delete it from source and try 2 download it again
Jul 30 05:59:07 <zubraj> yes..
Jul 30 06:21:11 <zubraj> suppose i want to use yocto project to make an image for a sitara processor , and the board for which i want to make an image , I have the BSP for it how should i proceed
Jul 30 06:33:29 <eFfeM_work> hi, in a kernel overlay how can I disable a config setting that I inherit ?
Jul 30 06:55:50 <zubraj> where can i get more information about yocto project , for a particular processor BSp
Jul 30 06:57:07 <tib> http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html ?
Jul 30 08:31:43 <bluelightning> morning all
Jul 30 08:35:57 <tib> morning
Jul 30 11:45:27 <likewise> gm
Jul 30 11:50:08 <gotan> hi
Jul 30 11:50:51 <gotan> I'm having trouble getting the serial console to run under qemu
Jul 30 11:51:05 <gotan> any ideas?
Jul 30 12:14:49 <Net147> gotan: what command you using for qemu?
Jul 30 12:15:52 <gotan> runqemu qemux86-64 core-image-mydistro serial
Jul 30 12:16:41 <gotan> it worked at one point, but stopped working. I'm guessing its something in the kernel config (like having to enable IDE support because runqemu requires a /dev/hda root)
Jul 30 12:18:32 <gotan> I've also only just noticed the bug that meant explict kernel recompilation without using menuconfig does not force a recomopile - which explains alot of my recent frustrations.
Jul 30 12:22:32 <Net147> not sure, i'm new to yocto so I haven't got around to doing much with it yet. maybe someone else would know something.
Jul 30 12:24:35 <bluelightning> gotan: what do you mean by "explict kernel recompilation" ?
Jul 30 12:24:52 <bluelightning> gotan: also which version of the build system are you using?
Jul 30 12:26:06 <gotan> bluelightning: just switched from 7.0 to 7.0.1 -
Jul 30 12:26:22 <gotan> bluelightning: using a korg recpie
Jul 30 12:26:54 <gotan> bluelightning: https://bugzilla.yoctoproject.org/show_bug.cgi?id=2256 - about kernel recompilation
Jul 30 12:27:31 <bluelightning> gotan: ok, so it should be fixed in master then I would assume
Jul 30 12:27:49 <bluelightning> (well, it should be... FYI I was the one who made the fix)
Jul 30 12:30:37 <gotan> I've been using the method described in comment 5
Jul 30 12:32:29 <bluelightning> gotan: right... comment 7 amends this as you probably already saw
Jul 30 12:32:35 <gotan> the problem i have now is that for some reason i'm getting VFS cannot mount root device (null), even though the root-image is ok ( checked with mount loopback)
Jul 30 12:35:31 <gotan> oops - nope. using that now.
Jul 30 12:46:52 <bluelightning> gotan: if it says (null) that sounds like it doesn't know where to find the rootfs... is root= being specified?
Jul 30 12:46:59 <bluelightning> (on the kernel command line)
Jul 30 12:48:05 <gotan> as far as i can tell the parameters in the qemu  command line are correct, but i cannot check without the serial qemu option
Jul 30 12:49:21 <gotan> guess i need to dig into the syslinux parameters
Jul 30 12:49:23 <tib> Is the little endian MIPS problem solved in Yocto 1.2.1?
Jul 30 12:49:52 <gotan> @bluelightning: guess i need to dig into the syslinux parameters
Jul 30 12:50:34 <bluelightning> gotan: I'm not sure syslinux is involved when using qemu...
Jul 30 12:52:48 <gotan> @bluelightning: how does the bitbake APPEND variable work in this qemu situation then?
Jul 30 13:10:03 <bluelightning> gotan: are we talking about runqemu or the kernel recipe now ?
Jul 30 13:13:14 <gotan> @bluelightning:quemu
Jul 30 13:13:39 <bluelightning> gotan: in that case, bitbake is not involved...
Jul 30 13:15:10 <bluelightning> gotan: if you mean --append that we pass to qemu, after that it's up to qemu to pass those options to the kernel
Jul 30 13:18:47 <gotan> @bluelightning: ok, but i'm using  qemu -serial stdio ... --append "vga=0 root=/dev/hda rw mem=128M ip=192.168.7.2::192.168.7.1:255.255.255.0 oprofile.timer=1 console=ttyS0", which does not work, it would seem to be a kernel option tat needs setting.
Jul 30 13:20:42 <bluelightning> gotan: you haven't by any chance set the command line within the kernel configuration have you?
Jul 30 13:22:20 <bluelightning> gotan: i.e. CONFIG_CMDLINE*
Jul 30 13:28:08 <gotan> @bluelightning:  looks like i might have, checking now.
Jul 30 13:29:10 <gotan> @bluelightning: i had it enabled, empty but with override.
Jul 30 13:33:58 <bluelightning> gotan: right, AIUI if CONFIG_CMDLINE_OVERRIDE is set that means you can't pass in any extra options, hence the --append would not be working
Jul 30 13:34:12 <bluelightning> so I guess that's the cause of your issue :)
Jul 30 13:45:54 <gotan> @bluelightning: should RTFM better - assumed override meant override the compiled  in command line - which makes more sense to me.
Jul 30 14:21:12 <JaMa|Off> hmm that probably explains why bitbake is using so much memory lately 2.5G    cache/default-eglibc
Jul 30 14:59:54 <gotan> @bluelightning: I'm assuming that "bitbake virtual/kernel -c oldconfig" will work as well as menuconfig for scripting bug No #7
Jul 30 15:00:24 <bluelightning> gotan: no, I don't think that will work
Jul 30 15:00:58 <bluelightning> gotan: the -c option selects a specific command, it is not passed to make verbatim
Jul 30 15:01:08 <gotan> @bluelightning: ah.
Jul 30 15:10:34 <gotan> @bluelightning: ah. annoying.
Jul 30 15:11:10 <bluelightning> gotan: well, the proper fix is the one applied in master... I appreciate that doesn't help you much using a released version, sorry about that...
Jul 30 15:14:34 <gotan> @bluelightning: any chance it will be backported into denzil
Jul 30 15:15:08 <bluelightning> gotan: that change was rather invasive, I doubt it....
Jul 30 15:15:32 <bluelightning> wouldn't be my call however
Jul 30 15:17:33 <gotan> @bluelightning: kind of leaves non yocto kernel development a bit broken - it's certainly frustrted me.
Jul 30 15:22:38 <gotan> @bluelightning: thanks for all your help though.. gotta go
Jul 30 15:49:43 <kergoth> looks like the bitbake wrapper's git version comparison is badly broken
Jul 30 15:50:15 <kergoth> it's calling awk to do a floating point comparison between 1.7.0.4 and 1.7.5, but those aren't valid floating point numbers. i have no clue what awk is doing about it, but it ends up thinking 1.7.0.4 is >= 1.7.5 on ubuntu 10.04 LTS
Jul 30 17:25:14 <AdityaGandhi> Hi Everyone, I compiled a custom binary for crownbay platform  using HOB, but I am unable to login, this is the error "crownbay login: root
Jul 30 17:25:16 <AdityaGandhi>  Login incorrect"
Jul 30 17:25:30 <AdityaGandhi> is this a know bug, is there a solution?
Jul 30 17:28:15 <khem> zeddii: usr/src/kernel/arch/x86/include/asm/unistd.h:17:29: fatal error: asm/unistd_32.h: No such file or directory
Jul 30 17:28:23 <khem> zeddii: thats with 3.4
Jul 30 17:28:34 <khem> with 3.0 its fine.
Jul 30 17:28:44 <khem> happens when compiling external modules
Jul 30 17:28:57 <khem> on x86_64
Jul 30 17:29:02 <khem> seen something like that ?
Jul 30 17:30:15 <zeddii> hmm. no, and I'm building external modules against the tree at the moment as well. the mrproper claiming another victim ?
Jul 30 17:31:10 <khem> no idea, its hot from oveen still did not look at it
Jul 30 17:31:11 <khem> yet
Jul 30 17:36:05 <khem> zeddii: are you building for x86-64 ?
Jul 30 17:37:04 <khem> zeddii: can you just add include <asm/unistd.h>
Jul 30 17:37:10 <khem> and see what happens ?
Jul 30 17:37:19 <khem> just for checks
Jul 30 17:38:13 <khem> heh 3.4.6 kernel feels so old :)
Jul 30 17:38:18 <zeddii> yep. I'll spin another build up. I fetched this morning, so I'll have some rebuilds I'm sure.
Jul 30 17:38:20 <khem> since I dealt with gcc so much
Jul 30 17:38:27 <khem> 3.4.6 was ages ago
Jul 30 17:38:39 <khem> I dont want to fix EABI in there again please
Jul 30 17:38:52 <zeddii> :) try having to maintain the 3.0 and 3.2 kernels at the same time .. ancient.
Jul 30 17:39:12 <zeddii> which reminds me, I need to prime the pump on my -dev for 3.6 :P
Jul 30 17:39:30 <khem> when I worked for your competetor gcc 3.4 was the blessed one
Jul 30 17:39:49 <khem> ok
Jul 30 17:40:01 <blloyd|work> just try 2.4.....
Jul 30 17:40:05 <khem> I think this dude compiled the kernel in 32bit mode it seems
Jul 30 17:40:27 <khem> blloyd|work: I only know that 2+2 = 4
Jul 30 17:41:24 <blloyd|work> and the company wanted to move forward to a more modern kernel (2.6)
Jul 30 17:42:03 <blloyd|work> (this is this year)
Jul 30 17:42:40 <zeddii> eeee! ;)
Jul 30 17:43:11 <khem> blloyd|work: leave that company will you ?
Jul 30 17:45:49 <AdityaGandhi> Hi guys, I cannot login into a serial prompt when I build the image using HOB for crownbay, and I do not have a vga output as I need to modify Xorg file to get the screen working. Which has to be done through serial
Jul 30 17:46:03 <AdityaGandhi> I enter root as login name
Jul 30 17:46:26 <AdityaGandhi> it gives me an error Login Incorrect
Jul 30 17:47:21 <blloyd|work> company I work for was more than willing to jump multiple versions at once, but unfortunately have a contract to support a specific device for another company for 2 more years.  It's the third party company.  Everything else is making the jump to 3.4.
Jul 30 17:48:05 <khem> AdityaGandhi: use EXTRA_IMAGE_FEATURES = "debug-tweaks" in your local.conf
Jul 30 17:48:24 <khem> blloyd|work: good.
Jul 30 17:48:48 <AdityaGandhi> khem: Let me try that, thanks
Jul 30 17:49:02 <dvhart> zeddii, I just bumped fri2 SRCREVs to pull in a fix and I'm hitting this failure on compile_perf of linux-yocto-3.2: http://pastebin.com/KwYMBZn4
Jul 30 17:49:07 <dvhart> zeddii, ring any bells?
Jul 30 17:50:01 <khem> dvhart: python changes
Jul 30 17:50:10 <khem> may be you need to inherit python-native
Jul 30 17:50:23 <khem> just thinking loud
Jul 30 17:50:35 <dvhart> hrm...
Jul 30 17:50:42 * dvhart tries building that first
Jul 30 17:50:45 <zeddii> perf does need that (patch soon for that).
Jul 30 17:50:50 <dvhart> in master I could see that
Jul 30 17:50:54 <dvhart> but this is denzil
Jul 30 17:51:08 <zeddii> but this looks like the classic perf-scripting bugs that were being hit if autorev kicked in.
Jul 30 17:51:31 <zeddii> tomz isn't here .. is he. He and Scott G went through a bunch of iterations on that.
Jul 30 17:51:38 <dvhart> autorev shouldn't be on
Jul 30 17:51:49 <dvhart> but I did but them to the latest SRCREV in the repository
Jul 30 17:52:07 <dvhart> s/did but/did bump/
Jul 30 17:52:20 <dvhart> tomz is back, but I think he's preoccupied atm
Jul 30 17:52:48 <zeddii> that could be it then. with the perf scripting changes to perf, but not the corresponding kernel changes, you'd get that. do you see Tom's commits on your BSP branch ?
Jul 30 17:52:49 <dvhart> zeddii, is there an known workaround?
Jul 30 17:52:55 <zeddii> yah. "don
Jul 30 17:52:59 <zeddii> @#$
Jul 30 17:53:05 <zeddii> "don't do that"
Jul 30 17:53:34 <zeddii> but in seriousness, we just need to make sure the kernel commits (to perf) are in play.
Jul 30 17:53:39 <dvhart> don't use the latest sources in linux-yocto-3.2?
Jul 30 17:53:58 <dvhart> zeddii, did the perf scripting changes go in to denzil?
Jul 30 17:54:03 <dvhart> I thought those were all master/1.3 stuff
Jul 30 17:54:29 <zeddii> same kernel tree at the moment. We haven't had anything disruptive.
Jul 30 17:54:44 <zeddii> which board is this ?
Jul 30 17:54:48 <dvhart> fri2
Jul 30 17:54:52 <zeddii> right
Jul 30 17:54:54 <zeddii> you said that.
Jul 30 17:55:19 <dvhart> is it the SRCREV for meta or standard/base that triggers this? do you know?
Jul 30 17:55:28 * dvhart backs out the meta change
Jul 30 17:55:29 <zeddii> I definitely see the changes on the fri2 branch in linux-yocto-3.2
Jul 30 17:55:38 <dvhart> ah
Jul 30 17:55:39 <dvhart> hrm
Jul 30 17:55:49 <dvhart> ok, I'll only bump that as far as I require it then and see
Jul 30 17:56:02 <dvhart> need the "EFI 32bit" fix for ioremap
Jul 30 17:56:12 <zeddii> it would be the machine branch that needs to be bumped past 0ec416edf0b0cab3e919c0a1c167a883f8b344a2
Jul 30 17:56:23 <zeddii> (me typed that in from memory).
Jul 30 17:56:27 <zeddii> argh.
Jul 30 17:56:34 <zeddii> I'm going to stop typing soon.
Jul 30 17:56:39 <zeddii> I'm going to hurt myself.
Jul 30 17:56:52 <dvhart> well.... I'm using the HEAD of that branch
Jul 30 17:57:22 <zeddii> so you should have everything you need.
Jul 30 17:57:37 <dvhart> :(
Jul 30 17:57:37 <zeddii> new issue perhaps.
Jul 30 18:01:07 <AdityaGandhi> kehm: EXTRA_IMAGE_FEATURES = "debug-tweaks"  option is already there in my local.conf file
Jul 30 18:01:42 <AdityaGandhi> Any other suggestions?
Jul 30 18:05:48 <dvhart> zeddii, fixed by back off before the perf changes but after the efi fix merged into fri2
Jul 30 18:05:57 <dvhart> this is consistent with crownbay as well
Jul 30 18:06:05 * dvhart moves on for now
Jul 30 18:07:55 <blloyd|work> oh, fray and zeddii.  Thank you very much for all your suggestions and help last week.  I both learned a lot and finally got a kernel that could boot.  Now if it only was smart enough to find the disk it just booted off of.  :)
Jul 30 18:08:40 <zeddii> hehe. sort of like I felt yesterday looking for a display port connector to see why my builder box wasn't booting!
Jul 30 18:11:41 <AdityaGandhi> I compiled a custom binary for crownbay platform  using HOB, but I am unable to login, when I enter username root, it says login incorrect! , I already tried  EXTRA_IMAGE_FEATURES = "debug-tweaks" , that was suggested
Jul 30 18:18:09 <dvhart> AdityaGandhi, that should do it. Have you verified that the setting made it into the build environment?
Jul 30 18:18:27 <dvhart> AdityaGandhi, eg "bitbake core-image-sato -e | grep EXTRA_IMAGE_FEATURES"
Jul 30 18:19:24 <AdityaGandhi> just trying it, this is my output
Jul 30 18:19:30 <AdityaGandhi> # IMAGE_FEATURES= ${EXTRA_IMAGE_FEATURES} apps-console-core ${SATO_IMAGE_FEATURES}
Jul 30 18:19:30 <AdityaGandhi> # EXTRA_IMAGE_FEATURES=debug-tweaks
Jul 30 18:19:30 <AdityaGandhi> EXTRA_IMAGE_FEATURES="debug-tweaks"
Jul 30 18:21:05 <AdityaGandhi> I think it did make it into the build environment, the option was always there, I hadn't changed it !
Jul 30 18:21:19 <dvhart> Got me then :(
Jul 30 18:21:55 <dvhart> if you look at the /etc/passwd on the image, what does the root user line look like?
Jul 30 18:24:25 <AdityaGandhi> let me check
Jul 30 18:25:12 <AdityaGandhi> root:x:0:0:root:/home/root:/bin/sh
Jul 30 18:25:30 <AdityaGandhi> thats what the root user line is like when I mount my image
Jul 30 18:35:40 <seebs> Hey, naive question about the bitbake parser.
Jul 30 18:35:52 <seebs> I could probably test this, but I would not trust a test result to match both intent and future development.
Jul 30 18:36:08 <seebs> If I want to put a line in a bitbake shell function that uses a quoted multiline shell string, am I doomed to failure?
Jul 30 18:36:17 <seebs> e.g., newline_separated_words="word1
Jul 30 18:36:18 <kergoth> iirc dropbear checks the global 'IMAGE_FEATURES' for debug-tweaks to change that behavior. it should really be fixed so the image does the config adjustments for that, not the recipe
Jul 30 18:36:18 <seebs> word2"
Jul 30 18:36:47 <kergoth> might work, but it depends not just on the capabilities of our shell but also on the capabilities of the pysh shell parser we're using
Jul 30 18:39:44 <seebs> Yeah.
Jul 30 18:40:12 <seebs> Thing is, I had cause to look at rpm_log_check, and it made me weep tears of blood. But the obvious improvement is to use grep -F, which wants newline-separated words.
Jul 30 18:40:57 <seebs> ... So I have a bug report involving libtool choosing, for reasons unknown to me, to run blah-blah-blah-gcc [various args] >/dev/null 2>&1
Jul 30 18:41:22 <seebs> I would like to nominate this for the Most Likely To Break A Maintainer's Spirit for 2012.
Jul 30 18:42:06 <seebs> It turns out that throwing away all possible diagnostics as to why something failed does not make my life as much better as the naive reader might have expected.
Jul 30 18:50:09 <AdityaGandhi> Hi I think HOB does not get its config from local.conf, it does not get the  EXTRA_IMAGE_FEATURES,
Jul 30 18:50:59 <AdityaGandhi> I saved the hob config as a template and figured that there were no  EXTRA_IMAGE_FEATURES, whereas the local.conf has  EXTRA_IMAGE_FEATURES="debug-tweaks"
Jul 30 19:08:41 <blloyd|work> it doesn't aditya
Jul 30 19:09:40 <blloyd|work> there is a settings button in HOB, then a tab for additional settings.  You can add it there.  Hob gets it's initial setup from local.conf then stores some files in a folder .hob.
Jul 30 19:33:16 <AdityaGandhi> thanks blloyd!
Jul 30 19:39:40 <blloyd|work> np.  You asked an easy one.  :)
Jul 30 19:42:01 <blloyd|work> question about ?= syntax.  It's a default, so overridden by =.  And it's higher priority than ??=, so always used in preference to ??=.  But which one is used when two files both have a ?= in them?
Jul 30 20:00:57 <dvhart> blloyd|work, depends on the order they are parsed
Jul 30 20:05:45 <blloyd|work> first one parsed or last one parsed?
Jul 30 20:06:08 <blloyd|work> Ie, if I have a file that requires another, do I put the line before or after the require line?  (I can control parse order).
Jul 30 20:07:14 <dvhart> In the case of ?=, the first is used.
Jul 30 20:07:53 <kergoth> 90% of the time you're best off using ??= when defining defaults. we should look into using it more at some point
Jul 30 20:07:56 <dvhart> blloyd|work, see 2.1.3 of the bitbake manual
Jul 30 20:08:14 <blloyd|work> thanks dvhart.  I knew it had to be somewhere.
Jul 30 20:08:24 <dvhart> The bitbake manual is often overlooked
Jul 30 20:09:24 <blloyd|work> the bitbake I could find is not current (no -C documented for instance), but I have read it.  :)
Jul 30 20:09:55 <blloyd|work> Just have crammed to much new in too short a time.  I feel like I've forgotten more than I learned.
Jul 30 20:10:30 <dvhart> blloyd|work, I know the feeling well :)
Jul 30 20:59:53 <blloyd|work> I am still trying to unravel the great mystery that is what bitbake does for me while building a kernel.  In particular, where do the configurations magically come from?  For instance, the meta-intel configurations are close to what I need, but where do I go to look at their configuration, and how am I supposed to know to look there?
Jul 30 21:02:43 <kergoth> there's no mystery.
Jul 30 21:02:47 <kergoth> find the recipe being built, read it.
Jul 30 21:02:56 <kergoth> if it inherits a class, read that. if it requires/includes another file, read that.
Jul 30 21:03:53 <blloyd|work> got all that printed out and scribbled on in front of me.
Jul 30 21:30:29 <blloyd|work> why would you ever need to inherit from an empty bbclass file?
Jul 30 21:32:16 <kergoth> it allows one to do something like this:
Jul 30 21:32:25 <kergoth> FOO ??= "dummy"
Jul 30 21:32:29 <kergoth> FOO_bar = "baz"
Jul 30 21:32:33 <kergoth> inherit ${FOO}
Jul 30 21:32:43 <kergoth> inherit with no argument is invalid syntax
Jul 30 21:33:42 <blloyd|work> that makes sense.  I have an "inherit module_strip.bbclass", and module_strip.bbclass is a 0 byte file.
Jul 30 21:34:07 <kergoth> in that case it was almost certainly for compatibility.
Jul 30 21:34:16 <kergoth> it used to exist and do something, what it did is no longer needed
Jul 30 21:34:25 <kergoth> but we don't want to break all the external layers, presumably
Jul 30 21:35:05 <blloyd|work> that makes sense, thank you.
Jul 30 21:35:26 <kergoth> np
Jul 30 22:24:43 <blloyd|work> I have a line PREFERRED_VERSION_linux-yocto = "3.2%"
Jul 30 22:25:33 <blloyd|work> in my local.conf.  I thought that should give me a 3.2 kernel.  But I'm still getting a 3.4 kernel when building qemu.  Suggestions for what I'm doing wrong/don't understand?
Jul 30 22:32:48 <seebs> The first one encountered, I believe.
Jul 30 22:32:58 <seebs> The variable tracking stuff should Reveal All, but I don't think it's ever gotten merged.
Jul 30 22:36:07 <blloyd|work> what's this variable tracking stuff you mention?  It sounds helpful with letting me understand things.
Jul 30 22:39:03 <khem> you need something like PREFERRED_VERSION_linux-yocto_qemux86-64 = "3.2%"
Jul 30 22:39:33 <khem> in your local.conf to be sure it uses what you want
Jul 30 22:39:55 <khem> overrides are overrides and they shadow
Jul 30 22:40:12 <blloyd|work> khem: PREFERRED_VERSION_linux-yocto_${MACHINE} acceptable syntax?
Jul 30 22:40:17 <khem> and kernel recipe for linux-yocto defines the version as overrides
Jul 30 22:40:30 <khem> who will expand MACHINE for you
Jul 30 22:41:10 <khem> in recipe it will work
Jul 30 22:41:17 <khem> but in conf metadata I doubt
Jul 30 22:44:12 <blloyd|work> so not a syntax in a .conf I should rely on.  Thanks, putting the _qemux86 at the end has it using the older version.
Jul 30 22:49:29 <kergoth> if you mean literally '${MACHINE}' rather than the machine it wouldn't make any sense
Jul 30 22:49:47 <kergoth> but otherwise should be fine, i'd think
Jul 30 22:49:54 <blloyd|work> Ok, end point: a live system that boots on my hardware.  Been referencing crownbay as a starting point, but I guess it's my lack of git familiarity blocking my ability to follow things.  How is it creating the git checkout?
Jul 30 22:50:55 <blloyd|work> kergoth: was wanting to put ${MACHINE} literally.  Why I asked.  Building for multiple platforms, wanted all using the same kernel so I can compare apples (red) to apples (yellow) instead of orangles and watermellons.
Jul 30 22:51:57 <kergoth> that doesn't make sense
Jul 30 22:52:17 <kergoth> a kernel is by definition bound to the target, you're never going to get one that works everywhere, particularly across architectures
Jul 30 22:52:24 <kergoth> so the _${MACHINE} would be of no real use
Jul 30 22:52:36 <kergoth> but *if* you wanted that, which you don't, there are plenty of generally applied overrides other than machine
Jul 30 22:52:54 <kergoth> e.g. forcevariable, which is designed to allow the user to force values overriding anything else in the metadata
Jul 30 22:53:06 <kergoth> see the definition of the OVERRIDES variable. anything listed there can be used as an override
Jul 30 22:56:37 <blloyd|work> is there a place where variables and their settings are reported so I can browse what happened in a build?  I seem to be missing a bunch of understanding.  Right now, it's like read every file and walk what should happen the variable.  grep being a friend for finding files to be walked.
Jul 30 23:00:37 <bluelightning> blloyd|work: bitbake -e
Jul 30 23:00:45 <bluelightning> blloyd|work: also bitbake -e <target>
Jul 30 23:00:58 <bluelightning> usually combined with grep / less
Jul 30 23:02:12 <blloyd|work> ok, so I'm asking about environment.  Got it.  Thanks
Jul 30 23:03:47 <kergoth> you're asking about the metadata, which is what -e dumps. the help calls it 'environment', and so it is, but that term is even more vague than 'bitbake metadata'. e.g. only some variables are exported into the process environment
Jul 30 23:04:24 <blloyd|work> which is why I didn't match them up.  Thanks.
Jul 30 23:08:28 * kergoth nods, np
Jul 30 23:08:53 <kergoth> it's not the only piece of remnant naming. e.g. PN when it's a recipe, not a package
Jul 30 23:08:54 <kergoth> heh
Jul 30 23:09:28 <khem> yeah recipe and packages are totally different
Jul 30 23:09:47 <khem> pn can be one of the packages that a recipe named pn generates
Jul 30 23:10:28 <khem> I have spent my life telling people the difference between an elf section thats an input to linker and elf segment thats output of linker
Jul 30 23:10:32 <blloyd|work> oh, well.  I'll get the naming conventions and legacy things down.  Along with learning python, git, bitbake, ...
Jul 30 23:12:25 <blloyd|work> assembly (lost track of the dialects over the years) and c are fine, those I've used for years as embedded languages.  Yocto is getting to add to my list of tools things I never considered a part of embedded.
Jul 30 23:14:48 <jzhang> jzhang
Jul 30 23:42:04 <blloyd|work> well, success of a sort.  I can now boot the machine qemux86 on my custom hardware.  The custom machine type doesn't work, but it makes the qemu machine compatible with my hardware.  What fun.
Jul 30 23:51:54 <khem> zeddii: sigh remember that missing header problem in the morning ?
Jul 30 23:52:22 <khem> zeddii: it turns out to be make -C $kerneldir _mrproper_scripts
Jul 30 23:52:34 <AdityaGandhi> One question, a  simeple one again, I am using HOB to build images, I even added the EXTRA_IMAGE_FEATURES = "debug-tweaks" in hob, but doesn't seem to work!
Jul 30 23:52:56 <khem> there seems to be no end of vows for external kernmods
Jul 30 23:53:07 <AdityaGandhi> Can you sugesst how do I add a web-browser to core-image-sato for poky 7
Jul 30 23:54:30 <khem> there is a layer for browsers its called meta-browser see layerindex on OE wiki
Jul 30 23:54:36 <khem> add that and dependent layers
Jul 30 23:55:54 <AdityaGandhi> thanks
Jul 31 00:09:18 <AdityaGandhi> khem would I add a layer directly to my bbapped file after I download and make a meta-xyz folder?
Jul 31 00:09:38 <AdityaGandhi> Or do I have to do something more so that I have the web browser in my image file?
Jul 31 00:43:34 <Crofton|work> seems like kernels around 3.2-3 do not like gcc 4.7.2?
Jul 31 00:52:45 <AdityaGandhi> Hi guys, kinda new here, I am bilding a core-image-sato for crownbay platform!
Jul 31 00:53:14 <AdityaGandhi> I need to add browser-layer from http://www.openembedded.org/wiki/LayerIndex
Jul 31 00:53:43 <AdityaGandhi> I have made a new folder called meta-browser-layer, added the layer to bbappend.conf
Jul 31 00:54:06 <AdityaGandhi> I need to add it to my core-image-sato, I tried reading documentation but it isn't very clear,
Jul 31 00:54:15 <AdityaGandhi> need some help with it
Jul 31 00:55:09 <AdityaGandhi> I added IMAGE_INSTALL_append = "firefox" to local.conf
Jul 31 00:55:31 <AdityaGandhi> I get an error ERROR: Nothing RPROVIDES 'base-passwdfirefox'
Jul 31 00:59:42 <kergoth> AdityaGandhi: _append doesn't add a separator.
Jul 31 00:59:44 <kergoth> you forgot a space
Jul 31 00:59:49 <kergoth> IMAGE_INSTALL_append = " firefox"
Jul 31 01:00:03 <kergoth> which you should have realized when it showed 'base-passwdfirefox' :)
Jul 31 01:00:24 <AdityaGandhi> ohh thanks! Will try again
Jul 31 01:02:00 <AdityaGandhi> kergoth is there anything else I would have to do to add firefox to my image?
Jul 31 01:02:20 <kergoth> shouldn't, no
Jul 31 01:02:33 <AdityaGandhi> I got an error saying ERROR: Nothing PROVIDES 'libnotify'
Jul 31 01:02:35 <kergoth> but i'm only half paying attention to this conversation, spotted the obvious mistake
Jul 31 01:02:40 <AdityaGandhi> do you know what provide it
Jul 31 01:03:07 <AdityaGandhi> The dependency on git for the browser states I need meta-oe core
Jul 31 01:03:17 <AdityaGandhi> do I need it even with yocto?
Jul 31 01:03:34 <kergoth> yocto doesn't magically provide what meta-oe does
Jul 31 01:03:40 <kergoth> if the layer needs meta-oe, it needs meta-oe, period
Jul 31 01:03:44 <kergoth> go by the layer documentation
Jul 31 01:05:50 <AdityaGandhi> Okay will try that! Thanks a lot, but my only doubt is that yocto and openembedded core have conflicts!
Jul 31 01:06:07 <AdityaGandhi> I mean they are two different build systems
Jul 31 01:19:11 <Crofton|work> jesus
Jul 31 01:19:25 <Crofton|work> the yocto/oe-core messaging is borked
Jul 31 01:19:49 <JaMa|Off> don't forget poky :)
Jul 31 01:19:53 <Crofton|work> rofl
Jul 31 01:20:10 <Crofton|work> JaMa|Off, I hope you are getting up, not going to bed
Jul 31 01:20:38 <Crofton|work> It is so frustrating
Jul 31 01:21:00 <Crofton|work> and so hard to communicate to the "yocto people" how confused people are
Jul 31 01:21:12 <Crofton|work> there was an email excahnge on meta-ti that was nuts
Jul 31 01:21:27 <Crofton|work> although the write was obviously serisouly confused
Jul 31 01:22:56 <JaMa|Off> Crofton|work: trying to fix pixman before going to bed :/
Jul 31 01:23:24 <JaMa|Off> finally I know what was killing emacs builds (temacs running in qemu..) -> pixman
Jul 31 01:25:07 <kergoth> we should put somewhere a summary: oe & friends ~= bitbake+oe-core+meta-oe, yocto/poky ~= bitbake+oe-core+meta-yocto
Jul 31 01:25:10 <kergoth> heh
Jul 31 01:25:21 <kergoth> it's a simple thing, but i think a lot of folks don't know it
Jul 31 02:02:13 <JaMa|Off> blah.. 4AM but pull request is on ML, gnite :)
**** ENDING LOGGING AT Tue Jul 31 02:59:58 2012

**** BEGIN LOGGING AT Tue Jul 31 02:59:59 2012
Jul 31 04:05:00 <zubraj> i tried compiling the yocto project with build system poky , but it is failing out with errors
Jul 31 04:05:13 <zubraj> http://codepad.org/ILT1TAjc
Jul 31 04:08:14 <zubraj> don't know what is the error
Jul 31 04:21:47 <bizhanMona> hi
Jul 31 04:22:30 <zubraj> hello
Jul 31 04:23:03 <bizhanMona> Hello all, I would like to use Yocto build infrastructure for Ivy Bridge with Q77 chipset, which git tree should I use? Many thanks in advance.
Jul 31 04:30:24 <bizhanMona> zubraj: any hint please?
Jul 31 05:04:22 <zubraj> the errro is http://codepad.org/ILT1TAjc
Jul 31 05:04:32 <zubraj> yocto compiling fails out this errors
Jul 31 06:31:18 <eFfeM_work> zubraj: looks as if your elfutils dir or source tarball is corrupted or not suited for your host env
Jul 31 08:11:57 <eFfeM_work> gtting a build error ERROR: Error executing a python function in ../poky-denzil-7.0/meta/recipes-kernel/linux/linux-yocto-rt_3.2.bb:
Jul 31 08:11:58 <eFfeM_work> ImportError: No module named license
Jul 31 08:11:58 <eFfeM_work> full log at http://pastebin.com/saVDt6Es
Jul 31 08:11:58 <eFfeM_work> anyone an idea what is wrong here ?
Jul 31 08:25:39 <bluelightning> eFfeM_work: strange... you do have meta/lib/oe/license.py ?
Jul 31 08:25:57 <eFfeM_work> checking
Jul 31 08:26:58 <eFfeM_work> bluelightning: thanks, found it, I have the file, but I made an error in my bblayers.conf file
Jul 31 08:27:45 <eFfeM_work> wanted to make it location independent, made a mistake in it (still not sure what the best way is to write a position independent conf file)
Jul 31 08:28:59 <bluelightning> eFfeM_work: I think the only way to do that would be to use a var from the environment (allowed through via BB_ENV_EXTRAWHITE if necessary)
Jul 31 08:30:54 <eFfeM_work> bluelightning: yeah, I did something like that in oe classic too (passing something like OE_TOPDIR)
Jul 31 10:50:46 <bizhanMona> Would someone please respond to my question: The latest release of the Yocto, 1.2, supports Intel chip Sandy bridge chip and Panther chip set, I am interested for Ivy Bridge chip and Q77 chip set, would the same release supports what I need or what should I do? Many thanks in advance
Jul 31 10:51:45 <likewise> bizhanMona: I think support for the chipset is purely dependent on the kernel, so the best thing to familiarize yourself with is what kernel supports your hardware.
Jul 31 10:54:27 <bizhanMona> likewise: oh okay thanks, so I need to find out the latest kernel by yocto release, 3.2 (?) has support for Ivy Bridge and Q77, then I should be able to use Romley to build for those if that is the case ????
Jul 31 11:10:52 <tib> If I wanted to use JTAG on a Yocto image, is it simple? Do I need to add the kernel module idbntf.ko for the runtime JTAG to work?
Jul 31 11:37:26 <eFfeM_work> anyone any idea on this: I have a kernel overlay in denzil for 3.2; that kernel builds fine and my patches are applied, kernel boots ok etc etc. now I want to move to rt-3.2 so copied  linux-yocto_3.2.bbappend  to linux-yocto-rt_3.2.bbappend and changed my local.conf to have linux-yocto-rt as preferred kernel; I can bake the recipe but somehow my patches are not fetched or applied
Jul 31 11:42:53 <tib> The name of the bbappend must exist as a .bb file in recipes-kernel/linux/ AFAIK.
Jul 31 11:43:34 <eFfeM_work> tib, sure
Jul 31 11:44:09 <tib> bbappend just extends the bb file it appends for, if you rename the bbappend so it doesn't exist in the recipe-kernel then it won't work?
Jul 31 11:44:23 <eFfeM_work> tib the name does exist
Jul 31 11:44:38 <eFfeM_work> my file linux-yocto-rt_3.2.bbappend
Jul 31 11:44:56 <eFfeM_work> recipes_kernel/linux: linux-yocto-rt_3.2.bb
Jul 31 11:45:37 <eFfeM_work> still seems my bbappend file is not processed
Jul 31 11:47:07 <tib> And you have: LINUX_VERSION_EXTENSION = "-custom" in the bbappend?
Jul 31 11:48:08 <eFfeM_work> hm, no (didn't have that in the linux-yocto_3.2.bbappend either)
Jul 31 11:49:34 <eFfeM_work> do I need that? is there a place in the docs where I should have found that ?
Jul 31 11:49:37 <tib> I'm quite a newbie though IIRC if you have made your custom kernel you should use above extension as else they prioritise the normal packages
Jul 31 11:50:31 <eFfeM_work> I'll try it, it only costs some cpu cycles
Jul 31 11:54:05 <eFfeM_work> back in a bit with the results ;-)
Jul 31 11:56:06 <tib> Otherwise the only things I can recall are SRCREV and SRC_URI so I hope that the use of -custom should be enough. If you have everything cached it may be that the cache doesn't recognise that you've changed packages so you can try a bitbake -c cleansstate as well I guess?
Jul 31 12:03:55 <tib> Is the MULTILIB_IMAGE_INSTALL dropped and how do you use multilib arch in Yocto now in that case?
Jul 31 12:09:34 <eFfeM_work> tib, tried a cleanall, it is still running do_fetch (apparently fetching the kernel takes ages)
Jul 31 12:09:45 <eFfeM_work> no idea on multilib, I am on powerpc
Jul 31 12:13:22 <eFfeM_work> not sure if the -custom did it but apparently now the files are fetched
Jul 31 12:20:07 <tib> Nice :)
Jul 31 12:31:43 <eFfeM_work> tib not sure if it ws the version extension or the cleanall and refetch, but it builds and boots
Jul 31 12:31:49 * eFfeM_work is :-)
Jul 31 12:32:00 <RP__> halstead: ping (when you wake up)
Jul 31 12:32:04 <tib> Either way the problem is solved, thumbs up. :)
Jul 31 12:32:25 <halstead> RP__, pong.
Jul 31 12:32:45 <RP__> halstead: You're working some strange hours?! ;-)
Jul 31 12:32:59 <RP__> halstead: Did you just change the OS on some autobuilders?
Jul 31 12:33:12 <halstead> I suppose so. I'm around quite a lot recently.
Jul 31 12:33:13 <RP__> halstead: I'm guessing that is why you started a test build too?
Jul 31 12:33:44 <halstead> I added in the two freshly installed builders we had been holding back.
Jul 31 12:33:56 <halstead> And yes the OSs are different.
Jul 31 12:34:13 <RP__> halstead: they have dash as /bin/sh I guess? :)
Jul 31 12:34:15 <halstead> I started a test hoping we would know if we had to pull them back out of the pool.
Jul 31 12:34:32 <RP__> halstead: I killed the test as the branch you were testing has bugs in
Jul 31 12:34:38 <halstead> The debian host does. I don't know about Fedora 17.
Jul 31 12:34:51 <halstead> RP__, Thank you.
Jul 31 12:35:03 <RP__> halstead: I'm trying with master and there are some failures but nothing that is wrong with the autobuilder
Jul 31 12:35:14 <RP__> halstead: I'm just wanting to confirm what changed :)
Jul 31 12:35:25 <bluelightning> RP__: the one on ab02 was pre Khem's dash fix
Jul 31 12:35:44 <RP__> bluelightning: yes, I know. I've restarted the non-gplv3 with that applied
Jul 31 12:36:05 <RP__> halstead: "Why are we only seeing this now" is something I'll probably get asked but its good we're seeing these issues
Jul 31 12:36:23 <RP__> halstead: and as mentioned above, I merged a patch for that issue just after I started the build! :)
Jul 31 12:36:41 <halstead> So ab10 is bash as the default shell but I need to change it on ab02.
Jul 31 12:37:01 <RP__> halstead: leave it as dash
Jul 31 12:37:21 <RP__> halstead: we're supposed to work on dash now so I'd like to know if we don't
Jul 31 12:37:23 <RP__> halstead: Where are we at with the bugzilla statistics ?
Jul 31 12:37:48 <halstead> RP__, My number still don't line up with the existing bug charts.
Jul 31 12:38:07 <RP__> halstead: That doesn't surprise me. How far out are they?
Jul 31 12:38:27 <RP__> halstead: I think neither bluelightning or I can ssh into ab02 btw
Jul 31 12:38:39 <RP__> halstead: I've suspected there was an issue somewhere with the numbers
Jul 31 12:38:48 <halstead> Just a moment I need to get back in that spot.
Jul 31 12:39:01 <halstead> Let me add you two to the new builders first.
Jul 31 12:39:37 <RP__> halstead: sorry, since I'm talking to you the queue is getting flushed ;-)
Jul 31 12:45:13 * zeddii reads from last night. khem: figures it was mrproper .. again.
Jul 31 12:57:16 <RP__> hmm, world build failing in gcc :/
Jul 31 12:57:42 <halstead> RP__, You should be able to access ab02.yp and ab10.yp now.
Jul 31 12:57:55 <RP__>  fatal error: sys/sdt.h. This looks familiar somehow
Jul 31 12:58:20 <RP__> halstead: yes, great thanks!
Jul 31 12:58:23 <RP__> bluelightning: ^^^
Jul 31 12:58:49 <halstead> bluelightning, I'll be ready for you shortly.
Jul 31 12:59:28 <RP__> halstead: sorry, I thought you must have enabled all the accounts. I'm jumping the gun!
Jul 31 13:03:18 <halstead> bluelightning, You should be set now as well.
Jul 31 13:03:46 <bluelightning> halstead: yep works, thanks!
Jul 31 13:04:52 <JaMa|Work> RP__: is it possible that BB_SIGNATURE_HANDLER_forcevariable = "OEBasicHash" from local.conf (DISTRO.conf sets OEBasic) is ignored? I do see it in bitbake -e, but stamps files don't have sstate hash suffix
Jul 31 13:12:44 <RP__> JaMa|Work: That sounds odd, it should work...
Jul 31 13:19:18 <JaMa|Work> yes weird, http://pastebin.com/Pz535R9w
Jul 31 13:20:55 <JaMa|Work> no idea where None in # BB_SIGNATURE_HANDLER_forcevariable=None came from
Jul 31 13:21:29 <JaMa|Work> but it wouldn't be first time when bitbake -e shows something different then what is acually used :/
Jul 31 13:38:18 <rburton> RP__: sys/sdt.h... i had that
Jul 31 13:38:28 <rburton> RP__: host systemtap headers present?
Jul 31 13:59:40 <halstead> LaurentiuSerban, Are the bug trends for WW30 available? I want to compare the numbers I'm seeing.
Jul 31 14:02:33 * JaMa|Work should probably report bugs in bugzilla instead of replying on commit which caused them to make trends more acurate
Jul 31 14:03:05 <RP__> rburton: yes, its host infection
Jul 31 14:03:33 <kergoth> RP__, JaMa|Work: heh, it wouldn't be the first time we've had a bug with config variables not having overrides applied, but i thought we fixed that so bitbake does a finalize in a local copy of the data for that
Jul 31 14:03:37 * kergoth yawns and gets breakfast
Jul 31 14:04:26 * JaMa|Work added log entry for that and waiting for build to finish to test it seeing OEBasic only when creating sighandler
Jul 31 14:06:41 <RP__> kergoth: I wonder if we're using the right copy of the data to look this up?
Jul 31 14:07:08 <RP__> JaMa|Work: either is fine, I do try and respond to the issues you report
Jul 31 14:08:39 <JaMa|Work> RP__: I know you're trying.. but sometimes those are smaller issues and if develope who caused them don't respond I tend to fix them myself when I get to cleanup oe-core mail folder..
Jul 31 14:08:56 <kergoth> RP__: it's a good question, we should probably sanity check the cooker and runqueue in particular in that regard
Jul 31 14:09:15 <JaMa|Work> RP__: with them in buzilla I can cleanup folder and forget them myself :)
Jul 31 14:09:29 <kergoth> long term, it may be worth having some sort of 'bitbake configuration' object which pulls what it needs from the metadata, rather than having all those use the metadata directly
Jul 31 14:10:41 <RP__> JaMa|Work: fair enough :)
Jul 31 14:10:54 <RP__> kergoth: yes, agreed
Jul 31 14:13:08 <tib> If I would use multilibs for more than lib32, would the proper way to do it be MULTILIBS = "multilib:lib32:<package 1>:<package2>", MULTILIBS = "multilib:lib32 \ multilib:<package 1> \ multilib:<package2>" or MULTILIB+="<package 1>", MULTILIB+="<package 2>", or what?
Jul 31 14:16:47 <RP__> require conf/multilib.conf \n MULTILIBS = "multilib:lib32" \n DEFAULTTUNE_virtclass-multilib-lib32 = "x86" \n bitbake lib32-<package>
Jul 31 14:24:16 <tib> You meant with \n bitbake lib32-<package> to bake said package instead of adding that line to the config, right? I wanted it in the image rather than building the rpm? What I was thinking of was the Yocto dev manuals:
Jul 31 14:24:21 <tib> "You could compile some binaries to use one set of libraries and other binaries to use other different sets of libraries. The libraries could differ in architecture, compiler options, or other optimizations. "
Jul 31 14:44:46 <kergoth> hmm, can't do a build without the x11 distro feature right now, at least not the usual due to this unconditional dependency chain: 'gconf', 'polkit', 'consolekit', 'virtual/libx11'
Jul 31 14:44:50 * kergoth investigates
Jul 31 14:46:03 <bluelightning> kergoth: what's depending on gconf?
Jul 31 14:47:27 <kergoth> task-base-* wants qemu-config which wants oprofileui-server which wants gconf
Jul 31 14:47:43 <kergoth> which thereby breaks core-image-base for qemu* machines with ad istro without x11
Jul 31 14:47:44 <bluelightning> kergoth: right, known issue (bug 1690, against me...)
Jul 31 14:47:48 <kergoth> ah, right
Jul 31 14:47:53 <kergoth> okay then, thanks
Jul 31 14:47:57 <kergoth> didn't think to check the bts :)
Jul 31 14:48:03 <bluelightning> workaround is to set POKYQEMUDEPS = ""
Jul 31 14:48:10 <bluelightning> or butcher qemu-config
Jul 31 14:48:36 * kergoth nods
Jul 31 14:59:13 * fray is on the call
Jul 31 14:59:22 * nitink is on the call
Jul 31 15:00:01 <bluelightning> YPTM: Paul Eggleton is on the call
Jul 31 15:00:05 * fusman is on the call
Jul 31 15:00:19 <strassek> YPTM: Kevin Strasser in on the call
Jul 31 15:00:21 * nitink YPTM: is on the call
Jul 31 15:00:23 <Song_Liu> YPTM: hi everyone, we are starting the technical meeting now. Who's on the bridge?
Jul 31 15:00:42 <tomz3> YPTM: Tom Zanussi on the call
Jul 31 15:00:45 <jzhang> YPTM: JZHANG here
Jul 31 15:00:59 <RP__> YPTM: is on the call
Jul 31 15:01:08 * fray has a new phone so if there is any problem hearing me please let me know ASAP
Jul 31 15:01:12 <Zagor> trying to get in. is the passcode the same as last month?
Jul 31 15:01:19 <halstead> YPTM: Michael Halstead is on the call.
Jul 31 15:01:24 <zeddii> YPTM: Bruce Ashfield is on the call.
Jul 31 15:01:34 <dvhart> YPTM: Darren Hart is on the call
Jul 31 15:01:38 <RP__> Zagor: yes
Jul 31 15:01:42 <fray> Zagor 76994298#
Jul 31 15:02:09 <Zagor> ok, now I'm in too
Jul 31 15:02:29 * Jefro is on the line
Jul 31 15:02:30 <rburton> YPTM ross burton on the call
Jul 31 15:02:49 <Jefro> and jefro
Jul 31 15:02:50 <rburton> i really need to try skyping the toll-free number...
Jul 31 15:03:05 <pidge> YPTM: dailing in now
Jul 31 15:03:17 <bluelightning> fray: does this one beep also? :)
Jul 31 15:03:33 <fray> no idea.. I doubt it
Jul 31 15:03:46 <fray> Samsung Galaxy S III.. no more PoS blackberry!
Jul 31 15:03:53 <bluelightning> fray: ah, nice
Jul 31 15:04:04 <Song_Liu> YPTM: welcome everyone! Please type out your opens if you have any opens
Jul 31 15:04:08 * kergoth is lurking on the call for once
Jul 31 15:04:40 <jmpdelos> YPTM  Jeff Polk is on
Jul 31 15:04:44 <dvhart> YPTM: call just went silent for me - still going for everyone else?
Jul 31 15:04:49 <zeddii> yep.
Jul 31 15:05:16 <RP__> Song_Liu: YPTM: Probably task about master status as part of the usual update
Jul 31 15:05:22 <Jefro> dvhart zeddii call is still going for me, just moving slowly
Jul 31 15:05:33 <RP__> er, s/task/talk/
Jul 31 15:05:39 <fray> Song_Liu YPTM: come team sharing I want to mention something..
Jul 31 15:05:42 <zeddii> Jefro, get back into coffee. that'll speed things up!
Jul 31 15:06:01 <dvhart> and poof it's back
Jul 31 15:06:07 <Jefro> zeddii can I consider that Dr.'s orders?
Jul 31 15:06:29 <Song_Liu> YPTM: https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.3_Status
Jul 31 15:06:58 <zeddii> Jefro, indeed. got my certificate over the 'net.
Jul 31 15:08:16 <Zagor> a package version bump counts as a feature, right?
Jul 31 15:08:18 <zeddii> YPTM: Song_Liu: random question are the yocto 1.3 milestones on the shared google calendar ? they aren't showing on mine.
Jul 31 15:08:44 <Zagor> in the context of the freeze, that is
Jul 31 15:08:50 <Song_Liu> YPTM: https://wiki.yoctoproject.org/wiki/Yocto_1.3_Schedule#M3_.28July_9_to_Aug._24.2C_2012_--_7_weeks:_planning_done_in_week_1.2C_development_week_1-4.2C_stabilization_week_5-7.2C_release:_week_7.29
Jul 31 15:09:07 <RP__> halstead: The new autobuilders are not 100% configured. Note the "Host key verification failed." near the end of http://autobuilder.yoctoproject.org:8010/builders/nightly-ppc/builds/506/steps/shell_25/logs/stdio
Jul 31 15:09:19 <halstead> RP__, Looking.
Jul 31 15:09:22 <RP__> halstead: also it looks like the network config for the automated sanity testing isn't in place
Jul 31 15:09:29 <RP__> halstead: I suspect something buildhistory related for that
Jul 31 15:10:14 <RP__> halstead: ab06 hasn't changed though, right? (http://autobuilder.yoctoproject.org:8010/builders/nightly-mips/builds/524/steps/shell_33/logs/stdio)
Jul 31 15:10:23 <halstead> RP__, I haven't set up the network config for automated sanity testing yet. So I'll document as I fix it.
Jul 31 15:10:46 <halstead> RP__, Nothing changed except to add ab02 and ab10.
Jul 31 15:11:05 <RP__> halstead: hmm, that failure on ab06 is odd then
Jul 31 15:11:08 <bluelightning> halstead: the error above("Host key verification failed")  is buildhistory trying to push to the repo and failing
Jul 31 15:12:30 <RP__> halstead: Its probably something like the .git directory in the user's homedir
Jul 31 15:13:35 <RP__> halstead: it looks like sanity is failing all over. I'll test locally, looks like something is maybe broken in master :/
Jul 31 15:14:57 <halstead> RP__, We can offline the new Fedora and Debian builders if that would help with troubleshooting.
Jul 31 15:16:31 <pidge> halstead: scp ~/.ssh to the hosts
Jul 31 15:16:46 <halstead> RP__, known_hosts are added for the build_history.
Jul 31 15:16:49 <pidge> halstead: I can work with you after this meeting to get this up
Jul 31 15:17:02 <halstead> pidge, Great.
Jul 31 15:17:12 <kergoth> damn, getting a ton of setscene failures due to the os.symlink() in fetch2 erroring with 'file exists'
Jul 31 15:17:31 <halstead> pidge, I had copied the keys but not the known hosts.
Jul 31 15:17:39 <pidge> ah
Jul 31 15:17:56 <pidge> halstead: also I can help with the sanity tests
Jul 31 15:26:27 * darknighte finally gets IRC working again
Jul 31 15:31:37 <zeddii> YPTM: Bruce Ashfield has to drop the call.
Jul 31 15:33:47 <nitink> pidge: are you next the the circle for the swat team chair ?
Jul 31 15:36:40 <pidge> nitink: Don't know. Am I?
Jul 31 15:37:15 <nitink> pidge: from the list here, you seems next
Jul 31 15:37:20 <nitink> pidge: https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team
Jul 31 15:38:07 <nitink> pidge: thanks beth
Jul 31 15:43:12 <dvhart> man, I'm cutting out for 5 seconds at a time and missing half the discussion :/
Jul 31 15:45:53 <darknighte> dvhart: you can always just make stuff up!  It can be entertaining.  ;)
Jul 31 15:49:52 <dvhart> darknighte, that's what I do anyway, if no-one can hear it... ;-)
Jul 31 15:51:09 * nitink1 rejoined the bridge
Jul 31 15:59:54 <Song_Liu> YPTM: The meeting is closed. Thank you all for joining the meeting, you have a nice day or evening!
Jul 31 16:00:24 <RP__> dvhart: must make the meetings much more fun :)
Jul 31 16:03:10 <halstead> pidge, Do you want to call to look over the new builders?
Jul 31 16:04:44 <pidge> halstead: 9:30?
Jul 31 16:04:53 <halstead> Sure.
Jul 31 16:05:49 <pidge> halstead: ty. my blood coffee level isn't high enough.
Jul 31 16:07:48 <RP__> looks like the qemu image testing is hosed :(
Jul 31 16:13:33 <RP__> hmm, qemuimagetest is ok :/
Jul 31 16:13:47 <RP__> my machine had some stale virtual networks on it
Jul 31 16:14:01 <RP__> halstead: did the networking change on the autobuilders?
Jul 31 16:16:13 <halstead> RP__,  ab04, ab05, & ab06 were rebooted so any networking changes that weren't added to the configuration would have been lost.
Jul 31 16:18:36 <RP__> halstead: Wasn't it supposed to be added to start automticaly?
Jul 31 16:18:47 <RP__> pidge: can you look into this with halstead please?
Jul 31 16:19:05 * RP__ has wasted half an hour poking around that :(
Jul 31 16:19:49 <halstead> RP__, It is. Any network config I set up is definitely persistent. But if any changes were made beyond that they would have been lost.
Jul 31 16:20:09 <RP__> halstead: I was under the impression pidge added someting
Jul 31 16:27:44 <pidge> RP__: there is a bug open for that. halstead: give me a call?
Jul 31 16:29:19 <RP__> pidge: no, I'm just trying to figure out the state of master
Jul 31 16:36:27 <bizhanMona> HI is there any plan to upgrade Yocto linux version in near future?
Jul 31 16:40:42 <zeddii> bizhanMona. only in the dev kernel. the 1.3 release will use 3.4.
Jul 31 16:51:13 * dvhart just realizes his last comment is missing a rather important "but" ... which completely changes the meaning... ah well, that's funny too
Jul 31 16:51:53 <dvhart> bizhanMona, is there a particular feature or version you are looking for?
Jul 31 17:37:04 <pidge> RP__: ab infrastructure should be functional now. I have a patch I'm going to be submitting for runqemu-gen-tapdevs in a few moments.
Jul 31 17:41:53 <bizhanMona> dvhart: I need support for Intel Ivy Bridge I was told it is in 3.4
Jul 31 17:42:22 <dvhart> linux-yocto_3.4 is available in master
Jul 31 17:44:19 <bizhanMona> dvhart: how long till it be part of the main release please?
Jul 31 17:44:50 <dvhart> the next release is 1.3 and will be out in November
Jul 31 17:45:09 <dvhart> But you can use it now
Jul 31 17:45:52 <bizhanMona> oh okay thanks so much for info.
Jul 31 18:33:43 <blloyd|work> is git able to checkout two branches at once?
Jul 31 18:33:56 <blloyd|work> and is that how the kernel build works?
Jul 31 18:36:31 <zeddii> nope.
Jul 31 18:37:13 <zeddii> the meta branch is made 'untracked' so it is globally visible. alternatively it could be merged to every BSP branch, but that just messes up the history when looking for board changes.
Jul 31 18:37:15 <blloyd|work> I'm still lost on how a specific flavor of a kernel is built.  I see references to two branches.
Jul 31 18:37:59 <zeddii> blloyd|work, are you looking at the docs ? If something isn't clear there, we can tweak them.
Jul 31 18:38:00 <blloyd|work> so checkout meta, untrack it, then checkout the branch you want and because the files are untracked they stick around?
Jul 31 18:38:13 <zeddii> blloyd|work. yep, that's it.
Jul 31 18:38:15 <blloyd|work> Yes, I've read docs
Jul 31 18:39:23 <blloyd|work> I'd assume this might be in The Yocto Project Kernel Architecture and Use Manual...  I've been (trying) to read the .bb files too.  Learning python as I go.
Jul 31 18:40:04 <zeddii> IIRC it is in the architecture doc, which we keep trying to move behind more practical documentation :)
Jul 31 18:40:06 <blloyd|work> And git too.  (subversion is the one I've used for most projects and migrated projects towards).
Jul 31 18:40:20 <zeddii> so a doubly whammy of new. :)
Jul 31 18:41:16 <blloyd|work> yup, give me a nice neat makefile or c code and I'm good.  This is hurting my head.  :(
Jul 31 18:41:51 <blloyd|work> However, I can say absolutely one of two things should be documented:
Jul 31 18:42:20 <blloyd|work> 1.  Either NEVER include your auto generated bsp project when not building for that architecture.
Jul 31 18:42:56 <blloyd|work> 2.  Or change the program so the bsp generator so the result doesn't modify kernels when not building for that architecture.
Jul 31 18:44:09 <zeddii> so that's from yocto-bsp ? I'm arms length from that .. you want tomz3 if you are talking yocto-bsp.
Jul 31 18:44:23 <blloyd|work> btw, I should have my machine that is able to participate in mailing lists back in two days.  I'll throw that on there with specifics when I get the machine back.
Jul 31 18:47:23 <blloyd|work> I needed samples.  It made a sample.  I've concluded it isn't the best sample.  But I'm curious: should I be able to add all the meta-intel/meta-* bsps at the same time and then run builds for all of them (using MACHINE=x bitbake core-image-minimal) and get the same results as including one at a time and building it?
Jul 31 18:49:21 <zeddii> .. maybe. dvhart might know. it depends if the layers have any .conf files that when parsed change the system and don't work together.
Jul 31 18:50:05 <blloyd|work> so in general not a good idea to have more than one hardware active at a time?
Jul 31 18:50:15 <blloyd|work> hardware *bsp
Jul 31 18:51:07 <zeddii> it depends on the layers (AFAIK). some layers, like meta-yocto contain support for multiple boards and there's no problem with it.
Jul 31 18:51:10 <kergoth> in general bsp layers should be constructed in such a way that any truly bsp specific changes should be bound by machine, so it *should* be safe to add any number of them together, but that counts on a certain degree of sanity on the part of the bsp layers, so it depends
Jul 31 18:51:15 * kergoth nods
Jul 31 18:56:25 <blloyd|work> so it would not be remiss to want to design new layers to be safe that way.
Jul 31 18:57:09 <blloyd|work> (I think I may be sadistic)
Jul 31 19:04:12 <blloyd|work> ok, section 3.2 of the Kernel guide is all I can find that describes setting up a repository.  It makes it sound like it doesn't just checkout a single branch, but the top one and applies the branches as patches.  Definitely not the same message I got from above discussion.  And still doesn't mention untracking meta and having checked it out.
Jul 31 19:05:35 <blloyd|work> could just be my poor grasp of English though, who knows.
Jul 31 19:12:42 <blloyd|work> how much does it hurt build times to include non-existent directories into the FILESEXTRAPATHS directive?
Jul 31 19:55:58 <JaMa|Off> is it possible to INHIBIT_PACKAGE_STRIP just for some files?
Jul 31 20:01:56 <fray> it has to be done on a -package- basis, not file basis
Jul 31 20:02:48 <fray> if you aren't going to strip, you might also want to inhibit package debug split as well
Jul 31 20:03:18 <fray> the only way around this.. if the item isn't executable, then it isn't processed (I think)
Jul 31 20:18:49 <JaMa|Off> fray: thought so.. I'll rename TUTORIAL.ko to TUTORIAL.KO to resolve that 1 file :)
Jul 31 20:19:49 <fray> .ko files should be ignored.. but just do chmod ugo-x on there and it hsould be fine
Jul 31 20:19:57 <fray> there is no reasona  .ko has to be executable
Jul 31 20:21:51 <JaMa|Off> fray: see http://patchwork.openembedded.org/patch/33365/
Jul 31 20:22:55 <JaMa|Off> I don't see test for executable flag in package.bbclass
Jul 31 20:23:23 <fray> looking just a sec
Jul 31 20:23:28 <JaMa|Off>         for root, dirs, files in os.walk(dvar):
Jul 31 20:23:28 <JaMa|Off>             for f in files:
Jul 31 20:23:28 <JaMa|Off>                 if not f.endswith(".ko"):
Jul 31 20:23:28 <JaMa|Off>                     continue
Jul 31 20:23:28 <JaMa|Off>                 runstrip(os.path.join(root, f), None, d)
Jul 31 20:24:49 <fray> look at lines 747-750
Jul 31 20:24:58 <fray> thats in the split and strip files section
Jul 31 20:25:23 <fray> that is the code that loads up the 'file_list'
Jul 31 20:25:52 <fray> but the .ko files may be treated differently..
Jul 31 21:32:30 <msm> anyone have suggestions on cheap hosting for a mirror?
Jul 31 21:32:43 <msm> want to dump XXX gb of data to be shared over http
Jul 31 21:35:22 <JaMa> fray: yes .ko are treated in lines 868-873 which I pasted
Jul 31 21:35:39 <fray> ya, then a rename is your only choice..
Jul 31 21:35:48 <fray> (short of skipping the whole package)
Jul 31 21:38:21 <blloyd|work> msm: depends on your definition of cheap.  And acceptable access speed, and...
Jul 31 21:38:56 <msm> blloyd|work: just looking for and http mirror ;)
Jul 31 21:39:17 <msm> ideally not limited on speed and availabilty, just billed by space and/or bandwidth used
Jul 31 21:41:14 <khem> I am seeing
Jul 31 21:41:15 <khem> NOTE: multiple providers are available for runtime dbus-x11 (dbus-nativesdk, dbus)
Jul 31 21:41:18 <khem> NOTE: consider defining a PREFERRED_PROVIDER entry to match dbus-x11
Jul 31 21:41:20 <khem> since yesterday
Jul 31 21:41:23 <khem> on master
Jul 31 21:41:30 <khem> poky/master that it
Jul 31 21:41:59 * JaMa too, already replied on commit which cause it
Jul 31 21:42:11 <seebs> I know this is probably silly, but if I wanted to make rpm_log_check use grep -F, would there be a remotely sane way for me to create a string literal in an embedded script that contained newlines?
Jul 31 21:42:53 <khem> JaMa: OK can u point me to commit
Jul 31 21:43:23 <khem> I also want to punt busybox out of image do we have knob for that ?
Jul 31 21:43:50 <JaMa> khem: sure http://lists.linuxtogo.org/pipermail/openembedded-core/2012-July/026915.html
Jul 31 21:46:29 <khem> > +RPROVIDES_${PN} = "dbus-x11"
Jul 31 21:46:29 <khem> > +RREPLACES_${PN} += "dbus-x11"
Jul 31 21:46:47 <khem> should use BPN there
Jul 31 21:46:52 <JaMa> yes
Jul 31 21:47:32 <khem> or use class-override
Jul 31 21:47:46 <JaMa> but then some -nativesdk package can RDEPEND on dbus-x11 and dbus won't provide dbus-x11-nativesdk
Jul 31 21:49:32 <khem> there is a class-override for target recipes too now
Jul 31 21:49:37 <blloyd|work> msm: http://aws.amazon.com/media-sharing/, I know several cost conscious companies using it.
Jul 31 21:52:00 <msm> blloyd|work: thanks, ill look also found rackspace cloudfiles
Jul 31 22:17:36 <kergoth> ERROR: An uncaught exception occured in runqueue, please see the failure below: .. fun
Jul 31 22:20:14 <JaMa> RP, kergoth: BB_SIGNATURE_HANDLER_forcevariable really doesn't work :/ with this small change http://bpaste.net/show/37826/ I see *two* lines - first selecting Noop and then OEBasicHash (with OEBasic selected by local.conf)
Jul 31 22:20:25 <JaMa> WARNING: Returning noop BB_SIGNATURE_HANDLER, BB_SIGNATURE_HANDLER_forcevariable None
Jul 31 22:20:28 <JaMa> WARNING: Returning OEBasicHash BB_SIGNATURE_HANDLER, BB_SIGNATURE_HANDLER_forcevariable OEBasic
Jul 31 22:20:46 <kergoth> it must not be using a finalized copy of the config metadata for that variable
Jul 31 22:25:46 <JaMa> at least in other setup where I'm changing BB_SIGNATURE_HANDLER in DISTRO.conf it does use that variable instead of default OEBasicHash from bitbake.conf
Jul 31 22:26:54 <JaMa> and setting it in local.conf without forcevariable override works too
Jul 31 22:30:49 <JaMa> do you know if BB_SIGNATURE_HANDLER is part of sstate checksums? (will it rebuild everything after change to OEBasicHash, or just reuse sstate and create new stamps for that?
Jul 31 22:31:46 * JaMa still quite far from trying 6791 of 8878..
Jul 31 22:32:21 <RP__> JaMa: it should ignore that value
Jul 31 22:34:07 <JaMa> ok and any hint to change it from local.conf if DISTRO.conf sets it without weak assignment? (and local.conf is read before that - so maybe I can use sanity.conf or something like that which is read after DISTRO.conf)
Jul 31 22:36:32 <RP__> JaMa: We need to figure out why the override didn't work
Jul 31 22:36:46 <Song_Liu> Anyone knows who 'Zagor' is on this morning's technical team meeting call? I think I missed him...
Jul 31 22:41:49 <RP__> Song_Liu: Bjorn from ENEA?
Jul 31 22:42:27 <RP__> JaMa:  Try adding  bb.parse.init_parser(self.configuration.event_data) at the end of the block commented "Special updated configuration we use for firing events" in cooker.py
Jul 31 22:43:52 <JaMa> after bb.data.update_data(..) right?
Jul 31 22:44:42 <RP__> JaMa: yes
Jul 31 22:46:57 <JaMa> RP__: looks better:
Jul 31 22:46:58 <JaMa> WARNING: Returning OEBasicHash BB_SIGNATURE_HANDLER, BB_SIGNATURE_HANDLER_forcevariable OEBasic
Jul 31 22:47:01 <JaMa> WARNING: Returning OEBasic BB_SIGNATURE_HANDLER, BB_SIGNATURE_HANDLER_forcevariable None
Jul 31 22:48:22 <Song_Liu> RP__: Thanks!
**** ENDING LOGGING AT Wed Aug 01 02:59:59 2012

**** BEGIN LOGGING AT Wed Aug 01 02:59:59 2012
Aug 01 08:02:27 <bluelightning> morning all
Aug 01 10:09:04 <tib> karma tib
Aug 01 10:09:38 <tib> yocti: karma tib
Aug 01 10:09:38 <yocti> tib: tib has neutral karma.
Aug 01 10:09:46 <tib> yocti: karma bluelightning
Aug 01 10:09:46 <yocti> tib: Karma for "bluelightning" has been increased 1 time and decreased 0 times for a total karma of 1.
Aug 01 10:09:55 <tib> yocti: bluelightning++
Aug 01 10:10:16 <tib> yocti: karma bluelightning
Aug 01 10:10:16 <yocti> tib: Karma for "bluelightning" has been increased 2 times and decreased 0 times for a total karma of 2.
Aug 01 10:10:32 <bluelightning> woot :)
Aug 01 10:10:49 <tib> Found out about the bot and wanted to thank for earlier help.
Aug 01 10:10:58 <bluelightning> you're welcome :)
Aug 01 14:02:51 <likewise> I'm (also) seeing a regression where the DTS is no longer generated (denzil-next):
Aug 01 14:03:26 <likewise> lib/modules/2.6.35/kernel/lib/libcrc32c.ko
Aug 01 14:03:28 <likewise> Warning: arch/powerpc/boot/dts/p2020rdb.dts is not available!
Aug 01 14:03:30 <likewise> ../linux-powerpc-fsl-2.6.35-r0/git$ ls -ald arch/powerpc/boot/dts/p2020rdb.dts
Aug 01 14:03:31 <likewise> -rw-r--r-- 1 leon leon 13632 2012-08-01 12:23 arch/powerpc/boot/dts/p2020rdb.dts
Aug 01 14:04:11 <likewise> My KERNEL_DEVICETREE has the ${S} prefix in it.
Aug 01 14:04:25 <likewise> Going back to denzil where it worked (TM).
Aug 01 14:05:18 <bluelightning> surely there can't be much difference between denzil and denzil-next atm, it should be pretty easy to see if there is any change that could have caused the issue...
Aug 01 14:22:21 <blloyd|work> tib: bluelightning++
Aug 01 14:22:40 <blloyd|work> yocti: bluelightning++
Aug 01 14:23:15 <blloyd|work> yocto: karma bluelightning
Aug 01 14:23:24 <blloyd|work> yocti: karma bluelightning
Aug 01 14:23:24 <yocti> blloyd|work: Karma for "bluelightning" has been increased 3 times and decreased 0 times for a total karma of 3.
Aug 01 14:23:39 <JaMa> someone using sip.bbclass?
Aug 01 14:23:41 <likewise> bluelightning: meta/recipes-kernel/linux/linux-dtb.inc is to blame
Aug 01 14:24:26 <blloyd|work> yocti: zeddii++
Aug 01 14:24:33 <blloyd|work> yocti: fray++
Aug 01 14:25:00 <JaMa> it depends on sip-native which is not in oe-core (I'm adding it to meta-oe now) and it sets DEPENDS = "sip-native" but do_generate task which is using sip-native is executed before do_configure, so it's not enforced to run sip-native.do_populate_sysroot before do_generate
Aug 01 14:26:00 <bluelightning> JaMa: according to my searches there was only one usage of it in OE-Classic even
Aug 01 14:28:12 <JaMa> I'm adding python-pyqt and python-sip as dependencies of anki
Aug 01 14:34:12 <JaMa> is there some bug with copying LIC_FILES_CHKSUM files? with maybe all -native packages I see warnings like this:
Aug 01 14:34:15 <JaMa> WARNING: /OE/shr-core/tmp-eglibc/work/x86_64-linux/sip-native-4.13.3-r0/sip-4.13.3/sipgen/sipgen.pro could not be copied for some reason. It may not exist. WARN for now.
Aug 01 14:34:21 <JaMa> and file exists
Aug 01 14:37:57 <gotan> hi, question about autotools & autogen & autoopts
Aug 01 14:38:58 <gotan> have an application that requires autoopts, its part of the autogen-native package, but does not seem to be available in the build environment (missing <autoopts/options.h>
Aug 01 14:47:30 <blloyd|work> does your package an appropriate DEPENDS line?
Aug 01 14:47:56 <bluelightning> JaMa: not sure, you'd have to look at the code
Aug 01 14:50:27 <blloyd|work> gotan: did you include a DEPENDS line in your new package?
Aug 01 14:53:18 <gotan> blloyd|work:DEPENDS += "autogen-native" & inherit gettext autotools
Aug 01 15:03:20 <gotan> blloyd|work: possibly a libopts recipe
Aug 01 15:04:09 <blloyd|work> are you just trying to manually build your program or using bitbake/hob?
Aug 01 15:13:10 <gotan> making a recipie for uio kernel module userspace tool. It requires <autoopts/options.h> to compile - which is part of the autogen package and should be installed, and enabled i assumed by autotools include
Aug 01 15:15:23 <gotan> I thought it might be an issue with autogen in poky bing 5.12 not 5.16, but autoopts is also part of 5.12, and poky created the h file, though the package is autogen-native, possibly i need to create a non-native one?
Aug 01 15:16:40 <blloyd|work> gotan: have a do_configure[deptask] = "do_populate_install" (think it's install you are dependent on).  As well?
Aug 01 15:17:54 <blloyd|work> err "do_install'
Aug 01 15:18:17 <gotan> no.
Aug 01 15:18:28 <blloyd|work> someone else will have to validate, I believe yocto uses install to install everything and skips staging.
Aug 01 15:20:38 <blloyd|work> try a do_path[depends] = "autogen-native:do_populate_staging" line and see how it works.  (BitBake manual, chapter 2)
Aug 01 15:21:43 <blloyd|work> you can also try "autogen-native:do_install".
Aug 01 15:22:07 <blloyd|work> do_configure[depends].  My typing is attrocious today.
Aug 01 15:22:33 <blloyd|work> not, do_path (don't ask what I've been drinking, I'm at work).
Aug 01 15:23:17 <gotan> what does do_path[depends] = "autogen-native:do_populate_staging" do?
Aug 01 15:24:21 <blloyd|work> do_configure[depends] = "autogen-native:do_populate_staging" sets a task dependency.  your do_configure task is then dependent on autogen-native:do_populate_staging completing before it runs.
Aug 01 15:25:13 <blloyd|work> I'm just not sure if you need the autogen-native do_install or do_populate_staging task as your pre-requisite.
Aug 01 15:27:09 <gotan> "depends upon non-existent task do_populate_staging"
Aug 01 15:29:08 <gotan> (BitBake manual, chapter 2)-> poky manual?
Aug 01 15:31:17 <gotan> ok
Aug 01 15:44:56 <blloyd|work> no gotan, BitBake manual.  Look in your poky/bitbake/docs, IIRC.
Aug 01 15:45:16 <blloyd|work> and disclaimer: it's not completely current.
Aug 01 15:48:37 <blloyd|work> gotan: try, do_install then.  Tells me it wasn't do_populate_staging.  :)
Aug 01 15:53:38 <bluelightning> I think this is going down the wrong track
Aug 01 15:53:46 <bluelightning> do_install itself doesn't stage anything
Aug 01 15:54:33 <bluelightning> having autogen-native in DEPENDS should be enough; if it isn't that likely means the needed files aren't staged at all
Aug 01 15:54:39 <blloyd|work> I'd listen to bluelightning over me.
Aug 01 15:54:46 <bluelightning> seems he's gone anyway...
Aug 01 15:56:01 <blloyd|work> hopefully looking at the manual I pointed him to.  I can do at least that much.
Aug 01 15:59:10 <bluelightning> for the record, staging occurs after do_install (in do_populate_sysroot), it's just that what gets staged comes from what is installed
Aug 01 16:01:07 <bluelightning> I believe putting recipe A into DEPENDS within recipe B is the equivalent of adding do_populate_sysroot of A to B's do_configure[depends]
Aug 01 16:22:10 <likewise> gm
Aug 01 16:22:40 <jstashluk> How do I tell my new package which toolchain to use?
Aug 01 16:23:11 <jstashluk> I am getting 'make: arm-none-linux-gnueabi-g++: Command not found'
Aug 01 16:26:05 <kergoth> how you tell your software what toolchain to use depends onthe software. examine its buildsystem and figure it out
Aug 01 16:42:46 <bluelightning> jstashluk: if you are using -b, don't
Aug 01 16:43:28 <bluelightning> (if you aren't, no worries)
Aug 01 16:47:04 <jstashluk> bluelightning: Nope, that isn't it.
Aug 01 16:47:49 <jstashluk> Somewhere poky builds all of the packages for mx6, and figures out correctly to use arm-linux-gnueabi-* tools.
Aug 01 16:54:59 <bluelightning> jstashluk: ok, in which case it sounds like whatever you are building may be hardcoded to use arm-none-linux-gnueabi-g++ (or it has some broken logic to figure out the OS)
Aug 01 16:55:56 <bluelightning> jstashluk: FWIW, we set CXX to the appropriate C++ compiler, so if you can ensure the build system your app is using uses that, all should be well
Aug 01 16:56:04 <jstashluk> I think arm-none-linux-gnueabi-g++ is somehow the default (as I never specify it), and needs to be overridden.
Aug 01 16:56:22 <bluelightning> jstashluk: are the makefiles autogenerated or static?
Aug 01 16:56:31 <jstashluk> static
Aug 01 16:57:17 <jstashluk> bluelightning: Thanks. yup, right there in the Makefile.
Aug 01 17:26:11 <khem> RP__: I think AUTOREV does not go well with BB_NO_NETWORK
Aug 01 17:26:48 <zeddii> khem. indeed it doesn't.
Aug 01 17:27:55 <khem> zeddii: so what do we do there ?
Aug 01 17:28:17 <khem> since internally folks may want to fetch the latest
Aug 01 17:28:41 <khem> actually fetcher is trying to do git ls-remote
Aug 01 17:28:52 <zeddii> it depends on what exact problem you are seeing. when I tried it, I was seeing the SRCREV checks
Aug 01 17:29:11 <zeddii> khem. I use a file based protocol + local repository.
Aug 01 17:29:19 <khem> so may be we can make it git ls-remote not a hard error when doing BB_NO_NETWORK
Aug 01 17:29:26 <zeddii> since I refuse to update SRCREVs internally ;)
Aug 01 17:29:31 <zeddii> but that would work as well.
Aug 01 17:29:52 <khem> zeddii: git://somewhere/protocol=file ?
Aug 01 17:29:55 <zeddii> it's not actually downloading anything in that sense,  but how long does git hang if there's really no network ?
Aug 01 17:29:58 <zeddii> khem, yes.
Aug 01 17:30:22 <khem> not long
Aug 01 17:30:28 <khem> it takes may be a minute
Aug 01 17:31:12 <khem> zeddii: in OE we shouldnt allow AUTOREV then
Aug 01 17:31:31 <khem> or use it in conjunction with file proto
Aug 01 17:31:47 <khem> I wonder if that will fly with other fetchers
Aug 01 17:31:56 <khem> fray: around ?
Aug 01 17:31:59 <zeddii> are there any in oe-core currently ? my only use is in meta-kernel dev and it uses file proto in that case.
Aug 01 17:32:16 <khem> no I havent seen one but I have seen in layers
Aug 01 17:33:16 <zeddii> at least it isn't rampant.
Aug 01 18:00:47 <RP__> khem: that doesn't surprise me
Aug 01 18:11:22 <dvhart> finally got remote gdb working to connect to the target and debug the ssh server.... only to find that with gdbserver connected to dropbear, the server no longer accepts any connections :-(
Aug 01 19:08:00 <msm> zenlinux: im seeing these again https://gist.github.com/3229861
Aug 01 19:08:10 <msm> the checksumerror class is not defined in denzil
Aug 01 19:19:35 <zenlinux> msm, yeah, I've not been good about following up on that - I know which patch we need, but it doesn't apply cleanly. I'm going to refactor it to address this for good after lunch today
Aug 01 19:20:01 <msm> zenlinux: i think
Aug 01 19:20:21 <msm> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=mattsm/denzil&id=afecfe67ec56c39a966e233f1e3deea7d3dbd202
Aug 01 19:20:26 <msm> this is an acceptable approach too
Aug 01 19:21:09 <zenlinux> hmmm, that might make things much simpler
Aug 01 19:21:20 <zenlinux> thanks for that, I may give that a spin and run it by RP
Aug 01 19:21:55 <seebs> kergoth, a heads-up about external-sourcery-toolchain.bb: the sed that alters the linker script can produce DEEPLY surprising results.
Aug 01 19:21:57 <msm> zenlinux: im doing a full build now
Aug 01 19:22:03 <msm> zenlinux: will let you know
Aug 01 19:22:26 <zenlinux> msm, also, I've taken note of your foomatic-filters patch for Fedora17. Once that hits master I can pull that into my denzil branch
Aug 01 19:22:48 <msm> zenlinux: awesome, thanks
Aug 01 19:22:56 <seebs> The alteration from /lib/libc.so.6 to ../../lib/libc.so.6 has the side-effect that if you are running the compiler (with suitable $PATH, sysroot, etc.) in a directory only two layers deep, the compiler ends up trying to open the host's /lib/libc.so.6, because it passes the ../.. path to open() directly before trying in the sysroot.
Aug 01 19:23:14 <msm> zenlinux: that's mostly all my fixes for denzil so far - we will start heavy testing over the next 4-5 weeks so a few more things might come up
Aug 01 20:11:36 <bizhanMona> Hello all, is Yocto distribution could be configured as 32 and 64 bit for X86 processor?
Aug 01 20:11:59 <kergoth> for the target? yes, of course
Aug 01 20:12:38 <bizhanMona> kergoth: thanks what is the default for SandBridge target, 64 or 32?
Aug 01 20:12:50 <kergoth> bitbake -e | grep TARGET_ARCH=
Aug 01 20:12:55 <kergoth> or read the machine files
Aug 01 20:13:11 <bizhanMona> kergoth: thanks so much
Aug 01 20:16:57 <zenlinux> msm, I've taken your ChecksumError removal patch, reworded the commit log a bit, and rebased it into my branch so it's immediately after the other fetch2 changes. http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=sgarman/denzil-next
Aug 01 20:17:09 <zenlinux> I think with this, I'm finally ready to queue this up on the autobuilder
Aug 01 20:22:37 <msm> zenlinux: good deal, im building for poky's 4 targets also on fc13 fc17 ubuntu 12.04 and centos 5.x
Aug 01 20:27:16 <khem> RP__: when creating the local mirror for download dir do we need to keep git2/ dirs too ?
Aug 01 20:27:28 <khem> RP__: I see that it has generated tarballs as well.
Aug 01 20:27:36 <RP__> khem: not if the tarballs are up to date
Aug 01 20:27:47 <khem> RP__: ok.
Aug 01 20:28:11 <khem> msm: for kernel in meta-fsl-ppc it still wants to talk to git.fsl.com
Aug 01 20:28:18 <khem> when BB_NO_NETWORK is set
Aug 01 20:29:08 <msm> khem: hmm
Aug 01 20:29:29 <msm> khem: why just this one? there is not much special
Aug 01 20:30:25 <khem> yeah I dont know I think we have SRCREV = "sometag"
Aug 01 20:30:27 <kergoth> after a bitbake -g core-image-base:
Aug 01 20:30:28 <kergoth> $ grep sdk pn-buildlist|wc -l
Aug 01 20:30:29 <kergoth> 29
Aug 01 20:30:35 * kergoth rolls eyes
Aug 01 20:31:45 <khem> RP__: this seems a problem to me in fetcher when I have network disabled it wants to go and talk to git server when I enable network it works ok but does not create any new tar for me so I assume the kernel is same as I had
Aug 01 20:31:58 <khem> then why in first place it went out looking for it
Aug 01 20:32:11 <khem> it does not use autorev
Aug 01 20:33:30 <khem> msm: interesting bit is that if I change SRCREV to a given sha id then it works fine
Aug 01 20:34:30 <khem> so probably anything thats not in sha form for SRCREV
Aug 01 20:34:39 <khem> msm: we have a tag in the recipe
Aug 01 20:35:00 <khem> tag is probably treated same as autorev by fetcher
Aug 01 20:41:09 <blloyd|work> khem: isn't that logical, can't tags be changed (ie deleted then created to point somewhere else).
Aug 01 20:41:54 <msm> khem: so we need to revert that change?
Aug 01 20:42:10 <msm> blloyd|work: its possible, although unlikely...
Aug 01 20:42:25 <msm> its not entirely secure though i suppose
Aug 01 20:44:18 <blloyd|work> sorry, just pointing out.  I'd already found the delete tag command in git, so not hard for a noob to do.
Aug 01 21:13:11 <kergoth> seebs: do you have example usage of the tuneabi stuff anywhere, by chance?
Aug 01 21:13:17 <kergoth> never really had a chance to look at it
Aug 01 21:13:25 <kergoth> s/look at/use/
Aug 01 21:13:45 <seebs> I have some in our stuff. Lemme see if I can find a useful example.
Aug 01 21:13:54 <kergoth> k, that'd be cool, thanks
Aug 01 21:18:29 <seebs> aaand my laptop is out of sync with my trees again, so getting a reasonably-current example is going to take about 30x longer than I thought.  :P
Aug 01 21:19:29 <kergoth> heh, no rush, doubt i'll have time to play with it anytime soon anyway :)
Aug 01 21:20:30 <seebs> BTW, that sysroot thing you sent me? I just got a complaint that my setup was working great for projects, but exported sysroots weren't working.
Aug 01 21:20:36 <seebs> So. Yeah. Nice to have the fix in hand.
Aug 01 21:38:45 <bizhanMona> Hi I am getting time out server on this link: git clone git://git.yoctoproject.org/poky.git  any reason?
Aug 01 22:29:36 <kergoth> ugh, i just realized bb.event doesn't run event handlers in registration order
Aug 01 22:29:46 * kergoth mutters
Aug 01 22:30:25 <jawilson> is there something I can put in a .bbappend to ignore the recipe altogether?
Aug 01 22:32:37 <kergoth> what are you trying to accomplish?
Aug 01 22:33:49 <jawilson> kergoth, well I'm trying to get my own psplash to play nice in angstrom, and bitbake keeps complaining about multiple providers and multiple .bb files to be built
Aug 01 22:34:30 <kergoth> so define PREFERRED_PROVIDER the way you're supposed to
Aug 01 22:34:55 <jawilson> I've tried adding PREFERRED_PROVIDER to my image recipe and local.conf for both psplash-support and virtual/psplash
Aug 01 22:35:20 <kergoth> preferred provider is a config variable, putting it in a recipe will do nothing
Aug 01 22:35:42 <jawilson> ok, well it's in my local.conf...
Aug 01 22:36:22 <jawilson> wait a sec
Aug 01 22:41:46 <jawilson> kergoth, yup, I'm an idiot, I had it set wrong, thanks
Aug 01 22:43:38 <jawilson> relatedly, all the alternative psplash recipes define the SRC_URI with "git://git.yoctoproject.org/${BPN}" I assume the ${BPN} is supposed to be just "psplash" but it's the whole PN (i.e. psplash-ti)
Aug 01 22:43:50 <jawilson> any idea how to fix that?
Aug 01 22:48:10 <kergoth> override BPN or SRC_URI in psplash-ti
Aug 01 22:51:55 <jawilson> yeah, that's what I do, just curious why it doesn't work like it's supposed to
Aug 01 22:52:20 <kergoth> it does exactly what it's supposed to do.
Aug 01 22:52:32 <kergoth> BPN is PN without any native/nativesdk/cross/crosssdk suffix
Aug 01 22:52:37 <kergoth> that's all it is
Aug 01 22:52:45 <kergoth> it isn't going to magically start removing random characters from PN
Aug 01 22:53:09 <jawilson> hmm, wonder why the recipe is wrong, because that repo doesn't exist
Aug 01 22:53:22 <jawilson> and there's two others just like it
Aug 01 22:53:45 <kergoth> report the issues to whomever is responsible for them
Aug 01 23:04:44 <chackal_sjc> guys
Aug 01 23:04:52 <chackal_sjc> just a off-topic stuff
Aug 01 23:05:15 <chackal_sjc> i have a ssh server, my device..
Aug 01 23:05:43 <chackal_sjc> and I added my public key in the authorized_keys on the device
Aug 01 23:06:16 <chackal_sjc> but its always asking the password for the private key for me.. but a co-worker that has the same environment it doesn't
**** ENDING LOGGING AT Thu Aug 02 02:59:59 2012

**** BEGIN LOGGING AT Thu Aug 02 02:59:59 2012
Aug 02 07:48:59 <tib> When reading up on Intel's JTAG debugger 2.3 it is supposed to be adapted for Yocto - is there anything specific that needs to be done to use it on Yocto driven hardware or is it just to use it normally and then install the idbntf.ko module if nessecary?
Aug 02 07:49:54 <tib> And what is the proper way to set NAT ranges with runqemu when starting a qemux86?
Aug 02 09:29:09 <JaMa> bluelightning: I haven't looked what you did in last buildhistory update, but now it's 1000% faster here, thanks a lot.. testing your current update now
Aug 02 09:29:38 <bluelightning> JaMa: yeah, the querying stuff should be a lot less intensive now
Aug 02 09:29:44 <bluelightning> JaMa: thanks, let me know what you find
Aug 02 09:42:06 <tib> What have you done? Will the general bake speed improved?
Aug 02 09:48:03 <bluelightning> tib: no, just the speed of gathering information when buildhistory is enabled
Aug 02 09:48:21 <bluelightning> tib: in case you were wondering - https://wiki.yoctoproject.org/wiki/Buildhistory
Aug 02 09:51:39 <blitz00> http://pastebin.com/5qK16gcj
Aug 02 09:53:11 <blitz00> one of the nightly core-image-sato-sdk images doesn't come with pkgconfig installed. Installing it with zypper works but then if I want to remove it...
Aug 02 09:53:54 <bluelightning> blitz00: hmm, that's a pretty nasty bug... would you mind filing a bug in bugzilla about it?
Aug 02 09:54:40 <blitz00> I was about to do that
Aug 02 09:54:51 <blitz00> any suggestion for a component?
Aug 02 09:55:04 <blitz00> I've met this on sugarbay images and emenlow too
Aug 02 09:56:01 <blitz00> one of the tc for weekly images fails because pkgconfig isn't installed in the sdk image, installing and then trying to remove it gives that nasty thing
Aug 02 10:01:46 <bluelightning> blitz00: I would say core for something rpm-related
Aug 02 10:01:55 <bluelightning> if it turns out to be bsp specific we can move it
Aug 02 10:13:59 <blitz00> https://bugzilla.yoctoproject.org/show_bug.cgi?id=2878
Aug 02 10:15:52 <blitz00> what's weird is that zypper remove pkgconfig tries to remove a lot of -dev pks. If they depend on pkgconfig how come pkgconfig wasn't installed in the first place?
Aug 02 10:24:56 <bluelightning> blitz00: we don't use zypper to create the root filesystem, so it could be that zypper's idea of dependencies is slightly different from what we use to do the rootfs construction
Aug 02 10:24:59 <bluelightning> it shouldn't be however
Aug 02 10:36:22 <gotan> question: BUILD_CFLAGS, it is exported into the environment, but i cannot see where it is being picked up and used in the makefile.
Aug 02 16:07:22 <jstashluk> otavio: ping
Aug 02 16:07:42 <JaMa> bluelightning: btw: you cannot share sstate of package tasks between host with and without buildhistory enabled ;/
Aug 02 16:08:13 <JaMa> bluelightning: Variable PACKAGEFUNCS value changed  (now including buildhistory_emit_pkghistory)
Aug 02 16:08:57 <bluelightning> JaMa: it would be tricky to fix that unfortunately :/
Aug 02 16:09:28 <kergoth> JaMa: heh, enabling/disabling buildhistory in concert with sstate is problematic anyway. without that, you'd get no buildhistory info, as it only runs when do_package runs, not when do_package_write_setscene or whatever is run
Aug 02 16:09:38 <kergoth> either leave it enabled or leave it disabled, i'd say
Aug 02 16:11:08 <JaMa> bluelightning: I was expecting that.. now I'll update default config to enable buildhistory also for SSTATE_MIRROR users (now it's much faster so doesn't hurt :))
Aug 02 16:11:29 <bluelightning> JaMa: you can always inherit and disable it...
Aug 02 16:11:37 <bluelightning> BUILDHISTORY_FEATURES = ""
Aug 02 16:13:51 <JaMa> ah nice
Aug 02 16:14:23 <JaMa> that way sstate doesn't find different buildhistory_emit_pkghistory fce?
Aug 02 16:14:26 <kergoth> probably not a good idea, at least if you ever want package buildhistory data, since if something comes from sstate, it won't generate it. either buildhistory_features is in teh checksums, in which case you're in the same boat as you were with PACKAGEFUNCS, or it's not, and you'd have to manually cleansstate
Aug 02 16:14:42 <kergoth> but as long as you keep that in mind..
Aug 02 16:16:07 <kergoth> hmm, the recent pass of CC in EXTRA_OEMAKE in u-boot.inc broke builds with older u-boots (e.g. 2009.11), fyi
Aug 02 16:16:35 <kergoth> tools/Makefile sets CC = $(HOSTCC), but the commandline is being passed into the submake and overriding it, causing it to build mkimage cross
Aug 02 16:16:52 * kergoth hacks around it via SUBDIRS= in those recipes
Aug 02 16:18:56 <JaMa> kergoth: so with it enabled it will reuse sstate cache, but provide no buildhistory data, right?
Aug 02 16:19:28 * kergoth nods
Aug 02 16:21:53 <kergoth> but if you're just enabling it for debugging or so, it's no big deal to manually cleansstate after adding package to the buidlhistory features
Aug 02 16:24:11 <ag_> Hello everybody!
Aug 02 16:24:26 <ag_> bluelightning: I think that rm error is from pseudo.
Aug 02 16:25:00 <ag_> Is there anybody who can test that a rm on a >2GB file works in a fakeroot function?
Aug 02 16:25:22 <JaMa> kergoth: I plan to keep it enabled forever on all my builders :)
Aug 02 16:26:22 <kergoth> probably best :)
Aug 02 17:02:31 <kergoth> | .depend:626: *** multiple target patterns.  Stop.
Aug 02 17:02:36 <kergoth> anyone seen this u-boot failure before?
Aug 02 17:05:41 <otavio> jstashluk: pong
Aug 02 17:48:01 <likewise> hi zenlinux
Aug 02 18:06:46 <zenlinux> hi like|away
Aug 02 18:23:08 <msm> has anyone ever seen this: https://gist.github.com/3239379
Aug 02 18:23:26 <msm> seems almost impossible that the same random file name was used
Aug 02 18:24:04 <msm> this is on denzil btw so maybe there was an upstream fix
Aug 02 18:24:27 <kergoth> i'd guess its some temporary thing used by quilt, but *shrug*
Aug 02 18:32:30 <msm> kergoth: well, let's see if I ever see it again ;)
Aug 02 18:32:41 <msm> i have a feeling this is a one time thing...
Aug 02 18:39:01 * kergoth argues with the new sstate dir layout
Aug 02 18:48:21 <kergoth> hmm, did bitabke's -l argument stop working at some point?
Aug 02 18:49:50 <AdityaGandhi> Hi , another simple question! Where does the default xorg.conf get generated . And how do I edit the default conf file?
Aug 02 18:51:52 <JaMa> AdityaGandhi: stored in openembedded-core/meta/recipes-graphics/xorg-xserver/xserver-xf86-config and you can overwrite it with your own with .bbappend
Aug 02 18:52:09 <AdityaGandhi> Thanks a lot Jama!
Aug 02 18:52:18 <AdityaGandhi> Will do!
Aug 02 19:26:52 <jstashluk> otavio: I found a bug in the latest meta-fsl-arm/classes/image_types_fsl.bbclass commit.
Aug 02 19:30:52 <jstashluk> otavio: what is the best way to get it to you?
Aug 02 19:44:59 <kergoth> wow, i just fed a SSTATE_MIRRORS that caused bitbake to basically infinite loop
Aug 02 19:45:28 <kergoth> actually, found two differnet lines that'll do it
Aug 02 19:50:54 * kergoth sighs
Aug 02 19:51:14 <RP__> kergoth: :(
Aug 02 19:51:44 <kergoth> it's hard to cover every case in code like this
Aug 02 19:51:49 <kergoth> so many outliers and corner cases
Aug 02 19:52:11 * kergoth 'll see about adding a test for this one
Aug 02 20:05:22 <RP__> kergoth: thanks
Aug 02 21:27:01 <plextoriano> Hi, someone can say me how can i flash the core-image-minimal in compact flash?
Aug 02 21:28:01 <AdityaGandhi> Do you have like a compact flash reader for your PC
Aug 02 21:28:26 <AdityaGandhi> Try connecting it, just unmount the compact flash if automatically mounted
Aug 02 21:28:39 <AdityaGandhi> assume the flash drive is /dev/sdb
Aug 02 21:28:41 <plextoriano> yes, I save correctly but when boot from cf, the system is waiting removable drive
Aug 02 21:28:58 <AdityaGandhi> navigate to your image folder
Aug 02 21:29:20 <AdityaGandhi> ohhh
Aug 02 21:29:30 <AdityaGandhi> Okay, its a similar problem as booting from HDD
Aug 02 21:30:31 <plextoriano> any idea?
Aug 02 21:30:57 <AdityaGandhi> Sorry I may not be able to help you there, I think your kernel needs to mount the compact flash
Aug 02 21:31:04 <AdityaGandhi> before running init scripts
Aug 02 21:31:12 <AdityaGandhi> i mean in your init.rd
Aug 02 21:31:26 <AdityaGandhi> I am not sure though, new to kernel
Aug 02 21:31:50 <plextoriano> ok i will try this
Aug 02 21:32:26 <AdityaGandhi> In your init.rd you could run a script to mount compact  flash, and then direct your root drive to that mount partition
Aug 02 21:33:27 <challinan> haven't spent much time with yocto-linux - is it still valid to do: file://defconfig to override a complete config in a linux .bbappend file? or must I use config fragments.  Will this be overridden by other fragments elsewhere?
Aug 02 21:33:43 <plextoriano> thanks AdityaGandhi
Aug 02 21:41:08 <seebs> Ugh.
Aug 02 21:41:24 <seebs> So it turns out that there is a fairly easy way to make pseudo Very Unhappy, probably, on 32-bit-ish Linux.
Aug 02 21:41:39 <seebs> Which is to build stuff using _FILE_OFFSET_BITS=64, but not build pseudo that way. Or vice versa.
Aug 02 21:42:02 <seebs> And this turns out to reveal all SORTS of exciting stuff.
Aug 02 21:43:01 <seebs> hmm
Aug 02 21:50:39 <AdityaGandhi> Hi guys I am getting an error which I cannot even begin to debug, please help
Aug 02 21:50:41 <AdityaGandhi> inforcecomputing@inforcecomputing-PRIMERGY-TX100-S3:~/Resources/Yocto/new/poky-denzil-7.0/build$ bitbake firefox
Aug 02 21:50:41 <AdityaGandhi> WARNING: Host distribution "Ubuntu 10.10" has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution.
Aug 02 21:50:41 <AdityaGandhi> NOTE: Error expanding variable do_unpack                                                                                                     | ETA:  00:00:27
Aug 02 21:50:41 <AdityaGandhi> NOTE: Error during finalise of /home/inforcecomputing/Resources/Yocto/new/poky-denzil-7.0/meta-oe/recipes-support/lzma/lzma_4.65.bb
Aug 02 21:50:44 <AdityaGandhi> ERROR: Unable to parse /home/inforcecomputing/Resources/Yocto/new/poky-denzil-7.0/meta-oe/recipes-support/lzma/lzma_4.65.bb
Aug 02 21:50:47 <AdityaGandhi> ERROR: Command execution failed: Exited with 1
Aug 02 21:50:49 <AdityaGandhi> Summary: There was 1 WARNING message shown.
Aug 02 21:50:51 <AdityaGandhi> Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
Aug 02 21:51:52 <AdityaGandhi> I have added meta-browser-layer from openembedded layers list, and got the meta-oe layer as it is required by meta-browser-layer
Aug 02 21:53:00 <kergoth> please use a pastebin
Aug 02 21:53:33 <AdityaGandhi> sure sorry
Aug 02 21:55:21 <AdityaGandhi> http://pastebin.com/CyqQ2tjw
Aug 02 21:55:52 <AdityaGandhi> I thought it might be okay for a few lines, I will be sure not to paste multiple lines again
Aug 02 21:57:50 <kergoth> 2 lines, yes, 5+, not so much :)
Aug 02 21:58:35 <AdityaGandhi> sure, could you guide me where to start debugging this problem
Aug 02 22:06:07 <RP__> seebs: Seems to be an interesting challenge :/
Aug 02 22:06:19 <RP__> seebs: I wondered when I saw the patch...
Aug 02 22:06:33 <seebs> I have a couple of answers. One is to change (rc == -1) to (rc == -1 && errno != EOVERFLOW).
Aug 02 22:06:54 <seebs> Another is to develop time travel, track Linus down right around the time he's starting to type, and say YOU NEED SIXTY-FOUR BIT FILE SIZES.
Aug 02 22:07:11 <seebs> And past that we have stuff like figuring out a general solution to this.
Aug 02 22:07:21 <seebs> Which I regard as substantially less likely to succeed than the time travel.
Aug 02 22:08:32 <RP__> seebs: If you do get the time travel working, there are a few messages I could do with back a few years too ;-)
Aug 02 22:08:46 <seebs> We know it'll never happen because electrons are negative.
Aug 02 22:08:55 <seebs> If you could tell people things in the past, electrons would be positive.
Aug 02 22:09:14 <RP__> seebs: positive electrons exist, they've called positrons
Aug 02 22:09:34 <seebs> Yeah, but the common things would have been given positive sign so we'd have a much easier time talking about electricity.
Aug 02 22:10:11 <seebs> Well, question #1: Does anyone have any idea whether it is consistent/expected that stat() is yielding complete stat bufs when it hits an overlarge file?
Aug 02 22:10:19 <seebs> It returns -1, but the buffer appears to have the expected contents.
Aug 02 22:10:46 <RP__> seebs: I don't really want to think about it at this time of night, thanks ;-)
Aug 02 22:11:01 * RP__ has enough trouble sleeping atm
Aug 02 22:11:06 <seebs> k.
Aug 02 22:17:15 <AdityaGandhi> Guys help with integrating browser-layer with crownbay-bsp for yocto
Aug 02 22:17:16 <AdityaGandhi>  http://pastebin.com/CyqQ2tjw
Aug 02 22:17:31 <AdityaGandhi> I have added browser-layer from layers list and meta-oe,
Aug 02 22:17:34 <kergoth> repeating yourself isn't going to magically get you help
Aug 02 22:30:18 <seebs> Oh, PHEW!
Aug 02 22:30:35 <seebs> If you build with -D_FILE_OFFSET_BITS=64, your code really is linked against stat64.
Aug 02 22:30:41 <seebs> So pseudo will be fine. Hmm.
Aug 02 22:30:54 <seebs> But that also means I can't just use that to get out of this mess.
Aug 02 22:53:10 <AdityaGandhi> hey I have a more detailed log, of the error here
Aug 02 22:53:11 <AdityaGandhi> http://pastebin.com/9qpcbHyJ
Aug 02 22:53:34 <AdityaGandhi> DEBUG: while parsing oe_runconf, unable to handle non-literal command '${CACHED_CONFIGUREVARS}'
Aug 02 22:53:54 <AdityaGandhi> thats where I think is the critical point is!
Aug 02 22:55:40 <kergoth> nope, sorry to say that's a red herring, and only has to do with the code which tracks variable dependencies
Aug 02 22:55:50 <kergoth> which is why it' s a debug message, not a warning or error
Aug 02 22:57:57 <AdityaGandhi> I will paste a line from lzma.inc which adds to the  do_unpack
Aug 02 22:57:58 <AdityaGandhi> # Replace MS-DOS line-endings with Unix style line-endings
Aug 02 22:57:58 <AdityaGandhi>     oe.process.run("find . -type f -print0 | xargs -0 sed 's/\r$//' -i",
Aug 02 22:57:58 <AdityaGandhi>                cwd=d.getVar("S", True))
Aug 02 22:58:14 <AdityaGandhi> does it have to with the line ending from dos?
Aug 02 22:59:22 <kergoth> is that a trick question?
Aug 02 22:59:27 <kergoth> the comment says exactly that
Aug 02 23:00:30 <AdityaGandhi> I am unsure how t change or what to change, quiet unfamiliar with recipes
Aug 02 23:00:34 <seebs> ...
Aug 02 23:00:58 <AdityaGandhi> could you suggest what do I change here
Aug 02 23:01:01 <seebs> How much do I have to bribe RP to accept bitbake patches in which I introduce comments which are completely and humorously misleading?
Aug 02 23:01:46 <seebs> Okay, first, ignore all the DEBUG messages, at least for now.
Aug 02 23:01:51 <seebs> Look at the ERRORs first.
Aug 02 23:02:22 <seebs> Do you have a copy of this lzma.bb file up that I could look at?
Aug 02 23:03:51 <AdityaGandhi> Here , phttp://pastebin.com/zKj4ptPk
Aug 02 23:04:13 <AdityaGandhi> that would be great thanks
Aug 02 23:05:31 <seebs> Hmm.
Aug 02 23:05:32 <seebs> NOTE: Error expanding variable do_unpack
Aug 02 23:05:57 <seebs> You have a do_unpack_append, which looks to be python.
Aug 02 23:06:11 <seebs> Do you know whether the base do_unpack is also python? I don't know how _append works in that case.
Aug 02 23:06:58 <AdityaGandhi> sorry seebs, I do not know
Aug 02 23:07:19 <AdityaGandhi> here is my lzma_4.65.bb file http://pastebin.com/AtuYgyL9
Aug 02 23:07:25 <AdityaGandhi> if it is anyhelp
Aug 02 23:07:57 <seebs> I guess the first thing I'd do is comment out the do_unpack, and see whether that error goes away. You may then have line-ending problems, but you'll be able to see what the do_unpack looks like.
Aug 02 23:09:53 <AdityaGandhi> It did go away
Aug 02 23:10:04 <AdityaGandhi> but I got another one
Aug 02 23:10:18 <seebs> Okay. Then my first candidate explanation will be that the do_unpack_append was in some way incompatible with the existing do_unpack.
Aug 02 23:10:51 <AdityaGandhi> hmmm, that could be because I have meta-oe from openembedded , using it with yocto
Aug 02 23:11:05 <seebs> That would not be my first explanation.
Aug 02 23:12:00 <AdityaGandhi> I got the same error with opencv_2.4.bb
Aug 02 23:12:20 <AdityaGandhi> where do I check what is the base do_unpack like
Aug 02 23:13:20 <seebs> build/tmp/work/<system>/<package>/temp/do_unpack/run.do_unpack.*
Aug 02 23:17:36 <AdityaGandhi> would it be bad to say I do not have the folder for browser layer or lzma
Aug 02 23:18:15 <AdityaGandhi> I mean I have just added them in my bblayers.conf and trying to compile packages for firefox
Aug 02 23:18:36 <AdityaGandhi> Do I need to do anything more to add the firefox package to my build?
Aug 02 23:19:24 <seebs> Heck if I know. I don't do much with packages, just toolchains.
Aug 02 23:19:50 <kergoth> "the folder for browser layer or lzma" — what?
Aug 02 23:21:01 <AdityaGandhi> I tried compiling bitbake lzma-native
Aug 02 23:21:15 <AdityaGandhi> and bitbake firefox , separately
Aug 02 23:22:02 <AdityaGandhi> both folder do no exist in any of the folder is have which are all-poky-linux, core2-poky-linux crownbay-poky-linux x86_64-linux
Aug 02 23:24:36 <seebs> I am not quite sure what you are talking about.  I assume by "folder" you mean "directory". But I am pretty sure you have several thousand more directories than those.
Aug 02 23:24:47 <seebs> So you are probably talking about directories in a particular location, but I can't imagine where.
Aug 02 23:25:37 <AdityaGandhi> okay seebs sugessted to check do_unpack in  build/tmp/work/<system>/<package>/temp/do_unpack/run.do_unpack.*
Aug 02 23:25:55 <AdityaGandhi> so I am looking for the <package> directory
Aug 02 23:26:28 <seebs> Well, hmm. If something else failed, that may not have come into existence.
Aug 02 23:26:35 <seebs> I was assuming that the rest of the parse would succeed.
Aug 02 23:26:41 <AdityaGandhi> okay that makes sense
Aug 02 23:27:32 <AdityaGandhi> no It didn't i had a problem with openCV  NOTE: Error expanding variable populate_packages
Aug 02 23:30:52 <AdityaGandhi> http://pastebin.com/R47yi2p0
Aug 02 23:31:03 <AdityaGandhi> here is the opencv.bb
Aug 02 23:40:58 <seebs> I have a speculative notion.
Aug 02 23:41:14 <seebs> ... no, nevermind.
Aug 02 23:41:23 <seebs> There are sometimes indentation inconsistencies, but not seeing any this time.
Aug 02 23:41:55 <seebs> FWIW, if anyone's interested in #2881 (pseudo causing rm failures on files over 2GB on 32-bit hosts), I have a proposed fix, which I have tested enough that it's currently tagged as PSEUDO_1_4_1.
Aug 02 23:59:07 <AdityaGandhi> hey thanks seebs looks like just a parsing error
Aug 02 23:59:25 <AdityaGandhi> fixing spaces for each failure
Aug 03 00:01:25 <seebs> spacing can do it, and it's not always 100% consistent between parts of the build system.
Aug 03 00:38:26 <AdityaGandhi> I have a new error with parsing,  ould not inherit file classes/pythonnative.bbclass
Aug 03 00:38:32 <AdityaGandhi> could not inherit file classes/pythonnative.bbclass*
Aug 03 00:51:14 <AdityaGandhi> Hi there is no class file called pythonnative.bbclass in /poky/meta/classes/
**** ENDING LOGGING AT Fri Aug 03 02:59:58 2012

**** BEGIN LOGGING AT Fri Aug 03 02:59:59 2012
Aug 03 07:20:59 <zubraj> hello all
Aug 03 07:21:13 <zubraj> I'm new to bitbake and yocto project
Aug 03 07:22:45 <zubraj> can anyone help me in compiling a library source file using bitbake , i have seen the helloworld sample but in my case its a library, i want the end package to be a library
Aug 03 07:38:46 <zubraj> how to include a library in bitbake
Aug 03 07:48:31 <bluelightning> morning all
Aug 03 07:49:50 <JaMa> morning
Aug 03 08:08:35 <zubraj> my bitbake is crashing because of some patch says failing in patching a file enforce with -f wat should i do
Aug 03 08:09:44 <zubraj> bitbake crashing
Aug 03 08:10:11 <zubraj> error is "FATAL: [Errno 2] No such file or directory: '/home/lukup/oe/arago/recipes/linux/linux-am335x-3.2.0-psp04.06.00.08.sdk/./0001-mach-omap2-pm33xx-Disable-VT-switch.patch'"
Aug 03 08:15:23 <bluelightning> zubraj: I think you're going to need to talk to the arago folks for that...
Aug 03 08:15:33 <bluelightning> bitbake is not crashing, it's telling you it can't find that file
Aug 03 08:18:45 <bluelightning> the file is part of the arago metadata by the looks of it
Aug 03 09:48:39 <zubraj> bluelightning: i have moved the file from that place what i wanted to know was wher are the file's patched and how can i ensure a force patch
Aug 03 09:48:48 <zubraj> -f
Aug 03 09:48:55 <zubraj> that's what the error was
Aug 03 09:49:42 <bluelightning> zubraj: if the patch does not apply you can't just force it, you need to fix up the patch
Aug 03 09:50:15 <zubraj> should i send yu the logs maybe u can tell how to fix that..
Aug 03 09:52:29 <zubraj> bluelightning:: i don't know the error suggests to put the patch by using -f
Aug 03 09:55:20 <zubraj> codepad.org is not working whcih are the pastebin sites
Aug 03 09:56:12 <zubraj> http://pastebin.com/vMDVM0JX
Aug 03 09:57:06 <zubraj> the above is th error report , it says enforce with -f what does that mean
Aug 03 09:57:33 <zubraj> bluelightning:-> i don't understand the error..
Aug 03 09:59:02 <bluelightning> zubraj: quilt, the utility we use to apply the patches, always reports that when a patch fails to apply
Aug 03 10:00:33 <bluelightning> zubraj: have you modified the recipe?
Aug 03 10:00:37 <zubraj> bluelightning:-> i knwo quilt is used for patching ..  but i don't know where to look for it..
Aug 03 10:00:46 <zubraj> no not a bit..
Aug 03 10:01:11 <zubraj> i have not modified anything..
Aug 03 10:01:54 <zubraj> can u make anything out of the logs ....
Aug 03 10:02:58 <bluelightning> zubraj: not really, it seems like the metadata is broken
Aug 03 10:03:28 <bluelightning> zubraj: but really, you should be asking the arago project about this I think, this is not yocto-project derived metadata
Aug 03 10:04:44 <zubraj> no what i was thinkin is I'll try to fix it on my own, can this be fixed..
Aug 03 10:05:15 <zubraj> i mean i know where are the files , but i don't know exactly where are the patches applied
Aug 03 10:07:30 <bluelightning> zubraj: you can find the work files under the WORKDIR for the recipe, i.e. TMPDIR/work/*/linux-am335x_3.2.0-psp04.06.00.08.sdk*/
Aug 03 10:12:23 <zubraj> bluelightning:->can u tell me the flow of this bitbake i mean , for building a root filesystem , how does the bitabke starts , i have read the doc.. buts confusing , just a brief will be enough
Aug 03 10:16:11 <zubraj> bluelightning:-> i'm inside the /linux-am335x-3.2.0-psp04.06.00.08.sdk-r21 dir there are three files one is git , temp and one file named defconfig.. ...
Aug 03 10:16:57 <zubraj> bluelightning->the git files is having the source code of a linux kernel i mean everything, like a normal kernel .. what should i do now..
Aug 03 10:17:56 <bluelightning> zubraj: I'm surprised there are no patches in there
Aug 03 10:20:14 <bluelightning> zubraj: honestly I think what you should do now is post your question to the arago mailing list rather than trying to hack around the problem yourself; it should not be broken out of the box
Aug 03 10:21:03 <zubraj> bluelightning-> this is how my entire terminal looks like.. and there are some files . whcih look like patches  guess u will have some idea
Aug 03 10:21:07 <zubraj> http://pastebin.com/2rPaJn2z
Aug 03 10:22:47 <bluelightning> zubraj: have a look under git/patches/
Aug 03 10:25:14 <zubraj> bluelightning ::-> have a look at this one
Aug 03 10:25:18 <zubraj> http://pastebin.com/n2YyrHsu
Aug 03 10:25:40 <bluelightning> right, it's a patch...
Aug 03 10:25:58 <zubraj> it is the same patch whcih was showing error
Aug 03 10:26:07 <bluelightning> sure
Aug 03 10:26:29 <bluelightning> zubraj: unfortunately this is too specific a problem for me to help with I'm afraid
Aug 03 10:27:09 <zubraj> ok ok , u show me the way i'm goin to do it. coz I'm a newbie with this bitbake bussiness..
Aug 03 10:27:49 <zubraj> just tell me what can be the error , u know patch not workin ... something to do with force patch what is that..
Aug 03 10:28:11 <bluelightning> as I said earlier, if the patch does not apply, forcing will not help
Aug 03 10:28:27 <bluelightning> you will just end up with a mangled file most of the time
Aug 03 10:29:24 <zubraj> is there any way i can remove the patch , i tried removing the patch .. it returns errors saying file missing..
Aug 03 10:29:41 <bluelightning> zubraj: you'd need to remove it from SRC_URI within the recipe
Aug 03 10:32:31 <zubraj> bluelightning:-> and the recipe will be in OE/recipes/linux right
Aug 03 10:33:25 <bluelightning> zubraj: I guess so, it's the recipe file indicated in the log you sent earlier
Aug 03 10:34:00 <zubraj> http://pastebin.com/vMDVM0JX
Aug 03 10:34:04 <zubraj> this one right
Aug 03 10:35:28 <bluelightning> zubraj: yes, you see it refers to /home/lukup/oe/arago/recipes/linux/linux-am335x_3.2.0-psp04.06.00.08.sdk.bb
Aug 03 10:38:19 <zubraj> bluelightning-> looks like this the .bb file
Aug 03 10:38:23 <zubraj> http://pastebin.com/fLXpxdYY
Aug 03 10:42:47 <zubraj> bluelightning -> i have removed the  "file://0001-mach-omap2-pm33xx-Disable-VT-switch.patch \" fromm SRC_URI
Aug 03 10:43:09 <zubraj> i guess I'm correct and i have started the tool,gain..
Aug 03 10:47:24 <zubraj> bluelightning:-the day befopre i was working on the yocto project i have compiled the poky as said in the video for qemu but its reurning some errors..
Aug 03 10:48:26 <bluelightning> zubraj: what were the errors?
Aug 03 10:49:08 <zubraj> i don't remember exactly i have the buil;d if u can tell mewhere to find the logs maybe i can send yu the logs
Aug 03 10:49:11 <zubraj> i mean inside poky
Aug 03 10:55:02 <bluelightning> zubraj: TMPDIR/cooker.log.<datetime>
Aug 03 11:00:32 <zubraj> bluelightning: here are th error logs
Aug 03 11:02:08 <zubraj> bluelightning:.here are th error logs when i try to build it using qemu x86 Yocto project
Aug 03 11:02:12 <zubraj> http://pastebin.com/BriNm4yL
Aug 03 11:03:49 <bluelightning> zubraj: which host distro are you building on?
Aug 03 11:04:01 <zubraj> Ubuntu 10.04 LTS
Aug 03 11:04:21 <zubraj> bluelightning :. dat's not a problem i guess..
Aug 03 11:04:38 <bluelightning> shouldn't be...
Aug 03 11:08:28 <zubraj> bluelightning: says error is in do_compile but there's no do_compile function in the recipe..
Aug 03 11:10:13 <zubraj> here's the recipe file
Aug 03 11:10:16 <zubraj> http://pastebin.com/WEdC4tqU
Aug 03 12:14:26 <roric> Anyone having any S/PDIF experiences with OMAP44xx?
Aug 03 12:53:25 <zubraj> bluelightning-> the arago-image is built
Aug 03 12:56:45 <bluelightning> zubraj: great
Aug 03 12:57:35 <zubraj> bluelightning_>by the way thanks for the help
Aug 03 13:00:12 <zubraj> bluelightning -> how do i upgrade Qt , i mean the recipe is for Qt4.7 i wan it to upgrade it to Qt 5, how do i modify it .. and i want a library to built along with the Qt , how should i begin
Aug 03 13:01:05 <bluelightning> zubraj: Qt 4.7 -> Qt 5 is not a straightforward transition
Aug 03 13:01:23 <zubraj> bluelightning_> i think just by renaming the *.bb file won't work , wat do u suggest..
Aug 03 13:01:43 <bluelightning> there are some qt 5 recipes here but they are not finished: https://github.com/martiert/meta-qt5
Aug 03 13:01:48 <zubraj> that means i have to write a new recipe file entirely
Aug 03 13:02:54 <bluelightning> look at the files linked above
Aug 03 13:03:51 <zubraj_> bluelightning-> a library called Qjsion should also be included in the package..
Aug 03 13:04:43 <bluelightning> zubraj_: we can't include everything in the core; it could be provided elsewhere though
Aug 03 13:05:30 <zubraj_> bluelightning-> i mean ok u mean that i can compile it as a package and get the ipkg file adn tryb to insert it.. r8
Aug 03 13:11:50 <zubraj> bluelightning-> what should i do for the library i mean compile it as a package
Aug 03 13:13:52 <bluelightning> zubraj: you'll need to write your own recipe for it I guess
Aug 03 13:14:47 <zubraj> no but i can't find any example for writing a libary recipe , the source code is with me .. some 12 C++ files
Aug 03 13:15:08 <zubraj> and the dependency is Qt should be above Qt 4.5
Aug 03 13:17:38 <zubraj> i
Aug 03 13:18:36 <bluelightning> zubraj: there are many many examples of libraries in the metadata...
Aug 03 13:19:00 <zubraj> bluelightning -> the filesystem whcih i have compiled is booting , but its stuck after booting , i mean the prompt is comin on the display , its not lettin me pass that
Aug 03 13:19:44 <bluelightning> zubraj: is this arago?
Aug 03 13:20:05 <zubraj> yes
Aug 03 13:22:38 <zubraj> bluelightning-> how is arago different from yosto project
Aug 03 13:22:56 <zubraj> i mean yocto project
Aug 03 13:22:58 <bluelightning> zubraj: I really don't know much about it
Aug 03 13:24:04 <zubraj> ok no problem , can u just tell me the location of one recipe -library file, which is compiled from the source
Aug 03 13:24:06 <zubraj> clear
Aug 03 13:24:07 <zubraj> ls
Aug 03 13:26:42 <zubraj> bluelightning-> I 'am amazed to see the absence of Qt library , I can't find it..  but I"m very much sure that i saw its recipe file
Aug 03 13:27:23 <bluelightning> zubraj: in our metadata it's under meta/recipes-qt/qt4/
Aug 03 13:28:03 <zubraj> so that means qt library should be there .. but I'm not able to find it.. on the filesystems on the board..
Aug 03 13:29:51 <bluelightning> well, that doesn't mean it's built and installed in the image you built...
Aug 03 13:31:43 <zubraj> if its like than it should pop out some error  right by the way these are the images i built  whcih one should i use
Aug 03 13:31:59 <zubraj> http://pastebin.com/nB7TRgs8
Aug 03 13:32:19 <zubraj> i have used the tar .gz image for filesystem
Aug 03 13:32:40 <bluelightning> not sure, sorry
Aug 03 13:33:42 <zubraj> ok no problem..
Aug 03 13:36:37 <zubraj> bluelightning->so in think the packages wghich are installed in the filesystem will be in work directory of  /tmp/work
Aug 03 18:17:58 <khem>  iputils-traceroute6         ##################################################
Aug 03 18:17:59 <khem> | chmod: cannot access `/bin/traceroute6': No such file or directory
Aug 03 18:18:09 <khem> anyone seen such a think with rmp
Aug 03 18:18:11 <khem> rpm
Aug 03 18:19:01 <khem> install -m 4555 traceroute6 ${D}${base_bindir}/
Aug 03 18:19:30 * khem looks at fray
Aug 03 18:24:53 <jstashluk> otavio: ping
Aug 03 18:33:34 <otavio> jstashluk: pong
Aug 03 18:34:22 <jstashluk> I found a bug in the meta-fsl-arm stuff. What's the best way to get you the fix?
Aug 03 18:34:41 <otavio> jstashluk: Mail it to the meta-fsl-arm mailing list
Aug 03 18:35:23 <jstashluk> otavio: thanks.
Aug 03 18:35:32 <otavio> jstashluk: you're welcome ...
Aug 03 18:35:44 <otavio> jstashluk: but what it is about? i am curious ... :-D
Aug 03 18:36:15 <jstashluk> Removing the empty 1k partion causes the wrong fs size to be calculated.
Aug 03 18:36:24 <jstashluk> For the boot partition.
Aug 03 18:37:13 <otavio> jstashluk: Uh? for mxs or other?
Aug 03 18:37:20 <jstashluk> other.
Aug 03 18:37:42 <jstashluk> Works fine until you want to deploy to a larger SDCARD
Aug 03 18:38:20 <otavio> jstashluk: did you find the fix?
Aug 03 18:38:35 <jstashluk> Yes.  It's trivial.
Aug 03 18:38:46 <otavio> jstashluk: yey! send it please
Aug 03 18:40:28 <kergoth> damnit, got an autogen process hung up entirely again
Aug 03 18:40:33 <kergoth> completely hung my build
Aug 03 18:55:55 <jstashluk> otavio: can you take a look and tell me if I submitted that correctly?
Aug 03 18:56:20 <otavio> jstashluk: sure; pvt messge ...
Aug 03 20:37:08 <awsation> ping pidge.
Aug 03 20:40:16 <fray> does anyone know how the license validation/warning works?  We're getting a local QA warning about a missing license file, and we're trying to figure out the steps to provide the license..
Aug 03 20:45:15 <awsation> we have put a generic license file in meta/files/common-licenses/ but the QA warning is still shows up
Aug 03 21:04:36 <seebs> I would just like to state for the record that by the time I had a reproducer for a pcre crash which turned out to be a compiler bug, I was totally and utterly shocked that it was a compiler bug.
Aug 03 21:06:24 <seebs> And hey, since it has crossed my mind: RP__, et al: Should I be resubmitting those tracking patches? Fixing them in some way?
Aug 03 22:28:53 <chackal_sjc> I'm having this
Aug 03 22:28:54 <chackal_sjc> QA Issue: non -dev/-dbg/-nativesdk package contains symlink .so: qcharts path '/work/armv7a-vfp-neon-poky-linux-gnueabi/qcharts-1.0.0-r0/packages-split/qcharts/usr/lib/libQtCommercialChart.so'
Aug 03 22:29:04 <chackal_sjc> But I added the .so to the package-dev
Aug 03 22:39:44 <seebs> Did you bump PR to make it rebuild?
Aug 03 22:50:52 <chackal_sjc> seebs: what you mean by that?
Aug 03 22:51:35 <seebs> When you change a package, such as by adding something to package-dev, if you do not also bump PR it may not get rebuilt, so stuff that you just fixed may not get fixed.
Aug 03 22:55:51 <chackal_sjc> seebs: I got it.. but the is an issue
Aug 03 22:56:25 <chackal_sjc> this was happening because my FILES_${PN} had a .so which is a link to the .so.1.0.0
Aug 03 22:56:56 <chackal_sjc> So i'm not adding this recipe anymore, but how the application will load the .so on the target device?
Aug 03 22:58:27 <seebs> I don't entirely know how to put together target packages, I haven't really done much with them. If I had to do this, I'd look for another package which installs a .so on the device, and look at what they do. Usually, though, the .so files would be considered part of their own library package, not part of some other package, I think.
Aug 03 23:05:31 <chackal_sjc> seebs: In my case, its because this library build the .so as a link. I will take care of this if it became a problem
Aug 03 23:05:52 <seebs> I am pretty sure it's fairly normal for the .so to be a symlink to a specific version.
Aug 03 23:07:00 <kergoth> chackal_sjc: apps don't use the .so at runtime. the .so link only exists for build time / development
Aug 03 23:14:11 <seebs> Huh. That would indeed explain it.
Aug 03 23:14:29 <seebs> I'm so used to seeing those references show up in stuff that I assumed they were being used at runtime too.
Aug 04 01:17:34 <chackal_sjc> kergoth: hmmm.. what apps load in run time, then?
Aug 04 01:17:47 <kergoth> what the .so symlink points to.
Aug 04 01:17:58 <kergoth> the actual library. e.g. libfoo.so.2
Aug 04 01:26:56 <chackal_sjc> kergoth: i know.. but im my case there will be no .so in the package because of that QA test
Aug 04 01:27:05 <kergoth> and?
Aug 04 01:27:16 <kergoth> i just told you, it uses libfoo.so.whatever, not libfoo.so
Aug 04 01:27:20 <kergoth> the symlink is only used at build time, not run time
Aug 04 01:27:28 <kergoth> i'm not sure how many more times i need to explain this
Aug 04 01:30:54 <chackal_sjc> kergoth: i dont know how many times i need to explain this
Aug 04 01:31:02 <chackal_sjc> but its ok, i can figure out
Aug 04 01:31:39 <kergoth> your .so should NOT be in the main package, it belongs in the -dev package. if you can't grasp that basic concept, good luck
Aug 04 01:38:51 <chackal_sjc> kergoth: again, i wasnt asking that.. thank you for your kindness anyway
Aug 04 01:44:08 <seebs> You were saying that you were trying to include libQtCommercialChart.so in your package. You shouldn't need it. The application does not use that.
**** ENDING LOGGING AT Sat Aug 04 02:59:58 2012

**** BEGIN LOGGING AT Sat Aug 04 02:59:58 2012
**** ENDING LOGGING AT Sun Aug 05 02:59:59 2012

**** BEGIN LOGGING AT Sun Aug 05 02:59:59 2012
**** ENDING LOGGING AT Mon Aug 06 02:59:58 2012

**** BEGIN LOGGING AT Mon Aug 06 02:59:58 2012
Aug 06 08:35:53 <bluelightning> morning all
Aug 06 08:48:16 <RP__1> morning all
Aug 06 08:48:23 <bluelightning> hi RP
Aug 06 14:26:03 <JaMa|Wrk> RP: can you please merge bluelightning's buildhistory improvements? if you haven't already
Aug 06 14:29:49 <RP> JaMa|Wrk: done
Aug 06 14:33:08 <JaMa|Wrk> thanks
Aug 06 14:40:02 <JaMa|Wrk> only pending patch needed for my builds is udev-extraconf now, good :)
Aug 06 18:36:57 <AdityaGandhi> Hi,
Aug 06 18:37:24 <AdityaGandhi> I tried building a custom image using hob from yocto 7.0.1
Aug 06 18:38:02 <AdityaGandhi> and I am unable to login, I have tried multiple times, if the build is not modified and use a template already provided I can login
Aug 06 18:38:28 <AdityaGandhi> but after editing I cannot login at all
Aug 06 18:55:58 <pidge> halstead: I think there is an issue going on with sanity testing on ab02. It should be set up correctly, however it seems to be choking. I'm going to take ab02 out of the pool for a bit, once this build is complete and figure out what is going on. This is the deb box, correct?
Aug 06 19:02:47 <AdityaGandhi> yup, I am using ubuntu 10.10
Aug 06 19:54:06 <halstead> It's out of the pool now. And yes this is the Debian 6 box.
Aug 06 20:00:28 <RP> AdityaGandhi: What did you change?
Aug 06 20:01:01 <RP> AdityaGandhi: It stands to reason something you've changed must have caused this inadvertently
Aug 06 20:08:30 <AdityaGandhi> I added a package called gst-ffmpeg-dev
Aug 06 20:08:44 <AdityaGandhi> thats it, wanted to see why my files weren't playing right
Aug 06 20:15:11 <walters> RP: i did a presentation at GUADEC about my gnome-OSTree work in case you're curious: http://people.gnome.org/~walters/guadec-2012-building-gnome
Aug 06 20:15:35 <walters> it's using Yocto still, but i am slowly hollowing out the Yocto-built part into more of a buildroot SDK
Aug 06 20:19:20 <RP> walters: I'm interested although my browser doesn't like that url :/
Aug 06 20:19:41 <walters> it's just the google html5 slides template...what browser?
Aug 06 20:21:13 <RP> walters: firefox but an old one
Aug 06 20:21:32 <walters> ah
Aug 06 20:21:34 <RP> walters: I tend to leave my desktop alone when it works, I get enough problems with yocto
Aug 06 20:21:51 <walters> works with Firefox ESR (10.0.5) here, from RHEL6
Aug 06 20:22:08 <walters> RP: fair enough =)  (although not updating your browser is kind of a bad idea)
Aug 06 20:22:23 <RP> walters: This is firefox 12.0 :/
Aug 06 20:22:37 <RP> walters: I'll take security stuff ;-)
Aug 06 20:53:51 <RP> walters: makes interesting reading. Would be good to talk over beer sometime ;-)
Aug 06 20:54:11 <walters> i'll be a plumber's in San Diego next
Aug 06 20:54:38 <RP> walters: I will be at linuxcon
Aug 06 20:55:10 <walters> RP: ah cool, plumbers follows that
Aug 06 20:55:54 <RP> walters: Are you there for linuxcon too? I'm there until Sunday if I remember rightly
Aug 06 20:58:26 <walters> ah, i thought linuxcon was before, but looks like they're all the same place and time
Aug 06 20:58:53 <walters> i'm in San Diego from Aug 29-Sep 03
Aug 06 21:00:44 <RP> walters: we should be able to find beer one evening and share some ideas then :)
Aug 06 21:01:22 <walters> RP: sounds good!  is there any yocto presentations/meetups going on there in general?
Aug 06 21:01:45 <RP> walters: er, yes
Aug 06 21:02:44 <walters> i see it on the schedule
Aug 06 21:03:49 <RP> walters: There are a few sessions there. Nothing in massive technical detail as we don't usually get the audience for that
Aug 06 21:03:51 <walters> my talk is https://blueprints.launchpad.net/lpc/+spec/lpc2012-boot-atomic-upgrades
Aug 06 21:06:54 <RP> walters: I've heard some interesting thoughts on that topic before...
Aug 06 21:08:13 <walters> i have working code, not just thoughts =)  but anyways
Aug 06 21:08:43 <walters> one the thing i hope to sell you guys on eventually is building everything from git
Aug 06 21:09:22 <RP> walters: You might not have as hard a job as you'd imagine, at least not for making the option available
Aug 06 21:09:51 <RP> walters: http://git.yoctoproject.org/cgit.cgi/poky/tree/meta-yocto/conf/distro/poky-bleeding.conf has stuck around for a reason
Aug 06 21:10:04 <RP> walters: The idea was that it would build the system from SCM
Aug 06 21:10:51 <RP> walters: http://git.yoctoproject.org/cgit.cgi/poky/tree/meta-yocto/conf/distro/include/poky-floating-revisions.inc has the details but its not been used for a while
Aug 06 21:11:20 <walters> yeah, one of the stumbling blocks is what to put in the package version field
Aug 06 21:12:13 <walters> i entirely sidestep that in my system - the distribution mechanism is just a versioning filesystem; it doesn't care at all about version numbers or packages
Aug 06 21:12:48 <RP> walters: This ends up using the PV string +gitN+revision where N is a build number. Not ideal but the best that will generically scale for existing package managers
Aug 06 21:14:48 <RP> walters: It would be interesting to have that as a dedicated "package" backend for the project. Its kind of like sstate in some ways
Aug 06 21:16:33 <walters> yeah, adding it as a rootfs option is on my list
Aug 06 21:18:37 <walters> RP: anyways i'll send you a mail when i get to SD, not totally sure what my schedule will be
Aug 06 21:19:34 <RP> walters: sounds good. I'll be there around the Yocto sessions and so on so we should manage to bump into each other at some point
Aug 06 21:20:00 <RP> walters: I suspect there will be a Yocto booth and they'll probably know where I am too
Aug 06 21:20:23 <walters> ok, cool
Aug 07 02:05:32 <khem> kergoth: Is there some way in bb to print time a task took onto cmdline
Aug 07 02:05:40 <khem> I know buildstats
Aug 07 02:05:50 <khem> but I am looking for something thats in cmdline
Aug 07 02:06:11 <khem> or may be some way that data from buildstats is displayable
Aug 07 02:06:18 <khem> in some human readable form
**** ENDING LOGGING AT Tue Aug 07 02:59:58 2012

**** BEGIN LOGGING AT Tue Aug 07 02:59:59 2012
Aug 07 04:56:41 <zubraj> .......
Aug 07 06:52:48 <CruX|> hello, bitbake -c fetchall succeedded
Aug 07 06:52:48 <CruX|> but if I try to build minimal-image on machine without internet connection bitbake fails here:
Aug 07 06:52:51 <CruX|> STDERR: fatal: unable to connect to git.yoctoproject.org: git.yoctoproject.org[0: 140.211.169.122]: errno=No route to host
Aug 07 06:52:54 <CruX|> why is not this downloaded with previous fetchall ? machine without internet connection is behind proxy, that's why I need to download all sources on other machine.
Aug 07 10:10:49 <ynezz>  /window 11
Aug 07 14:47:44 <Crofton> RP, go on vacation! Tell them to sort their poop out and have a solution in your inbox when you get back!
Aug 07 15:00:10 <bluelightning> YPTM: Paul Eggleton is on
Aug 07 15:00:30 <jmpdelos> YPTM: Jeff Polk is on
Aug 07 15:00:35 <strassek> YPTM: Kevin Strasser is here
Aug 07 15:00:38 <Song_Liu> YPTM: Hi guys, we are starting the technical team meeting now, let's see who's on the bridge
Aug 07 15:00:43 <RP> YPTM: Richard is here
Aug 07 15:00:50 <bogdanm> YPTM: Bogdan is on the bridge
Aug 07 15:01:03 <Zagor> YPTM: Bjorn is here
Aug 07 15:01:14 <nitink> YPTM: Nitin Kamble is on the bridge
Aug 07 15:01:17 * fray will be on the call in a second
Aug 07 15:01:24 <tomz3> YPTM: Tom Z is here
Aug 07 15:01:24 <laur> YPTM: Laurentiu Palcu is on
Aug 07 15:02:18 <halstead> YPTM: Michael Halstead is present.
Aug 07 15:02:36 <fray> YPTM: now on the call
Aug 07 15:02:50 <pidge> YPTM: Beth here.
Aug 07 15:02:51 <1JTAAA5GX> YPTM: I'm on the call as well
Aug 07 15:03:08 * 1JTAAA5GX needs to rename to jkridner
Aug 07 15:03:18 <RP> 1JTAAA5GX: In disguise? :)
Aug 07 15:03:34 <fray> heh
Aug 07 15:03:47 <bogdanm> YPTM: no opens
Aug 07 15:03:47 <Song_Liu> YPTM: Let's collect the opens now
Aug 07 15:03:49 <fray> YPTM: I have one minor issue around LSB/FHS
Aug 07 15:04:08 * RP should cover master status
Aug 07 15:04:20 <halstead> YPTM: Open, Public IP address space change.
Aug 07 15:05:00 <pidge> YPTM: Minor AB downtime
Aug 07 15:06:14 <denix> YPTM: here, no opens
Aug 07 15:08:33 <cristian> YPTM: cristi is on the bridge
Aug 07 15:14:53 <Song_Liu> YPTM: items at risk for M3:
Aug 07 15:14:59 <Song_Liu> YPTM: 61	nor	[Performance] Generate fontconfig cache when building image	3.0	laurentiu.palcu@intel.com	Medium	ACCE	(P1)(Scheduled) 1369	nor	[Multilib] On-target gcc enhancement	5.0	bogdan.a.marinescu@intel.com	Medium	ACCE	(P1)(Scheduled) 2010	nor	Some unnecessary packages installed cause AutoBuilder built failed	0.5	michael@yoctoproject.org	Medium	ACCE	(P1) (Development) Status: Tested. Estimate: 4 hours 2038	enh	[multilib] Add script
Aug 07 15:19:00 <Song_Liu>  https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.3_Status#Milestone_4
Aug 07 15:29:01 <zeddii> YPTM: are you done ? I was pulled away @ 5 minutes to the meeting.
Aug 07 15:29:56 <halstead> zeddii, We are doing opens now.
Aug 07 15:29:56 <Zagor> zeddii: meeting is still in progress
Aug 07 15:30:13 <zeddii> ok. I'll dial in and lurk :)
Aug 07 15:31:09 * zeddii lurks
Aug 07 15:31:54 <Song_Liu> YPTM: team sharing now, anyone?
Aug 07 15:32:27 <fray> nothing to really share... except I did send the RFC out about the Image generation and deployment to OE-core mailing list.. no feedback..
Aug 07 15:34:41 <RP> fray: I think you know my views on that one already :)
Aug 07 15:35:47 <JaMa|Wrk> RP: are there some steps we can do to include that udev-extraconf change (including license)?
Aug 07 15:36:56 <RP> JaMa|Wrk: I think I'm going to be out of time on that one :(
Aug 07 15:37:09 <RP> JaMa|Wrk: too much other instability and breakage
Aug 07 15:38:57 <Song_Liu> YPTM: The tech team meeting is closed now. Thank you all for joining!
Aug 07 15:40:17 <JaMa|Wrk> RP: ok, np
Aug 07 20:24:14 <ant__> zeddii: ping
Aug 07 20:24:40 <ant__> zeddii: http://paste.debian.net/182624/
Aug 07 20:27:40 <RP> halstead: would ab10 have sanity issues?
Aug 07 20:28:24 <RP> pidge: ^^^ ?
Aug 07 20:31:24 <halstead> rp there shouldn't be. Are you seeing some? i' grabbing lunch. I will be back where I can look at it shortly.
Aug 07 20:31:55 <RP> halstead: http://autobuilder.yoctoproject.org:8010/builders/nightly-mips/builds/534
Aug 07 20:36:09 <seebs> RP: Variable tracking: Should I resubmit? Resubmit with changes? Bury in an unmarked grave?
Aug 07 20:36:29 <RP> seebs: I like the idea, if you have rebased patches those would be appreciated
Aug 07 20:37:04 <RP> seebs: I'm on vacation the rest of this week and plan to pick up the remaining bitbake patches and sort through them when I return (including Jason's)
Aug 07 20:37:29 <RP> seebs: I wanted to sit down and properly review them but I think they were basically ok
Aug 07 20:38:19 <seebs> Well, have a nice vacation! I'll try to send rebased patches sometime later this week. I am sure the code is sort of pants in some ways, and I think there may be a bug in the reporting (or five).
Aug 07 20:38:40 <seebs> Someday when life is quiet I want to work a lot more on those and clean them up more.
Aug 07 20:38:49 <seebs> (The bug I may have found would just be excess verbosity, mind.)
Aug 07 20:44:05 <seebs> Had a merge conflict, and just to sanity-check: Was there a recent change that would have replaced \t with four spaces in a couple of quoted strings in ast.py?
Aug 07 20:45:27 <seebs> Oh, duh. git blame on master does indeed confirm, that's what I'm seeing.
Aug 07 20:46:31 <RP> seebs: yes, we use space indention now (and always should have been)
Aug 07 20:46:36 <seebs> k.
Aug 07 20:47:10 <seebs> I sort of want, in a merge conflict, an indication of what my patch *thought* it would be patching. But I managed to muddle through.
Aug 07 20:48:08 <halstead>  i'm grabbing lunch. I will be back where I can look at it shortly.
Aug 07 20:48:42 <RP> halstead: no rush, just wanted to mention it
Aug 07 20:50:01 <kergoth> seebs: see https://bitbucket.org/kergoth/dotfiles/src/97d4191dd49d/gitconfig#cl-119, specifically conflictstyle=diff3. with that, the conflict markers show all 3 bits of context. the common ancestor, what the new patch wanted to create, and finally what was actually there
Aug 07 20:50:06 <kergoth> that's usually sufficient for me
Aug 07 20:50:08 <seebs> oooooh
Aug 07 20:50:58 <seebs> ... I'm half fascinated by the git config, and half by bitbucket.org.
Aug 07 20:54:39 <RP> kergoth: that does sound useful
Aug 07 20:55:26 <kergoth> seebs: heh, i put my dotfiles there as an experiment to force me to learn mercurial nearly as well as i know git. didn't get quite that far, but close enough :)
Aug 07 20:56:00 <seebs> I have been avoiding trying to learn more version control systems.
Aug 07 20:56:13 <seebs> Everyone else lost brain cells in college to booze. I lost them to SCCS.
Aug 07 20:56:34 <walters> haha
Aug 07 20:56:47 <seebs> Although, man. Learning git, totally worth ti.
Aug 07 20:56:52 <seebs> s/ ti/ it/
Aug 07 20:57:04 <seebs> (I have to correct small typos compulsively or I lose my Editor Superpowers.)
Aug 07 20:58:00 <seebs> My offsite storage of stuff is mostly github, and I think I mostly ended up there because I knew Tekkub from my days doing WoW addons.
Aug 07 21:06:24 <RP> zeddii: looks like we have the slang issue with the routerstationpro and 3.0 ? :(
Aug 07 21:07:19 <pidge> RP: looking
Aug 07 21:46:12 <halstead> RP: tap0 was missing on ab10, tap1 and tap2 were created instead. That is fixed now. I'm looking at the script to see how it got in that state.
Aug 07 21:46:41 <RP> halstead: great, thanks
Aug 07 21:47:06 <ant__> RP: have you ever heard about | AttributeError: 'module' object has no attribute 'lib'
Aug 07 21:47:07 <ant__> | ERROR: Function failed: do_package_index
Aug 07 21:47:44 <RP> ant__: probably. Try removing the PYTHONPATH line from package-index.bb
Aug 07 21:47:55 <RP> ant__: I have a change queued for this but not tested yet
Aug 07 21:52:45 <ant__> RP: pulled now and issue disappeared
Aug 07 21:53:46 <ant__> I was tracking a strange opkg issue, built ipk's not listed in Packages
Aug 07 21:55:15 <RP> ant__: did you comment out the PYTHONPATH?
Aug 07 21:55:19 <ant__> well, solved .. I'm not yet rebuilding it...
Aug 07 21:56:02 <ant__> I don't have any PYTHONPATH
Aug 07 21:56:35 <ant__> maybe you mean  export PYTHONHOME = "${STAGING_DIR_NATIVE}/usr"
Aug 07 21:58:03 <ant__> yes, this helped
Aug 07 21:58:07 <ant__> # Force NATIVE python to use modules from STAGING_DIR_NATIVE
Aug 07 22:00:27 <msm> why isn't the a mirror for watchdog recipe being used?
Aug 07 22:00:48 <msm> its listed in mirrors
Aug 07 22:01:11 <msm> or they added a mirror for that recipe specifically
Aug 07 22:01:42 <RP> ant__: sorry, yes the PYTHONHOME.
Aug 07 22:02:06 <RP> msm: mirrors come after the original url, are you waiting for that to timeout?
Aug 07 22:02:08 <ant__> bingo
Aug 07 22:03:24 <ant__> RP: by the way we have suspects the toolchain does miscompile for armv4t like collie
Aug 07 22:03:28 <msm> RP: im just running 'bitbake watchdog' and it's not uses a mirror in the mirrors.bbclass
Aug 07 22:03:44 <ant__> RP: seems just the kernel
Aug 07 22:04:35 <RP> msm: hmm, and bitbake -e and looking at the MIRRORS variable shows the mirror?
Aug 07 22:04:50 <msm> yes
Aug 07 22:04:54 <RP> ant__: That is possible
Aug 07 22:05:03 <msm> remove my own mirrors as well
Aug 07 22:05:08 <RP> msm: odd. Have you a fetch log you can show for it
Aug 07 22:05:20 <RP> msm: that should have the fetcher debug messages in it
Aug 07 22:05:22 <msm> commit fe800caf592c7ba8247c1320c01075b8d063f310
Aug 07 22:07:08 <msm> RP: nevermind, it is checking the mirror
Aug 07 22:07:14 <msm> its just not finding it on the mirror either
Aug 07 22:07:27 <msm> or i get this
Aug 07 22:07:27 <msm> DEBUG: Fetcher failure for URL: 'http://fossies.org/linux/misc/watchdog_5.12.tar.gz'. The fetch command returned success for url http://fossies.org/linux/misc/watchdog_5.12.tar.gz but /local/home/mattsm/git/poky-upstream/build-master/downloads/watchdog_5.12.tar.gz doesn't exist?!
Aug 07 22:07:56 <msm> its downloaded OK, its just bitbake thinks it failed
Aug 07 22:08:04 <msm> the tarball is there (i can extract it)
Aug 07 22:08:25 <RP> msm: so  /local/home/mattsm/git/poky-upstream/build-master/downloads/watchdog_5.12.tar.gz exists?
Aug 07 22:08:33 <msm> http://fpaste.org/ZA73/
Aug 07 22:08:34 <msm> ya
Aug 07 22:09:39 <msm> this is actually master
Aug 07 22:09:43 <msm> (for a change)
Aug 07 22:12:03 <RP> msm: that code is quite simple:
Aug 07 22:12:03 <RP>         if not os.path.exists(ud.localpath) and not checkonly:
Aug 07 22:12:03 <RP>             raise FetchError("The fetch command returned success for url %s but %s doesn't exist?!" % (uri, ud.localpath), uri)
Aug 07 22:12:20 <RP> so either ud.localpath does or does not exist :/
Aug 07 22:12:33 <msm> RP: but I untarred it ;)
Aug 07 22:14:17 <RP> msm: Is there also a .xxx.1 file
Aug 07 22:16:09 <msm> ive deleted it all
Aug 07 22:16:12 <msm> tried again
Aug 07 22:16:16 <msm> its quite reproducible
Aug 07 22:16:47 <RP> msm: sounds like some glitch in the fetcher :/
Aug 07 22:17:09 <msm> seems like someone else would hit this though
Aug 07 22:20:07 <RP> msm: unless they're getting them from the yocto mirror or have a premirror setup or something
Aug 07 22:20:44 <msm> this recipe is from today
Aug 07 22:20:48 <msm> watchdog 5.12
Aug 07 22:21:44 <Strogg> 'lo 'lo
Aug 07 22:22:42 <RP> msm: 5 days ago
Aug 07 22:22:57 <msm> RP: *sigh* i rebased today
Aug 07 22:23:25 <RP> msm: ok, I was just confused as I thought it was about a week ago :)
Aug 07 22:23:39 <RP> days seem rather long atm :/
Aug 07 22:23:47 <msm> its all a blur anyways ;)
Aug 07 23:16:04 <kergoth> goddamnit, yet another grub do_compile hang in the exec of autogen from autogen-native
Aug 07 23:16:06 * kergoth sighs
Aug 07 23:56:42 <mranostay> kergoth: how does that hang exactly?
Aug 07 23:57:15 <kergoth> it appears to be running sed, presumably it screws up the call and its waiting on stdin
Aug 07 23:57:18 <kergoth> haven't had time to dig
Aug 08 00:09:57 <seebs> ...
Aug 08 00:10:14 <seebs> There was once, long ago, when a mysterious hang only ever in sed turned out to be pseudo.
Aug 08 00:10:29 <seebs> Pretty sure that bug cannot happen anymore, and relied on unique quirks of the WR build system, though.
**** ENDING LOGGING AT Wed Aug 08 02:59:58 2012

**** BEGIN LOGGING AT Wed Aug 08 02:59:58 2012
Aug 08 04:43:03 <seebs> kergoth, idle question: external-sourcery-toolchain provides virtual/libiconv, which is part of the 2008q3 version of the file, but at least in our toolchains, I don't actually SEE a libiconv, any thoughts on that?
Aug 08 04:45:01 <seebs> ... It seems to me that the answer is probably "glibc has its own iconv internally, so a separate library is not needed".
Aug 08 07:00:51 <rburton> morning
Aug 08 08:44:46 <bluelightning> morning all
Aug 08 11:15:44 <Crofton|work> gm
Aug 08 12:51:01 <use_yocto> I have a question about multilib. I have a layer which is Independent of meta. this layer include some bb files and some of them are same with bb files in meta. for example, ncurses_5.7.bb in my layer and ncurses_5.9.bb in meta. but when I run command bitbake lib32-ncurses the bb file in meta is called. I have set the priority in my layer. the prority is higher than layer in meta. why bb files in my layer can't be called ?
Aug 08 12:52:07 <use_yocto> and if I run bitbake ncurses then bb files in my layer can be called.
Aug 08 14:42:15 <jstashluk> I've added gst-plugins-base and gst-plugins-good to my image.  Only the base plugins make it to the image. Has anyone else run into this?
Aug 08 16:05:36 <bluelightning> zenlinux: hi, are you around?
Aug 08 17:04:22 <seebs> So, I just got handed a problem caused by tar-replacement-native being installed from prebuilts while the already-present copy is being used.
Aug 08 17:04:47 <seebs> And you know what? I genuinely did not realize that GNU tar does not have an option to handle replacing files which may be in use when unpacking.
Aug 08 17:04:51 <seebs> I just *assumed* it had that.
Aug 08 18:41:07 <kaiserfarrell> hi
Aug 08 18:41:17 <kaiserfarrell> anyone here?
Aug 08 18:45:10 <kaiserfarrell> ??
Aug 08 18:46:30 <hollisb> kaiserfarrell: you should ask your question and stick around for a while. if someone knows the answer, they'll answer, eventually...
Aug 08 18:47:01 <kaiserfarrell> sorry i'm new here.. :)
Aug 08 18:47:28 <kaiserfarrell> root@kaiserfarrelllinux:/media/1AC0692FC0691275/yocto# source poky-denzil-7.0.1/oe-init-build-env poky-denzil-7.0.1-build
Aug 08 18:47:28 <kaiserfarrell> bash: /media/1AC0692FC0691275/yocto/poky-denzil-7.0.1/scripts/oe-setup-builddir: Permission denied
Aug 08 18:47:31 <hollisb> kaiserfarrell: you'll find that's how most IRC channels work. people don't often monitor them minute-by-minute
Aug 08 18:47:53 <kaiserfarrell> why Permission denied?
Aug 08 18:48:51 <hollisb> probably missing the "x" permission bit on that file. how that happened is another question
Aug 08 18:49:32 <kaiserfarrell> what is "x"?
Aug 08 18:50:11 <hollisb> the execute bit
Aug 08 18:50:16 <hollisb> "/media" suggests this is external storage device... I think some distros disable execute permissions on removable storage as a security precaution
Aug 08 18:50:41 <hollisb> in other words, they prevent you from running *any* executables that reside on removable media
Aug 08 18:51:46 <kaiserfarrell> maybe permision from ubuntu..
Aug 08 18:52:56 <hollisb> kaiserfarrell: is that media a Linux filesystem (like ext3), or non-Linux (like FAT)?
Aug 08 18:53:56 <kaiserfarrell> nope.. it's ntfs
Aug 08 18:55:11 <kaiserfarrell> my ubuntu not enough space..
Aug 08 18:55:53 <hollisb> kaiserfarrell: looks like http://askubuntu.com/questions/17540/how-do-i-set-executable-permissions-on-a-removable-drive might help you
Aug 08 18:57:43 <kaiserfarrell> this my 2nd hdd
Aug 08 18:59:49 <hollisb> kaiserfarrell: then you might check /etc/fstab for the "noexec" option (https://help.ubuntu.com/community/Fstab)
Aug 08 19:00:06 <hollisb> but I suspect the first link is the one you need
Aug 08 19:00:45 <kaiserfarrell> ok i will do that
Aug 08 19:02:28 <sgw> fray: I seem to recall this from before, but I don't remember the fix (this is on a fresh F17 machine): rpmresolve: dbconfig.c:493: db3New: Assertion `dbOpts != ((void *)0) && *dbOpts != '\0'' failed.
Aug 08 19:12:46 <kaiserfarrell> thanks
Aug 08 19:13:30 <kaiserfarrell> it's about automount drive in ubuntu
Aug 08 19:22:27 <kaiserfarrell> <hollisb> did u have any tutorial for yocto?
Aug 08 19:55:14 <msm> sgw: i already had a fix for foomatic on fc17
Aug 08 19:55:21 <msm> sgw: anywho.. ;)
**** ENDING LOGGING AT Wed Aug 08 20:13:49 2012

**** BEGIN LOGGING AT Wed Aug 08 20:14:16 2012
Aug 08 20:20:02 <kaiserfarrell> i have pandaboard ES any BSP support package ?
**** ENDING LOGGING AT Wed Aug 08 20:41:31 2012

**** BEGIN LOGGING AT Wed Aug 08 20:42:22 2012
Aug 08 21:26:16 <zenlinux> msm, yeah I saw that foomatic fix in master so I've pulled it into sgarman/denzil-next
Aug 08 21:26:49 <zenlinux> btw - I had to rebase that branch to pull in two curl ssl-enabling commits I had in my oe-core branch but somehow forgot in poky, that's fixed now
Aug 08 21:27:22 * Bagder likes seeing oe-core on track with upstream curl
Aug 08 21:29:20 <Bagder> (since I maintain the upstream)
Aug 08 21:34:35 <msm> zenlinux: ok im back in sync with you, not sure what's going to happen with that owl-video bit
Aug 08 21:34:56 <msm> zenlinux: i also had a patch to poky.conf to say more distros are compatible (once ive done quite a few build tests with)
Aug 08 22:37:50 <seebs> Hmm. Is it a bug or a feature that explicit command-line requests for things in ASSUME_PROVIDED are silently ignored?
Aug 08 22:38:13 <seebs> I am inclined to think that if something was explicitly put on a bitbake command line, either we should build it or give some kind of diagnostic as to why not.
Aug 08 23:08:16 <kergoth> agreed, that does sound not ideal
Aug 08 23:20:12 <seebs> sent out a patch to bitbake-devel. It's totally trivial and obvious after a mere two hours of study and tracing.
Aug 08 23:27:01 <thaytan> :)
Aug 08 23:29:33 <pidge> hrm. M3 build is shouting about package version for the kernel going backwards.
Aug 08 23:59:20 <seebs> So apparently, if you aren't me, the proposed PSEUDO_1_4_1 branch blows up in really strange ways on Ubuntu.
Aug 09 00:00:45 <seebs> Possibly only 32-bit, though.
Aug 09 00:12:02 <seebs> Okay, technically, it is a bug that pseudo will mistakenly believe lstat() reported a file didn't exist if it is trying to expand a directory in which one of the components is a symlink over 2GB in length on a 32-bit system.
Aug 09 00:12:11 <seebs> But I am okay leaving that one for now.
Aug 09 00:12:25 <seebs> (Note: I don't mean the size of the thing linked to, I mean the size of the symlink itself.)
Aug 09 00:16:32 <thaytan> wait, you don't use sha-2^32 filenames for all your symlinks?
Aug 09 00:16:45 <seebs> what a very good idea.
Aug 09 00:17:09 <seebs> anyway, the reason I don't care is that I can't possibly succeed in allocating space for both the symlink data and the path to copy it into.
Aug 09 00:17:15 <seebs> So basically, Not My Problem.
Aug 09 00:17:23 <thaytan> right
Aug 09 00:17:35 <seebs> I am totally stumped on this one.
Aug 09 00:18:38 <seebs> I can't actually trigger the new reported failures of random and bogus modes getting set on files, but it certainly looks highly suspicious.
Aug 09 00:33:34 <thaytan> seebs: what would make it ubuntu specific? apparmor? filesystem stuff (btrfs root?)
Aug 09 00:33:47 <seebs> No idea. It might not be, it might be some other thing.
Aug 09 00:34:10 <seebs> I happen to have a fedora 17 32-bit handy, on which I can't reproduce it, but I don't have a detailed reproducer, so much as "here's what blows up late in a build".
Aug 09 00:35:18 <seebs> My trivial test was just to make and mess with some tarballs and see whether anything strange happened, but it doesn't seem to for me.
Aug 09 00:35:25 <thaytan> different version of a dependency?
Aug 09 00:36:04 <seebs> Can't imagine how it'd matter. Only thing pseudo really uses is sqlite, and if sqlite were broken on that system, this wouldn't have changed with the patch...
Aug 09 01:21:54 <seebs> I had occasion to read the changelog for zlib 1.2.7. One of the fixes is to stop relying on memmove().
Aug 09 01:22:01 <seebs> Turns out SunOS 4.1 doesn't have it.
Aug 09 01:22:11 <seebs> This code was checked in sometime in 2012.
Aug 09 01:55:48 <kaiserfarrell> what that mean? Summary: 1 task failed:
Aug 09 01:55:48 <kaiserfarrell>   virtual:native:/media/sdb3/yocto/poky-denzil-7.0.1/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.42.1.bb, do_compile
Aug 09 02:57:04 <seebs> It means that the system failed for some reason to compile e2fsprogs.
**** ENDING LOGGING AT Thu Aug 09 02:59:59 2012

**** BEGIN LOGGING AT Thu Aug 09 02:59:59 2012
Aug 09 03:39:49 <nitink> Good Morning All !
Aug 09 07:19:44 <rburton> oh hi thaytan
Aug 09 07:19:56 <rburton> wasn't expecting to see you in here
Aug 09 07:21:55 * rburton connects the dots
Aug 09 09:26:06 <sgw> bluelightning: you around?  AB Failure questions for you
Aug 09 09:26:15 <bluelightning> sgw: yep I'm here
Aug 09 09:27:08 <sgw> So what's going on with the AB master right now, we can't really ignore red for a Milestone build, and some of the backwards movement actually caused build failures.
Aug 09 09:27:46 <rburton> heh, i just pinged bluelightning myself
Aug 09 09:28:11 <bluelightning> sgw: right, it seems that way
Aug 09 09:28:28 <bluelightning> sgw: I had not anticipated this
Aug 09 09:28:32 <sgw> bluelightning: what steps can we take to reset the versions?
Aug 09 09:28:46 <rburton> for the eds/dates fails, it warned that the version went from git2 to git1, and then un-rebuild dates depends on git2
Aug 09 09:28:59 <bluelightning> one might suggest - don't do partial builds for a milestone release...
Aug 09 09:29:11 <sgw> Also since halstead is going to be taking the AB off line here shortly I don't want to start anything until that's done.
Aug 09 09:29:30 <sgw> bluelightning: so do a sstate reset for this Milestone?
Aug 09 09:30:09 <bluelightning> sgw: that's one option; another would be to dump and restore the old persistdb
Aug 09 09:30:25 <sgw> bluelightning: We have done that from time to time when issues like this exist, so that's OK
Aug 09 09:30:36 <sgw> bluelightning: how is that done and where?
Aug 09 09:30:56 <bluelightning> actually I should have thought of dumping and restoring before :/
Aug 09 09:31:18 <bluelightning> sgw: somewhere we have a copy of the old persistdb which is where the gitX numbers are stored
Aug 09 09:31:22 <sgw> Can we still do that or is the persist db not good?
Aug 09 09:31:31 <bluelightning> yeah it should be fine
Aug 09 09:31:53 <sgw> bluelightning: can we just reset the persistdb and have it rebuild it?
Aug 09 09:32:08 <bluelightning> sgw: that's how we ended up in this situation...
Aug 09 09:32:16 <bluelightning> all numbers reset to 1
Aug 09 09:32:18 <sgw> this is new to me (maybe around for a while, but I was unaware of it).
Aug 09 09:32:25 <bluelightning> sure
Aug 09 09:33:35 <sgw> bluelightning: please see pm
Aug 09 10:21:24 <rburton> "Unknown package 'locale-base-en-us'."
Aug 09 10:21:25 <rburton> argh
Aug 09 10:53:38 <sgw> halstead: how are things progressing?  Your not affecting lists.openembedded.org also are you?
Aug 09 10:58:45 <bluelightning> sgw: you're getting relay access denied as well?
Aug 09 10:59:19 <sgw> bluelightning: how did you know!
Aug 09 10:59:36 <sgw> maybe this is a general problem with the lists.oe.org machine
Aug 09 11:00:06 <sgw> bluelightning: are you proxy'ed or direct today?
Aug 09 11:00:32 <bluelightning> sgw: direct
Aug 09 11:01:15 <bluelightning> sgw: I've got one of the OE folks looking at it
Aug 09 11:01:27 <sgw> yeah me to, great thanks!
Aug 09 11:19:21 <halstead> sgw, lists.openembedded.org will not be affected.
Aug 09 11:19:41 <halstead> Okay network is going offline while the ISP updates routes.
Aug 09 11:22:11 <sgw> halstead: will that affect running AB stuff?
Aug 09 11:23:16 <halstead> sgw, As long as they don't need to access the internet at large no. They can still communicate with each other.
Aug 09 11:23:32 <sgw> Ok great
Aug 09 11:41:42 <halstead> Core services are back online.
Aug 09 11:42:00 <sgw> great news, quick
Aug 09 12:37:36 <Net147> if I run bitbake syslinux-native, how do I know where to find the native binaries for my host?
Aug 09 12:41:38 <bluelightning> Net147: they should go into tmp/sysroots/<native sysroot>/
Aug 09 12:42:00 <Net147> how do I determine "native sysroot"?
Aug 09 12:42:56 <Net147> is there a command that will tell me what the native sysroot and target sysroot is?
Aug 09 12:43:21 <bluelightning> Net147: bitbake -e | grep 'STAGING_DIR_NATIVE='
Aug 09 12:44:15 <bluelightning> for the target: bitbake -e | grep 'STAGING_DIR_TARGET='
Aug 09 12:44:20 <Net147> thanks
Aug 09 12:44:31 <Net147> is there documentation that mentions these somewhere?
Aug 09 12:44:57 <bluelightning> if you specifically want the binaries directory you should probably use STAGING_BINDIR_*
Aug 09 12:46:02 <bluelightning> Net147: it would appear our variable documentation does not cover those, no...
Aug 09 12:46:41 <bluelightning> typically you don't often need those paths externally
Aug 09 12:47:39 <bluelightning> e.g. when using syslinux-native as part of building an initramfs image, STAGING_BINDIR_NATIVE is already in the path
Aug 09 12:47:50 <bluelightning> s/path/PATH/
Aug 09 12:49:59 <halstead> All services should be restored at this point except for receiving mail from other linux foundation servers.
Aug 09 12:50:13 <Net147> well the problem I was having was that hddimg was not bootable when I wrote it to a usb pen
Aug 09 12:50:53 <Net147> hddimg doesn't seem to have a partition table
Aug 09 12:51:26 <Net147> i've successfully created bootable usb pen using other embedded build systems by creating a partition table and installing GRUB/syslinux on the device
Aug 09 12:52:57 <Net147> i've also encountered BIOS bugs with Intel D525MW where it will not boot from USB unless I put the first partition at sector 63
Aug 09 12:54:11 <bluelightning> Net147: right, there is not a partition table; that does work fine on many systems, but not all
Aug 09 12:54:21 <bluelightning> it's something we're working on improving
Aug 09 12:54:53 <bluelightning> the key is getting the right infrastructure to enable building different kinds of bootable images in a flexible and maintainable way
Aug 09 12:55:20 <Net147> and also not requiring root privileges...
Aug 09 12:55:25 <bluelightning> indeed
Aug 09 12:55:54 <bluelightning> Net147: the thread in case you're interested: http://lists.linuxtogo.org/pipermail/openembedded-core/2012-June/023484.html
Aug 09 12:56:31 <Net147> yes i've seen that thread before
Aug 09 13:19:27 <Net147> well one workaround for generating the bootable partitioned image as non-root: create blank image using dd, partition it with fdisk, dd the ext3 image into the partitioned image at the correct partition start with conv=notrunc
Aug 09 13:20:03 <bluelightning> Net147: indeed, that's the method I've used
Aug 09 13:20:34 <bluelightning> Net147: can be a little fragile if you're not careful about checking sizes exactly though
Aug 09 13:21:03 <Net147> should be okay if you calculate it precisely using a script
Aug 09 13:21:12 <Net147> would be nice if yocto had it integrated
Aug 09 13:21:46 <bluelightning> I agree
Aug 09 13:25:33 <Net147> you have script for it?
Aug 09 13:27:16 <bluelightning> it's something I did while I was playing around with the meta-raspberrypi layer
Aug 09 13:27:32 <bluelightning> it got reimplemented by someone else but it still uses the same technique I think
Aug 09 13:28:00 <bluelightning> https://github.com/djwillis/meta-raspberrypi/blob/master/classes/sdcard_image-rpi.bbclass
Aug 09 13:28:44 <Net147> thanks
Aug 09 13:30:38 <bluelightning> no worries
Aug 09 13:31:43 <Net147> what's mcopy?
Aug 09 13:33:14 <bluelightning> Net147: part of the mtools suite, which allows you to manipulate files in a FAT filesystem without mounting it
Aug 09 13:33:25 <Net147> seems useful
Aug 09 13:34:00 <bluelightning> yeah.. AFAIK it dates back to the time when Linux was unable to mount FAT filesystems directly, but it has found other uses since then such as this one
Aug 09 13:45:02 <Net147> bluelightning: http://libguestfs.org/ looks like it might be useful for user-space image manipulation as non-root
Aug 09 13:45:31 <bluelightning> Net147: I had a brief look at that as well, but when I did I found it had rather more dependencies than I would have liked...
Aug 09 13:47:21 <bluelightning> in theory it could be quite useful for this though I agree
Aug 09 13:53:02 <halstead> Mail from other LF servers is restored.
Aug 09 13:53:40 <halstead> And a bad power supply in the autobuilder master has been replaced.
Aug 09 15:43:13 <bluelightning> xxiao / xxiao_: did you figure out the cause of the problem you were having the other day?
Aug 09 15:50:05 <kergoth> hmm
Aug 09 15:50:26 <kergoth> it'd be nice if there was a convenient way to ship a prepopulated SRCREV cache from the persist data
Aug 09 15:50:37 <kergoth> so you could use autorev, etc in development, but then "lock it down" at release time
Aug 09 15:50:50 <kergoth> hmm
Aug 09 15:55:28 <kergoth> anyone else looked into this or have a solution for this already?
Aug 09 15:56:16 <bluelightning> kergoth: we're struggling with persistdb issues right now as you might have noticed
Aug 09 15:56:30 <kergoth> haven't, actually, what's going on?
Aug 09 15:57:13 <bluelightning> kergoth: I made the assumption if we reset the persistent db that we would get versions going backwards and that might kick out some buildhistory warnings but that would be the only ill effect
Aug 09 15:57:16 <bluelightning> turns out I was wrong
Aug 09 15:57:57 <kergoth> hmm, interesting
Aug 09 15:58:30 <bluelightning> for some packages (notably the evolution-data-server ones) the version was baked into a dependency and for whatever reason, that version changing did not result in the depending package being rebuilt
Aug 09 15:58:34 <bluelightning> not sure why
Aug 09 15:58:42 <kergoth> i have a need to ship layers + sources + cached-binaries together in a form which doesnt' require network access (i.e. BB_NO_NETWORK=1 should work), but I found a couple lurking recipes with either 1) ${AUTOREV} or 2) tags in SRCREV. so i either need to lock down every recipe now, which is okay but will require more work to keep updated, or emit SRCREV_pn- lines at build time somehow, or prepopulate the cache and set
Aug 09 15:58:42 <kergoth>  BB_SRCREV_POLICY=cache
Aug 09 15:59:00 <JaMa> kergoth: I'm bumping SRCREVs in recipes to last autorev from persistent db when we switch to "release" mode
Aug 09 15:59:16 <bluelightning> but it made me think that I don't believe we currently handle where SRCPV has incremented, sstate now relies upon that and then we only ship sstate
Aug 09 15:59:18 <kergoth> JaMa: *nod*. do you do that manually, or have something to automate that?
Aug 09 15:59:25 <JaMa> script
Aug 09 15:59:28 <kergoth> JaMa: seems like this is probably a common thing to want to do
Aug 09 15:59:46 <kergoth> man, srcrev/srcpv stuff gives me a headache
Aug 09 16:00:18 <bluelightning> kergoth: if you haven't already, don't look at the code then... it'll only make the headache worse
Aug 09 16:00:42 <kergoth> heh, indeed
Aug 09 16:01:25 <JaMa> kergoth: something like http://git.shr-project.org/git/?p=shr-chroot.git;a=blob;f=OE/bin/fix.autorev.sh;h=942006bbe4b7c3cfb3a5396f6105e83ca336f892;hb=HEAD but that's far from usable script for every scenario (works for mine)
Aug 09 16:01:41 <kergoth> JaMa: i was thinking about having a bit of python in our 'release' recipe which transfers the data from persist_data into its own file/db, ship that, and in a ConfigParsed handler, check for and transfer the content back to the real persist_data db, and set BB_SRCREV_POLICY to cache
Aug 09 16:01:49 <kergoth> i'll take a look, thanks, i appreciate it
Aug 09 16:02:17 <kergoth> ah, nice
Aug 09 16:10:56 <msm> does anyone know what libtirpc does? (http://sourceforge.net/projects/libtirpc/)
Aug 09 16:11:06 <msm> seems like my libpam build is trying to link against it and failing
Aug 09 16:11:55 <msm> seems like I just need to add a depends
Aug 09 16:12:23 <kergoth> it does the rpc bits that glibc did in the past
Aug 09 16:12:30 <kergoth> replaces the bits that were removed
Aug 09 16:12:45 <kergoth> (though apparently they're coming back to glibc at some point? *shrug*, ask khem)
Aug 09 16:12:53 <bluelightning> msm: this may be of interest: http://patches.openembedded.org/patch/33737/
Aug 09 16:15:11 <msm> bluelightning: yes, that's close to my problem… could even fix it ;)
Aug 09 16:18:25 <msm> libtirpc is in oe-core
Aug 09 16:18:39 <msm> so why wouldn't i add a proper depends for it instead of disable-nis
Aug 09 16:18:40 <msm> ?
Aug 09 16:19:42 <kergoth> guess it depends on whether you care about nis
Aug 09 16:19:56 <kergoth> sounds like a prospective packageconfig/distro_features
Aug 09 16:23:09 <msm> kergoth: hmm...
Aug 09 17:06:52 <Crofton|work> https://twitter.com/#!/search/dotster
Aug 09 17:17:37 <seebs> I did submit a patch for the mysterious silent failure of "bitbake bzip2-native".
Aug 09 17:31:16 <bluelightning> seebs: ah, I meant to reply to that, have just done so
Aug 09 17:31:35 <seebs> nooo spare me from your terrible wrath
Aug 09 17:31:47 <seebs> <-- has not actually seen the response, just speculating
Aug 09 17:33:07 <bluelightning> no wrath here :)
Aug 09 17:42:11 <defishguy> Has anyone had any experience with running yocto on a workgroup server for concurrent users doing builds?
Aug 09 17:42:44 <seebs> Hmm. How does this differ from one user running multiple builds against a single copy?
Aug 09 17:44:55 <bluelightning> defishguy: I think typically we only do one build at a time on each machine in the ab infrastructure; but multiple builds on the same machine should be perfectly fine if they use separate TMPDIR (and possibly SSTATE_CACHE, although we might have sufficient locking for that now, not sure)
Aug 09 17:45:49 <bluelightning> defishguy: also, you wouldn't want one user changing/updating the metadata while another is running a build, so if that's likely to happen you'd want to keep the metadata separate as well
Aug 09 17:49:03 <defishguy> bluelightning:  I work for a printer manufacturer, and we're considering a move to yocto.  Currently a chunk of our workstations are shall we say aged, and we are considering using workgroup servers for some of our devs.
Aug 09 17:49:05 <kergoth> yeah i do multiple builds on one machine quite often, keeping isolated metadata with the "project" in question. i like to isolate the changes
Aug 09 17:49:25 <kergoth> of course, you obviously want to control your BB_NUMBER_THREADS/PARALLEL_MAKE appropriate so the machine doesn't get awfully unhappy
Aug 09 17:49:35 <kergoth> heh
Aug 09 17:49:39 <defishguy> Are there performance / hardware guidelines we should be following?
Aug 09 17:50:28 <defishguy> We are thinking about as many as six devs per workgroup server.
Aug 09 17:51:34 <bluelightning> I guess it depends on how powerful that machine is and how much of it you let each dev use (i.e. how high BB_NUMBER_THREADS/PARALLEL_MAKE are set as kergoth points out)
Aug 09 17:52:27 <bluelightning> also, are the devs doing full from-scratch image builds or just an individual application? the kernel? etc.
Aug 09 17:52:31 <bluelightning> there are a lot of variables
Aug 09 17:53:35 <bluelightning> it would be useful for us to try to put together some recommendations, I'm not sure we have any documented
Aug 09 17:53:38 <defishguy> Let's assume a kernel build.
Aug 09 17:54:11 <defishguy> 16 cores, 24GB in a Dell M610 blade.
Aug 09 17:55:17 <seebs> Oh!
Aug 09 17:55:24 <seebs> Yeah, we do that.
Aug 09 17:55:29 <bluelightning> six devs on one of those sounds doable...
Aug 09 17:55:35 <seebs> I think I had somehow misunderstood the question.
Aug 09 17:55:54 <defishguy> bluelightning:  What bottlenecks should we look out for?
Aug 09 17:56:26 <bluelightning> defishguy: I/O for sure, the build is extremely I/O intensive as you might imagine
Aug 09 17:56:29 <seebs> Long story short, generally a reasonable thing. I am pretty sure they tend to be disk-performance limited, and there is no such thing as too much memory.
Aug 09 17:57:08 <seebs> If I were designing a thing to do this on, and had unlimited budget, I would be very strongly tempted to have at least the repositories and trees be on SSD, and/or have a LOT of extra memory for caching.
Aug 09 17:57:18 <defishguy> These have a few low speed 2.5" drives.
Aug 09 17:57:45 <seebs> I've got a laptop in which I've got an SSD which holds my Yocto tree, and my builds happen on a regular drive, but just having reads be nigh-instant by comparison helps a ton.
Aug 09 17:58:05 <defishguy> seebs: I can imagine.  We're considering this too.
Aug 09 17:58:11 <bluelightning> it's the speed of where TMPDIR (the output directory) is located that counts, but that needs to be capable of storing at least 50GB for a full image build per separate TMPDIR
Aug 09 17:58:30 <seebs> I/O is significant. I think the big servers are mostly using some kind of fancy network storage, or they're large boxes with a ton of drives.
Aug 09 17:58:55 <defishguy> seebs:  We're trying to get away from NFS.  We uhmmm..... over use it.
Aug 09 17:59:12 <defishguy> Our filers aren't local to the build systems.
Aug 09 17:59:13 <seebs> Well, that's good.
Aug 09 17:59:22 <seebs> Because if you try to tell me that there is a pseudo problem, and it involves NFS...
Aug 09 17:59:44 <seebs> Basically, the response will involve oompa loompas singing about how your foolhardy choices brought about your downfall.
Aug 09 18:00:03 <defishguy> seebs:  They sing here on a frequent basis.  One of them has an office.
Aug 09 18:00:25 <seebs> I think the IT people are using some kind of device where the disks are not physically in the machine, but the machine has access to them as block devices, not a networked filesystem.
Aug 09 18:00:52 <seebs> I am too old to keep up with hardware anymore, all I know is that there are some kind of wires or cables and also there are a HECK of a lot of bits on those things nowadays.
Aug 09 18:01:14 <defishguy> iSCSI and the like I'd guess.  Unfortunately we're confined to fi ber in the datacenter and ethernet to the drop.
Aug 09 18:01:40 <seebs> Okay. Well, just a technical limitation: We *know* that you can break pseudo with NFS. And yocto relies on it.
Aug 09 18:01:59 <seebs> It will probably work much of the time, but if you wanted to break it, you could, and I have never found adequate defenses against it.
Aug 09 18:02:00 <defishguy> I'm glad to learn that.
Aug 09 18:02:23 <seebs> Note, though: This only matters for TMPDIR, basically.
Aug 09 18:03:34 <seebs> Technical details: Pseudo is somewhat dependent on being pretty sure that device and inode numbers are stable. NFS does not provide much for guarantees of this. Also, pseudo uses flock() locking, which almost never works over NFS, and yes there is a reason it's not fcntl locking.
Aug 09 18:04:00 <seebs> ... It may come as a TOTAL SHOCK to find that I have been asked a few times about pseudo and NFS.
Aug 09 18:06:33 <defishguy> seebs:  Thank you for the information.
Aug 09 18:07:02 <seebs> Well, it is in my best interests that people succesfully migrate to yocto, and that does in a few cases involve knowing what NOT to try. :)
Aug 09 18:16:11 <seebs> ...
Aug 09 18:16:18 <seebs> Okay, I need to revise the variable tracking patches.
Aug 09 18:16:28 <seebs> On one of my builds, the variable logging for BBCLASSEXTEND is *TEN MEGABYTES*.
Aug 09 18:16:33 <seebs> One. Variable.
Aug 09 18:16:50 <seebs> The variable itself is only about 27K.
Aug 09 18:17:06 <seebs> But I print the first word, then the first two words, then the first three words, then...
Aug 09 18:19:26 <hollisb> :)
Aug 09 18:27:03 <seebs> Is "COREBASE" meaningful to bitbake?
Aug 09 18:27:24 <seebs> By which I mean: Is that an oe-coreism, that bitbake should not be aware of, or can bitbake sanely refer to it?
Aug 09 18:27:40 <seebs> The context here is variable tracking cleanup. I would like to strip a leading COREBASE from reported file names.
Aug 09 18:28:04 <seebs> Because in practice nearly all variable assignments come from there, so it's visual clutter galore and makes it hard to see the real file names.
Aug 09 18:28:46 <seebs> But it occurs to me that the value is defined in oe-core stuff, and I seem to recall that bitbake tries to avoid overt dependencies on oe-core's selection of variables.
Aug 09 18:55:46 <seebs> Oh, hey, and an actual bug in terms of reporting incorrectly on what happened!
Aug 09 19:04:44 <seebs> hmm
Aug 09 19:05:15 <seebs> In the variable tracking stuff: Would people be horribly offended by an idiom that the filename "Ignore" is used to indicate that an operation should not be tracked?
Aug 09 19:05:59 <seebs> There's a couple of cases where we want to use setVar, but it's unhelpful to the user to track them; parts of finalize(), for instance, or ConfHandler.py setting FILE.
Aug 09 19:07:17 <kergoth> seebs: bitbake has *zero* knowledge of COREBASE or anything else metadata specific
Aug 09 19:07:22 <seebs> Okay.
Aug 09 19:08:04 <seebs> Hmm. I would like to have some mechanism for cleaning up file name reporting, but I can't think of a way to pass that information to bitbake.
Aug 09 19:08:50 <kergoth> i expect the best you could do would be generate relative paths from $PWD or something
Aug 09 19:09:12 <seebs> Something like DATA_TRACKING_PATH[FOO] = "${FOO}", maybe, and the tracker looks up the flags of DATA_TRACKING_PATH and substitutes them.
Aug 09 19:09:32 <seebs> But anything I can communicate as configuration would have to be at least one variable with special meaning to bitbake, and I don't want that.
Aug 09 19:10:13 <kergoth> adding new variables probably isn't ideal, we have too many already :)
Aug 09 19:10:23 <seebs> Yeah.
Aug 09 19:10:36 <seebs> I think I'll just ignore the file name thing for now.
Aug 09 19:10:50 <seebs> That said, while cleaning this up, I found a genuine "that report is just plain wrong" error in the tracking.
Aug 09 20:13:51 <creber> Hello everybody,
Aug 09 20:14:00 <seebs> *hides*
Aug 09 20:14:24 <creber> One question about native sdk compilation. I need to build native sdk from a modern i686 machine and distribute it over a various set of i686 machines for application developement.
Aug 09 20:14:32 * mranostay drags seebs back in
Aug 09 20:14:58 <creber> However, I face on some machines "segfault" or "illegal instruction" while executing sdk binary.
Aug 09 20:15:15 <creber> running bitbake -e show that
Aug 09 20:15:21 <creber> SDKMACHINE is set to i686.
Aug 09 20:15:35 <seebs> How "various" are these machines? Similar OS versions? 32-bit, 64-bit?
Aug 09 20:16:02 <creber> all 32-bits
Aug 09 20:16:09 <creber> OS might be different
Aug 09 20:16:27 <creber> I mean kernel version might differ
Aug 09 20:16:47 <creber> SDKMACHINE is set to i686 & SDK_CC_ARCH="-march=i686"
Aug 09 20:20:00 <creber> -march=i686 does not seem to be used while doing native compilation
Aug 09 20:21:30 <creber> grep '-march=i686'    in tmp-eglibc/work/i686-linux show nothing relevant
Aug 09 20:22:57 <seebs> Well, the obvious thing would be: Is it possible that the SDK stuff is built against a newer libc or other library than the other machines have, or otherwise expecting different host environment stuff?
Aug 09 20:23:03 <seebs> The SDK is not 100% self-contained, I don't think.
Aug 09 20:23:34 <seebs> And improved variable tracking patches have been sent out.
Aug 09 20:23:50 <seebs> That has been looming over my head as requiring more attention for WEEKS.
Aug 09 20:28:06 <creber> <seebs> The SDK is not 100% self-contained, I don't think  => after a source environment-setup-... & a ldd on a segfaulting binary, I can see that most runtime dependencies (inc libc) are being resolved in the sdk except libstdc++
Aug 09 20:28:44 <seebs> hmm
Aug 09 20:28:53 <seebs> What's one of the binaries which segfaults?
Aug 09 20:28:55 <creber> will have a deeper look about the libc++ version on the sdk-builder machine & the "developer" machine
Aug 09 20:29:11 <creber> typically "file" & "moc"
Aug 09 20:29:28 <seebs> General cheap guideline: If you aren't sure, build the SDK on the oldest system on offer.
Aug 09 20:29:36 <seebs> Linux has really good compatibility with older binaries, usually.
Aug 09 20:29:52 <creber> "qmake" is working fine
Aug 09 20:31:03 <creber> yes, unfortunatly we used a brand new (& fresh installed) machine for image compilation & old machines for development ;) But I might try to installed older OS version
Aug 09 20:32:14 <kergoth> yeah building on the oldest machine is helpful for any binary you need to ship or use
Aug 09 20:32:22 <kergoth> we use centos5 for our stuff
Aug 09 20:32:25 <kergoth> heh
Aug 09 20:34:01 <creber> @kergoth =>  Ouch ;)
Aug 09 20:34:24 <kergoth> oh there's pain involved, indeed :)
Aug 09 20:35:12 <creber> I believe you ...
Aug 09 20:35:32 <creber> I'm still confused to not see any -march=i686 in the compilation log of tmp-eglibc/work/i686-linux. It shouldn't be the case ?
Aug 09 20:49:38 <khem> kergoth: yes rpc has been reinstated into glibc/eglibc 2.16 but as on obsolete feature
Aug 09 20:49:48 <kergoth> ah
Aug 09 20:49:57 <khem> kergoth: thats for time being until libtirpc becomes a full replacement for it
Aug 09 20:50:04 * kergoth nods
Aug 09 20:50:06 <kergoth> makes sense, thanks
Aug 09 20:50:26 <khem> kergoth: and I have enabled the obsoleted feature for us
Aug 09 20:50:33 <khem> so we are good there
Aug 09 20:50:59 <khem> now waiting for libtirpc to implement the missing APIs
Aug 09 20:51:24 <khem> and then one day in future glibc will happily redirect users to it. We are not there yet
Aug 09 20:52:04 <khem> qemu for x86 does not support nptl !!
Aug 09 20:52:09 <khem> in user mode
Aug 09 20:52:25 <khem> but it works for other arches
Aug 09 20:52:36 <khem> something where things are lagging on x86 :)
Aug 09 21:00:46 <seebs> creber: I don't know for sure, but I think the SDK stuff will mostly just trust that the host compiler has the right defaults.
Aug 09 21:01:33 <seebs> ... and yes, someone pointed out that one of the changes in patch #3 doesn't do anything. I'll take it out.
Aug 09 21:09:55 <creber> seebs:  ok, will have a look in this area. thx a lot for your support
Aug 09 22:04:33 <seebs> Well, the good news is, I reproduced the strange file type corruption thing someone reported with pseudo 1.4.1.
Aug 09 22:04:51 <seebs> The bad news is, cleaning and remaking that particular recipe does not reproduce it.
Aug 09 22:09:06 <khem> kergoth: have you used unionfs or similar things
Aug 09 22:10:23 <kergoth> khem: many many years ago, but not since
Aug 09 22:10:30 <kergoth> i doubt the stuff i played with even exists anymore :)
Aug 09 22:11:08 <seebs> I used it at one point for some tiny embedded project.
Aug 09 22:11:22 <seebs> This was BSD on an x86 board, though, so maybe not very relevant.
Aug 09 22:14:46 <khem> so I am thinking that boot the system with minimal initramfs
Aug 09 22:14:53 <khem> so it can do unionfs mounts
Aug 09 22:15:05 <khem> and then bring in the full rfs over nfs
Aug 09 22:15:15 <khem> it is something sensible at all?
Aug 09 22:15:29 <khem> I want to avoid user mode nfs
Aug 09 22:16:25 <khem> well my initramfs will do a bit more here where it needs to have nfs-client up and running etc.
Aug 09 22:16:49 <khem> so I want initramfs to populate the /dev correctly in ram
Aug 09 22:17:19 <khem> ramfs
Aug 09 22:19:26 <seebs> There was this one time when I had what seemed to be a moderately positive experience with an NFS rootfs, but then it turned out I was wrong.
Aug 09 22:20:21 <khem> seebs: usually yes. what were issues you ran into
Aug 09 22:20:35 <khem> seebs: my problem is that rfs will be like 500-600M
Aug 09 22:20:50 <khem> so I can not copy it into RAM although I would prefer
Aug 09 22:20:55 <khem> but it will be too much
Aug 09 22:21:00 <seebs> Well, in general, the issue is: I have not been happy with the consistent reliability of NFS. :P
Aug 09 22:21:16 <seebs> Hmm.  I know the historical Unix answer is "mount /usr later".
Aug 09 22:21:18 <khem> one problem I have is that it needs root access
Aug 09 22:21:27 <ant__> khem: hi there, so the issue is thumb code for armv4 ?
Aug 09 22:21:45 <khem> ant__: you ran away, I wanted to ask quesions
Aug 09 22:21:57 <khem> seebs: yes mounting /usr later is ok
Aug 09 22:22:01 <ant__> pls fire
Aug 09 22:22:23 <khem> seebs: my problem, is provide an easy way for folks to boot there own rfs
Aug 09 22:22:35 <khem> without doing root user stuff
Aug 09 22:22:50 <khem> ant__: so you said that the same init worked ok on armv5t
Aug 09 22:23:08 <khem> ant__: Did you try to apply that gcc patch I mentioned  and rebuild the rfs
Aug 09 22:23:55 <ant__> I have to read the logs, I just applied that other 'unbreak armv4' patch
Aug 09 22:24:18 <seebs> Hmm.
Aug 09 22:24:30 <seebs> What we do usually involves user-mode NFS and pseudo.
Aug 09 22:25:57 <ant__> khem: think about the initramfs we use for kexecboot: custom init mounts the devices and finds bootable rootfs. We plan to add NFS
Aug 09 22:26:01 <khem> ant__: yes that patch
Aug 09 22:26:36 <khem> seebs: someone said unfs was a toy
Aug 09 22:26:44 <khem> ant__: I think that patch will help
Aug 09 22:26:46 <ant__> ok, I applied it to gcc_4.7 and rebuilt the tc
Aug 09 22:27:02 <khem> ant__: you need to rebuild everything with it
Aug 09 22:27:03 <ant__> theat binary is the result
Aug 09 22:27:10 <ant__> yes, from scratch
Aug 09 22:27:12 <khem> ok
Aug 09 22:27:14 <khem> and ?
Aug 09 22:28:13 <ant__> kernel panic, we can't reach the console
Aug 09 22:28:26 <ant__> no way to run it on collie
Aug 09 22:29:07 <ant__> it could be the kernel as well
Aug 09 22:29:25 <khem> hmmm
Aug 09 22:29:27 <ant__> http://paste.debian.net/182874/
Aug 09 22:29:37 <ant__> here we use klibc dash as init...panic
Aug 09 22:29:57 <ant__> ah, note klibc in OE doesn't use thumb...
Aug 09 22:30:02 <khem> ant__: ok
Aug 09 22:30:36 <khem> ant__: enable debugging in kernel
Aug 09 22:30:38 <ant__> (I did some tests with hpa enabling it and the code was running)
Aug 09 22:30:46 <ant__> but it's ot
Aug 09 22:31:02 <ant__> yes, definitely...missing console sounds bad
Aug 09 22:31:31 <ant__> khem: I don't have that device, that's why I asked about qemu
Aug 09 22:32:42 <ant__> khem: about thumb interworking on armv4, I'm more confused after having read   http://wiki.debian.org/ArmEabiPort/
Aug 09 22:32:49 <ant__> :)
Aug 09 22:33:13 <ant__> "Thumb interworking suggests armv4t"
Aug 09 22:33:40 <ant__> "..as an alternative to BX. It works on ARMv4 and above and Thumb interworking is possible on ARMv4t and above, .."
Aug 09 22:34:30 <khem> ant__: yes it will work on armv4
Aug 09 22:34:55 <khem> ant__: IIRC when I did the original work on OE I made sure that we supported EABI back until armv4
Aug 09 22:35:04 <khem> so we could get rid of OABI completely
Aug 09 22:35:33 <khem> its just additional linker options that glues bx
Aug 09 22:36:10 <khem> ant__: ok can you pass --with-cpu=armv4 options to gcc ?
Aug 09 22:37:01 <ant__> for one file or rebuilding you mean?
Aug 09 22:37:11 <khem> ant__: in gcc-configure-common.inc add above to EXTRA_OECONF
Aug 09 22:37:16 <khem> no
Aug 09 22:37:23 <khem> I mean add it and then rebuild everything
Aug 09 22:37:33 <khem> I am thinking that libgcc is not built correctly
Aug 09 22:37:36 <ant__> ok
Aug 09 22:37:59 <khem> might have extra intructions
Aug 09 22:38:05 <khem> that armv4 does not like
Aug 09 22:38:11 <ant__> I'll rebuild the debug kernel before, should not matter
Aug 09 22:38:23 <khem> yeah it should not
Aug 09 22:38:32 <khem> these are independent excercises
Aug 09 22:38:56 <khem> btw. paste the run.do_configure of gcc-cross and gcc-runtime please
Aug 09 22:39:05 <ant__> ok
Aug 09 22:39:11 <khem> and I suppose you are on oe-core/master
Aug 09 22:39:31 <ant__> just to finish, I'll add --with-cpu=armv4  AND the
Aug 09 22:39:42 <ant__>  http://repository.timesys.com/buildsources/g/gcc/gcc-4.7.0/gcc-4.7.0-arm-unbreak-eabi-armv4t.patch
Aug 09 22:41:10 <khem> yeah thats fine
Aug 09 22:41:21 <khem> and this is collie board right
Aug 09 22:41:32 <ant__> zaurus collie, yes
Aug 09 22:42:29 <khem> if you have recent enough qemu you should have the board emulated there
Aug 09 22:42:32 <khem> see http://lists.gnu.org/archive/html/qemu-devel/2011-03/msg02651.html
Aug 09 22:42:58 <ant__> last I've heard from lumag, he was planning to commit
Aug 09 22:45:32 <ant__> khem: http://paste.debian.net/182986/ http://paste.debian.net/182987/
Aug 09 22:46:33 <ant__> march=armv4
Aug 09 22:47:20 <khem> Collie -> SL C5500 -> SA-1110 -> based on ARMv4
Aug 09 22:47:52 <ant__> right
Aug 09 22:48:07 <khem> ant__: these are log.do_* files
Aug 09 22:48:13 <khem> I asked for run.do_*
Aug 09 22:48:53 <khem> -march=armv4  -mthumb-interwork -mtune=strongarm1100
Aug 09 22:48:56 <ant__> I have two builds.. let me check the right one
Aug 09 22:49:01 <khem> seems fine to me
Aug 09 22:50:29 <khem> you said same binary ran ok on armv5t
Aug 09 22:50:40 <khem> so there must be something gcc is leaking in
Aug 09 22:50:54 <ant__> yes, on other 3 zaurus (pxa250, pxa255, pxa270)
Aug 09 22:51:00 <khem> which should be fixed when you do --with-cpu
Aug 09 22:51:20 <ant__> khem: we suspected the userspace could be poisoned
Aug 09 22:51:28 <khem> yes
Aug 09 22:51:34 <ant__> the issue is more generic: kernel panic
Aug 09 22:51:56 <khem> well kernel panic can mean several things one is that it took an intruction trap
Aug 09 22:51:58 <khem> and died
Aug 09 22:52:09 <ant__> still the init runs on other devices so it's not miscompiled
Aug 09 22:52:16 <ant__> (klcc)
Aug 09 22:52:41 <khem> yes thats because its probably using intructions that are not known to sa-1110
Aug 09 22:53:04 <ant__> ok, you are confirming that we could indeed have a toolchain issue
Aug 09 22:53:21 <khem> I am not confirming. I am speculating
Aug 09 22:53:25 <khem> thats all I can do
Aug 09 22:53:37 <khem> unless you report back with results
Aug 09 22:53:41 <ant__> I reword: two paths of failure: kernel , toolchain
Aug 09 22:53:48 <khem> yes
Aug 09 22:54:20 <ant__> then it's better I don't recompile th ekernel now
Aug 09 22:54:29 <ant__> I'l lrebuild all from scratch
Aug 09 22:54:36 <khem> OK another thing you could try is build core-image-minimal and avoid the whole klibc/klcc
Aug 09 22:54:40 <khem> and see if that works
Aug 09 22:54:49 <khem> then you know that klcc is not configured right
Aug 09 22:54:55 <ant__> done, still we can't boot :)
Aug 09 22:55:01 <khem> k
Aug 09 22:55:06 <khem> thats good
Aug 09 22:55:16 <ant__> klcc zaps the CC settings
Aug 09 22:55:59 <ant__> (klibc.bbclass does it)
Aug 09 22:58:36 <khem> ant__: another thing you need to try is apply http://git.openembedded.org/openembedded/tree/recipes/gcc/gcc-4.5/gcc-armv4-pass-fix-v4bx-to-ld.patch
Aug 09 22:58:49 <khem> or rather forward port it to gcc 4.7
Aug 09 22:58:57 <ant__> sure
Aug 09 22:59:34 <khem> do you have your toolchain handy ?
Aug 09 23:00:17 <ant__> I'm err removing tmpdir :p
Aug 09 23:00:37 <ant__> I have an old, unpatched toolchain
Aug 09 23:02:35 <khem> can you give me output of arm-blah-gcc -march=armv4 --verbose -xc /dev/null
Aug 09 23:03:05 <khem> I think the gcc patch I pointed above is gonna fix it for you
Aug 09 23:03:16 <ant__> see pm
Aug 09 23:13:03 <seebs> Ah-hah.
Aug 09 23:13:08 <seebs> #define base_lstat lstat64
Aug 09 23:13:10 <seebs> should have been
Aug 09 23:13:15 <seebs> #define base_lstat real_lstat64
Aug 09 23:13:34 <seebs> Inside a chroot, I ended up re-adding the chroot path when calling stat on things inside functions like rename()
Aug 09 23:22:26 <thaytan> seebs: \o/
Aug 09 23:26:39 <seebs> Interestingly, Linux pseudo has never *had* wrappers for stat64 et al.
Aug 09 23:26:42 <seebs> Because no one ever calls them.
Aug 09 23:27:17 <seebs> Any code which looks to the casual eye like it calls them is almost certainly actually calling __lxstat64() or something, and even if it isn't, the libc stat64 calls that anyway.
Aug 09 23:59:18 <kb> Hi, how do we define CROSS_COMPILE variable in a recipe?
Aug 10 00:17:07 <pidge> halstead: check your email. network horkage on ab.
Aug 10 01:43:10 <pidge> halstead: you rule. thank you for the server fix and build kick.
Aug 10 01:43:44 <halstead> pidge, You're welcome :) Sorry I didn't think to check the host files.
Aug 10 01:52:13 <pidge> halstead: It's ok. I'm sure you were exhausted
Aug 10 01:52:48 <halstead> A little. Waking up at 2am to drive to Corvallis will do that.
Aug 10 02:01:10 <pidge> halstead: ugh
**** ENDING LOGGING AT Fri Aug 10 02:59:58 2012

**** BEGIN LOGGING AT Fri Aug 10 02:59:59 2012
Aug 10 08:31:41 <bluelightning> morning all
Aug 10 09:18:55 <bluelightning> halstead: ping
Aug 10 11:18:43 <abddellah> hell
Aug 10 11:18:46 <abddellah> o
Aug 10 11:49:43 <tavish3> hi, i have CORE_IMAGE_EXTRA_INSTALL ?= "ffmpeg"
Aug 10 11:50:18 <tavish3> in my local.conf; ffmpeg is not being included in the rootfs. What may be the problem>?
Aug 10 11:53:01 <bluelightning> tavish3: ?= means set if not already set... are you sure it hasn't already been set?
Aug 10 11:53:17 <bluelightning> you can verify with bitbake -e | grep CORE_IMAGE_EXTRA_INSTALL
Aug 10 11:55:00 <tavish3> bluelightning: oh, thanks! that was it. i had used it for another package earlier.
Aug 10 11:55:46 <bluelightning> no problem :)
Aug 10 12:58:45 <Noor> hi
Aug 10 12:59:11 <Noor> is bitbake commander installer included in yocto release?
Aug 10 14:20:45 <steve165> hi there. I am a newbie to Yocto and Open Embedded. I've  got a  build issue
Aug 10 14:21:22 <bluelightning> steve165: hi, sure, what's the issue?
Aug 10 14:21:47 <steve165> I can build the core-image-minimal succesfully (so I thought but there is .hddimg file
Aug 10 14:22:30 <steve165> I want to build an SD card and boot up mybeagleboard with it
Aug 10 14:27:18 <bluelightning> steve165: ok, FYI there are instructions on how get the image booting on the board in README.hardware
Aug 10 14:30:46 <steve165> BlueLightning: OK,Thanks I didn't spot that -  I thought I'd gone through everything
Aug 10 14:41:46 <steve165> BlueLightning: I didn't select BeagleBoard machine but qemuarm. I sort of assumed that if I selected arm architecture I would get something to load
Aug 10 14:42:54 <steve165> I'm re-running now, giving my laptop a real work out!
Aug 10 14:42:58 <darknighte> msm: quick question.  what's the best place to submit P2020 patches?
Aug 10 14:44:56 <bluelightning> steve165: ok, yeah, qemuarm may not just work on all arm-based devices; best to choose the specific machine
Aug 10 18:56:26 <msm> is the 1.3 release dropping support for CentOS 5.x?
Aug 10 18:56:54 <msm> there are some issues with certain recipes for older glibcs now
Aug 10 18:56:54 <msm> https://gist.github.com/3316803
Aug 10 19:01:13 <bluelightning> msm: no, I think we still have interest in preserving that support, so if there are issues we should consider them bugs that need fixing
Aug 10 19:01:45 <msm> bluelightning: ok im going through the process, ill look at fixes and / or bug
Aug 10 20:21:38 <blloyd|work> I'm having fun trying to do an "HD install" for a yocto image.  Anyone have any suggestions?  Dev machine is a Fedora 64 bit system.  I'm not sure it's grub is compatible with the device.
Aug 10 20:22:06 <blloyd|work> (device does Loading GRUB infinite reboot loop).
Aug 10 20:25:00 <msm> does yp run patchworks on it's ml?
Aug 10 20:26:06 <fray> no
Aug 10 20:37:34 <msm> it should ;)
Aug 10 20:37:37 <msm> can I file a bug?
Aug 10 21:00:44 <bluelightning> msm: so far I don't think anyone's been able to make it work practically
Aug 10 21:01:07 <bluelightning> in order to be practical it would need to auto-mark merged patches
Aug 10 21:01:14 <msm> yea, you guys use poky-contrib fairly well
Aug 10 21:01:31 <msm> u-boot has done some work in the regard (auto marking patches applied) of course it's never perfect
Aug 10 21:01:38 <msm> its a nice database of patches I can pull from though
Aug 10 21:03:02 <bluelightning> msm: FWIW I'd like to see it working as well, so the patch queue is obvious...
Aug 10 21:03:19 <bluelightning> richard manages fine without it but I think others might find it useful
Aug 10 22:05:56 <rburton> bluelightning: and richard's magic process is opaque to outsiders
Aug 10 22:06:08 <rburton> bluelightning: i suspect his house is covered in postit notes, one per patch
Aug 10 22:16:02 <khem> bluelightning: OE patchwork automarks merged patches
Aug 10 22:16:47 <khem> bluelightning: Koen uses is and we have it for OE-Core as well I forgot if I have enabled it for OE-Core but it works
Aug 10 22:17:06 <khem> its not perfect but does most of work
Aug 10 22:19:36 <khem> msm: I think we should still support centos 5.x
Aug 10 22:19:43 <khem> may be not 4.x since its EOLed
Aug 10 22:20:46 <walters> released linux-user-chroot 2012.2, in case anyone might be motivated to try using it instead of pseudo: https://lkml.org/lkml/2012/8/10/290
Aug 10 22:21:26 <walters> (would be lots of hard work, but just fyi)
Aug 10 22:21:48 <khem> walters: what does it offer over pseudo
Aug 10 22:21:57 <walters> khem, there is no emulation layer
Aug 10 22:22:26 <walters> you build a root containing what you want (via cp or more ideally, hard links), and chroot in (and you can --clone-newnet to get no networking), and build
Aug 10 22:22:54 <khem> hmm sounds nice
Aug 10 22:22:56 <walters> e.g. one could copy in just selected binaries and libraries from the host
Aug 10 22:23:13 <khem> I would certainly be interested in knowing its overhead vs pseudo
Aug 10 22:23:15 <walters> actually just using --unshare-net would probably be useful
Aug 10 22:23:31 <walters> khem, it's literally as fast as your regular filesystem
Aug 10 22:23:47 <khem> we have started to use pseudo extensively earlier it was just a fakeroot replacement
Aug 10 22:23:51 <walters> it's just chroot as non-root (+ some linux container feature accesses)
Aug 10 22:24:06 <khem> walters: I see
Aug 10 22:24:31 <walters> yeah, so instead of e.g. running tar under fakeroot/pseudo, you'd need to add options to tar like --set-owner-uid=0 --set-owner-gid=0
Aug 10 22:24:40 <walters> my build system does something like that
Aug 10 22:24:41 <khem> walters: I think to get it accepted there has to be some amount of work done in OE
Aug 10 22:25:01 <khem> and its use is very extensive so need someone to baby sit as well
Aug 10 22:25:03 <walters> khem, oh it'd be a *lot* of work - i'm not planning to do it myself, just mentioning it exists =)
Aug 10 22:25:36 <khem> but its a compelling option
Aug 10 22:25:42 <khem> I would say
Aug 10 22:26:15 <khem> one way to get some traction is show some benchmarks where it beats hell out of pseudo
Aug 10 22:26:27 <khem> and that can get some folks interested
Aug 10 22:26:35 <khem> since we always look to reduce build times
Aug 10 22:27:18 <walters> https://lkml.org/lkml/2011/12/8/227
Aug 10 22:27:39 <blloyd|work> what is a reasonable build time anyway?  I feel like a complete build of a sato image from scratch is an hour plus, but haven't actually timed it yet.
Aug 10 22:28:59 <walters> probably the ugliest part would be figuring out what files host binaries depend on in order to put them in the root (relatively easy for native ones, just copy in DT_NEEDED...for python, more gross)
Aug 10 22:50:17 <bluelightning> khem: you can see how well it works by the number of patches still shown under oe-core... :/
Aug 10 22:50:25 * bluelightning -> sleep
Aug 10 22:50:33 <bluelightning> night all
Aug 10 23:33:27 <seebs> Yeah, there is a ton of room for making pseudo faster.
Aug 10 23:34:04 <seebs> For filesystem-heavy operations like large tar ops, I can get a 5x-10x speedup for some loads, but I can never get time to properly work on the needed changes.
**** ENDING LOGGING AT Sat Aug 11 02:59:58 2012

**** BEGIN LOGGING AT Sat Aug 11 02:59:58 2012
Aug 11 05:14:43 <msm> khem: O_CLOEXEC
**** ENDING LOGGING AT Sun Aug 12 02:59:59 2012

**** BEGIN LOGGING AT Sun Aug 12 02:59:59 2012
Aug 12 09:27:14 <RP> seebs: I'd better complain louder about pseudo then ;-)
Aug 12 10:19:36 <bluelightning> morning RP, all
Aug 12 10:35:31 <sgw> Hi bluelightning:
Aug 12 10:35:44 <bluelightning> hi sgw
Aug 12 10:37:56 <RP> hi sgw, bluelightning
Aug 12 10:37:58 <sgw> I have been trying to reproduce that rpmdepend thing, with no luck, even in the failed build!  Any luck on your end on Friday?
Aug 12 10:38:25 <bluelightning> sgw: I didn't carry on working on it in the evening...
Aug 12 10:38:44 <RP> sgw, bluelightning: anything I need to pull in urgently patch wise?
Aug 12 10:39:20 <bluelightning> RP: no, but we do need to talk about how the persistdb contents are handled when building from sstate
Aug 12 10:39:35 <bluelightning> we can have that discussion on monday though naturally :)
Aug 12 10:39:46 <RP> bluelightning: in person even!
Aug 12 10:39:52 <bluelightning> indeed :)
Aug 12 10:40:06 <sgw> RP, I pulled one thing into the 1.3_m3 branch, (watchdog SRC_URI fix), we are seriously flailing around with buildhistory and the rpmdepends heisien-bug
Aug 12 10:40:26 <bluelightning> s/buildhistory/persistdb/
Aug 12 10:40:34 <sgw> bluelightning: sorry correct
Aug 12 10:40:59 <sgw> RP: I was going to build a mut while we try to deal with the other stuff, just to be ready.
Aug 12 10:42:09 <RP> ok, thanks. I'd kind of guessed there were some issues :/
Aug 12 10:53:44 <sgw> bluelightning: Check your inbox shortly, I would like you and Robert to work on resolving that dbOpts issue tomorrow, please.
Aug 12 10:54:42 <bluelightning> sgw: sure
**** ENDING LOGGING AT Mon Aug 13 02:59:58 2012

**** BEGIN LOGGING AT Mon Aug 13 02:59:59 2012
Aug 13 08:48:16 <bluelightning> morning all
Aug 13 10:45:42 <rburton> when using PACKAGECONFIG, how would i turn options on by looking at the target arch (i.e. replace EXTRA_OECONF_append_x86)
Aug 13 10:50:04 <rburton> @base_contains('MACHINE_FEATURES', "x86",...)?
Aug 13 12:53:47 <ignus> hi all, can anyone help me figure out why my kernel modules arnt being installed in my root fs?
Aug 13 14:17:42 <ag_> Hello everybody. Can anybody point me to python code where git clone is run with a timeout or something?
Aug 13 14:20:16 <ag_> Obviously of there is such thing.
Aug 13 14:26:12 * walters_ hits a "running make install with -j > 1" issue in eglibc
Aug 13 14:42:54 <bluelightning> ignus: hi, still need some help?
Aug 13 14:43:11 <ignus> bluelightning, yeah, if you have a sec?
Aug 13 14:43:15 <bluelightning> ignus: sure
Aug 13 14:44:28 <ignus> are the kernel modules normally installed in the rootfs or just packaged as a .gz file?
Aug 13 15:52:20 <bluelightning> ignus: depends... if you want all modules installed you can add "kernel-modules" to your IMAGE_INSTALL
Aug 13 15:52:34 <bluelightning> otherwise you can specify individual modules to be installed
Aug 13 15:53:44 <bluelightning> typically with the latter you would add them to MACHINE_EXTRA_RRECOMMENDS or MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS; or alternatively bring them in via additional task recipes (using RRECOMMENDS in case the kernel config is changed to compile them in)
Aug 13 19:16:04 <seebs> I have just realized what sanity.bbclass and friends are missing. We have various checks for *host* requirements, but we do not have much checking for *user* requirements.
Aug 13 19:16:34 <seebs> We clearly need to have sanity.bbclass issue messages like "WARNING: You really don't know how to read configure output. In the event of errors, you will have no idea what went wrong."
Aug 13 20:06:42 <ant__> zeddii: any kernel > 3.4 in sight?
Aug 13 20:10:45 <zeddii> the dev kernel is sitting on the -rc's, since I was just going to jump to 3.6-rc1 this week. but nothing in a named recipe, since yocto 1.3 is going out with 3.4.x as the main kernel. but dev will definitely be 3.6 shortly.
Aug 13 20:11:15 <zeddii> typed that too fast. it's currently on 3.5-rc, but I skipped updating it to a full 3.5, since I was going to jump to 3.6.
Aug 13 20:13:28 <ant__> great to hear
Aug 13 20:13:46 <ant__> we have some old device getting 3.5 vanilla support
Aug 13 20:14:32 <ant__> now, what about linux-yocto-tiny? Is still at 3.2.
Aug 13 20:15:28 <zeddii> dvhart normally takes care of it, but it should jump to 3.4, and then follow to > 3.4 for yocto 1.4.
Aug 13 20:16:07 <ant__> I see, thx
Aug 13 20:17:25 <ant__> fwiw I plan to fragment my configs approaching 3.4
Aug 13 20:17:49 <ant__> now battling with an armv4 toolchain bug :/
Aug 13 20:18:59 <ant__> the chickens in the cage are all pxa apart one old strongarm
Aug 13 20:19:38 <ant__> this one makes us badly suffer this torrid August...
Aug 13 20:20:11 <zeddii> doesn't sound like fun!
Aug 13 20:22:40 <ant__> I'd be already on 3.4 if it wasn't for that 3.2 kernel panic'ing when switching to init
Aug 13 20:22:54 <ant__> Khem suspects there is armv5t code
Aug 13 20:24:43 <ant__> khem: btw here a similar version of the patch  https://dev.openwrt.org/browser/trunk/toolchain/gcc/patches/4.7-linaro/840-armv4_pass_fix-v4bx_to_ld.patch
**** ENDING LOGGING AT Tue Aug 14 02:59:58 2012

**** BEGIN LOGGING AT Tue Aug 14 02:59:58 2012
Aug 14 07:13:22 <sgw> Strange error of the day time!  Anyone seen this before on an x86-64 build machine:
Aug 14 07:13:22 <sgw> | ImportError: /usr/lib/python2.7/lib-dynload/_collectionsmodule.so: wrong ELF class: ELFCLASS32
Aug 14 07:28:16 * sgw finds this very strange, the cp-noerror script is using the sysroot python and finding the /usr/lib/python2.7 dir (32bit), but when I run cp-noerror standalone it uses the /usr/lib64/python2.7 (64bit) stuff correctly!
Aug 14 07:45:05 <halstead> We have had a short outage for downloads.yoctoproject.org. This appears to be caused by the ongoing problems with virtio.
Aug 14 07:46:00 <halstead> Outside connections were dropped from 12:15am to 12:23am PDT.
Aug 14 08:32:33 <bluelightning> morning all
Aug 14 10:12:56 <likewise> gm
Aug 14 10:14:15 <RoadRunnR> Hi
Aug 14 10:14:37 <likewise> gm ro
Aug 14 10:14:56 <RoadRunnR> i got a problem with bitbake, it seems that it is messing up dependencies when BB_NUMBER_THREADS is 4 or higher
Aug 14 10:14:56 <likewise> gm RoadRunnR  (this time w/ tab completion)
Aug 14 10:15:51 <likewise> RoadRunnR: sometimes we find race conditions with that, I guess, if dependencies are not made explicit enough. Is it reproducable?
Aug 14 10:16:22 <RoadRunnR> yes it is, i already revied the task dependencies, and they seem to be ok
Aug 14 10:16:34 <likewise> RoadRunnR:  what task is failing?
Aug 14 10:16:47 <likewise> RoadRunnR: on what package? and why is it failing?
Aug 14 10:16:47 <RoadRunnR> bb is starting a kernel build before libgcc is ready, so the kernel fails
Aug 14 10:18:01 <likewise> RoadRunnR: the kernel should depend on the cross toolchain, and libgcc with that, I assume. Is this within the standard Yocto release? Can someone else reproduce this easily?
Aug 14 10:19:16 <RoadRunnR> well, it's a modified yocto (additional layer), but as i said, the deps look exactly like plain yocto, my guess is that removing packages, and therefore making the kernel build earlier make the problem visible
Aug 14 10:20:47 <RoadRunnR> task-depends has this: "linux-tplino.do_build" -> "libgcc.do_package_write"
Aug 14 10:21:08 <RoadRunnR> but the linux-tplino.do_build is started before libgcc.do_package_write has finished
Aug 14 10:21:46 <RoadRunnR> it seems that the linux-tplino.do_build is started at about the same time as libgcc.do_package_write
Aug 14 10:27:22 <bluelightning> RoadRunnR: do_build is not important for this kind of issue, it's do_compile that matters
Aug 14 10:31:28 <RoadRunnR> bluelightning: that explains it, the dependency chain for that target does not include libgcc, i'll verify with vanila yocto, maybe it is my fault after all, thanks
Aug 14 10:33:24 <likewise> How can I include the devicetree in my rootfs? I have added DEPENDS += "virtual/kernel" in my image recipe, which includes the uImage, but not the FDT file. I tried "virtual/kernel-devicetree", but that doesn't exist.
Aug 14 10:37:11 <RoadRunnR> mhh, vanilla yocto seems to have the decencies, 'bitbake -g linux-yocto' show that linux-yocto.do_compile actually does not depend on libgcc, only linux-yocto.do_build does, or i'm not reading the .dot files correctly....
Aug 14 10:37:50 <RoadRunnR> meant to say: ... seems to have the *same* dependencies...
Aug 14 10:38:00 <bluelightning> libgcc is an output package though
Aug 14 10:38:32 <bluelightning> I suspect the real dependency you'd need would be gcc-cross:do_populate_sysroot
Aug 14 10:39:27 <RoadRunnR> yes, but libgcc needs to be present for the kernel compile to work, it will fails with an compile error otherwise
Aug 14 10:40:31 <bluelightning> I appreciate that
Aug 14 10:41:18 <bluelightning> however in terms of getting it into the sysroot, it'll be a do_populate_sysroot function that takes care of that, and it's likely from gcc-cross
Aug 14 10:42:32 <bluelightning> the libgcc dependency from do_build is intended to ensure that a libgcc package is created for deployment into the target image, it's not for the actual cross-compilation
Aug 14 10:42:57 <RoadRunnR> mhh, my log show that gcc-cross_4.7.bb, do_populate_sysroot had been execute before the kernel build, libgcc_4.7.bb, do_compile is actually started after that
Aug 14 10:43:12 <ant_work> (fwiw I've built last days many kernels and gcc last days with 4 BB threads and make -j5)
Aug 14 10:44:08 <ant_work> even built straight kernels, no images
Aug 14 10:44:35 <RoadRunnR> I'll try to recreate the problem on yocto, might have something todo with the speed of my box or pure luck :-(
Aug 14 10:45:24 <ant_work> long ago there was a ti module racing out :/
Aug 14 11:12:08 <fraviofii> hello all, does anybody here achieved build x-load for beaglebone using yocto and meta-ti?
Aug 14 12:29:55 <likewise> Crofton: gm
Aug 14 13:16:38 <xxiao> i need export a SDK to compile user applications for a powerpc target, adt-install seems like the default method
Aug 14 13:17:24 <xxiao> however it's not working, using the cross toolchain directly under tmp/, the toolchain can not find header files(sysroot)
Aug 14 13:18:03 <xxiao> is there a way for the cross-gcc etc to find sysroot, that really should be automatic? i don't want to modify ./configure --sysroot for each of my apps
Aug 14 13:18:37 <xxiao> by "not working" i mean the BSP team has not get adt-instsall working for this target yet
Aug 14 13:22:52 <bluelightning> xxiao: not sure I'm afraid, but since you're around - did you find the answer to the issue you were having earlier?
Aug 14 13:23:08 <bluelightning> (the tar issue)
Aug 14 13:23:46 <xxiao> bluelightning: not really, i'm still fighting i believe a broken yocto-based release, including that tar issue
Aug 14 13:24:28 <xxiao> that tar issue i was told that could be a yocto issue, but most of the rest are really about the new BSP
Aug 14 13:24:49 <bluelightning> I can only say we haven't seen that behaviour before, either on our autobuilders or locally
Aug 14 13:25:03 <bluelightning> but that doesn't mean we shouldn't try to investigate and fix it
Aug 14 13:25:19 <bluelightning> would you mind filing a bug for it?
Aug 14 13:25:27 <xxiao> bluelightning: thanks. i will try to report something once i get deeper into this release
Aug 14 13:25:48 <bluelightning> appreciated, thanks
Aug 14 13:25:56 <xxiao> the problem is that, i have multiple targets, some has both 32bit and 64bit, and it takes long time to reproduce,etc
Aug 14 13:26:14 <xxiao> but i will file a bug later, if it turns out to be indeed a yocto potential issue
Aug 14 13:41:51 <pirut> hi, I am trying to add a layer and initially I have a meta_myimage/conf/layer.conf and meta_myimage/recipes-kernel/linux-yocto_3.0.bbappend
Aug 14 13:42:03 <pirut> the change does not appear to have been patched
Aug 14 13:42:42 <pirut> where can I find the .conf file of the built kernel to see what config is being used, and how can I debug issues with layer
Aug 14 13:47:19 <pirut> basically I would like to see what teh final SRC_URI is for the kernel, to see if the kernel config additions have been added there
Aug 14 13:53:20 <bluelightning> pirut: bitbake -e linux-yocto | grep SRC_URI
Aug 14 13:53:38 <bluelightning> bitbake -e can almost always be used to query variable values
Aug 14 13:54:27 <bluelightning> the bitbake-layers utility has various functions to query the layer configuration
Aug 14 13:56:54 <pirut> bluelightning: thanks ! my file is listed there, where could I see the kernel .conf file ?
Aug 14 13:58:40 <bluelightning> pirut: TMPDIR/work/*/linux-yocto-*/linux-*-build/.config
Aug 14 13:59:11 <bluelightning> (only after building)
Aug 14 14:12:22 <blitz00> Error: Unable to support this combination of options
Aug 14 14:13:01 <blitz00> i'm trying to do runqemu qemumips on a routerstationpro rootfs and i got that
Aug 14 14:14:07 <blitz00> probably i'm doing something wrong, but I have no idea where to start looking
Aug 14 14:18:15 <blitz00> looking in runqemu-internal it seems it doesn't set QEMUOPTIONS properly because it's expecting an ext3 or btrfs filesystem  but the i have a jffs rootfs
Aug 14 14:18:59 <blitz00> that's what the autobuilder outputs...
Aug 14 15:00:49 <Song_Liu> YPTM: Hi guys, let's start the Yocto Project technical team meeting now. Please let us know who's on the bridge. Thanks!
Aug 14 15:00:53 <rburton> YPTM is here
Aug 14 15:00:55 <pidge> YPTM: Here
Aug 14 15:01:01 * sgw YPTM: Saul
Aug 14 15:01:09 <strassek> YPTM: Kevin Strasser is here
Aug 14 15:01:12 <halstead> YPTM: Michael Halstead is here.
Aug 14 15:01:15 <jmpdelos> YPTM: Jeff Polk is on
Aug 14 15:01:35 <nitink> YPTM: Nitin Kamble is calling the phone bridge
Aug 14 15:01:46 * davest  is in the tech team meeting bridge
Aug 14 15:01:50 <LaurentiuSerban> Laurentiu
Aug 14 15:02:01 * RP__ is here
Aug 14 15:02:06 * scottrif has joined the tech meeting
Aug 14 15:02:12 <kergoth> YPTM: Christopher Larson here, lurking as usual
Aug 14 15:02:17 * kergoth goes to get caffeine
Aug 14 15:02:38 <bluelightning> YPTM: Paul is indeed on the bridge
Aug 14 15:02:39 <sgw> YPTM: Bogan and Laurentiu P are here
Aug 14 15:02:57 <RP> davest: you're still here
Aug 14 15:03:04 <zeddii> YPTM: Bruce is on the call.
Aug 14 15:03:19 <darknighte> YPTM: Sean Hudson of Mentor Graphics on the call.
Aug 14 15:03:24 <scottrif> scottrif is here
Aug 14 15:03:41 <darknighte> No opens from me.
Aug 14 15:03:46 <Song_Liu> YPTM: let's collect some opens now
Aug 14 15:03:57 <pidge> pidge: ab status and 1.3_M3 status
Aug 14 15:04:21 <darknighte> Song_Liu: Looks like you got your nick figured out.
Aug 14 15:04:31 <RP> YPTM: Bitbake console UI changes
Aug 14 15:07:12 * fray finally made it onto the network...
Aug 14 15:07:33 * RP wonders who joined recently with the loud clicking
Aug 14 15:11:53 <darknighte> RP: I always get pretty horrible clicking on the call.  I guess I've just gotten used to it.
Aug 14 15:12:31 <RP> darknighte: Its only these calls I hear it on, has to be one of the attendees...
Aug 14 15:12:57 <darknighte> RP: yep.  I think someone's VOIP isn't very good.
Aug 14 15:13:00 * scottrif hears clicking as well only on this call
Aug 14 15:13:20 <darknighte> RP: of maybe it's someone's phone/headset.
Aug 14 15:14:45 * zeddii volunteers to drop off. let me know if it stops.
Aug 14 15:14:56 * zeddii drops
Aug 14 15:15:02 <darknighte> zeddii: heh, nice way to get off the call.
Aug 14 15:15:09 <zeddii> any change ?
Aug 14 15:15:11 <davest1> clicks still there
Aug 14 15:15:14 * zeddii dials
Aug 14 15:15:15 <RP> zeddii: still there
Aug 14 15:15:23 <darknighte> zeddii: not you.
Aug 14 15:15:50 <darknighte> Song_Liu: Who all is on the CCB?
Aug 14 15:16:25 * zeddii is back.
Aug 14 15:16:41 <zeddii> my headset acted up yesterday, so I wasn't sure that it wasn't me
Aug 14 15:18:36 <RP> darknighte: I think I technically chair the CCB FWIW
Aug 14 15:18:48 <darknighte> RP: I assumed as much.
Aug 14 15:22:08 * zeddii hears that as "naughty" ... 
Aug 14 15:22:50 <darknighte> zeddii: no.  knotty, not naughty.
Aug 14 15:23:02 <zeddii> social engineering.
Aug 14 15:24:49 <sgw> as opposed to nightie
Aug 14 15:25:11 <darknighte> hmmm, knotty, naughty, nightie.  my mind must be in the gutter today.
Aug 14 15:28:05 <RP> halstead: we'll gain decent user repository control with gitolite with the upgrade?
Aug 14 15:29:02 <onoffon> doesn't yo to use gitolite already
Aug 14 15:29:11 <rburton> being able to stop me accidently pushing top-level branches to poky-contrib would be useful :)
Aug 14 15:29:14 <RP> onoffon: yes, this is just an upgrade
Aug 14 15:29:39 <RP> rburton: we could probably put in some rules for that now
Aug 14 15:30:17 <onoffon> it should allow user branches only
Aug 14 15:30:33 <RP> onoffon: I wanted user repos
Aug 14 15:30:46 <RP> onoffon: the current support is partial
Aug 14 15:30:57 <onoffon> yes true
Aug 14 15:31:16 <halstead> RP, I'm taking to the newest version so we will have all the most current controls. It's also plugable now if we need something special.
Aug 14 15:31:35 <onoffon> user repos would let you have regular pulls
Aug 14 15:31:43 <RP> halstead: great, I'm sure there are some things we can take advanatge of there from last time I looked
Aug 14 15:34:08 <darknighte> Song_Liu: Sorry, I'll try to identify myself more.  also, I've been under the weather for the last couple of days, so my voice is a bit off.
Aug 14 15:35:08 <Song_Liu> YPTM: thank you all for joining the meeting. You have a nice day/evening!
Aug 14 15:35:55 <darknighte> Song_Liu: Thx for a quick meeting.  No what will I do with all these additional minutes.
Aug 14 15:37:13 <Song_Liu> halstead: do you have a minute?
Aug 14 15:37:28 <halstead> Song_Liu, Yes.
Aug 14 15:38:34 <Song_Liu> darknighte: np. I  hope we can always get done in 30 minutes for the meeting :) but please don't hesitate to bring up any issue or topic.
Aug 14 15:39:10 <Song_Liu> halstead: I'm just wondering about the FRI 2 build. Darren told me that you are working on it. Have you got it built?
Aug 14 15:40:23 <halstead> Song_Liu, I haven't been working on the FRI2 build but it does look like the build recently finished successfully.  http://autobuilder.yoctoproject.org:8010/builders/fri2/builds/188
Aug 14 15:42:03 <Song_Liu> halstead: this seems to be on 1.3 M3. The one I'm thinking is on 1.2 denzil. Did Darren tell you anything about this?
Aug 14 15:43:52 <halstead> Song_Liu, Nothing I remember and I don't have access the the machines that build fri2.
Aug 14 15:46:09 <Song_Liu> halstead: ok, thanks. I just forwarded you and Beth an email regarding this. Let's follow up via emails.
Aug 14 15:46:22 <halstead> ok
Aug 14 16:47:15 <ccssnet> anyone here going to 2012 DesignCon EAST?
Aug 14 16:48:08 <ccssnet> i registered a few weeks ago
Aug 14 17:39:20 <kergoth> it'd be really nice to reduce the amount of base_contains craziness in our tuning configuration
Aug 14 17:44:40 <kergoth> hmm, think it'd be worthwhile to add a sanity check which compares BBFILE_PRIORITY to BBLAYERS/BBPATH order, and warns when there's a mismatch?
Aug 14 17:46:46 <fray> I've certainly considered it..  I keep coming back to something said way back when.. it's intentionally that they're different.. but I wonder if maybe they should be automatically set based on layer order or something
Aug 14 17:47:30 <kergoth> I've always thought this was wrong, primarily due to the split of responsibility. layer chooses recipe priority, but *user* chooses config/class prority, this seems rwrong. if a class is in a layer, it's because it needs that exact class
Aug 14 17:50:28 * kergoth shrugs and goes back to hacking on other things
Aug 14 18:45:01 <pidge> halstead: I'm pulling ab10 out of the pool to figure out the sanity test issue with it.
Aug 14 18:47:06 <halstead> pidge, Okay. I can help look at those if you point me at them.
Aug 14 18:53:32 <pidge> halstead: I'm sure it's the same issue we had with 02.
Aug 14 18:53:58 <halstead> pidge, That was tap creation/permission.
Aug 14 18:54:36 <halstead> pidge, I did the same fix on ab10. I'll double check.
Aug 14 18:55:28 <pidge> halstead: thank you. ok, then if you did it on 10, it's something else going funky
Aug 14 18:55:50 <pidge> see: http://autobuilder.yoctoproject.org:8010/builders/nightly-mips/builds/553/steps/shell_36/logs/stdio
Aug 14 18:56:15 <halstead> pidge, Is there any reason is has always been mips?
Aug 14 18:57:03 <pidge> no: http://autobuilder.yoctoproject.org:8010/builders/nightly-x86/builds/640/steps/shell_36/logs/stdio
Aug 14 18:57:07 <pidge> x86 there
Aug 14 18:57:10 <pidge> however...
Aug 14 18:57:14 <pidge> looking at something
Aug 14 18:57:40 <pidge> yeah, no, doesn't seem sanity has passed on 10 in a bit
Aug 14 18:57:55 <pidge> I have it out of the pool, so feel free to muck around in there
Aug 14 18:58:31 * halstead nods.
Aug 14 18:59:07 <msm> eglibc 2.16 won't build on older distro's right?
Aug 14 18:59:31 <msm> even 2.15 as well
Aug 14 18:59:34 <msm> for centos 5.x
Aug 14 19:10:10 <walters> so i'm a little lost in the forest of git repositories again
Aug 14 19:10:14 <walters> where is this patch applying? http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-July/022133.html
Aug 14 19:10:57 <msm> khem: are eglibc build reqs documented anywhere (per release) ?
Aug 14 19:12:15 <chackal_sjc> guys
Aug 14 19:12:33 <chackal_sjc> bitbake is running a git command and stops there..
Aug 14 19:12:59 <chackal_sjc> git ls-remote ssh://user@XXX/repo.git master
Aug 14 19:13:01 <chackal_sjc> its this command
Aug 14 19:13:06 <chackal_sjc> and it waits for ever
Aug 14 19:13:25 <chackal_sjc> I tried to see if the ssh is asking for a passphrase
Aug 14 19:13:27 <chackal_sjc> but its not
Aug 14 19:13:45 <chackal_sjc> any thoughts?
Aug 14 19:14:26 <seebs> Wait, is it literally trying to conect as user@XXX?
Aug 14 19:14:42 <chackal_sjc> seebs: no, i changed
Aug 14 19:14:45 <seebs> Because I am like 80% sure that's not a valid host name.
Aug 14 19:14:59 <walters> also, has anyone seen this one before?  http://pastebin.mozilla.org/1755972
Aug 14 19:15:13 <seebs> It seems a bit odd to use ssh with a user name in bitbake.
Aug 14 19:15:26 <chackal_sjc> seebs: what you mean?
Aug 14 19:16:04 <seebs> walters: I haven't. Usually when libtool fails to configure, in my experience, it is because the weight of our transgressions has caused Autotools to turn its face from us. Or a parallel build problem.
Aug 14 19:16:12 <walters> hah
Aug 14 19:16:13 <chackal_sjc> seebs: i updated the authorized_keys in .ssh under this user.. so its not asking password.. and was working until now
Aug 14 19:16:24 <seebs> Well, see.
Aug 14 19:16:36 <seebs> In the normal tree, any git repos we are trying to access will usually be public ones.
Aug 14 19:16:47 <chackal_sjc> seebs: this is private trees
Aug 14 19:16:49 <walters> just doing: /home/ostree/build/gnomeos-build/tmp/sysroots/x86_64-linux/usr/share/aclocal/this-is-an-empty-file  fixes it
Aug 14 19:16:51 <seebs> (Actualyl, when libtool fails to configure *near me*, 90% of the time it is because I broke the toolchain again.)
Aug 14 19:16:55 <walters> er, add touch ^
Aug 14 19:17:07 <seebs> Huh, not sure.
Aug 14 19:17:21 <seebs> Well, then, I dunno. I guess I'd try running the command from the command line.
Aug 14 19:17:28 <walters> i should try to reproduce with oe-core
Aug 14 19:17:49 <chackal_sjc> seebs: i tried, and it works =/
Aug 14 19:18:26 <seebs> Huh. Well, then I'm not sure. Unless there's something in the bitbake environment causing it to pick a different .authorized_keys or something? No clue.
Aug 14 19:21:00 <chackal_sjc> seebs: no, because this authorized_keys is in the server
Aug 14 19:22:30 <seebs> Yeah, I meant... er. Memory has failed me. The ssh config stuff that tells the client which keys to send.
Aug 14 19:25:24 <chackal_sjc> seebs: maybe I know whats that
Aug 14 19:26:29 <chackal_sjc> anyway to kill all bitbake process in a easy way, eg. not using: ps aux | grep bitbake | cut -d " " -f 4 | xargs kill
Aug 14 19:26:48 <seebs> Some linuxes have a "killall" program for just that sort of circumstance.
Aug 14 19:27:33 <chackal_sjc> seebs: doesnt work, because killall searches for the process name, and bitbake is run by python, so I cant killall python
Aug 14 19:27:48 <seebs> I dunno, sounds like a win to me.
Aug 14 19:27:49 <seebs> :P
Aug 14 19:27:53 <chackal_sjc> and pgrep bitbake | xargs kill, or pkill bitbake doesnt work also
Aug 14 19:31:37 <chackal_sjc> it worked!!!!!!!!
Aug 14 19:31:57 <chackal_sjc> seebs: the ssh session was old.. i had to open a new bash session and it worked
Aug 14 19:32:06 <seebs> Environment variables, probably.
Aug 14 19:32:40 <seebs> I have gotten in the habit of logging out of individual screen sessions completely and starting new ones before running builds, after a handful of really CRAZY problems caused by running bitbake with stale environment variables.
Aug 14 19:33:20 <chackal_sjc> seebs: yes, it was
Aug 14 19:33:51 <chackal_sjc> seebs: good point.. thanks... im using tmux, btw
Aug 14 19:34:15 <seebs> I keep planning to learn more about that and try it. I think the reason I didn't switch back in the day was that I actually *used* screen's serial port options.
Aug 14 19:40:34 <kergoth> chackal_sjc: pkill -f bitbake
Aug 14 19:42:00 <kergoth> chackal_sjc: if your'e using tmux, see https://bitbucket.org/kergoth/dotfiles/src/d73c1e36dda8/zsh/functions/tmux_update_env
Aug 14 19:42:27 <kergoth> tmux showenv accesses env vars of the client, so that shell function applies those to the current shell
Aug 14 19:42:32 <kergoth> so you don't need to restart your session
Aug 14 19:43:58 <kergoth> chackal_sjc: pkill uses process name, pkill -f searches the whole commandline, iirc
Aug 14 19:45:13 <grifter188> 'killall <process name>' too
Aug 14 20:00:48 <kergoth> no, that's useless in this context because the process name is 'python' not bitbake
Aug 14 20:00:58 <kergoth> you need something that'll search the whole process command line / arguments
Aug 14 20:01:09 <kergoth> either ps|grep or similar, or pgrep -f or pkill -f
Aug 14 20:33:24 <chackal_sjc> kergoth: thanks
Aug 14 20:36:46 <chackal_sjc> kergoth: does this function works with bash?
Aug 14 20:37:20 <kergoth> should, yeah, don't think it uses any zsh specific functionality. iirc bash has ~= too
Aug 14 20:38:16 <chackal_sjc> kergoth: yes, it worked
Aug 14 20:38:21 <chackal_sjc> thx
Aug 14 20:38:35 <kergoth> np
Aug 14 20:55:39 <msm> anyone seen: https://gist.github.com/3352962
Aug 14 21:43:28 <seebs> msm: Yes.
Aug 14 21:43:33 <seebs> Well, not that exact one, but things like that.
Aug 14 21:43:33 <kergoth> meh
Aug 14 21:44:02 <seebs> In most cases, the error message probably means what it says. We had a really weird special case with a custom toolchain, mips, and a symbol visibility rule that created strangeness.
Aug 14 21:44:31 <seebs> But usually, it means that you're linking against liba.so, and liba.so is linked against libb.so, and you aren't naming libb.so. gcc used to helpfully try to follow those chains, but no longer does.
Aug 14 22:07:49 <msm> the thing is it looks like -ldl is getting passed to the linker
Aug 14 22:08:31 <msm> what does the whole cannot read symbols bit mean though?
Aug 14 22:49:13 <seebs> The "cannot read symbols" thing, if I understand it correctly, is a blatant lie. Basically, in the case where the set of libraries Looks Wrong, the linker pretends it was unable to read the symbols.
Aug 14 22:49:37 <seebs> Because there's not a real mechanism for passing back a substantially more informative error, and it did just explain what was wrong in its own words.
Aug 14 22:52:07 <_Lucretia_> hi, i need to get a specific patch from the tree into mine, I've had to create my own denzil branch of poky and remove the tabs->spaces patches to get it to build, but it fails on deblistparser there are duplicates, i'm just not sure what I need to fix it in my tree?
Aug 14 22:59:09 <kergoth> insufficient information
Aug 14 23:06:05 <_Lucretia_> kergoth: https://lists.yoctoproject.org/pipermail/poky/2012-August/008203.html <-
Aug 14 23:06:29 <_Lucretia_> I would rather grab the selected change from the tree and include it in my branch if i can
Aug 15 00:42:52 <seebs> This may be a silly question, but it appears that the user-mode NFS rootfs export uses <rootfs>/var/pseudo as the LOCALSTATEDIR.
Aug 15 00:43:02 <seebs> Shouldn't that directory NOT be on the target filesystem?
**** ENDING LOGGING AT Wed Aug 15 02:59:59 2012

**** BEGIN LOGGING AT Wed Aug 15 02:59:59 2012
Aug 15 08:04:49 <bluelightning> morning all
Aug 15 10:57:49 <likewise> gm
Aug 15 12:25:01 <pirut> bluelightning: thanks for teh help yesterday, I followed teh directions on where to find the .config for the kernel I was building and noticed that the config from my layer was not enabled
Aug 15 12:25:21 <pirut> then I tried "bitbake -c clean virtual/kernel"
Aug 15 12:25:38 <pirut> "bitbake -c clean virtual/kernel"
Aug 15 12:26:09 <pirut> but there did not seem to be anything in the build directory output
Aug 15 12:26:31 <pirut> so I did a "git clean -dxf" and then rebuilt from scratch
Aug 15 12:26:45 <pirut> and it was there and my feature is enabled
Aug 15 12:27:13 <pirut> but what is the minimum that I should have to do when adding a layer or a config change
Aug 15 12:27:33 <pirut> the git clean route is pretty slow :)
Aug 15 12:28:17 <pirut> sorry that second bitbake command was "bitbake virtual/kernel"
Aug 15 12:37:01 <jawilson> I have a package (PyQT) that depends on another package (sip-native) for the do_generate task. I have sip-native in the depends, but apparently this is only for the configure phase. How can I make a package depend on another for the generate phase?
Aug 15 12:40:11 <JaMa> jawilson: use meta-oe recipes for pyqt
Aug 15 12:41:14 <jawilson> JaMa, I don't see pyqt in meta-oe...
Aug 15 12:41:57 <JaMa> jawilson: and the problem you had is resolved in sip.bbclass http://git.openembedded.org/openembedded-core/commit/?id=5f1af539b3d34e6689a69d09c69d9099eee983d4
Aug 15 12:42:29 <JaMa> jawilson: meta-openembedded/meta-oe/recipes-devtools/python/python-pyqt_4.8.4.bb
Aug 15 12:42:54 <jawilson> JaMa, must not be in the denzil branch yet, or just recently added
Aug 15 12:43:07 <jawilson> thanks!
Aug 15 12:43:09 <JaMa> yes I've added it 1-2 weeks ago
Aug 15 12:43:33 <jawilson> recently enough for me, awesome!
Aug 15 13:10:00 <bluelightning> pirut: that's definitely not necessary, something else must be at work here
Aug 15 13:10:40 <bluelightning> pirut: are you using a release or current git master?
Aug 15 13:11:19 <pirut> bluelightning: I am using the denzil branch
Aug 15 13:12:08 <bluelightning> pirut: ok, so what you need to do is either bump PR each time you make a change, or bitbake -c cleansstate virtual/kernel (instead of -c clean)
Aug 15 13:12:36 <bluelightning> in latest master and the next release all you'll need to do is just build the kernel again and it will pick up the change to your config automatically, FYI
Aug 15 13:17:59 <pirut> bluelightning: that is great, thanks. I was just ahead of the game :)
Aug 15 13:26:46 <bluelightning> pirut: no problem
Aug 15 14:06:30 <kergoth> morning
Aug 15 14:06:51 <moolinex> morning
Aug 15 15:36:01 <zeddii> RP__ (or others). is anyone else doing mixed 32 bit rootfs and 64 bit kernels. I'm looking to fix the QA errors for word/bitsize in that scenario. I've modified insane.bbclass to allow the kernel to skip the warning, but is something automatic per module better ? the QA warning CAN catch real errors ...
Aug 15 15:36:44 <RP__> zeddii: you would need to catch external modules too
Aug 15 15:36:55 <zeddii> hrm. indeed.
Aug 15 15:37:06 * zeddii makes his test case better.
Aug 15 15:37:24 <zeddii> catching the packages-split modules was easier.
Aug 15 16:31:12 <msm> i recall some terminal control stuff being added recently to bitbake, did that make it in? does it need to be turned on?
Aug 15 16:32:01 <kergoth> msm: if you mean the interactive press this key to enable log tailing and all, that series hasn't been merged
Aug 15 16:33:20 <msm> kergoth: yes, i meant that ;) thanks
Aug 15 16:37:36 <kergoth> np
Aug 15 16:51:45 <kergoth>     >        for dep in flags['deps']:
Aug 15 16:51:46 <kergoth>                  dep = data.expand(dep, d)
Aug 15 16:51:46 <kergoth> KeyError: 'deps'
Aug 15 16:51:50 <kergoth> wtf, thsi recipe made bitbake explode
Aug 15 17:06:32 <seebs> I have had things like that happen occasionally.
Aug 15 17:07:08 <seebs> I think I blew things up in a way rather like that by picking a multilib which was named "lib" rather than "lib32" or "lib64".
Aug 15 17:10:27 <jwessel> RP__: I just got the rest of the patches you referenced.
Aug 15 17:10:35 <jwessel> Must be some problem with the WR mail relay.
Aug 15 17:11:06 <jwessel> I'll have to look at the differences between what you have and what I have because I never posted another series, but I added an additional 6 patches.
Aug 15 17:11:30 <jwessel> One was labeled:     knotty.py: Handle rare interrupted select call
Aug 15 17:11:50 <jwessel> Where the cooker aborts with a stack trace.
Aug 15 17:12:28 <jwessel> I had assumed you dropped the stuff or put it to the back burner and I figured I might re-sync it again at another point.
Aug 15 17:12:50 <jwessel> The screen-line stuff is also implemented a completely different way than the original I posted.
Aug 15 17:16:39 <pirut> where can I find the documentation for what the following expand to: ${base_libdir} and ${libdir} etc
Aug 15 17:31:45 <bizhanMona> HI where could I find out the list of the packages supported by Yocto ?
Aug 15 17:32:51 <pidge> bizhanMona: http://packages.yoctoproject.org/
Aug 15 17:33:10 <bizhanMona> pidge: thanks
Aug 15 17:33:44 <pidge> bizhanMona: Not sure that's up to date, but that'll give you an idea. That's just what comes with Yocto. meta-oe has a lot more.
Aug 15 17:39:15 <hollisb> pidge: neat. shouldn't that be automatically updated though?
Aug 15 17:41:15 <pidge> hollisb: There were issues with the code base IIRC.
Aug 15 17:41:41 <hollisb> huh :)
Aug 15 17:43:14 <pidge> hollisb: sgw would know more about where it currently stands. And yes, it should be automatically updated. :)
Aug 15 17:45:09 <bizhanMona> One more question, the support for the Ivy Bridge is it part of the Yocto branch romley?
Aug 15 17:47:31 <bluelightning> pirut: those are all set in meta/conf/bitbake.conf unless the distro config overrides them
Aug 15 17:47:48 <bluelightning> pirut: "git grep" can be useful for some of these things if you weren't already aware of it
Aug 15 17:54:26 <pidge> bizhanMona: Chiefriver is Ivy Bridge with Panther point, IIRC. Romley is Sandy Bridge.
Aug 15 17:55:28 <bizhanMona> pidge: Would Chiefriver works with Q77 chipset?
Aug 15 17:55:30 * pidge checks the meta-intel readmes. 
Aug 15 17:55:53 <pidge> bizhanMona: nitink, tomz, or dvhart would know that better than I.
Aug 15 17:56:10 <bizhanMona> pidge: thanks very much
Aug 15 19:00:58 <flynn378> How do you write a recipe file that only installs files, like wav files?   I have searched for a while and tried just coping the files for do_install but nothing gets packaged
Aug 15 19:16:03 <rburton> flynn378: probably doing it wrong - compare with https://github.com/Guacamayo/meta-guacamayo/blob/master/meta-guacamayo/recipes-demos/pictures/
Aug 15 19:17:56 <flynn378> rburton: thanks
Aug 15 19:31:45 <AdityaGandhi> Hi all, I have compiled qt4e-demo-image for crownbay platform, works fine! Now I want to develop qt-applications for the same, used the adt-installer guide to generate a toolchain and a sysroot
Aug 15 19:32:42 <AdityaGandhi> but it does not contain qt specific files in sysroot , I tried mounting the image created and point to it as sysroot, but had a doubt if it would work
Aug 15 19:33:43 <AdityaGandhi> some directories were missing like /usr/shar/pkgconfig , which I may be able to compy from the sysroot generated by adt
Aug 15 19:34:31 <AdityaGandhi> So now I have a sysroot, which is only readable to a normal user, will  I be able to compile using the new sysroot
Aug 15 19:35:19 <AdityaGandhi> for qt-apps
Aug 15 20:26:25 <AdityaGandhi> hi guys, one quick question
Aug 15 20:27:20 <AdityaGandhi> I am building a qt4e-demo-image, I want to know what packages are included in that particular build, where is the file for crownbay bsp which specifies this inforcemation?
Aug 15 20:27:25 <AdityaGandhi> information*
Aug 15 20:30:07 <AdityaGandhi> Basically what I mean to ask is where are the image recipes
Aug 15 20:34:28 <seebs> I do not think that is a quick question.
Aug 15 20:34:31 <seebs> :)
Aug 15 20:34:54 <seebs> I am not totally sure. I have my variable-tracking packages, and with them you could probably backtrack to figure out where the various things came from.
Aug 15 20:35:05 <seebs> Pretty sure that the image specification is not generally tied to the BSP, though.
Aug 15 20:35:29 <seebs> So, while it's time for posting questions and curiosities in the channel:
Aug 15 20:35:44 <seebs> I'm using external toolchain stuff, and I'm having interesting problems with multilibs in our setup.
Aug 15 20:36:39 <seebs> In our setup, we are using symlinks to the prebuilt binaries, and the symlinks live in STAGING_BINDIR_TOOLCHAIN.
Aug 15 20:36:55 <seebs> Thing is, if we do a multilib build, STAGING_BINDIR_TOOLCHAIN becomes a different directory.
Aug 15 20:37:42 <seebs> And right now, the symlink setup occurs before all the actual tasks are performed, which leads to an interesting quirk: I cannot find any way, outside of a package build, to determine "what would STAGING_BINDIR_TOOLCHAIN be for this other multilib?"
Aug 15 20:38:49 <seebs> The issue is that it ends up including TARGET_VENDOR, and TARGET_VENDOR is being overridden by TARGET_VENDOR_virtclass_multilib-lib32 (or whatever), but that override isn't created until multilib_virtclass_handler, which executes only on an event which is an instance of bb.event.RecipePreFinalise.
Aug 15 20:40:12 <seebs> My options appear to be (1) duplicate the logic (I've done this and it works, but I hate it for obvious reasons), (2) move the symlink creation into a different phase somehow, or (3) change the logic defining when the multilib overrides values are initially defined.
Aug 15 20:40:21 <seebs> Or (4) whine about it in #yocto and hope someone else has already solved it.
Aug 15 20:40:23 <fraviofii> hello all
Aug 15 20:40:33 <fraviofii> I made some changes on a u-boot
Aug 15 20:40:40 <fraviofii> and I would like to rebuild
Aug 15 20:40:48 <fraviofii> I'm using yocto for beaglebone
Aug 15 20:41:40 <kergoth> seebs: yikes, good luck with all that
Aug 15 20:41:47 <seebs> ...
Aug 15 20:41:55 * kergoth has been happily ignoring multilib until he absolutely has to deal with it :P
Aug 15 20:42:02 <seebs> I believe you misspelled "I just committed a really simple fix that addresses this."
Aug 15 20:42:17 <fraviofii> after creating a patch, I did 'bitbake -c clean u-boot && bitbake -c compile u-boot && bitbake core-image-minimal' and at tmp/deploy/images I realize that the files timestamps hasn't changed
Aug 15 20:42:39 <fraviofii> what am i doing wrong?
Aug 15 20:42:46 <kergoth> seebs: one option would be to put it into a different dir in PATH, that's common to the multilibs, rahter than STAGING_BINDIR_TOOLCHAIN
Aug 15 20:42:49 <seebs> Actually, one thing that occurred to me is an alternative where we pick YET ANOTHER directory to symlink all the toolchain binaries into, and put that directory in $PATH. But that doesn't solve one of my other problems, so I probably can't do it.
Aug 15 20:42:56 <kergoth> :)
Aug 15 20:43:09 <seebs> The secondary problems is that we've got preliminary toolchain wrappers working.
Aug 15 20:43:45 <seebs> And the intended use case is that you can just do /path/to/tuning-wrswrap-linux-gnu-gcc -o foo foo.c and get foo compiled correctly for <tuning>, even if nothing was in $path and you don't know what a sysroot is.
Aug 15 20:44:06 <seebs> And that works only if the wrappers are in a directory which has the underlying toolchain binaries or their symlinks.
Aug 15 20:44:29 <seebs> Although. Hmm.
Aug 15 20:44:54 <seebs> You know, it might make sense to pick a single directory which isn't necessarily STAGING_BINDIR_TOOLCHAIN. And put them all there, because the wrapper names can't conflict.
Aug 15 20:45:18 <seebs> That's probably an order of magnitude less soul-destroying than duplicating the logic for determining the triplet being used for a multilib.
Aug 15 20:56:44 <RP__> seebs: Can't you just ask what the value of TARGET_VENDOR_virtclass-lib32 is ?
Aug 15 20:57:14 <seebs> It's not defined until later.
Aug 15 20:57:33 <RP__> jwessel: I'd be interested in the updated versions, see if there is anything else we can merge
Aug 15 20:57:48 <seebs> TARGET_VENDOR_virtclass_multilib-lib32 is defined by multilib_virtclass_handler, which executes only on an event which is an instance of bb.event.RecipePreFinalise.
Aug 15 20:58:01 <seebs> And the toolchain setup is trying to execute at BuildStarted.
Aug 15 20:59:27 <seebs> So as of when this code executes, all the other TARGET_VENDOR values are not-yet-set.
Aug 15 21:01:04 <kergoth> i really need to go smack around the sourcery team and get them to stop shipping this weird hybrid host/target ia32 toolchain non-prefixed binary stuff and msgxx-glibc and all
Aug 15 21:01:11 <kergoth> i cannot imagine what the use case was for this madness
Aug 15 21:01:24 <kergoth> i don't care if your'e running on the same arch as the target, it's still crosscompiling
Aug 15 21:01:30 * kergoth mutters
Aug 15 21:02:43 <RP__> seebs: ah, right, hmm :/
Aug 15 21:21:03 <kergoth> damnit, what the hell. bitbake isn't emitting one of the shell functions that's used by t his other shell function
Aug 15 21:21:17 <kergoth> worse yet, it's showing a task failure wihtout showing the log, no log file exists, despite the thing running under set -x
Aug 15 21:21:19 <kergoth> what the hell?
Aug 15 21:21:31 <kergoth> hrm
Aug 15 21:22:35 <kergoth> i suspect there may be a shell parsing failure by the dependency tracking code, but it's being suppressed somehow
Aug 15 21:22:37 * kergoth scratches head
Aug 15 21:54:20 <AdityaGandhi> thanks a lot seebs, a little late though
Aug 15 21:54:55 <AdityaGandhi> anyone with a bit of Qt experience
Aug 15 21:55:21 <seebs> So I'm currently leaning towards using a new directory which is not STAGING_BINDIR_TOOLCHAIN, but is also a subdir of the sysroot/usr/bin, and putting the external toolchain links, and wrappers, all in there.
Aug 15 21:56:21 <kergoth> doesn't sound unreasonable to me
Aug 15 21:56:32 <kergoth> though the proliferation of dirs under bin/ is a potential concern
Aug 15 21:56:40 <kergoth> but there aren't that many yet, so maybe its not an issue
Aug 15 21:57:37 <seebs> It is an issue. And I guess I could just put the symlinks in usr/bin directly, but I sorta dislike that, too. People do NOT need 70+ extra files with long names in usr/bin.
Aug 15 21:57:47 <seebs> (And yes, for a multilib build on an SPE target, it can be up towards that many.)
Aug 15 21:57:48 <kergoth> a subdir is better
Aug 15 21:58:36 <kergoth> man, i just realized if i add my meta-sourcery to my bblayers, i'm *forced* to use the external sourcery tcmode, due to the replacement of the tune files. i guess i should just force the TCMODE somehow.. or at least add a sanity check
Aug 15 21:58:58 <kergoth> either that or i should say screw the tune-*.conf replacements and go back to letting the tcmode .inc forcibly fuck with ccargs
Aug 15 21:59:01 <kergoth> but that's not pleasant either
Aug 15 21:59:03 * kergoth mutters
Aug 15 21:59:11 <seebs> Does anything outside the stuff provided by or replaced by the external toolchain use STAGING_BINDIR_TOOLCHAIN? I can't find much except the assignments to it in some classes.
Aug 15 21:59:28 * kergoth likes it when a layer can be added without harming anything until you opt into its functionality, like bsp layers that use MACHINE overrides and distro layers that use the distro override
Aug 15 21:59:30 <seebs> kergoth: For what it's worth, for the external toolchain stuff, we simply replace all the conf/inc files.
Aug 15 21:59:36 * kergoth nods
Aug 15 21:59:40 <seebs> And we forcibly set tcmode in the layer.
Aug 15 21:59:49 <kergoth> ah. in the layer.conf?
Aug 15 21:59:50 <seebs> Because otherwise, Life Is Way Too Hard.
Aug 15 21:59:51 <seebs> Yeah.
Aug 15 21:59:53 * Daemon404 sees a wild seebs appeared
Aug 15 22:00:00 <kergoth> k, guess i'll do that too for the time being
Aug 15 22:00:03 <kergoth> anything else hurts my head
Aug 15 22:00:09 <seebs> PSEUDO USER used BUG REPORT. It's not very effective.
Aug 15 22:00:40 <seebs> I suppose we could have some kind of elaborate "but search this path first only if this variable has a particular value" thing, but it seems easier to just say "this layer changes the toolchain."
Aug 15 22:00:53 <seebs> It also has to have a ton of blacklisting rules and other magic to work over the full set of cases.
Aug 15 22:01:49 <seebs> Hmm. I really don't see anything else using STAGING_BINDIR_TOOLCHAIN. I wonder whether I should just override it not to be multilib-specific. ... No, because the moment I do, SOME recipe will put something there with an unqualified name.
Aug 15 22:01:54 <Daemon404> oh
Aug 15 22:02:05 <kergoth> the internal toolchain doesn't use that path for the crosscompiler it emits?
Aug 15 22:02:06 <Daemon404> this is a good opportunity to ask -- seebs have you poked x32 (laugh) at all?
Aug 15 22:02:07 <kergoth> hmm
Aug 15 22:02:22 <seebs> Deamon404: I have sworn blood vengeance on x32 unto the seventh generation.
Aug 15 22:02:29 <seebs> ... which is to say, it's not on my requirements list.
Aug 15 22:02:30 <seebs> :P
Aug 15 22:02:35 <Daemon404> excellent
Aug 15 22:02:42 <Daemon404> randy was supposed to poek you for me and ask
Aug 15 22:02:45 <Daemon404> i dont think that happened
Aug 15 22:02:51 <seebs> I don't think so, no.
Aug 15 22:03:08 <seebs> My sole exposure, I think, is that I confused the heck out of myself for about a week once by thinking it was just shorthand for x86_32.
Aug 15 22:03:31 <seebs> kergoth: I think the internal toolchain does, yes. But I don't think anything *but* the internal toolchain talks to it -- meaning if my code is in place, theirs isn't, so I don't care. :)
Aug 15 22:03:35 <Daemon404> i managed to almost get the meta-x32 layer to to compile a meta-toolchainm
Aug 15 22:03:39 <Daemon404> almost. eglibc is fucked.
Aug 15 22:04:09 <seebs> I think the staging/stash directory is probably right for now.
Aug 15 22:04:28 <seebs> Sometime later, I want to clean the wrappers up and try to get them into oe-core, because when they *do* work... Man, that is *HANDY*.
Aug 15 22:04:44 <seebs> Forgot to put a test case on the target? wrapper-gcc -o hello hello.c
Aug 15 22:05:11 <AdityaGandhi> Hi Guys, iwant to compile a tool chain for my host which is x86_64, for qt and native
Aug 15 22:05:20 <AdityaGandhi> then link it to qt creator for apps!
Aug 15 22:05:48 <kergoth> that does soun useful
Aug 15 22:06:40 <seebs> It is. It is also astounding how easy it is to break it.
Aug 15 22:07:05 <seebs> In particular, it is devastating to the kernel build if you set everything to use the wrapper. Because the kernel does NOT like it when other people set compiler flags on it.
Aug 15 22:34:17 <bluelightning> fraviofii: bitbake -c cleansstate u-boot; bitbake u-boot
Aug 15 22:35:24 <mru> seebs: rumour has it you're having trouble with libav and ppc...
Aug 15 22:35:54 <fray> I found out today, denzil at least has a reuqirement in external-python-tarball -- for opkg.. :p
Aug 15 22:36:03 <fray> I'm going to see if that is still there in master
Aug 15 22:36:28 <seebs> mru: yeah. It's almost certainly not your fault, mind.
Aug 15 22:36:43 <mru> not my fault, but perhaps I can fix it
Aug 15 22:37:15 <seebs> Long story short, there's a copy of libav embedded in part of gstreamer, and by the time our build system has mutilated poky and poky has set everything up, so far as I can tell, there is nothing available to the gst code that would let it pass a meaningful --cpu.
Aug 15 22:37:46 <seebs> And what bit us was that, on a 603e-derived system, we somehow managed to pass the first couple of AltiVec-related tests, so we got to the one about the {} syntax, and the configure died.
Aug 15 22:37:59 <seebs> The simplest answer from my point of view would be for that test to also do "|| disable altivec"
Aug 15 22:38:01 <mru> yeah, those tests are a bit weird
Aug 15 22:39:16 <seebs> If you want a proposed patch or something, lemme know and I can try to toss one together. What I think I would like as a user is for "whoops, there's not really altivec" to not be a fatal error unless the user specifically asked for it.
Aug 15 22:39:42 <seebs> I suspect that the majority of the desktop market is in environments where ppc almost always means altivec; I'm in a world where I think we MIGHT have one thing we support that has it.
Aug 15 22:40:01 <mranostay> if a test fails just drop it :P
Aug 15 22:40:14 <seebs> I wrote some articles for developerWorks many moons ago on AltiVec.
Aug 15 22:40:18 <mru> mranostay: not that kind of test
Aug 15 22:40:22 * mranostay has seen that in QA before... 
Aug 15 22:40:30 <mru> mranostay: we're talking about feature tests in configure
Aug 15 22:41:09 <seebs> In the third article of the series, I wrote a detailed analysis of how to optimize a chunk of Darwin's code. Specifically the idle loop, which increments a counter. I built something that rotated through sets of registers incrementing vectors of the form {X, X+1, X+2, X+3}, getting good pipelining.
Aug 15 22:41:32 <seebs> Then I pointed out that really, the performance issues that matter are the ones where the machine has slowed down and is giving that spinning rainbow beachball.
Aug 15 22:41:35 * Daemon404 watches mru and seebs get into compiler talk..
Aug 15 22:41:40 <mru> why would you want to optimise the idle loop?
Aug 15 22:41:52 <seebs> ... so I presented an altivec-optimized routine for taking RGB values, converting them to HSV, incrementing the hue value, and converting them back.
Aug 15 22:41:55 <seebs> Well.
Aug 15 22:42:01 <seebs> It may matter that the article's publication date was April 1.
Aug 15 22:42:08 <mru> hehe
Aug 15 22:43:00 <seebs> Thing is, apart from the unusually-contrived test cases, it wasn't a particularly *bad* article. It really did give some useful insights into how to make use of vector ops, how conditionals are replaced by performing operations and then selecting results conditionally, and so on.
Aug 15 22:43:20 <seebs> But at least one news site said it was a stupid article because why would you ever want to do that.
Aug 15 22:43:56 <mru> if you don't have a halt instruction, you probably do want to optimise the idle loop for power though
Aug 15 22:43:58 <seebs> Years later, that's the part I really cherish. Money's nice, managing to get professional writers to criticize your april fools joke without recognizing it as such is awesome.
Aug 15 22:44:35 <seebs> Some years back, I remember a discussion on the NetBSD lists. Someone had added a feature to the idle loop, which was that if there were free pages that had not been zeroed, it would zero them and move them to the zeroed-pages list.
Aug 15 22:45:02 <seebs> Apparently produced a non-zero improvement in system performance in cases where there was any idle time going on.
Aug 15 22:45:14 <mru> yeah, that's a useful thing
Aug 15 22:45:31 <mru> doesn't linux have that too?
Aug 15 22:45:45 <seebs> Probably? I can't keep up with LKML.
Aug 15 22:46:08 <mru> they even have background merging of identical pages
Aug 15 22:46:39 <seebs> Neat.
Aug 15 22:47:44 <mru> apparently it's useful if you're running several identical VMs
Aug 15 23:00:49 <seebs> hmm.
Aug 15 23:01:03 <mru> hang in there, I'm cooking up a patch
Aug 15 23:01:29 <seebs> I was just doing one myself because I needed a thing to think about while waiting for something to fail in an inexplicable new way.
Aug 15 23:03:19 <seebs> My sort of solutiony thing is to make each of the tests be inside a separate "if enabled altivec;", so as soon as one fails the others are ignored.
Aug 15 23:03:34 <seebs> Because, in fact, in our case the first test was failing, so altivec was already disabled before we even got to the "die" test.
Aug 15 23:03:40 <mru> I have a better one
Aug 15 23:03:52 <mru> getting rid of some legacy crap in the process
Aug 15 23:04:01 <seebs> Cool.
Aug 15 23:11:01 <mru> patch sent to libav-devel
Aug 15 23:17:32 <seebs> And today, I think, I am going to try to actually implement _remove
Aug 15 23:18:37 <seebs> Speaking of variables, anyone tried the much-improved variable tracking I submitted recently?
Aug 15 23:18:58 <fray> works well for me.. except sometimes it's way too much info..
Aug 15 23:19:20 <fray> only complaint I have is when I'm just trying to figure out what the value of a variable is, it's "too much"
Aug 15 23:21:12 <fray> what I really want is something that would just dump out one or a set of variables in expanded and unexpanded form.. instead of all of -e..
Aug 15 23:21:25 <fray> (which could be a wrapper script)
Aug 15 23:57:15 <evanp> been thinking about a TCMODE-ish thing that uses the Linux Standard Base compiler kit as an external toolchain--but only for nativesdk packages
Aug 15 23:57:27 <evanp> thoughts anybody? am I insane?
Aug 16 00:00:46 <seebs> Hmm. hmm
Aug 16 00:01:00 <seebs> So you'd be avoiding the need to build a host compiler, but still building a target compiler?
Aug 16 00:01:18 <seebs> And yet not necessarily relying on the host's compiler to be any good.
Aug 16 00:03:06 <evanp> right; also, meta-toolchain wouldn't bundle its own glibc and programs would have /lib64/ld-lsb-x86-64.so as their ELF interpreter
Aug 16 00:26:53 <kergoth> anyone thought about implementing some sort of USER_FEATURES, which allows explicit removal/add of DISTRO_FEATURES?
Aug 16 00:27:03 <kergoth> e.g. USER_FEATURES = "~bluetooth" or something
Aug 16 00:27:13 <AdityaGandhi> Hi guys, I compiled a QT-toolchain, and now I have qmake which it says cannot run
Aug 16 00:27:29 <AdityaGandhi> I get permission denied, all the permissions are okay
Aug 16 00:27:36 <AdityaGandhi> I did chmod 777
Aug 16 00:27:40 <AdityaGandhi> still no go
Aug 16 00:28:15 <kergoth> evanp: that sounds like it'd be lovely, though i've heard horror stories about trying to build things with the lsb sdk :)
Aug 16 00:34:11 <evanp> kergoth: I thought about something like that briefly a few days ago, but ended up just creating my own distro and overriding a few key variables
Aug 16 00:34:49 <evanp> kergoth: been a long time, but doesn't Gentoo allow something like that in their USE flags?
Aug 16 00:35:03 <kergoth> yeah, thats what i'm thinking about
Aug 16 00:35:15 <kergoth> it's easy to create your own distro, but it'd also be quite easy to implement something like this
Aug 16 00:35:21 * kergoth might have to prototype it
Aug 16 00:37:06 <evanp> on the LSB thing, I'm thinking the resulting RPMs for nativesdk packages might be more palatable that way
Aug 16 00:38:09 <evanp> I've got some stuff that kinda sounds like it should be nativesdk, but really wants to be better integrated into the host distribution. In /usr/sbin and stuff, not off in /opt and linked against its own libc.
Aug 16 00:40:05 <evanp> dunno. maybe trying to build those bits with poky is a mistake.
Aug 16 00:52:43 <seebs> kergoth: Well, I haven't done that, but!
Aug 16 00:52:50 <seebs> I have a patch I'm about to send out that allows:
Aug 16 00:53:03 <seebs> DISTRO_FEATURES_remove_armv5 = "anything-useful"
Aug 16 00:53:25 <seebs> Or if you want something unconditional:
Aug 16 00:54:12 <seebs> IMAGE_INSTALL -= "annoying-package"
Aug 16 00:54:40 <kergoth> look forward to reviewing that
Aug 16 00:55:01 <seebs> It's probably pretty bad. It's *hard* to do cleanly.
Aug 16 00:56:02 <evanp> that would be useful...some of my bbappends could be less brittle
Aug 16 00:56:03 <kergoth> yep, non-trivial
Aug 16 00:56:10 <kergoth> potentially risky
Aug 16 00:56:13 <kergoth> but would be nice
Aug 16 00:56:14 <seebs> Basically:
Aug 16 00:56:50 <seebs> _remove becomes a setvar_keyword. During _finalize, we do the normal override-processing to filter out _removes which don't apply. Then we stash them under the _remove_later flag.
Aug 16 00:57:09 <seebs> In getVar, expansion becomes value = self.expand(...) instead of return self.expand().
Aug 16 00:57:40 <seebs> And if there are any things in _remove_later, we then split var, remove any values from the remove list from it, and reassemble it.
Aug 16 00:58:10 <kergoth> man, i'd really like to see _prepend/_append/etc applied at getVar() time, with appropriate caching, at some point
Aug 16 00:58:13 <seebs> It's done at the very last minute because otherwise it doesn't make sense. And I don't want to do it in finalize, because that would mean that finalize would be committing expansions for variables with a _remove pending.
Aug 16 00:58:23 <kergoth> it'd really make their behavior more predictable due to timing issues
Aug 16 00:58:32 <seebs> No real argument here.
Aug 16 00:58:46 <kergoth> the only concern there is likely performance, but with appropriate caching i bet it'd work fine
Aug 16 00:58:51 <kergoth> oh well, thats a someday/maybe item..
Aug 16 00:58:52 <kergoth> heh
Aug 16 00:58:58 <kergoth> seebs: sounds reasonably sane
Aug 16 00:59:29 * kergoth pushes http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/commit/?id=a916077 for now, was trivial to add
Aug 16 01:00:56 <seebs> Right now, _remove is on top of the variable tracking.
Aug 16 01:01:08 <seebs> Because if you think for a minute I could implement it on a tree without variable tracking, you are *crazy*.
Aug 16 01:14:39 <seebs> Sent. Have fun!
Aug 16 01:19:37 <kergoth> will probably review it tomorrow if i can find the time
Aug 16 01:44:55 <kergoth> i really need to sit down and read/comment on the 'RFC: OE-Core image creation and deployment' mail
Aug 16 01:45:10 <kergoth> been sitting in my inbox
**** ENDING LOGGING AT Thu Aug 16 02:59:58 2012

**** BEGIN LOGGING AT Thu Aug 16 02:59:58 2012
**** BEGIN LOGGING AT Thu Aug 16 03:18:28 2012
Aug 16 08:09:25 <bluelightning> morning all
Aug 16 08:09:32 <JaMae> morning
Aug 16 08:10:09 <bluelightning> hi JaMa
Aug 16 09:43:28 <RP__1> morning all
Aug 16 09:46:37 <JaMa> morning RP
Aug 16 14:11:55 <kergoth> RP: you forgot to remote knotty from the list of valid interfaces. bitbake -u knotty2:
Aug 16 14:11:56 <kergoth> FATAL: Invalid user interface 'knotty2' specified.
Aug 16 14:11:56 <kergoth> Valid interfaces: depexp, goggle, ncurses, hob, knotty [default], knotty2.
Aug 16 14:11:58 <kergoth> :)
Aug 16 14:14:55 <RP> kergoth: ah, right
Aug 16 14:15:09 <kergoth> s/remote knotty/remove knotty2/, obviously :)
Aug 16 14:15:29 * kergoth is glad to see those changes in, lots of folks probably didn't know knotty2 existed
Aug 16 14:16:35 <RP> kergoth: me too, there are a couple of glitches people have found but in general I think its a good improvement
Aug 16 14:16:42 <RP> and as you say, people didn't know about it
Aug 16 14:28:32 * mranostay yawns
Aug 16 14:31:02 * mru makes a lovely espresso, passes it in front of mranostay's face, then drinks it himself
Aug 16 14:31:59 <mru> damn, I'm almost out of beans again
Aug 16 14:47:59 <pirut> hi, when creating a project/recipes-project/task/task-core.project.bb file do I only have to include the names of the new .bb files in my layer or should I also include the .bbappend files to the RDEPENDS_task-core-project variable ?
Aug 16 14:50:47 <pirut> e.g. I have a layer that includes some additional kernel configs (.bbappend) and some new user space libs as (.bb)
Aug 16 14:53:08 <bluelightning> pirut: no, the bbappends are a parse-level function, so as far as bitbake is concerned after parsing the bbappends don't really exist; their contents are just considered part of the recipe they are appending to
Aug 16 14:54:51 <pirut> bluelightning: so if I understand correctly once my layer is added to the build/conf/bblayer.conf my .bbappends are "active"
Aug 16 14:55:06 <bluelightning> pirut: correct
Aug 16 14:56:22 <pirut> bluelightning: thanks again :)
Aug 16 15:01:41 <kergoth> ERROR: chrpath command failed with exit code 7
Aug 16 15:01:51 <kergoth> well that was helpful.. no actual error message, just the exit code?
Aug 16 15:01:52 * kergoth sighs
Aug 16 15:09:21 <bluelightning> kergoth: ah, crap... I missed that because it prints an ERROR the task log does not get printed
Aug 16 15:09:44 <kergoth> heh, oops
Aug 16 15:10:12 <bluelightning> really, sub.call is not a great way to run anything you expect to monitor I guess
Aug 16 15:10:17 <bluelightning> well, subprocess.call
Aug 16 15:11:12 <bluelightning> I suspect this has silently been failing quite a lot... :(
Aug 16 15:11:38 <bluelightning> kergoth: in your case what does the task log indicate?
Aug 16 15:12:26 <kergoth> heh, probably best off using bb.process.run() or similar. I'll be glad when we bump our minimum python version to 2.7 and just use subprocess.check_output()
Aug 16 15:13:56 <pirut> what is the difference between a distro and an image ?
Aug 16 15:14:25 <pirut> some meta-* supply both and some only an image dorectory
Aug 16 15:14:42 <bluelightning> pirut: they're not really related...
Aug 16 15:15:42 <bluelightning> pirut: a distro is a set of configuration/policies for how to build the system; often this influences things at the compilation level
Aug 16 15:16:04 <kergoth> machine, distro, and image are largely orthogonal. you can mostly pick any combination of the 3 and get something that should work. this was why it was designed this way..
Aug 16 15:16:05 <kergoth> heh
Aug 16 15:17:31 <bluelightning> pirut: the most basic definition of an image is something containing files that goes onto a device (or media to be connected to a device)
Aug 16 15:18:09 <bluelightning> pirut: usually when we say image we refer to either a root filesystem or the recipe that we use to produce it
Aug 16 15:18:53 <bluelightning> the image recipe indicates what packages should be assembled to produce the image as well as any post-processing that should be performed upon it
Aug 16 15:19:08 <pirut> bluelightning: this is where my confusion arises, I have seen image configs that add .bb recipies but then there is kernel configs taht are also required for those to actually work but they are guarded by "${@base_contains('DISTRO_FEATURES'" style
Aug 16 15:19:29 <pirut> includes
Aug 16 15:19:49 <pirut> so the userspace will be inthe image, by using bitbame core-image-project
Aug 16 15:20:11 <pirut> but they wont work until DISTRO ?= project is set and a rebuild is done
Aug 16 15:20:50 <bluelightning> well, there are good ways and poor ways to design things when it comes to the metadata
Aug 16 15:20:58 <pirut> :D
Aug 16 15:21:34 <bluelightning> ideally you don't end up with recipes that only function when a specific configuration option is enabled without the recipe being "skipped" completely (we have a couple of mechanisms to do this)
Aug 16 15:21:42 <pirut> would it be wrong to add "DISTRO_FEATURES_append" to a recipes-project/images/core-image-project in that case
Aug 16 15:21:51 <bluelightning> that would not work
Aug 16 15:22:15 <bluelightning> the change to DISTRO_FEATURES set in that way would only apply to the image itself not any other recipes
Aug 16 15:23:00 <bluelightning> DISTRO_FEATURES and any other global setting that is considered part of the distro configuration can only be influenced from the distro configuration or in a more temporary fashion from local.conf
Aug 16 15:23:14 <bluelightning> (practically)
Aug 16 15:24:04 <bluelightning> pirut: is there a specific reason for your question?
Aug 16 15:24:48 <pirut> in a nut shell I have created a layer to turn on a kernel feature and add a userspace lib and some programs taht depend on that feature
Aug 16 15:25:28 <pirut> the feature is image neutral
Aug 16 15:26:22 <pirut> so it could be tacked onto many image configs with the task.bb I created, and I am looking for the cleanest way to make this possible
Aug 16 15:28:12 <bluelightning> right, it's a tricky thing, but turning on kernel config options can really only be done at the distro or kernel recipe level
Aug 16 15:28:45 <bluelightning> if you can be sure of the kernel recipe that is being used you can bbappend it in your layer and enable the options though
Aug 16 15:30:33 <pirut> I am on denzil branch
Aug 16 15:30:43 <pirut> and have linux-yocto_3.0.bbappend and linux-yocto_3.2.bbappend
Aug 16 15:31:47 <pirut> both are identical at the moment they add a file://project.cfg to SRC_URI
Aug 16 15:32:02 <pirut> and the .cfg ahs the options I want
Aug 16 15:33:46 <pirut> so is it "safe" to jsut have a bare include i.e. SRC_RRI += "file://project.cfg"
Aug 16 15:34:16 <pirut> or should I create a distro for this functionality ?
Aug 16 15:36:32 <bluelightning> pirut: that is safe yes, assuming linux-yocto 3.0/3.2 are being used
Aug 16 15:48:08 <pirut> bluelightning: is tehre a more generic way to add kernel support ?  I noticed that if i add a linux-yocto 3.4.bbappend it bails stating that thre is no 3.4 recipe to append to
Aug 16 15:49:11 <bluelightning> right, bbappends are version specific
Aug 16 15:50:11 <bluelightning> I don't think there really is a generic mechanism to add the option for any enabled kernel
Aug 16 15:57:17 <sgw> seebs: can you have a look at the email I just forwarded, looks like your change to base.bbclass caused a problem that I did not catch in my testing.
Aug 16 15:58:53 <bluelightning> kergoth: so presumably you found that the chrpath error was a length issue?
Aug 16 15:59:15 <walters> so it looks like running through my oe-core build costs about $3 on EC2 on an m1.medium instance
Aug 16 15:59:21 <walters> that's a lot lower than i thought it'd be
Aug 16 15:59:31 <ag_> sgw: Hello. I was just about to upload connman an dbus stuff... i could see that Mr. Musca already pushed that before.
Aug 16 15:59:41 <kergoth> oddly, i had wiped and restarted the build before i even saw the message, and the second attempt worked fine. i'm guessing it used sstate the second time around and didn't chrpath
Aug 16 15:59:41 <kergoth> hrm
Aug 16 15:59:47 <seebs> whee
Aug 16 15:59:55 <sgw> ag_: catching up, was traveling yesterday
Aug 16 16:00:03 <ag_> sgw: Ok.
Aug 16 16:00:17 * kergoth yawns
Aug 16 16:00:36 <kergoth> this bitbake color patch is rather cute, i remember prototyping that once, but never polished it off
Aug 16 16:00:43 <kergoth> having color codes in bb.msg makes me sad though
Aug 16 16:00:51 <kergoth> seems liek that should go into uihelper or knotty
Aug 16 16:03:08 <xxiao> is the hob_web project similar to narcissus @ angstrom?
Aug 16 16:03:35 <xxiao> is it an assembly framework or build-from-source framework?
Aug 16 16:03:50 <kergoth> xxiao: I'd suggest watching the video
Aug 16 16:04:22 <kergoth> https://wiki.yoctoproject.org/wiki/Yocto_Web_Hob_Design
Aug 16 16:05:03 <xxiao> is hob2 = webhob
Aug 16 16:08:46 <xxiao> watching...90% users probably just want to re-assembly a rootfs at will, similar to narcissus
Aug 16 16:08:47 <msm> should poky build over NFS? is there any info on getting this to work?
Aug 16 16:09:16 <kergoth> msm: i suspect the answer is it's just not going to happen :)
Aug 16 16:09:32 <msm> kergoth: that's a fine answer - just wanted to make sure before i told a user
Aug 16 16:09:55 * kergoth isn't 100%, but historically we've just said it won't work, afaik
Aug 16 16:10:03 <zeddii> pseudo ends up with inode issues IIRC.
Aug 16 16:10:19 <zeddii> then you can fall back to "NFS sucks" and run away.
Aug 16 16:10:31 <bluelightning> xxiao: no, webhob is web-based, hob2 is gtk-based
Aug 16 16:10:32 <kergoth> hehe
Aug 16 16:10:51 <bluelightning> xxiao: for binary distros, sure; and that's what narcissus provides
Aug 16 16:11:08 <bluelightning> xxiao: we have the potential to be able to offer a bit more with web hob
Aug 16 16:11:36 <xxiao> when will webhob be available for the public use?
Aug 16 16:11:41 <xxiao> after 1.3?
Aug 16 16:13:01 <bluelightning> xxiao: at the moment we have really gone no further than the clickable prototype stage... it won't be in 1.3
Aug 16 16:13:13 <xxiao> ok,thanks
Aug 16 16:13:30 <xxiao> the video does seem very promising
Aug 16 16:16:53 <kergoth> hmm, anyone tried bulidling ipsec-tools recently? getting a LIC_FILES_CHKSUM mismatch
Aug 16 16:44:13 <mranostay> vivijim: your connection sucks
Aug 16 16:44:36 <mranostay> or flooding rather
Aug 16 16:49:37 <vivijim> sorry
Aug 16 16:51:17 <vivijim> not just the network... vpn + bip + proxy + pidgin :P
Aug 16 16:54:40 <kergoth> RP: did you ever see https://gist.github.com/2788410 ? was just fun experimentation, but it's something to think about.. consider: PRINC += 1 ;)
Aug 16 16:56:18 <RP> kergoth: I think I did look at it before, yes. Its kind of neat
Aug 16 16:56:43 <kergoth> probably insufficient, since we probably want our *own* types, just json's types, but..
Aug 16 16:56:45 * kergoth ponders
Aug 16 16:57:26 <kergoth> was jsut doing yet another ${@int(PRINC) + 1} and got me thinking about it again :P
Aug 16 16:57:42 <harrison> Is this the closest thing there is to an IRC channel where Tilera is relevant?
Aug 16 16:58:07 <harrison> In other words, I wish there was a #tilera
Aug 16 16:58:45 <kergoth> i guess you could create one, though if you're looking for help that wouldn't help :)
Aug 16 16:59:38 <harrison> well yes that is correct
Aug 16 17:00:57 <harrison> perhaps i hoped a little that someone here would say "well, you could try #somechannel or #someotherchannel"
Aug 16 17:01:19 * kergoth nods, don't know personally, hopefully someone else does
Aug 16 17:05:23 <bluelightning> kergoth: hmm... I definitely dislike the PRINC business... but that will probably go away with the PR server so at least that problem won't be around for much longer
Aug 16 17:21:23 <JaMa> bluelightning: is there some plan to make PR server working without using OEBasicHash?
Aug 16 17:21:48 <bluelightning> JaMa: I'm not sure how it could work reliably without it...
Aug 16 17:23:10 <JaMa> me too.. that's why I hope that PR server switch will be done in next release cycle not in current
Aug 16 17:23:22 <JaMa> so I could stay with last release
Aug 16 17:24:23 <bluelightning> JaMa: you'd need to talk to RP about that I guess
Aug 16 17:26:34 <zenlinux> RP, I know you're still digging out from being away, but was wondering when you could take a look at my denzil pull requests
Aug 16 17:31:32 <JaMa> bluelightning: it's still the same as described few months ago.. just making OEBasicHash mandatory for PR server makes it few times worse
Aug 16 17:35:51 <bluelightning> JaMa: have you tried OEBasicHash recently?
Aug 16 17:37:15 * kergoth can't remember the last tie he didn't build with OEBasicHash
Aug 16 17:37:19 <kergoth> s/tie/time/
Aug 16 17:38:15 <JaMa> bluelightning: yes on one jenkins server.. it's building 24/7 just to catch up..
Aug 16 17:38:41 <JaMa> bluelightning: with PR server users wont be able to opkg upgrade over gprs..
Aug 16 17:39:31 <bluelightning> JaMa: the question is what is changing to cause the rebuilds you're seeing that you don't think should be happening?
Aug 16 17:39:40 <JaMa> I agree it works good when you base your setup on releases or don't update oe-core too often
Aug 16 17:40:17 <JaMa> but for rolling updates and tracking oe-core/HEAD with jenkins build started every day it's too strict
Aug 16 17:40:35 <bluelightning> I'm not sure whether it's a reasonable expectation to be able to provide stable distro feeds from master of OE-Core to be perfectly honest
Aug 16 17:41:22 <JaMa> that's why I plan to stop using HEAD after next release (don't want to go back to denzil) and I was hoping that it will be without PR server
Aug 16 17:42:36 <JaMa> bluelightning: it's not master directly.. it's from shr branch (but that tracks master very closely - 1-2 days lag just for testing, before it's merged to shr branch)
Aug 16 17:43:51 <kergoth> we work from master, but i only update the upstream layers on a weekly basis or so, after i've sanity checked the update to make sure nothing upstream broke us. works fairly well
Aug 16 17:44:09 <JaMa> kergoth: and how big is your "feed"?
Aug 16 17:44:31 <bluelightning> working from master is fine, that's a different thing to having users expect that to be always usable
Aug 16 17:44:44 <kergoth> our distro isn't a binary one, we don't have customer accessible binary feeds the way shr and angstrom do, so our needs are different
Aug 16 17:44:49 <bluelightning> right
Aug 16 17:45:05 <JaMa> kergoth: because with stuff like webkit-gtk/webkit-efl/qt4-x11-free and other *big* stuff it takes ages (core-image on the other hand is quite fine)
Aug 16 17:45:20 <kergoth> hmm
Aug 16 17:46:29 <bluelightning> I'm not sure there are any magic half-way solutions
Aug 16 17:47:21 <kergoth> course, i'm not really affected by oebasichash anyway, because i don't keep around build directories. with sstate, i wipe after every build and just keep its output
Aug 16 17:47:22 <kergoth> heh
Aug 16 17:47:43 <bluelightning> it might be reasonable at this point to leave the PR server switch until after 1.3 but I imagine RP will not be happy with that
Aug 16 17:47:55 <JaMa> kergoth: hehe.. but one such build for me takes >1 day for one arch :)
Aug 16 17:48:03 <kergoth> holy cow
Aug 16 17:48:07 <kergoth> you must build a lot of stuff
Aug 16 17:48:18 <bluelightning> unfortunately I have to head home now, may be back on later
Aug 16 17:48:40 * kergoth should try kicking off a build like that and see how long it takes on his build vm
Aug 16 17:49:04 <JaMa> kergoth: try bitbake world with oe-core/meta-oe/meta-smartphone enabled :)
Aug 16 17:50:52 <kergoth> ooh
Aug 16 17:51:03 <kergoth> i haven't tried a world in ages, thats a good idea
Aug 16 17:51:05 <JaMa> kergoth: image with whole feed included has something like 400MB (but no -dev/-dbg packages) and deploy/ipk has about 8G
Aug 16 17:51:10 <kergoth> i'd better get another disk for that..
Aug 16 18:18:33 <kergoth> http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/commit/?id=a916077 - stupidly simple, but if anyone else would find it useful..
Aug 16 18:23:03 <mranostay> kergoth: that seems Gentoo'ish :)
Aug 16 18:23:46 <kergoth> indeed
Aug 16 18:24:05 <msm> anyone see this: http://pastebin.com/wZ0gxmey
Aug 16 18:25:00 <msm> its occuring on an old centos 5.x box
Aug 16 18:34:43 <kergoth> msm: I have seen that before, but unfortunately I can't recall if there was a solution offhand
Aug 16 19:00:19 <kergoth> why does the bitbake wrapper require that we run bitbake from the build directory? bitbake doesn't require this, it lets you run from anywhwere *under* the build dir
Aug 16 19:00:26 <kergoth> all it needs to do is make sure that $PWD starts with $BUILDDIR/
Aug 16 19:00:32 * kergoth 'll have to do a patch for that
Aug 16 19:06:34 <bizhanMona> Hello please answer this question, I have loaded my x86 (sandy bridge) box using buildroot. What am I missing by not using Yocto romely image?  Many thanks in advance.
Aug 16 19:20:49 <kergoth> sgw: I think you're getting a little over-enthusiastic in your 'merged to oe-core' mails. Pretty sure the dbus nativesdk fix you replied to on the list wasn't actually merge,d but was superceded by a fix richard did, and you also replied to a bitbake patch saying it was merged to oe-core ;)
Aug 16 19:21:18 * kergoth stretches and hacks on mentor's oe env setup script
Aug 16 19:21:55 <sgw> kergoth: yeah, I was looking at the wrong log file, and missed that, sorry for the confusion.
Aug 16 19:22:27 <kishore> Hi, Did anyone had question on romley bsp?
Aug 16 19:22:36 <kishore> I missed the question.
Aug 16 19:22:51 <sgw> kishore: bizhanMona asked about Romely BSP
Aug 16 19:23:07 <sgw> kergoth: just one of those days!
Aug 16 19:24:02 <kishore> bizhanMona: ping
Aug 16 19:25:03 <kergoth> sgw: hehe, np. i'm sure the folks who posted the patches realize was what meant :) just figured i'd make sure you realized
Aug 16 19:25:19 <seebs> This may be a pretty silly question, but I'm stumped and the log files don't mention anything. I'm building a -cross package. If I use STAGING_BINDIR_TOOLCHAIN, everything works.
Aug 16 19:25:52 <seebs> If I use a different directory that's the same except for the last directory component, do_populate_sysroot fails because it can't package things using tar, because the directory it wants to change to doesn't exist.
Aug 16 19:26:09 <seebs> Thing is, that directory is in sysroot-destdir/*. And the package only writes to image/*.
Aug 16 19:26:23 <seebs> And I can't find anything in my logs that explains how it got moved/copied. :)
Aug 16 19:27:01 <seebs> Hmm. This seems to be staging.bbclass, but I can't figure out why there's no log or diagnostic messages...
Aug 16 19:28:13 <seebs> oh-hoh! I think that is it. ${bindir}, for toolchainy-stuff, has been set to STAGING_BINDIR_TOOLCHAIN. And sysroot_stage_dir is copying ${bindir}, which isn't usr/bin. Hmm.
Aug 16 19:29:10 <seebs> ... So now the mystery is, how did I look at this for nearly half an hour to no avail, and find it within three minutes of starting to type in IRC?
Aug 16 19:29:26 <fray> because, thats how it works
Aug 16 19:29:53 <seebs> So what I really want to do is override ${bindir}, probably.
Aug 16 19:32:08 <ant__> sebs: sounds starnge... I had similar issues when I was trying to package -cross recipes
Aug 16 19:32:30 <kergoth> that's typical. most debugging issues are just a mismatch between your mental model and reality, and explaining it forces you to re-evaluate your assumptions
Aug 16 19:32:32 <kergoth> heh
Aug 16 19:32:41 <seebs>  Yes.
Aug 16 19:32:51 <ant__> you should just inherit cross and   install -d ${D}${base_bindir}
Aug 16 19:32:53 <seebs> Nearly everything people have trouble with turns out to be a mismatch between mental model and reality.
Aug 16 19:33:07 <seebs> Well, thing is. I don't want to end up in base_bindir. I want to end up in This Other Directory Over Here.
Aug 16 19:33:29 <ant__> ;)
Aug 16 19:33:30 <ant__> install -m 0755 klcc/klcc ${D}${base_bindir}/${TARGET_PREFIX}klcc
Aug 16 19:33:50 <ant__> this goes straight in sysroot
Aug 16 19:34:03 <seebs> My solution is
Aug 16 19:34:25 <seebs> bindir = "${TOOLCHAIN_STASH_DIR}", which is at the moment <sysroot>/usr/bin/toolchain
Aug 16 19:35:49 <ant__> seebs: chack out this example, klcc is in sysroot but the utils are for target
Aug 16 19:35:55 <ant__> http://cgit.openembedded.org/meta-openembedded/tree/meta-initramfs/recipes-devtools/klibc/klcc-cross_2.0.1.bb
Aug 16 19:36:12 <ant__> (I stil lwonder how bad this approach is...)
Aug 16 19:36:51 <msm> anyone seeing this: https://gist.github.com/3372954
Aug 16 19:37:05 <msm> (again im only seeing it on my older centos machine python 2.6
Aug 16 19:37:06 <msm> )
Aug 16 19:38:37 <bluelightning> msm: I believe that just got fixed
Aug 16 19:38:57 <bluelightning> pull and it ought to go away I think
Aug 16 19:42:50 <msm> bluelightning: awesome, thanks for the info ;)
Aug 16 19:46:09 <bluelightning> np
Aug 16 19:46:23 <msm> kergoth: that cross-localedef-native issue is seemingly fixed by adding a define for DUMMY_LOCALE_T
Aug 16 19:46:31 <kergoth> ah, interesting
Aug 16 19:46:36 <msm> and avoiding the definition conflict
Aug 16 19:46:48 <msm> however, im not sure what im doing
Aug 16 19:46:52 <msm> besides fixing the build
Aug 16 21:26:44 <msm> whoa
Aug 16 21:26:47 <msm> what works under knotty2?
Aug 16 21:26:50 <msm> errr
Aug 16 21:26:54 <msm> what shortcuts are there?
Aug 16 21:27:32 <msm> i seem to recall some emails this
Aug 16 21:30:29 <msm> its hypnotic watching the "log" now ;)
Aug 16 21:31:10 <kergoth> none of the interactive commands and all got merged
Aug 16 21:31:17 <kergoth> just a few fixes to knotty2 and the merge into knotty
Aug 16 23:04:00 <halstead> We had a hiccup on downloads.yoctoproject.org network. Looking into it.
Aug 17 02:37:00 <xxiao> if i don't set IMAGE_ROOTFS_SIZE, and default is ?=65M, when my real rootfs is larger than 65M, how does it adjust?
Aug 17 02:37:32 <xxiao> meta/conf/bitbake.conf has it IMAGE_ROOTFS_SIZE ?= "65536"
Aug 17 02:37:52 <xxiao> if i don't override it, and my rootfs is large, how does yocto cope with that
Aug 17 02:42:35 <evanp> I think IMAGE_ROOTFS_EXTRA_SPACE and IMAGE_OVERHEAD_FACTOR are involved; haven't had to learn those details yet, so I can't say for sure
Aug 17 02:47:55 <xxiao> evanp: yeah it's likely when final rootfs is assembled yocto adjust it somehow, the question is how much extra-space it leaves
Aug 17 02:48:12 <xxiao> s/adjust it/adjusts its size/
Aug 17 02:52:17 <kergoth> pretty sure the extra space is governed by IMAGE_ROOTFS_EXTRA_SPACE as evanp just said, no?
**** ENDING LOGGING AT Fri Aug 17 02:59:58 2012

**** BEGIN LOGGING AT Fri Aug 17 02:59:58 2012
Aug 17 03:07:59 <xxiao> kergoth: meta/conf/bitbake.conf:IMAGE_ROOTFS_EXTRA_SPACE ?= "0"
Aug 17 03:08:11 <xxiao> meta/classes/rootfs_rpm.bbclass:IMAGE_ROOTFS_EXTRA_SPACE_append = "${@base_contains("PACKAGE_INSTALL", "zypper", " + 51200", "" ,d)}"
Aug 17 03:09:56 <xxiao> i don't know what 51200 means, it seems i should use IMAGE_ROOTFS_EXTRA_SPACE in image file to choose extra space
Aug 17 03:21:05 <msm> sgw: you there?
Aug 17 03:21:28 <msm> sgw: did you decide if you were going to merge the kmod native fix?
Aug 17 05:00:33 <sgw> msm: which variation of it, I have seen different patches, can you re-send with a new request.
Aug 17 05:19:55 <msm> sgw: hmm, i don't mind which one - they all achieve the same effect - but i can resend something tomorrow
Aug 17 07:59:08 <shoragan> bluelightning, hi
Aug 17 07:59:17 <bluelightning> hi shoragan, all
Aug 17 07:59:27 <shoragan> i've finally found time to update yocto to denzil-7.0.1
Aug 17 07:59:35 <shoragan> and test hob again
Aug 17 07:59:53 <shoragan> but the result is the same, a error box with no text during parsing
Aug 17 08:02:59 <bluelightning> shoragan: hmm, that's annoying
Aug 17 08:03:23 <ant_work> zeddii: [PATCH] kconfig: remove CONFIG_MTD_NAND_VERIFY_WRITE
Aug 17 08:03:59 <ant_work> zeddii: that's the final word on the issue
Aug 17 08:08:00 <shoragan> and MACHINE=mymachine bitbake -p works fine
Aug 17 08:13:02 <shoragan> do you have any idea on how to find the actual error cause?
Aug 17 08:13:30 <bluelightning> no I don't I'm afraid...
Aug 17 08:13:48 <bluelightning> I can't remember, is there a bug filed on this issue?
Aug 17 08:14:57 <shoragan> not by me
Aug 17 08:15:11 <shoragan> i seem to remember that you wanted to file one
Aug 17 08:19:42 <bluelightning> I'm probably not as well placed to do that atm - would you mind doing it?
Aug 17 08:27:20 <shoragan> ok
Aug 17 08:48:58 <shoragan> bluelightning, https://bugzilla.yoctoproject.org/show_bug.cgi?id=2960
Aug 17 09:04:57 <bluelightning> shoragan: great, thanks
Aug 17 09:44:28 <ag_> Hello.
Aug 17 09:45:09 <ag_> Can anybody explain what is the reason of having ";" at the end of patches in SRC_URI?
Aug 17 09:49:40 <ag_> I know that there should be arguments. But if there is none, wouldn't this fail with non existent file?
Aug 17 09:50:11 <bluelightning> ag_: that's not necessary... probably an artefact of search and replace removing patch=1 I'm guessing
Aug 17 09:50:32 <bluelightning> it probably won't fail because ; is always considered as a separator
Aug 17 09:50:37 <ag_> Nope.
Aug 17 09:50:40 <ag_> Here is my use case.
Aug 17 09:52:47 <ag_> I have another recipe named, dbus-tests, which includes dbus.inc and adds EXTRAFILEPATHS to dbus-${PV}. Well... it crashes with: ERROR: Function failed: Fetcher failure for URL: 'file://tmpdir.patch;'. Unable to fetch URL from any source.
Aug 17 09:52:59 <ag_> Strangely dbus itself is working ok
Aug 17 09:56:00 <ag_> bluelightning: So somehow it fails...
Aug 17 09:56:56 <bluelightning> are you using _append or .= with SRC_URI in your other recipe?
Aug 17 09:57:07 <ag_> +=
Aug 17 09:57:23 <bluelightning> ok, well I guess it's not a good idea to have ; with no arguments then
Aug 17 09:57:33 <ag_> Seems like...
Aug 17 09:57:55 <ag_> I will try to find out why isn't this considered a separator.
Aug 17 09:58:41 <ag_> But i just can't realize why this works in dbus and it doesn't work in a recipe which includes the same inc and adds path to patches...
Aug 17 10:03:21 <ag_> You'll never guess where was the real problem.... no ${THISDIR} ... in EXTRAFILEPATHS
Aug 17 10:03:27 <ag_> bluelightning: thank you very much
Aug 17 10:03:35 <ag_> bluelightning: Sorry for my stupidity ....
Aug 17 10:03:43 <bluelightning> oh, oops...
Aug 17 10:03:46 <bluelightning> no problem :)
Aug 17 12:48:12 <peachj> What would you all recommend for minimum amounts of memory and cores/processors (including speed) for reasonably swift development with Yocto?
Aug 17 12:49:28 <bluelightning> depends on how fast you want the build to go :)
Aug 17 12:51:11 <xxiao> it's interesting to know the memory size though, to avoid heavy swapping during yocto build
Aug 17 12:52:20 <xxiao> otherwise, build the whole image once, which will take a while, then build your packages and kernel/uboot, those should be built relatively faster
Aug 17 12:52:28 <bluelightning> RAM usage will be dependent on how much parallelisation you enable
Aug 17 12:52:45 <xxiao> assuming it's 1.5xcores or 2x,
Aug 17 12:53:06 <bluelightning> FWIW, I'm doing a "world" build now on a four core machine with 8GB RAM, and only 5.5GB is being used
Aug 17 12:53:26 <bluelightning> that's with 8 / 8 for BB_NUMBER_THREADS and PARALLEL_MAKE
Aug 17 12:53:48 <xxiao> that's similar to my machine, but i do 12/8 here
Aug 17 12:53:57 <bluelightning> of course what's left over will be used for caches
Aug 17 12:55:12 <bluelightning> builds will work perfectly fine on a 2-core 32-bit machine with 4G RAM, they just take a little longer
Aug 17 12:55:46 <likewise> xxiao: with those parameters, your disk becomes important, I gained 30% speed when moving from HDD to SSD.
Aug 17 12:55:47 <bluelightning> going back in history I've done OE builds on much lesser machines than that
Aug 17 12:56:18 <likewise> I guess my remark was based on bluelightning's numbers (8/8).
Aug 17 12:56:19 <bluelightning> hmm, I wouldn't necessarily recommend using an SSD for TMPDIR for regular builds though
Aug 17 12:56:35 <likewise> bluelightning: why not? it won't wear out that fast.
Aug 17 12:56:55 <xxiao> likewise: i kind of not trusting ssd, i had 2 dead SSDs out of 8 during a benchmark testing two months ago
Aug 17 12:56:56 <likewise> bluelightning: even with high write amplification you are not going to wear the disk out.
Aug 17 12:57:03 * mru has not regretted upgrading his machine to 24GB RAM
Aug 17 12:57:11 <bluelightning> a *lot* of data gets written out during a build... if you start from scratch that gets thrown away
Aug 17 12:57:15 <likewise> xxiao: can you name brands?
Aug 17 12:57:38 <xxiao> vortex ocz
Aug 17 12:57:41 <likewise> bluelightning: well, writes are fast on ssd.
Aug 17 12:57:50 <xxiao> google told me it's because of some silicon bug
Aug 17 12:58:35 <likewise> xxiao: assuming a stable ssd, I don't see any downside in using it. My HDD's also die after 3-5 years.
Aug 17 12:59:28 <likewise> 3-10 yrs, but i've seen a lot of disks die around ~5 yrs of use. (That was often with multiple starts per day)
Aug 17 12:59:59 <RP> likewise: My experience suggests ssds wear out much faster
Aug 17 13:00:07 <RP> likewise: This was a year or two ago though
Aug 17 13:00:10 <xxiao> that's fine, but the SSD I tested die in 2 months, I only use them at test runs, not daily heavy build or anything
Aug 17 13:03:17 <likewise> RP: faster than Intel says? :)
Aug 17 13:05:36 <RP> likewise: these weren't intel ssds
Aug 17 13:09:00 <likewise> ok, I have not have seen any wear out problems with Intel, Samsung, Crucial, and I have avoided the known-bad firmwares. YMMV, for me the speed gain outways the cost to replace.
Aug 17 13:09:54 <xxiao> likewise: what capacity is on your SSD?
Aug 17 13:13:04 <likewise> xxiao: 80 GB to 256 MB
Aug 17 13:13:09 <likewise> MB=>GB
Aug 17 13:13:19 <likewise> and I just got two 32 GB's but not for OE builds
Aug 17 13:14:01 <likewise> indeed, capacity does matter for longevity
Aug 17 13:21:33 <_Lucretia_> hi, i've been trying to get an apt patch applying in my local git tree as the denzil branch does not have it and it fails - it's a var redeclaration.
Aug 17 13:22:39 <_Lucretia_> so, I thought I'd go to the mat branch, git format-patch -1 9e7c9151147363a2ebc30612fc87d667a96af0f8 1e71397c23c90fc74f76db4d6e34917f4d58af0f and then go my denzil branch and then do git am 0001-apt-get-0.7.14-hangs-at-runtime.patch - it says it applies, but i see no patch in the files dir. can anybody help?
Aug 17 13:33:01 <bluelightning> _Lucretia_: surely an easier way to do that is just git cherry-pick ?
Aug 17 13:33:12 <_Lucretia_> no idea
Aug 17 13:33:24 <_Lucretia_> like i've said, my git usage so far has been minimal
Aug 17 13:33:42 <bluelightning> that's the easiest way to take a single commit from one branch and apply it to another, assuming those revs are valid within the same clone
Aug 17 13:34:11 <_Lucretia_> well, i just made a copy of the denzil branch to work in as the denzil branch doesn't build
Aug 17 13:34:25 <_Lucretia_> so i can do that inside my own branch?
Aug 17 13:35:14 <bluelightning> if the copy is still a valid git clone, sure you can just do the cherry-pick from the other branch
Aug 17 13:35:43 <_Lucretia_> well, am applied the commit, didn't give me any errors, how do i go back?
Aug 17 13:35:56 <bluelightning> go back? you mean undo the cherry-pick?
Aug 17 13:36:16 <bluelightning> or something else?
Aug 17 13:36:24 <_Lucretia_> no, to before the am
Aug 17 13:37:22 <bluelightning> git am --abort
Aug 17 13:37:43 <bluelightning> oh, the am worked...
Aug 17 13:38:19 <_Lucretia_> yet the patch includes a patch for the files dir to remove the redeclaration, but that's not there
Aug 17 13:38:26 <_Lucretia_> and it fails on build still
Aug 17 13:38:27 <bluelightning> well, after first checking to ensure you haven't got any uncommitted changes, you should be able to git reset --hard HEAD^
Aug 17 13:38:34 <bluelightning> are you sure you got the right commit?
Aug 17 13:39:11 <_Lucretia_> this is the one, pointed to on the ml
Aug 17 13:39:12 <bluelightning> because either format-patch will give you the entire commit, if that actually added a file it will be there
Aug 17 13:39:22 <_Lucretia_> and here's the full patch http://pastebin.com/2wXXmWVt
Aug 17 13:39:45 <bluelightning> right
Aug 17 13:39:55 <_Lucretia_> file is not there
Aug 17 13:41:12 <bluelightning> I think there's something else going on here, if the patch applied the file would exist
Aug 17 13:41:40 <bluelightning> easiest thing is, reset back to where you were before and use cherry-pick to get the commit you need
Aug 17 13:41:48 <_Lucretia_> poky$ ls meta/recipes-devtools/apt/files/
Aug 17 13:41:49 <_Lucretia_> apt.conf  db_linking_hack.patch  environment.patch  no-curl.patch
Aug 17 13:42:27 <bluelightning> _Lucretia_: ah, right... if you look at that patch you will see the path to the added file is under apt-0.7.14, not files
Aug 17 13:43:19 <_Lucretia_> poky$ ls meta/recipes-devtools/apt/apt-0.7.14/
Aug 17 13:43:19 <_Lucretia_> includes-fix.patch  localefixes.patch  makerace.patch  noconfigure.patch  nodoc.patch  no-ko-translation.patch  use-host.patch
Aug 17 13:44:09 <bluelightning> _Lucretia_: do you see the patch when you do "git show"? or some other commit?
Aug 17 13:44:21 <bluelightning> or the top commit of git log, for that matter
Aug 17 13:45:20 <_Lucretia_> yup
Aug 17 13:45:57 <bluelightning> _Lucretia_: right, so looking at "git show"... where does it say the patch has been added?
Aug 17 13:46:16 <bluelightning> oh and check "git status" to make sure it hasn't been deleted
Aug 17 13:47:32 <_Lucretia_> actually, the patch shows removing the line to add the patch in the bb file
Aug 17 13:48:03 <_Lucretia_> i've got nothing to commit
Aug 17 13:48:09 <bluelightning> I'm having a hard time understanding what the current state of your working dir is to be honest
Aug 17 13:48:22 <_Lucretia_> diff --git a/meta/recipes-devtools/apt/apt-0.7.14/remove-redeclaration.patch b/meta/recipes-devtools/apt/apt-0.7.14/remove-redeclaration.patch
Aug 17 13:48:22 <_Lucretia_> deleted file mode 100644
Aug 17 13:48:28 <_Lucretia_> from show
Aug 17 13:49:05 <_Lucretia_> so it's deleted the patch - which wasn't there to start with, instead of putting it in
Aug 17 13:49:23 <bluelightning> right, it's the reverse of what you described and what I assumed without reading it correctly...
Aug 17 13:49:34 <_Lucretia_> my branch is the current denzil - from when i pulled it, branched and then took out those tabs->spaces patches
Aug 17 13:50:06 <bluelightning> well, hang on... denzil did not include any of those tabs->spaces changes
Aug 17 13:50:17 <_Lucretia_> no, remember last week
Aug 17 13:50:18 <bluelightning> that was done in master
Aug 17 13:51:17 <_Lucretia_> i had to rebase to remove the spaces patches so it would build
Aug 17 13:51:30 <bluelightning> which git repository are we talking about here?
Aug 17 13:51:33 <walters> has anyone seen this one before?  http://pastebin.mozilla.org/1761696
Aug 17 13:51:57 <bluelightning> walters: I haven't, maybe someone else has though
Aug 17 13:51:58 <walters> so this find_cpp() function in libc/sunrpc/rpc_main.c...awful code
Aug 17 13:52:27 <_Lucretia_> bluelightning: that was the meta-gumstix repo
Aug 17 13:53:29 <bluelightning> _Lucretia_: I spoke to the meta-gumstix maintainer, he claims that the offending recipe has been removed from master and thus the master branch should now work with denzil
Aug 17 13:54:02 <bluelightning> (when I say denzil, I mean the Poky/OE-Core denzil branch)
Aug 17 13:54:55 <bluelightning> _Lucretia_: can you update to master of meta-gumstix and check if that is the case?
Aug 17 13:55:08 <bluelightning> latest master that is
Aug 17 13:56:08 <walters> ah, i wonder if this is fixed by 1cfd618493c30ccadb6ca3691074562d1589e8d8
Aug 17 13:56:57 <walters> pointless conflict on PR...
Aug 17 13:57:40 <bluelightning> _Lucretia_: wait a second, why are we talking about meta-gumstix if this is a patch against apt? that's in Poky/OE-Core....
Aug 17 13:58:16 * bluelightning 's head is starting to hurt
Aug 17 13:59:27 <walters> i have to compliment you guys on the high quality of commit messages - i've often been able to find bugfixes in master to cherry-pick within a few seconds of searching for keywords
Aug 17 13:59:54 <bluelightning> walters: it's something we beat people over the head about constantly ;)
Aug 17 14:00:02 <bluelightning> or at least, I do...
Aug 17 14:00:10 <walters> bluelightning, yeah, i spend a lot of time trying to do it in GNOME too
Aug 17 14:00:20 <likewise> bluelightning: is that why your head hurts? :)
Aug 17 14:00:30 <bluelightning> likewise: could be, I should stop hitting it :)
Aug 17 14:00:36 <likewise> bluelightning: ;-)
Aug 17 14:00:52 <RP> walters: It is good to know people do find them useful :)
Aug 17 14:01:23 <bluelightning> personally I always try to put something in the commit message even if the patch seems self-explanatory
Aug 17 14:01:29 <RP> walters: I know we've made mistakes in the past in that area, some of my early commits are nearly unintelligible even to me now
Aug 17 14:01:41 <walters> what really confused me about this bug is my build worked on Fedora 16 and RHEL6, but just recently started blowing up on Fedora 17
Aug 17 14:01:45 * RP tries to learn from the past
Aug 17 14:02:09 <_Lucretia_> bluelightning: there are two issues - at the moment - 1) meta-gumstix and spaces instead of tabs, 2) apt doesn't build
Aug 17 14:05:35 <RP> walters: the system is great at finding what seem at first to be crazy bugs :/
Aug 17 14:08:23 <walters> i suspect some Fedora update finished the UsrMove and the /lib/cpp symlink went away or something, because it worked a few months ago
Aug 17 14:08:43 <kergoth> My biggest pet peeve with messages is when they say *what* they do but not *why*, and I'm as guilty of those as anybody :)
Aug 17 14:09:12 <bluelightning> _Lucretia_: so 1) are you using the latest master of meta-gumstix?
Aug 17 14:09:28 <_Lucretia_> no, was still n my hacked branch
Aug 17 14:09:29 <bluelightning> kergoth: yes, that's a critical part of a good commit message
Aug 17 14:09:43 <bluelightning> _Lucretia_: right, I would suggest trying latest master
Aug 17 14:09:59 <bluelightning> (of just meta-gumstix)
Aug 17 14:10:01 <walters> our page on this is https://live.gnome.org/GnomeLove/SubmittingPatches
Aug 17 14:10:58 <_Lucretia_> bluelightning: not all of the repos?
Aug 17 14:11:24 <bluelightning> _Lucretia_: let's just keep things simple for now
Aug 17 14:11:56 <_Lucretia_> ok, but just one thing, because i couldn't build for gumstix, I moved to trying to build for panda
Aug 17 14:12:13 <_Lucretia_> so the above issue is a problem for pandaboard/denzil
Aug 17 14:12:30 <bluelightning> if you select deb packaging, of course...
Aug 17 14:13:12 <RP> kergoth: we've all been guilty at some point, I think we also try and do better. Certainly I think we've improved the message quality over the past while
Aug 17 14:13:18 <bluelightning> walters: here's our equivalent: https://wiki.yoctoproject.org/wiki/Contribution_Guidelines
Aug 17 14:13:37 <bluelightning> it's not always followed but we do try
Aug 17 14:13:37 <kergoth> RP: agreed. it's an ongoing effort
Aug 17 14:13:49 * RP likes having patches documented too. That helps an awful lot
Aug 17 14:17:47 <kergoth> oh yes, not having to dig through the git logs at all is lovely when it happens
Aug 17 15:06:46 <walters> ok just to follow up on this cpp issue
Aug 17 15:07:04 <walters> the issue is complicated by two things: UsrMove and multilib
Aug 17 15:07:32 <walters> looks like my Fedora system got upgraded and UsrMove symlinked /lib64 -> /usr/lib64, but kept /lib as a directory...clearly a fail
Aug 17 15:07:57 <walters> now, the real wtf is why rpcgen doesn't just search $PATH
Aug 17 15:09:08 <walters> maybe this laptop just got screwed over by yum/rpm + hacky shell scripts to convert
Aug 17 15:09:39 * walters looks forward to replacing those piles of crap with ostree ;)
Aug 17 15:13:29 <RP> walters: :)
Aug 17 15:49:04 <kergoth> is there a page somewhere that summarizes the yocto janitorial work?
Aug 17 15:49:17 <kergoth> i realize there's bugzilla severity for it
Aug 17 15:49:25 <kergoth> but was curious about how it's managed, if it is
Aug 17 15:51:18 <bluelightning> I think the only thing we have is the category really
Aug 17 15:51:30 * kergoth nods, k, figured as much
Aug 17 15:55:09 <halstead> pidge, One sec I'm adding Bruce right now.
Aug 17 15:58:32 <pidge> ty halstead
Aug 17 16:32:22 <sgw> kergoth: I think dvhart created a wiki explaining the concept, we could add a mediawiki hook there that lists the tasks
Aug 17 16:34:23 <halstead> zeddii, You're live on the builders and should have e-mail. Let me know if you have any questions.
Aug 17 16:34:40 <zeddii> ok. I'll have a go at it!
Aug 17 18:04:36 <dvhart> kergoth, https://wiki.yoctoproject.org/wiki/Janitors
Aug 17 18:04:44 <dvhart> kergoth, there doesn't seem to be much interest/activity so far
Aug 17 18:05:08 <dvhart> kergoth, that wiki page should be converted to bugzilla records
Aug 17 18:05:17 <dvhart> kergoth, I just have not got around to doing it
Aug 17 18:05:34 <kergoth> dvhart: heh, that's typical, i think.. we tried to do the same sort of thing with OE. i never understood *why*, because there does seem to be a group of folks that want to contribute but aren't sure how, and this would seem to fit them perfectly..
Aug 17 18:05:48 <kergoth> maybe we need to be more proactive about seeking them out
Aug 17 18:05:53 <kergoth> reduce barriers
Aug 17 18:05:56 * kergoth shrugs
Aug 17 18:06:04 <dvhart> kergoth, agreed
Aug 17 18:06:28 <dvhart> reduce barriers on both sides - for experts to populate and for noobs to get started
Aug 17 18:06:30 <Daemon404> how about creating a wiki page called "how to create your first bb recipe"
Aug 17 18:06:57 <dvhart> Daemon404, see the How-do-I pages, that would be a good addition there if there isn't one already
Aug 17 18:07:04 <Daemon404> and perhaps document all the possible vars/functions
Aug 17 18:07:08 <Daemon404> many are nto documented
Aug 17 18:07:10 <dvhart> although that is at least touched on in the manual
Aug 17 18:07:15 <Daemon404> and i have to grep through bbclasses to find them
Aug 17 18:08:02 <dvhart> Daemon404, as you find relevant, undocumented variables, please share what you learn on the list and CC scott rifenbark
Aug 17 18:08:25 <Daemon404> dvhart, my oe/yocto poking is at a minimum nowadays
Aug 17 18:08:26 <dvhart> he can then ensure they get added to the glossary in the manual
Aug 17 18:08:59 <kergoth> the problem with out of band documentation of something like variables it it'll never stay in sync. hence documentation.conf instead
Aug 17 18:11:29 <evanp> does anything link to that Janitors page? the Wiki itself doesn't...
Aug 17 18:13:23 <dvhart> evanp, perhaps not - in part because we want to use Bugzilla for janitors
Aug 17 18:13:39 <dvhart> but that page should be updated to reflect the new process and linked in to an appropriate place
Aug 17 18:14:13 <dvhart> kergoth, true, documentation.conf should definitely be updated first. Unfortunately it doesn't seem suitable for a detailed description of each variable and how they are meant to be used.
Aug 17 18:16:51 <kergoth> I think ideally we'd be able to use the flags for a summary, variable type to encode some of the semantics if possible, and even capture the comments above the flag definition as a more full help, or something..
Aug 17 18:16:52 * kergoth ponders
Aug 17 18:16:58 <kergoth> s/flags/doc flag/
Aug 17 18:17:23 <dvhart> kergoth, that's an interesting though
Aug 17 18:17:24 <dvhart> t
Aug 17 18:18:54 <kergoth> the type can work as documentation, or generate it, in some cases. e.g. FOO ?= "alpha"; FOO[type] = "choice"; FOO[choices] = "alpha beta gamma"
Aug 17 18:19:10 <kergoth> obviously more is necessary to describe the choices, but.. it's something
Aug 17 18:19:10 <kergoth> heh
Aug 17 18:31:03 <kergoth> hmm, would be nice if the PACKAGE_ARCH in the external toolchain recipe reflected the multilib it grabbed, somehow
Aug 17 20:50:20 <msm> is anyone seeing this on master?
Aug 17 20:50:20 <msm> https://gist.github.com/3382525
Aug 17 20:52:56 <msm> its late friday… surely someone knows something ;)
Aug 17 20:57:34 <mranostay> not late enough :)
Aug 17 21:59:42 <evanp> is it supported to have one PREFERRED_PROVIDER for package foo and another for foo-nativesdk? Or does something collapse that down? I've tried to do that, but am having a hard time making sense of the errors it reported.
Aug 17 22:01:40 <kergoth> foo-nativesdk and foo are entirely different recipes from bitbake's perspective
Aug 17 22:01:53 <kergoth> PREFERRED_PROVIDER_<pn> works for any recipe name, including both of those
Aug 17 22:01:59 <kergoth> so yes, it's supported, and no, it's not "collapsed"
Aug 17 22:04:17 <evanp> The PREFERRED_PROVIDER entries resulting in this conflict were: ['PREFERRED_PROVIDER_virtual/$ARCH1-$DISTRO1-linux-compilerlibs-nativesdk = mycrazything', 'PREFERRED_PROVIDER_virtual/$ARCH2-$DISTRO2-linux-compilerlibs = gcc-runtime']
Aug 17 22:05:11 <evanp> any ideas how I should interpret that? maybe the code which detects and prints this warning collapses them, and it otherwise works?
Aug 17 22:06:07 <evanp> err, not warning. it's an error.
Aug 17 22:08:19 <evanp> is using BBCLASSEXTEND = "nativesdk" exactly equivalent to having two recipies, one of which ends in "-nativesdk"?
Aug 17 22:08:24 <kergoth> yes.
Aug 17 22:08:33 <kergoth> it duplicates the metadata, and in the second recipe it inherits the nativesdk class
Aug 17 22:30:37 <evanp> huh. I guess PACKAGES in mycrazything.bb was somehow causing that
Aug 17 22:34:28 <evanp> I guess a recipe must implicitly RPROVIDE its PACKAGES?
Aug 17 22:35:36 <kergoth> that's what an rprovide *is*. a package a recipe is emitting
Aug 17 22:35:51 <kergoth> RPROVIDES just lets you add additional runtime deps to the existing packages
Aug 18 02:09:43 <khem> pidge: around ?
Aug 18 02:10:24 <khem> pidge: $tmpdir/buildstats dir has all timing info. How can I display it graphically ?
Aug 18 02:21:30 <khem> nm got it ../scripts/pybootchartgui/pybootchartgui/main.py
Aug 18 02:25:31 <khem> hmmm cool except the beginnin is clipping disaply of task name
Aug 18 02:25:44 <khem> may be it should be right aligned or something there
**** ENDING LOGGING AT Sat Aug 18 03:00:00 2012

**** BEGIN LOGGING AT Sat Aug 18 03:00:00 2012
Aug 18 04:55:22 * pidge_mobile waves at halstead.
Aug 18 04:55:45 * halstead waves at pidge_mobile.
Aug 18 10:31:18 <_Lucretia_> ok, so i've built the core-minimal image for pandaboard - changed my package method to ipk, which it likes. how do i go about getting this onto an sd card? just partition, copy over mlo/u-boot/kernel to msdos bootable partition and then unpack the filesystem tar onto the second partition?
Aug 18 12:30:06 <ccssnet> _Lucretia_: unlikely that you want to be using msdos formated media
Aug 18 12:30:40 <_Lucretia_> from what i've seen so far the pandaboard requires an msdos boot partition
Aug 18 12:31:15 <_Lucretia_> my aim is to get an understanding of the development/build process of yocto/poky for gumstix and panda
Aug 18 12:31:54 <_Lucretia_> and then from there, get it building specific stuff for the board - then to strip it down so it can produce a nand image
Aug 18 12:38:24 <ccssnet> hmm, i was not aware the pandaboard used a msdos boot part. news to me
Aug 18 12:38:35 <ccssnet> especially considering you mention u-boot above
Aug 18 12:47:13 <ccssnet> but hey i dont own one, i just have experience with other open source paired hardware such as the open pandora, and various routers
**** ENDING LOGGING AT Sun Aug 19 03:00:01 2012

**** BEGIN LOGGING AT Sun Aug 19 03:00:01 2012
**** ENDING LOGGING AT Mon Aug 20 02:59:59 2012

**** BEGIN LOGGING AT Mon Aug 20 02:59:59 2012
Aug 20 08:15:12 <RP> morning all
Aug 20 08:15:58 <JaMa> morning
Aug 20 08:16:26 <JaMa> RP: anything we can do for udev-extraconf merge?
Aug 20 08:18:06 <ant_work> JaMa, RP,  hello
Aug 20 08:18:54 <RP> JaMa: hmm, I'll try and get that sorted
Aug 20 08:19:05 <ant_work> JaMa: collie/armv4 still having tc issues. I added linaro 830 and 840 but still no luck
Aug 20 08:19:41 <JaMa> RP: thanks
Aug 20 08:20:30 <JaMa> ant_work: yes armv4t sucks more and more
Aug 20 10:36:38 <ignus> hi all - does anyone know how hard it would be to set up a udev blacklist in a root filesystem?
Aug 20 10:38:07 <bluelightning> ignus: hi - hmm, I don't know much about that specifically, presumably it's just a matter of placing a configuration file in an appropriate place in the rootfs?
Aug 20 10:38:51 <ignus> i assume so - my previous encounters with udev have been brief and painful from what i remember...
Aug 20 10:39:44 <ignus> bluelightning, is there a way to manipulate the rootfs after the yocto has finished populating it but before it gets packaged into a .ext3 file?
Aug 20 10:40:30 <bluelightning> ignus: indeed there is, typically you create a shell function and then add it to the end of ROOTFS_POSTPROCESS_COMMAND
Aug 20 10:40:54 <bluelightning> ignus: for something like this though you would probably just add it to SRC_URI of the udev recipe and then ensure it gets installed within do_install there
Aug 20 10:40:57 <ignus> ok, cool!
Aug 20 10:41:29 <ignus> i was actually thinking of using it to work around my kernel/modules issue until it is resolved.
Aug 20 10:41:44 <bluelightning> ignus: ah ok... did you get any further in isolating that one?
Aug 20 10:42:43 <ignus> the one  you were helping me with last week. i logged it in bugzilla and Bruce Ashfield seems to have picked it up.
Aug 20 10:43:06 <bluelightning> ah ok, cool, I didn't see that, will go and have a look now
Aug 20 10:43:50 <ignus> i dont think im allowed to post the info he requested so i just mailed it to him...
Aug 20 10:43:58 <ant_work> ignus: there is an udec.blacklist :)
Aug 20 10:44:35 <ignus> ant_work, ok great - that sounds like it might be what i need!
Aug 20 10:45:57 <ant_work> check udev-extraconf in oe-core
Aug 20 10:46:33 <bluelightning> ignus: ok, I'll reply to the bug with a pointer to where I think the dependency is being added
Aug 20 10:47:14 <ignus> bluelightning, that would be great, thanks! would it help if you could see the dep tree?
Aug 20 10:49:44 <bluelightning> ignus: I just realised something - did you try setting RDEPENDS_kernel-base = "" in your kernel recipe/bbappend?
Aug 20 10:49:48 <bluelightning> that ought to fix it...
Aug 20 10:50:42 <ignus> no, didnt try that. would that cause the kernel not to be built though or just not included in the output rootfs?
Aug 20 10:55:12 <ignus> ant_work, that seems to be exactly what im looking for, thanks!
Aug 20 10:57:33 <bluelightning> ignus: no, it won't affect building, just the package dependencies
Aug 20 10:57:46 <bluelightning> and therefore whether it is included in the rootfs
Aug 20 10:58:23 <ignus> ok - let me just try that
Aug 20 11:03:01 <ignus> bluelightning, if this works does it mean we will need to have 2 different kernel recipes if we want to have the bzimage included in one filesystem and not the other?
Aug 20 11:03:44 <bluelightning> ignus: no, you can just explicitly add kernel-image to IMAGE_INSTALL for the image in which you want to include the bzImage
Aug 20 11:04:21 <RP> ignus: The above is what I suspected might be possible when we talked
Aug 20 11:04:46 <RP> ignus: It just removes the dependency meaning you'd have to insert it manually if you want it back
Aug 20 11:05:00 <ignus> ah ok - thats fantastic. exactly what we need
Aug 20 11:06:07 <ignus> i hope its really that easy to fix, i was starting to think i might turn into an ordeal....
Aug 20 11:06:35 <bluelightning> I think we really need to document this one
Aug 20 11:07:55 <ignus> im kind of surprised its such a corner case and that no-one else has requested this before..
Aug 20 11:09:10 <bluelightning> ignus: a large number of machines boot with the kernel image inside the rootfs; for those that don't it might be the case that they don't use modules at all
Aug 20 11:09:20 <bluelightning> but you're right it's not that obscure a use case
Aug 20 11:13:17 <ignus> bluelightning, RP: it looks like that might have done it.
Aug 20 11:14:19 <bluelightning> ignus: great :)
Aug 20 11:14:21 <ignus> judging by the output file size. ill just have a look at the rootfs to confirm.
Aug 20 11:14:59 <ignus> bluelightning, do you think you can close the bug i logged and stick this down as the resolution or will i mail Bruce?
Aug 20 11:15:25 <bluelightning> ignus: I can mark it resolved, will do that now with a comment
Aug 20 11:29:26 <ignus> bluelightning, that worked, it just seems to create a symlink to a file which does not exist in /boot but that wont make any difference
Aug 20 11:33:19 <ignus> bluelightning, RP: thanks again for your help with this!
Aug 20 11:37:47 <ant_work> ignus: while you're there, do you have "modules.*" cruft  in your /lib/modules/$YOUR_KERNEL/ ?
Aug 20 11:38:44 <ant_work> I'm trying to purge my initramfs out of that modules stuff but what I see in image.bbclass is not encouraging
Aug 20 11:44:34 <ant_work> RP: It seems the code at image.bbclass#n209 could add unconditionally stuff to e.g. an initramfs image and beside of that run depmod
Aug 20 11:47:07 <ant_work> RP: then the default LDCONFIGDEPEND add th rest of the cruft I see :)
Aug 20 11:47:27 <ant_work> this one can be easily adjusted
Aug 20 11:48:46 <ant_work>  #78 LDCONFIGDEPEND ?= "ldconfig-native:do_populate_sysroot"
Aug 20 11:48:57 <ant_work> rather undocumented var :)
Aug 20 12:19:20 <ignus> ant_work, ill have a look for you now...
Aug 20 12:20:48 <ignus> ant_work, yeah there is quite a lot of stuff in there - about 16 modules.* files
Aug 20 12:41:08 <_Lucretia_> I don't really understand how this ADT fits into Yocto, I mean, you download the git repos for the layers you want, then configure and build, it builds all the compilers for you, what else is there?
Aug 20 12:44:24 <bluelightning> the ADT is designed for application developers rather than system developers
Aug 20 12:44:55 <ignus> ant_work, still there?
Aug 20 12:55:38 <ignus> does anyone else know how i might blacklist kernel modules using udev?
Aug 20 12:57:56 <_Lucretia_> for applications running on the yocto image?
Aug 20 13:07:51 <bluelightning> _Lucretia_: yes
Aug 20 13:08:23 <_Lucretia_> ok, but why not just create a package for your app so that it gets included in the build?
Aug 20 13:11:56 <bluelightning> _Lucretia_: that's what you would end up doing for production, but for day-to-day application development, the ADT is easier to deal with for apps developers
Aug 20 13:25:10 <bluelightning> ignus: looks like you just need to put a file in /etc/modprobe.d containing "blacklist <modulename>"
Aug 20 13:27:48 <ignus> bluelightning, i just got that far :D
Aug 20 13:28:35 <ignus> now im trying to make sure that this is something that should be done in the udev recipe
Aug 20 13:32:54 <bluelightning> ignus: another option would be to be more selective about which modules you install, of course
Aug 20 13:33:43 <ignus> bluelightning, i asked the kernel engineer if that was an option and he shot it down straight away...
Aug 20 13:33:57 <bluelightning> ignus: ah ok, fair enough
Aug 20 13:34:03 <ignus> bluelightning, meta/classes/kernel.bbclass:    install -d ${D}/etc/modprobe.d
Aug 20 13:34:31 <ignus> it looks like the kernel bbclass should create that dir but it doesnt seem to exist in my rootfs, which is strange
Aug 20 13:35:28 <bluelightning> ignus: there's also some code in kernel.bbclass which removes that directory if it's empty
Aug 20 13:35:49 <ignus> ah ok
Aug 20 13:36:04 <bluelightning> it should be OK to create that directory in udev-extraconf or whereever you end up adding the blacklist file
Aug 20 13:36:23 <ignus> do you think it would be safe to create it again in the udev recipe?
Aug 20 13:37:20 <ignus> ok, ill give it a shot...
Aug 20 13:43:22 <pirut> hi, is there a known issue building core-image-base on ubuntu 12.04
Aug 20 13:43:43 <pirut> "jade: symbol lookup error: /home/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/bin/../../usr/lib/libospgrove.so.0: undefined symbol: _ZN14OpenJade_Grove8ClassDef12sgmlDocumentE"
Aug 20 13:44:39 <pirut> "yocto/poky/build/tmp/work/x86_64-linux/docbook-utils-native-0.6.14-r3/docbook-utils-0.6.14/doc/HTML"
Aug 20 14:49:47 <kaju> I heard about the yocto project via the elce sometime back but just started trying out few days back. Every time i run the 'bitbake core-image-sato' it fails due to some missing symbols in jade. Any clues?
Aug 20 15:19:43 <autif> kaju: paste the whole error (pastebin) and may be someone will be able to help you. chances are you are missing some dependency (somelibrary or something that is needed for the build)
Aug 20 15:19:49 <kaju> I searched the bugzilla but didnt find any existing bugs on the issue. I tried poky-denzil-7.0.1 and even the git version but both fails.
Aug 20 15:20:11 <autif> kaju: paste the whole erroe
Aug 20 15:20:13 <kaju> autif: let me get that.
Aug 20 15:26:13 <kaju> huh! I lost my logs, so rebuilding to reproduce the error.
Aug 20 15:26:37 <bluelightning> FWIW, I'm running 12.04 here and docbook-utils-native builds fine
Aug 20 15:26:51 <bluelightning> presumably as autif says, something is missing
Aug 20 15:28:18 <kaju> hey, I am running 12.04 too but for me the docbook-utils-native fails reporting of some unresolved symbols in jade. I am rebuilding to get the exact error trace now.
Aug 20 15:31:51 <pirut> bluelightning: the path I pasted earlier with the issue seems to point to libospgrove.so.0 under poky, is this the case or is it just copied there from the host ?
Aug 20 15:31:58 <pirut> pirut> "jade: symbol lookup error: /home/yocto/poky/build/tmp/sysroots/x86_64-linux/usr/bin/../../usr/lib/libospgrove.so.0: undefined symbol: _ZN14OpenJade_Grove8ClassDef12sgmlDocumentE"
Aug 20 15:32:30 <kaju> ==pirut
Aug 20 15:32:38 <kaju> oops.. i wanted to say == pirut
Aug 20 15:33:15 <bluelightning> it shouldn't be copied there from the host no
Aug 20 15:34:14 <kaju> please elaborate?
Aug 20 15:34:18 <zenlinux_> morning RP, any chance my denzil pull request will be reviewed today?
Aug 20 15:35:25 <RP> zenlinux_: I knew there was something I hadn't got to :/
Aug 20 15:36:44 <kaju> bluelightning: I have the same error now
Aug 20 15:37:08 <kaju> | make[2]: *** [helpers.html] Error 127
Aug 20 15:37:09 <kaju> | jade: symbol lookup error: /opt/kdev/poky-x86-64-build/tmp/sysroots/x86_64-linux/usr/bin/../../usr/lib/libospgrove.so.0: undefined symbol: _ZN14OpenJade_Grove8ClassDef12sgmlDocumentE
Aug 20 15:39:27 <kaju> why is the jade getting built anyways when I have installed openjade on 12.04?
Aug 20 15:39:49 <kaju> the openjade on ubuntu 12.04 works fine but the one built by bitbake does not.
Aug 20 15:41:43 <bluelightning> kaju: what do you get if you run: ls -l /opt/kdev/poky-x86-64-build/tmp/sysroots/x86_64-linux/usr/bin/jade
Aug 20 15:42:47 <kaju> $ ls -l /opt/kdev/poky-x86-64-build/tmp/sysroots/x86_64-linux/usr/bin/jade
Aug 20 15:42:47 <kaju> lrwxrwxrwx 1 kaju kaju 8 Aug 20 21:05 /opt/kdev/poky-x86-64-build/tmp/sysroots/x86_64-linux/usr/bin/jade -> openjade
Aug 20 15:43:51 <kaju> FYI ldd doesnt give any issues over openjade
Aug 20 15:44:07 * kaju looking at what ubuntu is doing to build the stuff
Aug 20 15:45:13 <kaju> wow! ubuntu is building it with static and **not** shared.
Aug 20 15:45:47 * kaju wonders why?
Aug 20 15:46:18 <bluelightning> shouldn't matter... we're building our own openjade
Aug 20 15:46:48 <bluelightning> presumably /opt/kdev/poky-x86-64-build/tmp/sysroots/x86_64-linux/usr/bin/openjade exists?
Aug 20 15:47:35 <kaju> bluelightning: yes
Aug 20 15:47:53 <kaju> ah! the libogrove.so is not listed in the ldd over openjade
Aug 20 15:48:29 <bluelightning> it is here...
Aug 20 15:48:56 <bluelightning> so somehow openjade on your system has built without linking to libogrove
Aug 20 15:49:09 <kaju> which compiler are you using?
Aug 20 15:49:25 <kaju> I meant which version of gcc
Aug 20 15:49:28 <bluelightning> the default - gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
Aug 20 15:49:32 <bluelightning> for native that is
Aug 20 15:49:53 <bluelightning> I'm building for i686 though not x86-64, so that's one difference
Aug 20 15:50:04 <kaju> hmm..
Aug 20 15:50:19 <kaju> A quick look at the openjade source suggests that the call "_ZN14OpenJade_Grove8ClassDef12sgmlDocumentE" actually is present in one of the shared so lobogrove.so
Aug 20 15:51:42 <kaju> openjade bin object files dont use libogrove directly, so it appears that the gnu linker is ignoring it on my system
Aug 20 15:52:14 <bluelightning> kaju: could you pastebin the log.do_configure and log.do_compile from openjade?
Aug 20 15:54:38 <kaju> will do, and let me change the build option to use static as well in the mean time
Aug 20 15:59:09 <kaju> take a look at http://pastebin.com/P189gBPJ
Aug 20 16:01:22 <kaju> gr8, so using static in openjade fixes the issue
Aug 20 16:03:38 * kaju wonder if this is gcc bug
Aug 20 16:04:47 <kaju> I dont recollect any rule to say that a.out -> b.so -> c.so shouldn't be done
Aug 20 16:05:29 <kaju> though it doesnt look too good an engineering practice.
Aug 20 16:06:45 <dvhart> hrm... what effect does including the same path in two FILES_${PN}-* variables witin the same recipe have?
Aug 20 16:07:34 <bluelightning> dvhart: first package in PACKAGES gets the file I believe
Aug 20 16:07:43 <dvhart> I thought so too
Aug 20 16:08:17 <bluelightning> kaju: not sure, but oddly it looks like it is being told to link against libogrove.so in that log
Aug 20 16:08:49 <kaju> bluelightning: yeah! its odd that gcc cannot find the linking in x86_64
Aug 20 16:09:23 <kaju> since things are alright for you, so its a x86_64 issue
Aug 20 16:09:36 <bluelightning> well, I wouldn't say that's guaranteed
Aug 20 16:09:44 <kaju> ?
Aug 20 16:09:48 <bluelightning> it's just one difference noted between our two installations
Aug 20 16:10:17 <bluelightning> we don't have any direct evidence that it's an x86-64 only issue
Aug 20 16:10:31 <kaju> ah! yeah
Aug 20 16:10:43 <msm> bluelightning: "some people" haha ;)
Aug 20 16:11:01 <bluelightning> msm: should I have named you instead? ;)
Aug 20 16:12:15 <kaju> the following fixes the issue on my machine http://pastebin.com/cUb1x2Qj
Aug 20 16:13:56 <JaMa> RP: this is quite wrong.. notice meta/meta path http://git.openembedded.org/openembedded-core/commit/?id=e9a6df98458d9147227659d3888eff01589f2f76
Aug 20 16:14:14 <JaMa> WARNING: Unable to get checksum for qemu-nativesdk SRC_URI entry qemu-vmware-vga-depth.patch: file could not be found
Aug 20 16:14:43 <bluelightning> kaju: hmm, does it help if you undo that and set ASNEEDED = "" in the openjade recipe?
Aug 20 16:15:59 <kaju> bluelightning: will ASNEEDED = "" disable build of openjade and use the one installed on my system?
Aug 20 16:16:01 <msm> bluelightning: at least it implies there are more than just me ;)
Aug 20 16:16:37 <bluelightning> kaju: no, it disables the -Wl,as-needed linker option, which I suspect may be the cause of this issue... well, it's worth a shot anyway
Aug 20 16:16:44 <bluelightning> msm: :)
Aug 20 16:17:44 <bluelightning> kaju: although I don't see that option in your log...
Aug 20 16:19:20 * kaju trying ASNEEDED option
Aug 20 16:20:14 <bluelightning> actually that's not going to help...
Aug 20 16:20:35 <bluelightning> that's only for building for the target I think
Aug 20 16:22:25 <kaju> it didnt
Aug 20 16:23:14 <kaju> it appears that the best option right now is to use static inside openjade
Aug 20 16:25:42 <RP> JaMa: fixed thanks. Not sure why that happened :/
Aug 20 16:26:49 <kaju> bluelightning: should this go as a bug on OE-Core?
Aug 20 16:26:49 <bluelightning> kaju: could you do an ldd on the compiled executable under the workdir?
Aug 20 16:27:07 <bluelightning> kaju: I think we ought to have a bug filed about this yes
Aug 20 16:28:14 <kaju> bluelightning: I dont understand the version numbers there which goes till 1.4, but I tested over the denzil 7.0.1 and git/master
Aug 20 16:28:47 <bluelightning> kaju: you can probably put 1.3 then
Aug 20 16:29:46 <kaju> ok
Aug 20 16:34:24 <khem> RP: now that GL patches are dropped is someone working on upgrading qemu recipes to say 1.1+
Aug 20 16:37:49 <kaju> bug#2972 posted
Aug 20 16:38:06 <bluelightning> kaju: thanks
Aug 20 16:38:30 <kaju> np
Aug 20 16:40:04 <kaju> my image is built now and qemu runs as well. yocto rocks
Aug 20 16:41:06 <bluelightning> kaju: could you pastebin the log.do_install from the broken openjade?
Aug 20 16:41:26 <khem> bluelightning: did you try the armv4 kernel ?
Aug 20 16:41:45 <kaju> bluelightning: is the earlier log retained?
Aug 20 16:42:02 <bluelightning> khem: yes, same issue as before on collie
Aug 20 16:42:15 <bluelightning> kaju: if you didn't clean then yes
Aug 20 16:42:41 <kaju> gr8
Aug 20 16:46:24 <kaju> bluelightning: http://pastebin.com/erKaFN9L (updated the bug as well)
Aug 20 16:48:11 <bluelightning> kaju: hmm ok... can't see anything conclusive
Aug 20 16:48:23 <seebs> Okay, I have had more time to look. I find about three scripts that refer to the $rootfs/var/pseudo convention for PSEUDO_LOCALSTATEDIR, and so far as I can tell, nothing else is depending on that choice. And I can find no indication that there is a deeper meaning to that...
Aug 20 16:53:02 <RP> khem: not yet, I'll take patches though
Aug 20 16:53:19 <RP> khem: this was the first step, sorry it took a while to get sorted
Aug 20 17:05:56 <kaju> bluelightning: as I understand the issue is with linking openjade, where the  libogrove.so is not directly used by the binary so the linker is not linking it although the libospgrove.so uses libogrove.so (strange programming). What interests me is why the issue is non-existent on x86 host?
Aug 20 17:06:28 <bluelightning> kaju: did you try ldd on the openjade binary in the workdir?
Aug 20 17:07:02 <kaju> workdir, as in native installation on my system?
Aug 20 17:07:36 <bluelightning> kaju: tmp/work/<native sysroot>/openjade-native-*/openjade-*/
Aug 20 17:07:46 <kaju> yes, I did
Aug 20 17:10:10 <kaju> bluelightning: is there something specific you are looking for? Do you need the output?
Aug 20 17:12:52 <bluelightning> er, <native sysroot> is wrong in the above, but I guess you got what I meant
Aug 20 17:12:56 <bluelightning> kaju: I wanted to see if the ldd output was different between that binary and the one that ended up in the sysroot
Aug 20 17:13:43 <kaju> FWIW: I built openjade from source with OpenSP on my system (x86_64) and I see the same problem (unresolved symbols) for v1.3+
Aug 20 17:15:36 <kaju> bluelightning: I dont suspect that there is any issue with yocto, but openjade is at fault when build with shared-libs.
Aug 20 17:16:26 <bluelightning> right, but we still need to figure out what the correct fix is
Aug 20 17:16:45 <bluelightning> I'm not convinced that just making it static is the right answer
Aug 20 17:18:13 <kaju> hmm, alternatively you could see the unreleased openjade (sitting somewhere) in the original trunk (openjade.sf.net).
Aug 20 17:18:50 <kaju> ubuntu 12.04 uses openjade-1.4devl btw
Aug 20 17:33:58 <paulg> dvhart, what about yocto@yoctoproject.org ?  Should there be a blurb in there about what it is meant to be used for too?
Aug 20 17:37:26 <dvhart> Not from the poky repository
Aug 20 17:37:54 <dvhart> things like meta-intel and other Yocto projects that don't have their own lists go to yocto@yp...
Aug 20 17:38:00 <dvhart> but nothing in poky - I don't think
Aug 20 17:38:36 <dvhart> bluelightning, do I have that right?
Aug 20 17:38:50 <dvhart> nothing in poky that should have patches go to yocto@yp.org right?
Aug 20 17:38:53 <dvhart> sgw, ?
Aug 20 17:40:25 <bluelightning> dvhart: that's correct... I was going to suggest mentioning the docs in response to your README patch though
Aug 20 17:40:55 <dvhart> please do, I suspect rp and sgw may have changes too. I'll collect them and resubmit as appropriate
Aug 20 17:41:07 <dvhart> this gets something out there to get the ball rolling at least
Aug 20 17:47:26 <sgw> dvhart: just noticed this under my email window, reading
Aug 20 17:50:57 <dvhart> thanks sgw
Aug 20 17:51:01 <sgw> dvhart: the only thing I think might need to be added is caution in the scripts directory since I think it's the most blended part of the integrated poky
Aug 20 17:51:15 <sgw> dvhart: I am looking at that now just to see if I am right
Aug 20 17:51:20 <dvhart> Ah, I didn't realize that
Aug 20 17:51:30 <dvhart> how would you suggest wording that?
Aug 20 17:54:28 <sgw> dvhart: seems to be limited to yocto-bsp and yocto-kernel right now and oe-setup-builddir which looks to meta-yocto/conf instead of  meta/conf, so I would just add the warning that scripts might require a little research, you wording there is pretty close to that already.
Aug 20 17:55:05 <dvhart> OK, I'll highlight scripts
Aug 20 17:55:34 <Tartarus> sgw, I assume no one is auto-building oe-core still, true?
Aug 20 17:56:17 <sgw> Tartarus: it's on the list, but sadly not being ab'ed yet.
Aug 20 17:56:21 <paulg> dvhart, whoever owns this page:  https://lists.yoctoproject.org/listinfo  probably wants to change it then, since that is where I got the misinformation to use  yocto@yp.org
Aug 20 17:56:41 <Tartarus> sgw, OK, I'll just post my failure to get it to build to the ML and ask you for logs there
Aug 20 17:56:51 <paulg> it says for "Discussion of all things Yocto"
Aug 20 17:56:54 <sgw> sure thing
Aug 20 17:57:20 <Tartarus> sgw, oh, and can you confirm that u-boot-* builds for you without my changes?
Aug 20 17:57:24 <sgw> paulg: All things Yocto execpt patches for meta-yocto?
Aug 20 17:57:39 <dvhart> None of those descriptions are qdequate
Aug 20 17:57:50 <paulg> sgw, I guess that is an improvement.  :)
Aug 20 17:58:00 <sgw> Tartarus: I will get a build set up with and without your changes locally, it will be a bit.
Aug 20 17:58:05 <dvhart> and I see we've grown by a few more vague lists and descriptions
Aug 20 17:58:11 <Tartarus> thanks
Aug 20 17:58:31 <sgw> dvhart: those where thrown up there a long time ago when the lists where first created.
Aug 20 17:58:33 <paulg> dvhart, yeah, the description for the kernel-centric one is largely content free too.
Aug 20 17:59:02 <dvhart> sgw I believe they have changed some over time
Aug 20 17:59:10 <paulg> linux-yocto could be taken to mean largely anything....
Aug 20 17:59:15 <dvhart> paulg, hrm, I thought that one was clear :( how would change that?
Aug 20 17:59:34 <paulg> insert the word kernel somewhere?
Aug 20 17:59:39 <dvhart> "linux-yocto*.git Linux kernel repositories" ?
Aug 20 18:00:21 <dvhart> The actual blurb on the about page is:
Aug 20 18:00:24 <dvhart> "Development list for the linux-yocto git repositories. Patches for the various KTYPE and BSP branches as well as meta-data should be sent to this list for review and discussion."
Aug 20 18:00:51 <paulg> dvhart, my assumption was that unless you are down in the nuts and bolts of things, Joe Average would have no clue that the repos for kernel had the name prefix linux-yocto
Aug 20 18:00:54 <dvhart> is that adequate? (I can of course add the "Linux kernel" qualifier.
Aug 20 18:01:07 <dvhart> paulg, ack
Aug 20 18:01:54 <paulg> yeah, that would be a win for the summary page -- the desc on the list specific page wasn't so bad, but I'm guessing the summary page is what most ppl see.
Aug 20 18:07:41 <dvhart> paulg, agreed
Aug 20 18:08:02 <dvhart> it's a balance between keeping it short and sweet and not confusing the crap out of people...
Aug 20 18:12:10 <dvhart> hrm.... we also have http://www.yoctoproject.org/community/mailing-lists
Aug 20 18:12:24 <dvhart> I'm thinking this should just be replaced with a link to lists.yoctoproject.org
Aug 20 18:16:18 <msm> zenlinux: ping, i have a few more denzil commits on my poky-contrib branch
Aug 20 18:16:53 <zenlinux> msm, I'll make a note of them. I got word from RP today that he's planning on reviewing my current denzil pull request tomorrow.
Aug 20 18:16:56 <msm> zenlinux: two are semi-new (but not really) - upstream has disabled selinux for native stuff too as far as I can tell but also recipe names have changed
Aug 20 18:17:19 <msm> zenlinux: the others are quite obvious i believe
Aug 20 18:17:58 <msm> zenlinux: im thinking i should send these to the ML?
Aug 20 18:18:57 <zenlinux> msm, IMO the more review they get the better, so that would be good
Aug 20 18:24:04 <msm> zenlinux: ok ive sent the *new* patches, i've left the cherry-picks out for now
Aug 20 20:20:33 <rburton> is anyone actually using mesa-xlib?
Aug 20 20:20:53 <rburton> (or can someone with lots of yocto/oe BSP's checked out, grep for mesa-xlib)
Aug 20 20:22:29 <JaMa> rburton: meta-handheld is
Aug 20 20:22:38 <rburton> JaMa: omg why
Aug 20 20:22:59 <rburton> nothing actually *uses* it, right?
Aug 20 20:24:02 <JaMa> yes it was mostly to test xserver-lite on some device.. feel free to revert 2ed328bd842c96496fb5bbeecd3f6c7ed2df4c65 there
Aug 20 20:24:29 <JaMa> or ask ant why he wanted it so much
Aug 20 20:24:45 <rburton> i just discovered that mesa-xlib is literally turning GL ops to xlib drawing calls
Aug 20 20:25:03 <rburton> which must bring a whole new level of "slow" to a low-power arm
Aug 20 20:25:30 <rburton> i'm totally up for killing that, it's complicating the mesa recipes for no good reason
Aug 20 20:26:32 <JaMa> rburton: imho he wanted me to change that, because distroless oe-core default setup was using mesa-xlib and full xorg-xserver was failing for him
Aug 20 20:27:01 <JaMa> rburton: partialy fixed by 966f28c29a149dca3035e2c37ccf54ed82713bdf, but that still left 2 mesa providers for zaurus
Aug 20 20:28:26 <JaMa> rburton: and mesa-xlib was default provider till 2012 May..
Aug 20 20:28:33 <rburton> !
Aug 20 20:28:44 <rburton> ok
Aug 20 20:29:08 <rburton> i guess actual working GL on the devices we're targetting is a fairly recent development anyway :)
Aug 20 20:29:54 <JaMa> yes.. see 22775b5f1d9c6d9860a579245bf7a48a982ab62f
Aug 20 20:29:56 <rburton> i'll dig tomorrow, time to watch breaking bad
Aug 20 20:30:07 <rburton> thanks JaMa
Aug 20 20:30:14 <JaMa> yw
Aug 20 21:20:04 <bizhanMona> Hey all, is there a link on internet I can go and check for supported packages on yocto ? specially for X11 support?
Aug 20 21:24:07 <kergoth> depends on what you mean by supported
Aug 20 21:25:18 <bizhanMona> kergoth: x11 or xorg packages?
Aug 20 21:28:20 <kergoth> i didn't say 'what you mean by packages'
Aug 20 21:29:04 <bizhanMona> kergoth: could we run X11 on Yocto target system?
Aug 20 21:30:58 <AdityaGandhi> Hey guys, has anyone got the qte toolchain for intel platforms working?
Aug 20 21:32:50 <AdityaGandhi> I get an error when I run qmake, says permission denied, I have check chmod 777, and ownership is root:root
Aug 20 21:33:13 <AdityaGandhi> I tried sudo, etc after installing the toolchain that was built by bitbake
Aug 20 21:36:44 <bluelightning> bizhanMona: yes
Aug 20 21:38:11 <RP> bizhanMona: What you probably want to do is see whether recipes (.bb files) exist for the software you want to build. You can do that by looking in the core and various layers
Aug 20 21:41:43 <rburton> bizhanMona: the easiest way to browse that it the git interface. https://github.com/openembedded/oe-core/tree/master/meta is oe-core, and meta-oe has a lot more
Aug 20 21:43:26 <bizhanMona> Thanks for info. That helps alot
Aug 20 21:48:24 <m1565>  
Aug 20 22:42:04 <chackal_sjc> guys, how to add a sym link in a recipe?
Aug 20 23:00:19 <AdityaGandhi> I have a problem using a keyboard on crownbay platform with qt demo image
Aug 20 23:00:26 <AdityaGandhi> Any Ideas how to resolve this?
Aug 20 23:09:27 <kergoth> chackal_sjc: huh?
Aug 20 23:09:40 <kergoth> chackal_sjc: you create symlinks the way you create symlinks anywhere else. ln -s.
Aug 21 00:02:47 <seebs> ...
Aug 21 00:02:48 <seebs>   PSEUDO_COMMAND="$native_sysroot/usr/bin/pseudo"
Aug 21 00:02:49 <seebs>   PSEUDO_OPTS="-P $natvie_sysroot/usr"
Aug 21 00:02:49 <seebs>   TAR_OPTS="-xjf"
Aug 21 00:02:51 <seebs>   PSEUDO_OPTS="-P $native_sysroot/usr"
Aug 21 00:03:07 <seebs> o/" one of these things, is not like the other ones, one of these things just doesn't belong o/"
Aug 21 00:08:42 <jkprg> hi. is it true master branch of poky doesn't support armv7 arch? Thx
Aug 21 00:26:52 <Crofton> poky is built on oe-core, and oe-core supports armv7 fine
Aug 21 00:27:01 <Crofton> so I would assume poky does
**** ENDING LOGGING AT Tue Aug 21 02:59:58 2012

**** BEGIN LOGGING AT Tue Aug 21 02:59:58 2012
Aug 21 07:49:51 <bluelightning> morning all
Aug 21 07:52:25 <JaMa> morning
Aug 21 07:54:48 <halstead> Good morning to you.
Aug 21 08:01:40 <JaMa> hmm even with -v -v -D I cannot find where https://bugzilla.yoctoproject.org/show_bug.cgi?id=2977 actually fails :/
Aug 21 08:09:15 <JaMa> ah The file you are trying to attach is 2655 kilobytes (KB) in size. Attachments cannot be more than 1000 KB.
Aug 21 08:12:06 <bluelightning> JaMa: the easiest way would be to fix the error handling code so that the error is not masked
Aug 21 08:12:28 <JaMa> true
Aug 21 08:14:04 <JaMa> now I know at least which layer was causing that.. so I'll return to my daywork and let you guys fix error handling code
Aug 21 08:14:04 <bluelightning> unfortunately it sounds like this issue might be at least partially my fault, I think I wrote that code...
Aug 21 08:14:36 <bluelightning> JaMa: which layer was it?
Aug 21 08:15:19 <JaMa> meta-handheld or meta-webos, trying to add them back 1 by 1
Aug 21 08:15:33 <JaMa> ok meta-webos
Aug 21 08:17:29 <bluelightning> hmm, let me try that here...
Aug 21 08:18:34 <bluelightning> JaMa: do you mean khem's meta-woce or some other layer?
Aug 21 08:20:01 <JaMa> no something else but that is private..
Aug 21 08:23:12 <bluelightning> JaMa: ok, bit hard for me to test that then...
Aug 21 08:24:29 <bluelightning> if you can narrow down what it is that that layer is doing so that I can reproduce it here that would be a big help
Aug 21 09:35:43 <pirut> hi, where can I change teh keyboard layout on a minimal image ?
Aug 21 13:24:34 <peachj> Is there a relatively simple way to list all the actual SRCREVs used in a given build, including having all AUTOREV references resolved?
Aug 21 13:26:42 <JaMa> peachj: yes, read cache/bb_persist_data.sqlite3
Aug 21 13:35:37 <peachj> Looking at the file, it seems there's a lot of good data in there, but I just tried building a package I have from a git repo, and I can't find any data about that package.
Aug 21 13:35:59 <peachj> Any thoughts about why that would happen?  I saw the do_fetch task execute and everything...
Aug 21 13:44:41 <xxiao> "development using yocto project directly", cd <S> && sh && vi myfile.c && exit && bitbake -c compile -f
Aug 21 13:44:48 <xxiao> why do I need that sh and exit pair?
Aug 21 13:46:51 <Zagor> xxiao: you don't. it rather looks like a pushd/popd replacement
Aug 21 13:47:25 <Zagor> except the cd and sh are the wrong order
Aug 21 13:47:41 <Zagor> where did you get that?
Aug 21 13:48:08 <xxiao> http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html
Aug 21 13:48:12 <xxiao> chapter 5.1.4
Aug 21 13:48:38 <Zagor> right, that has sh before cd so it's just a pushd/popd replacement
Aug 21 13:48:46 <xxiao> i c, thanks
Aug 21 13:49:02 <xxiao> i do use pushd/popd
Aug 21 13:49:34 <Zagor> at least I can't think of any other reason to do like that
Aug 21 13:50:15 <xxiao> maybe not all shells have pushd/popd, i have no idea
Aug 21 13:50:44 <xxiao> even then you don't normally need sh, just cd should be fine
Aug 21 13:57:30 <xxiao> can I modify yocto rootfs/SDK offline, something like opkg-target?
Aug 21 13:57:59 <xxiao> hope rpm inclusion did not ruin the best part of openembedded
Aug 21 14:04:09 <kergoth> cd foo; cd -; usually works as an alternative to pushd/popd. oe classic used to provide compatibility implementations of pushd/popd/dirs for shells that didn't have them, also, but i don't think that ever went into oe-core.f or the curious, see http://git.openembedded.org/openembedded/tree/classes/utils.bbclass#n450
Aug 21 14:04:14 * kergoth yawns and stretches
Aug 21 14:05:04 * kergoth wanders off in search of food
Aug 21 14:32:37 <mebrown> Ok, so after struggling for this for a couple of days, i need help. I would like to modify the kernel recipe to use an already-checked-out git repository and stop switching/creating branches.
Aug 21 14:33:38 <mebrown> I have stubbed out do_fetch, do_unpack, do_validate_branches, and do_kernel_checkout
Aug 21 14:33:49 <mebrown> but it looks like something in do_patch is switching branches around on me
Aug 21 14:34:16 <mebrown> but if I stub it out, it wont build
Aug 21 14:34:31 <bluelightning> this might be a situation where externalsrc.bbclass is useful
Aug 21 14:34:52 <mebrown> I'm using externalsrc extensively in my other recipes
Aug 21 14:35:09 <mebrown> I haven't been able to get it to work with the kernel recipe
Aug 21 14:35:11 <kergoth> is this actually a yocto kernel tree? if not, i'd avoid linux-yocto, and thereby sidestep the branch juggling it does
Aug 21 14:35:15 <mebrown> yes
Aug 21 14:35:34 <mebrown> I've made a local clone of the yocto linux tree
Aug 21 14:35:42 <bluelightning> zeddii: you might be able to help here ^^
Aug 21 14:36:07 <mebrown> i'm using the android 'repo' tool to stitch together all our active git repos into one big tree
Aug 21 14:36:18 <mebrown> and use externalsrc
Aug 21 14:36:31 <mebrown> the branch switching in the kernel recipe is messing up the workflow
Aug 21 14:37:35 <mebrown> I'm trying to go as stock-yocto as possible, but I have to use the 'repo' tool and need to use the same workflow for the kernel that we are using for all our other components
Aug 21 14:38:01 <kergoth> ah, interesting
Aug 21 14:38:21 <mebrown> basically, I need the linux-yocto recipe to trust me and use HEAD
Aug 21 14:38:27 <mebrown> and not switch between branches
Aug 21 14:38:59 <mebrown> and I just discovered the 'meta' branch, and have no clue what that's doing
Aug 21 14:39:22 <mebrown> so what started off as "this should be relatively simple" is turning into a huge monster for me
Aug 21 14:45:41 <zeddii> mebrown, you don't really want linux-yocto then.
Aug 21 14:46:20 <zeddii> maybe linux-yocto custom if you want some config fragments, but the branch switching is part of validating the tree, so it can't be disabled.
Aug 21 14:58:07 <mebrown> zeddii, are there any guidelines for writing your own kernel recipe?
Aug 21 14:59:30 <pidge> YPTT: Present.
Aug 21 14:59:34 <zeddii> I'd say it's more examples, i.e. oe-class, meta-*, etc, etc. and obviously what is covered in the oe-core/poky/yocto docs about the kernel.bbclass, etc.
Aug 21 14:59:44 <zeddii> mebrown, but it all depends on what you are really trying to do.
Aug 21 15:00:33 <Song_liu> YPTM: Hello all, let's get the Yocto Project technical team meeting rolling now. Please let me know who's on the bridge.
Aug 21 15:00:42 * sgw YPTM: Saul's here
Aug 21 15:00:45 <RP> YPTM: Song_liu: I'm here...
Aug 21 15:00:51 <denix> is it time?
Aug 21 15:00:51 <mebrown> zeddii, what I am really trying to do is work within the workflow I already have set up and working for ~120 projects.
Aug 21 15:00:55 <strassek> YPTM: Kevin Strasser is here
Aug 21 15:00:57 <denix> YPTM: here
Aug 21 15:01:03 <halstead> YPTM: Michael Halstead here
Aug 21 15:01:04 <pidge> YPTM: Song_Lui: I'm one
Aug 21 15:01:13 <Jefro> YPTM Jefro is here
Aug 21 15:01:15 <bogdanm> YPTM: Bogdan is here
Aug 21 15:01:23 <zeddii> mebrown. sure, but I have no idea what that is at the moment :)
Aug 21 15:01:36 <mebrown> zeddii, yes. I'll explain... sec
Aug 21 15:01:36 <Guest28386> YPTM: Tom Zanussi here
Aug 21 15:01:44 <jmpdelos> YPTM: Jeff Polk here
Aug 21 15:01:55 <zeddii> YPTM: bruce ashfield here.
Aug 21 15:02:02 <davest> YPTM: davest here
Aug 21 15:02:08 <kergoth> YPTM: Chris Larson from Mentor here
Aug 21 15:02:10 <rburton> YPTM: ross here
Aug 21 15:02:27 <mebrown> YPTM: Michael Brown (Dell) here
Aug 21 15:03:17 <zeddii> mebrown, I put in inhibits for externalsrc, but if that is used, it really does assume that you've set everything up and have controlled everything possible. but BSPs are going to do merges, etc, depending on what they've have in their meta data.  the repo needs to be staged the same way that the inhibited phases would have done.
Aug 21 15:03:27 <mebrown> zeddii, I have a process where developers submit topic branches. Those branches are test merged by a jenkins job and built. After build and BVT, they are merged with master.
Aug 21 15:03:53 <Song_liu> YPTM: any opens, folks?
Aug 21 15:04:06 <bogdanm> YPTM: no opens
Aug 21 15:04:13 <bluelightning> YPTM: Paul and Belen are here
Aug 21 15:04:13 <davest> YPTM: no opens
Aug 21 15:04:28 <mebrown> zeddii, so what i'm trying to accomplish is to let my jenkins job set up the branch and do the merges it needs to do and not have the job clobber it
Aug 21 15:04:29 <Jefro> YPTM very quick announcement about LinuxCon next week
Aug 21 15:04:37 <pidge> YPTM: minor upcoming autobuilder changes.
Aug 21 15:05:00 <adamian> No opens
Aug 21 15:05:08 <Song_liu> YPTM: sorry, I dropped, calling in again
Aug 21 15:07:12 <zeddii> mebrown, yep. I understand, and there are plenty of workflow collisions there. are you trying to work against yocto master ? I can re-test externalsrc support, but there would still be some custom steps you'd need at front.
Aug 21 15:07:28 <mebrown> zeddii, I think that would work
Aug 21 15:07:44 <mebrown> zeddii, I just need to know specifically what I have to do to prep my tree
Aug 21 15:07:51 <zeddii> let me fire off a few things. I can test the building blocks, and let you know what setup is required up front.
Aug 21 15:07:52 <mebrown> zeddii, I want to track yocto as much as possible
Aug 21 15:08:12 <zeddii> ok. we'll figure something out that doesn't make my life, or yours, miserable ;)
Aug 21 15:08:18 <darknighte> Song_liu: YPTM: just joined the call
Aug 21 15:09:03 <zeddii> there may be some bitrot, so I need to test.
Aug 21 15:17:09 <mebrown> zeddii, sorry, I did misspeak. I said we are using yocto master when in fact I am on denzil currently. Depending on the release schedule for master, I should be able to switch over to master.
Aug 21 15:17:44 <mebrown> Actually, our release is far enough out that I am pretty confident I can switch to master
Aug 21 15:18:56 <zeddii> ok. for my first test, either is fine. I need to calm the system down with respect to SRCREVs anyway :)
Aug 21 15:23:44 <dvhart> khem, how's this: http://pastebin.com/SQbg20FW
Aug 21 15:26:54 <Song_liu> dvhart: are you on the call?
Aug 21 15:27:04 <dvhart> yes
Aug 21 15:29:27 <Jefro> BoF
Aug 21 15:33:44 * zeddii just received a NMI and must drop the call.
Aug 21 15:40:08 <RP> halstead: all sounds great, thanks!
Aug 21 15:40:29 <halstead> Thank you RP.
Aug 21 15:40:58 <RP> halstead: I like the idea of the tap device monitoring too :)
Aug 21 15:44:19 <Song_liu> YPTM: thank you all for joining the meeting. You all have a nice day/evening!
Aug 21 15:46:13 <kergoth> RP: so, I was talking with sean hudson, and we were thinking about having the oe-core wrapper reproduce bitbake's internal 'search up from $PWD to / to find conf/bblayers.conf' logic, to find and auto-set BUILDDIR. to try to get back our original goal of not having to set any env vars other than PATH. thoughts on that? I bet it wouldn't be all that difficult to implement
Aug 21 15:46:26 * kergoth ponders
Aug 21 15:46:51 <fray> doesn't that assume that bitbake then is a subdirectory of meta?
Aug 21 15:47:02 <fray> it is not in our product
Aug 21 15:47:07 <RP> kergoth: The more I think about it, the more I hate that wrapper
Aug 21 15:47:22 <kergoth> agreed
Aug 21 15:47:23 <bluelightning> we're using it as a crutch in a lot of cases
Aug 21 15:47:24 <fray> the other purpose of the wrapper is the two stage build..  which I'd really like to get -out- of the wrapper
Aug 21 15:47:52 <fray> we really need a way to stage the builds..  "build this" ohh when that recipe builds, it triggers a re-exec of bitbake..  start over and continue
Aug 21 15:47:58 <kergoth> heh
Aug 21 15:48:05 <RP> kergoth: It was originally meant for one thing. Then people added X, Y and Z to it :(
Aug 21 15:48:05 <kergoth> collections.inc did that, and it was pretty disgusting
Aug 21 15:48:11 <kergoth> (the bitbake re-exec, that is)
Aug 21 15:48:34 <fray> he re-exec is needed though for pseudo
Aug 21 15:48:50 <RP> fray: how could I forget
Aug 21 15:48:51 <fray> to get the best performance, the pseudo needs to be loaded as part of the bitbake process and not "after"
Aug 21 15:49:20 <kergoth> I rather like oe-lite's "oe" script, i wonder if we couldn't do something like that at some point
Aug 21 15:49:57 <kergoth> at any rate, just seems silly to have to set BUILDDIR when bitbake itself is able to find the proper place based on context (read: $PWD) :)
Aug 21 15:50:01 <bluelightning> kergoth: what does it do (for those who haven't seen it?)
Aug 21 15:50:12 <kergoth> bluelightning: http://oe-lite.org/redmine/projects/oe-lite/wiki/Quick_Start_Guide_to_Build_a_RootFS#Preparing-the-Build
Aug 21 15:50:38 <kergoth> has subcommands to clone, update layers, do builds, show metadata, etc. sort of a higher level wrapper around the build process
Aug 21 15:50:39 <fray> kergoth, if the assumption is BUILDDIR is the pwd, I'm ok with that..
Aug 21 15:51:14 <kergoth> fray: bitbake lets you run your builds from anywhere *under* BUILDDIR. that'd be the goal
Aug 21 15:51:27 <RP> kergoth: The other idea I wondered about was to exec() the runqueue master
Aug 21 15:51:39 <RP> kergoth: then it would be possible to re-exec it
Aug 21 15:51:51 <kergoth> hmm, indeed
Aug 21 15:52:02 <RP> kergoth: or have pools of workers, some with pseudo, some without
Aug 21 15:52:26 <fray> RP, I thought you said the pool idea had been tried in the past and the message passing was too slow
Aug 21 15:52:47 <RP> fray: we tried exec() instead of fork()
Aug 21 15:52:58 <RP> fray: we've not done execution from a pool
Aug 21 15:53:36 <fray> Hmm, I thought I had suggested that back when we first talked about pseudo and the re-exec case.. anyway
Aug 21 15:53:48 <RP> perhaps we don't need the pool, perhaps we just have a master child worker we exec and then fork other processes from it
Aug 21 15:53:56 <jwessel> Does that mean you pay the > 6 cpu second startup cost to read the cache for getting a runqueue up and running?
Aug 21 15:54:09 <zenlinux> runqemu with master of last night is acting funny - trying to start a vnc server?
Aug 21 15:54:29 <RP> jwessel: there would be some cost, probably not six seconds
Aug 21 15:54:36 <zenlinux> that's normally something associated with the sanity tests, and nothing in the runqemu scripts refers to vnc
Aug 21 15:54:37 <RP> jwessel: and it would be a one time cost
Aug 21 15:54:50 <jwessel> I am asking about the way it currently is.
Aug 21 15:55:06 <jwessel> Because if you fork() today and just exec a runqueue you would already have the cache in core.
Aug 21 15:55:27 <jwessel> The only cost is the vm activation, which is cheap.
Aug 21 15:55:28 <bluelightning> zenlinux: there's a command line option in qemu for that, maybe that is being specified?
Aug 21 15:55:29 <RP> jwessel: right, that is why we fork() today
Aug 21 15:55:35 <fray> ya.. thats the conversation I remember "back before" was the startup cost was bad due to the cache/message passing activities..
Aug 21 15:55:41 <fray> which is why we went ot the two stage build
Aug 21 15:56:27 <jwessel> and hopefully today we are smart about the fork/exec combos and use use vfork() where you don't pay for the vm image activation :-)
Aug 21 15:56:33 <jwessel> I have never looked at any of that code.
Aug 21 15:56:40 <zenlinux> bluelightning, doesn't look like it
Aug 21 15:56:48 <zenlinux> I see we just disabled gl passthrough with qemu
Aug 21 15:56:53 <RP> jwessel: its whatever python os.fork() does
Aug 21 15:56:55 <zenlinux> I wonder if that has something to do with it
Aug 21 15:57:30 <fray> RP/jwessel last time I looked at python it had a "smart" fork, and didn't just blindly call into libc's fork
Aug 21 15:57:43 * RP suspects it does the right thing
Aug 21 15:57:46 <fray> it tried to do the more efficient thing, based on what it was being asked to do
Aug 21 15:59:00 <RP> I can picture how we could make this work and keep it pretty fast...
Aug 21 15:59:17 <RP> I wish I had time to sit and code it
Aug 21 15:59:28 * RP likes code like that
Aug 21 16:00:55 <bluelightning> what's the purpose of BBINCLUDED ?
Aug 21 16:01:11 <bluelightning> I see it is set in two places, I can't see it being referred to anywhere else though
Aug 21 16:02:02 <RP> bluelightning: where is it used?
Aug 21 16:03:26 <bluelightning> it isn't read anywhere... it gets set in cooker within parseConfigurationFiles() and in ast at the end of finalize()
Aug 21 16:03:59 <fray> what value does it get?
Aug 21 16:04:03 <jwessel> kergoth: What about adding a API to query the original ENV?
Aug 21 16:04:21 <jwessel> It was really easy to add because it was created, but thrown away along the way.
Aug 21 16:04:29 <fray> jwessel I thought that was already there -- or maybe it's internal to bitbake?
Aug 21 16:05:03 <jwessel> I did this a while ago so I could ask for the value of something to use in a do_... function.
Aug 21 16:05:33 <jwessel> Certainly I can understand why the API doesn't exist, so as to prevent folks from contaminating things,
Aug 21 16:05:41 <fray> bluelightning:
Aug 21 16:05:43 <fray>     bitbake: Added BBINCLUDED variable.
Aug 21 16:05:43 <fray>     
Aug 21 16:05:43 <fray>     Added new variable BBINCLUDED indicating the file dependency
Aug 21 16:05:43 <fray>     information. It exposes the internal variable '__base_depends' and
Aug 21 16:05:43 <fray>     '__depends'.
Aug 21 16:05:49 <jwessel> But for a specific purpose like what is the value of "M=..."
Aug 21 16:06:09 <fray> thats the commit message for that item.. looks like a useful debug item, and perhaps something that can be used by bbclasses to track and identify dependency information
Aug 21 16:06:15 <bluelightning> fray: ah yes, a git blame might have helped...
Aug 21 16:06:54 <bluelightning> FYI, I ask because it appears to be the only variable left that is causing hob to invalidate the cache when using the same config as the command line (see bug #2680 filed by jwessel)
Aug 21 16:07:25 <fray> sounds to me like it should be something that is "ignored" because it's simply a diagnostic variable
Aug 21 16:07:27 <jwessel> bluelightning: I wrote the bug because I couldn't figure out what it was for either :-)
Aug 21 16:07:47 <fray> my reading is it's purely diagnostic for event driver classes...
Aug 21 16:12:10 <bluelightning> jwessel: for the environment question, could you not just add the variable to BB_ENV_EXTRAWHITE so that it comes through into the bitbake environment?
Aug 21 16:12:19 <bluelightning> that's the way we typically handle such things
Aug 21 16:13:17 <jwessel> bluelightning: But I don't want to contaminate other processes.
Aug 21 16:13:33 <jwessel> Exporting random variables is not a great idea.
Aug 21 16:14:07 <jwessel> This was a specific case of course where the value of M=... was passed to a specific task to compile an external kernel module.
Aug 21 16:14:49 <bluelightning> I'm not sure I feel great about being able to influence the build externally in that way full stop, to be honest...
Aug 21 16:14:56 <jwessel> like:  M=/tmp/external_module bitbake -c external_modules linux
Aug 21 16:15:16 <jwessel> bluelightning: I didn't say it was good or bad, just that I understand why it probably isn't there.
Aug 21 16:15:41 <kergoth> bluelightning: I'm not a big fan of use of env vars to control the build at all — after all, you can easily emit to auto.conf instead
Aug 21 16:15:42 <kergoth> heh
Aug 21 16:17:02 <jwessel> My other option was to write something into a file and read it on the other side of bitbake.   We simply don't have an easy control mechanism that doesn't make you re-parse if you just want to run a one off task.
Aug 21 16:17:47 <zenlinux> I reverted the qemugl changes, rebuilt qemu, and it works now
Aug 21 16:17:50 <zenlinux> will report to the ML
Aug 21 16:21:01 <RP> jwessel: the original environment is stored away in cooker
Aug 21 16:21:17 <jwessel> RP: Correct, but there is no API to get at it.
Aug 21 16:21:17 <RP> jwessel: Its never been exposed API
Aug 21 16:21:29 <jwessel> I had to make one to exec a query.
Aug 21 16:22:47 <jwessel> I can completely understand why it doesn't exist, because you don't want the causal user to read a variable that can influence a build to generate two different things with the same top level sum.
Aug 21 16:23:45 <jwessel> That was not what I was using it for however.  I was just using it in such a way to get my sysroot and dependencies automatically for building an external package.
Aug 21 16:24:07 <jwessel> If the sysroot actually worked for direct external module this might also be a moot point.
Aug 21 16:25:32 <jwessel> At the moment we have the classic trading one evil for another type problem.  And I am not sure it is warranted to expose the original environment for this specific problem.
Aug 21 16:28:34 <khem> dvhart: looks good
Aug 21 16:28:42 <dvhart> ack, sending
Aug 21 16:48:20 <thaytan> I want to build the meta-ti layer, but I'm not sure which version of poky, if any, I can use it with
Aug 21 16:48:32 <thaytan> I'm getting "This recipe does not have the LICENSE field set' errors
Aug 21 16:48:55 <denix> thaytan: which recipe?
Aug 21 16:49:22 <thaytan> cloud9-gnome-image, cloud9-gfx-image, ti-hw-bringup-image, cloud9-image
Aug 21 16:49:44 <thaytan> then it bombs out with a python exceptiion in cooker.py
Aug 21 16:51:41 <denix> thaytan: BBMASK = "meta-ti/recipes-misc"
Aug 21 16:52:16 <bluelightning> denix: btw, shouldn't you be using "require" instead of "include" in those images?
Aug 21 16:52:21 <denix> there is a README file there
Aug 21 16:52:53 <denix> bluelightning: have you looked at them?
Aug 21 16:52:59 <bluelightning> denix: I just did yes
Aug 21 16:53:20 <thaytan> denix: I saw the BBMASK in the README, I just didn't realise it applied to these errors
Aug 21 16:53:52 <bluelightning> denix: clearly they cannot work without the included file, so it should be a require
Aug 21 16:54:32 <denix> bluelightning: it requires local files and includes files from other layers
Aug 21 16:54:43 <denix> what really kills them is inherit systemd
Aug 21 16:55:09 <bluelightning> denix: I see that, but it should still be require - if one of those files vanishes even with the layers enabled, don't you want to get an error?
Aug 21 16:55:40 <sgw> thaytan: how are things going?
Aug 21 16:55:46 <bluelightning> or at least, an error better than that LICENSE is not set...
Aug 21 16:57:00 <thaytan> sgw: making progress
Aug 21 16:57:15 <thaytan> wondering if I'll get enough done before I hop back on a plane on Sunday to head to San Diego
Aug 21 16:57:22 <denix> bluelightning: well, the original point was to enable building of meta-ti when meta-angstrom is not in the stack, hence the change from require to include
Aug 21 16:57:55 <denix> bluelightning: since then the missing LICENSE started breaking the build, so it doesn't matter anymore :)
Aug 21 16:58:10 <denix> btw, the missing LICENSE is just a side-effect...
Aug 21 16:58:28 <bluelightning> yes, I get that
Aug 21 16:59:40 <thaytan> denix: working much better now, thank you
Aug 21 16:59:54 <sgw> thaytan: I know the feeling, but I won't be on a plane to SD, you might see RP or davest there.
Aug 21 17:00:20 <denix> thaytan: NP
Aug 21 17:01:49 <thaytan> sgw: ah, but how to recognise them
Aug 21 17:02:10 <sgw> thaytan: go to the talk or BOF!
Aug 21 17:02:39 <thaytan> sgw: aha! I suppose I should at least look at the Linuxcon schedule before I arrive
Aug 21 17:02:49 <thaytan> I'm too focussed on my talk @ the GStreamer conf on tuesday :)
Aug 21 17:18:20 <bluelightning> thaytan: http://www.flickr.com/photos/denix0/5701589991/
Aug 21 17:19:23 <denix> heh :)
Aug 21 17:19:32 <chackal_sjc> how to force a package to go all through the entire process again?
Aug 21 17:19:40 <chackal_sjc> just cleanall before?
Aug 21 17:19:50 <bluelightning> denix: oddly enough I googled for that, thanks for posting it ;)
Aug 21 17:20:36 <bluelightning> chackal_sjc: if you want to test the entire process, yes that will do it
Aug 21 17:22:53 <chackal_sjc> bluelightning: is there any short cuts to fetch -> go to all process to package ?
Aug 21 17:23:18 <bluelightning> chackal_sjc: -c cleansstate will preserve the fetched file and throw out everything else
Aug 21 17:23:45 <bluelightning> chackal_sjc: -c command -f will force a specific task to rerun e.g. -c compile -f
Aug 21 17:23:53 <chackal_sjc> yes
Aug 21 17:24:08 <bluelightning> although -f may only be completely reliable with master
Aug 21 18:33:26 <seebs> Heads up, I have submitted a proposed patch that would move pseudo state directories for exported filesystems around, there are Sound Technical Reasons for this, but it's possible that I didn't find all the places.
Aug 21 18:35:41 <fray> Jessica needs to look at this..
Aug 21 18:42:02 <mranostay> howdy hollisb
Aug 21 18:42:10 <hollisb> mranostay: hey
Aug 21 18:48:31 <awsation> Does anyone know if there exists a recipe for unixODBC
Aug 21 19:16:11 <seebs> noooooooo
Aug 21 19:16:31 <seebs> I just discovered that */pseudo/pseudo.log is FULL of stuff indicating that things are getting screwed up.
Aug 21 19:16:41 <seebs> And it's probably working out right 99.9% of the time.
Aug 21 19:16:51 <kergoth> heh, oops
Aug 21 19:16:56 <seebs> But there are diagnostics here showing that we are creating database misalignments which COULD result in crazy stuff.
Aug 21 19:17:22 <seebs> Problem is, there's a ton of phases and operations that are probably being run outside of pseudo for performance, but which are in some cases moving or renaming directories containing stuff pseudo knew about.
Aug 21 19:18:04 <seebs> Okay, quick sanity check: How would people feel about something in the qa checks for files which reports on number/kind of pseudo diagnostics or warnings?
Aug 21 19:18:59 <seebs> Not a fatal error, obviously, but... This is an actual serious problem, I think. That I need to look into at some length. Because some of these indicate stuff Actually Wrong.
Aug 21 19:42:59 <RP> seebs: I would love a "don't care about stuff outside directory X" option for pseudo
Aug 21 19:43:14 <seebs> Me too. :)
Aug 21 19:43:17 <RP> seebs: There are likely things we do change from under pseudo that it notices but we don't care about
Aug 21 19:43:52 <RP> seebs: I know where we'd care or not by path
Aug 21 19:44:02 <RP> kergoth: Got a second?
Aug 21 19:44:18 <seebs> What's killing us (VERY rarely -- we only see it 'cuz we have ludicrous numbers of test builds and then run them and mess about with them) is cases where, say, pseudo determines that it's never heard of a file before, but wait, there's something with that inode, and ends up reporting 0644 for an executable.
Aug 21 19:45:12 <RP> seebs: need more data with paths
Aug 21 19:45:39 <RP> kergoth: Wondering about our methodpool, again. http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t1&id=b685de0bea543b39acaefb16860467a0de364899
Aug 21 19:45:46 <seebs> Yeah. I am actually really bothered by that -- the "no path" stuff is VERY rare in our old build system, but relatively common in Yocto, and I'm not sure why yet.
Aug 21 19:45:53 <seebs> I need like a month or two to work on this.
Aug 21 19:46:43 <RP> seebs: The reason why is you run your whole build under it. We have multiple pseudo contexts
Aug 21 19:46:44 <fray> we're doing something like 100+ test builds a day (automated)
Aug 21 19:47:34 <RP> seebs: We use it to care about specific directories but it still tracks things outside those directories which we don't care about. We can and will change those directories outside of pseudo's knowledge
Aug 21 19:47:58 <seebs> No, it's not that. LDAT switched to per-package pseudo contexts, and the errors I'm seeing are all within a given package directory.
Aug 21 19:48:13 <RP> seebs: hmm, that is bad then :(
Aug 21 19:48:16 <seebs> Yeah.
Aug 21 19:48:22 <RP> seebs: sstate involved?
Aug 21 19:48:27 <seebs> I don't *think* so.
Aug 21 19:48:32 <seebs> Although actually. It might well be.
Aug 21 19:48:34 <seebs> Hmmmm.,
Aug 21 19:48:47 <seebs> Well, I don't know. I'll have to look more. Sometime when I have a TON of time.
Aug 21 19:49:08 <seebs> But yeah, the per-package contexts change was... well, I was terrified of it, but I did it and I had NO problems. I was stunned. :)
Aug 21 19:49:27 <seebs> Trivia point: The reason LDAT went to per-package contexts was actually logging performance.
Aug 21 19:50:07 <seebs> We had a mode where we'd run pseudo with logging on to check for host contamination, and a log of every single filesystem access (not reads/writes, just pseudo-level stuff) for an entire build would produce these 18GB+ log databases...
Aug 21 19:50:22 <RP> seebs: I can imagine ;-)
Aug 21 19:53:56 <seebs> I am totally gonna do a kickstarter for pseudo updates. "$100 donor level: I will tell you your problem is user error. $250 donor level: I will listen to your description of your problem, then tell you it's user error.  $1000 donor level: I will actually look at your problem."
Aug 21 19:54:06 * fray notes bitbake-devel seems to slow "again"..
Aug 21 19:54:19 <fray> sent a patch, and I haven't gotten it back yet nor is it in the archvies yet
Aug 21 20:02:36 <mebrown> zeddii,
Aug 21 20:02:47 <mebrown> zeddii, blah, hit enter in the wrong term
Aug 21 20:03:15 <mebrown> zeddii, trying to work through this on my own, but it just isn't quite working for me. any pointers welcome
Aug 21 20:04:42 <zeddii> mebrown, I have to head out to pickup some kids before they get tossed out on the street, but I have a bbappend, that gets me into the build with externalsrc here.
Aug 21 20:05:15 <mebrown> can you email it?
Aug 21 20:05:21 <zeddii> if you drop me an email (bruce.ashfield@windriver.com), I can write something up for you whnen I get back to a keyboard.
Aug 21 20:05:49 <mebrown> mail sent
Aug 21 20:05:58 <mebrown> can you pastebin the bbappend?
Aug 21 20:07:20 <zeddii> without a description, it won't do you much good, and I'm 10 mins late already (I was fighting with unionfs). sorry.
Aug 21 20:07:34 <mebrown> ok. thanks
Aug 21 21:02:50 <ag_> Hello guys.
Aug 21 21:03:22 <ag_> libgudev is installed in /lib and needs libraries from /usr
Aug 21 21:03:57 <ag_> The needed libraries are: libgobject libgthread libffi libglib
Aug 21 21:04:32 <ag_> So QA warnings are present in this case.
Aug 21 21:05:50 <ag_> Any objection on moving libgudev to /usr?
Aug 21 21:06:23 <ag_> objections*
Aug 21 21:41:58 <khem> I am now seeing contains probably-redundant RPATH /usr/lib/../lib
Aug 21 21:42:04 <sgw> ag_: I would ask why is installed in /lib to start with?  Is it used by something early in startup?
Aug 21 21:42:14 <khem> there was a patch to squash such uses
Aug 21 21:42:17 <khem> has that been merged
Aug 21 21:45:41 <sgw> khem: Yes we are all seeing it, RP is waiting for a libtool patch, not sure why he pulled the insane check patch in first, quick work around is to using INSANE_SKIP_gettext = "useless-rpaths"
Aug 21 21:46:30 <sgw> sorry INSANE_SKIP_libgettextlib = "useless-rpaths
Aug 21 21:48:42 <khem> yeah thanks I will use this workaround meanwhile
Aug 21 21:49:12 <khem> I wonder if there are more packages which will fail in same manner
Aug 21 21:49:46 <sgw> libgettextextsrc also needs it
Aug 21 21:49:58 <sgw> other than that, I have not seen any more on the AB
Aug 21 21:54:11 <khem> OK, I have more layers
Aug 21 21:59:53 <seebs> Well, to be fair, it certainly seems to me that such an RPATH is a sign that Something Is Wrong.
Aug 21 22:04:53 <RP> sgw: I'd not realised we had this issue :(
**** ENDING LOGGING AT Wed Aug 22 03:00:00 2012

**** BEGIN LOGGING AT Wed Aug 22 03:00:00 2012
Aug 22 05:28:43 <moolinex> morning
Aug 22 06:40:20 <RP> morning all
Aug 22 08:13:20 <bluelightning> morning all
Aug 22 10:18:41 <rburton> RP: still waiting a libtool patch to fix the insane rpath warnings in gettext?
Aug 22 10:57:14 <RP> rburton: yes. I shouldn't have merged that test :/
Aug 22 13:01:23 <peachj> So, I asked this yesterday and never got a full answer.  I'm trying to find all SRCREVs used in my build.  I'm looking in tmp/cache/bb_persist_data.sqlite3.  I don't see data for every package that's using SRCREV in there.  Any idea why that might happen?
Aug 22 13:02:25 <bluelightning> peachj: I suspect that you will only get entries in that db for recipes that use SRCPV
Aug 22 13:40:56 <peachj> Okay, after much experimenting, you appear to be correct.  I have to use SRCPV in some variable that goes into the has, I guess?  That seems to make it show up.
Aug 22 13:41:22 <peachj> That means I still don't have a for-sure way to see all SRCREVs
Aug 22 13:41:28 <peachj> Any other thoughts?
Aug 22 13:55:46 <bluelightning> peachj: there are a bunch of places you could hook into the system and write it out
Aug 22 13:56:05 <bluelightning> peachj: I wonder though if we should be saving it as part of buildhistory perhaps
Aug 22 13:57:15 <peachj> It may well be helpful.  I'm looking for it for build reproducibility.
Aug 22 14:02:59 <kergoth> heh, i've been having to deal with a slightly related issue for our product. we want the customer to be able to build without a network, which is why we ship our DL_DIR, but that doesn't prevent all network contact due to AUTOREV or non-hashes in SRCREV. looking for a way to impose a lockdown on that at release time. possibly by capturing the persist_data at release time, injecting it at runtime, then changing the srcrev policy to
Aug 22 14:02:59 <kergoth>  cache. haven't decided on a good route yet
Aug 22 14:04:11 <RP> kergoth: sounds like a similar problem to the PR lockdown we need with the PR service
Aug 22 14:06:06 * kergoth nods
Aug 22 14:06:40 <kergoth> for now we're punting and manually locking down srcrevs, but obviously that's not ideal for day to day development
Aug 22 14:06:41 <kergoth> heh
Aug 22 14:09:06 <bluelightning> peachj: hmm, so buildhistory won't really help here actually because it only considers stuff that goes onto the target
Aug 22 14:09:13 * kergoth yawns
Aug 22 14:10:35 <peachj> We considered not allowing the use of AUTOREV (don't care about the tagging issue, at least not yet, I don't think)
Aug 22 14:10:42 <peachj> But, as stated, that's not idea
Aug 22 14:11:03 <peachj> I really don't like disabling a useful feature for my dev community just because it makes it harder to rerproduce builds
Aug 22 14:14:24 * kergoth nods
Aug 22 14:30:32 <bluelightning> peachj: a quick hack: https://gist.github.com/3426129
Aug 22 14:30:45 <bluelightning> there may be better solutions
Aug 22 14:31:18 <xxiao> just curious, seems debian package does not parse the whole dependency tree when building a new deb, why yocto does that? each bitbake involes a global parsing which takes time
Aug 22 14:34:30 <bluelightning> xxiao: sorry, I'm not quite understanding what you mean
Aug 22 14:35:40 <xxiao> bluelightning: bitbake hello.bb will parse all recipes first? to make sure dependency correct? or not
Aug 22 14:36:37 <bluelightning> xxiao: it's supposed to only parse once, and after that only parse changed files, unless you change the global configuration
Aug 22 14:37:07 <bluelightning> i.e. if you edit local.conf it will force a full reparse, that is deliberate
Aug 22 14:37:40 <rburton> xxiao: in debian you don't have a global view of the source packages. in debian you only rebuild a package, in bitbake you're rebuilding parts of the whole.
Aug 22 14:40:27 <xxiao> yeah just hope to boost the build speed even more, say if my hello.bb only depends on gcc and glibc it shouhd be built immediately without checking other recipes
Aug 22 14:41:09 <xxiao> that is, by looking at hello.bb then realize only limited dependency need be reparsed, not everything else
Aug 22 14:44:51 <kergoth> you're forgetting about PROVIDES.
Aug 22 14:44:59 <kergoth> also, filename and pn don't have to be the same
Aug 22 14:45:05 <kergoth> the recipe is free to override it
Aug 22 14:45:17 <kergoth> we can't resolve the build time dependencies vs provides without parsing everything
Aug 22 14:45:33 <kergoth> so basically, it doesn't know to look at hello.bb when you run 'bitbake hello'
Aug 22 14:45:39 <kergoth> because any recipe can PROVIDES += "hello"
Aug 22 14:45:45 <kergoth> and tada, can be built via bitbake hello
Aug 22 14:47:10 <xxiao> ic
Aug 22 14:48:44 <kergoth> if you really want to feel better about the parse time, try building oe classic with bitbake from before parallel parsing went in, then try a modern build again. it used to be much worse :)
Aug 22 14:51:38 <rburton> ha
Aug 22 15:43:22 <rburton> | ./gen-bases: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory
Aug 22 15:43:26 <rburton> hmpf
Aug 22 15:43:29 <rburton> khem: there?
Aug 22 16:34:34 <msm> im seeing this on denzil: https://gist.github.com/3422904
Aug 22 16:35:01 <msm> and not on master, any idea what commit might have fixed this… my first search did not show anything obvious
Aug 22 16:53:22 <RP> msm: http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/classes/base.bbclass?id=ae213b252fb0b87ec3daaa2c78b794a3e17addb6
Aug 22 17:06:00 <rburton> msm: python-curl and python-imaging failing QA on the autobuilder (http://autobuilder.yoctoproject.org:8010/builders/nightly-world/builds/242/steps/shell_34/logs/stdio) could this be something caused by your distutils change?
Aug 22 17:06:07 <rburton> msm: (you also have bugmail)
**** BEGIN LOGGING AT Wed Aug 22 17:34:23 2012
Aug 22 17:37:10 <khem> back again
Aug 22 17:42:51 <peachj> In my continuing quest to print out all my SRCREVs, even in the presence of AUTOREV, I added a task called printsrcrev that exists between fetch and compile
Aug 22 17:43:08 <peachj> But now AUTOREVs SRCREV print as AUTOINC
Aug 22 17:43:15 <peachj> Any easy way to resolve that?
Aug 22 18:18:30 <msm> RP: that patch has been included since edison release
Aug 22 18:18:57 <msm> rburton: got the notifications, should be an easy fix… will test something sometime soon hopefully
Aug 22 18:19:21 <msm> RP: and i was looking at that preferred_ml_update and it looks seemingly the same between denzil and master
Aug 22 18:19:34 <msm> or rather no obvious differences
Aug 22 18:38:48 <RP> msm: I don't know then, that is the code that was meant to fix that issue afaik. Was there any fixes to it?
Aug 22 18:39:02 <RP> peachj: You can see the information from SRCPV ?
Aug 22 18:39:22 <RP> peachj: The trouble is you can have two revisions for some recipes (like linux-yocto)
Aug 22 18:39:42 <peachj> Actually, yeah, I just had the realization I could use SRCPV
Aug 22 18:39:52 <peachj> But you're saying that will be problematic?
Aug 22 18:40:29 <msm> RP: maybe it's a difference in my layer then, i'll keep looking
Aug 22 18:40:50 <RP> peachj: no, SRCPV is fine
Aug 22 18:41:07 <RP> peachj: if depends if you want just the revision or the version string
Aug 22 18:42:27 <peachj> RP: All I need is the revision, which I think I can get pretty trivially out of SRCPV, it would seem.
Aug 22 19:04:40 <RP> kergoth: The way we handle python xxx () and def yyy differently in BBHandler/ast is horrible :(
Aug 22 19:05:22 <RP> kergoth: I was going to do some consolidation but the walls crashed down around me :(
Aug 22 19:05:42 <kergoth> agreed
Aug 22 19:09:59 <RP> kergoth: the trouble is we can't defer all python until the end as some variable expansion may use it. Equally, we can't expand python xxx () immediately as we need to account for overrides
Aug 22 19:10:38 <RP> Anyhow, hopefully the series I just posted improves the backtraces to be vaguely legible
Aug 22 19:37:14 <sgw> RP: was the libtool change that you pulled in supposed to fix the RPATH issue?
Aug 22 19:38:22 <sgw> andyross: you around?  We seem to be seeing more failures with your libtool change on x86_64 builds
Aug 22 19:39:44 <RP> sgw: yes
Aug 22 19:39:51 <RP> sgw: its breaking things?
Aug 22 19:39:56 <andyross> Here, but literally about to stand up for an errand.  What's the issue?
Aug 22 19:40:23 <RP> sgw: I really want to see it using libtools own functions but since the build was broken, I thought that would help :/
Aug 22 19:40:51 <sgw> RP: well there are more failures in the x86_64 builds for pango and rpm (see: http://autobuilder.yoctoproject.org:8010/builders/nightly-x86-64/builds/593/steps/shell_26/logs/stdio)
Aug 22 19:40:59 <sgw> andyross: ^^^^
Aug 22 19:41:06 <andyross> RP, I actually put together one using func_normal_abspath this morning if you want me to resubmit.
Aug 22 19:41:34 <RP> andyross: please do send that
Aug 22 19:41:41 <sgw> andyross: please rebase it against master.
Aug 22 19:41:51 <sgw> RP: I will pull it into mut and test it fully
Aug 22 19:42:17 <sgw> andyross: did you do a qemux86-64 machine build?
Aug 22 19:42:43 <kergoth> hmm
Aug 22 19:43:17 <kergoth> isn't a port mapper needed to run an nfs server? I just notijced task-core-nfs-server doesn't include portmap or rpcbind
Aug 22 19:43:31 <sgw> RP: strangely I am still seeing the gettext failure also on my local machine, and it has the libtool change, I also saw a strange failure of sysroot/.../sed missing
Aug 22 19:43:36 <kergoth> hm
Aug 22 19:43:40 <andyross> Looking at that log, those are the warnings that got added to insane.bbclass.  That's not uniformly fixed by this patch, only spots that pick up bad paths via libtool.  We'll need to audit all those.  I remember seeing the rpm ones.
Aug 22 19:44:41 <andyross> But the actual build *failure* on x86_64 is a binutils bug where the host directories get searched incorrectly when ld is passed a -rpath argument (it doesn't interpret via sysroot).  I think I have that fixed too, should be inbound today
Aug 22 19:46:02 <RP> kergoth: probably although I remember some history about that possibly. Might be worth checking the logs
Aug 22 19:46:23 <RP> kergoth: I could be thinking of something qemu nfs related though :/
Aug 22 19:48:45 <sgw> andyross: you might try a clean build looks like you added sed-native to dependency for libtool, will that cause problems?
Aug 22 19:48:50 <kergoth> will have to test it out
Aug 22 19:51:20 <andyross> That may be getting beyond my experience level.  I'm all but certain there is other sed usage in that same script, but I admit to no clue about how the very low level dependencies are arranged.  All I can say for sure is that nothing in that sed line is non-POSIX, and also that a variant that reuses the existing normalization function instead of a direct sed will be going out today.
Aug 22 20:22:12 <kergoth> what need was task-core-console / task-core-apps-console intended to meet?
Aug 22 20:22:28 <kergoth> psplash, avahi, dbus, and portmap is a rather random collection, no?
Aug 22 20:33:42 * RP agrees portmap is rather odd there
Aug 22 20:33:59 <RP> there is a reason bluelightning is looking at this :/
Aug 22 20:35:19 * kergoth nods
Aug 22 21:04:40 <kergoth> hmm, there's no ssh server in core-image-base?
Aug 22 21:04:42 * kergoth ponders
Aug 22 21:11:19 <khem> ant__: hi
Aug 22 21:11:31 <khem> ant__: I have built an image for collie
Aug 22 21:11:45 <khem> http://uclibc.org/~kraj/collie/
Aug 22 21:12:03 <khem> ant__: I am looking for testers to see if it boots
Aug 22 21:12:04 <ant__> khem: I've seen the kernel.bbclass patch great work
Aug 22 21:12:37 <ant__> bluelightning: ^^^
Aug 22 21:12:51 <ant__> Jay7x: ^^^
Aug 22 21:12:58 <khem> I have notified bluelightning :)
Aug 22 21:13:19 <khem> qemu segfaults when emulating collie
Aug 22 21:13:22 <khem> so I am out of luck
Aug 22 21:13:24 <ant__> :/
Aug 22 21:14:42 <khem> If it works then I will post the gcc patch as well
Aug 22 21:15:19 <khem> kergoth: I use core-image-core
Aug 22 21:15:49 <khem> kergoth: that seems to be more or less complete in terms usable minimal package set in my case
Aug 22 21:16:09 <ant__> do we still need gcc linaro patches like 820 830 and 840 ?
Aug 22 21:16:16 <kergoth> does that include an ssh server by default? I'm guessing no?
Aug 22 21:16:46 <ant__> khem: well, 840 is yours :)
Aug 22 21:17:12 <kergoth> hmmm
Aug 22 21:17:29 <Jay7x> ant__: do we have working kexecboot for collie?
Aug 22 21:17:35 <kergoth> how to handle lttng vs lttng2. they're different sets of packages, yet multiple tasks explicitly refer to one vs the other
Aug 22 21:18:09 <kergoth> at mentor we added lttng/lttng2 MACHINE_FEATURES, since the machine knows what patches it has applied to its kenrel, so knows which, if any, it supports
Aug 22 21:18:15 * kergoth ponders
Aug 22 21:18:31 <ant__> Jay7: there is a new kernel to test
Aug 22 21:18:32 <khem> kergoth: I have EXTRA_IMAGE_FEATURES_append_pn-core-image-minimal = " ssh-server-openssh" in my local.conf :)
Aug 22 21:19:19 <khem> kergoth: virtual/lttng ?
Aug 22 21:19:33 <kergoth> khem: ah :)
Aug 22 21:19:40 <sgw> seebs: around?  How can I get more info out of pseudo to try and debug a rootfs creation issue?
Aug 22 21:19:57 <khem> ant__: http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/misc&id=c82d1d7965f5fa5c0b5a4f79dff0daad2e95f611
Aug 22 21:20:02 <khem> thats the patch we need
Aug 22 21:20:07 <seebs> PSEUDO_DEBUG=2 will spew immense amounts of data into log files. Sadly, I have never gotten the time to make the logs very legible.
Aug 22 21:20:08 <khem> if it works
Aug 22 21:20:27 <kergoth> khem: it's not just one package though. lttng you want lttng-control, lttng-ust. lttng2 you want lttng-tools, lttng-modules, lttng2-ust, afaik
Aug 22 21:20:46 <kergoth> guess could use two tasks with PROVIDES of the virtual
Aug 22 21:21:05 <khem> kergoth: exactly create a meta-package
Aug 22 21:21:22 <khem> or PACKAGEGROUP
Aug 22 21:21:40 <ant__> khem: kernel built with that patch and two more is bad. Now I'll rebuild the same with updated kernel.bbclass
Aug 22 21:21:59 <sgw> seebs: ok just set that in the environment and fire up bitbake?
Aug 22 21:22:10 <kergoth> khem: then the question becomes how the user adds it to their image, when its likely they have no clue which to use (PACKAGE_GROUP). guess task+virtual/
Aug 22 21:22:13 * kergoth tests that
Aug 22 21:22:29 <seebs> Yeah. And keep in mind, "log files" includes stderr.
Aug 22 21:22:36 <seebs> So redirect and expect boatloads of data.
Aug 22 21:22:51 <sgw> seebs: now you tell me!
Aug 22 21:23:12 <seebs> I basically always run builds into log files anyway. :)
Aug 22 21:23:17 <seebs> Hmm.
Aug 22 21:23:38 <khem> ant__: there is one more fix for LDFLAGS that might be needed
Aug 22 21:23:42 <sgw> I am trying to find a needle in a haystack, there's a chmod going wrong in the middle of the rootfs creation with RPM only
Aug 22 21:23:45 <seebs> You can also use PSEUDO_DEBUG_FILE.
Aug 22 21:23:46 <khem> but lets do it step by step
Aug 22 21:24:00 <seebs> e.g. PSEUDO_DEBUG_FILE=/tmp/pseudologs/%s-%d.log
Aug 22 21:26:18 <ant__> khem: what about that  SUBTARGET_CPU_DEFAULT TARGET_CPU_arm10tdm
Aug 22 21:26:27 <ant__> i
Aug 22 21:26:34 <khem> ant__: I want to avoid it
Aug 22 21:26:45 <ant__> is >4 years old :/
Aug 22 21:27:02 <khem> ant__: thats should not be needed if we have out CCFLAGS right
Aug 22 21:27:32 <ant__> yes, not defaulting
Aug 22 21:27:38 <sgw> seebs: are the paths relative or absolute in the logs?
Aug 22 21:27:44 <khem> I want to support arch < armv5te but not change defaults
Aug 22 21:27:57 <ant__> it's fine
Aug 22 21:28:20 <seebs> Generally absolute. I think at debug=4 it'll show how the resolution is happening.
Aug 22 21:28:31 <khem> ant__: I am hopeful we can avoid it
Aug 22 21:28:41 <seebs> On my list: Changing it to use debug types rather than "levels".
Aug 22 21:28:51 <khem> ant__: it changes are default and that can have indirect issues
Aug 22 21:29:10 <ant__> ok ,but for strongarm it does not harm, isn't?
Aug 22 21:29:11 <xxiao> i'm having trouble to let bitbake virtual/kernel to pick up my newly added patches. i appened file://mypatch to SRC_URI, did -c cleansstate, bumped PR, but bitbake -c patch virtual/kernel keeps ignoring the new patches
Aug 22 21:29:30 <ant__> khem: anyway
Aug 22 21:29:41 <xxiao> what else could be missing?
Aug 22 21:29:44 <ant__> I'll rebuild with your patch only
Aug 22 21:30:02 <ant__> plus kernel.bbclass one
Aug 22 21:31:47 <kergoth> hrm
Aug 22 21:34:04 <xxiao> i could not find SRCREV in the working kernel git, so maybe that's the wrong recipe
Aug 22 21:42:08 <zecke_> seebs: hi, RP referred me to you
Aug 22 21:42:24 <seebs> Pseudo problem? It's user error. :P
Aug 22 21:42:44 <zecke_> seebs: http://paste.lisp.org/display/131171, is my pseudo hacks to build on FreeBSD...
Aug 22 21:42:52 <seebs> ooohhh
Aug 22 21:42:57 <zecke_> seebs: first is to use /usr/bin/env bash.. as /bin/bash might not exist
Aug 22 21:43:39 <seebs> Heh, yeah. Well, at least I wasn't assuming /bin/sh was bash. :)
Aug 22 21:43:51 <zecke_> seebs: but I wonder how to 'verify' some basic operation.. e.g. there is no "make check" for the tests
Aug 22 21:44:05 <zecke_> seebs: and there is no stat64 in FreeBSD
Aug 22 21:44:26 <seebs> The Darwin port is probably closer, it doesn't need stat64.
Aug 22 21:44:37 <seebs> Or at least I hope it doesn't.
Aug 22 21:44:53 * RP -> Zzzz
Aug 22 21:44:54 <zecke_> seebs: there is no struct stat64, so pseudo.h requires an #ifdef
Aug 22 21:44:55 <RP> have fun ;-)
Aug 22 21:45:00 <sgw> fray: around?  RPM question for you
Aug 22 21:45:07 <sgw> RP night!
Aug 22 21:45:19 <seebs> ... Wait, I totally thought this was fixed when I did the darwin port.
Aug 22 21:45:42 <seebs> Ohhh. No, because I still have some stuff lying around for conversions.
Aug 22 21:45:53 <zecke_> seebs: I just git cloned master (and you see that i just remove the stuff)
Aug 22 21:46:03 <seebs> It never gets used, I think. It should probably be conditional on the STATBUF64 define.
Aug 22 21:46:31 <seebs> I haven't had a chance to try more ports yet, although I keep planning to.
Aug 22 21:47:14 <seebs> Yeah, that stuff should probably be conditional on PSEUDO_STATBUF64. I think it's only used on such systems anyway.
Aug 22 21:47:15 <zecke_> i need to move home.
Aug 22 21:47:31 <zecke_> how do you prefer contributions? by shouting? sending patches?
Aug 22 21:47:59 <seebs> Send patches, email, something like that. And I think there's a "make test" which may or may not work. Mostly I just run pseudo and Do Stuff a bit and see how it looks.
Aug 22 21:48:07 <sgw> seebs so the pseudo calls are not chroot'ed at all, so when RPM calls the chmod via a script under pseudo it uses the absoulte path?
Aug 22 21:49:10 <seebs> Huh. RPM uses chroot at least sometimes. It may be that when it's calling scripts, it's not using chroot, though.
Aug 22 21:49:54 <sgw> seebs: seems ipk also has the same issue just does not error out in the same way (I found the same chmod call fail in the pseudo logs).
Aug 22 21:49:57 <zecke_> bye
Aug 22 21:50:00 <seebs> whee
Aug 22 21:50:21 <sgw> seebs: that's what I said followed by an oh <>
Aug 22 21:50:48 <seebs> It's possible something's busted in the way pseudo tries to pass chroot information to child processes, or busted by something in our environment. That's not the most heavily-tested code in pseudo.
Aug 22 21:52:19 <sgw> seebs running the do_rootfs is pretty heavy weight, but I am not sure how to minimize this issue, see https://bugzilla.yoctoproject.org/show_bug.cgi?id=2892 for setup if you are interested in digging into it (should I assign this to you?)
Aug 22 21:52:28 <seebs> wheee
Aug 22 21:52:33 <xxiao> hmm it's the right recipe, why it did not take my patches
Aug 22 21:52:38 <seebs> Sure, go ahead. Although I have no idea when I'd be able to do much on it.
Aug 22 21:53:18 <sgw> seebs: well maybe I will continue to bang on it, I think this is one that needs to get fixed as it breaks rootfs creation!
Aug 22 21:54:09 <seebs> Just mark rootfs creation as an "optional functionality". :P
Aug 22 22:01:21 <xxiao> alright, what if the git from the recipe could not find the SRCREV commit-id? will it fail?
Aug 22 22:01:38 <xxiao> or keep building on top of that git repo?
Aug 22 22:02:12 <kergoth> it'll fail
Aug 22 22:11:26 <xxiao> this is really odd, git kernel does not have the SRCREV commit-id, my patches did not get picked up, and it's the only recipe i'm baking
Aug 22 22:11:47 <xxiao> PR updated, cleansstate done too, just in case
Aug 22 22:12:39 <xxiao> -v -DDD did not show any patching process and it's too verbose
Aug 22 22:23:02 <xxiao> i hate to say but yocto is too hard to debug
Aug 22 22:27:30 <xxiao> esp when you have 5+ extra layers to support 4 similar chips (32bit and 64bit) at the same time, the abstraction lost me
Aug 22 22:30:41 <xxiao> ok find that SRCREV hiding in a inc file at a different layer
Aug 22 22:33:24 <xxiao> require 1.inc; 1.inc has SRCREV and SRC_URI(patches); require 2.inc; 1.inc has the right SRCREV and SRC_URI, need move patches to the very last 2.inc
Aug 22 22:33:27 <xxiao> sigh
Aug 22 22:33:55 <xxiao> require 1.inc; 1.inc has SRCREV and SRC_URI(patches); require 2.inc; 2.inc has the right SRCREV and SRC_URI, need move patches to the very last  2.inc
Aug 22 22:33:59 <xxiao> that should fix it
Aug 22 23:10:36 <kergoth> yow, setting INCOMPATIBLE_LICENSE sure results in a lot of bitbake messaging spam
Aug 22 23:10:42 <kergoth> i can see why it'd do that, but sheesh
Aug 22 23:11:00 * kergoth thinks about how you'd clean that up
Aug 22 23:17:55 <thaytan> denix: ping?
Aug 22 23:18:24 <denix> pong
Aug 22 23:18:24 <thaytan> I built out a kernel for the TI 814x EVM, but it throws an alignment exception early in the boot
Aug 22 23:18:41 <thaytan> some googling suggests adding a compiler flag to not use unaligned access as one workaround
Aug 22 23:18:59 <thaytan> does that behaviour ring any bells?
Aug 22 23:19:52 <msm> RP: the preferred_ml_updates is working OK on both branches… but some reason the MultipleProviders event is still occuring
Aug 22 23:20:58 <xxiao> denix: TI begins to submit A15 patches to kernel.org, does arago host the newest A15 stuff?
Aug 22 23:21:08 <denix> thaytan: I believe it was discussed on the meta-ti mailing list some time ago... unfortunately, ti81xx is not very supported in yocto/meta-ti or openembedded...
Aug 22 23:21:50 <xxiao> denix: i think TI81xx SDK is still building on top of arago?
Aug 22 23:23:11 <denix> xxiao: yes and no - not all pieces of A15 is public yet, but should be very soon
Aug 22 23:23:50 <xxiao> denix: does it have a staging git somewhere, e.g. omapzoom or arago kernel git?
Aug 22 23:24:18 <denix> xxiao: yes, it's still building on top of arago, i.e. Classic OE, but it's 2.6.37 kernel and gcc-4.5 toolchain, so don't expect any forward porting to be easy
Aug 22 23:25:37 <xxiao> denix: it depends on when TI moves to post-2.6.37 for all its SDKs, i guess it will be a long while...
Aug 22 23:27:38 <thaytan> denix: I'll see if I can find the discussion. Otherwise, is there a correct place to put 'EXTRA_CFLAGS=-mno-unaligned-access' so it gets used?
Aug 22 23:27:59 <thaytan> arago is a release code name?
Aug 22 23:28:50 <denix> xxiao: which part? there is omap5 and there's keystone2
Aug 22 23:29:09 <denix> xxiao: some SDKs are on 3.x
Aug 22 23:30:24 <xxiao> denix: mostly i used ti81xx SDKs, which is 2.6.37, just want to know when new kernel will be updated, was told by TI it's not on the agenda yet a while ago
Aug 22 23:30:38 <xxiao> meanwhile wondering where TI's A15 git tree is
Aug 22 23:31:03 <denix> thaytan: KERNEL_CC_append += "-mno-unaligned-access "
Aug 22 23:32:28 <khem> hmmm pango still complains about rpath
Aug 22 23:32:29 <thaytan> ta
Aug 22 23:33:06 <khem> denix: kernel with thumb2 still fails with gold using binutils 2.23 :(
Aug 22 23:33:12 <denix> thaytan: arago is the name of the project that covers several different things for TI open source efforts. it's an umbrella project, kind of like yocto project... :)
Aug 22 23:33:19 <khem> I will see if I can grab a testcase
Aug 22 23:33:31 <khem> denix: you promised me a testcase long ago
Aug 22 23:33:35 <khem> never delivered :)
Aug 22 23:33:46 <denix> xxiao: about A15 - see my question above about which part you are interested in
Aug 22 23:34:53 <denix> khem: I thought I did... :)
Aug 22 23:37:05 <denix> xxiao: ti33x is the leading SoC in terms of upstreaming and open sourcing (after omap35x/37x)...
Aug 22 23:37:17 <khem> thought are thoughts sometimes they are like emulators
Aug 22 23:37:47 <thaytan> denix: do you work for TI?
Aug 22 23:38:25 <denix> khem: :)
Aug 22 23:38:29 <thaytan> ah yes, google says you do
Aug 22 23:39:11 <denix> darn google knows it all!
Aug 22 23:39:40 <khem> google knows even your credit card # and SSN if you follow the trail hard enough
Aug 22 23:40:05 <khem> and it had copies of your tax returns somehwere too
Aug 22 23:56:59 * xxiao saw some website intentionally providing fake ssn and credit card , a nice bait for google
Aug 22 23:57:31 <xxiao> tryinng your name with ssn in google, you will get a hit most likely, and it will be fake
Aug 22 23:59:07 <denix> xxiao: you didn't answer which A15 part you are interested in. if omap5, look at linaro landing team. if keystone, look at arago
Aug 22 23:59:33 <xxiao> omap5 that is, thanks
Aug 22 23:59:52 <xxiao> isn't keystone DSP?
Aug 22 23:59:56 <xxiao> 6678?
Aug 23 00:00:01 <denix> xxiao: no. http://arago-project.org/git/projects/?p=linux-keystone.git;a=summary
Aug 23 00:00:24 <denix> more specifically http://arago-project.org/git/projects/?p=linux-keystone.git;a=commitdiff;h=50c5b8f404ea233600e3b7e7a37d903acdb6e440
Aug 23 00:00:34 <xxiao> http://processors.wiki.ti.com/index.php/Keystone_Device_Architecture
Aug 23 00:00:59 <xxiao> that's odd on the naming :) i did some work on c6678 so thought keystone must be for dsp
Aug 23 00:01:19 <denix> well, it's keystone2, to be correct ;)
Aug 23 00:02:39 <xxiao> does keystone2=keystone(DSP)+A15?
Aug 23 00:02:43 <xxiao> could not google it
Aug 23 00:03:20 <denix> if you look at http://www.ti.com/product/tms320c6678 you will see that the old DSP-only was called Keystone I, while A15 based is officially called Keystone II
Aug 23 00:04:19 <xxiao> i c , it's for basestation and i think A15 will be running the control layer for protocol etc
Aug 23 00:04:24 <denix> http://newscenter.ti.com/index.php?s=32851&item=123088
Aug 23 00:04:43 <denix> correct
Aug 23 00:06:31 <denix> it's not only for basestations, but that's the current focus for now. it is also positioned as multi-purpose multi-core soc...
Aug 23 00:06:55 <xxiao> well, it's ARM+DSP again, should be called OMAP5 or DM6788 or something
Aug 23 00:09:00 <xxiao> anyways, it looks more powerful than FSL's BSC913x
Aug 23 00:10:06 <xxiao> BSC9131=Powerpc+DSP, shooting for base-station as well
Aug 23 00:10:33 <denix> omap5 is more mobile-oriented
Aug 23 00:11:16 <denix> dsp side on omap5 is not very important and is not as powerful
Aug 23 00:11:45 <xxiao> right, on mobile chip these days you use hw accelerator IP
Aug 23 00:11:50 <xxiao> to save power at least
Aug 23 00:45:55 <kergoth> anyone have any ideas for stuff to add to https://wiki.yoctoproject.org/wiki/LesserKnownFeatures ? figured i'd jot down some things that people don't seem to realize exist
Aug 23 01:25:06 <kergoth> hmm, i think there's still some sstate reuse bugs
Aug 23 02:40:46 <msm> kergoth: which ones?
Aug 23 02:41:15 <kergoth> haven't nailed it down yet, but i've seen my natives get rebuilt when i didn't change anything taht should have affected them, multiple times today
Aug 23 02:41:21 <kergoth> will have to dig
Aug 23 02:41:43 <msm> i think there is an issue when you add multilib, it rebuilds things
Aug 23 02:42:07 <msm> i think sstate-cache needs more automated testing
Aug 23 02:42:07 <kergoth> interesting. not using that yet, but will keep an eye out
Aug 23 02:42:45 <kergoth> i'd love for tmpdir to keep track of the sstates for a given recipe in some fashion, so i don't have to go diging for current ahd previous to do the diff
**** ENDING LOGGING AT Thu Aug 23 02:59:59 2012

**** BEGIN LOGGING AT Thu Aug 23 03:00:00 2012
Aug 23 03:03:49 <xxiao> kergoth: if i updated a PR for a recipe which is part of the image,will a rebuild of the image give me a new image, or just the old image from sstate since i have not updated PR in the image's bb?
Aug 23 03:04:30 <xxiao> i.e. do I need bump PR in image recipe when anything that is part of the image changed?
Aug 23 03:08:28 <kergoth> images are always built from scratch
Aug 23 03:08:37 <kergoth> they don't get stored in sstate
Aug 23 03:08:57 <xxiao> kergoth: thanks, want to confirm that, looks like it is the case
Aug 23 03:08:59 <kergoth> also, if you're using basichash, it'll rebuilt affected things even without PR bumps
Aug 23 03:09:05 <kergoth> np
Aug 23 03:10:07 <xxiao> the kernel is always problematic, i noticed after a new kernel is built, which normally added -dirty to its version, could break other packages whichever has dependencies on kernel versions
Aug 23 03:10:26 <xxiao> i had to do compile -f for each of them then build the final image again
Aug 23 03:11:49 <xxiao> is there a standard reciple that provides a merge directory, i.e. recipe-merge/files/overlay-rootfs-dirs for yocto
Aug 23 03:12:10 <xxiao> that i put whatever under recipe-merge/files will be overlayed to rootfs at the last stage?
Aug 23 03:18:11 <kergoth> i think msm has one that freescale uses, but i dont' think anything of the sort is in one of the upstream layers yet
Aug 23 03:22:36 <xxiao> kergoth: i think it would be good if yocto can support it directly
Aug 23 03:22:44 <xxiao> very handy in practice
Aug 23 03:23:03 * xxiao is aware of freescale's merge recipe
Aug 23 03:23:15 <kergoth> agreed, i'm sure it would be
Aug 23 03:52:28 <msm> merge-recipes has it's downsides too
Aug 23 03:54:06 <xxiao> msm: you mean it's too intrusive?
Aug 23 03:54:17 <msm> it just causes problems
Aug 23 03:54:20 <msm> too
Aug 23 03:54:40 <msm> why won't my x86 binary run this ppc board? etc etc
Aug 23 03:55:10 <msm> in reality it's caught by sanity checks - but things lead to more things
Aug 23 03:55:30 <msm> people need to just make a recipe OR if they are doing development using a hard drive or NFS or something
Aug 23 03:56:07 * kergoth nods
Aug 23 03:56:11 <kergoth> that's a good point
Aug 23 03:56:25 <kergoth> sometimes making something easy isn't good, if it encourages them to not learn what's underneith the abstraction
Aug 23 03:56:31 <xxiao> for bringup / bsp it's very handy
Aug 23 03:57:11 <xxiao> openwrt has similar things too, files/ directory
Aug 23 04:28:21 <msm> bruuuuuuce
Aug 23 04:28:38 <msm> are you rhyming now?
Aug 23 07:44:06 <RP> morning all
Aug 23 07:45:06 <bluelightning> hi RP
Aug 23 07:59:05 <JaMa> bluelightning: hi, sorry no more detail for that Parse Error, I could not reproduce it later with that layer used in other setup
Aug 23 08:10:31 <Zagor> oops, I sent my patches to the wrong list (poky instead of yocto). moderator, feel free to discard them.
Aug 23 08:12:53 <bluelightning> JaMa: hmm... well if you figure it out please let me know, otherwise I'm a little stuck with that one...
Aug 23 08:15:04 <JaMa> bluelightning: ok, will try to reproduce it with some self inflicted parsing errors..
Aug 23 08:16:31 <JaMa> bluelightning: interesting is, that the layer didn't do anything completely bad (as it parsed ok in other setup) and it wasn't even some stalled cache problem (I've tried to delete tmp-eglibc/cache/* to reparse everything
Aug 23 08:40:15 <_Lucretia_> still problems with gumstix :(
Aug 23 08:40:18 <_Lucretia_> NOTE: Error expanding variable do_unpack
Aug 23 08:40:18 <_Lucretia_> NOTE: Error during finalise of /home/laguest/src/others/poky/poky/meta-gumstix/recipes-bsp/firmwares/marvell-sdio-fw_9.70.3-p37.bb
Aug 23 08:40:18 <_Lucretia_> ERROR: Unable to parse /home/laguest/src/others/poky/poky/meta-gumstix/recipes-bsp/firmwares/marvell-sdio-fw_9.70.3-p37.bb
Aug 23 08:40:23 <_Lucretia_> this is on the master branch
Aug 23 08:40:44 <_Lucretia_> and: ERROR: Nothing PROVIDES 'pseudo-native' ??
Aug 23 08:47:24 <bluelightning> _Lucretia_: the second is a follow-on from the first, ignore it
Aug 23 08:47:52 <_Lucretia_> k
Aug 23 08:48:10 <_Lucretia_> lots of spaces->tabs warnings again, but warnings, so not bothered
Aug 23 08:48:45 <bluelightning> _Lucretia_: er, that file does not exist in current master of meta-gumstix...
Aug 23 08:49:25 <bluelightning> checkout master and pull the latest version
Aug 23 08:49:29 <_Lucretia_> I have
Aug 23 08:49:51 <bluelightning> you are using git://gitorious.org/schnitzeltony-oe-meta/meta-gumstix.git correct?
Aug 23 08:50:00 <bluelightning> git remote -v to check
Aug 23 08:50:20 <_Lucretia_> yup
Aug 23 08:50:24 <_Lucretia_> $ git checkout  master
Aug 23 08:50:24 <_Lucretia_> Already on 'master'
Aug 23 08:50:24 <_Lucretia_> laguest@rogue:~/src2/others/poky/poky/meta-gumstix$ git pull
Aug 23 08:50:24 <_Lucretia_> Already up-to-date.
Aug 23 08:50:33 <_Lucretia_> bbiab
Aug 23 08:51:07 <bluelightning> what is the output of: git status
Aug 23 09:14:51 <zeeblex> dvhart: ping
Aug 23 09:41:23 <_Lucretia_> back
Aug 23 09:41:58 <_Lucretia_> bluelightning: nothing to commit - clean
Aug 23 09:47:10 <_Lucretia_> just done a new clone, no, it's not there
Aug 23 09:51:37 <bluelightning> either those files were uncommitted or you weren't on master...
Aug 23 09:52:48 <bluelightning> bbiab
Aug 23 09:55:55 <_Lucretia_> blitz00: I'm starting again with a fresh tree as i noticed it's still referencing source from the old tree, somehow
Aug 23 09:56:09 <_Lucretia_> I've had to buy a new drive as i was running out of space
Aug 23 09:56:25 <_Lucretia_> balls, not blitz00...
Aug 23 10:36:04 <_Lucretia_> ok, i'm really confused. why is this reading the wrong files? /home/laguest/src/others/poky/poky/meta-gumstix/recipes-bsp/firmwares/marvell-sdio-fw_9.70.3-p37.bb - I have created poky inside /home/laguest/src2/others/poky
Aug 23 10:42:42 <RP> _Lucretia_: something in bblayers.conf ?
Aug 23 10:42:55 <_Lucretia_> fek
Aug 23 10:42:57 <_Lucretia_> thanks
Aug 23 10:43:45 <_Lucretia_> cut n paste from my previous instructions - missed that bit
Aug 23 11:33:38 <Zagor> is anyone here a yocto list moderator? I sent some patches to the list this morning but they haven't reached the list yet
Aug 23 12:07:57 <bluelightning> Zagor: I don't think the list is moderated - with mailman you usually get a message telling you that your message is in the moderation queue if that's the case
Aug 23 12:33:39 <Zagor> bluelightning: right. puzzling...
Aug 23 13:18:43 <xxiao> msm: ping
Aug 23 14:21:12 <Zagor> turns out I had a bad envelop address
Aug 23 16:02:50 <kergoth> RP: ping
Aug 23 16:05:08 <RP> kergoth: pong
Aug 23 16:05:28 <RP> kergoth: although I'm multitasking...
Aug 23 16:07:38 <kergoth> RP: just wondering about the lack of dependency mapping for nativesdk, noticed the package/rdeps/etc bits are commented out
Aug 23 16:11:43 <kergoth> being bitten by eglibc-nativesdk and external-sourcery-tolchain both providing libc-mtrace, getting a preferred provider conflict as a result
Aug 23 16:12:51 <kergoth> https://raw.github.com/gist/3438132/f99405985c8e25e1ef301b4428a3b0276468638e/gistfile1.txt is the exact failure
Aug 23 16:16:17 <RP> kergoth: ah. The trouble is that code didn't work
Aug 23 16:16:38 <RP> kergoth: My intent has been to move this to use the mutilib mechanism as its know to work
Aug 23 16:16:53 <RP> kergoth: The trouble is nativesdk needs to become a prefix, not a suffix
Aug 23 16:16:53 <kergoth> ah, makes sense
Aug 23 16:16:57 <kergoth> right
Aug 23 16:17:06 <kergoth> i'd imagine the suffixing would be a pain in the ass with -dev/-doc/etc
Aug 23 16:17:28 <RP> kergoth: exactly. I ended up concluding it was near impossible to make it work right
Aug 23 16:17:35 <RP> kergoth: I put an RFC out about switching a while back
Aug 23 16:17:43 <RP> kergoth: I never got the changes done though
Aug 23 16:18:33 <RP> kergoth: I've even abstracted the multilib bits so we can reuse it for this
Aug 23 16:19:35 <kergoth> aha, need to add ${PKGSUFFIX} to the libc-mtrace RPROVIDES in eglibc-package.inc
Aug 23 16:19:41 <kergoth> will get past my current issue anyway :)
Aug 23 16:20:27 <RP> kergoth: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip2&id=de9b4197cd482ea59dbb02a8e458ca693a2cf8ce http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip2&id=b7321fbacca2dcc45e478cdd22fe242896515bcd
Aug 23 16:21:24 <kergoth> ah, nice
Aug 23 16:22:15 <kergoth> couple minor issues from a quick glance
Aug 23 16:22:16 <kergoth> - if pkg.endswith("-native") or pkg.endswith("-nativesdk"):
Aug 23 16:22:17 <kergoth> + if pkg.endswith("-native") or pkg.startswith("-nativesdk"):
Aug 23 16:22:35 <kergoth> note teh position of the dash didn't change from beginning to end in the second two changes for those conditionals
Aug 23 16:22:38 <kergoth> :)
Aug 23 16:22:40 <kergoth> looking good though
Aug 23 16:22:43 <kergoth> look forward to this stuff going in
Aug 23 16:24:19 <msm> xxiao: yes?
Aug 23 16:25:04 <kergoth> guh
Aug 23 16:25:46 <kergoth> changed RPROVIDES_${PN}-mtrace in eglibc-package.inc and it causes external-soucery-toolchain to rebuild due to the additional vardep on PKGSUFFIX, even though it doesn't actually affect what ends up in the package
Aug 23 16:26:03 <kergoth> and of course that causes the rest of the universe to rebuild
Aug 23 16:26:10 * kergoth sighs
Aug 23 16:26:14 * kergoth glares at siggen
Aug 23 16:29:52 <RP> kergoth: well spotted :)
Aug 23 16:30:02 <kergoth> :)
Aug 23 16:30:37 <xxiao> msm: i'm using sdk12 here
Aug 23 16:31:37 <RP> kergoth: those patches will be horrible to rebase :/
Aug 23 16:31:44 <kergoth> indeed
Aug 23 17:10:28 <kergoth> hmm
Aug 23 17:10:28 <kergoth>   File "/scratch/mel6/sanity/oe-core/meta/lib/oe/buildhistory_analysis.py", line 363, in process_changes
Aug 23 17:10:31 <kergoth>     filechanges = compare_file_lists(alines,blines)
Aug 23 17:10:34 <kergoth>   File "/scratch/mel6/sanity/oe-core/meta/lib/oe/buildhistory_analysis.py", line 235, in compare_file_lists oldvalue = splitv[3]
Aug 23 17:10:37 <kergoth> IndexError: list index out of range
Aug 23 17:10:40 <kergoth> anyone seen this one?
Aug 23 17:15:36 <bluelightning> kergoth: hmm, no, but I can look into it tomorrow...
Aug 23 17:15:56 <kergoth> k, no rush, i can always git show/log -p :)
Aug 23 17:15:56 <bluelightning> unfortunately I have to dash now
Aug 23 17:16:01 <kergoth> no worries, later
Aug 23 17:16:07 <bluelightning> cya
Aug 23 17:28:46 <bhundven> looking at meta-fsl-ppc/conf/machine/p1020rdb.conf, I notice that it uses P1020RDB-PC. I have a normal P1020RDB (not PC). Other then changing the u-boot board config and the dts, is there anything I should do with BOOTFORMAT_CONFIG?
Aug 23 17:33:00 <bhundven> it seems like this p1020rdb.conf should be called p1020rdb-pc.conf
Aug 23 17:37:16 <bhundven> it also seems like the confusion between p1020rdb and p1020rdb-pc started here: 7705457fb3846e5ebffc9ed7cb3b9976cefcfd1a
Aug 23 17:50:51 <msm> bhundven: i think the P1020RDB builds u-boot for each type of board
Aug 23 17:51:01 <msm> bhundven: that should be the only difference
Aug 23 17:51:49 <bhundven> well, it builds for all the -PC types, but none of the non-PC types
Aug 23 17:56:10 <bhundven> even u-boot differentiates between p1_p2_rdb and p1_p2_rdb_pc
Aug 23 18:00:53 <msm> bhundven: you seem to be correct
Aug 23 18:01:01 <msm> bhundven: i think we dropped official support for it
Aug 23 18:01:06 <bhundven> oh
Aug 23 18:01:14 <msm> you can add it back, and see: http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-ppc/tree/conf/machine/p1020rdb.conf
Aug 23 18:01:24 <msm> just add P1020RDB
Aug 23 18:01:53 <bhundven> it doesn't have a notice on freescale's site
Aug 23 18:03:12 <bhundven> http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=P1020RDB&parentCode=P1020&fpsp=1
Aug 23 18:04:46 <msm> bhundven: im not familiar with how that's done - can you point at a board that has a notice?
Aug 23 18:04:56 <bhundven> eh, nm
Aug 23 18:05:15 <bhundven> I'll just fork meta-fsl-ppc and merge any new changes on top
Aug 23 18:05:39 <msm> bhundven: if everything works - i'd be happy to take a patch to add it back… not sure how much support beyond that i can provide ;)
Aug 23 18:06:20 <bhundven> sure, I'm not sure if I should go through the normal patch contribution channels as for yocto or just send the change to you?
Aug 23 18:06:32 <bhundven> (opening a bug, etc...)
Aug 23 18:06:43 <msm> either, people send me random stuff all the time
Aug 23 18:06:57 <bhundven> ok, so one last question
Aug 23 18:07:05 <msm> githelp@freescale.com, yocto ml, direct…
Aug 23 18:07:13 <msm> putting it on github and IM'ing me works too
Aug 23 18:07:40 <bhundven> BOOTFORMAT_CONFIG = "config_ddr3_1gb_p1_p2_rdb_pc_800M.dat"
Aug 23 18:07:42 <bhundven> what is that?
Aug 23 18:08:06 <bhundven> I'm not sure the p1020rdb has that
Aug 23 18:08:32 <bhundven> (as opposed to the p1020rdb-pc)
Aug 23 18:09:13 <msm> that's the on chip rom config file for booting from spi or sd card
Aug 23 18:09:22 <msm> if you use NOR or NAND you should not need that
Aug 23 18:09:27 <bhundven> oh, ok
Aug 23 18:09:29 <bhundven> thanks
Aug 23 18:10:13 <bhundven> thanks again for you time msm!
Aug 23 18:10:28 <msm> bhundven: np
Aug 23 18:10:43 <msm> is there an example of forcing a recompile of a recipe if the kernel is rebuilt?
Aug 23 18:20:51 <msm> also, is there a way around the chrpath sanity checks installed recently?
Aug 23 18:20:51 <msm> http://fpaste.org/bCRn/
Aug 23 18:35:07 <msm> to answer my own question, add INSANE_SKIP_${PN} = "useless-rpaths"
Aug 23 18:41:23 <Daemon404> has anyone mentioned that the oe-core mailing list is REALLY annoying, in that setting up message filters for it is almost impossible
Aug 23 18:41:33 <Daemon404> since there are like 10 addresses people can sent to to reach it
Aug 23 18:41:39 <Daemon404> s/sent/send/
Aug 23 18:42:07 <Daemon404> u seem to catch a new one every day
Aug 23 18:51:24 <seebs> What header are you using?
Aug 23 18:52:02 <seebs> I've been using List-Id of openembedded-core, and that seems to be consistent.
Aug 23 18:52:14 <kergoth> I never have a problem
Aug 23 18:52:25 <kergoth> i use gmail's list:, which iirc uses List-Id also
Aug 23 18:57:01 <Daemon404> seebs, ive been sorting by to/cc, quite evilly
Aug 23 18:57:08 <seebs> Ah-hah!
Aug 23 18:57:17 <seebs> See? It's *ALWAYS* user error. :P
Aug 23 18:59:02 <Daemon404> not always
Aug 23 18:59:13 <Daemon404> i have at least one list with inconsistent list-ids
Aug 23 19:00:04 <seebs> It's just my default diagnosis when people report problems that have even the most tenuous relationship with pseudo.
Aug 23 19:01:04 <seebs> Funny thing being, it's actually right more often than I am if I try to carefully think about the bug and make a diagnosis.
Aug 23 19:02:50 <bhundven> msm: https://github.com/bhundven/meta-fsl-ppc/commit/ed193971a9557b2e117b41a6a81a32f6537e5285
Aug 23 19:02:51 <Daemon404> seebs, the sole time i reported a problem with pseudo
Aug 23 19:02:54 <Daemon404> it was a bug in pseudo
Aug 23 19:02:55 <Daemon404> and you fixed it
Aug 23 19:02:56 <Daemon404> :)
Aug 23 19:04:27 <seebs> Exception that proves the rule. :P
Aug 23 19:04:34 <Daemon404> :P
Aug 23 19:05:06 <Daemon404> btw, a fun side note: ive been using pseudo on arm with success
Aug 23 19:05:09 <seebs> Idle note: That's actually a legal principle, and the idea is that if a law specifically describes an exception, that implies that there is a rule that it is an exception to.
Aug 23 19:05:10 <Daemon404> (i know it's unsupported)
Aug 23 19:05:15 <seebs> Well...
Aug 23 19:05:31 <seebs> At this point, as of 1.4.1, I consider it "expected to work". And heck, someone's been getting it working on FreeBSD.
Aug 23 19:05:42 <Daemon404> inb4 donn
Aug 23 19:06:17 <msm> bhundven: does it boot up?
Aug 23 19:06:26 <bhundven> well see :D
Aug 23 19:07:17 <msm> bhundven: wait, why do you need a new machine.conf? why not just add u-boot image to UBOOT_MACHINES?
Aug 23 19:08:22 <bhundven> p1020utm, p1020mbg, and p1020rdb-pc are all from p1_p2_rdb_pc, why don't they all use p1020rdb-pc.conf?
Aug 23 19:08:51 <bhundven> well, and p2020rdb-pc
Aug 23 19:10:04 <bhundven> and p1_p2_rdb would be p1020rdb and p2020rdb in p1020rdb.conf...
Aug 23 19:10:12 <bhundven> I guess
Aug 23 19:11:14 <bhundven> but thats a lot of u-boot builds for making one target, and specifically, if you only care about a nor build
Aug 23 19:11:59 <bhundven> also, the dts defaults to the 32b, which isn't always used, which may be a seperate .conf
Aug 23 19:14:57 <msm> bhundven: the machine for p1020rdb-pc can't change now though
Aug 23 19:15:12 <msm> bhundven: people are expecting p1020rdb to build their p1020rdb-pc images
Aug 23 19:15:24 <msm> is there anything in place to deal with a recipe that has no license?
Aug 23 19:16:55 <bhundven> msm: np, I'll just keep my own tree as I suggested before. If you guys are deprecating that product anyways, then who cares.
Aug 23 19:18:45 <msm> hmm bye ;/
Aug 23 19:25:51 <msm> zeddii: any update on the slang issue?
Aug 23 19:30:48 <zeddii> msm, good timing. I was literally just typing up a pull request. build tests passed here.
Aug 23 19:32:26 <msm> zeddii: so i won't need anything for my kernel recipe now?
Aug 23 19:34:09 <zeddii> right. nothing.
Aug 23 19:34:16 <zeddii> the kernel.bbclass sed's the file.
Aug 23 19:37:46 <msm> zeddii: k
Aug 23 20:55:42 <RP> andyross: ping?
Aug 23 20:56:09 <RP> msm: Do we understand why the python debug path changes are needed?
Aug 23 20:57:30 <msm> RP: im not sure where modules are supposed to get
Aug 23 20:57:34 <msm> go*
Aug 23 20:57:53 <msm> RP: all i know is they were in /usr/lib when ${libdir}=/usr/lib64
Aug 23 20:58:07 <msm> so, i was initially attempting to fix that
Aug 23 21:05:41 <andyross> Here, sorry
Aug 23 21:06:48 <RP> andyross: Just looking at the binutils change - what build systems rely on rpath-link looking at the host system directories?
Aug 23 21:07:06 <RP> andyross: I get very worried reading that patch :/
Aug 23 21:07:11 <seebs> I would hope that very few if any do.
Aug 23 21:07:35 <seebs> We submitted a bug report on this to CodeSourcery/MG, and the initial response was basically "I have no idea why the linker is even looking at -rpath directories". :)
Aug 23 21:07:52 <seebs> Well, -rpath and -rpath-link are different cases, not sure about the latter.
Aug 23 21:07:56 <andyross> e2fsprogs was the first one I hit, it uses something like "-rpath-link ../lib".  But thinking about that harder I think that's actually right.  Otherwise there would be no way to pass a build-time rpath-equivalent, so what would be the point of rpath-link?
Aug 23 21:08:06 <seebs> I do not comprehend the distinction between -rpath-link and -L.
Aug 23 21:09:09 <andyross> I agree too -- "-rpath" shouldn't affect the link time search order at all.  But it does.  Maybe we can blame SunOS or something
Aug 23 21:09:24 <kergoth> pretty sure rpath-link was used when one lib linked against another, the whole implicit linking thing thats not supported anymore
Aug 23 21:09:30 <kergoth> but i could be remembering wrong
Aug 23 21:09:50 <RP> andyross: relative paths I can understand. But why would it ever need to look in the system directories?
Aug 23 21:10:21 <RP> andyross: Can we make it not looking in the system directories, ever for rpath-link or rpath
Aug 23 21:10:42 <RP> andyross: I don't mind if we have to carry that one, its insane to do anything else
Aug 23 21:10:45 <andyross> But that requires that ld know what the system directories are.  I don't think it does.
Aug 23 21:11:30 <andyross> Note that the libtool fix already filters out the system directories, and the insane.bbclass warning will catch stragglers (unless they fail first due to version skew).
Aug 23 21:11:38 <seebs> I think the system directories thing could be an unintentional side effect.
Aug 23 21:11:59 <seebs> At one point, the external CS toolchain replaced /lib/libc-mumble.so with ../../lib/libc-mumble.so in one of the linker scripts.
Aug 23 21:12:00 <andyross> But the -rpath fix, where it really was looking at polluted directories, seemed like it was provably correct and should go in
Aug 23 21:12:24 <seebs> Which ended up meaning that, if you were in a directory exactly two steps down from /, it would search host /lib.
Aug 23 21:13:04 <andyross> (Note that absolute paths with -rpath-link might very well currently be /path/to/sysroot/usr/lib already, as that's what current code has to do if it wants to hit the correct directory)
Aug 23 21:14:09 <RP> andyross: hmm, so you can't just prefix everything since it may already be prefixed
Aug 23 21:14:16 <RP> andyross: what a mess :(
Aug 23 21:14:34 <andyross> amen to that
Aug 23 21:15:17 <RP> andyross: we probably need to test if it starts with the sysroot prefix, if not, add it
Aug 23 21:15:37 <RP> assuming its an absolute path
Aug 23 21:18:26 <andyross> I guess, though the more I think about it I think the idea of "-rpath-link is a build-space path, never a target directory" is actually pretty sane.  It's always behaved that way, even if the documentation was unclear.  The whole purpose to it is to allow the linker to find stuff at link time, it doesn't affect the generated binary.
Aug 23 21:19:13 <RP> andyross: I guess. and the -rpath should always be a target path so unconditionally adding the sysroot makes sense
Aug 23 21:19:23 <andyross> So given that everything (by defintion) is already using it that way, I argue just leave it that way even if it seems insane.  Maybe we could patch in another warning condition.
Aug 23 21:19:50 <andyross> I.e. "directory specified by -rpath-link does not exist, are you trying to use a target path?"
Aug 23 21:19:52 <RP> andyross: yes, our gcc poison patches work like that
Aug 23 21:20:15 <RP> andyross: well, in a similar way - you're doing something insane, are you really sure about it? :)
Aug 23 22:24:56 <RP> msm: I've looked long and hard at the distutils stuff and it needs to install to ${D}/${PYTHON_SITEPACKAGES_DIR}
Aug 23 22:48:06 <msm> RP: so the original patch should have had that then
Aug 23 22:59:17 <msm> RP: i've sent another patch
Aug 23 23:30:42 <sgw> andyross: Hi I am still digging into the pango issue rpath issue and found that libstdc++ has a libdir=/usr/lib/../lib in it's .la file
Aug 23 23:35:07 <andyross> Can you try it again with the libtool patch I posted earlier today?  I don't have a poky build at the moment, but in our internal tree the pango/rpm rpath warnings disappeared.  I'm suspicious that I had a typo in the sed that fixed itself.
Aug 23 23:44:58 <sgw> andyross: I am building with that patch, looking into pango and rpm
Aug 23 23:45:30 <sgw> andyross: on x86 or x86-64, they are gone on x86, but not x86-64
Aug 23 23:50:43 <andyross> Hm.   OK, I'll take a look.  Your build host is 64 bit too, right?
Aug 23 23:55:20 <sgw> andyross: yes.
Aug 23 23:55:42 <sgw> I will also keep looking and let you know if I find anything
Aug 24 00:42:20 <andyross> sgw: reproduced, the /usr/lib/../lib string is all over the place in .la files.  Looks like the libtool normalization spot is too low, needs to be higher.
Aug 24 00:42:42 <sgw> yup, that's the one
Aug 24 00:43:07 <sgw> andyross: are you able to patch it or shall I keep digging?
Aug 24 00:43:51 <andyross> I'll need to debug.  This isn't directly related to anything I did (other than unmasking that error).
Aug 24 00:45:29 <sgw> I will leave you to it then and checkout other stuff
**** ENDING LOGGING AT Fri Aug 24 03:00:04 2012

**** BEGIN LOGGING AT Fri Aug 24 03:00:04 2012
Aug 24 09:55:40 <RP> morning all
Aug 24 10:04:03 <JaMa> morning
Aug 24 10:54:14 <_Lucretia_> hokay, so I still cannot build for gumstix using master (all trees), http://pastebin.com/UTfjKQab - back to defconfig does not exist on the server to download
Aug 24 12:18:50 <xxiao> bluelightning: i think i found the issue with tar-perl-recipe when building multiple platform using one sstate
Aug 24 12:19:07 <bluelightning> tar-perl ?
Aug 24 12:19:41 <xxiao> bluelightning: a second build will fail as the perl reciple can not untar to /usr/lib
Aug 24 12:21:10 <xxiao> the reason is one "private" recipe created a directory with the same name, i had to fix that recipe
Aug 24 12:21:46 <xxiao> the standard perl recipe expects /usr/lib/perl5 to be a symlink
Aug 24 12:22:04 <xxiao> so no other recipe should create "mkdir /usr/lib/perl5"
Aug 24 12:22:58 <RP> xxiao: you mean $SYSROOT/usr/bin/perl5 ?
Aug 24 12:24:17 <xxiao> sysroot-destdir/usr/lib/
Aug 24 12:25:04 <xxiao> it has a perl directory contains pm etc, then it has sysroot-destdir/usr/lib/perl5 symlink to syroot-destdir/usr/lib/perl
Aug 24 12:26:09 <xxiao> so other recipes are not supposed to create mkdir -p sysroot-destdir/usr/lib/perl5
Aug 24 12:27:28 <RP> xxiao: hmm, I can imagine how that is causing problems given the way we ue the sysroots
Aug 24 12:29:06 <RP> xxiao: I suspect if you setup the symlink in ${D} in do_install_prepend you might find things work better
Aug 24 12:29:59 <_Lucretia_> does nobody here build for gumstix?
Aug 24 12:30:11 <xxiao> RP: will try that
Aug 24 15:47:23 <JaMa> is it possible to share sstate-cache between 2 builders with different tmp-eglibc/cache/bb_persist_data.sqlite3 ? different SRCPV for e.g. gcc can invalidate a lot of sstate checksums I guess
Aug 24 15:49:48 * JaMa still wondering why I see so little sstate reuse and so many rebuilds from scratch
Aug 24 16:00:21 <RP> JaMa: the different srcpv would be an issue :/
Aug 24 16:15:14 <jwessel> Is there a simple way to invoke rm_work after you completed a build aside from modifying local.conf.
Aug 24 16:15:45 <jwessel> I had assumed that is what cleanup-workdir did, but in fact it doesn't.
Aug 24 16:16:24 <JaMa> RP: then it would make sense to use PR service to synchronize LOCALCOUNT numbers too
Aug 24 16:20:43 <RP> JaMa: agreed
Aug 24 16:21:07 <RP> jwessel: there isn't any simple way I'm aware of
Aug 24 16:21:22 <jwessel> RP: After hunting a bit, that is my conclusion as well.
Aug 24 16:21:58 <jwessel> I see back in 2010 someone suggested a KEEP variable where you could always leave it on, but default it to KEEP.
Aug 24 16:23:05 <jwessel> I was just looking for a way to iterate and purge things, because I don't see any kind of task that can purge your tmp area of what you don't need.
Aug 24 16:24:09 <jwessel> This is mainly to get someone unstuck after an update.
Aug 24 16:24:36 <jwessel> For some reason packages don't always fully get rebuilt correctly after any random update.
Aug 24 16:25:05 <jwessel> The one that comes to mind is when your config.cache needs to be removed for example.
Aug 24 16:26:16 <jwessel> Obviously you can clean out a package with bitbake -c clean and let it rebuild, but I was looking at a way to not have to reset up your environment and just clean it all away.
Aug 24 16:27:01 <RP> jwessel: Its a dilemma when to clean and when not to clean. The trouble is bitbake can't really know when to do which level of clean
Aug 24 16:27:35 <jwessel> RP: Sure, but this is a user choice.
Aug 24 16:28:42 <jwessel> In the LDAT world if a checksum of library/header you depended on changed, it made you purge your source tree.  bitbake doesn't seem to do that.  It just re-runs configure, compile etc...
Aug 24 16:29:15 <jwessel> We had a default of don't remove something unless a user had the equivlent of rm_work set.
Aug 24 16:30:18 <jwessel> And you got an error when one of these popped up and the choice I am looking for here is more or less the same in OE.   Tell me there is a problem, and then I'll decide to auto rm_work or I'll run the -c clean myself.
Aug 24 16:30:58 <jwessel> RP: Is this perhaps a dependency problem of sorts?
Aug 24 16:31:16 <jwessel> Clearly OE knows it wants to rebuild things linked against ncurses for example.
Aug 24 16:31:40 <jwessel> If you change the ncurses, but it doesn't re-unpack a fresh source of the dependent.
Aug 24 16:35:02 <RP> jwessel: I wouldn't expect it to re-unpack the source. The source didn't change
Aug 24 16:35:25 <jwessel> But that is the only way it is going to rebuild properly for a lot of packages.
Aug 24 16:36:07 <RP> jwessel: well, make unpack depend on the dependencies, not configure
Aug 24 16:37:10 <jwessel> I figure eventually I'll see the problem again with the config.cache and I was just assuming this was part of the cause.
Aug 24 16:37:11 <RP> jwessel: just add do_unpack[deptask] = "do_populate_sysroot"
Aug 24 16:37:48 <RP> jwessel: I have seen the config.cache issue but only with gcc/eglibc
Aug 24 16:38:39 <jwessel> I average about one a month in some random package.
Aug 24 16:39:01 <jwessel> My litmus test has been to try to keep the same builddir going as long as I possibly can.
Aug 24 16:39:14 <jwessel> It is a bit of an experiment at this point.
Aug 24 16:40:08 <jwessel> My builddir has gotten full of "cruft" though, and I was looking for a way to clean it :-)
Aug 24 16:41:38 <RP> jwessel: I do this too and also tend to push parallelisation beyond sane limits
Aug 24 16:41:49 <RP> hence the number of parallel fixes I generate...
Aug 24 17:02:09 <Daemon404> i wonder if a tool to build things that can be build in parallel (e.g. many deps) in a random order (using a seed, so it can be repro'd) would be useful
Aug 24 17:02:21 <Daemon404> could be useful for a "fuzzing" run
Aug 24 17:02:26 <bluelightning> Daemon404: I think we already have this somewhere...
Aug 24 17:02:39 <Daemon404> ive never seen it :o
Aug 24 17:04:26 <bluelightning> hmm, maybe I'm mistaken... could be that we just talked about it
Aug 24 18:22:43 <kergoth> heh, i never played with a random ordering thing personally, but i did make a bitbake scheduler class that inserted random delays, once
Aug 24 18:22:58 <kergoth> not quite good enough though
Aug 24 18:31:03 <khem> kergoth: delays for what ?
Aug 24 18:31:45 <kergoth> khem: Daemon404 was talking about potentially randomly ordering the parallel building of tasks to check for ordering failures
Aug 24 18:32:11 <kergoth> that should be doable from a bitbake scheduler
Aug 24 18:32:22 <kergoth> not randomly as in breaking dep order, but random within that
Aug 24 18:32:24 <kergoth> heh
Aug 24 18:33:09 <khem> I see yes
Aug 24 18:33:18 <khem> so what policy does it use now
Aug 24 18:33:23 <khem> to select runnable tasks
Aug 24 18:33:42 <khem> does it have any preference at all or alphabetical or somesuch
Aug 24 18:33:49 <kergoth> there's a linear list of tasks to be run, and it does a fair bit of sorting against that to shift it into the right order
Aug 24 18:34:01 <kergoth> presumably the sorts are stable, which would mean it'd be based on the origianl task order
Aug 24 18:34:10 <kergoth> not sure where that comes from, co uld be the order in which the files are found on disk
Aug 24 18:34:22 <khem> hmm
Aug 24 18:34:51 <khem> so essentially if we build an image twice from scratch task order is always same
Aug 24 18:35:09 <khem> provided nothing affecting depchain changed
Aug 24 18:35:34 <kergoth> probably, but havent' verified
Aug 24 18:35:37 <kergoth> i'd expect so, though
Aug 24 18:35:46 <kergoth> you could easily add a randomize to the original task list prior to the sorts
Aug 24 18:35:50 <kergoth> i bet that'd do it
Aug 24 18:35:53 <khem> it would be cool if it could choose the best amongst all runnable tasks
Aug 24 18:35:54 <kergoth> assuming the sorts are stable
Aug 24 18:36:06 <kergoth> it tries to do that already based on the length of dependency chain
Aug 24 18:36:08 <khem> I dont want randomize :)
Aug 24 18:36:17 <kergoth> e.g. if this is needed by more other tasks than that, it gets built first
Aug 24 18:36:28 <khem> I want e.g. say binutils and gcc both are runnable then please run gcc first
Aug 24 18:36:29 <Daemon404> khem, the idea is to actually run serially
Aug 24 18:36:30 <Daemon404> not parallel
Aug 24 18:36:32 <khem> since it takes longer :)
Aug 24 18:36:34 <kergoth> khem: i wrote a scheduler at one point that weighted the tasks based on their run times, stored from a previous build.
Aug 24 18:36:37 <Daemon404> in different orders
Aug 24 18:36:40 <Daemon404> generated by a seed
Aug 24 18:36:45 <Daemon404> so ti is completely reproducable
Aug 24 18:36:51 <kergoth> khem: but the changes were miniscule :\
Aug 24 18:36:54 <khem> kergoth: yeah profile based optimization thats what I was inclining to
Aug 24 18:37:26 <kergoth> khem: i'd love a coherent clean mechanism for storing info from previous builds for later builds to use. maybe just a persist data db in a place common to multiple builds, or something
Aug 24 18:37:30 <kergoth> heh
Aug 24 18:37:33 <kergoth> someday..
Aug 24 18:37:53 <khem> kergoth: agreed
Aug 24 18:38:28 <khem> new knotty is not as naughty as old knotty I like it
Aug 24 18:38:37 <kergoth> lot easier to spot real problems
Aug 24 18:38:42 <kergoth> less useless info cluttering it up
Aug 24 18:38:42 <khem> correct
Aug 24 18:39:04 <khem> and if I gaze at it enough I now know that glibc and gcc-cross are bottle necks
Aug 24 18:39:12 <kergoth> hehe, indeed
Aug 24 18:39:18 <kergoth> they jsut sit at the top of the list
Aug 24 18:39:59 <khem> and sometime eglibc dopackage and perl do_package are two task left before do_rootfs can begin
Aug 24 18:40:25 <khem> kernel modules is another bummer
Aug 24 19:11:00 <Daemon404> khem, my issue is with eglibc-locae packages
Aug 24 19:11:11 <Daemon404> it makes like 50 billion packages, and takes far longer than any otehr single package
Aug 24 19:11:15 <Daemon404> i end up beign serialized
Aug 24 19:17:06 <kergoth> if you don't want all the locales, you don't have to generate them all
Aug 24 19:17:22 <kergoth> iirc, GLIBC_GENERATE_LOCALES ?= "en_US en_US.UTF-8"
Aug 24 19:17:25 <kergoth> or whatever
Aug 24 19:17:38 <Daemon404> hmm
Aug 24 19:17:44 <Daemon404> was that documented in the handbook?
Aug 24 19:17:46 <Daemon404> or just wiki
Aug 24 19:18:01 <Daemon404> google only finds a wiki page that may or may not actually be linked anywhere
Aug 24 19:18:11 <kergoth> i don't read the docs, no clue
Aug 24 19:18:18 <Daemon404> oh.. local.conf.sample
Aug 24 19:18:18 <Daemon404> derp.
Aug 24 19:40:45 <AdityaGandhi> Hi Guys, I am trying to compile a kernel for the crown-bay platform from the latest git master branch, both for pok and meta-intel. I have a problem with | ERROR: Function failed: do_validate_branches (see /home/inforcecomputing/build/poky/build/tmp/work/crownbay-poky-linux/linux-yocto-3.4.7+git1+d7a96809a585e06933d8c08adb9b9f66b21efb4c_1+19f7e43b54aef08d58135ed2a897d77b624b320a-r4.0/temp/log.do_validate_branches.19740 for further information)
Aug 24 19:41:05 <AdityaGandhi> I get a validate_branches error
Aug 24 19:42:38 <AdityaGandhi> http://pastebin.com/Y66VEfVp
Aug 24 19:42:46 <AdityaGandhi> is this a know issue?
Aug 24 19:43:48 <zeddii> not known per-se, but meta-intel has the wrong branch in the 3.4 bbappend.
Aug 24 19:44:04 <zeddii> it should be standard/crownbay , not standard/default/crownbay.
Aug 24 19:54:27 <msm> shouldn't RPROVIDES in my recipes be getting extended in the multilib case?
Aug 24 20:03:37 <AdityaGandhi> zeddii: thanks a lot, but which file do I change for this?
Aug 24 20:06:55 <zeddii> meta-intel/meta-crownbay/recipes-kernel/linux/linux-yocto_3.4.bbappend
Aug 24 20:06:56 <zeddii> KBRANCH_crownbay  = "standard/default/crownbay"
Aug 24 20:07:00 <zeddii> KBRANCH_crownbay  = "standard/crownbay"
Aug 24 20:25:45 <AdityaGandhi> thanks
Aug 24 20:26:00 <AdityaGandhi> did that and it compiled fine,
**** ENDING LOGGING AT Sat Aug 25 03:00:04 2012

**** BEGIN LOGGING AT Sat Aug 25 03:00:05 2012
Aug 25 03:40:35 <xxiao> what's the alternative for udev in yocto
Aug 25 03:40:59 <xxiao> udev gave me troubles, udevadm settle - timeout of 180 seconds reached
Aug 25 03:41:04 <xxiao> so far could not fix that
Aug 25 03:41:53 <kergoth> you could use udev, mdev, or devtmpfs if your kernel is new enough
Aug 25 03:42:28 <xxiao> kergoth: arhh thanks, i have always been using devtmpfs recently, let me double check my kernel config
Aug 25 03:43:27 <kergoth> i guess you should be able to just exclude udev from your build via the appropriate VIRTUAL-RUNTIME variable and let devtmpfs handle it
Aug 25 03:43:32 <kergoth> but i haven't played with that myself
Aug 25 03:44:24 <xxiao> i have been using devtmpfs for almost a year, worked wonderfully for me
Aug 25 03:44:46 <xxiao> so i took it for grandted that this kernel has it on by default, which is not the case
Aug 25 03:45:04 <xxiao> thanks for the reminder, trying now
Aug 25 03:52:55 <kergoth> np
Aug 25 03:53:04 * kergoth adds a todo to play with it himself
Aug 25 03:57:09 <xxiao> odd, ifconfig shows only lo, but ifconfig eth0 will show eth0
Aug 25 03:58:40 <kergoth> so the interface exists, but it's not up
Aug 25 03:58:42 <kergoth> see also 'ifconfig -a'
Aug 25 03:58:47 <kergoth> which shows all interfaces, including down ones
Aug 25 03:58:54 <kergoth> check the config in /etc/network/interfaces
Aug 25 04:05:59 <xxiao> kergoth: right, usually ifconfig -a will show it, but in  this case somehow even ifconfig -a showed nothing
Aug 25 04:09:03 <kergoth> weird.
Aug 25 04:09:41 <xxiao> yes, that happened after i added devtmpfs, will look into it, ifconfig -a always worked for me before that
Aug 25 04:09:48 * xxiao is trying to find the place to remove udev
Aug 25 04:13:12 <kergoth> see VIRTUAL-RUNTIME_dev_manager
Aug 25 04:13:28 <kergoth> line 21 of task-core-boot pulls it in with ?=, so you should be able to just define VIRTUAL-RUNTIME_dev_manager = ""
Aug 25 04:13:31 <kergoth> in local.conf
Aug 25 04:13:32 <kergoth> afaict
Aug 25 04:14:22 <xxiao> it's actually pretty hard to find thing like that when you have all those meta layers esp when certain bb is pulled in by dependencies etc
Aug 25 04:15:33 <xxiao> find meta* -name "*.conf" | xargs grep --color dev_manager  showed nothing
Aug 25 04:15:56 <kergoth> it's not in a .conf, it's a recipe
Aug 25 04:16:07 <kergoth> i recommend installing ack — http://betterthangrep.com/
Aug 25 04:16:17 <xxiao> i c
Aug 25 04:16:26 <xxiao> found it, s you said, task-core-boot.bb
Aug 25 04:16:26 <kergoth> then https://bitbucket.org/kergoth/dotfiles/src/185492235afc/ackrc as ~/.ackrc
Aug 25 04:16:36 <kergoth> then just 'ack -w udev' or whatever
Aug 25 04:16:47 <kergoth> with that ackrc, since it teaches it how to recognize bitbake file formats
Aug 25 04:16:49 <xxiao> yeah never used ack
Aug 25 04:16:52 <kergoth> you can alias bback="ack --type=bitbake"
Aug 25 04:16:54 <kergoth> then bback udev
Aug 25 04:16:57 <kergoth> will only search bitbake files
Aug 25 04:17:04 <kergoth> it's like grep, but less annoying
Aug 25 04:17:07 <xxiao> need learn that, thanks!
Aug 25 04:17:10 <kergoth> searches the current directory recursively by default, etc
Aug 25 04:17:27 <kergoth> only hits recognized file types unless you pass -a, so it's quick and tends to skip .o, etc automatically
Aug 25 04:18:19 <kergoth> of course, grep -nrI -w udev . or something works, but it's so terribly slow..
Aug 25 04:18:20 <kergoth> heh
Aug 25 04:20:26 <kergoth> if you export ACKRC=.ackrc, it'll actually use one that's in the current directory if one exists, so you can copy ~/.ackrc to .ackrc; printf '—ignore-dir=build\n' >> .ackrc; if you want to tweak how it behaves within a certain project, to hide stuff only from there. it's not ideal, since it only hits the .ackrc int he current directory, and you hace to duplicate config from ~/.ackrc, but it gets the job done
Aug 25 04:20:36 <kergoth> </rambling about tools and dotfiles>
Aug 25 04:20:50 <kergoth> s/hace/have/
Aug 25 04:21:48 <xxiao> grep is so frequently used probably all distro should do ln -s ack grep soon
Aug 25 04:22:00 <xxiao> i heard about ack a while ago but never invested time into it, seems it's about time
Aug 25 04:22:19 <kergoth> hehe, that'd break compatibility with every shell script out there due to the differing command line syntax
Aug 25 04:22:32 <kergoth> just a matter of retraining your fi ngers instead
Aug 25 04:22:33 <xxiao> right
Aug 25 04:22:48 <kergoth> or using an alias, since that doesn't go into child processes
Aug 25 19:42:34 <xxiao> VIRTUAL-RUNTIME_dev_manager = ""
Aug 25 19:42:50 <xxiao> adding that to my image.bb still pulls in udev, strange
Aug 25 19:59:38 <xxiao> had to change recipes-core/tasks/task-core-boot.bb instead
Aug 25 22:11:44 <kergoth> xxiao: as i said, it's used by task-core-boot. one recipe can't affect another recipe by design, they're isolated. you have to modify the task or add the define to an appropriate file in your config metadata. local.conf, site.conf,, your distro, whatever
Aug 25 22:13:07 <xxiao> right, for this case somehow it did not take my setting at local.conf, odd
Aug 25 22:18:56 <xxiao> kergoth: for perl-native and perl recipes, which one runs on the target from the naming?
Aug 25 22:19:13 <xxiao> is perl-native meant for the target rootfs?
Aug 25 22:19:19 <xxiao> or perl
Aug 25 22:19:39 <xxiao> turns out i need add perl to both SDK and target rootfs
Aug 25 22:20:26 <kergoth> -native *always* means it's built to run on the build machine
Aug 25 22:20:33 <kergoth> cross means built to run on the build machine, but for the target
Aug 25 22:20:38 <kergoth> non-suffixed is target
Aug 25 22:20:42 <kergoth> s/cross/-cross/
Aug 25 22:21:01 <kergoth> the perl build requires perl-native, as it needs to be able to run the perl interpreter for the same perl version
Aug 25 22:21:14 <kergoth> which we can't guarantee if we use the build machine's existing perl (assuming it even has it)
Aug 25 22:21:17 <xxiao> i think , on angstrom, when native-sdk is mentioned, it means something like gcc on the target?
Aug 25 22:21:20 <kergoth> so that's why perl-native gets built
Aug 25 22:21:23 <kergoth> nope
Aug 25 22:21:28 <kergoth> nativesdk is something else entirely
Aug 25 22:21:37 <kergoth> :)
Aug 25 22:21:42 <xxiao> gosh
Aug 25 22:21:52 <kergoth> nativesdk is essentially for producing toolchains
Aug 25 22:21:56 <xxiao> for me native always implied the target, i.e. non-cross
Aug 25 22:22:00 <kergoth> but it can target a different build machine architecture
Aug 25 22:22:19 <kergoth> e.g. with nativesdk you can be building on an x86_64 machine, but produce a toolchain that can run on i586
Aug 25 22:22:21 <xxiao> cross, canadian-cross, native
Aug 25 22:22:45 <kergoth> crosssdk is essentially a canadian cross build
Aug 25 22:22:55 <kergoth> the cross version of nativesdk
Aug 25 22:23:06 <xxiao> canadian-cross is meant for building toolchain, other than that, cross means arm-linux-gcc, native means gcc on the arm target, for me
Aug 25 22:23:42 <kergoth> yeah, thats not the case in oe or yocto
Aug 25 22:23:49 <kergoth> you'll need to learn the different terminology
Aug 25 22:24:11 <kergoth> target means target. native means built to run natively on the current machine, not the targeted machine
Aug 25 22:26:43 <xxiao> if the 'current machine' means x86 build machine, so you mean oe needs its specific version of gcc/tar/etc from the host ditro default installations?
Aug 25 22:28:35 <xxiao> looks like i need add perl-native to adt SDK, then add perl to rootfs, correct?
Aug 25 22:28:40 <xxiao> both are missing
Aug 25 22:29:22 <kergoth> no
Aug 25 22:29:37 <kergoth> perl-native doesn't emit anything for any sdks, it's used to build and install into the internal sysroot only
Aug 25 22:29:47 <kergoth> again, nativesdk and crosssdk target sdk emission
Aug 25 22:29:55 <kergoth> that said, i've never touched the adt
Aug 25 22:30:16 <kergoth> current machine means your build machine, no one ever required that it be x86, that's just generally the case. but it's not hardcoded.
Aug 25 22:31:01 <xxiao> i need crosscompile a perl module and install it to the rootfs, it keeps pulling in my host's perl version, plus I don't have perl at all on the target yet
Aug 25 22:31:02 <kergoth> to crosscompile things, we have certain host/build machine requirements that we can't rely on always being satisfied, so we build our own.
Aug 25 22:31:09 <kergoth> also, in some cases we have to patch things to use for the build process
Aug 25 22:31:21 <kergoth> e.g. autoconf, automake, libtool
Aug 25 22:31:46 <xxiao> understand that.
Aug 25 22:32:29 <kergoth> if you want perl on the target, add perl to IMAGE_INSTALL. nothing to it. for building a perl module, presumably we have a class that does the heavy lifting for you
Aug 25 22:33:16 <xxiao> i need add perl and all the default modules to rootfs, meanwhile i need crosscompile one module outside yocto
Aug 25 22:35:04 <xxiao> adding perl to image is easy, but crosscompile a module externally is not
Aug 25 22:35:21 <xxiao> i think i need the same version perl to be included into SDK
Aug 25 22:36:01 <xxiao> crossmake -f Makefile.PL only likes the host build env
Aug 25 22:36:03 <kergoth> it'd be a lot easier to just make a recipe for it, but it sounds like you want nativesdk/crosssdk packages of some sort. never played with the adt sdk personally
Aug 25 22:36:22 <kergoth> i'd just make a recipe for it, myself :)
Aug 25 22:37:05 <xxiao> this package contains kernel module, user apps, perl, and all that, i tried to make a few recipes and it's too complicated for me
Aug 25 22:37:25 <xxiao> so i'm doing it externally to get it working first, everything works fine except this perl module
Aug 26 02:11:58 <ag_> Hello all.
Aug 26 02:12:58 <ag_> Any idea why a preferred provider even if is correctly added in machine.conf is not working? ERROR: Multiple .bb files are due to be built which each provide virtual/egl (/home/agherzan/work/personal/yocto/meta-raspberrypi/recipes-bcm/vc-graphics/vc-graphics-hardfp.bb /home/agherzan/work/personal/yocto/poky-contrib/meta/recipes-graphics/mesa/mesa-dri_8.0.4.bb).
Aug 26 02:14:24 <ag_> vc-graphics-hardfp provides virtual/egl
Aug 26 02:19:06 <ag_> And i have PREFERRED_PROVIDER_virtual/egl ?= "vc-graphics-hardfp"
Aug 26 02:27:51 <ag_> No ideas?
Aug 26 02:30:18 <kergoth> the message tells you what's happening
Aug 26 02:30:33 <kergoth> it's being built anyway, which means something is depending on it without using virtual/egl, most likely
Aug 26 02:30:41 <kergoth> it's being pulled in via  a different path
Aug 26 02:37:40 <ag_> kergoth: Makes sense. Thank you.
Aug 26 02:40:33 <kergoth> np
Aug 26 02:40:42 <kergoth> unfortunately its a royal pain to figure how why it's coming in
Aug 26 02:40:50 <kergoth> you can use bitbake -g, but it doesn't always ahve enough information
Aug 26 02:40:52 <kergoth> its a start, though
Aug 26 02:41:51 <ag_> Yeah i know... thank you once again.
Aug 26 02:42:17 <kergoth> best to check what it mentions — the common case, which is one provider having something provided that the other doesn't. whether that's something from PROVIDES, or a binary package
Aug 26 02:42:20 <kergoth> np
Aug 26 02:43:02 <ag_> Well.
Aug 26 02:43:07 <ag_> It is the case here.
Aug 26 02:43:48 <ag_> mesa-dri provides virtual/libgles1 and rpi doesn't.
Aug 26 02:43:54 <ag_> So it could be something form here.
Aug 26 02:44:05 * kergoth nods
Aug 26 02:44:29 <xxiao> does perl recipe come along with some modules? i added perl to sdk and it's installed, but not a single pm is included
Aug 26 02:45:10 <ag_> kergoth: One more thing. Sorry for arguing with you about the subject prefix in bitbake.
Aug 26 02:45:29 <ag_> I was pretty sure we were all talking about bitbake in yocto.
Aug 26 02:45:34 <ag_> Slap!
Aug 26 02:45:48 <kergoth> ag_: changes flow up into bitbake.git, then back down into poky.git
Aug 26 02:45:55 <kergoth> generally speakin
Aug 26 02:45:56 <kergoth> g
Aug 26 02:46:11 <kergoth> np
Aug 26 02:46:19 <ag_> Thanks.
**** ENDING LOGGING AT Sun Aug 26 03:00:00 2012

**** BEGIN LOGGING AT Sun Aug 26 03:00:00 2012
Aug 26 03:55:57 <xxiao> kergoth: ping
Aug 26 06:22:02 <pidge> All: autobuilder is going down for maintenance. ETA for it's return is tomorrow @ 3pm.
Aug 26 15:06:55 <nshine> hey all
Aug 26 15:08:04 <nshine> Is it possible to run full p4080ds board with qemuppc?
Aug 26 15:08:39 <nshine> I mean to virtualize the board itself, ot just the e500mc chips from qemuppc and not just on the physical board
Aug 26 18:20:08 <Daemon404> nshine, for full-board emulation, you might have to use simics
Aug 26 18:20:13 <Daemon404> dotn quote me though.
Aug 26 18:21:40 <nshine> Maybe, Also tried to build fsl image for i686 host using e500mc... and a red message was shown "report a bug"
Aug 26 18:21:41 <nshine> :)
Aug 26 18:22:10 <nshine> Anynone here maybe try in the past to simulate e500mc on i686 host?
Aug 26 18:22:14 <nshine> emulate* :)
Aug 26 21:02:10 <xxiao> nshine: seems like qemuppc is just for e300/e600, never tried e500/e500mc/e5500/e6500, those might need simics indeed?
Aug 26 21:05:26 <nshine> should
Aug 26 21:05:38 <nshine> be its seems like qemu support e500
Aug 26 21:06:17 <nshine> http://wiki.qemu.org/ChangeLog/1.1 "We can now emulate e500mc cores, but no e500mc based board is emulated yet. You need to use -M mpc8544ds and a special guest kernel"
Aug 26 21:06:21 <nshine> 1.1 was before a long time ago :)
Aug 26 21:08:00 <xxiao> hmm never tried that
Aug 26 21:08:11 * xxiao always wish debian supports e500, sigh
Aug 26 21:09:17 <nshine> Don't try debian.. it just don't work :-\
Aug 26 21:09:27 <nshine> Too legacy..
Aug 26 21:09:33 <nshine> also seems like having problem with the ppc bios
Aug 26 21:09:47 <xxiao> debian works well for e300/e600
Aug 26 21:10:00 <xxiao> it's just e500's odd FPU caused all those troubles
Aug 26 21:10:47 <nshine> ;\
Aug 26 21:11:01 <nshine> I need a way to work with that e500mc :\
Aug 26 21:11:08 <nshine> on normal intel linux :)
Aug 26 21:11:40 <nshine> I also tried fsl git.. problems as well.
Aug 26 21:16:25 <nshine> "ERROR: User requested feature fdt ERROR: configure was not able to find it"
Aug 26 21:16:28 <nshine> ;-( tried 1.1.1
**** ENDING LOGGING AT Mon Aug 27 02:59:57 2012

**** BEGIN LOGGING AT Mon Aug 27 02:59:58 2012
Aug 27 07:47:06 <yegorich> Hi! I've added poky/meta-openembedded/meta-efl to my bblayers.conf. What should I add to meta-yocto/conf/machine/beagleboard.conf to get Enlightenment installed and activated?
Aug 27 10:06:44 <snkt> root/msg NickServ identify root123
Aug 27 10:07:06 <snkt> hello all
Aug 27 10:07:50 <snkt> i had builded core-image-cdv-media ...... but I have to compile qt4 on it?
Aug 27 10:07:54 <snkt> how can I?
Aug 27 10:58:31 <yegorich> When adding IMAGE_INSTALL_append = " task-x11-illume" I get following error
Aug 27 10:59:03 <yegorich> ERROR: Function failed: task-x11-illume: LIC_FILES_CHKSUM points to an invalid file: ../mybuilds/meta-openembedded/meta-efl/COPYING.MIT
Aug 27 11:57:57 <ag_> Hello. Anybody saw this?
Aug 27 11:58:08 <ag_> scripts/bitbake: fork: retry: Resource temporarily unavailable
Aug 27 11:58:25 <ag_> scripts/bitbake: fork: retry: No child processes
Aug 27 11:58:42 <ag_> [...]
Aug 27 11:58:55 <ag_> awk: cmd. line:1: END { exit ( !(  > 1.23)); }
Aug 27 11:58:56 <ag_> awk: cmd. line:1:                  ^ syntax error
Aug 27 11:58:56 <ag_> awk: cmd. line:1: END { exit ( !(  > 1.23)); }
Aug 27 11:58:56 <ag_> awk: cmd. line:1:                         ^ syntax error
Aug 27 11:58:56 <ag_> awk: cmd. line:1: END { exit ( !(  > 1.23)); }
Aug 27 11:58:56 <ag_> awk: cmd. line:1:                          ^ syntax error
Aug 27 11:58:59 <blitz00> check ulimit
Aug 27 11:59:01 <blitz00> ulimit -a
Aug 27 11:59:18 <ag_> max user processes?
Aug 27 11:59:20 <blitz00> and increase  max user processes for your shell
Aug 27 11:59:24 <blitz00> yup
Aug 27 11:59:25 <ag_> 1024
Aug 27 11:59:52 <ag_> I need more than 1024?
Aug 27 12:00:16 <blitz00> yeah you'll need more.
Aug 27 12:00:33 <ag_> thanks
Aug 27 12:34:31 <BjornArnelid> Hi, I am getting a nullpointer exception when i am trying to set up yocto eclipse plugin in ubuntu 12.04, is this a known bug or am i doing something wrong?
Aug 27 14:42:15 <ignus> hello all
Aug 27 15:42:00 <peachj> I'm trying to add a new task to my builds.  It's called do_log_srcrev.  The task executes as expected until I want to use sstate with it.
Aug 27 15:42:05 <peachj>   Once I try to add the appropriate variables for doing sstate, I get an ugly error string that ultimately dies with KeyError: 'do_log_srcrev' occurring in sstate_checkhashes.
Aug 27 15:42:31 <peachj> Any clues as to why that might happen before I roll up my sleeves and dig deep into the code?
Aug 27 17:45:44 <msm> zeddii: are all slang fixes in master?
Aug 27 17:46:34 <zeddii> saul sent an 'applied' email this morning. so AFAIC, they are.
Aug 27 18:01:31 <sgw> msm: zeddii: Yes, the slang fix is in oe-core and poky master
Aug 27 18:01:53 <thaytan> hey hey
Aug 27 18:01:58 <sgw> zeddii: I am seeing this warning
Aug 27 18:02:03 <sgw> find: warning: -path /intel/poky/builds/sanity/tmp/work/qemux86-poky-linux/linux-yocto-3.4.7+git17+28bcd46af1d592dab39bd8a0891c872454fde8bc_5+c77666c1d4c4be4be4b2046c3ff25bf1db34eb21-r4.0.1/linux/ will not match anything because it ends with /.
Aug 27 18:02:32 <sgw> any ideas where it might come from, this is with meta-tlk in the BBLAYERS list
Aug 27 18:02:45 <sgw> thaytan: you must be on the west coast
Aug 27 18:02:47 <JaMa> sgw: I've reported it about month ago with other weird warnings from linux-yocto
Aug 27 18:03:12 <zeddii> sgw. yah, its from the tools. I'm working on a small bug fix series.
Aug 27 18:03:28 <sgw> Ah Ok, just wondering
Aug 27 18:03:32 <thaytan> sgw: @ LinuxCon
Aug 27 18:03:40 <thaytan> well, GStreamer con these first 2 days
Aug 27 18:03:51 <zeddii> sgw. I'll fire something off for a bunch of minor items in a bit.
Aug 27 18:03:53 * zeddii goes back to it.
Aug 27 18:03:55 <sgw> thaytan: figured, I remember you saying something about that.
Aug 27 18:04:08 <JaMa> sgw: http://lists.linuxtogo.org/pipermail/openembedded-core/2012-June/024593.html
Aug 27 18:05:23 <sgw> JaMa: yeah that's the one, sounds like he is working on it, time for me to tackle a few bug fixes while it's quiet!
Aug 27 19:50:58 <msm> i'll be near linuxcon this week (for those that want to harass me)
Aug 27 19:54:59 <zeddii> msm, near ? i.e. plumbers ?
Aug 27 19:58:38 <msm> zeddii: yea, ill be doing plumbers
Aug 27 19:59:36 <zeddii> cool. I head down tomorrow morning.
Aug 27 19:59:49 <zeddii> plumbers + linux con (a bit).
Aug 27 20:01:57 <khem> bluelightning: did you get a chance to try the collie images ?
Aug 27 20:02:35 <bluelightning> khem: not yet I'm afraid no
Aug 27 20:02:43 <khem> bluelightning: ok, np
Aug 27 20:03:10 <khem> latest qemu supports cortex-a15 thats nice
Aug 28 01:16:12 <msm> is there a way to run a sstate-cache mirror check without actually doing anything?
Aug 28 01:55:40 <evanp> anyone know the use case for the task lockfiles-shared attribute?
Aug 28 02:32:55 <evanp> I'm seeing a build race due to the shared ${S} between gcc-cross-initial, libgcc, and gcc-runtime; bitbake tries to run do_unpack, do_headerfix, and do_patch concurrently.
Aug 28 02:33:27 <evanp> apparently I've got an SMP machine wide enough that the timing is right quite reliably
Aug 28 02:34:54 <evanp> I see in the recipe code that do_unpack/do_headerfix/do_patch all have [stamp-base] = "${SS}"
Aug 28 02:35:41 <evanp> I assume what's happening is that the multiple threads all ask "does this task have a stamp?", and the answer in all those threads is "no"....
Aug 28 02:39:38 <evanp> I thinking this may be solvable using a [lockfile], but I'm not sure if the lock guards stamp check or not....
**** ENDING LOGGING AT Tue Aug 28 03:00:03 2012

**** BEGIN LOGGING AT Tue Aug 28 03:00:03 2012
Aug 28 03:13:00 <evanp> doesn't look like it
Aug 28 03:42:08 <evanp> I don't really see any easy way to ensure do_unpack/do_headerfix/do_patch execute exactly once unless I do something like docbook-utils-native_0.6.14.bb:do_configure_prepend does....
Aug 28 03:53:09 <evanp> maybe I've been looking at this too long, but now I don't see what keeps do_unpack from running multiple times for each of gcc-cross-initial, gcc-runtime, and libgcc in the normal case where they aren't attempted concurrently....
Aug 28 03:53:27 <RP__> evanp: Those have a shared work directory
Aug 28 03:53:36 <evanp> yeah, exactly
Aug 28 03:54:25 <RP__> evanp: The code adding that is at the end of gcc-common.inc
Aug 28 03:55:23 <RP__> evanp: The ${SS} and ${SW} bits
Aug 28 03:55:31 <evanp> right
Aug 28 03:56:13 <evanp> my problem is that there's a build race; the do_unpack/do_headerfix/do_patch steps of gcc-cross-internal, gcc-runtime, and/or libgcc get executed concurrently
Aug 28 03:56:19 <evanp> and then, obviously, blow up
Aug 28 03:57:23 <evanp> e.g. because one of the do_unpacks throws OSError because ${S} is nonempty while do_patch fails because the patch has already been applied
Aug 28 03:57:42 <RP__> evanp: You only see this if you have OEBasicHash enabled and the stamps for your tasks don't match
Aug 28 03:57:52 <RP__> evanp: assuming you're using shared work directories
Aug 28 03:58:14 <RP__> evanp: run bitbake-diffsigs on the things you thing should be the same. The results are often illuminating
Aug 28 03:58:52 <RP__> evanp: I agree this should be more obviously warned about by bitbake, perhaps you could file an enhancement request for that?
Aug 28 04:00:06 <evanp> are stamps checked during the build, or only at the beginning? I was looking at the code and the only stamp check I found was in runqueue....granted, I don't really understand what I'm looking at
Aug 28 04:04:32 <evanp> I should mention that I'm starting from a completely new build/
Aug 28 04:10:45 <evanp> also, while it's not bitbake-diffsigs, I did do "bitbake -e {gcc-cross-initial,gcc-runtime,libgcc} | grep BB_BASEHASH_task-do_unpack" and verify those all matched
Aug 28 04:11:39 <evanp> when it finishes what it's doing now I'll do bitbake-diffsigs
Aug 28 04:16:55 <evanp> RP__: it looks like adding do_{unpack,headerfix,libgcc}[lockfiles] = "${SW}.unpack.lock" also fixes the race
Aug 28 04:40:59 <evanp> RP__: bitbake-diffsigs on libgcc do_unpack vs. gcc-runtime do_unpack says nothing
Aug 28 04:42:44 <evanp> RP__: bitbake-diffsigs on libgcc do_unpack vs. gcc-cross-initial do_unpack says "Dependency on task libgcc_blah.bb.do_fetch was added ... Dependency on task gcc-cross-initial_blah.bb.do_fetch was removed"
Aug 28 04:42:52 <evanp> RP__: not sure what to make of that
Aug 28 06:14:14 <snkt> hello
Aug 28 06:15:47 <snkt> I m builded core-image-cdv-media from Yocto... I have to compile qt4 sdk on it... can anyone help me... how can I ?
Aug 28 07:17:29 <bluelightning> morning all
Aug 28 07:23:27 * B4gder gets reminded there's the AB meeting today
Aug 28 08:37:30 <Zagor> RP__: do you think I should already cc the ptest discussion to oe-core?
Aug 28 08:38:22 <Zagor> it'd be a bit odd to do it mid-thread though...
Aug 28 08:38:59 <B4gder> Zagor: you should probably repost the patch thread to that list, adressing the feedback you already got etc
Aug 28 08:39:38 <B4gder> then reply to the yocto mail, pointing to the continued discussion on oe-core
Aug 28 08:39:38 <Zagor> yeah, I don't want to run two parallell threads though, duplicating the posts
Aug 28 08:42:30 <Zagor> right, moving it sounds reasonable
Aug 28 09:28:45 <BjornArnelid> Hi, is there a reason why host folder must be named "*-pokysdk-linux" in sysroot?
Aug 28 10:35:49 <ignus> hi all, is there any documentation anywhere which explains what is contained in the various core-image* images?
Aug 28 10:47:08 <bluelightning> ignus: there's a section in the manual I think, one sec
Aug 28 10:47:35 <bluelightning> ignus: http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#ref-images
Aug 28 10:50:43 <ignus> bluelightning, i had a look at that earlier but it seem to have the same info as there is at the top of each recipe
Aug 28 10:51:27 <bluelightning> ignus: it probably is, yes
Aug 28 10:52:13 <ignus> bluelightning, i suppose ill just build a few of them and see what they look like...
Aug 28 11:01:31 <ignus> bluelightning, any idea what might cause this? http://pastebin.com/pxfagxv6
Aug 28 11:08:44 <bluelightning> ignus: do you have xattr in DISTRO_FEATURES ?
Aug 28 11:11:17 <ignus> bluelightning, where does DISTRO_FEATURES usually live?
Aug 28 11:11:42 <bluelightning> ignus: well, first thing to check is bitbake -e | grep ^DISTRO_FEATURES=
Aug 28 11:11:59 <bluelightning> but normally it can be found in your distro config
Aug 28 11:12:17 <JaMa> qemu-native now failing without libX11?
Aug 28 11:12:19 <JaMa> |   LINK  i386-softmmu/qemu
Aug 28 11:12:19 <JaMa> | /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lX11
Aug 28 11:12:23 <JaMa> that's new
Aug 28 11:16:11 <ignus> bluelightning, doesnt look like its in there. can i just do a += in the layer.conf?
Aug 28 11:16:53 <bluelightning> ignus: you shouldn't, no... if you're using your own custom distro config then that's where that change belongs
Aug 28 12:54:12 <bluelightning> JaMa: hmm I get the same thing here
Aug 28 13:16:46 <JaMa> hmm openembedded-core/scripts/sstate-cache-management.sh now removes more then it should for change
Aug 28 13:19:24 <bluelightning> JaMa: can you be more specific?
Aug 28 13:20:02 <JaMa> I'm doing 6th build to narrow that a bit
Aug 28 13:20:23 <JaMa> but last try with -L used and everything downloaded from SSTATE_MIRROR just removed everything..
Aug 28 13:27:07 <bluelightning> that script could really use a dry-run mode...
Aug 28 13:30:54 <JaMa> bluelightning: it shows what it's planning to remove but it's really hard to notice something is wrong (except the case when it removes everything and you count all files before starting it :))
Aug 28 13:49:13 <JaMa> bluelightning: specific info updated in https://bugzilla.yoctoproject.org/show_bug.cgi?id=2897
Aug 28 13:50:04 <bluelightning> JaMa: thanks
Aug 28 14:59:38 * RP__ has joined
Aug 28 15:00:02 <scottrif> Scott Rifenbark joined the meeting
Aug 28 15:00:15 <tomz2> Tom Z here
Aug 28 15:00:17 <Zagor> Björn Stenberg joined the meeting
Aug 28 15:00:27 <adamian> Alex Damian joined
Aug 28 15:00:30 * sgw YPTM: Saul has joined 
Aug 28 15:00:44 <RP__> hi Song_Liu
Aug 28 15:00:46 <strassek> YPTM: Kevin Strasser is here
Aug 28 15:00:54 <Song_Liu> YPTM: Hi everyone, let's get started with the YP technical team meeting. Please let me know who's on the bridge.
Aug 28 15:01:13 <cristianiorga> Cristian Iorga is on the bridge and in audio
Aug 28 15:01:25 <cristianiorga> and on chat :-D
Aug 28 15:01:44 <davest> YPTM davest is on the call
Aug 28 15:02:01 <nitink> YPTM: Nitin joined
Aug 28 15:02:12 <bluelightning> YPTM: Paul & Belen joined
Aug 28 15:02:21 <davest> YPTM: you missed me
Aug 28 15:02:26 <Zagor> did you miss me? Björn Stenberg
Aug 28 15:02:31 <davest> YPTM: np
Aug 28 15:03:34 * moolinex joined YPTM
Aug 28 15:03:44 <Song_Liu> YPTM: please let me know you opens
Aug 28 15:03:56 <adamian> no opens for me
Aug 28 15:04:15 <sgw> autobuilder from pidge when she joins
Aug 28 15:04:18 * RP__ should mention nativesdk
Aug 28 15:04:37 <pidge> YPTM: Calling in. cell issue
Aug 28 15:05:01 <darknighte> Song_Liu: YPTM: Dialed in
Aug 28 15:06:08 <pidge> Song_Liu: Joined. Autobuilder status and plans for my open.
Aug 28 15:07:29 * fusman dialing in
Aug 28 15:07:36 <Song_Liu> YPTM: https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.3_Status#Milestone_3
Aug 28 15:09:56 * halstead won't made the YPTM today. I'm on my way to the airport.
Aug 28 15:10:48 <rburton> YPTM: ross, late.
Aug 28 15:36:01 <moolinex> rburton: thanks :D i was next on the list
Aug 28 15:36:11 <zeeblex> :))
Aug 28 15:36:19 <rburton> moolinex: i should have checked the state before offering!
Aug 28 15:36:29 <zeeblex> :))
Aug 28 15:36:32 <rburton> hm, could be worse
Aug 28 15:37:07 <zeeblex> what if mihai goes on vacation next week?
Aug 28 15:37:20 <zeeblex> :D
Aug 28 15:40:30 <darknighte> YPTM: Song_Liu: back in the call
Aug 28 15:43:29 <davest> YPTM: Ah, the clicking returns to the bridge.
Aug 28 15:45:46 <moolinex> rburton: yeah, worse, it could have been me
Aug 28 15:46:31 <moolinex> :D
Aug 28 15:52:36 <bluelightning> wow, that's some serious clicking there
Aug 28 15:52:46 <Zagor> from me?
Aug 28 15:52:54 <moolinex> is that morse code?
Aug 28 15:52:55 <bluelightning> not sure who it is...
Aug 28 15:52:57 <bluelightning> heh
Aug 28 15:53:00 <Zagor> ah no I here it too
Aug 28 15:53:04 <Zagor> *hear
Aug 28 15:53:05 <darknighte> bluelightning: yep.  and RP__ has an *awesome* hum.
Aug 28 15:53:06 <cristianiorga> morsel code, maybe??
Aug 28 15:53:18 <RP__> darknighte: hotel phone :/
Aug 28 15:54:02 <Song_Liu> YPTM: thank you all for joining the meeting. Have a nice day/evening!
Aug 28 15:54:21 <darknighte> RP__: heh.  not sure which is better.  I'm using my laptop and it just cut out in the middle and I had to reboot the darn thing to get the network to reconnect.
Aug 28 15:54:30 <rburton> RP__: you did sound very far away :)
Aug 28 15:54:53 <darknighte> rburton: that's just cause RP__ is far from home.  ;)
Aug 28 15:54:56 <RP__> darknighte: With my networking issues an IP was a non-starter
Aug 28 15:55:12 <Zagor> I'm never sure what exactly is on-topic on these meetings :-)
Aug 28 15:55:27 <rburton> RP__: tried ip over dns tunnel?
Aug 28 15:55:27 * RP__ is far from home. The flights yesterday were driving me crazy towards the end
Aug 28 15:55:42 <RP__> rburton: wondered about it before
Aug 28 15:56:32 <darknighte> Zagor: understandable. personally, I thought it was good to solicit feedback on the call.
Aug 28 15:57:06 <darknighte> of course, there's always the concern that people not on the call won't know what was discussed.
Aug 28 15:57:35 <darknighte> but that's what Song_Liu 's excellent notes are for!  ;)
Aug 28 15:58:04 <Zagor> darknighte: thanks. yeah. I just feel this can turn into quite a big effort and I'd prefer people shoot it down now than several months in.
Aug 28 15:59:43 <Zagor> I'll try and get an updated patch set together tomorrow for the oe-core list so the discussion can continue
Aug 28 16:00:01 <onoffon> darknighte what point was it
Aug 28 16:00:57 <darknighte> onoffon: On the Yocto Project Technical Meeting, Zagor asked for input on a proposal on the mailing list regarding ptest.
Aug 28 16:01:38 <RP__> Zagor: I think its good to raise the profile of the issue
Aug 28 16:02:06 <RP__> Zagor: I'll reply on list when I get a chance
Aug 28 16:02:16 <Zagor> excellent
**** ENDING LOGGING AT Tue Aug 28 16:11:53 2012

**** BEGIN LOGGING AT Tue Aug 28 16:12:23 2012
Aug 28 16:17:06 <mckoan> good morning
Aug 28 16:18:08 <mckoan> anybody has details about Yocto Project Developer Day
Aug 28 16:18:16 <mckoan> Thursday, November 8 - Barcelona, Spain
Aug 28 16:20:37 <mckoan> bluelightning, RP__ : do you know if is free access?
Aug 28 16:21:39 <mckoan> or is an exclusive, invitation-only summit?
Aug 28 16:30:47 <bluelightning> mckoan: it's open and free, but you need to register beforehand
Aug 28 16:31:15 <bluelightning> http://events.linuxfoundation.org/events/embedded-linux-conference-europe/co-located-events
Aug 28 16:32:57 <mckoan> bluelightning: I have to register to Yocto or to ELCE?
Aug 28 16:33:35 <mckoan> I haven't registered to ELCE yet, Im just returned from vacations and I'm planning it
Aug 28 16:33:50 <Crofton> http://events.linuxfoundation.org/events/embedded-linux-conference-europe/co-located-events
Aug 28 16:33:53 <Crofton> might help
Aug 28 16:34:11 <mckoan> Crofton: hi, I read it
Aug 28 16:34:32 <bluelightning> mckoan: I'm not sure but I think it should be offered as an option when you register for ELCE
Aug 28 16:35:14 <Crofton> that sounds familiar
Aug 28 16:35:37 <mckoan> Crofton: that's possible ;-)
Aug 28 16:36:07 <mckoan> but it is not explained anywhere
Aug 28 16:36:23 <mckoan> BTW I will wait until I register to ELCE than
Aug 28 16:36:33 <Crofton> the price goes up soon
Aug 28 16:36:41 <mckoan> DO you have any Yocto favourite hotel ?
Aug 28 16:37:12 <Crofton> I suspect I will end up at the conference hotel, unless someone finds a good alternative nearby
Aug 28 16:37:19 <mckoan> (like for FOSDEM)
Aug 28 16:37:19 <bluelightning> cheaper price until sept 7th
Aug 28 16:37:23 <Crofton> thanks
Aug 28 16:37:57 <mckoan> bluelightning: yep, I definitely do it before sept 7th
Aug 28 16:38:18 <Crofton> are you going to the dev day as a user or staff?
Aug 28 16:38:24 <Crofton> as I recall it wants a code for staff
Aug 28 16:38:53 <Crofton> talk with jefro, I didn't and will need him to fix my registration I thnk :)
Aug 28 16:42:10 <bluelightning> I haven't planned my ELCE trip yet but I suspect I will be there as staff
Aug 28 16:44:27 <Crofton> I suspect registering project members as staff leaves space for new people
Aug 28 16:44:34 <Crofton> but check with jefro
Aug 28 16:45:17 <bluelightning> will do
Aug 28 16:45:55 <mckoan> is there any way to register at a cheaper rate? :-D
Aug 28 16:46:39 <mranostay> mckoan: well you could have submitted a talk :P
Aug 28 16:48:13 <Crofton> mckoan, don't worry about the staff choice for the dev day
Aug 28 16:48:48 <Crofton> it is largely an artificial difference anyway :)
Aug 28 16:49:07 <Jefro> mckoan agreed - I can change your registration if needed, no worries
Aug 28 16:52:32 <mckoan> mranostay: LOL
Aug 28 17:02:32 * Bagder is on the AB dial-up now
Aug 28 17:09:10 <mckoan> have a nice rest of the day
Aug 28 17:09:55 <sgw> bluelightning: you around still?
Aug 28 17:12:39 <bluelightning> sgw: yep
Aug 28 17:42:27 <AdityaGandhi> Hey folks
Aug 28 17:43:04 <AdityaGandhi> I have a problem compiling core-image-sato : eglut.c:7:21: fatal error: EGL/egl.h: No such file or directory
Aug 28 17:43:32 <AdityaGandhi> I am using the latest repo from git,  for both poky nad meta-intel
Aug 28 17:43:43 <AdityaGandhi> yes I am compiling for crownbay platform
Aug 28 17:47:05 <msm> has anyone seen this issue?
Aug 28 17:47:08 <msm> https://gist.github.com/3501328
Aug 28 17:47:14 <msm> know if there was a fix for it?
Aug 28 17:47:54 <sgw> seen the error, typically you have to dig into the config.log to figure out the real issue
Aug 28 17:48:30 <sgw> msm: I know it's pointing at your gcc
Aug 28 17:48:41 <msm> my gcc?
Aug 28 17:48:41 <sgw> but there might be something else also.
Aug 28 17:48:52 <msm> well i have a fix for gcc some guys wrote
Aug 28 17:49:06 <msm> internally, i was trying to see if there was an upstream fix
Aug 28 17:49:16 <msm> its related to cmplrs
Aug 28 17:49:56 <AdityaGandhi> sgw would you know anything about  eglut.c:7:21: fatal error: EGL/egl.h: No such file or directory
Aug 28 17:51:57 <sgw> AdityaGandhi: sorry no, what recipe is that?
Aug 28 17:52:39 <AdityaGandhi> mesa-demos_8.0.1.bb
Aug 28 17:53:07 <AdityaGandhi> I think it may be related to EMGD drivers
Aug 28 17:54:05 <rburton> AdityaGandhi: crownbay is emgd, right?
Aug 28 17:54:13 <AdityaGandhi> right
Aug 28 17:54:22 <rburton> so emgd doesn't actually do egl
Aug 28 17:54:28 <rburton> but mesa-demos is detecting egl
Aug 28 17:55:04 <AdityaGandhi> hmmm,  thats interesting. I am trying to build core-image-minimal
Aug 28 17:55:27 <AdityaGandhi> which is giving me this error, probably the minimal image does not include emgd drives
Aug 28 17:55:33 <AdityaGandhi> let me confim
Aug 28 17:55:36 <AdityaGandhi> confirm*
Aug 28 17:55:45 <rburton> AdityaGandhi: that will force it to build mesa-dri
Aug 28 17:55:55 <rburton> so whilst it builds, you'll have no 3d :)
Aug 28 17:56:03 <AdityaGandhi> okay
Aug 28 17:56:34 <rburton> oh hang on, core-image-minimal?
Aug 28 17:56:38 <rburton> why is that building mesa-demos?
Aug 28 17:56:46 <rburton> oh, you probably have a feature pulling it in
Aug 28 17:56:47 <AdityaGandhi> I was trying to compile qt4e-demo-image but was getting some error in the kernel, so decided to start with minimal image
Aug 28 17:57:21 <AdityaGandhi> Oh yes, I do have added qt4e-toolchain-sdk
Aug 28 17:57:38 <rburton> AdityaGandhi: but please do file a bug and add ross.burton@intel.com to cc - mesa-demos should build on emgd
Aug 28 17:58:10 <AdityaGandhi> Okay , rburton thanks
Aug 28 18:04:22 <AdityaGandhi> rburton: under what will the bug be filed
Aug 28 18:04:42 <AdityaGandhi> layers I assune
Aug 28 18:04:46 <AdityaGandhi> assume*
Aug 28 18:05:19 <rburton> AdityaGandhi: erm, good point. no meta-intel layer.
Aug 28 18:05:57 <rburton> AdityaGandhi: layers->layer will do for now
Aug 28 18:06:48 <AdityaGandhi> rburton: Thanks
Aug 28 19:23:14 <AdityaGandhi> rburton I tried cleaning and compiling again, I get an error like this eglut.c:55:32: error: 'EGL_SCREEN_BIT_MESA' undeclared (first use in this function)
Aug 28 19:23:37 <rburton> AdityaGandhi: add the full error and context to the bug pls
Aug 28 19:27:01 <AdityaGandhi> okay, will do it nw
Aug 28 19:31:18 <AdityaGandhi> hey I get warning before compiling, is it related to this
Aug 28 19:31:19 <AdityaGandhi> NOTE: preferred version 7.11 of mesa-dri not available (for item mesa-dri)
Aug 28 19:31:19 <AdityaGandhi> NOTE: versions of mesa-dri available: 2:8.0.4 2:8.0.4+git1+c1f4867c89adb1a6b19d66ec8ad146115909f0a7
Aug 28 19:32:08 <AdityaGandhi> rburton: is it because I am getting the wrong version of mesa-dri?
Aug 28 19:32:41 <rburton> AdityaGandhi: for a emdg target you shouldn't be getting mesa-dri at all
Aug 28 19:32:53 <rburton> if you want 3D, you want emgd.  mesa-dri will only give you a software renderer.
Aug 28 19:33:15 <AdityaGandhi> okay but how do I force it to use emgd
Aug 28 19:34:03 <AdityaGandhi> I have the license whitelisted in my local.conf
Aug 28 19:34:18 <AdityaGandhi> and I use the bblayer with emgd
Aug 28 19:41:04 <rburton> "If you want to enable the layer that supports EMGD graphics add the
Aug 28 19:41:05 <rburton> following to the local.conf file:  MACHINE ?= "crownbay""
Aug 28 19:41:15 <rburton> you need to explicitly not use emgd
Aug 28 19:42:18 * rburton hasn't really used the meta-intel BSPs and knows there is a mesa problem exposed somewhere else too
Aug 28 19:42:25 <rburton> i was working on it last week but then went away
Aug 28 19:44:12 <AdityaGandhi> I do alread have MACHINE as crownbay, I will check again thanks
Aug 28 19:48:08 <AdityaGandhi> rburton: is there a way I can explicitly say exclude  mesa-dri instead emgd, so I am sure I am only using emgd
Aug 28 19:48:15 <AdityaGandhi> cause my application needs emgd
Aug 28 19:48:39 <rburton> AdityaGandhi: you'll have to find out whats pulling in mesa-dri and why the emgd package isn't good enough
Aug 28 19:48:45 <rburton> depexp can help with that
Aug 28 19:49:31 <AdityaGandhi> okay thanks, will look at that
Aug 28 19:52:14 <rburton> i suspect something in qt is depending on mesa-dri directly
Aug 28 19:52:26 <rburton> that *should* be fine as the emgd driver should provide it with a higher priority
Aug 28 19:56:14 <AdityaGandhi> Yup, I will check and see the depexp for what depends on mesa-dri
Aug 28 20:02:35 <AdityaGandhi> rburton: in my depexp file , mesa-dri  reverse depends on xserver-xorg, mesa-dri and task-core-x11
Aug 28 20:03:30 <AdityaGandhi> now task-core-x11 runtime depends on both emgd and mesa-dri
Aug 28 20:04:18 <AdityaGandhi> and xserver-xorg build depends on mesa-dri
Aug 28 20:06:53 <rburton> oh, this emgd does do EGL
Aug 28 20:06:56 <rburton> that's the good news
Aug 28 20:07:47 <rburton> AdityaGandhi: add PROVIDES="mesa-dri" to emgd-driver-bin
Aug 28 20:07:51 <AdityaGandhi> Okay, and ya I tried compiling again and it did go beyond the precious point I was stuck at
Aug 28 20:08:19 <AdityaGandhi> I had the machine ??="crownbay" instead of machine ?="crownbay"
Aug 28 20:08:28 <rburton> AdityaGandhi: and PREFERRED_PROVIDER_mesa-dri = "emgd-driver-bin" to the crownbay.conf
Aug 28 20:08:29 <rburton> oh
Aug 28 20:08:50 <AdityaGandhi> thanks
Aug 28 20:11:32 <AdityaGandhi> I thought it would be PREFERRED_PROVIDER_mesa-dri = "emgd-driver-bin", but was pointing to mesa-dri 7.1
Aug 28 20:13:32 <AdityaGandhi> rburton: Thanks a lot
Aug 28 20:55:16 <ynezz> ;
Aug 28 22:41:39 <kergoth> what the heck, my sstate_create_package for do_populate_lic is failing inexplicably with no useful info in the log
**** ENDING LOGGING AT Wed Aug 29 02:59:58 2012

**** BEGIN LOGGING AT Wed Aug 29 02:59:58 2012
Aug 29 05:24:23 <evanp> huh...I've twice now -c cleanall'ed my recipe, and then bitbake claims that there's a dependency loop involving a bunch of native packages. but if I run bitbake a second time, everything's fine.
Aug 29 09:39:49 <mckoan> good morning
Aug 29 09:40:16 * mckoan has just registered to attend Yocto Project Developer Day and participate in the Advanced User Track w/Labs
Aug 29 09:40:26 <mckoan> see you there ;-)
Aug 29 10:40:41 <bluelightning> hi all
Aug 29 10:41:10 <rburton> hi bluelightning
Aug 29 13:21:10 <ignus> hello all, whats the easiest way to patch one of the udev files in my layer before it is installed. i would like to be able to comment out one of the lines...
Aug 29 13:23:08 <bluelightning> ignus: I'm not sure if it's exactly what you're after but you should be able to rm the file within a do_install_append()
Aug 29 13:23:54 <ignus> bluelightning: hey, hows it going?
Aug 29 13:24:14 <bluelightning> ignus: great thanks, and you?
Aug 29 13:24:50 <ignus> bluelightning: im good! busy...
Aug 29 13:25:47 <ignus> bluelightning: i was hoping to only change one line, to prevent udev from loading kernel modules on boot and its (apparently) more desirable to do it this way than to write a blacklist which is what i was doing...
Aug 29 13:26:46 <bluelightning> ignus: change one line where though?
Aug 29 13:28:01 <ignus> poky/meta/recipes-core/udev/udev/local.rules
Aug 29 13:28:12 <ignus> i just want to comment out line 31
Aug 29 13:28:56 <rburton> ignus: why do you want to do that?
Aug 29 13:29:01 <ignus> which will prevent modules from loading on boot or when devices are plugged in...
Aug 29 13:29:31 <bluelightning> ok, in that case your options are either provide your own version of that file (with a bbappend that adds to FILESEXTRAPATHS so that the file can be found in your layer); or alternatively use sed to comment the line out e.g. in do_configure_append()
Aug 29 13:31:36 <ignus> is that all the bbappend would have to have in it?
Aug 29 13:33:16 <ignus> rburton, i think its a resource thing...
Aug 29 13:36:41 <bluelightning> ignus: yes for both cases
Aug 29 13:38:44 <ignus> bluelightning, ok, ill go see if i can get that working, thanks!
Aug 29 13:40:34 <peachj> I've run into a problem with sstate.  A couple days ago, I mentioned on here that was I was trying to get a new task added using sstate and getting this really nasty KeyError back from bitbake after following the instructions in the docs.
Aug 29 13:41:21 <peachj> I found a dictionary called 'mapping' under sstate_checkhashes with hard-coded values, that made it look to me as though no task could run through sstate unless it were included in there.
Aug 29 13:41:56 <peachj> (That's in sstate.bbclass)
Aug 29 13:43:44 <peachj> My question is two-fold.  1) Am I just doing something wrong, and there's another way I should be using sstate aside from what's in the docs?
Aug 29 13:44:14 <peachj> 2) Even after looking at git blame/log, I'm having a hard time understanding why this dictionary exists.  Can someone tell me?
Aug 29 13:46:46 <bluelightning> peachj: I think the mapping just exists to get sane names we can use in the context where they are needed...
Aug 29 13:46:56 <bluelightning> peachj: can you describe the actual failure you are getting?
Aug 29 13:47:54 <peachj> File "sstate.bbclass", line 16, in sstate_checkhashes(sq_fn=['/bonus/scratch/build-bundle/meta-lexmark/recipes-example/goodbye/goodbye.bb', '/bonus/scratch/build-bundle/meta-lexmark/recipes-example/goodbye/goodbye.bb' <line snipped for brevity>
Aug 29 13:48:07 <peachj> Ending with, "KeyError: 'do_log_srcrev'"
Aug 29 13:49:34 <peachj> I used the instructions here: http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#shared-state
Aug 29 13:50:35 <peachj> And I even looked at deploy.bbclass, just to make sure I was doing it right
Aug 29 13:51:21 <peachj> FYI, do_log_srcrev is the task I'm adding
Aug 29 13:56:49 <bluelightning> hmm, it seems to me that dict is probably something old before we had the sstate-name varflags...
Aug 29 13:58:04 <peachj> That's the impression I was getting
Aug 29 13:58:25 <peachj> I was a little surprised that it's been there since 2010, given that it seems any custom task using sstate would hit this problem
Aug 29 13:59:45 <bluelightning> indeed
Aug 29 14:00:07 <bluelightning> peachj: though I suspect you are one of the few who has attempted to use that information since it was written ;)
Aug 29 14:03:03 <peachj> Hey, I'm special, what can I say?  ;-)  That's what happens when you're trying to replace your existing build system and you're trying to see if Yocto meets all your requirements.
Aug 29 14:04:25 <rburton> peachj: might be easier to say what you're trying to do, there might be a better way
Aug 29 14:05:30 <peachj> I'm wanting to log all SRCREVs for my build, for both build reproducibility and giving my users an easier way to see the differences between any two builds.
Aug 29 14:05:37 <peachj> I tried using the parse cache
Aug 29 14:05:53 <peachj> But noticed that the HEADREVS table doesn't get filled in on sstate cache hits.
Aug 29 14:06:39 <peachj> So I made a simple task to convert SRCPV into something useful in hopefully all cases, though that's certainly not fully vetted yet.
Aug 29 14:11:08 <bluelightning> peachj: if it's SRCREV you want, how come you are working with SRCPV?
Aug 29 14:11:31 <peachj> AUTOREV is the interesting case for all of this -- otherwise I'd just need the revs of my layers
Aug 29 14:11:41 <peachj> SRCREV = "AUTOINC" in the case of AUTOREV
Aug 29 14:11:45 <peachj> So I can't just use it
Aug 29 14:12:55 <peachj> SRCPV has appeared to contain the correct revision in those cases, though, in what I've seen so far
Aug 29 14:24:42 <kergoth> what the hell
Aug 29 14:24:43 <kergoth> | /scratch/mel6/sanity/build/tmp/work/p2020rdb-mel-linux-gnuspe/mel-release-granular-1.0-r7/temp/run.sstate_create_package.17574: xmalloc: ../bash/subst.c:2129: cannot allocate 691170 bytes (5524766720 bytes allocated)
Aug 29 14:24:47 * kergoth mutters
Aug 29 14:40:13 <ignus> bluelightning, FILESEXTRAPTTHS with the modified file doesnt seem to work. can i show you what i have?
Aug 29 14:50:30 <bluelightning> ignus: certainly
Aug 29 15:31:24 <mranostay> kergoth: too early? :)
Aug 29 15:37:59 <kergoth> oh yes
Aug 29 15:38:50 <kergoth> gah!
Aug 29 15:38:57 <kergoth> i have this task, when it fails, there's never a lot
Aug 29 15:39:01 <kergoth> even if i run it with set -x
Aug 29 15:39:03 <kergoth> it makes  no sense
Aug 29 15:39:07 <kergoth> s/lot/log/
Aug 29 15:59:18 <peachj> Okay, I thought I'd be clever and try to figure out how to patch this problem with checkhashes myself, but I'm pretty new to pure bitbake (we have a very old, forked version).  I assume I should log a Bugzilla bug to track my sstate issue?
Aug 29 16:00:39 <peachj> Also, is there anything I do in the meantime to log all SRCREVs, including ones for packages on which I get an sstate cache hit, but are using AUTOREV?
Aug 29 16:00:44 <bluelightning> peachj: I think it's reasonable to add a feature request for the underlying feature you're after, plus a bug about the sstate map needing to be removed
Aug 29 16:00:59 <peachj> Okay, that sounds good.  Thank you!
Aug 29 16:01:45 <bluelightning> my only other suggestion would be an event handler that upon recieving a do_populate_sysroot(_setscene) event, calls into the fetcher to find out the actual SRCREV value
Aug 29 16:02:51 <peachj> I will chat about that with my colleagues.  I appreciate your help!
Aug 29 17:05:24 * zenlinux holds out hope that his new bike gets built today
Aug 29 17:05:36 <zenlinux> sorry, off-topic, wrong channel
Aug 29 17:07:02 <bluelightning> zenlinux: no worries, it's pretty quiet in here atm... :)
Aug 29 17:07:02 <mranostay> we forgive
Aug 29 17:10:08 <zenlinux> on a more relevant note, do I understand correctly that the perl-modules package supposed to pull in every built perl module package? I'd like something that includes a sensible set of default perl modules
Aug 29 17:10:29 <zenlinux> I'm trying to run Bastille Linux, and it needs about 40 perl modules AFAICT
Aug 29 17:10:39 <zenlinux> it's been quite tedious installing them all one by one
Aug 29 17:23:07 <bluelightning> zenlinux: I think that's the way it's intended ... the question would be what would be a sensible set of defaults?
Aug 29 17:23:47 <bluelightning> zenlinux: ideally we would have some logic that would set up the package dependencies automatically at the very least... I know that's been discussed in the past
Aug 29 17:24:00 <zenlinux> bluelightning, valid point - just picking a set that some desktop distros include by default probably isn't appropriate
Aug 29 17:24:20 <bluelightning> FWIW I had to go through the same exercise for webmin when I was putting together meta-baryon, and I agree it's very tedious
Aug 29 17:24:53 <zenlinux> of course, I'm now realizing Bastille distributes an RPM and I could probably take a look at the rpm's dependencies. :-/
Aug 29 17:27:57 <bluelightning> I'm off home... bbl
Aug 29 18:06:56 <mranostay> wb challinan
Aug 29 18:09:54 <challinan> hi mranostay
Aug 29 18:12:06 <mranostay> challinan: how is the storm? miss you completely?
Aug 29 18:12:08 <challinan> mranostay: I like your ppp (punk profile picture)
Aug 29 18:12:26 <challinan> we got alot of wind and rain, some flooding, but not much $$ damage
Aug 29 18:14:11 <mranostay> seems New Orleans can't catch a break
Aug 29 18:15:22 <challinan> dude, today is the exact 7 year anniversary of Katrina hitting landfall in New Orleans
Aug 29 18:20:40 <mranostay> yeah i saw that
Aug 29 19:09:50 <Crofton> I am on an airplane, flying through the sky!
Aug 29 19:10:07 <Crofton> zecke, will you make ELCE by any chance?
Aug 29 19:10:16 <mranostay> Crofton: crazy man!
Aug 29 19:10:39 <Crofton> amazing
Aug 29 19:14:45 <mranostay> Crofton: $10 a flight?
Aug 29 19:18:36 <Crofton> yeah
Aug 29 19:18:45 <Crofton> I am "working" though
Aug 29 19:31:30 <zecke> Crofton|work: didn't plan to.
Aug 29 19:35:50 <evanp> if I want to include a conf file, but that file assigns to a variable thereby masking a default value I want to preserve, is there a way to work around that?
Aug 29 19:36:36 <kergoth> change the file to use ?= or whatever. or use := to back it up
Aug 29 19:36:59 <evanp> would adding an event handler for RecipeParsed and calling e.data.delVar() work?
Aug 29 19:37:36 <kergoth> ?
Aug 29 19:37:40 <kergoth> that'll delete the variable, sure
Aug 29 19:37:49 <evanp> := sounds way easier, but I'm still curious
Aug 29 19:38:09 <kergoth> but the event handler won't magically resurrect the default value, unless the default was assigned with ??=
Aug 29 19:38:13 <kergoth> it'll just delete it entirely
Aug 29 19:41:37 <evanp> mmm. I was kinda hoping RecipeParsed let me manipulate the parse tree before it was eval'ed
Aug 29 20:10:04 <evanp> if I addhandler, is the new handler executed before all previous ones, or after?
Aug 29 20:38:45 <seebs> I'm not even sure whether it's deterministic.
Aug 29 20:39:19 <seebs> Hey, silly question. I have a report about permissions changes in the filesystem, and... Do people occasionally see weird, unreproducible, permissions errors in filesystem builds?
Aug 29 20:40:30 <seebs> Because there is such a thing on my list right now, and I can't reproduce it. And we've made a change which I don't think *should* matter, but which could in principle. And if it did, I'd expect to see rare-but-occasional screw-ups in filesystem permissions, like binaries not getting setuid bits or ownership right. And this would almost certainly happen with filesystems for local NFS usage, but not with ext3 filesystems and the like.
Aug 29 21:42:26 <khem> does anyone else sees a negative timestamp on git.yp.org's cgit
Aug 29 21:42:34 <khem> -81 min.	runqemu-export-rootfs and friends: don't put pseudo db in target fs	Peter Seebach	3	-11/+14
Aug 29 21:42:44 <khem> see -81
Aug 29 21:42:52 <khem> thats the time relative to now
Aug 29 21:43:39 <khem> or was it some glitch on RPs computer
Aug 29 21:43:52 <khem> which will get fixed in 81 mins I guess
Aug 29 21:45:54 <evanp> khem: which repo?
Aug 29 21:46:02 <khem> poky
Aug 29 21:46:18 <evanp> ah. yeah, I see it too
Aug 29 21:47:11 <khem> may be when you committed you were in a different timezone than when you push could possibly cause it
Aug 29 21:47:14 <khem> who knows
Aug 29 21:49:05 <evanp> anybody know a way to evaluate some python _during_ parsing? I tried ${@d.renameVar("PACKAGES", "nativepkg_PACKAGES") or ''}, but that doesn't parse. I'd need the rename to happen before the parser sees a require directive
Aug 29 21:50:04 <kergoth> evanp: use an anonymous python function, there are examples all over the metadata
Aug 29 21:50:10 <kergoth> or a RecipeParsed event handler
Aug 29 21:50:13 <kergoth> there are a number of those also
Aug 29 21:50:15 <kergoth> python () {
Aug 29 21:50:24 <kergoth> is an anonymous python function, it runs at the end of the parsing process
Aug 29 21:50:55 <evanp> kergoth: that's too late
Aug 29 21:51:19 <evanp> the variable I want to save is already overwritten by then
Aug 29 21:51:21 <kergoth> then you should almost certainly find a better solution
Aug 29 21:51:27 <kergoth> this whole approach sounds wrong
Aug 29 21:51:37 <kergoth> but if you really want to do it, use := to force immediate expansion of a ${@} block
Aug 29 21:53:09 <khem> now I see that at one point of time bitbake is just doing 1 task eglibc do_install
Aug 29 21:53:21 <khem> I am temped to say use gcc-cross-initial for kernel
Aug 29 21:53:26 <kergoth> hehe
Aug 29 21:53:28 <khem> so we can atleast have 2 tasks
Aug 29 21:53:59 <khem> since eglibc and gcc-cross are real bottlenecks
Aug 29 21:54:15 <khem> but may be its just me because I rebuild them often
Aug 29 22:00:41 <kergoth> doesn't seem like a bad idea
Aug 29 22:02:17 <khem> in the end its building kernel modules or packaging them and eglibc-locale
Aug 29 22:02:24 <khem> so those are ending actors :)
Aug 29 22:02:47 <khem> so I assume if I shift kernel a bit earlier in chain hopefully modules will be built earlier too
Aug 29 22:03:32 <kergoth> woudl think so
Aug 29 22:12:09 <khem> kergoth: have you looked into scala
Aug 29 22:12:22 <kergoth> sadly not
Aug 29 22:12:24 <khem> its functional and OO language combined
Aug 29 22:12:27 <kergoth> on the list of stuff to check out
Aug 29 22:12:30 <kergoth> long list
Aug 29 22:12:30 <khem> its kind of cool
Aug 29 22:12:31 <kergoth> :)
Aug 29 22:12:50 <khem> its something to consider for bitbake-next :)
Aug 29 22:13:12 <khem> it has aspect orientedness
Aug 29 22:13:33 <khem> and framework for concurrency
Aug 29 22:13:54 <khem> think of bitbake running asynchronous threads on a 24core machine
Aug 29 22:14:10 <khem> it uses java bytecode though
Aug 29 22:14:18 <khem> for code generation
Aug 29 22:42:36 <seebs> I would vote for basically any language that isn't PHP as an alternative. :P
Aug 29 22:42:40 <seebs> Okay, well. PHP, or GNU make.
Aug 29 22:46:28 <grifter188> I vote for Pascal as the next builder language :P
Aug 29 22:51:27 * mranostay hides grifter188 body
Aug 29 22:52:47 * mranostay wonders if they still 'make' TurboPascal
Aug 29 22:53:06 <grifter188> I don't think so, kids learn Java now days
Aug 29 22:53:59 <grifter188> http://turbopascal.net/  Interesting
Aug 29 22:58:03 <khem> I dont think its considered manly if you can do your own memory management
Aug 29 22:58:29 <khem> there is no derth of bugs no matter how smart one thinks of himself as a C programmer
Aug 29 22:58:42 <khem> or any language that lets you have hand of system resources
Aug 29 22:58:56 <khem> there is a reason why java is #1 language in world
Aug 29 22:59:10 <khem> and I work on gcc
Aug 29 23:01:51 <mranostay> heh
Aug 29 23:04:01 <khem> in 1999 when I talked about linux people said 'linux is for kids' and I was one so I did not mind it
Aug 29 23:56:39 <kergoth> wtf, bitbake just showed a fetch failure warning message for an sstate package
Aug 29 23:56:42 <kergoth> do. not. care.
Aug 30 01:25:41 <seebs> Ah-hah!
Aug 30 01:25:52 <seebs> This probably won't affect anyone else, but:
Aug 30 01:26:20 <seebs> If you have mysterious pseudo problems on a 32-bit host, one possible cause is that you have 32-bit prebuilts of some sort, such as compiler binaries, but don't have a complete 32-bit development environment installed.
Aug 30 01:26:30 <seebs> The test for /usr/include/gnu/stubs-32.h does not seem to be reliable in that case.
**** ENDING LOGGING AT Thu Aug 30 03:00:01 2012

**** BEGIN LOGGING AT Thu Aug 30 03:00:02 2012
Aug 30 08:39:28 <bluelightning> morning all
Aug 30 08:39:53 <JaMa> morning
Aug 30 09:02:49 <ignus> hello all
Aug 30 09:07:23 <bluelightning> hi ignus, JaMa
Aug 30 13:52:23 <jchonig> Does Yocto currently support ARM BE8?
Aug 30 16:33:53 <peachj> Quick Bugzilla question.  I put in a request for an enhancement, but after digging yet further, I don't think I need it anymroe.
Aug 30 16:34:09 <peachj> 1) Do I change the status?  2) To what should I changed the status?  Resolved?
Aug 30 16:37:57 <bluelightning> peachj: which one was this?
Aug 30 16:46:57 <peachj> Bug 3041
Aug 30 16:47:12 <peachj> Ironically, the request I talked about logging on here yesterday, about printing SRCREVs
Aug 30 16:48:07 <peachj> FYI, gotta run to a meeting in a couple minutes for about an hour, if you need anything else for me.
Aug 30 16:55:46 <bluelightning> peachj: hmm... something like this does sound useful - at least, if not a way to print out the SRCREVs, at least a way to satisfy the requirement to be able to freeze the build even in the face of recipes that set SRCREV = "${AUTOREV}" and reproduce it later
Aug 30 16:56:54 <kergoth> damn, this bug when you have multiple recipes using the same git repo, but with different srcrevs based on the same branch, is still there, i think
Aug 30 16:57:17 <kergoth> the autoincrementing bits keep running as the two recipes fight over it
Aug 30 17:16:11 <bluelightning> kergoth: ah, interesting, I was aware we had some subtle bug that was triggering SRCPV increments, but I wasn't aware it was related to two recipes sharing the same repo...
Aug 30 17:31:07 <peachj> bluelightning: Actually, there is a way to do that, I just didn't realize it
Aug 30 17:31:33 <peachj> SRCREV="${AUTOREV}" by itself doesn't permute the hash.  That was data I've been missing this whole time.
Aug 30 17:32:03 <peachj> That means SRCPV pretty much has to come into play, and if it does, the parse caching DB gets populated with revs
Aug 30 17:32:15 <peachj> Even in the face of cache hits
Aug 30 17:33:12 <kergoth> bluelightning: yeah, iirc it can even happen if you have two versions of a given recipe in two different layers, so we only ever end up building one of them, but it's the *parse* that triggers the problem.. heh
Aug 30 17:33:24 <kergoth> i haven't naield down exactly why it's happening, but it's pretty easy to reproduce
Aug 30 17:33:29 <kergoth> i'll see about opening a bugzilla bug
Aug 30 17:39:40 <bluelightning> kergoth: that would be great... unfortunately the code that handles the incrementing is less than transparent :/
Aug 30 17:40:04 * kergoth nods
Aug 30 17:41:49 <kergoth> we got bit by it in the past with u-boot recipes, iirc meta-oe had one based on the same branch one of our bsp layers did, and it resulted in u-boot being rebuilt every time due to the continuously changing number :)
Aug 30 17:41:55 <kergoth> wasn't critical at the time
Aug 30 23:07:31 <evanp> anyone know a reason I can't rewrite process_dir in relocatable.bbclass to use os.path.relpath?
Aug 30 23:12:10 <RP__> evanp: I suspect we supported python 2.5 at that point or something so its probably fine to convert it now
Aug 30 23:13:10 <evanp> also...is it filtering out already-$ORIGINed entries intentionally?
Aug 30 23:17:57 <RP__> evanp: no, didn't we fix that?
Aug 30 23:18:13 <RP__> evanp: or did I never get sent a patch? :/
Aug 30 23:19:14 <evanp> RP__: I probably should pull...on denzil as of a month or two ago right now
Aug 30 23:19:38 <RP__> evanp: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=650227eea3f36f18b6cfbfc23a30474cc07014e1
Aug 30 23:19:58 <RP__> evanp: so its fixed in master, not sure if it was backported to denzil. zenlinux would know
Aug 30 23:20:28 <RP__> evanp: looks like it hasn't and zenlinux should consider it
Aug 30 23:21:00 <zenlinux> I'll make a note of this and merge it soon
Aug 30 23:21:40 <RP__> zenlinux: thanks!
Aug 30 23:53:01 <kergoth> anyone hit build failures due to lib/locale vs lib64/locale?
Aug 30 23:53:33 * kergoth just ran into one
Aug 31 00:52:09 <seebs> kergoth: Not recently, although I think I've seen packages that made Bad Assumptions about libdir one way or the other.
Aug 31 00:52:43 <seebs> But I'm not even sure what build system that was in...
**** ENDING LOGGING AT Fri Aug 31 02:59:59 2012

**** BEGIN LOGGING AT Fri Aug 31 03:00:00 2012
Aug 31 04:22:26 <sgw> khem: yes, I saw it on the AB, RP__ pushed a change, I am hoping he can fix it tonight.
Aug 31 05:46:10 <RP__> sgw, khem: Fix pushed, sorry
Aug 31 05:46:35 <RP__> I had the fix locally but didn't squash it in properly to the original commit :/
Aug 31 07:53:02 <moolinex> morning
Aug 31 08:24:02 <bluelightning> morning moolinex, all
Aug 31 13:52:28 <bluelightning> hmm... is it still useful to be able to install leafpad, matchbox-terminal and pcmanfm (i.e. X text editor, terminal & file manager) from an IMAGE_FEATURES item?
Aug 31 13:52:59 <bluelightning> or are they only worth having as part of the full Sato?
Aug 31 13:53:03 <bluelightning> rburton: ^
Aug 31 14:09:45 <RP__> morning all
Aug 31 15:03:12 <bluelightning> RP__: morning
Aug 31 15:03:22 <bluelightning> RP__: how's the conference going?
Aug 31 15:04:56 <nitink> RP__: morning !
Aug 31 17:21:11 <seebs> This may be a silly question, but... I know roughly how addhandler works. If code is introduced with "python() {", when does it execute?
Aug 31 17:21:43 <seebs> The reason I ask is that I have a handler which is trying, at BuildStarted events, to refer to SITEINFO_BITS, which isn't set yet. It's set in an anonymous Python function.
Aug 31 17:25:39 <kergoth> seebs: it's at the end of the recipe parse, just like RecipeParsed event handlers
Aug 31 17:25:51 <seebs> Ah-hah.
Aug 31 17:25:59 <kergoth> also, BulidStarted is global
Aug 31 17:26:05 <kergoth> it gets the config metadata, not recip emetadata
Aug 31 17:26:27 <seebs> Yeah. Okay, here's my problem: Because the external toolchain binaries are 32-bit binaries, we *MUST* build 32-bit libpseudo for them to work.
Aug 31 17:26:31 <kergoth> its likely you need to copy the config metadata and finalize it to get the anonymous python functions run, assuming that python () {} block is defined in teh config metadata
Aug 31 17:26:39 <kergoth> yep, that's true
Aug 31 17:26:46 <seebs> But wait! Builds complete just fine without it, you say? Why, yes, yes they do. *With corrupted permissions.*
Aug 31 17:26:47 <kergoth> so set NO32LIBS in the tcmode .inc and call it a day
Aug 31 17:26:51 <seebs> Ahh, see.
Aug 31 17:27:22 <seebs> If you look at the pseudo recipe, it checks for three things:  1. NO32LIBS=0.  2. SITEINFO_BITS == 64.  3. /usr/include/gnu/stubs-32.h exists.
Aug 31 17:27:34 <seebs> And if that last one isn't true, it *silently decides not to build the 32-bit version*.
Aug 31 17:27:48 <seebs> So my idea was, hey, I'll just have the toolchain setup check for that file.
Aug 31 17:27:57 <seebs> Only. We have *32-bit* hosts where that file doesn't exist.
Aug 31 17:28:08 <kergoth> that sounds wrong, i'd say it should only use that if NO32LIBS isn't set by the user, and arrange its value to be able to figure that out
Aug 31 17:28:10 <seebs> (On all the 64-bit hosts I can find, either that file exists or 32-bit compiles fail.)
Aug 31 17:28:19 <kergoth> user preference should always be able to override automation
Aug 31 17:28:29 <kergoth> imo anyway
Aug 31 17:29:04 <seebs> That is my plan. But that is the "after this release is working" plan, because it involves synchronizing with upstream. :)
Aug 31 17:29:21 <kergoth> ah
Aug 31 17:29:34 <seebs> So in the mean time, I sort of want to make a test that's like SITEINFO_BITS == 64, but works at BuildStarted. And I haven't thought of one yet.
Aug 31 17:30:01 * kergoth ponders
Aug 31 17:38:01 <seebs> BUILD_ARCH, I think.
Aug 31 17:38:29 <seebs> Because in practice, I don't think I care about non-x86_64 systems on this timescale.
Aug 31 17:40:32 <seebs> ... hmm. Nope. BUILD_ARCH is in bitbake -e output with no targets, but apparently not set at BuildStarted? Or I'm spelling something wrong.
Aug 31 17:41:49 <seebs> ...
Aug 31 17:41:58 <kergoth> must be typoing or something, it's set in bitbake.conf
Aug 31 17:42:01 <seebs> getVar(foo) != getVar(foo, DO WHAT I MEAN YOU STUPID COMPUTER)
Aug 31 17:42:09 <kergoth> heh
Aug 31 17:42:12 <kergoth> we did that badly
Aug 31 17:42:18 <kergoth> expanded is by far the common case
Aug 31 17:42:30 <seebs> I sort of wonder what the damage would be of a global pass to invert that.
Aug 31 17:42:54 <bluelightning> I think that was discussed and rejected a year or two ago
Aug 31 17:51:02 <kergoth> i'm sure there are very very few uses without passing , True, but it still seems risky, compatibility wise
Aug 31 17:51:14 <kergoth> maybe consider it for the next major/minor version bump
Aug 31 17:53:11 <bluelightning> I think it's reasonable to bring it up again
Aug 31 17:53:29 <bluelightning> I agree it would be nicer not to have to pass True all the time
Aug 31 18:05:06 <kergoth> if it was default, you could even use the __getitem__()
Aug 31 18:05:16 <kergoth> d["SRC_URI"]
Aug 31 18:05:18 <kergoth> if you really wanted to
Aug 31 18:05:42 <kergoth> you can do that today, but of course it's the unexpanded value, which is of limited usefulness
Aug 31 18:24:17 <seebs> Huh.
Aug 31 18:25:05 <seebs> Is anyone *using* the __getitem__ value? Because if not, perhaps the thing to do would be to make that be the expanded value by default, and then encourage people to use it.
Aug 31 18:28:00 <kergoth> its the same issue as with getVar. just because we think most people don't use it doesn't mean we can just go ahead and break compatibility willy nilly
Aug 31 18:28:03 <kergoth> imo
Aug 31 18:31:02 <mranostay> heh
Aug 31 18:57:49 <xxiao> building webos on top of oe here, quite some rough corners
Aug 31 19:01:36 <khem> kergoth: do we have API concept for bitbake at all ?
Aug 31 19:01:49 <khem> kergoth: we use whatever we like in OE
Aug 31 19:01:53 <khem> from bitbake
Aug 31 19:02:07 <khem> I think it woould be better to define API clearly
Aug 31 19:06:52 <kergoth> khem: agreed, but even without something defined, there should be an implicit assumption of compatibility across micro/minor versions, i'd think
Aug 31 19:07:51 <khem> yes should be
Aug 31 19:09:22 <xxiao> webos is baked
Aug 31 19:19:40 <sgw> khem: we seem to be having a rash of sanity check failures on the Autobuilders
Aug 31 19:19:58 <sgw> khem: checking how to run the C preprocessor... mips-poky-linux-gcc -E --sysroot=/srv/home/pokyb
Aug 31 19:19:58 <sgw> uild/yocto-autobuilder/yocto-slave/nightly-mips/build/build/tmp/sysroots/qemumips -meb -ma
Aug 31 19:19:58 <sgw> bi=32 -mhard-float
Aug 31 19:19:58 <sgw> configure: error: in `/srv/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-mips/build
Aug 31 19:19:58 <sgw> /build/tmp/work/mips32-poky-linux/eglibc-initial-2.16-r6+svnr20393/build-mips-poky-linux':
Aug 31 19:19:58 <sgw> configure: error: C preprocessor "mips-poky-linux-gcc -E --sysroot=/srv/home/pokybuild/yoc
Aug 31 19:19:58 <sgw> to-autobuilder/yocto-slave/nightly-mips/build/build/tmp/sysroots/qemumips -meb -mabi=32 -m
Aug 31 19:19:59 <sgw> hard-float" fails sanity check
Aug 31 19:19:59 <sgw> See `config.log' for more details
Aug 31 19:32:44 <khem> sgw: yes config.log will have details
Aug 31 19:33:10 <khem> usually some weird compiler option or missing header files
Aug 31 19:33:17 <khem> cause such issues
Aug 31 19:37:00 <sgw> khem, was wondering if you were seeing this at all, it's happening on multiple arches
Aug 31 19:37:16 <khem> hmmm no I did not see it
Aug 31 19:37:29 <khem> is it some sstate thing prolly
Aug 31 19:37:46 <khem> can I see the config.log
Aug 31 19:37:55 <sgw> maybe, I am digging into this.
Aug 31 19:56:53 <sgw> khem, interesting, at least in this mips case we are missing /usr/include/limits.h, I will check the other cases
Aug 31 19:58:15 <khem> oh that sounds familiar
Aug 31 19:58:19 <khem> hmmm
Aug 31 19:59:09 <sgw> khem: same problem with the x86-64 build
Aug 31 20:00:24 <khem> ok
Aug 31 20:00:30 <khem> let me give you something to try
Aug 31 20:01:39 <sgw> khem sure
Aug 31 20:01:55 <sgw> I am also looking at the linux-libc to see if there is an issue with it.
Aug 31 20:09:34 <khem> sgw: I dont see an issue so far.
Aug 31 20:09:39 <sgw> khem: it's not using sstate for eglibc-initial
Aug 31 20:09:40 <khem> so tell me something about when it happens
Aug 31 20:09:51 <khem> ok
Aug 31 20:09:58 <khem> hmm
Aug 31 20:10:09 <khem> so you have sstate and clean tmpdir
Aug 31 20:10:17 <khem> and then its populated stuff from sstate
Aug 31 20:10:19 <khem> is that right
Aug 31 20:10:29 <sgw> here is the cooker log: http://autobuilder.yoctoproject.org:8010/builders/nightly-mips/builds/586/steps/shell_26/logs/stdio
Aug 31 20:11:53 <khem> sgw: ok it seems it gets gcc-cross-initial from sstate
Aug 31 20:11:58 <khem> but not eglibc-initial
Aug 31 20:12:01 <sgw> khem: since this has your updated eglibc, it's building eglibc from scratch no sstate
Aug 31 20:12:16 <khem> ok.
Aug 31 20:12:26 <khem> so essentially to reproduce it
Aug 31 20:12:30 <khem> have sstate
Aug 31 20:12:33 <sgw> khem: right
Aug 31 20:12:34 <khem> and tweak eglibc
Aug 31 20:12:47 <khem> and it will then try to rebuild eglibc-initial and fail
Aug 31 20:12:55 <sgw> maybe, I have seen it work also
Aug 31 20:13:59 <khem> sgw: can you paste config.log of eglibc-initial too
Aug 31 20:14:08 <sgw> sure
Aug 31 20:14:50 <khem> my guess is bad interaction with
Aug 31 20:14:52 <khem> commit c8815d2f21849deb9359706f54dc71490773415e
Aug 31 20:14:52 <khem> Author: Richard Purdie <richard.purdie@linuxfoundation.org>
Aug 31 20:14:52 <khem> Date:   Mon Aug 6 11:13:06 2012 +0000
Aug 31 20:14:52 <khem> gcc-cross-initial: Ensure it uses an isolated sysroot
Aug 31 20:15:36 <khem> because now gcc-cross-intial is fetched from sysroot and do_configure is not run
Aug 31 20:15:42 <khem> can you try this step
Aug 31 20:16:09 <khem> bitbake -ccleansstate gcc-cross-initial; bitbake eglibc-initial and see if that works ?
Aug 31 20:16:16 <sgw> http://pastebin.com/Qfkr5Kmn
Aug 31 20:17:20 <khem> /srv/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-mips/build/build/tmp/sysroots/x86_64-linux/usr/lib/mips32-poky-linux.gcc-cross-initial/gcc/mips-poky-linux/4.7.2/include-fixed/limits.h:169:61: fatal error: limits.h: No such file or directory
Aug 31 20:17:24 <khem> hmmm
Aug 31 20:17:31 <khem> can you pastebin /srv/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-mips/build/build/tmp/sysroots/x86_64-linux/usr/lib/mips32-poky-linux.gcc-cross-initial/gcc/mips-poky-linux/4.7.2/include-fixed/limits.h
Aug 31 20:17:47 <sgw> it finds a different limits.h
Aug 31 20:18:30 <khem> actually it should not ask for limits.h from within include-fixed/limits.h in gcc-cross-initial
Aug 31 20:18:53 <sgw> do you still need the pastebin?
Aug 31 20:19:11 <sgw> http://pastebin.com/w9eQnUZZ
Aug 31 20:20:44 <khem> commit aab76b339937fa666945fefe1167a3e39b5d874f
Aug 31 20:20:45 <khem> Author: Khem Raj <raj.khem@gmail.com>
Aug 31 20:20:45 <khem> Date:   Mon Jul 23 22:40:52 2012 -0700
Aug 31 20:20:45 <khem> gcc-cross-initial: Stage self sufficient fixed limits.h
Aug 31 20:20:50 <khem> should have done the right thing
Aug 31 20:20:59 <khem> how old is gcc-cross-initial sstate
Aug 31 20:21:13 <sgw> I just cleaned!
Aug 31 20:22:33 <khem> ok that limits.h is wrong
Aug 31 20:22:45 <khem> I am guessing your sstate was older than the above
Aug 31 20:22:49 <khem> commit
Aug 31 20:23:08 <sgw> PR bump needed someplace then?
Aug 31 20:23:38 <sgw> that clean caused eglibc-initial to pass ok!
Aug 31 20:23:46 <khem> that commit itself bumped PR
Aug 31 20:23:51 <khem> so it should have rebuilt
Aug 31 20:24:06 <khem> ok now do this
Aug 31 20:24:39 <khem> bitbake -cclean gcc-cross-initial; bitbake -ccleansstate eglibc-initial;bitbake eglibc-initial
Aug 31 20:25:27 <khem> if the problem was old sstate then the above sequence should work
Aug 31 20:25:44 <khem> if the problem is something else then it should fail exactly the way it did before
Aug 31 21:07:08 <sgw> khem: yup we had a bad gcc-cross-initial somehow, I looked at the gcc-cross-initial sstate files and fairly new (oldest is Aug 26)
Aug 31 21:09:17 <khem> k
Aug 31 21:09:45 <khem> sgw: btw. if you picked my eglibc/uclibc branch
Aug 31 21:09:54 <khem> then I am going to push two other package fixed
Aug 31 21:10:12 <sgw> It's in mut right now, but I want to address this issue and then rebuild
Aug 31 21:10:12 <khem> which lets core-image-sato build and boot with uclibc again
Aug 31 21:10:37 <sgw> looking at the sysroot tar files they seem to be missing the limits.h
Aug 31 21:12:45 <sgw> khem: what's the right version of limits.h
Aug 31 21:15:57 <khem> sgw: hmmm limits.h should not include another limits.h
Aug 31 21:16:11 <khem> if you have the one that does it in gcc-initial install
Aug 31 21:16:16 <khem> then thats a problem
Aug 31 21:16:29 <khem> sgw: btw. I update my pull tree
Aug 31 21:16:37 <sgw> ok thanks
Aug 31 21:16:39 <khem> so please repull before you fire your build
Aug 31 21:16:57 <sgw> I am wondering if we need another PR bump for gcc?
Aug 31 21:17:24 <khem> hmmm, I would not expect to have one
Aug 31 21:18:07 <khem> limits.h should not be in bootstrap sysroot
Aug 31 21:18:17 <khem> you cant have it since you have not build eglibc yet
Aug 31 21:18:28 <khem> its just in gcc-cross-initial install
Aug 31 21:18:39 <khem> you should have one in final sysroot
Aug 31 21:18:47 <khem> then all falls into places
Aug 31 21:18:59 <khem> its a bootstrap hairy peice of many
Aug 31 21:22:22 <sgw> I wonder if I should just delete these other ones that has wrong limits.h
Aug 31 21:22:35 <khem> I guess yes
**** ENDING LOGGING AT Sat Sep 01 03:00:01 2012

**** BEGIN LOGGING AT Sat Sep 01 03:00:02 2012
Sep 01 07:57:51 <mckoan> good morning
**** ENDING LOGGING AT Sun Sep 02 02:59:59 2012

**** BEGIN LOGGING AT Sun Sep 02 02:59:59 2012
Sep 02 11:57:12 <eren> is there anyone who works with AMD Geode LX type processor, typically ALIX 3D3 board?
Sep 02 11:57:44 <eren> there are some discussions about BSP for ALIX 3D3 on mailling lists but not much coherent information
Sep 02 19:44:10 <ag_> Hello.
Sep 02 19:44:43 <ag_> Can anybody point me to a url / reference where i can see the valid packages sections [variable: SECTION]?
Sep 02 22:09:04 <kergoth> Pretty sure it's a convention, not a standard, and I doubt there is a definitive list unless you look at debian's policy manual or something for inspiration, but i'm not certain
Sep 02 22:16:51 <bluelightning> we haven't paid much attention to SECTION
Sep 02 22:17:22 <bluelightning> it's almost heading into distro territory although there's nothing against sane defaults I guess
Sep 02 22:25:32 <kergoth> yeah, what 'category' something is in does feel distroish
Sep 02 22:25:36 <ag_> bluelightning: kergoth: thanks. Well, i saw this is http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html
Sep 02 22:25:57 <ag_> The section where package should be put. Package managers use this variable.
Sep 02 22:26:42 <ag_> I remember that when i sent a path for a package (time ago) somebody commented that "that" wasn't a valid section....
**** ENDING LOGGING AT Mon Sep 03 03:00:00 2012

**** BEGIN LOGGING AT Mon Sep 03 03:00:00 2012
Sep 03 05:25:51 <zeeblex> sync
Sep 03 06:51:24 <mckoan> good morning
Sep 03 07:20:43 <sujith> HI all. I have made a recipe for DLT-viewer. Since DLT-daemon resides in the meta-ivi repo, I created the recipe in that directory. May I know how to send the patch for review and to which mailing list I need to send?
Sep 03 07:54:31 <bluelightning> morning all
Sep 03 07:55:18 <JaMa|Off> morning
Sep 03 07:55:45 <mckoan> gm
Sep 03 08:52:54 <sujith> bluelightning: Hi
Sep 03 11:01:51 <JaMa|Off> NOTE: multiple providers are available for virtual/nativesdk-libintl (nativesdk-eglibc, nativesdk-gettext)
Sep 03 11:01:54 <JaMa|Off> NOTE: consider defining a PREFERRED_PROVIDER entry to match virtual/nativesdk-libintl
Sep 03 11:02:05 <JaMa|Off> ^ after nativesdk move from suffix to prefix
Sep 03 12:02:27 <gotan> Hi, quick question about GTK - is there any way of telling (in a makefile during a build) if GTK has been configured for the image?
Sep 03 12:04:55 <rburton> you *could* use pkgconfig to look for gtk+
Sep 03 12:05:37 <rburton> like it should be doing already to find the headers, but with a non-fatal test
Sep 03 12:06:18 <gotan> i tried a devshell gtk-config and it failed
Sep 03 12:09:48 <rburton> gtk-config is gtk+1
Sep 03 12:09:59 <rburton> is that what you mean?
Sep 03 12:10:58 <rburton> $ pkg-config  --exists gtk+-2.0 ; echo $?
Sep 03 12:10:58 <rburton> 0
Sep 03 12:11:00 <rburton> that's what i meant
Sep 03 12:11:06 <rburton> (works for -3.0 too)
Sep 03 12:17:02 <gotan> will git it a try, it will pick up the proper pkg-config binary iguess?
Sep 03 12:28:45 <rburton> gotan: yes
Sep 03 12:42:00 <gotan> @rburton thanks.
Sep 03 12:57:14 <rburton> this isn't bloody twitter! :)
Sep 03 12:58:48 <bluelightning> rburton: ?
Sep 03 12:59:11 <rburton> bluelightning: gotan's last message
Sep 03 12:59:36 <bluelightning> rburton: oh you meant the @.... #pedantry
Sep 03 12:59:38 <bluelightning> ;)
Sep 03 12:59:48 <rburton> yes #pedant
Sep 03 12:59:59 * bluelightning is not on twitter...
Sep 03 13:02:35 <rburton> bluelightning: you are the last human being to not be on twitter
Sep 03 14:09:20 <ignus> hi all, is there an easy way of seeing the kernel config used by yocto inside the tmp/ dir?
Sep 03 14:11:21 <bluelightning> ignus: hi
Sep 03 14:12:52 <bluelightning> ignus: tmp/work/<machine>/linux-*/linux-*-build/.config
Sep 03 14:15:41 <ignus> bluelightning, fantastic, thats exactly what i was looking for.
Sep 03 14:16:18 <ignus> bluelightning, my build seems to be picking up an old kernel config and i seriously have no idea where its coming from...
**** ENDING LOGGING AT Tue Sep 04 02:59:58 2012

**** BEGIN LOGGING AT Tue Sep 04 02:59:58 2012
Sep 04 07:50:15 <mckoan> good morning
Sep 04 08:35:38 <bluelightning> morning all
Sep 04 09:09:01 <rburton> morning
**** ENDING LOGGING AT Tue Sep 04 10:09:37 2012

**** BEGIN LOGGING AT Tue Sep 04 10:12:19 2012
Sep 04 10:21:18 <JaMa> bluelightning: ping
Sep 04 10:21:52 <JaMa> bluelightning: I've just seen #2977 again and can provide some details to reproduce it
Sep 04 11:54:11 <JaMa> sgw: ping
Sep 04 12:15:32 <JaMa> bluelightning: how do you ensure upgrade path on target from task-* recipes to packagegroup-*?
Sep 04 12:16:12 <JaMa> bluelightning: tasks are installed mostly by image recipe, so target will stay on task-* which won't be ever upgraded
Sep 04 12:20:59 <JaMa> ah, there are RPROVIDES at least in some renamed recipes
Sep 04 12:31:17 <bluelightning> JaMa: there's a RPROVIDES yes
Sep 04 12:42:31 <JaMa> RP: ping6 about udev-extraconf (I would like to be able to parse meta-openmoko with oe-core master..)
Sep 04 12:43:07 <RP> JaMa: ah, yes. Thanks for reminding me as that has slipped through the cracks :/
Sep 04 12:47:22 <JaMa> bluelightning: and does RPROVIDES really work?
Sep 04 12:48:01 <JaMa> bluelightning: I've added it to all meta-oe/meta-smartphone/meta-webos task-* recipes including PR bump and nothing is upgraded on target
Sep 04 12:48:10 <bluelightning> JaMa: I'm not sure if it will help in that situation
Sep 04 12:48:22 <JaMa> bluelightning: I guess you have to add RREPLACES too
Sep 04 12:49:23 <RP> JaMa: looking at the patch, its going to break oe-core's udev
Sep 04 12:51:17 <JaMa> how?
Sep 04 12:51:35 <RP> JaMa: both would provide mount.sh and network.sh
Sep 04 12:51:48 <JaMa> there is also http://patchwork.openembedded.org/patch/33185/ fwiw
Sep 04 12:52:21 <RP> JaMa: that doesn't solve the file and rule duplication
Sep 04 12:52:46 <RP> JaMa: Let me try and sort this out...
Sep 04 12:52:56 <bluelightning> JaMa: I can send a follow-up patch to add RREPLACES but I'm concerned about the added cruft, when can we reasonably remove them?
Sep 04 12:53:59 <JaMa> bluelightning: I don't know, never?
Sep 04 12:54:11 <JaMa> as some users tend to upgrade from very old images sometimes
Sep 04 12:54:28 <bluelightning> JaMa: :/
Sep 04 12:54:58 <JaMa> bluelightning: and I'm not sure if RREPLACES does work (haven't tried yet)
Sep 04 12:55:14 <bluelightning> JaMa: it'll work as well as the package manager implements it
Sep 04 12:56:21 <bluelightning> if I had the choice I'd rather we had such things in a separate inc file
Sep 04 12:56:22 <JaMa> RP: etc/udev/rules.d/local.rules is also duplicate :/
Sep 04 12:56:46 <JaMa> bluelightning: I have about 30 such task-* recipes I don't want 30 new .inc files :/
Sep 04 12:56:57 <bluelightning> JaMa: you only need one...
Sep 04 12:57:07 <JaMa> those are in about 6 different layers
Sep 04 12:57:16 <RP> bluelightning: I've wondered about putting the RREPLACES in a separate file with pn- overrides
Sep 04 12:57:21 <RP> JaMa: yes, its a bit of a mess :/
Sep 04 13:04:47 <bluelightning> RP: I've just tested quickly, that could indeed work
Sep 04 13:06:32 * JaMa testing on other layers
Sep 04 13:10:46 * RP wishes his phone would figure out he was in his home timezone
Sep 04 13:12:28 <moolinex> RP: get it near a window, to notice the familiar view
Sep 04 13:13:25 <JaMa> bluelightning: even with RREPLACES opkg does not upgrade them
Sep 04 13:14:07 <JaMa> bluelightning: http://pastie.org/4662063
Sep 04 13:14:17 <JaMa> bluelightning: so last one to mix RCONFLICTS :)
Sep 04 13:14:24 <bluelightning> JaMa: are you sure? Koen has insisted on the addition of RREPLACES in the past for this exact situation... surely he tested it then?
Sep 04 13:14:30 <bluelightning> JaMa: but they don't conflict
Sep 04 13:15:03 <JaMa> not on files, but if some other task depends on new packagegroup, then opkg will make sure to remove task-* before it
Sep 04 13:16:13 <JaMa> bluelightning: the problem is that task-* are installed by image (not pulled as dependency of something else)
Sep 04 13:16:24 <bluelightning> adding RCONFLICTS to fix broken opkg behaviour is wrong, IMHO
Sep 04 13:16:40 <JaMa> and maybe even with thise it won't work :/
Sep 04 13:16:51 <bluelightning> JaMa: so unfortunately the version of my changes without PR bumps went in :/ does it make a difference if you bump PR?
Sep 04 13:17:01 <JaMa> no
Sep 04 13:17:11 <JaMa> I did and as you see in that pastebin it's ignored
Sep 04 13:18:27 <RP> JaMa: I've tweaked the udev-extraconf stuff and merged it
Sep 04 13:18:33 <bluelightning> how did we deal with this situation in the past? this is not the first time we've renamed things...
Sep 04 13:18:35 <JaMa> RP: thanks
Sep 04 13:18:52 <RP> JaMa: I reworded it to be a move of bits udev -> udev-extraconf
Sep 04 13:18:52 <JaMa> bluelightning: manuall install works, but old task-* stays too http://pastie.org/4662099
Sep 04 13:19:11 <JaMa> I've read pushed commit
Sep 04 13:20:02 <RP> JaMa: oe-core had some tweaks in the script to reduce the number of boot time forks
Sep 04 13:20:14 <RP> JaMa: I've tried to preserve them
Sep 04 13:25:12 <bluelightning> JaMa: can you add RCONFLICTS and check if that works?
Sep 04 13:26:35 <JaMa> yes
Sep 04 13:27:04 <JaMa> but I'm running out of targets to upgrade :)
Sep 04 13:39:00 <JaMa> bluelightning: yes it seems to work
Sep 04 13:39:29 <JaMa> Upgrading packagegroup-shr-minimal-x (2.0-r55) to root...
Sep 04 13:39:36 <bluelightning> JaMa: right, AIUI this is opkg mimicking debian policy, so it's not broken, it's just annoying for this kind of replacement
Sep 04 13:39:36 <JaMa> Removing package task-shr-minimal-x from root...
Sep 04 13:39:54 <JaMa> yes especially with 8 subpackages in one recipe :)
Sep 04 13:40:00 <JaMa> 24 new lines
Sep 04 13:40:21 <bluelightning> JaMa: indeed, I'm going to propose it as a separate inc file
Sep 04 13:40:33 <bluelightning> it's egregious otherwise IMO
Sep 04 13:41:08 <rburton> bluelightning: don't you dare criticise debian policy, it's perfection in literary form!
Sep 04 13:41:09 <JaMa> and how to solve it in different layers?
Sep 04 13:41:29 <JaMa> I'm sending patch to meta-oe with them in recipes
Sep 04 13:44:06 <bluelightning> rburton: heh
Sep 04 13:44:38 <bluelightning> JaMa: btw, task-x11* in meta-oe should go away completely
Sep 04 13:45:05 <bluelightning> JaMa: they should be replaced with packagegroup-x11*  after my changes
Sep 04 13:45:22 <bluelightning> er, packagegroup-core-x11*
Sep 04 13:45:51 <JaMa> there is no upgrade path to packagegroup-core-x11*
Sep 04 13:46:03 <JaMa> so same problem as task-* rename
Sep 04 13:46:06 <bluelightning> JaMa: why can't there be?
Sep 04 13:46:22 <bluelightning> JaMa: I made the contents largely the same
Sep 04 13:46:26 <JaMa> it can, but it needs to be in oe-core first
Sep 04 13:47:08 <JaMa> +RPROVIDES_${PN} += "packagegroup-xserver task-x11-server task-xserver"
Sep 04 13:47:11 <JaMa> +RREPLACES_${PN} += "packagegroup-xserver task-x11-server task-xserver"
Sep 04 13:47:14 <JaMa> +RCONFLICTS_${PN} += "packagegroup-xserver task-x11-server task-xserver"
Sep 04 13:47:21 <bluelightning> JaMa: I can't add it there unless I get agreement that task-x11* will be removed from meta-oe
Sep 04 13:47:25 <JaMa> something like this ^ and the same for -utils and
Sep 04 13:47:50 <JaMa> if packagegroup-core-x11 provides same functionality and upgrade path then you'll get my Ack
Sep 04 13:58:28 <bluelightning> JaMa: OK, I'm going to put them in the recipes for now as it's less work, with the caveat that these values will almost certainly be moved out at some point in the future
Sep 04 13:58:53 <JaMa> ok, fine with me
Sep 04 13:59:42 <RP> rburton: Dare I ask why we need three config lines to do one thing? When at least two of the lines don't seem to do much on their own?
Sep 04 13:59:48 * RP hides
Sep 04 14:00:03 <rburton> RP: HERETIC!
Sep 04 14:01:12 <rburton> you could have a new variable with precise "this package is a rename of another package" semantics, that expands to those three lines on dpkg/opkg
Sep 04 14:01:48 <RP> rburton: it might be simpler to do something like that ultimately
Sep 04 14:02:48 <JaMa> sometimes you need only 2 of them
Sep 04 14:03:15 <JaMa> e.g. when on bigger package is split to smaller one you need RREPLACES and RCONFLICTS but not RPROVIDES for smaller
Sep 04 14:04:03 <rburton> yeah, they all have specific semantics and you only need all three for packages-with-files-that-conflict
Sep 04 14:04:12 <rburton> for meta-packages you don't need the conflicts (on dpkg)
Sep 04 14:04:19 <rburton> as they don't conflict - you can install both
Sep 04 14:04:53 <JaMa> rburton: and does dpkg upgrade from old to new without conflicts?
Sep 04 14:05:21 <rburton> JaMa: replaces *should* be enough...
Sep 04 14:05:42 <rburton> JaMa: i'll admit that all my packages had files, so had conflicts too
Sep 04 14:10:04 <rburton> so who actually builds meta-handhelds?
Sep 04 14:10:24 <JaMa> I'm
Sep 04 14:10:29 <JaMa> spitz only
Sep 04 14:10:39 <JaMa> and ant does probably
Sep 04 14:11:15 <rburton> JaMa: i've a patch to xserver-xorg so if the distro doesn't have the opengl feature it turns off dri/glx. which means no mesa-xlib farce.  want to test it?
Sep 04 14:12:06 <rburton> also, what's the going rate for a spitz these days? I'm sure my old one is still in the office somewhere? they must be rare now!
Sep 04 14:13:35 <JaMa> rburton: I can later, but now I have 10 builds from scratch and builders are running out of space.. so a bit busy
Sep 04 14:14:36 <rburton> JaMa: hehe, that's fine.  i can start a build and cross my fingers.  what image would be a good start?
Sep 04 14:15:09 <JaMa> I'm using my shr images
Sep 04 14:16:07 <JaMa> and also not xserver-lite like nodistro config does for spitz
Sep 04 14:16:33 <rburton> yeah, i've a patch to remove that too
Sep 04 14:16:53 <rburton> you know -lite saves a grand total of sixteen k
Sep 04 14:17:05 <rburton> it's almost like modular packaging is useful
Sep 04 14:17:20 <JaMa> yes I wanted to remove it too.. but that was refused back then
Sep 04 14:18:23 <rburton> JaMa: so the shr layer changes the spitz provider, or is that a local tweak?
Sep 04 14:22:45 <bluelightning> rburton: me
Sep 04 14:23:26 <bluelightning> (I have a spitz as well :)
Sep 04 14:24:17 <JaMa> rburton: distro sets P_P for xserver as well as virtual/libgl
Sep 04 14:25:05 <rburton> JaMa: i presume you don't actually use GL on a spitz :)
Sep 04 14:25:52 <rburton> bluelightning: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=ross/xorg&id=97b1a2a62cd120fa8eb458a6998adb5d2bc6d13e <-- no glx in xserver-xorg unless the opengl distro feature is set.
Sep 04 14:26:16 <bluelightning> rburton: I think that's reasonable
Sep 04 14:26:27 <rburton> bluelightning: just needs someone to confirm it builds :)
Sep 04 14:26:45 <bluelightning> rburton: I have my hands a bit full atm I'm afraid :(
Sep 04 14:26:51 <rburton> well, builds and works and doesn't still pull in mesa anyway
Sep 04 14:26:56 <rburton> np
Sep 04 14:31:27 <JaMa> RP: udev.inc still has mount.sh and networks.sh in SRC_URI
Sep 04 14:35:53 <JaMa> RP: something like http://bpaste.net/show/43727/ should help
Sep 04 14:41:28 <RP> JaMa: thanks, fix pushed
Sep 04 14:58:03 <darknighte> RP: we having the tech call today?
Sep 04 15:01:32 <scottrif> Scott Rifenbark joined the bridge
Sep 04 15:01:45 * rburton will be on the bridge shortly
Sep 04 15:02:27 <tomz2> Tom Zanussi here
Sep 04 15:02:39 <laur> LaurentiuP joined
Sep 04 15:02:40 <nitink1> nitin is on the bridge YPTM
Sep 04 15:02:41 <dvhart> YPTC: Darren has joined
Sep 04 15:02:41 <cristianiorga> Cristian Iorga, Yocto Team Intel Romania in audio and online meeting
Sep 04 15:02:46 * moolinex joined
Sep 04 15:02:50 <Zagor> Björn Stenberg joined
Sep 04 15:02:54 * bogdanm joined
Sep 04 15:03:04 <zeddii> YPTC: Bruce joined
Sep 04 15:03:06 <darknighte> YPTM: Sean Hudson on the call
Sep 04 15:03:10 <darknighte> Song_Liu: ^^
Sep 04 15:03:19 <strassek> YPTM: Kevin Strasser is here
Sep 04 15:03:58 <davest> YPTM: davest is on the call
Sep 04 15:04:08 <bluelightning> YPTM: Paul Eggleton is on the call
Sep 04 15:04:23 <davest> YPTM: sorry we made Song late
Sep 04 15:04:24 <sgw> YPTM: Saul is here
Sep 04 15:04:26 <Song_Liu> YPTM: Hi everyone, let's start the tech meeting now. Who's on the bridge?
Sep 04 15:04:30 <RP> YTPM: RP is here too
Sep 04 15:04:45 <Jefro> YPCC Jefro is on bridge
Sep 04 15:04:55 <RP> darknighte: yes, its on now
Sep 04 15:05:09 <scottrif> Scott Rifenbark is also here
Sep 04 15:05:10 <tomz2> tomz here too again
Sep 04 15:05:16 <nitink1> nitin is on the bridge too
Sep 04 15:05:18 <RP> Jefro: YPCC?
Sep 04 15:05:21 <LaurentiuSerban> Laurentiu Serban is here
Sep 04 15:05:22 <bogdanm> YPTM: bogdanm is still here
Sep 04 15:05:36 <cristianiorga> Zagor: Hello Bjorn, I have been an Enea employee for 3 years :-D
Sep 04 15:05:36 <Zagor> Björn joined too
Sep 04 15:05:47 <Zagor> cristianiorga: hi
Sep 04 15:06:17 <RP> dvhart: you were just early
Sep 04 15:06:18 <Jefro> RP yocto project conference call - used wrong initials
Sep 04 15:06:36 * zeddii has a four letter capital he can use.
Sep 04 15:06:43 <darknighte> zeddii: beat me to it!
Sep 04 15:06:45 <Song_Liu> YPTM: any opens?
Sep 04 15:06:49 <bogdanm> YPTM: no opens
Sep 04 15:06:49 <zeddii> :)
Sep 04 15:06:50 <RP> zeddii: I'm sure you were not the only one thinking that
Sep 04 15:06:53 <jkridner___> gm all
Sep 04 15:06:57 <davest> YPTM: no opens
Sep 04 15:07:00 * darknighte chuckles 
Sep 04 15:07:00 <RP> darknighte: I was expecting that from you for some reason...
Sep 04 15:07:16 * darknighte tries to look innocent
Sep 04 15:07:27 * darknighte fails pretty miserably
Sep 04 15:07:30 <rburton> YPTM: here
Sep 04 15:07:38 <zeeblex> me joined
Sep 04 15:07:50 <adamian> no opens
Sep 04 15:08:01 <darknighte> Song_Liu: no opens from me
Sep 04 15:08:28 <Song_Liu> YPTM: https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.3_Status
Sep 04 15:09:25 <dvhart> RP, early?
Sep 04 15:09:51 <RP> dvhart: I don't think Song_Liu scrolled back to that point or maybe wasn't in the channel
Sep 04 15:11:05 <darknighte> Song_Liu: where on the page are you?
Sep 04 15:11:38 <dvhart> ah
Sep 04 15:11:46 * darknighte is still tired
Sep 04 15:12:10 <darknighte> 28% reduction isn't bad at all.
Sep 04 15:13:57 <RP> darknighte: I'm very pleasantly surprised
Sep 04 15:23:00 <davest> Ah the clicking
Sep 04 15:23:51 <davest> The clicking sounds like someone with a weak headset battery?
Sep 04 15:24:48 <davest> Or maybe a bluetooth headset wandering out of range? Maybe that's why the culprint never knows about it, because they wander from the IRC
Sep 04 15:25:05 <scottrif> we have this clicking every week
Sep 04 15:25:23 <davest> So I have heard
Sep 04 15:28:42 <rburton> my son was talking about dinosaurs drinking my coffee - what's the current topic?
Sep 04 15:29:17 <Song_Liu> YPTM: Anyone would like to share something with all of us?
Sep 04 15:29:34 <adamian> ro guys, please do the rounds :)
Sep 04 15:29:57 <dvhart> bluelightning++
Sep 04 15:31:26 <darknighte> bluelightning: +1 on the changes
Sep 04 15:32:19 <darknighte> RP: http://www.yoctoproject.org/branding-compliance-guidelines
Sep 04 15:35:22 <Zagor> RP: that sounds excellent
Sep 04 15:36:06 <RP> Zagor: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t5&id=f17d0a39e05a431ab7c0ce61af076ed000a12eb8 if you want to experiment
Sep 04 15:36:31 <RP> Zagor: probably won't make 1.3 but interesting to experiment with nonetheless
Sep 04 15:36:40 <Zagor> indeed
Sep 04 15:38:44 <RP> Zagor: I would add I wrote this on a plane suffering sleep deprivation and have not re-read it since ;-)
Sep 04 15:38:53 <Zagor> haha
Sep 04 15:39:37 <moolinex> halstead: there's a patchwork instance running on openembedded.org
Sep 04 15:40:52 <Song_Liu> YPTM: thank you all for joining the meeting, you have a nice day/evening!
Sep 04 15:42:35 <bluelightning> sgw: we don't need any R* backwards compatibility for meta-qt3 do we?
Sep 04 15:43:08 <sgw> bluelightning: sorry not parsing R*
Sep 04 15:43:21 <halstead> moolinex, Yes, http://patches.openembedded.org/ is an example of patchwork collecting without being used for state updates.
Sep 04 15:43:22 <bluelightning> sgw: i.e. RPROVIDES/RREPLACES/RCONFLICTS
Sep 04 15:43:51 <sgw> not sure, the meta-qt3 is for LSB requirements
Sep 04 15:44:32 <bluelightning> right
Sep 04 15:44:39 <bluelightning> I'm going to assume the answer is no
Sep 04 15:44:49 <sgw> moolinex: RP and I want a place to be able to test state updating on the oe-core and poky patches
Sep 04 15:47:53 <moolinex> halstead: that's the one, i thought the usage scenario was the same, and mentioned it
Sep 04 15:47:57 <moolinex> sgw: ok, i see
Sep 04 16:45:14 <JaMa> rburton: xf86-video-glamo in meta-oe is using EXA
Sep 04 16:45:21 <JaMa> fixing RDEPENDS now
Sep 04 17:10:08 <FalCone> Anyone around for a dumb question?
Sep 04 17:10:43 <bluelightning> FalCone: we're around for any questions, sure :)
Sep 04 17:10:50 <FalCone> Yeah, awesome.
Sep 04 17:11:04 <FalCone> I'm just trying to get my ~first build~ done. That was cool. It just ran.
Sep 04 17:11:23 <FalCone> But now I'm trying to get it to go for PowerPC, and I'm wondering if I'm supposed to actually change more
Sep 04 17:11:28 <FalCone> than just that one line in local.conf
Sep 04 17:13:20 <FalCone> It's baby's first, so I'm kinda just derping my way through the whole thing. Heh.
Sep 04 17:14:37 * kergoth plays around with aboriginal
Sep 04 17:15:15 <bluelightning> FalCone: are you trying to build for qemuppc or a PPC machine via an existing BSP, or are you adding support for a new machine?
Sep 04 17:15:51 <FalCone> Uh. I would tell you if I knew. I'm just trying to generate something that'll run on PowerPC as it is
Sep 04 17:16:01 <FalCone> Nothing terribly fancy, I don't think.
Sep 04 17:17:05 <evanp> FalCone: do you mean a real physical PowerPC machine you have, or a virtual one emulated via QEMU?
Sep 04 17:17:27 <FalCone> The virtual one for now.
Sep 04 17:17:44 <FalCone> Eventually going into an actual box, just trying to get it to go, first.
Sep 04 17:17:47 <bluelightning> FalCone: ok, in which case it should be enough to change MACHINE to qemuppc
Sep 04 17:18:46 <FalCone> Well, I did that, but I'm getting a failure
Sep 04 17:19:11 <kergoth> ugh, i really wish the task rename hadn't gone into oe-core so quickly. i'm definitely holding off on updating my layers
Sep 04 17:19:38 <FalCone> "ERROR: Task 518 (/poky-denzil-7.0.1/meta/recipes-kernel/linux/linux-yocto_3.2.bb, do_kernel_configme) failed with exit code '1' "
Sep 04 17:19:58 <FalCone> it exclaims, much to my chagrin
Sep 04 17:25:33 <FalCone> I dunno :V
Sep 04 17:30:05 <FalCone> Any tips bluelightning? evanp? Scratching my head a bit with no real clue. Heh.
Sep 04 17:31:01 <evanp> FalCone: what yocto version/branch are you using?
Sep 04 17:31:25 <FalCone> denzil 7.0.1, I think
Sep 04 17:35:50 <evanp> FalCone: maybe try the head of the release branch out of git? don't see anything really obvious, but there are some commits that mention PPC....
Sep 04 17:36:05 <evanp> evanp: that is, the denzil branch
Sep 04 17:36:17 <FalCone> Yeah, I'll give that a shot.
Sep 04 17:37:53 <FalCone> Uh
Sep 04 17:37:56 <FalCone> Where do I clone that from?
Sep 04 17:38:27 <evanp> FalCone: git://git.yoctoproject.org/poky
Sep 04 17:40:21 <FalCone> just clone that and try to configure/bake that again, then, correct, evanp?
Sep 04 17:40:30 <FalCone> Sorry, kinda really new.
Sep 04 17:41:22 <evanp> "git checkout origin/denzil" first; that'll put you on that branch
Sep 04 17:52:14 <evanp> anyone know where the code is that makes certain nativesdk RPMs not have "-nativesdk" in them? e.g. libmpfr4-3.1.0-r1.x86_64.rpm instead of elfutils-nativesdk-0.148-r7.x86_64.rpm? I've been skimming and grepping for a while and haven't found the smoking gun. Anyone know where I should focus my attention?
Sep 04 17:52:55 <kergoth> i'm guessing you're hitting the shlib based renaming from debian.bbclass, but i've never messed with nativesdk
Sep 04 17:53:07 <evanp> no, I'm just trying to understand how that happens so that I can make it happen in another place
Sep 04 17:53:08 <bluelightning> kergoth: it was faster than I'd planned... FYI if it helps I posted a script to do the rename for other layers
Sep 04 17:53:20 <kergoth> cool, that should be useful
Sep 04 17:53:35 <bluelightning> kergoth: https://gist.github.com/3608439
Sep 04 17:57:45 <evanp> oh, I see. debian.bbclass is inherited unconditionally....
Sep 04 17:57:52 <kergoth> yes
Sep 04 17:58:30 <kergoth> actually, i rather dislike debian.bbclass. i'd think we could just rprovide the shlib names for package management systems that cant handle it themselves (e.g. dpkg, opkg)
Sep 04 18:03:01 <evanp> kergoth: you're right, it's definitely debian.bbclass. thanks.
Sep 04 18:03:21 <kergoth> np
Sep 04 18:03:44 <kergoth> evanp: there's a mapping rename function/hook that's used to adjust the fields like rdepends/etc to match what was emitted
Sep 04 18:06:45 <evanp> kergoth: do you mean mapping_rename_hook/runtime_mapping_rename in package.bbclass?
Sep 04 18:06:57 <kergoth> yeah
Sep 04 18:07:40 <evanp> kergoth: found that earlier, but I couldn't find the connection between ${PN} and ${PKG_${PN}}, which didn't seem to be set anywhere I looked....;-)
Sep 04 18:08:12 * kergoth nods
Sep 04 18:08:34 <kergoth> PKG is the general mechanism by which we change the names of the packages. it's just not used very often outside of debian.bbclass :)
Sep 04 19:04:20 <evanp> so I tried do_foo_virtclass-bar[noexec] = "1", but apparently that doesn't work. How should I accomplish that?
Sep 04 19:08:24 <evanp> well, "do_foo_virtclass-bar () { : }" seems to work. If there's a different idiom people prefer let me know.
Sep 04 19:13:23 <ag_> Hello.
Sep 04 19:14:14 <ag_> I know that poky disto contains DISTRO_FEATURES_append = " largefile opengl".
Sep 04 19:15:37 <kergoth> evanp: flags don't cross override boundries
Sep 04 19:15:52 <kergoth> evanp: yo'd havce to set it on do_foo directly, or use anonymous python to set it conditionally
Sep 04 19:16:14 <ag_> This opengl FEATURE is not realistic for machines where only libgles is present.
Sep 04 19:17:52 <ag_> So, what i'm asking is, shouldn't this be backfilled?
Sep 04 19:20:04 <kergoth> agreed, it's annoying that there's no clean way to override that append
Sep 04 19:20:16 <ag_> I will submit patch.
Sep 04 19:20:23 <ag_> kergoth: Just needed a confirmation.
Sep 04 19:21:10 <rburton> ag_: i plan on sorting that soon - "opengl" is too vague.  there needs to be machine features for gl and gles, for a start.
Sep 04 19:21:46 <rburton> so when the distro says opengl, the machine features can be inspected, or something.
Sep 04 19:21:59 <rburton> haven't really thought it through yet :)
Sep 04 19:23:05 <ag_> In the meanwhile i need a way to get rid of opengl
Sep 04 19:23:17 <ag_> so the fast (and clean) way would be to backfill
Sep 04 19:24:15 <ag_> rburton: Or... we can do this way:
Sep 04 19:25:30 <ag_> Never-mind. I need to think about this
Sep 04 19:30:05 <rburton> ag_: tell me if you have a brainwave :)
Sep 04 19:30:13 <ag_> rburton: It's a deal.
Sep 04 19:30:35 <rburton> ag_: i want to sort it too - cedartrail has laughable GL support, i've got a raspberry pi, etc etc
Sep 04 19:31:17 <ag_> rburton: This issues comes from rpi. :)
Sep 04 19:31:43 <rburton> it's certainly not new to rpi though
Sep 04 19:32:18 <rburton> but if you have a patch to meta-yocto, send it quick
Sep 04 19:34:53 <ag_> rburton: I will tomorrow. Need sleep now.
Sep 04 19:35:00 <ag_> rburton: Thank you.
Sep 04 20:43:55 <msm> ERROR: Function failed: Fetcher failure for URL: 'http://www.citi.umich.edu/projects/nfsv4/linux/libnfsidmap/libnfsidmap-0.25.tar.gz'. Unable to fetch URL from any source.
Sep 04 20:43:58 <msm> this mirror looks to be down
Sep 04 20:44:43 <msm> and it's not on a mirror yet either
Sep 04 20:46:04 <RP> halstead: Any reason viewing the waterfall on the autobuilder would be slow?
Sep 04 20:46:22 <halstead> RP, I'll check.
Sep 04 20:48:01 <halstead> RP, java is currently using 1800% of CPU resources on the build master.
Sep 04 20:48:21 <halstead> out of 2400% total. ;)
Sep 04 20:48:29 <rburton> sweet
Sep 04 20:48:44 <rburton> see, that pure cpu utilisation is why Fortune 500 chooses java
Sep 04 20:49:16 <RP> halstead: that sounds "suboptimal"? :)
Sep 04 20:49:41 <rburton> why is the java stuff happening on the master?
Sep 04 20:50:02 * rburton assumes there are reasons, don't answer that
Sep 04 20:50:04 <JaMa> rburton: shouldn't that opengl DISTRO_FEATURE be respected only in xserver-xorg (not -lite)?
Sep 04 20:50:15 <rburton> JaMa: -lite is DEAD with this change
Sep 04 20:50:18 <JaMa> rburton: or do you remove -lite just after this?
Sep 04 20:50:19 <halstead> Indeed. We are trying the OracleJDK right now. The master builds eclipse plugin.
Sep 04 20:50:34 <JaMa> yes exactly.. it will be the same for DISTRO with opengl feature
Sep 04 20:51:28 <RP> halstead: hmm, so its the eclipse plugin build? :/
Sep 04 20:52:15 <rburton> JaMa: i should have sent a pull request with a cover letter to explain more
Sep 04 20:53:06 <halstead> RP, I think so. Getting information about the process is timing out.
Sep 04 20:53:30 <RP> halstead: the server is responding a bit better here now...
Sep 04 20:54:15 <halstead> RP, I schedule the java process at 19 and restricted it to idle io (class 3).
Sep 04 20:54:33 <halstead> So everything else should be responsive again.
Sep 04 20:56:21 <rburton> JaMa: see ross/beagle and ross/xorg in poky-contrib.  just need to find a beagle that works to test ross/beagle.
Sep 04 21:01:08 <JaMa> sgw: 404 http://www.yoctoproject.org/tlk
Sep 04 21:06:56 <sgw> yup, that will be there by the time this actually hits an image, Jefro is working on that.
Sep 04 21:07:12 <JaMa> k
Sep 04 21:10:26 <JaMa> rburton: hmm cannot fetch poky-contrib error: there are still refs under 'refs/remotes/contrib/mhatle/bitbake'
Sep 04 21:10:47 <sgw> jama maybe a git remote prune?
Sep 04 21:11:34 <JaMa> doesn't help
Sep 04 21:11:55 <JaMa> it seems like there was "directory" bitbake in mhatle now only one branch, or something like that
Sep 04 21:12:30 <JaMa> rm -rf .git/logs/refs/remotes/contrib/mhatle/bitbake .git/refs/remotes/contrib/mhatle/bitbake/ && git remote update worked
Sep 04 21:14:29 <JaMa> rburton: looking on ross/xorg, why not kill -common.inc now too?
Sep 04 21:15:38 <JaMa> rburton: swap -lite removal and opengl feature commits and it will be easier to just merge xorg-xserver-common.inc to xserver-xorg.inc
Sep 04 21:24:48 <rburton> JaMa: good plan
Sep 04 21:25:36 <JaMa> someone seen some -native (e.g. pango-native) changing sstate checksum each rebuild?
Sep 04 21:27:47 <JaMa> it could be another sstate-cache-management.sh issue, but hash from sstate-cache really isn't in stamps directory after rebuild (but bitbake-diffsigs says only that do_install hash was changed and I don't have do_install.sigdata from previous build)
Sep 04 22:03:50 <JaMa> rburton: and exa module is missing some R* variables too
Sep 04 22:03:51 <JaMa>  * check_data_file_clashes: Package xserver-xorg-module-exa wants to install file /usr/lib/xorg/modules/libexa.so
Sep 04 22:03:54 <JaMa>         But that file is already provided by package  * xserver-xorg
Sep 04 22:04:46 <JaMa> rburton: the problm is that xserver-xorg-module-exa is being installed before xserver-xorg is upgraded
Sep 04 22:07:29 <JaMa> rburton: RREPLACES should be enough
Sep 04 22:29:03 <JaMa> bluelightning: is there some reason why buildhistory does not track RREPLACES/RCONFLICTS/RPROVIDES, but only RDEPENDS/RRECOMMENDS?
Sep 04 22:29:33 <bluelightning> JaMa: nothing deliberate, I just didn't think of it at the time I suppose
Sep 04 22:34:08 <JaMa> bluelightning: not sure how usefull they will be after this packagegroup changes, but I was a bit surprised not to see them in last image build diff
Sep 05 01:06:44 <JaMa> pango-native rebuilds explained and patch sent to ML :)
**** ENDING LOGGING AT Wed Sep 05 02:59:59 2012

**** BEGIN LOGGING AT Wed Sep 05 02:59:59 2012
Sep 05 05:40:25 <evanp> has anybody had any problems with archive-*-source.bbclass? it keeps bombing on me because it's deleted the "tar-package" temporary file it uses internally before it's actually done with it--near as I can tell, anyway
Sep 05 08:05:31 <bluelightning> morning all
Sep 05 08:10:34 <JaMa|Zzz> morning
Sep 05 08:22:41 <ag_> cheers
Sep 05 10:10:54 <rburton> JaMa: there?
Sep 05 10:19:25 <JaMa> y
Sep 05 10:28:10 <rburton> JaMa: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=ross/exa&id=7ae66393d5bac8c1fc16860bf21e21e5c4aa539b <-- fix exa like this?
Sep 05 10:30:53 <JaMa> rburton: yup that should work
Sep 05 10:31:27 <rburton> sent
Sep 05 10:31:37 <JaMa> thx
Sep 05 13:58:26 <kergoth> wtf
Sep 05 13:58:33 <kergoth> i just got global name 'd' is not defined in an ${@} block
Sep 05 14:01:11 <bluelightning> hmm, that doesn't sound right
Sep 05 14:01:51 <kergoth> yeah.. very strange, something is seriously wrong here
Sep 05 14:03:43 <Crofton|work> bluelightning, what are the chances of getting oe-core to support sqitching beteewn sysvinit and systemd for the next release?
Sep 05 14:18:17 <bluelightning> Crofton|work: in the 1.4 timeframe, I think that's likely to happen
Sep 05 14:21:05 <Crofton|work> 1.4 is the next cyckle, or the one after :)
Sep 05 14:21:13 <Crofton|work> I can't keep names and numbers traight :)
Sep 05 14:21:48 <rburton> Crofton|work: we're working towards 1.3 now, just feature froze yesterday
Sep 05 14:21:57 <Crofton|work> ok
Sep 05 14:22:07 <Crofton|work> that is what I thought, and 1.4 planning is underway
Sep 05 14:22:20 <bluelightning> Crofton|work: indeed
Sep 05 14:22:22 <Crofton|work> and denzil == 1.2?
Sep 05 14:22:25 <bluelightning> yep
Sep 05 14:22:30 <Crofton|work> madness
Sep 05 14:22:46 <Crofton|work> :)
Sep 05 14:23:00 <Crofton|work> must book elce hotel and flight
Sep 05 14:23:11 <bluelightning> hmm yes I need to sort that out
Sep 05 14:23:17 <bluelightning> too
Sep 05 14:46:28 <jwessel> Is there any kind of log or way to debug the hob hanging?
Sep 05 14:46:47 <jwessel> It just sits at "Populated recipes 99%" forever.
Sep 05 14:47:51 <bluelightning> jwessel: hmm, seems to be a known bug (bugzilla bug 2895)
Sep 05 14:48:01 <bluelightning> jwessel: unfortunately there is no log I'm afraid
Sep 05 14:48:39 <bluelightning> I think it's fair to say that current master has a fair few hob bugs which we will do our utmost to address before the 1.3 release
Sep 05 14:48:55 <jwessel> Is there any kind of work around?
Sep 05 14:49:16 <jwessel> The bug report does not seem to indicate any kind of actual cause.
Sep 05 14:49:49 <jwessel> I get this problem Right after selecting the target machine.
Sep 05 14:49:57 <jwessel> Everything is just grayed out forever in the UI.
Sep 05 14:50:41 <jwessel> The lack of any kind of way to know what it is that it is doing or where it is within the statemachine does not lend itself to understanding of where to look at the problem.
Sep 05 14:51:39 <jwessel> Where are all the debug logs going?  Is there no way to get them from the cooker or anything?  Because I am wondering if something threw an exception or what.
Sep 05 15:06:15 <bluelightning> jwessel: I have to admit I don't know, my familiarity with hob code is limited
Sep 05 15:08:42 <jwessel> bluelightning: I zero about the internals of the hob.
Sep 05 15:08:55 <jwessel> I was trying to figure out the flow of the code, but it is not obvious at all.
Sep 05 15:09:06 <jwessel> I don't understand what generates the events to transition from one state to another.
Sep 05 15:09:21 <bluelightning> jwessel: it's heavily tied to the internals of bitbake which does make it difficult to follow I agree
Sep 05 15:09:48 <jwessel> I figure I can probably fix the problem I if can figure out where it left off.
Sep 05 18:08:48 <chackal_sjc> how to I create an image with not rootfs in it?
Sep 05 18:08:52 <chackal_sjc> just stuff that I want
Sep 05 18:18:28 <kergoth> ?
Sep 05 18:18:31 <kergoth> create an image recipe of your own
Sep 05 18:18:36 <kergoth> there are plenty of examples to base it on
Sep 05 18:19:10 <chackal_sjc> kergoth: I did that, but I would like to generate a .tar.gz with the image like the core-image.bb does
Sep 05 18:19:39 <kergoth> so set IMAGE_FSTYPES to whatever image formats you want
Sep 05 18:19:52 <kergoth> it's a space separated list of formats
Sep 05 18:19:56 <kergoth> e.g. tar.gz ext3 live
Sep 05 18:22:06 <chackal_sjc> kergoth: but if I do inherit image in my image recipe, it will generate a .tar.gz with the entire rootfs, ie, with binaries and stuff
Sep 05 18:23:08 <chackal_sjc> kergoth: with IMAGE_FSTYPE  = "empty" still generating some trash, like /usr/locale/... and others
Sep 05 18:26:56 <kergoth> huh?
Sep 05 18:27:03 <kergoth> *you* decide what packages go into the image
Sep 05 18:27:08 <kergoth> if you don't want base-files, don't install base-files
Sep 05 18:27:17 <kergoth> IMAGE_INSTALL controls what packages go into the image
Sep 05 18:27:23 <kergoth> (and IMAGE_FEATURES)
Sep 05 18:28:38 <chackal_sjc> kergoth: how do I remove the rpm package manager?
Sep 05 18:31:33 <evanp> chackal_sjc: just don't put "package-management" in IMAGE_FEATURES
Sep 05 18:32:11 <kergoth> chackal_sjc: again, you have full control over what goes into the image, set IMAGE_INSTALL and IMAGE_FEATURES to what you want
Sep 05 18:41:21 <evanp> why are the *.src.rpm files generated by archiver.bbclass/archive-*-source.bbclass are actually _binary_ RPMs...?
Sep 05 18:44:30 <fray> the class is used for the license compliance (if it's what i think it is)..
Sep 05 18:44:48 <fray> one of the archiving steps is to determine the format of the source archive.... tar, cpio, srpm
Sep 05 18:44:59 <fray> it should generate a packaged srpm
Sep 05 18:45:44 <chackal_sjc> kergoth: I'm doing this; http://paste.kde.org/544454/
Sep 05 18:45:49 <chackal_sjc> and still installing the package-manager
Sep 05 18:45:51 <evanp> fray: if I run "file" on the srpm, it says it's actually a binary RPM. The two formats, source and binary, have different magic apparently.
Sep 05 18:46:05 <fray> there is no real difference..
Sep 05 18:46:08 <fray> and file is often wrong
Sep 05 18:46:42 <evanp> fray: I noticed because rpmbuild refuses to do anything with them, claiming they're binary
Sep 05 18:47:13 <fray> host rpmbuild or the rpmbuild from the system?
Sep 05 18:47:24 <fray> also the srpms being generated are really just archives.. they won't actually rebuild..
Sep 05 18:49:15 <evanp> fray: host. Looks like the one inside the sysroot accepts them....
Sep 05 18:50:12 <fray> there ya go.. format difference between the host and the version of rpm in oe
Sep 05 18:50:24 <fray> but really the way to extract them is use rpm2cpio
Sep 05 18:50:42 <fray> (effectively that is all rpm does when you "install" a src.rpm)
Sep 05 18:51:31 <evanp> sigh. guess that means they're useless to me.... only reason I want one is so that people can do "rpmbuild --rebuild out-of-tree-kernel-module.src.rpm"
Sep 05 18:52:26 <fray> ya, that won't work.. these things are not rebuildable, because there are assumptions on the oe-core environment
Sep 05 19:07:06 <kergoth> <3 bitbake -C
Sep 05 20:35:36 <chackal_sjc> kergoth: did you see my image? http://paste.kde.org/544454/
Sep 05 20:35:52 <chackal_sjc> still installing rpm
Sep 05 21:09:53 <kergoth> chackal_sjc: an rpm based image won't install any package manager if package-management isn't in IMAGE_FEATURES. an ipk based image will install run-postinsts. read image.bbclass, see ROOTFS_PKGMANAGE and ROOTFS_PKGMANAGE_BOOTSTRAP
Sep 05 21:10:14 <kergoth> chackal_sjc: also, use bitbake -e to make sure IMAGE_INSTALL and IMAGE_FEATURES are set the way you think they are
Sep 05 21:19:33 <ant_mob> kergoth: enlightning about rootfs pollution of our initramfs barebone images.thx
Sep 05 21:19:49 <ant_mob> bluelightning:^
Sep 05 21:20:05 <kergoth> package-management feature is a bit special, since the contents of ROOTFS_PKGMANAGE_BOOTSTRAP are installed only if the pakcage-management feature is *not* installed
Sep 05 21:20:15 <kergoth> but other than that it's pretty straightforward
Sep 05 21:23:13 <bizhanMona> HI all , I am trying to bring up my x86 system (Sandy Bridge) using Yocto package. I have installed ATI graphic card (Megamind) on my system, the driver for Megamind is packaged as rpm and supports Fedora/Redhat, what do I need to do to support it on Yocto?
Sep 05 21:36:43 <bluelightning> bizhanMona: so in theory the rpm could be just installed directly into the target
Sep 05 21:37:06 <bluelightning> bizhanMona: that will only work if it doesn't rely on dependencies or layouts we don't provide
Sep 05 21:37:28 <bluelightning> bizhanMona: the more robust way to do it is to unpack the rpm and then repackage it
Sep 05 21:37:42 <bluelightning> bizhanMona: there is an example of this in the cedartrail BSPs IIRC
Sep 05 22:11:11 <kergoth> damnit, we can't run bitbake -e when a sanity check is failing, again?
Sep 05 22:12:18 * kergoth is really starting to question yocto's direction, thinking about quitting all contribution on his own time and switching to another project (still have to work on this for work, of course)
Sep 05 22:16:01 <RP> kergoth: well, several of those sanity tests need to happen earlier and it was causing other usability issues. I don't doubt we need a better fix
Sep 05 22:16:11 <bluelightning> kergoth: we don't deliberately look for situations to break things just for you, you know...
Sep 05 22:37:03 <msm> do inc files need to be in the same folder?
Sep 05 22:37:07 <msm> require blah.inc?
Sep 05 22:37:30 <kergoth> relative paths search BBPATH. the dir the including file is in gets automatically injected into bbpath
Sep 05 22:37:39 <kergoth> so e.g. require recipes-core/foo/bar.inc will work too
Sep 05 22:38:49 <msm> kergoth: err, right i tried with meta prepended
Sep 05 22:41:00 <chackal_sjc> kergoth: this inherit rootfs_${IMAGE_PKGTYPE} in image.bbclass is installing some unnecessary rpm stuff
Sep 05 22:41:16 <chackal_sjc> i checked everything else and its good
Sep 05 22:41:28 <chackal_sjc> I just would like to remove some uncessesary files
Sep 05 22:42:37 <msm> does PREFERRED_VERSION override all the types (native, nativesdk, etc?)
Sep 05 22:43:48 <msm> 	im setting PREFERRED_VERSION_qemu = "1.0"
Sep 05 22:43:55 <msm> and not the pref version for qemu-native is also 1.0
Sep 05 22:48:26 <msm> it seems you can go back and override native/nativesdk again
Sep 05 22:49:53 <ag_> Hello everybody. I missed this http://www.mail-archive.com/yocto@yoctoproject.org/msg06000.html at that time but there is an issue while using dash. echo -e "\n" in dash will print "-e and new line".
Sep 05 22:50:01 <ag_> In bash will be just the new line.
Sep 05 22:50:13 <ag_> Here are some more info: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550399
Sep 05 22:52:27 <ag_> The fast fix is to avoid echo and use printf but is this known?
Sep 05 22:52:32 <RP> ag_: where do we run into that issue?
Sep 05 22:52:46 <RP> ag_: I suspect its not well known at least
Sep 05 22:52:52 <ag_> https://github.com/djwillis/meta-raspberrypi/pull/51/files
Sep 05 22:53:29 <RP> ag_: Right. I wonder if that is anywhere in the core? :/
Sep 05 22:53:48 <ag_> Yes,
Sep 05 22:53:58 <ag_> RP: Just gave a search,
Sep 05 22:54:27 * ag_ finds 65 results
Sep 05 22:55:20 <RP> ag_: I need to sleep right now but that is something we need to look at, good catch...
Sep 05 22:55:42 * ag_ needs sleep too :)
Sep 05 22:56:02 <ag_> RP: Ok then. Anyway in meta-rpi i will switch on printf
Sep 05 22:56:14 <ag_> Do you see any problems with that?
Sep 05 22:56:49 <RP> ag_: offhand no but I haven't thought about it a lot ;-)
Sep 05 22:57:34 <ag_> RP: I'll postpone it then.
Sep 05 22:58:10 <ag_> RP: A bug in bugzilla would be a good way to trace this?
Sep 05 22:58:31 <ag_> Or is this chart "report" is enough?
Sep 05 22:58:36 <ag_> Or is this chart "report" enough?
Sep 05 22:58:43 <ag_> Or is this chat "report" enough?
Sep 05 22:58:56 <ag_> (sleepy....)
Sep 05 23:00:57 <msm> is there a preferred way to make a recipe ONLY apply to specific machine/arches for the non-native non-nativesdk case?
Sep 05 23:01:11 <msm> i've come up with some methods that seem to be abusing COMPATIBLE_MACHINE w/ some overrides
Sep 05 23:01:33 <msm> https://gist.github.com/3647033
Sep 05 23:02:48 <msm> well that does not exactly work even but...
Sep 05 23:03:46 <evanp> msm: I don't know if it's the "preferred way" but I've done something very similar
Sep 05 23:04:37 <msm> evanp: is there an example somewhere?
Sep 05 23:05:22 <evanp> msm: my use is variants of COMPATIBLE_MACHINE_pn-eglibc = "((?!(myarch1|myarch2)$).+)"
Sep 05 23:05:54 <evanp> msm: ugly, but it was all I could come up with
Sep 05 23:06:06 <bluelightning> ag_: I suspect a bug report would be helpful if it's code in OE-Core that is triggering it...
Sep 05 23:07:04 <ag_> bluelightning: It was removed the necessity of having sh->bash. So echo -e won't work.
Sep 05 23:07:27 <msm> evanp: is that literally myarch1/2 or machine1/2?
Sep 05 23:09:32 <evanp> msm: you're right, it's really machines; my two machines are also their own architectures so my case is a little weird
Sep 05 23:09:33 <bluelightning> ag_: yes, I got that from what you said above
Sep 05 23:10:30 <ag_> bluelightning: :) then why asking me if is triggered by oe-core? :)
Sep 05 23:13:15 <bluelightning> ok, I misread
Sep 05 23:13:46 <bluelightning> if there are results in scripts that don't declare #!/bin/bash then I guess they need to be fixed, so a bug report is appropriate
Sep 05 23:15:51 <ag_> bluelightning: I understood now your idea. Well after checking there is no script without /bin/bash. But there is a class...
Sep 05 23:16:04 <AdityaGandhi> Hi, I am building using daily snapshots, I compiled a qt4e-demo-image with no modification except enabled a kernel module for mac80211 , but I cannot boot
Sep 05 23:16:17 <ag_> Actually 3: package_rpm.bbclass / deb /ipk
Sep 05 23:16:29 <AdityaGandhi> it's stuck at waiting for removable device
Sep 05 23:17:38 <AdityaGandhi> http://pastebin.com/n3FhcRPC
Sep 05 23:17:44 <AdityaGandhi> can anyone help please
Sep 05 23:22:42 <ag_> bluelightning: But anyway, there is no sign of using rpm_log_check where this echo -e is...
Sep 05 23:25:37 <khem> msm: you would use COMPATIBLE_HOST
Sep 05 23:25:44 <khem> msm: see for eg in oe-core
Sep 05 23:25:54 <ag_> bluelightning: I was wrong. It is called. Thank you anyway. I will sync with RP on this.
Sep 05 23:25:59 <khem> bluelightning: around ?
Sep 05 23:26:27 <ag_> Good night all
Sep 05 23:27:03 <bluelightning> khem: yes I'm still here
Sep 05 23:27:28 <bluelightning> AdityaGandhi: I don't know, but there are quite a few ACPI errors early on, not sure if that is an issue or not...
Sep 05 23:27:31 <khem> bluelightning: if SRC_URI = "file:////x/t/x"
Sep 05 23:27:45 <khem> then it does not hit the local mirror have you seen something similar
Sep 05 23:29:16 <msm> khem: hmm for some reason I thought that was the build host
Sep 05 23:29:29 <msm> khem: but it looks pretty robust and could do it in one line instead
Sep 05 23:29:56 <khem> msm: remember this is target recipe so host in that case is the machine its running on
Sep 05 23:30:04 <khem> not building on
Sep 05 23:30:44 <msm> right, i see examples with targets instead of build machines
Sep 05 23:31:00 <bluelightning> khem: no clues in the do_fetch log?
Sep 05 23:31:13 <khem> bluelightning: it never referenced my local mirror
Sep 05 23:31:19 <msm> khem: is this denzil?
Sep 05 23:31:27 <khem> msm: all on master
Sep 05 23:31:35 <msm> khem: what recipe is failing?
Sep 05 23:32:02 <khem> msm: its something local
Sep 05 23:32:03 <AdityaGandhi> Hmmm bluelightning, I checked they were present in the previous build
Sep 05 23:32:19 <AdityaGandhi> I think when the kernel changed to 3.4.9 some changes that have affected this
Sep 05 23:32:55 <khem> AdityaGandhi: you are booting Linux version 3.4.6-yocto-standard
Sep 05 23:34:41 <AdityaGandhi> but my kernel recepie says 3.4.9, I am confused
Sep 05 23:35:14 <AdityaGandhi> khem: I will try and clean and re build
Sep 05 23:35:22 <AdityaGandhi> thanks for pointing it out,
Sep 05 23:35:49 <bluelightning> AdityaGandhi: you shouldn't need to clean
Sep 05 23:36:10 <khem> bluelightning: btw. I have BB_NO_NETWORK set to 1
Sep 05 23:36:12 <bluelightning> bitbake -e virtual/kernel | grep ^PV
Sep 05 23:36:17 <bluelightning> AdityaGandhi: ^
Sep 05 23:36:30 <AdityaGandhi> bluelightning: I know, but how is it possible that I have kernel 3.4.6 in the latest snapshot
Sep 05 23:36:56 <khem> BB_NO_NETWORK disabled doesnt help either
Sep 05 23:37:08 <bluelightning> AdityaGandhi: if you have something setting a PREFERRED_VERSION somewhere
Sep 05 23:37:26 <bluelightning> khem: off the top of my head I don't know, it ought to work
Sep 05 23:37:53 <khem> SOURCE_MIRROR_URL = ?= "file:///x/y/z"
Sep 05 23:37:57 <khem> INHERIT += "own-mirrors"
Sep 05 23:37:58 <AdityaGandhi> I have tried not to edit recipes, let me check again
Sep 05 23:38:11 <khem> and the tar is in /x/y/z
Sep 05 23:38:15 <khem> but it never looks there
Sep 05 23:39:03 <bluelightning> AdityaGandhi: please check bitbake -e virtual/kernel
Sep 05 23:40:17 <bluelightning> khem: do you have PATH at the end of your MIRRORS entry?
Sep 05 23:42:17 <khem> bluelightning: I think I understand now
Sep 05 23:42:26 <khem> bluelightning: its added to PREMIRRORS
Sep 05 23:42:36 <khem> and PREMIRRORS is missing regrexp for file://
Sep 05 23:43:00 <khem> thats a bug in own-mirrors.bbclass I think
Sep 05 23:43:02 <khem> let me try it
Sep 05 23:44:06 <AdityaGandhi> bluelightning: this is output of my  bitbake -e virtual/kernel : http://pastebin.com/BSh6ieUs
Sep 05 23:44:17 <AdityaGandhi> I could see nothing asking for 3.4.6
Sep 05 23:44:19 <bluelightning> khem: so, why do you want it to be looking in the mirror for a local file that should already exist locally?
Sep 05 23:44:47 <khem> bluelightning: well local location is not shared across all
Sep 05 23:45:14 <khem> bluelightning: no harm in it looking at mirror anyway
Sep 05 23:45:55 <bluelightning> khem: assuming it checks the mirror second, otherwise if the file gets updated in the metadata that won't get used... I don't know what the behaviour is if a file://.* entry is added to  PREMIRRORS
Sep 05 23:46:46 <khem> bluelightning: hmm I can ask for file:///
Sep 05 23:46:50 <bluelightning> AdityaGandhi: on this hardware is the kernel booted from within the root filesystem or some separate partition/memory area?
Sep 05 23:47:49 <AdityaGandhi> from a boot partition which has a rootfs.img which is mounted in the RAM
Sep 05 23:48:37 <bluelightning> AdityaGandhi: ok, was the kernel there updated?
Sep 05 23:49:10 <AdityaGandhi> yes, I created the image using bitbake qt4e-demo-image
Sep 05 23:49:18 <AdityaGandhi> It was a new image that was created
Sep 05 23:49:33 <AdityaGandhi> may be it picked up the old kernel which was compiled earlier
Sep 05 23:49:42 <AdityaGandhi> let me check again
Sep 05 23:49:53 <AdityaGandhi> I am cleaning now, going to compile again
Sep 05 23:50:22 <bluelightning> as I mentioned before, cleaning shouldn't be necessary
Sep 05 23:51:13 <AdityaGandhi> I know, but the space I have is replenished, and I am facing build problems. Hoping a clean will resolve some issues
Sep 05 23:51:29 <msm> khem: HOST_SYS is acually too generic
Sep 05 23:51:30 <AdityaGandhi> I get random failures on few components
Sep 05 23:51:33 <bluelightning> AdityaGandhi: I'd much rather we uncover what the actual problem is
Sep 05 23:52:04 <khem> msm: are these machine specific recipes ?
Sep 05 23:52:05 <msm> MULTIMACH_HOST_SYS would work
Sep 05 23:52:14 <msm> khem: right, but every machine in my layer ;)
Sep 05 23:52:33 <msm> i was just looking for an easier way...
Sep 05 23:52:47 <AdityaGandhi> bluelightning: I will try looking, let me go through conf files again, But I am sure I didn't change any, I just do a git pull each morning and compile again
Sep 05 23:53:28 <bluelightning> AdityaGandhi: I'm not suggesting necessarily that you changing something caused the issue, but if you throw everything away and start again there will be less chance of being able to debug it
Sep 05 23:55:22 <AdityaGandhi> bluelightning: I have not thrown anything away,  I am looking at where the fault is. But I will soon if I cannot find the fault, I have to get an image build with new drivers by tomorrow!
Sep 06 00:06:58 <bluelightning> ok, I have to get some sleep now... bye all
Sep 06 00:08:55 <khem> msm: hmmm you could add a BBMASK
Sep 06 00:47:56 <msm> khem: where would i add a bbmask?
Sep 06 00:48:11 <msm> the other users of my layer would add that
Sep 06 00:48:16 <msm> in this instance, i think
Sep 06 00:49:36 <evanp> anybody using the -nativesdk RPMs to install a cross toolchain? rather than the tarball?
Sep 06 02:05:30 <evanp> hmm... package_rpm.bbclass is passing "--target x86_64-nativesdk-pokysdk-linux" to RPM, which it parses as arch=x86_64 vendor=nativesdk os=pokysdk ignored=linux....
Sep 06 02:06:04 <evanp> that can't be right...right?
Sep 06 02:51:25 <msm> evanp: when did that feature come around?
Sep 06 02:52:29 <evanp> msm: you mean the --target thing?
Sep 06 02:53:22 <evanp> msm: looks like the much of it is from 83ada559 (Aug 11 2011)
Sep 06 02:53:53 <evanp> msm: but it looks like it's an unexpected interaction with anything that sticks a suffix on PACKAGE_ARCH
**** ENDING LOGGING AT Thu Sep 06 02:59:58 2012

**** BEGIN LOGGING AT Thu Sep 06 02:59:58 2012
Sep 06 03:05:45 <msm> no i mean when did they start making rpms for nativesdk stuff
Sep 06 03:09:38 <evanp> msm: oh. based on the birth date of populate_sdk_rpm.bbclass, must be since Jan 2011
Sep 06 03:11:16 <evanp> msm: this strange behavior I've been looking at, and I thought you were asking about, means they probably aren't actually installable though
Sep 06 03:11:34 <evanp> msm: at least not without you using --ignoreos on the rpm command line
Sep 06 03:13:44 <msm> file a bug
Sep 06 03:13:50 <msm> they are good about following up
Sep 06 03:14:15 <evanp> yup
Sep 06 07:31:34 <mckoan> good morning
Sep 06 08:40:28 <bluelightning> morning all
Sep 06 09:00:33 <ag_> morning
Sep 06 10:43:53 <rburton> ag_: writing a nice long mail in reply to your gl post right now
Sep 06 10:44:29 <ag_> rburton: Christmas came earlier. :)
Sep 06 10:44:45 <rburton> i wouldn't go that far :)
Sep 06 10:45:04 <bluelightning> heh
Sep 06 12:20:42 <mertsas> how can I filter out GPLv3 code from yocto. I know I can do INCOMPATIBLE_LICENSE="GPLv3", but this filters out everything mentioning GPLv3, also gcc which has an exception with libgcc, as well as xz where only the build system is GPLv3. As far as I know there should be a "sane" way to do this, without removing libgcc and a couple of other packages.
Sep 06 12:31:18 <_Lucretia_> anyone know what the email address of the meta-gumstix maintainer is? the one in the README bounces
Sep 06 12:59:56 <RP> _Lucretia_: what was their name? have you looked at the mailing list for them?
Sep 06 13:00:18 <RP> mertsas: It should not filter out gcc-cross, only the on target gcc
Sep 06 13:00:44 <RP> mertsas: libgcc should be preserved too
Sep 06 13:02:00 <_Lucretia_> Layer maintainer: Andreas Müller <schnitzeltony@googlemail.de>
Sep 06 13:02:07 <mertsas> yeah, it did. my bad. libgcc was ok, but not gcc, which is ok
Sep 06 13:05:32 <rburton> though i can see that xz should be installable if its only the build system which is v3
Sep 06 13:16:17 <bluelightning> _Lucretia_: try @googlemail.com, he just used that email address today
Sep 06 13:16:37 <bluelightning> _Lucretia_: while you're at it you can tell him the email address in the layer README is broken ;)
Sep 06 13:17:45 <bluelightning> mertsas: rburton: in which case the HOSTTOOLS_WHITELIST_GPLv3 should be used for xz
Sep 06 13:26:40 <mertsas> bluelightning: so HOSTTOOLS_WHITELIST_GPLv3 will accept xz into the toolchain, but not in the image?
Sep 06 13:27:04 <bluelightning> mertsas: I believe so yes
Sep 06 13:27:42 <mertsas> bluelightning: cool. I'll try that then. At least we don't care about gplv3 in the toolchain, so that's nice
Sep 06 13:42:28 <JaMa|Off> bluelightning: looking at our last bugzilla comment, do you have some list of those bitbake revs I should try (with that similar error?)
Sep 06 13:42:58 <bluelightning> JaMa|Off: for 2977? not yet, let me see what I can find
Sep 06 13:43:53 <JaMa|Off> yup that's the one
Sep 06 14:31:34 <Crofton|work> The yocto dev day is Nov 8? Thursday?
Sep 06 14:36:57 <bluelightning> Crofton|work: I think that's what the schedule says yes
Sep 06 14:37:00 <bluelightning> IIRC
Sep 06 14:38:09 <Crofton|work> looking over plane tickets
Sep 06 14:43:46 <bluelightning> I see QEMU 1.2 is out
Sep 06 15:09:53 <bluelightning> JaMa|Off: try these: http://pastebin.com/85CmkLkZ
Sep 06 15:10:25 <bluelightning> JaMa|Off: apply in order from the top - cat filename | xargs -n1 git cherry-pick   :)
Sep 06 15:10:49 <bluelightning> I checked that they apply, didn't actually run bitbake though
Sep 06 16:08:37 <patrickjquinn> Hey guys, what is the proceudre for testing non generic qemu images (e.g atom-pc), when i specifiy "runqemu qemux86 core-image-atom ext" it returns an error regarding missing tunctl from the tmp/sysroots/x86_64-linux/usr/bin
Sep 06 16:20:05 <Fal-Cone> U
Sep 06 16:20:08 <Fal-Cone> Uhhh...
Sep 06 16:20:25 <Fal-Cone> It's not normal for a core-image-sato build to, um.
Sep 06 16:20:34 <bluelightning> um?
Sep 06 16:20:37 <Fal-Cone> Explode and flail python traceback errors ad infinitum.
Sep 06 16:20:38 <Fal-Cone> is it? :|
Sep 06 16:20:43 <bluelightning> no...
Sep 06 16:20:48 <Fal-Cone> Yeah. Didn't think so.
Sep 06 16:21:08 <bluelightning> could you pastebin at least the top part of the error output?
Sep 06 16:21:32 <Fal-Cone> I'd say I could, but was infinite flailing and my ssh session pushed it out of window
Sep 06 16:21:51 <Fal-Cone> It was giving me a ValueError: insecure string pickle
Sep 06 16:22:00 <Fal-Cone> I don't even. Minimal build worked, though, at least :V
Sep 06 16:22:16 <bluelightning> Fal-Cone: it would have written the log to TMPDIR/cooker.log.<DATETIME> or TMPDIR/logs/cooker/cooker.log.<DATETIME>
Sep 06 16:22:32 <bluelightning> (depending on which version you were using)
Sep 06 16:23:27 <Fal-Cone> Yeah, I opened the last logfile it made
Sep 06 16:24:24 <Fal-Cone> The end of the file is a huge repeat of http://pastebin.com/XUByNnwM
Sep 06 16:25:32 <Fal-Cone> I mean, I forgot to change it to PPC like I hoped to, but, uh, it ideally should still work out of the box, right?
Sep 06 16:26:36 <bluelightning> Fal-Cone: yes
Sep 06 16:26:45 <bluelightning> Fal-Cone: can I see the top rather than the repeating part?
Sep 06 16:26:57 <Fal-Cone> Yeah, sure. My bad.
Sep 06 16:27:15 <Fal-Cone> The part where it lists the build config?
Sep 06 16:27:38 <bluelightning> well that might be instructive, but the important bit is the first error shown
Sep 06 16:27:44 <bluelightning> i.e. what went wrong first
Sep 06 16:29:05 <Fal-Cone> Yeah. Okay.
Sep 06 16:29:16 <Fal-Cone> http://pastebin.com/L6pidTRG
Sep 06 16:32:10 <bluelightning> Fal-Cone: have you changed MIRRORS or PREMIRRORS in your configuration?
Sep 06 16:32:20 <Fal-Cone> I changed nothing for this build.
Sep 06 16:32:26 <Fal-Cone> I cloned it, and ran it
Sep 06 16:32:30 <bluelightning> ok
Sep 06 16:33:40 <Fal-Cone> After that, it started looping python error messages
Sep 06 16:34:15 <bluelightning> Fal-Cone: could you pastebin TMPDIR/work/*/gnutls*/temp/log.do_fetch ?
Sep 06 16:36:44 <Fal-Cone> Uh
Sep 06 16:36:48 <Fal-Cone> Gotta find a log.do_fetch first
Sep 06 16:40:08 <Fal-Cone> Uh, it's a lot of comparing ftp locations to each other
Sep 06 16:40:15 <Fal-Cone> Like. A lot of it.
Sep 06 16:41:08 <bluelightning> right, the original fetch failed as you can see in your paste above, so it should go off and find an appropriate mirror
Sep 06 16:41:15 <Fal-Cone> Uh
Sep 06 16:41:16 <bluelightning> (from MIRRORS)
Sep 06 16:41:20 <Fal-Cone> It just keeps adding slashes.
Sep 06 16:41:24 <bluelightning> at that point it seems to have gone wrong
Sep 06 16:41:37 <Fal-Cone> I'm holding page down
Sep 06 16:41:51 <Fal-Cone> the address it's caring about is getting longer, one / at a time.
Sep 06 16:41:54 <bluelightning> again, can you pastebin the top section?
Sep 06 16:41:57 <Fal-Cone> Mhm
Sep 06 16:43:14 <Fal-Cone> http://pastebin.com/V3PJy5Tf
Sep 06 16:43:34 <Fal-Cone> That's what it's giving me when I just, you know output the contents of work/*/gnutls*/temp/log.do_feetch
Sep 06 17:03:25 <bluelightning> Fal-Cone: er, we seem to have an entry that points to itself in mirrors.bbclass (!)
Sep 06 17:03:37 <bluelightning> ftp://ftp.gnutls.org/pub/gnutls ftp://ftp.gnutls.org/pub/gnutls/ \n \
Sep 06 17:03:37 <Fal-Cone> Wasn't me :V
Sep 06 17:06:04 <Fal-Cone> Yeah, that would explain the /////////
Sep 06 17:06:06 <bluelightning> well, try deleting that and see if it helps
Sep 06 17:06:18 <bluelightning> the line that is not the whole file ;)
Sep 06 17:06:28 <Fal-Cone> Mhm.
Sep 06 17:07:09 <Fal-Cone> Uh, where does that live?
Sep 06 17:07:10 <Fal-Cone> :V
Sep 06 17:07:15 <bluelightning> meta/classes/mirrors.bbclass
Sep 06 17:07:24 <bluelightning> sorry, I should have been clearer
Sep 06 17:07:52 <Fal-Cone> Nah, don't stress it.
Sep 06 17:08:04 <bluelightning> RP: I'm assuming there wouldn't be any point to having an entry in mirrors.bbclass that points to itself...?
Sep 06 17:24:36 <bluelightning> hmm, the entry is ancient though...
Sep 06 17:25:06 <bluelightning> Fal-Cone: did that fix it?
Sep 06 17:25:11 <Fal-Cone> Uh
Sep 06 17:25:12 <Fal-Cone> It's building
Sep 06 17:25:18 <Fal-Cone> But it's, well
Sep 06 17:25:21 <bluelightning> right so it got past that point
Sep 06 17:25:24 <bluelightning> ?
Sep 06 17:25:24 <Fal-Cone> building, so I won't know until later.
Sep 06 17:25:34 <bluelightning> well, it got past gnutls do_fetch, that's the key
Sep 06 17:26:04 <Fal-Cone> It blew up around task 1500 or something, didn't it?
Sep 06 17:26:47 <zester> I have a few questions regarding "hob", I was wondering what gui toolkit is it using Gtk, Qt, ... and is there an external python api for hob?
Sep 06 17:27:07 <bluelightning> zester: it's written in PyGTK
Sep 06 17:28:17 <bluelightning> zester: there's no external Python API, no - what would you want to do with it in particular?
Sep 06 17:28:38 <zester> I wanted to build a Qt version.
Sep 06 17:29:49 <zester> Kinda makes it easyer if there was a backend api. Ill have to find and look at hobs source to see how it was put together.
Sep 06 17:30:48 <bluelightning> zester: so, bitbake has an abstraction for UIs that hob makes use of, so I guess you would do it in a similar thing to what it does
Sep 06 17:31:19 <zester> Ahh ok then ill look at both ;)
Sep 06 17:31:31 <bluelightning> so in those terms there is an API
Sep 06 17:31:57 <zester> Thanks ;)
Sep 06 17:32:08 <bluelightning> it's not guaranteed to be fixed though I should warn you
Sep 06 17:32:21 <bluelightning> not that we plan to break it massively either
Sep 06 17:33:40 <zester> Its not a big deal. I was just wondering.
Sep 06 17:33:43 <sgw> fray: thanks for looking at that patch, does the second chunk you mention need to be done now or later?  I don't want to pull something that will break things.
Sep 06 17:34:19 <fray> is anyone using zypper?  if not.. it can be merged now.. if they are.. then we need to sync the patches..
Sep 06 17:34:37 <fray> but we can't ignore the zypper side (it's a pretty simple change since it should be local to the recipe itself and not the sources)
Sep 06 17:35:01 <bluelightning> fray: what do you mean by using?
Sep 06 17:35:18 <fray> with all of the problems of zypper, I wonder if anyone is actually using it
Sep 06 17:35:24 <sgw> fray, I believe it's being tested with by QA, not sure real usage by downstream projects.
Sep 06 17:35:34 <fray> zypper/sat-solver need to know the order of the arch's to do the stuff..  but baring that, it should work fine
Sep 06 17:35:36 <sgw> fray: I thought you guys will be using it.
Sep 06 17:36:02 <bluelightning> fray: well, it worked reasonably well for me when I used it but that was just to refresh and install a few additional packages
Sep 06 17:36:15 <fray> it may just be hte sat-solver and not zyppoer
Sep 06 17:36:20 <fray> it's the do_archgen function
Sep 06 17:36:43 <fray> we just need to match it there as in the rpm generation
Sep 06 17:37:07 <fray> and libzypp..
Sep 06 17:37:11 * bluelightning -> home
Sep 06 17:37:15 <fray> ok.. sat-solver and libzypp -- do_archgen function..
Sep 06 17:37:16 <zester> Is there any chance of a Yocto forum in the future?
Sep 06 17:37:30 <fray> what kind of "forum"?
Sep 06 17:37:46 <sgw> zester: right what kind?
Sep 06 17:37:54 <zester> A searchable one lol the mailing list is a pain in the ass.
Sep 06 17:38:30 <sgw> you mean you don't like the ML archives ;-)
Sep 06 17:39:46 <zester> :) lol Ill refrain from subscribing lol, I am still trying to remove the 10,000+ emails from the tizen projects mailing list.
Sep 06 17:41:07 <fray> I usually end up using google to search mailing lists.. ;)
Sep 06 17:41:29 <fray> but the sheer volume of patches has made it difficult to discuss various topics
Sep 06 17:41:35 <zester> Thats what I was saying lol. Noooo thanks
Sep 06 17:42:33 <zester> Any Qt developers here?
Sep 06 17:42:38 <otavio> +-
Sep 06 17:42:39 <otavio> ;-)
Sep 06 17:44:48 <mranostay> will anyone admit it rather
Sep 06 17:47:23 <zester> I have worked on both dev teams Gtk/Gnome and Qt/Kde for the last 12 years ill take Qt and leave that GObject madness to those who hate them selfs.
Sep 06 17:48:07 <zenlinux> msm, I'm going to use your suggested change to FILES_perf-dbg in kerenel.bbclass for denzil, so I can get an autobuilder run going in a bit
Sep 06 17:56:48 <zester> Would Yocto LSB package builds be cross compatible with other  distros like Debian, Ubuntu, Fedora, ...
Sep 06 17:58:39 <fray> Yocto Project doesn't build "lsb" packages, they build software to support running LSB packages on Yocto Project distributions (when configured properly)
Sep 06 17:58:59 <fray> onyl way to build an LSB package is to use the Linux Foundation/LSB scripts to control the toolchains
Sep 06 17:59:17 <fray> using those it is likely possible to build LSB applications, on a yocto project target when configured with the LSB distro
Sep 06 18:04:59 <msm> zenlinux: ok did you need a patch from me or did you make one?
Sep 06 18:06:31 <zenlinux> msm, just made one
Sep 06 18:06:39 <zenlinux> just giving you a heads-up
Sep 06 18:07:34 <msm> zenlinux: k, i'll check that off my list. thanks
Sep 06 18:42:21 <sgw> khem: around?  Can you add Upstream-Status to your GCC patches fixing the branch is fine, thanks
Sep 06 18:53:02 <msm> does anyone know if there is a standard for renaming ethernet devices if the MAC changes
Sep 06 18:53:07 <msm> or is that just something udev does?
Sep 06 18:53:53 <evanp> zester: do you mean target or nativesdk LSB packages? I spent a day or two seeing how far I could get towards a LSB nativesdk (not very, more important things to do)
Sep 06 19:17:51 <zester> evanp: Well what I mean is building packages on yocto that will work on other lsb compliant distros.
Sep 06 19:19:22 <zester> Like if I build say a gtk+ rpm or deb package that i could install on fedora or ubuntu
Sep 06 19:20:49 <sgw> ag_: you around?
Sep 06 19:23:31 <zester>  work on other distros.
Sep 06 19:24:51 <zester> Crap freenod only posted the last part of my paragraph.
Sep 06 19:28:35 <ag_> sgw: Hello Saul.
Sep 06 19:28:58 * ag_ is around
Sep 06 19:29:15 <sgw> ag_: Did you mention to me that you had looked into Qemu 1.2 update?  or am I confused (which I might well be).
Sep 06 19:29:43 <ag_> Bet on confused. :) Din't do anything on that.
Sep 06 19:29:46 <ag_> didn't*
Sep 06 19:30:02 <sgw> Ok it was someone else then!
Sep 06 19:30:17 <ag_> sgw: About that ipk bug. Did you receive my email?
Sep 06 19:30:48 <ag_> I even sent a separate email to the one who reported that. No feedback.
Sep 06 19:31:05 <sgw> let me look (subject has ipk?
Sep 06 19:31:21 <ag_> :) let me check
Sep 06 19:31:47 <ag_> Any interest in digging into an opkg issue?
Sep 06 19:31:55 <ag_> "Any interest in digging into an opkg issue?" a reply to this
Sep 06 19:33:31 <sgw> Ok, I remember sending that and found it catching up
Sep 06 19:34:24 <sgw> ag_: did you ping him directly also or just via bugzilla, maybe a direct email?
Sep 06 19:35:09 <ag_> Direct mail and comment
Sep 06 19:35:49 <sgw> did you try the information provided in the first comment, that seems like it should be enough
Sep 06 19:38:09 <sgw> ag_: I think if you install package A that has an RRECCOMMENDS package B, which also gets installed, then try to remove package B, it will not remove correctly unless you use --force-depends, that what it seems to me.
Sep 06 19:58:08 <msm> zeddii: can a recipe enable a kernel feature?
Sep 06 20:09:11 <zeddii> yes, but the mechanism varies by kernel.
Sep 06 20:12:25 <ag_> sgw: Ok. I will try this.
Sep 06 20:12:39 <msm> zeddii: whats a recipe that does this?
Sep 06 20:13:45 <ag_> sgw: Wait a sec. What do you mean by: remove? Remove from target? Remove from image?
Sep 06 20:14:11 <sgw> ag_: remove from the target using the opkg tools
Sep 06 20:14:19 <ag_> Understood
Sep 06 20:14:28 <ag_> sgw: Thanks.
Sep 06 20:14:34 <sgw> sure thing
Sep 06 20:14:37 <zeddii> msm. all the linux-yocto ones do it via KERNEL_FEATURES. In my travels, I've seen other methods that use distro or other variables and python/shell routines to sed/modify/add to .config.
Sep 06 20:14:46 <zeddii> I'm sure you'd guess which I'm more familiar with :)
Sep 06 20:15:00 <msm> right, i was more interested in the KERNEL_FEATURES method
Sep 06 20:15:36 <ag_away> Good night!
Sep 06 20:15:54 <msm> what does one need to include to use the KERNEL_FEATURES bits? aka, what class do I include to use the kernel fragments? what does it expect about the base repository? Can we use it with any old repo or does it need a special meta branch?
Sep 06 20:17:01 <zeddii> msm. ok, I can answer all of the above, but can I do it async via email ? I'm timing out for heading out soon. we can obviously post the results if anyone else is interested.
Sep 06 20:18:46 <msm> zeddii: of course
Sep 06 20:18:55 <msm> you can also point me at the docs that exist
Sep 06 20:19:02 <msm> if its mentioned somewhere
Sep 06 20:20:21 <zeddii> msm. will do and will do. want to drop me a reminder email. I'll go home, and completely blank on it.
Sep 06 20:20:28 <zeddii> no beer required.
Sep 06 20:20:36 * zeddii whistles innocently 
Sep 06 20:21:18 <msm> mmm beer
Sep 06 20:21:23 * msm liver still hurts
Sep 06 20:21:31 <fray> heh
Sep 06 20:21:38 * fray hears msm likes to give hugs and kisses
Sep 06 20:21:40 <fray> ;)
Sep 06 20:22:06 <zeddii> he's more of a slapper
Sep 06 20:22:16 <fray> I thought that was before the hugs and kisses.. ;)
Sep 06 20:22:29 * fray lol
Sep 06 20:22:43 <msm> there were no kisses
Sep 06 20:22:46 <msm> lol
Sep 06 20:22:57 <fray> ... that you remember ...
Sep 06 20:23:14 * msm sigh
Sep 06 20:37:38 <Fal-Cone> Uh
Sep 06 20:37:54 <Fal-Cone> So what kind of linux does yocto actually attempt to deploy in these images?
Sep 06 20:38:07 <fray> "what kind"?
Sep 06 20:38:14 <Fal-Cone> Uh, I dunno
Sep 06 20:38:23 <Fal-Cone> version? distro? Anything with a GUI?
Sep 06 20:38:27 <Fal-Cone> I'm horrifyingly new, you see.
Sep 06 20:38:33 <fray> OE-Core/Yocto Project components are used to allow you to define a Linux distribution for your embedded devices..
Sep 06 20:38:58 <fray> it comes with a collection of software information, that in conjunction with various configuration settings allow you to define what you need and build it from scratch..
Sep 06 20:39:09 <fray> it has some similarities w/ Debian.. but they are fairly light
Sep 06 20:39:31 <Fal-Cone> Yeah. But let's say I'm running the quick start guide
Sep 06 20:39:51 <Fal-Cone> Can I necessarily boot what I'm running in simulation into a thing that works?
Sep 06 20:39:55 <fray> then you will be using the poky distribution configuration and likely building a small "core-image-minimal' distribution
Sep 06 20:40:04 <Fal-Cone> c
Sep 06 20:40:39 <fray> distribution configure sets things such as filesystem path layout, if you want pam, selinux, largefile support, etc..
Sep 06 20:40:48 <fray> either option weighs into how much is required for the system to function
Sep 06 20:41:19 <Fal-Cone> Mhm.
Sep 06 20:41:27 <Fal-Cone> But for like
Sep 06 20:41:41 <fray> (beyond quick start -- fairly advanced features) you can also tailor what capabilities eglibc gives you.. i.e. you can turn off wide character support.. our double precision math support..
Sep 06 20:41:55 <Fal-Cone> Yeah, I'd imagine there's plenty of options available
Sep 06 20:41:56 <fray> when building very small systems (i.e. less then 4 mb filesystems) that is very important to be able to do
Sep 06 20:42:04 <Fal-Cone> I'm still on baby's-first, so. Heh.
Sep 06 20:42:35 <Fal-Cone> Trying it out, and seeing if I can just deploy a ppc configured build onto a target device with literally no knowledge of this stuff
Sep 06 20:42:41 <fray> ya.. you want to use the default poky distribution (there are also predefined poky-tiny and poky-lsb)
Sep 06 20:43:03 <fray> if you use qemuppc or happen to have a supported ppc development board.. then you should be able to..
Sep 06 20:43:11 <fray> if not, you'll need to likely learn some of the kernel configuration items
Sep 06 20:43:17 <Fal-Cone> Only one way to find out.
Sep 06 21:45:22 <AdityaGandhi> Hi Guys, I want to know if we can have Open GL with qt4e-demo-image for crown-bay platform
Sep 06 21:46:04 <AdityaGandhi> I mean in the toolchain that is built, cause I am trying to cross compile an app but no opengl headers available
Sep 06 23:18:42 <RP> msm: I smiled reading the scrollback ;-)
Sep 06 23:20:23 <fray> :)
Sep 07 01:09:04 <mranostay> :-)
Sep 07 02:54:48 <msm> RP: i bet ;)
**** ENDING LOGGING AT Fri Sep 07 02:59:59 2012

**** BEGIN LOGGING AT Fri Sep 07 02:59:59 2012
Sep 07 07:05:42 <bluelightning> morning all
Sep 07 07:26:10 <mckoan> good morning
Sep 07 07:52:09 <florian> good morning
Sep 07 10:01:11 <FunkyPenguin> moaning
Sep 07 10:35:32 <FunkyPenguin> what's the correct repo for meta-ti, is it git://git.yoctoproject.org/meta-ti or https://github.com/Angstrom-distribution/meta-ti.git ?
Sep 07 10:35:42 <FunkyPenguin> or does it not matter?
Sep 07 10:39:05 <bluelightning> they're mirrors of eachother  AFAIK
Sep 07 10:39:22 <bluelightning> AIUI the yoctoproject.org one is the "main" one
Sep 07 10:40:36 <FunkyPenguin> bluelightning: thanks, i thought the yoctoproject one would be the canonical one, but thought I should check check
Sep 07 10:46:52 <rburton> | pcm_usb_stream.c:222:3: warning: implicit declaration of function 'mremap' [-Wimplicit-function-declaration]
Sep 07 10:47:09 <rburton> include and gnu defines present, any ideas?  works with denzil, breaks with oe-core master.
Sep 07 10:56:44 <FunkyPenguin> erm, when trying to build sato with both meta-linaro & meta-ti i get http://paste.opensuse.org/72291937, what's the correct way to fix?
Sep 07 11:02:26 <rob_w> your $USER variable is wrong
Sep 07 11:02:32 <rob_w> its not expanding in your context
Sep 07 11:03:01 <rob_w> and you need to stated the licenses of your recipes as well :_)
Sep 07 11:03:24 <rob_w> ${USER} maybe
Sep 07 11:10:06 <bluelightning> FunkyPenguin: have a look at the README file for the layer, there are some extra steps
Sep 07 11:10:16 <bluelightning> (the README in meta-ti I mean)
Sep 07 11:12:07 <FunkyPenguin> bluelightning: ive got everything mentioned in the README
Sep 07 11:12:17 <bluelightning> FunkyPenguin: BBMASK ?
Sep 07 11:12:45 <FunkyPenguin> bluelightning: im using meta-openembedded too
Sep 07 11:12:56 <FunkyPenguin> so my understanding is that isnt needed
Sep 07 11:13:29 <bluelightning> ok, I've just checked
Sep 07 11:13:34 <bluelightning> the readme is wrong unfortunately
Sep 07 11:13:44 <FunkyPenguin> oh?
Sep 07 11:13:46 <bluelightning> those recipes must be masked if you are not using angstrom
Sep 07 11:13:53 <bluelightning> what a mess :/
Sep 07 11:14:39 <FunkyPenguin> so just add "BBMASK = meta-ti/recipes-misc" ?
Sep 07 11:15:24 <bluelightning> yes
Sep 07 11:17:07 <FunkyPenguin> most kind squire!
Sep 07 11:21:58 <gotan> hi, I'm having trouble finding any documentation on installing a generated image on a target from a USB stick. Its probably blindingly obvious, but i'm missing it. so thought to ask here....
Sep 07 11:28:53 <bluelightning> gotan: which machine?
Sep 07 11:29:01 <gotan> x86
Sep 07 11:29:11 <bluelightning> gotan: have a look in README.hardware
Sep 07 11:29:15 <gotan> atomish
Sep 07 11:29:33 <bluelightning> ah right, that is definitely covered
Sep 07 11:32:01 <rburton> oh hi FunkyPenguin
Sep 07 11:32:26 <FunkyPenguin> cooey rburton
Sep 07 11:32:46 <rburton> gotan: its either really easy (dd the hddimg), or oh my god hard, depending on your bios
Sep 07 11:39:42 <gotan> I think i'm in the omghard because i have no trouble making the usb usbimage,
Sep 07 11:43:05 <gotan> i'm having have trouble installing the usb image onto the target.
Sep 07 11:46:23 <gotan> @rburtonwhat bios issues have you come across
Sep 07 11:46:28 <gotan> @rburton what bios issues have you come across
Sep 07 11:47:00 <rburton> gotan: bios refusing to boot a hddimg on a usb stick, mainly
Sep 07 11:47:35 <rburton> that's that the usb-zip stuff in the readme is all about
Sep 07 11:50:16 <gotan> ok, then i think i have a misconfig, because the usb is booting, but not bringing up a prompt.
Sep 07 11:50:33 <gotan> @rburton ok, then i think i have a misconfig, because the usb is booting, but not bringing up a prompt.
Sep 07 11:54:53 <gotan> @rburton initrd is picked up, all local resources are found, but getting " EXT3-fs (nbd8): error: unable to read superblock  block nbd15: Attempted send on closed socket  end_request: I/O error, dev nbd15, sector 16"
Sep 07 11:55:29 <gotan> etc errors for the various compiled in filesystems
Sep 07 11:55:36 <rburton> how strange
Sep 07 11:55:40 <rburton> its booting, so it should be working
Sep 07 11:57:47 <gotan> @rburton yeh, this has been bugging me for a bit now. my best guess a the moment is that its something to do with the hddimg being generated not having apropriate parition information or something.
Sep 07 11:58:47 <gotan> ore just as likley some boneheaded kernel option i missed.
Sep 07 14:53:09 <FunkyPenguin> rburton: are you free for a brief chat
Sep 07 14:53:22 <FunkyPenguin> rburton: i'd rather pop round if poss?
Sep 07 15:21:09 <RP> FunkyPenguin: That is a somewhat alien concept on a distributed project like this :)
Sep 07 15:26:25 <FunkyPenguin> RP: true but im physically about <500m from where he is :)
Sep 07 15:27:59 <RP> FunkyPenguin: I guessed as much, I just find the concept quite alien. It would be nice to have vistors here but as a friend put it, this part of the world is marked as "there be dragons" on most people's mental maps
Sep 07 15:28:17 <RP> FunkyPenguin: (near Newcastle upon Tyne FWIW)
Sep 07 15:28:45 <sgw> RP: those are the best places to visit, dragons can be fun ;-)
Sep 07 15:29:28 <RP> sgw: I like it ;-)
Sep 07 15:30:52 <FunkyPenguin> RP: i just looked at my map and there's a massive chunk missing where you would be, clearly eaten by a dragon :)
Sep 07 15:32:00 <RP> FunkyPenguin: The reputation keeps the foreigners out and the place less crowded ;-)
Sep 07 15:46:09 <FunkyPenguin> rburton: never mind, need to head off now
Sep 07 16:41:36 <rburton> FunkyPenguin: sorry, was away. i'll be in tomorrow if you want to chat.
Sep 07 16:49:17 <xxiao> a basic question, is there a list for all x86 chips supported by yocto
Sep 07 16:49:29 <xxiao> is it atom only, or i7 will be running fine with yocto too?
Sep 07 16:49:45 * xxiao is ignorant on x86 other than the desktop
Sep 07 16:53:34 <RP> fray: FWIW I know libtool has issues with the distclean :(
Sep 07 16:53:55 <RP> xxiao: jasperforest is xeon iirc for example
Sep 07 16:54:10 <RP> xxiao: i7 is fine
Sep 07 16:56:11 <xxiao> RP: someone wants to deploy yocto to their production servers and i feel a bit nervous about that
Sep 07 16:56:31 <xxiao> feel it's less tested in the field, comparing to debian for example, when resource is not a major concern
Sep 07 16:57:05 <RP> xxiao: It is true its had less exposure than debian...
Sep 07 16:57:36 <xxiao> i know people running openwrt on real servers, but this is the first time i know someone wants to run yocto for the same reason
Sep 07 16:58:02 <RP> xxiao: we do at least try and keep an eye on CVEs and generally keep the system secure
Sep 07 16:58:07 <Crofton|work> only one way to get the exposure, just do it
Sep 07 16:58:07 <xxiao> they could not use centos because their devices are x86/ppc even some arms, so need something cross-architecture
Sep 07 16:58:49 <RP> I don't see any reason it shouldn't be used in that environment FWIW
Sep 07 16:59:14 <RP> If there are any issues, we do have people who'd respond to issues quickly
Sep 07 16:59:19 <xxiao> like you said, then you will need security updates for releases such as 5.0/6.0/7.0 for a long while
Sep 07 17:01:31 <RP> xxiao: With things like Wind River 5.0 based off the Yocto Project, I'd expect this to be an improving situation
Sep 07 17:02:42 <xxiao> i don't think those guys want to subscribe to winddriver's 'commercial' releases :)
Sep 07 17:04:19 <RP> xxiao: WR collaborate around the project, not keep everything to themselves
Sep 07 17:04:46 <RP> There is a strong pressure to create a good core which includes ensuring its secure
Sep 07 17:05:01 <xxiao> that sounds great
Sep 07 17:05:31 <xxiao> security is too important when you're done with toying and start to think about deploying
Sep 07 17:06:48 <RP> xxiao: agreed and we know this as a project
Sep 07 17:13:34 <Crofton|work> anyone trying to make money of the yocto project should know not to sit on security stuff
Sep 07 17:14:11 <Crofton|work> tainting the primary brand name damages derived works, even if the derived work claims to have better security
Sep 07 18:18:20 <FalCone> Uh.
Sep 07 18:18:34 <FalCone> Yeah, I start my questions with that more often than I'd like.
Sep 07 18:19:22 <FalCone> How can I target my builds for specific machines that aren't explicitly listed in the local.conf comments?
Sep 07 18:20:15 <FalCone> Like, I want to run a build on MPC8544 instead of the MPC8315 listed in the comments
Sep 07 18:20:21 <FalCone> or the qemuppc for the emulator
Sep 07 18:25:16 <sgw> FalCone: for machines that are part of the Yocto Project, you can set MACHINE="qemuppc" (for example), if you want to build for a MPC8544, you will need to create a meta/conf/machine/mpc8544.conf file that matches the requirements of that hardware, you can look at the meta-yocto{-bsp}/conf/machine/mpc8315.conf for example.  Basicly you need to create a BSP layer for that machine.
Sep 07 18:25:36 <sgw> FalCone: then you can set MACHINE="mpc8544" and rebuild
Sep 07 18:25:43 <FalCone> Ah.
Sep 07 18:25:58 <sgw> Good a Uh -> Ah that's a good sign?
Sep 07 18:26:34 <FalCone> Well
Sep 07 18:26:39 <FalCone> it's a nudge in the right direction
Sep 07 18:26:42 <FalCone> I have no idea what I'm doing :V
Sep 07 18:26:51 <FalCone> So knowing what to look at certainly helps.
Sep 07 18:27:43 <sgw> FalCone: refer to the Yocto Project web site and wiki for details on creating a BSP layer, you can start off with meta-yocto, but should really create your own layer.
Sep 07 18:28:11 <FalCone> Yeah, I was just about to do that.
Sep 07 19:41:24 <evanp> Conceptually, what is the difference between ordinary recipes, a task-*.bb, and a meta-*.bb? What's the reasoning behind those names?
Sep 07 21:03:06 <khem> evanp: meta and task recipes are same in essense
Sep 07 21:03:14 <khem> they are higher order recipes
Sep 07 21:05:51 <evanp> khem: I found some doc text saying tasks are just bundles of other recipes, which makes sense. But what makes a meta-*.bb package different from a task-*.bb one?
Sep 07 21:06:20 <evanp> khem: I get that they're not _really_ that different as far as bitbake is concerned
Sep 07 21:06:46 <evanp> khem: I'm just hoping for some insight into why the humans around Yocto call some stuff one thing and other stuff something else
Sep 07 21:09:28 <evanp> maybe there's no real reason--maybe it's just like how the plural of "house" is "houses", not "hice" ;-)
Sep 07 21:20:10 <sgw> khem: Are you going to resend your gcc patches with Upstream-Status, please!
Sep 07 22:06:08 <khem> sgw: ok I will update
Sep 07 22:06:19 <khem> sgw: I thought I had that in
Sep 07 22:06:28 <khem> which patch in particular is missing it
Sep 07 22:06:43 <khem> evanp: well think of them as meta recipes
Sep 07 22:15:58 <sgw> Khem Raj - meta/recipes-devtools/gcc/gcc-4.7/gcc-armv4-pass-fix-v4bx-to-ld.patch
Sep 07 22:15:58 <sgw> Khem Raj - meta/recipes-devtools/gcc/gcc-4.7/ppc_no_crtsavres.patch
Sep 07 22:21:28 <khem> sgw: figured
Sep 07 22:46:34 <khem> sgw: I will test the update since the effect of ppc patch is achieved also in an upstream patch which I am testing instead of this one
Sep 07 22:46:47 <khem> I will let you know when I push the updates to branch
Sep 07 22:50:57 <sgw> khem: Ok I will hold off on the gcc updates then.
Sep 07 23:50:41 <sgw> khem, did you see my patch for openssh, when phil mentoind that, I dug and found the existing code in image just need another tweak to the config to make it work.
Sep 07 23:56:50 <xxiao> trying to complie meta-java and it failed on not finding gmp-i386.h
Sep 07 23:56:53 <xxiao> http://pastebin.com/D77WJywz
Sep 07 23:58:48 <xxiao> there is no such file as gmp-i386.h under tmp-eglibc or in my host /usr/include(ubuntu x64)
Sep 08 00:21:12 <xxiao> fixed
Sep 08 00:21:34 <xxiao> classpath recipe is missing a gmp patch
**** ENDING LOGGING AT Sat Sep 08 02:59:58 2012

**** BEGIN LOGGING AT Sat Sep 08 02:59:58 2012
Sep 08 17:29:01 <fray> anyone around that knows how to configure teh buildhistory stuff?
Sep 08 17:29:08 <fray> I can't find my notes and I'm not sure I've done it right
Sep 08 17:42:24 <bluelightning> fray: yep
Sep 08 17:42:34 <bluelightning> fray: https://wiki.yoctoproject.org/wiki/Buildhistory
Sep 08 17:43:09 <fray> thanks!  thats what I was looking for..
Sep 08 17:43:38 <fray> we think we found a python/multilib problem.. I've got a fix by one of our developers.. but I need to use buildhistory to see if 1) it really is the right fix..
Sep 08 17:43:44 <fray> 2) the problem is 'real'
**** ENDING LOGGING AT Sun Sep 09 02:59:58 2012

**** BEGIN LOGGING AT Sun Sep 09 02:59:59 2012
Sep 09 12:07:46 <gotan> hi, having trouble getting preferred provider virtual/kernel to be picked up by my build. Very annoying, and no idea at this time why not, or how to track it down.
Sep 09 12:09:54 <bluelightning> gotan: what do you get if you run: bitbake -e | grep PREFERRED_PROVIDER_virtual/kernel
Sep 09 12:12:27 <gotan> Thats the annoying part: # PREFERRED_PROVIDER_virtual/kernel=linux-yocto PREFERRED_PROVIDER_virtual/kernel="linux-yocto"
Sep 09 12:15:24 <bluelightning> gotan: right, it's almost certain that the distro config is setting that
Sep 09 12:15:39 <bluelightning> git grep "PREFERRED_PROVIDER_virtual/kernel"
Sep 09 12:19:41 <gotan> I think i've figured it out, checking now. It was a wood for the trees, i did not check that the compatible machine was set properly in the distro. I'm guessing you have to explicily set that in .confi files or something? because it does not seem to be a requirement for .bb files.
Sep 09 12:20:25 <bluelightning> gotan: no, COMPATIBLE_MACHINE is a recipe-level variable
Sep 09 12:21:09 <bluelightning> If you're working on a BSP you may wish to refer to the BSP guide if you aren't already
Sep 09 12:21:52 <gotan> I added COMPATIBLE_MACHINE = "(${MACHINE})" to my distro conf, and its now picking up the preferred provider for the kernel.
Sep 09 12:22:10 <gotan> at least thats what bitbake -e is telling me.
Sep 09 12:22:32 <bluelightning> that's not a good idea, because you will be overriding COMPATIBLE_MACHINE of other recipes which won't always be appropriate
Sep 09 12:23:02 <bluelightning> you need to use a bbappend for the kernel recipe in your BSP layer
Sep 09 12:24:21 <bluelightning> well, actually that won't override it if it is set by the recipe, however it will be setting it globally which is still not correct
Sep 09 12:33:33 <gotan> I'm making a distro, with a core kernel recipie and kernel config specific bbappends based on machine target. my problem seems to be that the initial virtual kernel set in the distro is being ignored or overwritten somewhere. I can see how i can use -e to dump the default environment for the distro, but is it possible  to see where an variable is set via logging?
Sep 09 12:34:34 <gotan> an variable in this case (pardon my typo) is the PREFERRED_PROVIDER_virtual/kernel which is only set in the distro.conf
Sep 09 12:37:39 <bluelightning> gotan: there is no built-in tracing no, but you can almost always find the culprit using "git grep" in the layers you are yisng
Sep 09 12:37:52 <bluelightning> s/yisng/using/
Sep 09 12:45:38 <gotan> I've been using straight grep, but I think I'm on top of it now.
Sep 09 12:45:39 <gotan> I understand that the global namespace is like a palimpsest of layered configuration files, but I don't yet get how that layering happens.
Sep 09 12:46:48 <gotan> Do the different extensions confer any difference to the outcome (other than bbclass and bbappend)? .conf and .inc and .bb seem almost interchangeable.
Sep 09 13:41:12 <bluelightning> gotan: they aren't interchangeable no
Sep 09 13:42:15 <bluelightning> gotan: bitbake first looks for conf/bblayers.conf to read where to find recipes (.bb/.bbappend) then conf/bitbake.conf, and then the default version of the latter tells it where else to look
Sep 09 15:11:09 <gotan> any idea why "bitbake -e distro-core-image" has correct  preferred virtual/kernel, but "bitbake -D -nv distro-image-core" picks up linux-dummy? with: DEBUG: providers for virtual/kernel are: ['linux-dummy'], could it have something to do with layer priorities?
Sep 09 19:36:34 <pidge> autobuilder going down for upgrades. be back in a few hours
**** ENDING LOGGING AT Mon Sep 10 02:59:58 2012

**** BEGIN LOGGING AT Mon Sep 10 02:59:59 2012
Sep 10 08:06:00 <bluelightning> morning all
Sep 10 08:07:58 <JaMa> morning
Sep 10 08:09:05 <JaMa> bluelightning: IIRC you said that you've also noticed qemu-native not building when host doesn't have libX11, right?
Sep 10 08:09:16 <bluelightning> hi JaMa
Sep 10 08:09:20 <bluelightning> JaMa: yes I have
Sep 10 08:11:24 <JaMa> and are you using -diet or -trim version of libx11?
Sep 10 08:12:06 <JaMa> because only normal libx11 provides -native version, so virtual/libx11-native wont probably work for other setups but libx11-native should
Sep 10 08:16:54 <bluelightning> JaMa: do we really want to build libx11 native if the machine doesn't have it installed?
Sep 10 08:17:28 <bluelightning> JaMa: seems to me since this is a native recipe it could just autodetect whether libx11 is available and disable linking against it if not
Sep 10 08:18:22 <JaMa> and how do you share such recipe with sstate-cache then?
Sep 10 08:18:40 <JaMa> when both hosts have same LSB name, but one has and one has not libx11 installed?
Sep 10 08:18:59 <bluelightning> JaMa: hmm true
Sep 10 08:19:55 <JaMa> I would say, disable it for both.. but I guess it's something yocto wants for runqemu* scripts or something
Sep 10 08:20:31 <JaMa> for me I don't want to build qemu-native at all :)
Sep 10 08:20:36 <bluelightning> JaMa: well if you want to display the output of a running VM on a local machine (or a remote one) that is needed
Sep 10 08:21:09 <JaMa> because builder just produces image for someone to download them and run them on his own qemu (on machine maybe without OE completely)
Sep 10 08:21:48 <bluelightning> JaMa: you should be able to just set EXTRA_IMAGEDEPENDS_forcevariable = "" in that case
Sep 10 08:22:18 <bluelightning> it could be that we should split that out into a separate variable to allow safer disabling though
Sep 10 08:23:49 <JaMa> bluelightning: yes I'm using https://github.com/shr-distribution/oe-core/commit/ac00fa6e5c5cd4252440ba6d072c87db36576065 https://github.com/shr-distribution/oe-core/commit/f3b652322db9681758c6ec493ab351ed9a2b319a
Sep 10 08:24:14 <JaMa> and would be great to provide some variable to say if builder is also running qemu for tests or not
Sep 10 08:29:18 <bluelightning> JaMa: well we do have IMAGETEST but I guess that's not what you're referring to
Sep 10 08:37:38 <JaMa> bluelightning: IMAGETEST could be used to apply that EXTRA_IMAGEDEPENDS in qemu.inc only when it's set I guess
Sep 10 08:38:28 <JaMa> if it works for your use-cases then I can drop my patch and set IMAGETEST to empty for my images
Sep 10 08:39:22 <JaMa> machine specific netbase cannot be solved by this.. it would need some distro switch for that :/
Sep 10 08:40:05 <bluelightning> JaMa: that does not handle the single user who is just getting started and wants to run their final image under qemu
Sep 10 08:40:43 <bluelightning> JaMa: I think it ought to be a variable you can just clear if you prefer not to build it
Sep 10 08:42:02 <JaMa> cannot runqemu* script check that qemu (from host or from qemu-native) is available or not and build that for such user?
Sep 10 08:42:49 <JaMa> but either way, extra variable would help
Sep 10 08:45:12 <bluelightning> I understand we have good reasons for not using host qemu; but I'm not sure if those are still true given that we've dropped our GL patches
Sep 10 08:46:36 <JaMa> but the problem with libx11-native still stands :/
Sep 10 08:47:39 <bluelightning> I think we need two solutions to that - 1) allow disabling X11 support for those who still want to use serial; 2) allow disabling the EXTRA_IMAGEDEPENDS completely for those that don't want qemu-native to be built at all
Sep 10 08:47:59 <bluelightning> JaMa: re the netbase thing, seems that could be done in a postprocessing function within do_rootfs
Sep 10 08:48:00 <JaMa> I'm using qemu-native for emacs build, but something builds libx11-native because emacs and qemu-native build usually
Sep 10 08:48:28 <bluelightning> JaMa: can you find out what that "something" is?
Sep 10 08:49:18 <JaMa> my first guess was dbus-native but that has libx11-native disabled, mmt
Sep 10 08:50:02 <bluelightning> bitbake -g will be able to tell you definitively
Sep 10 08:50:12 <JaMa> it could be cairo-native
Sep 10 08:50:54 <JaMa> ah.. my usually I mean, that emacs is build only as part of task-shr-feed, so I'm not sure if it's in emacs dependency tree, but almost everything is built already when it's building emacs
Sep 10 08:51:22 <JaMa> so something completly unrelated could have built libx11-native before emacs (that's why I don't see this error in normal setup)
Sep 10 08:51:29 <JaMa> but I'll check -g too
Sep 10 09:32:19 <Ramana_> hhh.
Sep 10 11:33:34 <gotan> Hi, having a problem with the initrd for init-live.sh. It seems that it locks up if udev does not mount anything in /media. I'm guessing this should just work. I've gone through the udev kernel parameter checklist, and udevd is up, and the kernel is recognising the device when i plug it in and unplug it.
Sep 10 14:14:56 <_jacob> Hello all!
Sep 10 14:15:22 <bluelightning> hi _jacob
Sep 10 14:15:28 <_jacob> How are you bluelightning ?
Sep 10 14:15:39 <bluelightning> _jacob: great and you?
Sep 10 14:16:02 <_jacob> Oh, I'm really fine! How long time, no?
Sep 10 14:18:30 <_jacob> Actually, I'm having some problems with Yocto meta-toolchain...
Sep 10 14:18:47 <bluelightning> _jacob: ah ok, what's the issue?
Sep 10 14:19:08 <_jacob> Some time ago I started a development of some recipes to build my custom linux with my applications and libs...
Sep 10 14:20:20 <_jacob> So, the final way to finish this task is build the toolchain to other team develop/debug our application...
Sep 10 14:21:48 <_jacob> With my custom OS and recipes, using bitbake meta-toolchain, some problems occurs on final steps... Actually, in do_populate_sdk task...
Sep 10 14:22:32 <_jacob> So, I try using the default poky distro... And again, the same error in do_populate_sdk task...
Sep 10 14:23:02 <_jacob> That is: poky-denzil-7.0.1/build/tmp/work/armv5te-poky-linux-gnueabi/meta-toolchain-1.0-r7/sdk/image//opt/poky/1.2.1/sysroots/armv5te-poky-linux-gnueabi/etc: Cannot open: No such file or directory
Sep 10 14:23:35 <bluelightning> _jacob: can you pastebin the full error output?
Sep 10 14:23:52 <_jacob> Ok...
Sep 10 14:24:04 <_jacob> NOTE: package meta-toolchain-1.0-r7: task do_populate_sdk: Started
Sep 10 14:24:05 <_jacob> ERROR: Function failed: do_populate_sdk (see /home/hugo/work/Yocto/poky-denzil-7.0.1/build/tmp/work/armv5te-poky-linux-gnueabi/meta-toolchain-1.0-r7/temp/log.do_populate_sdk.1746 for further information)
Sep 10 14:24:05 <_jacob> ERROR: Logfile of failure stored in: /home/hugo/work/Yocto/poky-denzil-7.0.1/build/tmp/work/armv5te-poky-linux-gnueabi/meta-toolchain-1.0-r7/temp/log.do_populate_sdk.1746
Sep 10 14:24:05 <_jacob> Log data follows:
Sep 10 14:24:05 <_jacob> | ERROR: Function failed: do_populate_sdk (see /home/hugo/work/Yocto/poky-denzil-7.0.1/build/tmp/work/armv5te-poky-linux-gnueabi/meta-toolchain-1.0-r7/temp/log.do_populate_sdk.1746 for further information)
Sep 10 14:24:08 <_jacob> | dpkg-scanpackages: info: Wrote 7 entries to output Packages file.
Sep 10 14:24:10 <_jacob> | dpkg-scanpackages: info: Wrote 2838 entries to output Packages file.
Sep 10 14:24:13 <_jacob> | dpkg-scanpackages: info: Wrote 260 entries to output Packages file.
Sep 10 14:24:15 <_jacob> | dpkg-scanpackages: info: Wrote 7 entries to output Packages file.
Sep 10 14:24:16 <_jacob> | dpkg-scanpackages: info: Wrote 594 entries to output Packages file.
Sep 10 14:24:18 <_jacob> | Installing TARGET packages
Sep 10 14:24:20 <_jacob> | Ign file: ./ Release.gpg
Sep 10 14:24:21 <bluelightning> _jacob: pastebin as in pastebin.com
Sep 10 14:24:22 <_jacob> | Ign file: ./ Release.gpg
Sep 10 14:24:24 <_jacob> | Ign file: ./ Release.gpg
Sep 10 14:24:26 <_jacob> | Get:1 file: ./ Release [15B]
Sep 10 14:24:28 <_jacob> | Ign file: ./ Packages
Sep 10 14:24:30 <_jacob> | Get:2 file: ./ Release [15B]
Sep 10 14:24:33 <_jacob> | Get:3 file: ./ Release [11B]
Sep 10 14:24:36 <_jacob> | Ign file: ./ Packages
Sep 10 14:24:39 <_jacob> | Ign file: ./ Packages
Sep 10 14:24:40 <_jacob> | Reading package lists...
Sep 10 14:24:42 <_jacob> | W: Ignoring Provides line with DepCompareOp for package rtld
Sep 10 14:24:44 <_jacob> | W: You may want to run apt-get update to correct these problems
Sep 10 14:24:46 <_jacob> | tar: /home/hugo/work/Yocto/poky-denzil-7.0.1/build/tmp/work/armv5te-poky-linux-gnueabi/meta-toolchain-1.0-r7/sdk/image//opt/poky/1.2.1/sysroots/armv5te-poky-linux-gnueabi/etc: Cannot open: No such file or directory
Sep 10 14:24:49 <_jacob> | tar: Error is not recoverable: exiting now
Sep 10 14:24:51 <_jacob> NOTE: package meta-toolchain-1.0-r7: task do_populate_sdk: Failed
Sep 10 14:24:53 <_jacob> ERROR: Task 8 (/home/hugo/work/Yocto/poky-denzil-7.0.1/meta/recipes-core/meta/meta-toolchain.bb, do_populate_sdk) failed with exit code '1'
Sep 10 14:24:56 <_jacob> NOTE: Tasks Summary: Attempted 1901 tasks of which 922 didn't need to be rerun and 1 failed.
Sep 10 14:24:58 <_jacob> Summary: 1 task failed:
Sep 10 14:25:00 <_jacob>   /home/hugo/work/
Sep 10 14:25:02 <_jacob> Ok!
Sep 10 14:25:09 <_jacob> Sorry! The link is http://pastebin.com/n9SC0acH
Sep 10 14:28:14 <_jacob> I need to remember, I did some tests with the default poky distro and the every occurs the same error...
Sep 10 14:29:25 <_jacob> This report is specifically with MACHINE ?= "qemuarm" and PACKAGE_CLASSES ?= "package_deb" in default local.conf
Sep 10 14:31:54 <bluelightning> _jacob: hmm... I'm not sure to be honest, there aren't any obvious clues in the error output
Sep 10 14:32:24 <bluelightning> _jacob: presumably the etc subdir does not exist?
Sep 10 14:32:40 <_jacob> Yes! Me too. And the log file don't help in anything...
Sep 10 14:33:00 <_jacob> Again yes, the etc subdir not exist...
Sep 10 14:33:14 <_jacob> At the same level, only var subdir exist...
Sep 10 14:50:33 <_jacob> bluelightning, I will try using ipk packages, not deb...
Sep 10 14:57:10 <_jacob> bluelightning, using ipk packages, the default poky setup works...
Sep 10 14:57:24 <_jacob> I will try with my custom distro and recipes
Sep 10 15:53:36 <RP> msm: You know that you need to remove the xorg-lite references for your layer?
Sep 10 15:54:33 <msm> RP: hmm, ok
Sep 10 15:54:58 <msm> RP: we moved to what?
Sep 10 15:55:28 <RP> msm: http://autobuilder.yoctoproject.org:8010/builders/p1022ds/builds/35/steps/shell_32/logs/stdio - change to xserver-xorg iirc
Sep 10 15:55:38 <RP> msm: basically the -lite version didn't offer much benefit
Sep 10 15:55:44 <msm> RP: i rarely if ever test gfx
Sep 10 15:56:14 <RP> msm: Just do the s/xserver-xorg-lite/xserver-xorg/ then...
Sep 10 15:56:23 <RP> rburton: I have the right name?
Sep 10 15:56:50 <rburton> yes
Sep 10 15:57:27 <rburton> msm: so the difference was that -lite didn't compile glx. if you really don't want GL, you can unset (or not set) the "opengl" distro feature.
Sep 10 15:59:15 <msm> rburton: ok, thanks
Sep 10 16:00:04 <rburton> msm: if you do want glx but can't be bothered with distro features, mesa will get built but you don't need to ship the xorg modules (the meta-yocto beagleboard machine doesn't)
Sep 10 16:01:15 <msm> rburton: RP: i'll push a fixfor the build.. i won't be able to verify other issues for a while (if they exist)
Sep 10 16:01:29 <awafaa> if i build an image for the pandaboard with meta-ti, is the resulting image just a matter of extracting the tarball and dd'ing to an sd card?
Sep 10 16:01:44 <RP> msm: That should be ok, the next autobuild will at least test the build process
Sep 10 16:02:45 <msm> RP: why didn't i see this on the yocto-builds list?
Sep 10 16:02:49 <RP> awafaa: it depends what the pandaboard expects on boot. We usually recommend people put something in the README files about deployment
Sep 10 16:03:01 <RP> msm: MUT build, its not been built against master since the change
Sep 10 16:03:07 <JaMa> rburton: please look at libx11-trim and libx11-diet when you have time
Sep 10 16:03:10 <RP> msm: It would fail with master too
Sep 10 16:03:22 <RP> msm: So we're just ahead of the game :)
Sep 10 16:03:31 <rburton> JaMa: eh, what, -trim *and* -diet?
Sep 10 16:03:32 <JaMa> rburton: one of them is completely the same of libx11 now (after xcb became mandatory)
Sep 10 16:03:37 <rburton> ha
Sep 10 16:03:45 <msm> MUT = master under test? aka master-next?
Sep 10 16:03:59 <RP> msm: master under test
Sep 10 16:03:59 <JaMa> rburton: and I've proposed to remove them twice already, but you have better possition for such changes it seems :)
Sep 10 16:04:19 <RP> msm: master-next is similar but different. sgw owns MUT, I own master-next
Sep 10 16:04:42 <RP> JaMa: I said I'd take patches making diet a PACKAGECONFIG option
Sep 10 16:04:59 <msm> RP: is it a branch somewhere?
Sep 10 16:05:04 <awafaa> RP: looks like there isn't anything about deploying the image, just the git repos and BBMASK
Sep 10 16:05:05 <RP> JaMa: afaik, nobody actually sent me a patch or I'd have applied it
Sep 10 16:05:17 <msm> RP:  i see sgw branch on poky-contrib
Sep 10 16:05:43 <RP> awafaa: I'd point that out on the meta-ti list as its annoying and I already have a reputation for complaining about things like this ;-)
Sep 10 16:05:58 <RP> msm: yes, stage/master_under_test iirc
Sep 10 16:06:44 <JaMa> rburton: also with -diet and -trim gone, this should be fixed properly too http://lists.linuxtogo.org/pipermail/openembedded-core/2012-July/025711.html
Sep 10 16:07:03 <awafaa> RP: complain? surely not :)
Sep 10 16:07:34 <awafaa> looking closely at the resulting files looks like it's a manual job to get it on the card - much faffing required :/
Sep 10 16:08:25 <JaMa> RP: I'm not using them, so I would expect Laurentiu Palcu or Xiaofeng Yan to remove at least one of them after http://lists.linuxtogo.org/pipermail/openembedded-core/2011-November/012755.html
Sep 10 16:09:06 <RP> awafaa: FWIW, in order to be "Yocto Project Compatible", a decent README is a requirement. Sounds simple, its amazing how many people don't put it in
Sep 10 16:09:59 <RP> JaMa: Its on rburton's hit list
Sep 10 16:10:45 <rburton> awafaa: fwiw, the raspberrypi bsp generates a sdcard image, you can just dd.  might be worth harassing meta-ti to make that an option.
Sep 10 16:11:04 <awafaa> RP: documentation is boring!
Sep 10 16:11:09 <rburton> awafaa: with beagle its only the initial setup that's a faff, after that you can generally just wipe and re-extract the rootfs
Sep 10 16:11:13 <RP> awafaa: We could do with better utils for this kind of thing too like a helper script like the one rburton mentions
Sep 10 16:11:33 <awafaa> rburton: yeah, i might do that :)
Sep 10 16:11:43 <RP> awafaa: I know its on several people's todo lists...
Sep 10 16:12:06 <rburton> yeah there's been a big discussion about all-new imaging tools
Sep 10 16:12:11 <awafaa> RP: the question is how far down their lists is ;)
Sep 10 16:12:22 <rburton> writing a sd card for beagle is pain, writing usb sticks for PCs can be serious pain
Sep 10 16:12:41 <awafaa> what about integrating it with OBS and have that handle the image building for deployment?
Sep 10 16:12:50 * awafaa runs and hides :)
Sep 10 16:12:54 <rburton> awafaa: sounds a lot like overkill to me
Sep 10 16:13:20 <rburton> awafaa: as i said, rpi generates a sd image for you. its just that meta-ti doesn't jump through that hoop
Sep 10 16:13:40 <rburton> (complicated by the obvious tools to generate a sd image need root perms)
Sep 10 16:14:12 <awafaa> rburton: true it probably is. i'll see if i can wedge that up my list then
Sep 10 16:15:19 <rburton> awafaa: sdcard-image-rpi looks simple to amend into something panda/beagle friendly
Sep 10 16:16:32 <RP> It should become an image type
Sep 10 16:16:45 <RP> if we can find a way to do it without root
Sep 10 16:17:08 * RP ponders qemu in that mix
Sep 10 16:18:18 <rburton> looks like this does - uses parted to create a partition in a image, and mtools to drop in the boot loader, and dd's the rootfs into the image
Sep 10 16:25:16 <rburton> RP: -lite removal isn't actually on master yet
Sep 10 16:25:40 <rburton> oh, its probably in oe-core but not poky
Sep 10 16:25:53 <JaMa> I see it removed in oe-core
Sep 10 16:26:16 <RP> rburton: Four hours ago: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=887a731468374c4b972ac21b488d567eadfa7609
Sep 10 16:27:02 <rburton> gnrnr
Sep 10 16:27:04 * rburton kicks git
Sep 10 16:57:39 <ag_> rburton: Hello.
Sep 10 16:57:45 <rburton> ag_: hi
Sep 10 16:57:57 <rburton> ag_: disappearing in a few minutes :)
Sep 10 16:58:09 <ag_> I will be fast
Sep 10 16:58:55 <ag_> rburton: How awful would you think a DISTRO FEATURE CONSIDERED existence in a machine conf would be?
Sep 10 16:59:44 <rburton> ag_: i suspect that upsets the layering, but i'd defer to RP and other more experience on that
Sep 10 17:00:13 <ag_> rburton: Ok.
Sep 10 17:00:26 <ag_> rburton: Thank you.
Sep 10 17:00:32 <bluelightning> ag_: do not do that ;)
Sep 10 17:00:43 <ag_> :)
Sep 10 17:00:56 <ag_> I want to get rid of opengl with a backfill variable.
Sep 10 17:01:09 <ag_> The way pulseaudio and rtc is used right now.
Sep 10 17:01:56 <ag_> Until we will figure out a better solution (machine features_ for gl /gles as discussed on mailing list
Sep 10 17:04:10 <bluelightning> you should not touch distro configuration from the machine configuration, that's pretty much all there is to it
Sep 10 17:04:34 <bluelightning> I would suggest waiting for the proper fix, it shouldn't be too far away
Sep 10 17:04:46 <ag_> bluelightning: I know this.
Sep 10 17:05:17 <ag_> Ok then. I will synk with rburton . I think he started some stuff on this issues.
Sep 10 17:05:20 <ag_> issue*
Sep 10 17:05:44 <rburton> oh the pressure!
Sep 10 17:05:51 <ag_> I just wanted to know if a temporary hack like this would be tolerated. :p
Sep 10 17:06:12 <ag_> rburton: Don't shoot the messenger. :p
Sep 10 17:06:52 <ag_> rburton: I have to finish some stuff now. After that, if you didn't already submit stuff i will work on this.
Sep 10 17:21:42 <rburton> JaMa: first run of libx11 patches send, proper rationalisation tomorrow
Sep 10 17:23:45 <ag_> sgw: Do you have one minute?
Sep 10 17:28:50 <JaMa> rburton: looks good sofar, thanks!
Sep 10 17:28:56 <sgw> ag_: sure what's up?
Sep 10 17:31:40 <ag_> sgw: i'm a little confused with: 4de7aafbed1d3d6885b188f3bc61d6da5b0659a4
Sep 10 17:33:06 <ag_> SO if base_size is greater than IMAGE_ROOTFS_SIZE we don't take into consideration IMAGE_ROOTFS_EXTRA_SPACE?
Sep 10 17:33:34 <ag_> Only the IMAGE_OVERHEAD_FACTOR?
Sep 10 17:34:57 <sgw> ag_: reviewing
Sep 10 17:38:20 <sgw> ag_: look at where the parens are, I believe is should add EXTRA_SPACE in both cases, so use base_size if it's bigger and then add EXTRA_SPACE
Sep 10 17:39:50 <ag_> sgw: Indeed.
Sep 10 17:40:16 <ag_> sgw: Didn't see that sorry.
Sep 10 17:40:20 <sgw> ag_: is something now working right?
Sep 10 17:40:35 <ag_> there is a porblem
Sep 10 17:40:47 <ag_> but i already foxed it
Sep 10 17:40:52 <ag_> and i will submit patches.
Sep 10 17:41:19 <ag_> sgw: The idea is that we cont on the fact that IMAGE_ROOTFS_EXTRA_SPACE is aligned.
Sep 10 17:41:22 <ag_> count*
Sep 10 17:42:25 <ag_> And IMAGE_ROOTFS_SIZE too.
Sep 10 17:42:36 <ag_> So what i did was to move the alignment code after the ROOTFS_SIZE calculus.
Sep 10 17:43:18 <ag_> sgw: Makes sense?
Sep 10 17:43:42 <sgw> ag_: yup it does.
Sep 10 17:44:15 <ag_> sgw: One more thing. I would like to see ROOTFS_SIZE exported. Is an useful variable for partitioning classes and so on.
Sep 10 17:45:08 <ag_> sgw: Do you think of a problem in exporting this variable? Why shoudn't it be exported?
Sep 10 17:53:54 <sgw> ag_: where would you use it, it after the rootfs is created and compressed?
Sep 10 17:55:11 <ag_> Yes.
Sep 10 17:55:23 <ag_> In a SD image card creation.
Sep 10 17:55:54 <ag_> sgw: https://github.com/agherzan/meta-raspberrypi/commit/204f9a223e7ba542574773b1f61d4d7cfe3b20bd
Sep 10 17:55:58 <sgw> ag_: would that be part of an image command or compressed image command?
Sep 10 17:56:11 <ag_> sgw: Image
Sep 10 17:56:31 <sgw> core image-minimal is 60M!  That sounds big
Sep 10 17:57:17 <ag_> sgw: Forget that. I will amend. I was talking about an image mased on core-image-minimal.
Sep 10 17:57:21 <ag_> based*
Sep 10 17:59:04 <sgw> you should be able to use ROOTFS_SIZE in that code
Sep 10 17:59:38 <ag_> sgw: I tried but no luck.
Sep 10 17:59:40 <sgw> ag_: take a look at IMAGE_CMD_ext3, you can see ROOTFS_SIZE is used there, since it pulled into the context of runimagecmd
Sep 10 18:00:14 <ag_> sgw: Hmmm... let me try once more. Thank you for hints.
Sep 10 18:00:23 <sgw> ag_: maybe you where using ${ROOTFS_SIZE} instead of $ROOTFS_SIZE?
Sep 10 18:00:35 <ag_> sgw: Bingo :|
Sep 10 18:00:56 <sgw> yeah it mayes a difference sometimes.
Sep 10 18:01:10 <ag_> sgw: Yeah i know....
Sep 10 18:01:23 <_jacob> Hi everyone!
Sep 10 18:01:28 <ag_> sgw: Thank you very much!
Sep 10 18:01:33 <ag_> Cheers _jacob
Sep 10 18:02:06 <_jacob> Hi ag_!
Sep 10 18:02:35 <_jacob> I have some questions about meta-toolchain and native-sdk packages...
Sep 10 18:02:59 <_jacob> I'm building a custom OS with some libs and a main application...
Sep 10 18:03:48 <_jacob> To finish this task, I need to build a SDK to distribute to others team, to develop/debug/maintain the main application...
Sep 10 18:04:51 <_jacob> So, the question is: i have some libs which my application will use...
Sep 10 18:05:45 <_jacob> But, I not wrote any recipe -native or -native-sdk...
Sep 10 18:06:39 <_jacob> Anyway, how I can include these libs to toolchain (like meta-toolchain recipe) ?
Sep 10 18:08:11 <_jacob> I really need to write all -native or -native-sdk recipes to each?
Sep 10 18:09:18 <sgw> _jacob: no, you can use the BBCLASSEXTEND for -native (if you need native tools only), if it's just libraries you only need to use BBCLASSEXTEND = "nativesdk"
Sep 10 18:09:33 <sgw> _jacob: in your existing recipe.
Sep 10 18:11:13 <_jacob> Hmm... Fine...
Sep 10 18:11:33 <_jacob> A trivial question, what's the difference between BBCLASSEXTEND and inherit ?
Sep 10 18:20:59 <_jacob> Oh sgw, I was with you in Linuxcon Brazil...
Sep 10 18:22:11 <_jacob> We talk about Yocto and Qt, with Thiago Macieira and Otavio Salvador and my boss...
Sep 10 18:23:41 <sgw> _jacob: Ok, good to hear from you again.
Sep 10 18:25:41 <sgw> _jacob: BBCLASSEXTEND is extending the class with a certain set of attributes like native, vs inherit some functionality from a class like autotools, probably not the best answer, but not a trivial question either.
Sep 10 18:25:55 <sgw> _jacob: maybe best to read the docs on BBCLASSEXTEND.
Sep 10 18:26:11 <_jacob> Our Yocto recipes are very advanced now... The OS with the main application is working fine in our x86 platform and the our new ARM test platform (pandaboard like)...
Sep 10 18:29:17 <_jacob> Oh, one more question... Or two more questions... What means gmae (aka meta-toolchain-sdk)? And, what's the difference between meta-toolchain and meta-toolchain-sdk ?
Sep 10 18:31:50 <evanp> _jacob: Gnome Mobile And Embedded
Sep 10 18:32:17 <evanp> _jacob: that confused me for quite a while
Sep 10 18:33:43 <evanp> _jacob: IIRC the only practical difference between meta-toolchain and meta-toolchain-sdk is the additional GMAE libs in the latter
Sep 10 18:34:24 <_jacob> Ok... Thus, I need only meta-toolchain...
Sep 10 18:35:01 <_jacob> Anyway, using BBCLASSEXTEND += " nativesdk " not work, yet...
Sep 10 18:37:12 <_jacob> I don't need create meta-toolchain.bbappend and add INSTALLS += " mylib " to it?
Sep 10 18:41:09 <evanp> _jacob: all BBCLASSEXTEND does is make the -nativesdk version available--the effect is quite similar to "cp foo.bb foo-nativesdk.bb"
Sep 10 18:42:08 <evanp> _jacob: it won't automatically show up inside anything (e.g. the SDK tarball)
Sep 10 18:42:45 <evanp> _jacob: how exactly you get that to happen is a good question...I just realized I need to figure out the answer too....
Sep 10 18:44:02 <_jacob> Hmm... I will create a meta-toolchain.bbappend and try using INSTALL += " mylib-nativesdk"
Sep 10 18:56:41 <ag_> Cheers all. Good night!
Sep 10 18:56:55 * ag_ goes home... 
Sep 10 18:57:28 <_jacob> Cya ag_
Sep 10 18:58:52 <evanp> _jacob: are you sure INSTALL does anything? looks like ultimately PACKAGE_INSTALL does the magic, which is set to the value of IMAGE_INSTALL when building for the target and the value of TOOLCHAIN_TARGET_TASK when building the SDK...unless I'm misreading this
Sep 10 18:59:57 <evanp> _jacob: notice that meta-toolchain-gmae.bb overwrites TOOLCHAIN_TARGET_TASK to include GMAE stuff
Sep 10 19:01:25 <evanp> _jacob: my money's on that variable being the one you need to change in your meta-toolchain.bbappend. Could be wrong though.
Sep 10 19:01:34 <_jacob> evanp, you is right. Looking at meta-toolchain-qte.bb, its override TOOLCHAIN_HOST_TASK
Sep 10 19:01:42 <_jacob> and TOOLCHAIN_TARGET_TASK
Sep 10 19:31:35 <JaMa> RP: bitbake-diffsigs is missing bb.tinfoil :/ http://git.openembedded.org/bitbake/commit/?id=e5707e3938ace47c4a8d1fa2e81583fd4dc6b95d
Sep 10 19:33:35 <_jacob> evanp, I made it using a new toolchain recipe and a few tasks
Sep 10 19:34:04 <_jacob> especifically I need the TOOLCHAIN_HOST_TASK and TOOLCHAIN_TARGET_TASK
Sep 10 19:34:59 <_jacob> in TOOLCHAIN_HOST_TASK, use RDEPENDS_${PN} += " mylib-nativesdk "
Sep 10 19:35:41 <_jacob> in TOOLCHAIN_TARGET_TASK, use RDEPENDS_${PN} += " mylib-dev "
Sep 10 19:36:33 <_jacob> If you want to change toolchain name, in meta-mytoolchain.bb, use TOOLCHAIN_OUTPUTNAME = "${SDK_NAME}-toolchain-mytoolchain-${DISTRO_VERSION}"
Sep 10 19:42:02 <msm> does anyone have an example of how to fix the rpath error qa?
Sep 10 19:42:13 <msm> err i guess i should look for one via git first
Sep 10 19:51:51 <_jacob> evanp, cheat! Now, bitbake wants all -nativesdk packages that mylib depends
Sep 10 19:52:22 <msm> RP: seeing this on master: https://gist.github.com/3693402
Sep 10 20:24:15 <RP> msm: multilib shouldn't be trying to extend nativesdk :/
Sep 10 20:24:54 <msm> RP: that's what i thought too
Sep 10 20:48:42 <msm> RP: build-appliance-image does not extend nativesdk either
Sep 10 20:49:01 <RP> msm: nor should it
Sep 10 20:49:06 <msm> RP: well nvm that's not important to paste i made
Sep 10 20:49:12 <msm> i thought they were both nativesdk, nevermind
Sep 10 21:20:51 <scot_> new Yocto user question: what does "??=" (as used in the manual's "MACHINE ??= ..." example) mean? how is it different from "?="
Sep 10 21:22:42 <evanp> scot_: the = and ?= assignments are processed in the order they are seen by the parser
Sep 10 21:22:59 <walters> in other words:  ??= = ?
Sep 10 21:23:36 <evanp> scot_: the ??= are ignored until parsing is complete, and only the last one encountered is processed
Sep 10 21:24:15 <evanp> scot_: so its like an even weaker version of ?=, except it's the last one that has an effect, not the first
Sep 10 21:28:27 <scot_> gotcha
Sep 10 21:28:28 <scot_> thanks
Sep 11 00:52:47 <evanp> is there a good way to provoke an inherit or require from within a RecipePreFinalise handler? I want to monkey-patch recipes which inherit from a particular .bbclass, but only when they also inherit from another one (via BBCLASSEXTEND)
Sep 11 00:57:10 <evanp> maybe a better way would be to add a new tag into OVERRIDES in my handler, but only for recipies which inherit from both the classes in question? hmm....
**** ENDING LOGGING AT Tue Sep 11 02:59:58 2012

**** BEGIN LOGGING AT Tue Sep 11 02:59:58 2012
Sep 11 08:22:16 <ag_> Hello.
Sep 11 08:22:49 <ag_> Anybody can give me a hint on error like dsputil_vfp.S:118: Error: selected processor does not support ARM mode `vstmia r0!,{s14-s15}'?
Sep 11 08:23:28 <ag_> The respective cpu has vfp
Sep 11 08:25:12 <seebs> That usually means you're compiling in thumb mode but you've got a program using inline ARM mode assembly.
Sep 11 08:25:57 <bluelightning> morning all
Sep 11 08:28:08 <ag_> bluelightning: Hello.
Sep 11 08:28:19 <bluelightning> hi ag_
Sep 11 08:28:50 <ag_> seebs: Indded. It has -mthumb-interwork
Sep 11 08:28:54 <ag_> indeed*
Sep 11 10:54:25 <ag_> seebs: I don't think that the problem is with thumb
Sep 11 10:55:13 <ag_> seebs: because above of this error i compile successfully some other inline S files
Sep 11 10:55:45 <ag_> seebs: And it dies only when seeing vfp instructions
Sep 11 11:00:55 <gotan> hi, I'm attempting to boot up a live.hdd img, and i'm getting "INFO: task mount:1439 blocked for more than 120 seconds." after the switchroot
Sep 11 11:40:49 <ag_> seebs: I managed to fix it. It seems like -mfpu=vfp was not in gcc flags...
Sep 11 12:54:12 <peachj> Does anyone know of any good docs that describe release management for embedded Linux distros created using Yocto?  It's a bit difficult to search for, and everything I've found so far hasn't been fruitful...
Sep 11 12:54:40 <peachj> Just looking for some "best practices" sorts of documents
Sep 11 12:59:14 <bluelightning> peachj: I think we're planning to add that sort of information to the Development Manual
Sep 11 13:03:28 <peachj> Okay, so let me briefly explain my current setup
Sep 11 13:03:57 <peachj> I've got a handful of layers all checked into a git repo along with the poky tools
Sep 11 13:04:27 <peachj> The overarching thing that controls all of these layers and tools is a single git repo called "build-bundle", where each layer is a git submodule
Sep 11 13:05:01 <peachj> We've come up with two approaches for potentially cutting releases out of this build-bundle repo
Sep 11 13:05:13 <peachj> 1) Use git tags and call it a day.  Just tag whatever you release.
Sep 11 13:06:01 <peachj> 2) We're already going to produce logs for these releases, and the logs will contain the data about the revisions of all the layers as well.  So, we've thought about using the logs to track (and later reproduce) releases.
Sep 11 13:06:44 <peachj> The only advantage to the latter is, if AUTOREV ever made it into a release for any reason, you'd have the appropriate revision for the AUTOREV'd code.
Sep 11 13:07:16 <RP> peachj: This is partly why submodules are a bit of a hazard :/
Sep 11 13:07:49 <RP> peachj: for exmaple we build the poky repository with the combo-layer tool so that one git revision gives a very specific state of the tree
Sep 11 13:08:37 <RP> This has its pros and cons too, I'm not saying any one approach is better than the other, they're just different and it depends on your needs
Sep 11 13:12:17 <ag_> khem: Do you have one minute?
Sep 11 13:13:16 <ag_> khem: I'm almost sure you can help me with something that I was struggling to make it work. And i almost give up.
Sep 11 13:13:42 <peachj> RP: I hadn't read about combo-layer before.  Doing further reading, I still don't understand how that might help me with the situation I'm describing, with AUTOREV.  Am I missing something?
Sep 11 13:14:24 <RP> peachj: It doesn't help AUTOREV, we simply have a policy of nothing using AUTOREV by default
Sep 11 13:14:41 <peachj> Sure, that's the same policy we're adopting.
Sep 11 13:15:30 <peachj> So...At the end of the day, I assume what you guys would recommend as a best practice would be to use git tagging, and if for some reason that's not good enough, fall back on the log?
Sep 11 13:15:34 <JaMa> peachj: use AUTOREV from separate .inc file (pulled by distro config or local.conf) and bump SRCREVs in recipes just before release and remove require that.inc
Sep 11 13:16:15 <JaMa> peachj: I'm using small script to get last used revisions from bitbake persistent cache and replace SRCREVs in recipes
Sep 11 13:17:22 <peachj> JaMa: We're typically going to use local.conf to set AUTOREV for builds, I was just wondering what would happen if some dev made the mistake of adding SRCREV=${AUTOREV} to their BB file and that somehow got released.
Sep 11 13:17:43 <JaMa> then it's really mistake and should not happen :)
Sep 11 13:17:47 <peachj> JaMa: I was actually going to create such a script for the purpose of reproducing a build where AUTOREV was used.
Sep 11 13:19:42 <peachj> I'm going to probably continue going forward with the git tagging approach, then.  We'll still keep logs, but they won't be used as the standard method for reproducing releases.
Sep 11 13:25:30 <RP> peachj: tags should be good but with submodules I'm not sure how the two can interact
Sep 11 13:28:07 <peachj> RP: I would think it would retain the state of the submodule revisions, just like it would anything else...Is there a reason why tags would interact badly with submodules?
Sep 11 13:28:52 <RP> peachj: I've not worked with them for a long time. Once they didn't do things you'd expect so I'd just double check
Sep 11 13:29:53 <peachj> RP: Fair enough.  I wouldn't be doing a good job of moving us to new systems for building and releasing if I didn't test it ;-)  Thanks for the advice.
Sep 11 13:51:29 <rburton> before i look, can anyone (looking at RP and JaMa here!) remember why libx11 wants xproto-native?
Sep 11 13:55:59 <RP> rburton: not offhand
Sep 11 13:57:18 <JaMa> rburton: to build makekeys.c it seems
Sep 11 13:57:26 <JaMa> rburton: but that should be removed completely now
Sep 11 13:57:34 <rburton> yeah, that was next on the list
Sep 11 13:57:41 <rburton> almost down to a single libx11 :)
Sep 11 13:57:48 <rburton> check me out avoiding writing slides
Sep 11 13:57:56 <JaMa> touch makekeys-makekeys.o ; ${BUILD_CC} ${BUILD_CFLAGS} -I${STAGING_INCDIR_NATIVE} makekeys.c -o makekeys
Sep 11 13:58:16 <JaMa> here it's using STAGING_INCDIR_NATIVE for some reason (that's why I think xproto-native was used)
Sep 11 13:58:23 <rburton> yeah that would be it
Sep 11 13:58:31 <rburton> thanks
Sep 11 14:00:26 <rburton> so if i managed to remove libx11-trim, then libx11 should rreplace/rconflict/rprovide libx11-trim, right?
Sep 11 14:01:42 <RP> rburton: I think they all used the same package names?
Sep 11 14:02:50 <JaMa> rburton: yes
Sep 11 14:02:51 <rburton> RP: from what i can tell, only when debian-renaming
Sep 11 14:03:17 <RP> rburton: we generally have that enabled
Sep 11 14:03:32 <JaMa> rburton: well I never used -diet or -trim (neither did koen afail) and we're only 2 who cares for upgrade path it seems..
Sep 11 14:04:04 <rburton> oh, angstrom used proper libx11?
Sep 11 14:04:20 <JaMa> I think so
Sep 11 14:04:22 <JaMa> but not sure
Sep 11 14:04:42 <JaMa> conf/distro/include/angstrom-core-tweaks.inc:PREFERRED_PROVIDER_virtual/libx11 = "libx11"
Sep 11 14:05:26 <rburton> fair enough
Sep 11 14:05:41 <rburton> fwiw, oe-core defaults to -trim and then poky-lsb uses full x11
Sep 11 14:06:14 <rburton> JaMa: you don't know of anything that actually uses xcms, right?
Sep 11 14:07:43 <JaMa> xcms?
Sep 11 14:08:09 <rburton> exactly
Sep 11 14:08:21 <JaMa> ah no
Sep 11 14:09:20 <rburton> well that's the easy stuff sorted, so it's "just" makekeys now
Sep 11 14:09:37 <ant_work> JaMa: out of curiosity, is the xserver-nodm-init unified with meta-oe by now?
Sep 11 14:10:27 <JaMa> ant_work: no
Sep 11 14:10:46 <ant_work> ouch
Sep 11 14:37:13 <JaMa> hmm 2nd opkg segfault today (armv4t and armv7a machines) both left with broken /var/lib/opkg/status :/
Sep 11 14:38:03 <ant_work> JaMa: is armv4t kernel ok then?
Sep 11 14:39:01 <JaMa> mine is
Sep 11 14:39:13 <ant_work> we'll test on a few hour with fresh-built userspace, on collie
Sep 11 14:39:43 <ant_work> wow, seems tc is ok now, great
Sep 11 14:39:53 <JaMa> ant_work: check this thread on oe-core as you care about meta-handhelds qemuarm: should it really have TUNE_ARCH armv5te?
Sep 11 14:40:30 <ant_work> ok
Sep 11 14:40:37 <bluelightning> JaMa: I saw you cc'd me in but to be honest I have no idea what the correct answer is :(
Sep 11 14:41:16 <JaMa> let's hope RP will comment on that as that was his comment I was copy&pasting
Sep 11 14:41:46 <JaMa> e.g. ppc seems to set TUNE_PKGARCH for each tune-*
Sep 11 14:44:17 <JaMa> but it would be better to set xscale/arm926 tune only for packages where such -mtune brings some speedup and build the rest only with -march
Sep 11 14:45:29 <JaMa> but mixed feed and -mtune=xscale packages on arm926 targets looks like worst case
Sep 11 14:50:13 <JaMa> oe-classic had the same issue with mixed -mtune in package arch feeds, but at least it wasn't rebuilding them after each machine switch
Sep 11 15:00:09 <Song_Liu> YPTM: Hi all, let's get the Yocto Project Technical team meeting started now. Would you please let me know who's on the conference bridge?
Sep 11 15:00:23 <bluelightning> YPTM: Paul Eggleton is here
Sep 11 15:00:30 <tomz2> YPTM: Tom Zanussi here
Sep 11 15:00:31 <rburton> YPTM: ross here
Sep 11 15:00:36 <bluelightning> YPTM: also Belen Barros-Pena is in the room
Sep 11 15:00:48 <strassek> YPTM: Kevin Strasser is here
Sep 11 15:00:49 <bogdanm> YPTM: here
Sep 11 15:01:04 <fray> YPTM: here now
Sep 11 15:01:08 <sgw> YPTM: Saul Here
Sep 11 15:01:15 <laur> YPTM: LaurentiuP joined
Sep 11 15:01:26 <Zagor> YPTM: Björn here
Sep 11 15:01:33 * RP is here
Sep 11 15:01:53 <darknighte> Song_Liu: Not going to be able to attend.  I have an internal meeting to attend.
Sep 11 15:02:12 <FunkyPenguin> YPTM: Andy Wafaa is in
Sep 11 15:02:26 <LaurentiuSerban> Laurentiu Serban
Sep 11 15:02:31 <fray> yup
Sep 11 15:03:08 <jzhang> YPTM: JZ is here
Sep 11 15:03:26 <pab_> paul here
Sep 11 15:04:20 <nitink> YPTM: nitin is on the bridge
Sep 11 15:04:20 <Song_Liu> YPTM: Any opens from anyone?
Sep 11 15:04:52 * RP wants to highlight the point on the schedule we're at - starting to switch from feature development to stabilisation and bug fixing
Sep 11 15:05:04 * RP doesn't have much more to add to that
Sep 11 15:06:46 <dvhart> YPTM: Darren is on
Sep 11 15:08:25 <davest> YPTM: davest is here
Sep 11 15:15:45 <Guest10301> hi all... trying to get started with yocto, however having a problem unzipping build appliance... says i need 734 PB for install!? MD5 on download page is for older version... any help?
Sep 11 15:18:22 <fray> nice
Sep 11 15:18:28 <sgw> Guest10301: I will look into that!
Sep 11 15:18:31 <dvhart> Guest10301, ah come on, just buy a bigger disk already
Sep 11 15:18:33 <dvhart> ;)
Sep 11 15:20:07 <fray> YPTM: I can share a few things..
Sep 11 15:20:27 <zeddii> argh
Sep 11 15:20:27 <Guest10301> pipe dreams...
Sep 11 15:20:32 * zeddii curses sgw ;) 
Sep 11 15:20:39 <zeddii> his request made me forget the meeting.
Sep 11 15:20:52 <zeddii> YPTM: I had intentions of joining, but I blame Saul for missing :)
Sep 11 15:21:11 <halstead> Guest10301, MD5SUM is available now.
Sep 11 15:21:30 <halstead> No errors detected in compressed data of Yocto_Build_Appliance_Yocto_1.2.1.zip.
Sep 11 15:21:48 <sgw> Guest10301: just a couple of sanity questions, what OS are you on?
Sep 11 15:22:02 <Guest10301> win7 x64, chrome browser
Sep 11 15:22:11 <sgw> halstead: so the md5 on the web-page is now the correct one
Sep 11 15:22:52 <Guest10301> the file size is also incorrect... should be 2.6 GB
Sep 11 15:23:14 <Guest10301> for file Yocto_Build_Appliance_Yocto_1.2.1.zip
Sep 11 15:24:19 <halstead> sgw, The md5 there is generated from the file in the release on the NAS.
Sep 11 15:24:27 <sgw> Guest10301: 55f242fbfabe4e20b7418c894a4b3d67  Yocto_Build_Appliance_Yocto_1.2.1.zip
Sep 11 15:24:45 <Guest10301> sgw: that's what i calculated on my machine also...
Sep 11 15:24:53 <Guest10301> hmm let me try unzipping with other application then
Sep 11 15:24:55 <sgw> halstead: we need to update the webpage itself along with the size which is 2.7G
Sep 11 15:25:33 <sgw> Guest10301: which application Chrome? or windows exploder (in this case it's true).
Sep 11 15:25:55 <Guest10301> i initially used windows explorer to unzip
Sep 11 15:26:31 <Guest10301> it's extracting with 7zip now... windows, go figure
Sep 11 15:28:25 <halstead> sgw, Information at https://www.yoctoproject.org/download/tools/build-appliance is now updated.
Sep 11 15:30:46 <darknighte> halstead: geez.  that took you *so* long!
Sep 11 15:31:09 <halstead> ;)
Sep 11 15:31:19 * darknighte really appreciates halstead for response times
Sep 11 15:31:22 <Guest10301> sgw: successfully unzipped with 7zip. not sure if it's worth writing a note on download page, or if it's just an isolated incident, but yeah, got errors trying to extract with win 7 x64 windows explorer
Sep 11 15:33:22 <Song_Liu> YPTM: Thank you all for joining the meeting. You have a nice day/evening!
Sep 11 15:34:17 <sgw> Guest10301: thanks for that, I think others have used windows explorer, so maybe this is isolated (let's hope at least), let me know if you need any additional help or questions
Sep 11 15:34:38 <Guest10301> sgw: no problem, thank you!
Sep 11 15:39:48 * ag_ out
Sep 11 15:40:25 <rburton> JaMa: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=ross/xorg
Sep 11 15:43:36 <JaMa> rburton: 62b1f533688281d24cc15464cf9723292b5cc904 should probably bump PR in other recipes using xorg-lib-common.inc but probably fine
Sep 11 15:44:26 <rburton> JaMa: i was avoiding that because its every recipe there, and it's probably a no-op for most of them
Sep 11 15:45:26 <JaMa> f1b346b2601865ea9f469db721975a296d850a1b doesn't --disable-xcms work only with X18NCMSstubs.diff? or is it only for xlocale?
Sep 11 15:46:29 <rburton> the cms stubs don't actually appear to be needed
Sep 11 15:46:52 <rburton> literally nothing in the universe uses xcms
Sep 11 15:47:07 <rburton> that reminds me, i need to prune that patch
Sep 11 15:47:21 <rburton> it's pointlessly reverting bits of the configure script
Sep 11 15:48:09 <rburton> really considering moving -diet to meta-oe...
Sep 11 15:49:40 <JaMa> rburton: d8e152c12b4db7148800d67cde22622b4e1d5bc9 drops x11_disable_makekeys.patch but file is still there I guess
Sep 11 15:50:23 <rburton> JaMa: goot catch
Sep 11 15:50:46 <JaMa> I don't really like 2776141b053b025b83583c3a9621fb4125eaa363, but that's just about taste I guess
Sep 11 15:51:13 <rburton> JaMa: i was getting annoyed with three copies of almost every patch
Sep 11 15:51:15 <JaMa> common patches are fine in common directory, but X18NCMSstubs.diff could be left in libx11-diet-1.5.0
Sep 11 15:51:24 <rburton> yeah, now its just one common...
Sep 11 15:51:34 <rburton> maybe i'll revert it
Sep 11 15:51:56 <JaMa> I've made them split a while back when -diet -trim and proper had different versions
Sep 11 15:52:25 <JaMa> so it was easier to keep them in ${P}
Sep 11 15:52:35 <rburton> yeah
Sep 11 15:53:01 <JaMa> and maybe again it would be easier to review if you remove libx11-trim as first commit :)
Sep 11 15:53:36 <rburton> true - this was the progression of removing bits until everything's the same
Sep 11 15:55:03 <JaMa> yes I guessed that :)
Sep 11 16:02:26 <JaMa> rburton: and why not convert libx11-diet to PACKAGECONFIG[xlocale] too?
Sep 11 16:02:52 <JaMa> rburton: because of those additional patches applied?
Sep 11 16:04:38 <rburton> JaMa: working on it!
Sep 11 16:04:50 <rburton> JaMa: but yes, the patches make that non-trivial
Sep 11 16:05:27 <JaMa> rburton: ah ok.. all seems like wrapped in #ifdef XLOCALE, except fix-utf8-wrong-define.patch which doesn't have any description why it was needed :/
Sep 11 16:06:06 <JaMa> rburton: and X18NCMSstubs.diff seems to hide that --disable-udc option
Sep 11 16:06:43 <rburton> yeah thats the crazy patch that needs ... work
Sep 11 16:07:14 <JaMa> maybe look at older version before it was rebased couple of times with libx11-* upgrades :/
Sep 11 16:08:48 <JaMa> hmm it looked that bad in oe-classic already
Sep 11 16:14:40 <rburton> JaMa: my favourite thing about libx11 is how the -diet patches are all "fix" this and "fix" that
Sep 11 16:14:46 <rburton> JaMa: when they mean "hack" and "break"
Sep 11 16:24:37 <JaMa> rburton: true :)
Sep 11 16:24:54 <JaMa> that's why I never used -diet :)
Sep 11 16:29:13 <rburton> JaMa: i say if someone cares enough about -diet they can keep it
Sep 11 16:49:54 <peachj> RP: You around still?  I've got a question re: Bug 3039, i.e. the one about the hardcoded mapping in sstate.bbclass.  (https://bugzilla.yoctoproject.org/show_bug.cgi?id=3039)
Sep 11 16:50:07 <RP> peachj: still here (just)
Sep 11 16:50:18 <peachj> I still can't seem to add my own tasks
Sep 11 16:50:30 <RP> peachj: what isn't working?
Sep 11 16:50:51 <peachj> Specifically, SSTATETASKS+="mytask" is not causing mytask to show up in the variable when it's processed at that point.
Sep 11 16:51:44 <RP> peachj: What else are you setting?
Sep 11 16:52:05 <RP> peachj: Is this task in all recipes and the core config or just some of them?
Sep 11 16:52:06 <peachj> I'm doing the exact same thing that was in the ticket
Sep 11 16:52:13 <RP> peachj: as deploy?
Sep 11 16:53:34 <peachj> RP: Here's do_log_srcrev.bbclass, in it's entirety: http://pastebin.com/EZG7km7J
Sep 11 16:53:46 <RP> peachj: where do you add that?
Sep 11 16:53:59 <RP> INHERIT += "classname"?
Sep 11 16:54:01 <peachj> RP: I'm currently only inheriting it in a test package
Sep 11 16:54:10 <RP> peachj: so you need the extra line
Sep 11 16:54:10 <peachj> No, "inherit do_log_srcrv"
Sep 11 16:54:34 <RP> EXTRASSTATEMAPS = "do_log_srcrv:srcrev"
Sep 11 16:54:38 <RP> well, +=
Sep 11 16:54:53 <RP> and you need to do that somewhere that *is* inherited by the core
Sep 11 16:55:04 <peachj> RP: Will that work?  Won't sstate.bbclass overwrite me when it's run?
Sep 11 16:55:27 <RP> peachj: hmm, probably should be a += in there too
Sep 11 16:56:36 <peachj> RP: If I "INHERIT += do_log_srcrev" in local.conf, will that work by itself?
Sep 11 16:56:46 <RP> peachj: I think so
Sep 11 16:56:48 <peachj> RP: Because that's my intended use case, eventually
Sep 11 17:01:39 <peachj> RP: Now I'm hitting a variety of other problems (like the class isn't in the poky layers, so it can't find it), but some of these I might be able to tackle on my own
Sep 11 17:01:54 <peachj> RP: I'll see what I can figure out going down this path
Sep 11 17:02:10 <RP> peachj: sounds like your layer.conf needs to append to BBPATH
Sep 11 17:02:16 * RP -> afk
Sep 11 17:10:26 <sgw> ag_: ping, I saw an expr failure with your change last night, digging into it now.
Sep 11 18:30:12 <msm> if im going to make another layer in a git repo, i probably need to do a complete reorg
Sep 11 18:30:31 <msm> or is it reasonable to just add another meta-newlayer in a meta-layer repo?
Sep 11 18:31:35 <khem> msm: you can create sublayers like meta-intel
Sep 11 18:31:40 <khem> has done
Sep 11 18:31:59 <msm> perfect, i just wanted an example ;)
Sep 11 18:32:12 <khem> btw. may I ask what this layer it about
Sep 11 18:32:16 <khem> s/it/is
Sep 11 18:33:58 <msm> trying to move out our distro bits to a separate layer
Sep 11 18:34:35 <msm> and also maybe one for a freescale sanctioned toolchain
Sep 11 18:40:45 <evanp> peachj: my project is using git submodules too; I plan to tag the outer repo and then have the build control script write SRCREVs into a .conf file based on the submodule revisions. Can't claim that's "best practice" though, it's a little odd.
Sep 11 18:49:53 <zenlinux> When the virtual keyboard pops up in Sato, how do you close it?
Sep 11 18:52:08 <peachj> evanp: How are you going to get the SRCREVs?  Just curious, because I've been perpetually fighting with trying to find a way to dereference AUTOREV (for non-release builds, of course) into the correct revision.
Sep 11 18:52:34 <peachj> evanp: (I've got a method now, but it still doesn't work 100%)
Sep 11 18:55:34 <evanp> peachj: right now, I solve it outside of bitbake--I run a script which generates a .conf file with one variable=commit line per submodule, then in my recipes I set SRCREV=${variable}
Sep 11 18:57:32 <evanp> peachj: originally I tried enhancing bitbake's git fetcher to allow specifying a submodule name in SRC_URI, but the corner cases made me abandon that. I like my original approach better conceptually, but this way is trivially reliable.
Sep 11 18:58:11 <msm> sgw: there is a v3 of that patch already too btw
Sep 11 18:58:34 <evanp> peachj: provided of course nobody sticks SRCREV=${AUTOREV} into a .bb file
Sep 11 18:58:40 <msm> sgw: im bad, i know ;)
Sep 11 19:00:39 <peachj> evanp: For me, I've got a task that's going to execute called "do_log_srcrev", and in theory, it should create a file under each package's workdir with a line of this format: <bb file name> <SRC_URI> <revision> ["AUTOREV", if pkg is AUTOREV'd]
Sep 11 19:00:47 <peachj> Those all get stored via sstate
Sep 11 19:01:48 <peachj> evanp: In theory, I want to turn the task on during my "system" (i.e. non-user) builds by doing 'INHERIT += "do_log_srcrev"' in local.conf
Sep 11 19:01:49 <sgw> msm: I missed the PR bump, was too focused on just the script!
Sep 11 19:02:02 <peachj> evanp: But that part isn't working right yet...
Sep 11 19:02:14 <sgw> msm I found v3 also, just about to start a mut, is there a v4 ;-)
Sep 11 19:04:06 <msm> pb acked v3 so i hope not
Sep 11 19:04:37 <evanp> peachj: I take it you have a do_log_srcrev.bbclass which does "addtask log_srcrev before do_configure" or something?
Sep 11 19:06:11 <peachj> evanp: Yeah, but "after do_fetch before do_compile", actually.  At least that's where I'm sticking it right now.
Sep 11 19:06:49 <peachj> evanp: It has to come after do_fetch, in particular, because do_fetch sets up SRCPV correctly, which is ultimately the variable I have to check
Sep 11 19:29:54 <msm> RP: xz for sstate-cache…. where should I implement this?
Sep 11 19:36:09 <peachj> So, I'm led to another question by my pursuit of finding SRCREVs.  Where do I go to inject a task into the middle of the task graph of every package?  I've tried INHERIT += "log_srcrev", but that gives me oodles of errors about trying to resolve SRCPV before it's been set...
Sep 11 19:43:18 <evanp> peachj: not sure this is a good idea...but you could always just ask git what version it has checked out, instead of trying to grab that from a variable....
Sep 11 19:48:00 <evanp> peachj: actually...IIRC the final commit ID that the git fetcher checks out isn't actually put into the datastore at all, at least in some cases
Sep 11 20:53:32 <RP> msm: how do you mean "where"?
Sep 11 20:56:04 <msm> well i did it in the sstate.bbclass a while back
Sep 11 20:56:10 <msm> and you mentioned it should be in bitbake
Sep 11 20:56:21 <msm> so im asking where you start if i reimplement this so i don't waste time ;)
Sep 11 21:01:44 <RP> msm: Do you have the reference where I said that as I can't picture what I was thinking of...
Sep 11 21:05:53 <msm> RP: http://git.freescale.com/git/cgit.cgi/ppc/sdk/poky.git/commit/?id=fb970dc90ce5007d657670880fbfc26b6c54dfe7
Sep 11 21:05:56 <msm> for example
Sep 11 21:06:19 <RP> msm: I remember you doing this, but where is the feedback I gave?
Sep 11 21:06:37 <msm> http://lists.linuxtogo.org/pipermail/openembedded-core/2011-December/013911.html
Sep 11 21:06:43 <msm> still looking
Sep 11 21:08:07 <msm> RP: must have been IRC
Sep 11 21:08:11 <msm> i can't find it
Sep 11 21:08:21 <msm> no comments from you on email
Sep 11 21:08:21 <msm> http://patches.openembedded.org/project/oe-core/list/?state=*&q=sstate.bbclass%3A+add+option+to+use+alternate+compression+in+lieu+of+gzip
Sep 11 21:08:31 <RP> msm: I can't picture how this would work from bitbake or how that would help
Sep 11 21:09:08 <RP> msm: I'd probably take that patch above although I don't like the lack of standardisation this is going to lead to
Sep 11 21:09:33 <msm> RP: well the savings is quite large
Sep 11 21:09:42 <RP> msm: Requiring native things tend to cause problems too though, this is mainly why I went for gzip :/
Sep 11 21:09:46 <msm> RP: so, its sort of a requirement for us to fit stuff on a dvd
Sep 11 21:09:54 <RP> msm: does centos have xz?
Sep 11 21:10:00 <msm> no
Sep 11 21:10:04 <msm> you need to install it
Sep 11 21:10:08 <RP> right :(
Sep 11 21:11:37 <msm> well, its just sstate its not like anyone really shares that
Sep 11 21:13:04 <RP> msm: we do as a project and people do within sites
Sep 11 21:13:25 <msm> right, but there is a structure there
Sep 11 21:13:46 <msm> we used xz just fine within since everything was setup for folks and documented
Sep 11 21:13:56 <RP> msm: I just worry that if you give people options like this, people will use them and no sstate will be compatible with another. We'll then need to add code to search for a list of different compression types in order
Sep 11 21:13:58 <RP> and so on
Sep 11 21:14:29 <msm> hmmm, i guess you could probably always fallback to all types
Sep 11 21:14:42 <msm> just create via the one type specified
Sep 11 21:14:42 <RP> msm: I can see the bug reports now. "sstate from freescale doesn't work with the poky/angstrom distro type"
Sep 11 21:14:54 <msm> do they anyways?
Sep 11 21:15:04 <msm> it seems unlikely they would have the same sigs even now
Sep 11 21:15:14 <RP> msm: fallback to all types is going to really slow down what is a relative fast path atm :/
Sep 11 21:15:25 <RP> msm: that won't stop the bug getting filed
Sep 11 21:15:46 <msm> NOTABUG :)
Sep 11 21:16:03 <msm> no one is supposed to use our distro anyways, its just for people without an internet connection ;)
Sep 11 21:16:07 <RP> msm: Someone will make it an issue, I know how this works
Sep 11 21:16:23 <RP> msm: pick different names above then...
Sep 11 21:17:01 <RP> msm: the correct answer is probably change and hardcode xz instead but that means rewriting and testing the quick start/prerequisute lists and documenting dealing with centos
Sep 11 21:17:04 <msm> hmm, well there is a problem then… because the space savings is quite large...
Sep 11 21:17:54 <RP> msm: I have no choice but to take the patch, I just know I'll get a ton of pain down the line for this and end up into making the code nastier :(
Sep 11 21:18:16 <RP> i.e. search for a list of different compression types
Sep 11 21:20:22 <msm> RP: we should probably not even make a release then ;) hehe
Sep 11 21:20:25 <msm> RP: skip the hassle
Sep 11 21:21:07 <RP> msm: It'll just turn into another fetcher
Sep 11 21:21:23 <msm> RP: i dont think it's that bad
Sep 11 21:21:40 <RP> msm: I once thought that about the fetcher ;-)
Sep 11 21:22:06 <msm> we should just add sstate to the fetcher
Sep 11 21:22:17 <RP> msm: Its questions like which tar version support the "--use-compress-program" argument ?
Sep 11 21:22:23 <RP> msm: how would that help?
Sep 11 21:22:38 <RP> I'm hoping the answer is "lots" but I don't know that
Sep 11 21:23:04 <msm> RP: im just joking
Sep 11 21:39:45 <kergoth> hmm, WARNING: Screen started. Please connect in another terminal with "screen -r devshell devshell_12990"
Sep 11 21:39:51 <kergoth> i don't think this screen command syntax is correct
Sep 11 21:52:43 * mranostay hides from challinan 
Sep 11 21:53:52 <mranostay> challinan: i see you are touring the country. all on your bike?
Sep 11 22:09:10 <ccssnet> challinan_: that would be rather time consuming. touring any country on a bike
Sep 11 22:10:29 <ccssnet> not sure where that was talked about in backlog, i must have missed it but mranostay mentioned it
Sep 11 22:31:29 <ant__> well... today netfilter.org is down :/
Sep 11 22:31:55 <ant__> iptables_1.4.15.bb, do_fetch -> boom
Sep 11 22:32:11 <ant__> DOS ?
Sep 11 22:38:52 <grifter188> ant__: I get nslookup... for now, but port 80 won't answer
Sep 11 22:39:09 <ant__> lists are down as well
Sep 11 22:41:45 <ant__> let's retry tomorrow
Sep 11 22:41:48 <ant__> gn
Sep 12 01:06:32 <fk_007> i followed instructions here to create sd card for booting on olinuxino micro ---> http://www.jann.cc/2012/08/08/building_freescale_s_community_yocto_bsp_for_the_olinuxino.html
Sep 12 01:07:11 <fk_007> i can boot the sd card but I have no keyboard and the video is offset on the TV Screen
Sep 12 01:10:27 <fk_007> I have tried downloading the defconfig configuration file ---> https://github.com/OLIMEX/OLINUXINO/tree/master/SOFTWARE/iMX233 and booting and it does the same as before although I have gotten the one generated by Dimitar Gamishev to work perfectly
Sep 12 01:12:02 <fk_007> when I bitbake what do I need to do to ensure the settings from menuconfig are being used?
Sep 12 02:29:23 <kergoth> ugh, hob seems to require that meta-hob be relative to COREBASE, which basically hoses anyone doing builds with a different layout than poky uses — e.g. anyone using oe-core separately
Sep 12 02:30:31 <kergoth> hmm
Sep 12 02:32:47 <seebs> Will it be more work to change that, or to have all such people forcibly suppressed?
Sep 12 02:34:26 * kergoth chuckles
Sep 12 02:37:33 <seebs> <-- it has been a very long month or three of development effort in my world
**** ENDING LOGGING AT Wed Sep 12 02:59:59 2012

**** BEGIN LOGGING AT Wed Sep 12 02:59:59 2012
Sep 12 04:37:09 <msm> zeddii: go. to. bed
Sep 12 08:21:40 <bluelightning> morning all
Sep 12 09:57:58 <rburton> who was it that was actually using meta-handheld on a zaurus?
Sep 12 09:58:14 <JaMa> I'm
Sep 12 09:58:19 <rburton> it's the only user of mesa-xlib that i can tell -- and that can probably be dropped
Sep 12 09:58:34 <JaMa> and ant_work is
Sep 12 09:58:43 <rburton> instead of pulling in mesa-xlib, just remove the opengl distro feature - no glx in xorg so no mesa.
Sep 12 09:58:45 <JaMa> I wasn't using meta-xlib
Sep 12 09:59:05 <JaMa> and what about other distro supported devices? :)
Sep 12 09:59:17 <JaMa> which can support opengl
Sep 12 09:59:35 <rburton> is there anything in meta-handheld that does support gl?
Sep 12 09:59:43 <rburton> well, in that case, for now just use mesa-dri
Sep 12 09:59:54 <JaMa> yes that's what I'm doing
Sep 12 09:59:57 <rburton> you'll get a different form of gl software rendering
Sep 12 10:00:25 <rburton> ant_work: there?
Sep 12 10:00:44 <rburton> from my logs, it's all ant_work's fault
Sep 12 10:00:58 <JaMa> hehe, right :)
Sep 12 10:15:05 <ant_work> hi there
Sep 12 10:16:50 <ant_work> the xserver settings have been a sort of quicksands...
Sep 12 10:17:21 <ant_work> we decided to abandon kdrive and went to the lighter xorg server we had
Sep 12 10:19:03 * ant_work is still hoping xserver-nodm-init & co. will be unified within meta-oe and oe-core
Sep 12 10:19:24 <rburton> ant_work: the init scripts having diverged is also on my list
Sep 12 10:19:47 <rburton> ant_work: but apparently you're to blame for meta-handhelds using mesa-xlib for zaurus
Sep 12 10:20:15 <rburton> ant_work: so any objections to me ripping mesa-xlib out of oe-core?
Sep 12 10:20:24 <ant_work> no obections
Sep 12 10:20:28 <ant_work> +j
Sep 12 10:20:36 <rburton> the alternatives currently include just using mesa-dri, or removing the opengl distro feature
Sep 12 10:20:37 <rburton> yay
Sep 12 10:20:39 <rburton> thanks :)
Sep 12 10:21:07 <ant_work> iirc we discussed with RP on irc about that :]
Sep 12 10:21:47 <ant_work> keep on the great work, looking forward to a single xserver
Sep 12 10:21:49 <rburton> yeah, this has been talked about before. just confirming before i send the patch
Sep 12 10:22:19 <rburton> down to just libx11 and libx11-diet!
Sep 12 10:22:30 <rburton> or as i prefer to call them, libx11 and libx11-on-my-god-it-burns
Sep 12 10:22:58 <rburton> (does anyone actually use libx11-diet?)
Sep 12 10:23:12 <ant_work> btw, for strange reasons bitbake does not error out about missing "xserver-xorg-lite" still in our conf
Sep 12 10:23:43 <rburton> that's clever
Sep 12 10:24:11 <rburton> oh, still some references in poky too
Sep 12 10:26:14 <JaMa> ant_work: there is patch for that if you want in my branch
Sep 12 10:27:05 <ant_work> JaMa: I think we should just revert http://cgit.openembedded.org/meta-handheld/commit/conf/machine/include/zaurus.inc?id=2ed328bd842c96496fb5bbeecd3f6c7ed2df4c65
Sep 12 10:27:49 <JaMa> ant_work: I never used that one..
Sep 12 10:28:30 <ant_work> I was lurking in your repo in a bad moment :)
Sep 12 10:28:55 <JaMa> https://gitorious.org/shr/meta-handheld/commit/d366d0215065b96e9f5de5fe4bf4ebf684d72aaf
Sep 12 10:29:08 <JaMa> but mesa-xlib should be now changed too
Sep 12 10:29:24 <JaMa> I have it set by distro config..
Sep 12 10:39:12 <agherzan> Hi everybody!
Sep 12 10:39:25 * agherzan is registering for ELCE and Yocto day. :)
Sep 12 11:24:33 <ant_work> rburton: while you're playing with X, what about including xinput-calibrator? I did send a proposal once but one said 'don't pollute oe-core'  . Well, IMHO if we want to be objective the whole xorg-xserver bunch of correlated packages ought to be in a separate layer...
Sep 12 11:25:35 <JaMa> ant_work: now it was, "when you're moving stuff from meta-oe to oe-core, use at least latest version"
Sep 12 11:26:05 <ant_work> yes, was during the unfortunate 'systemd-toxic-brakage"...
Sep 12 11:26:23 <JaMa> http://patchwork.openembedded.org/patch/13093/
Sep 12 11:26:47 <JaMa> now this was even before systemd was introduced in meta-oe
Sep 12 11:26:55 <JaMa> s/now/no,/
Sep 12 11:27:23 <ant_work> JaMa: anyway after one year the situation is, we still have 2 udev and 2 xserver.... oe-core + meta-oe
Sep 12 11:27:39 * ant_work counts on kernel.bbclass being finally purged. thx Khem etal.
Sep 12 11:28:20 <JaMa> ant_work: where is 2nd xserver?
Sep 12 11:28:41 <ant_work> xserver-nodm-init I meant. I gave up , you understand...
Sep 12 11:30:57 <JaMa> ok, because 2nd xserver was migrated to oe-core year ago http://git.openembedded.org/meta-openembedded/commit/meta-oe/recipes-graphics?id=d957e045c04e026e87d6325735c3e07029d32423
Sep 12 11:38:28 <rburton> ant_work: xi-calib sounds pretty core to me, no kdrive means the tslib stuff can disappear
Sep 12 11:39:24 <ant_work> rburton: tsilb/kdrive was dead then somehow revived...
Sep 12 11:39:28 <ant_work> :)
Sep 12 11:40:25 <ant_work> rburton: unfortunately the ATI IMAGEON W100 on our beloved corgi only had an x11 accelerated driver for kdrive
Sep 12 11:41:32 * rburton tries to remember what one corgi was
Sep 12 11:41:46 <ant_work> one Zaurus handheld
Sep 12 11:41:52 <rburton> yeah, i had an akita
Sep 12 11:42:01 <ant_work> former model serie
Sep 12 11:45:36 <ant_work> rburton: as you see, x11-common vs. xserver-common is where oe-core and meta-oe diverge. See RDEPS
Sep 12 11:46:11 <ant_work> (as for feature-set)
Sep 12 11:47:39 <JaMa> florian: ping about merging those xserver-common patches upstream :)
Sep 12 11:48:40 <JaMa> florian: fwiw I have one more since sending it (12 Apr 2012)
Sep 12 11:55:55 <RP> ant_work: Its not like the w100 driver actually did much acceleration wise though :)
Sep 12 11:55:59 <RP> er, :(
Sep 12 11:58:00 <ant_work> he he
Sep 12 12:05:29 <florian> JaMa: yep... I still have the mail open :)
Sep 12 12:31:11 <ignus> Hello all, im having this problem https://lists.yoctoproject.org/pipermail/yocto/2012-June/009289.html but I dont understand the fix, can anyone help?
Sep 12 12:34:10 <ignus> as in, how do I add something to DISTRO_FEATURES_LIBC_DEFAULT ?
Sep 12 12:39:27 <bluelightning> hi ignus
Sep 12 12:39:32 <bluelightning> hmm
Sep 12 12:40:57 <bluelightning> ignus: are you setting DISTRO_FEATURES in your custom distro config?
Sep 12 14:08:57 * rburton wonders if anyone will notice if he deletes libx11-diet
Sep 12 14:09:36 <JaMa> do it :)
Sep 12 14:09:52 <rburton> JaMa: just writing a mail
Sep 12 14:19:04 * ant_work hopes this time rburton will merge meta-oe recipe ;)
Sep 12 14:20:27 <JaMa> yes rburton looks like he knows what he is doing, so he will probably copy it fine :)
Sep 12 14:21:03 <ant_work> JaMa|Off: lol
Sep 12 14:37:20 <peachj_> I've got a task (for logging SRCREVs -- I think I'm finally getting this to work) that I want permuting the hash of as little as possible of the stuff that comes after it (preferably, it permutes nothing since it's a logging task).  What's the best way to insert the task into the task dependency graph?
Sep 12 15:01:58 <jwessel> bluelightning: Since you seem to be working on the hob at the moment.   Is there any way to get a variable to select the default MACHINE, instead of always forcing someone to select it?
Sep 12 15:02:08 <jwessel> That has been a constant source of pain for me.
Sep 12 15:15:34 <bluelightning> jwessel: I'll look into it - is it a variable you need though or could it just remember what you selected last?
Sep 12 15:15:51 <jwessel> I want to select it forcefully.
Sep 12 15:16:10 <bluelightning> jwessel: note that this would mean it would jump straight into parsing, but I assume that's what you want
Sep 12 15:16:10 <jwessel> If I have defined MACHINE and HOB_MACHINE in local.conf why would I ever even choose anything else?
Sep 12 15:16:34 <jwessel> You cannot do anything useful in the hob until you select a machine anyway.
Sep 12 15:16:56 <jwessel> And I always select the same machine 100% of the time for what I built the project for.
Sep 12 15:17:03 <bluelightning> currently the values of all of the settings from local.conf that hob is capable of configuring are ignored if set in local.conf
Sep 12 15:17:40 <jwessel> Well you can make it work anyway you like.
Sep 12 15:17:54 <jwessel> I just want to have the ability to specify a default machine.
Sep 12 15:18:24 <jwessel> There are other places in the hob code where it attempts to unset the machine to, like after an image or some such.
Sep 12 15:18:34 <jwessel> It just doesn't make any sense if you only have one machine you are targeting.
Sep 12 15:19:17 <jwessel> Generally speaking from a customer point of view (a WR customer) they will only ever build one device per project.
Sep 12 15:19:29 <bluelightning> so I can look at putting in a short-term fix, but ideally we would want to analyse the desired workflow in more detail for 1.4 and come up with some improvements
Sep 12 15:19:35 <bluelightning> right, I can understand that
Sep 12 15:20:00 <jwessel> And it is trouble some to always select it.   Especially if you accidentally select the wrong one (oh I have done that too) and then you get a full parse, and if you don't notice it till later, you will even get the wrong machine.
Sep 12 15:22:01 <bluelightning> jwessel: right, I have observed that issue myself
Sep 12 15:22:39 <jwessel> bluelightning: To me it seemed like a fairly straight forward simplification.
Sep 12 15:22:48 <jwessel> If you have HOB_MACHINE set in a conf, just use it.
Sep 12 15:22:52 <jwessel> Else do what it does today.
Sep 12 15:24:05 <bluelightning> jwessel: sure I can see that will solve the problem you are experiencing; but ideally we would want to not have people exit the tool in order to change aspects of its behaviour
Sep 12 15:24:25 <jwessel> well that is a separate problem.
Sep 12 15:25:04 <jwessel> I believe you can have the same behavior though where once you select  a machine, the UI just keeps using it.
Sep 12 15:25:32 <jwessel> I could forsee using the same code path to honor the default, being used.
Sep 12 15:26:08 <jwessel> bluelightning: You are talking about the case where you initially run HOB, and select a machine, and you'll get it back from then on.
Sep 12 15:26:32 <bluelightning> selecting the last value would be the easiest to implement as it stands rather than introducing HOB_MACHINE and then potentially removing it later once the problem is solved in a better way
Sep 12 15:26:58 <jwessel> I think we are talking about the same thing though.
Sep 12 15:27:20 <jwessel> If you always auto pick last machine, please allow me to set my "last machine" before starting the hob.
Sep 12 15:27:54 <jwessel> e.g Don't make me choose something, because I already know the answer in advance.
Sep 12 15:27:58 <bluelightning> let me see what I can come up with
Sep 12 15:28:31 <jwessel> bluelightning: Thanks!  That is probably the most un-smooth part of the hob, that looked the easiest to change.
Sep 12 15:29:01 <jwessel> There are other areas it could absolutely be improved, but we can talk about those separately.
Sep 12 15:36:46 <salquint> I'm dealing with a build error involving a configure that failed because a file wasn't found.  If I were just running ./configure to build something and it failed, I'd add the module and re-run. How is that dealt with in this environment?  From what I've read, it seems like dependencies are determined automatically, but if not, where do you set a depenency for another module?  ncurses is the dependency in this case.
Sep 12 15:37:33 <kergoth> grep is your friend
Sep 12 15:37:48 <kergoth> 90% of the recipes declare dependencies, read some
Sep 12 15:38:57 <salquint> grep is my friend, but I'm a newb and got a lot of results.  What files list recipe declarations?
Sep 12 15:39:08 <kergoth> ?
Sep 12 15:39:25 <kergoth> again, read a recipe. pick a .bb file and read it.
Sep 12 15:39:34 <kergoth> or just grep for DEPENDS, which is in the majorityo f recipes
Sep 12 15:39:39 <salquint> thanks
Sep 12 15:39:41 <salquint> .bb, that's what I was looking for
Sep 12 15:39:52 <kergoth> build dependencies are *not* automatic.
Sep 12 15:40:11 <salquint> and DEPENDS, thanks for that too
Sep 12 15:40:27 <kergoth> np
Sep 12 15:40:38 <salquint> So it automatically makes dependency directives based on DEPEND statements, is that more accurate?
Sep 12 15:41:23 <kergoth> no, it automatically sets *runtime* dependencie sin the binary packages based on what was really used, in particular cases. for example, if a binary links against a shared library, the shared library's package will be added to the binary's package's dependencies.
Sep 12 15:41:37 <kergoth> but to link against it during the build, you have to have it in DEPENDS, otherwise it wont' be built first
Sep 12 15:42:02 <kergoth> also, it works the other direction too
Sep 12 15:42:13 <salquint> thanks again, that was a lot clearer than the general page I found (no surprise)
Sep 12 15:42:17 <kergoth> if you have something that's needed to run, but not to build, bitbake knows to build both to ensure both binary packages are emitted
Sep 12 15:42:33 <kergoth> e.g. RDEPENDS_${PN} += "perl" for some perl script, it'll know to build perl when building an image that includes that package
Sep 12 15:43:17 <kergoth> (R meaning 'runtime', _${PN} meaning it's referring to the package of that name (pn is the recipe's name, basically)
Sep 12 15:44:04 <kergoth> obviously there's a lot going on in a typical build :)
Sep 12 15:44:13 <salquint> Is there a more detailed doc that describes this, or is it spread around?
Sep 12 15:44:47 <kergoth> the best docs i know of are at https://yoctoproject.org/documentation or on the wiki
Sep 12 15:44:56 <kergoth> but i'm honestly not sure how the coverage is
Sep 12 15:46:04 <salquint> ok
Sep 12 17:28:57 <msm> i have a patch for eglibc that's just for freescale parts, can I use an overrride from my layer for this?
Sep 12 17:29:17 <msm> SRC_URI_fslmachine += "somepatch.patch"
Sep 12 17:29:22 <msm> it will actually effect other powerpc parts
Sep 12 17:29:46 <bluelightning> msm: SRC_URI_append_fslmachine = " somepatch.patch"
Sep 12 17:29:51 <bluelightning> note leading space
Sep 12 17:30:48 <bluelightning> unfortunately += will not do what you hope it might when you use it in conjunction with an override since the two operations occur at different times during the parse process
Sep 12 17:31:51 <kergoth> msm: that adds to SRC_URI_fslmachine. then SRC_URI_fslmachine will replace SRC_URI. so unless SRC_URI_fslmachine already contains most of the sources, it won't do what you want, as bluelightning mentions :)
Sep 12 17:32:12 <kergoth>  hmm
Sep 12 17:32:21 <kergoth> http://theprofoundprogrammer.com/post/31404285177/text-debugging-will-continue-until-morale
Sep 12 17:33:43 <msm> right right...
Sep 12 17:33:47 <msm> append as well
Sep 12 17:33:55 <msm> just makign sure it's OK to add that override from our layer
Sep 12 17:33:58 <msm> it makes the most sense
Sep 12 17:34:16 <bluelightning> kergoth: hmm, looking at that website I wouldn't necessarily use the word "profound"
Sep 12 17:34:20 <bluelightning> kergoth: profane, perhaps
Sep 12 17:34:33 <kergoth> that doesn't surprise me. haven't looked anywhere but that one image
Sep 12 17:35:06 <seebs> Someone sent me a link to a hilarious and subtle comic about philosophy. And I thought "man, this is awesome" and decided to read more of the comic.
Sep 12 17:35:09 <kergoth> hmm, wonder how useful a build-appliance-image rootfs would be as a chroot. probably quite useful..
Sep 12 17:35:29 <seebs> Roughly 90% of the comic was NSFW, and I don't mean "minor cusswords".
Sep 12 17:35:34 <kergoth> yikes
Sep 12 17:35:38 <seebs> ... Admittedly, it stayed really funny, but I coulda used a warning.
Sep 12 17:36:18 <kergoth> http://www.exocomics.com/245 - this comic is somewhat entertaining and always cute, and never nsfw
Sep 12 17:36:38 <seebs> My spouse is on tumblr, though, so I'm basically jaded at this point.
Sep 12 17:37:17 <bluelightning> pidge_mobile: sorry to hear about your double tire blow-out...
Sep 12 17:37:51 <bluelightning> oh man... sorry... I meant "tyre"
Sep 12 17:37:59 <pidge_mobile> Hehe yeah and with a full tank of helium in the truck too.
Sep 12 17:38:17 <bluelightning> pidge_mobile: you sure do carry around some interesting stuff in that truck :)
Sep 12 17:39:39 <pidge_mobile> Hehe. I had just picked it up. Nothing like 110cf of compressed gas in uour front seat to make a 55 mph blow out a little more exciting
Sep 12 17:41:49 <pidge_mobile> Bluelightening: it's for a demo
Sep 12 17:44:12 <bluelightning> pidge_mobile: everything OK?
Sep 12 17:44:27 <bluelightning> other than the tyres of course...
Sep 12 17:44:38 <bluelightning> and the hassle
Sep 12 17:45:02 <pidge_mobile> Should be. Covering the tanks so they dont get warm.
Sep 12 17:48:19 <grifter188> pidge_mobile: I didn't catch if it was your front or back tire that blew?
Sep 12 17:49:20 <pidge_mobile> Grifter188. Front. The same one that blew last night. Pos spare.
Sep 12 17:49:54 <bluelightning> bbiab
Sep 12 17:50:56 <grifter188> ouch, well best of luck.  You call AAA or chaning the tire yourself?
Sep 12 17:51:58 <grifter188> ohh no spare? ...  if you're close to the office I'll come and pick up those tanks.
Sep 12 17:52:12 <pidge_mobile> I can't change it. It was the spare :(. Now i know why it lookef weird.
Sep 12 17:52:22 <grifter188> <--- Tim
Sep 12 17:52:31 <pidge_mobile> Grifter188. Nag
Sep 12 17:52:57 <pidge_mobile> Ha stupid phone.
Sep 12 17:53:01 <grifter188> ya
Sep 12 17:53:25 <pidge_mobile> Im in vsntucky. Ill get them in tomorrow
Sep 12 18:10:53 <peachj> I've got a logging task.  I want to insert it into the task graph for all packages in a way that won't cause any other tasks to re-run.  Is this possible?
Sep 12 18:11:18 <peachj> (Note: I'm pulling in the task by doing an "INHERIT += my_bb_class" in local.conf.  That's adding the task.)
Sep 12 18:12:29 <kergoth> addtask will result in sstate issues due to it being a part of the task graph. it sounds like you really want to just add a prefuncs or postfuncs
Sep 12 18:12:39 <kergoth> e.g. do_unpack[postfuncs] += "do_omsething_after_unpack"
Sep 12 18:12:41 * kergoth shrugs
Sep 12 18:15:13 <peachj> kergoth: Would it perhaps be best to do this as 'do_fetch[postfuncs] = "do_log_srcrev"', since logging SRCREVs is the specific purpose of this task?
Sep 12 18:15:26 <peachj> +=, sorry, not just =
Sep 12 18:15:31 <kergoth> that was an example
Sep 12 18:15:38 <kergoth> i didnt know or care which task happens to be involved
Sep 12 18:15:41 <kergoth> thats for you to decide
Sep 12 18:15:53 <kergoth> but yes, that sounds sane enough
Sep 12 18:17:48 <peachj> kergoth: Okay, I figured it was.  It was, in fact, a sanity check to make sure I was doing this right.  Perhaps I could even submit a patch, eventually, to fix bug 3041, which I logged.
Sep 12 18:18:50 <peachj> kergoth: Ah, crud.  I did forget about something.
Sep 12 18:19:21 <peachj> kergoth: I do need this maintained as part of sstate, I think, because I want to make sure this information gets recorded even on a cache hit.
Sep 12 18:20:18 <kergoth> that'd be an issue, yes
Sep 12 18:21:02 <peachj> kergoth: So...I'm left with no choice but to disrupt my hashes, I suppose?
Sep 12 18:21:23 <peachj> kergoth: If so, how can I minimize the damage?
Sep 12 18:22:23 <yao> is it possible to use PACKAGECONFIG_${PN}-xxx[yyy] in recipe?
Sep 12 18:23:23 <kergoth> yao: that'd be meaningless
Sep 12 18:23:31 <kergoth> packageconfig controls how the recipe builds
Sep 12 18:23:35 <kergoth> it has nothing to do with packaging
Sep 12 18:24:04 <yao> it also controls what is the dependency and rdepends, right?
Sep 12 18:25:17 <yao> and it will only add [r,]dependency to ${PN} I guess
Sep 12 19:04:12 <kergoth> it adds depends, not rdepends
Sep 12 19:07:14 <yao> kergoth: it will add rdepends to RDEPENDS_${PN} too, read base.bbclass
Sep 12 19:08:29 <kergoth> if you add elements to that portion of packageconfig, sure, but that's not the common case. if that's not sufficient to your needs, use base_contains with PAKCAGECONFIG yourself
Sep 12 19:10:18 <yao> thanks kergoth, I just want to make sure PACKAGECONFIG doesn't support _${PN} form, that is all, use other ways will do it for sure
Sep 12 19:13:27 <kergoth> though it alters rdepends, the variable itself is intended to function at the recipe level, so yeah, not that i know of
Sep 12 19:13:59 * kergoth ponders
Sep 12 19:24:50 <yao> kergoth: how does the "RDEPENDS" works? all sub packages will have those RDEPENDS ?
Sep 12 20:01:04 <msm> so if i want to always enable multiarch in a particular machine, how should I handle this
Sep 12 20:01:09 <msm> right now its a DISTRO_FEATURE
Sep 12 20:01:50 <sakoman> has there been a name chosen yet for the upcoming release? (i.e. like denzil was for the last release)
Sep 12 20:02:10 <msm> seems like i could just do a few EXTRA_OECONF_pn-{gcc,binutils,gdb} in my machine.conf file to manually enforce it
Sep 12 20:02:14 <fray> RP has a few in mind, but I don't believe one has been choosen yet
Sep 12 20:02:22 <fray> (and he wouldn't tell me what they are)  ;)
Sep 12 20:02:30 <msm> it needs a name
Sep 12 20:02:35 <msm> im tired of calling it master ;)
Sep 12 20:02:57 <msm> the next name should be decided after a release ;)
Sep 12 20:03:12 <msm> right now it's yocto 1.3 which conflicts with other versions ;)
Sep 12 20:03:31 <sakoman> just want to name my testing branch and figured I would use the code name if it was chosen yet
Sep 12 20:04:02 <sakoman> but "next" should work fine for now
Sep 12 20:04:16 <fray> thats more or less what I've been calling it  'next' or 'master'
Sep 12 20:31:11 <khem> fray: I am seeing some problems with rfs creation today's master
Sep 12 20:31:20 <khem> rpm is giving me some errors
Sep 12 20:31:35 <fray> nothing has changed there recently..
Sep 12 20:31:38 <fray> what is the error?
Sep 12 20:31:43 <khem> like http://pastebin.com/DLf1GEd9
Sep 12 20:31:48 <fray> (wait, someone did change the arch generated on a few targets)
Sep 12 20:31:52 <khem> fray: difference is I have enabled multilib
Sep 12 20:32:21 <khem> my target is x86_64
Sep 12 20:32:22 <fray> that dependency is 'real'... it means something in there likely has a /usr/bin/env foo  enabled script..
Sep 12 20:32:33 <fray> but nothign (busybox) or coreutils is providing /usr/bin/env..
Sep 12 20:34:27 <fray> most likely if the thing that the script in libevent needs is python or perl or similar..  and that rdepend is missing.. fix that, and the /usr/bin/env is likely to shift to the right provider.. if it doesn't.. it's likely something we should fix there
Sep 12 20:34:41 <fray> (i.e. all python stuff should be invoked w/ /usr/bin/env python...)
Sep 12 20:34:46 <khem> I wonder why its complaining now
Sep 12 20:34:59 <khem> it has not been complaining until now
Sep 12 20:35:44 <fray> "something" changed in that package or another triggering that thing to not be built..
Sep 12 20:35:49 <fray> did someone disable a busybox feature?
Sep 12 20:36:19 <khem> hmm need to check
Sep 12 20:36:32 <khem> I am having busybox pulled in into recipe though
Sep 12 20:36:45 <fray> ya, if busybox builds, it -should- contain env
Sep 12 20:38:22 <khem> let me check
Sep 12 20:40:00 <khem> fray: http://pastebin.com/zMM4jLib
Sep 12 20:40:11 <khem> somehow busybox is not there
Sep 12 20:40:23 <khem> rpm should have listed it there
Sep 12 20:40:25 <khem> right
Sep 12 20:40:37 <fray> rpm -qlp <busybox package>  --- is /usr/bin/env in the list?
Sep 12 20:41:06 <fray> khem, that processing list only covers the items int he INSTALL_IMAGE.. if busybox is required, it won't be listed there, it'll come in another way
Sep 12 20:41:10 <fray> (via the dep resolver)
Sep 12 20:47:39 <khem> fray: let me check
Sep 12 20:54:48 <khem> fray: I am apalled busybox is not built at all
Sep 12 20:55:07 <khem> sometimes its good to clean your tmp
Sep 12 21:00:05 <fray> check for coreutils and util-linux then..
Sep 12 21:03:55 <khem> fray: ok got it was the task->packagegroup renaming debacle in internal layers
Sep 12 21:04:30 <khem> fray: btw. I would prefer to remove busybox from one kind of images have you done that kind of stuff
Sep 12 21:04:43 <khem> not use busybox at all
Sep 12 21:06:52 <fray> it's been a while, but yes.. it should be possible
Sep 12 21:09:00 <msm> so let's say i want to add support for more ppc targets to runqemu
Sep 12 21:09:01 <sgw> msm:  nice catch, probably would not have caught it with our build testing.
Sep 12 21:09:26 <msm> do i just start making qemuppc{e500v2,e500mc,e5500} ?
Sep 12 21:09:35 <msm> sgw: yea, i only caught it during a build test...
Sep 12 21:10:46 <msm> sgw: we may start producing a cheap p5020 board soon, maybe we can add it ;)
Sep 12 21:11:29 <sgw> msm would that be a replacement for the mpc board as a meta-yocto bsp?
Sep 12 21:11:46 <msm> sgw: i dunno
Sep 12 21:11:56 <msm> sgw: its 32 and 64bit
Sep 12 21:12:01 <msm> more could be tested with it
Sep 12 21:12:16 <msm> not sure how many mpc83xx are aroun
Sep 12 21:12:45 <sgw> msm: cool, what did you want to add to runqemu?  Seems that it needs to be manged by distros / bsp layers also
Sep 12 21:13:08 <msm> sgw: well just more targets
Sep 12 21:13:09 <sgw> msm: right, something to bring up with RP
Sep 12 21:13:15 <msm> qemuppc seems to be mpc83xx right now
Sep 12 21:14:14 <msm> would be nice if i only needed changes to a layer to add a new runqemu target
Sep 12 21:16:04 <sgw> zeddii: speaking of mpc! Seems your recent kernel change is give mpc fits: http://autobuilder.yoctoproject.org:8010/builders/nightly-ppc/builds/598/steps/shell_52/logs/stdio
Sep 12 21:16:31 <sgw> msm: not sure if you can help with ^^^^
Sep 12 21:27:31 <msm> what's an mpc8315?
Sep 12 21:27:35 <msm> ;o
Sep 12 21:36:43 <khem> msm: I have a layer called meta-qemuextra
Sep 12 21:36:54 <khem> where I have put SH4 and MIPS64 compiler
Sep 12 21:36:57 <khem> err qemu
Sep 12 21:37:02 <khem> machine confs
Sep 12 21:37:28 <khem> msm: you could also model along the lines in OE-Core itself
Sep 12 21:37:35 <khem> see how arm is done
Sep 12 21:37:59 <khem> I mean in runqemu
Sep 12 21:40:03 <msm> where is this layer?
Sep 12 21:41:57 <msm> is it just this: http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=kraj/mips64
Sep 12 21:42:26 <khem> its not pushed anywhere
Sep 12 21:42:36 <khem> I think I did not have enough time
Sep 12 21:42:41 <khem> to put it somewhere
Sep 12 21:42:51 <khem> I can push it to my github tonight
Sep 12 21:43:53 <khem> sgw: uprobes are probably disabled in .config
Sep 12 21:51:24 <sgw> khem: hmm, zeddii just sent a patch for uprobes, I wonder what happened.
Sep 12 21:53:57 <Crofton> there is  a special place in hell for people who desgin boards different from the eval board
Sep 12 22:36:15 <kergoth> hmm, looks like there's an exception we need to catch to spot a different area of cache corruptiono - https://gist.github.com/3710487
Sep 12 22:39:17 <khem> sgw: hmm ok
Sep 12 22:39:25 <khem> Crofton: yes: )
Sep 12 22:39:42 <khem> Crofton: like C programmers dont die they get casted to void :)
Sep 12 22:39:50 <Crofton> yes
Sep 12 22:40:32 <khem> I deal with this everyday where it works on eval board but does not work on real shipping HW
Sep 12 22:46:58 <ant__> khem: collie/Armv4t still not booting properly...debugging kernel now :/
Sep 12 22:49:14 <khem> ant__: OK, I will be interested in fixing it
Sep 12 22:49:25 <khem> ant__: if you give me good inputs
Sep 12 22:51:18 <ant__> khem: sure, thx
Sep 12 22:51:56 <khem> ant__: is it kernel failure
Sep 12 22:52:12 <khem> ant__: or userspace
Sep 12 22:52:38 <ant__> right. again, userspace is klibc so atm no-thumb
Sep 12 22:52:57 <Crofton> ant__, are you going to ELCE?
Sep 12 22:52:59 <ant__> and the binary is ok on armv5te
Sep 12 22:53:16 <khem> I will be at ELCE btw :)
Sep 12 22:53:26 <Crofton> I saw
Sep 12 22:53:29 <Crofton> that will be fun
Sep 12 22:53:33 <ant__> Crofton: yes, I'll have to be in Koeln on 9. though :/
Sep 12 22:53:36 <khem> ant__: that sounds a real problem
Sep 12 22:53:45 <khem> Crofton: we can book same flights from JFK :)
Sep 12 22:53:59 <khem> Oh cologne :)
Sep 12 22:54:00 <Crofton> I'll go via philly or Charlotte
Sep 12 22:54:11 <Crofton> cool
Sep 12 22:54:23 <khem> ant__: send me the offending binary
Sep 12 22:54:28 <khem> let me disassemble it
Sep 12 22:54:34 <khem> and please with debug info and symbols
Sep 12 22:54:43 <khem> Crofton: I will head to India from there
Sep 12 22:55:06 <khem> so instead of stopping in F'furt or Amsterdam I am taking 3 day pit stop
Sep 12 22:55:14 <khem> at B'lona
Sep 12 22:56:44 <khem> ant__: also send me compiler commandline that was used to compile this binary
Sep 12 23:06:39 <ant__> khem: let us doublee-check it's not a kernel bug :/
Sep 12 23:10:07 <khem> ant__: hmmm ok
Sep 13 00:30:46 <salquint> Hi folks, I need some advice.  I'm chasing a bug where expat doesn't always build due to not finding ncurses_config when packages are built in parallel.  It's an easy fix if I add DEPENDS += "ncurses" to the expat recipe file, but expat doesn't use ncurses as far as I can tell.  I've been grep'ing CONFIG_SITE, sniffing around autoconf, and generally following mazes (I'm a newb).  Any suggestions would be appreciated.
**** ENDING LOGGING AT Thu Sep 13 03:00:00 2012

**** BEGIN LOGGING AT Thu Sep 13 03:00:00 2012
Sep 13 07:28:11 <Gintaro> I'm having some issues with the opkg index, almost every built package get's moved to the morgue instead of being incorporated in the index
Sep 13 07:50:52 <Gintaro> Hmmm, for some reason opkg can't properly determine the arch and name of the packages
Sep 13 07:56:35 <Gintaro> ah, fixed, for some reason it was choosing python 3 instead of 2
Sep 13 08:14:59 <ant_work> khem: I see I missed the patch for kernel compiler ... there is still little hope
Sep 13 08:31:42 <tarek_> Hi I have a problem with playing h264, mpeg2 or mpeg4 with gstreamer can anyone help?
Sep 13 08:51:03 <bluelightning> morning all
Sep 13 12:33:15 <bilboed> any pointers to debug a kernel not booting on pandaboard ? I essentially followed these instructions : https://maniacbug.wordpress.com/2012/08/03/pandayocto/
Sep 13 12:33:25 <bilboed> but I get this at boot : http://pastebin.com/1Uk9m4LZ
Sep 13 12:33:33 <bilboed> i.e ... the kernel gets loaded ... but doesn't start
Sep 13 19:33:19 <sgw> zeddii: ping!
Sep 13 19:50:28 <zecke> sgw: did you get my initial FreeBSD patches for pseudo?
Sep 13 19:51:23 <fray> zecke, have you worked w/ seebs?  he is the maintainer of pseudo
Sep 13 19:51:36 <seebs> I got those, I haven't had a chance to do anything with them yet.
Sep 13 19:51:52 <seebs> I expect I will have a few cycles in October or so.
Sep 13 20:35:57 <fray> I'm trying to register for ELC-E..  but I don't have the 'staff' code for the Yocto Project Developer Day
Sep 13 20:36:19 <fray> anyone happen to know wht that is?
Sep 13 20:37:39 <fray> Hmm apparently leaving it blank isn't fatal.. :)
Sep 13 21:18:05 <Crofton> fray, ask jefro
Sep 13 21:18:17 <Crofton> I ignored it and talke to him to sort things out :)
Sep 13 21:45:21 <msm`> cleanup-workdir appears to skip over work-shared
Sep 13 21:55:58 <msm`> khem, do you know libgcc.a actual dependencies?
Sep 13 21:56:08 <msm`> just libc?
Sep 13 21:59:21 <seebs> Other way around, really.
Sep 13 21:59:33 <seebs> There is stuff you can build with libgcc and no libc. There is not much you can do without libgcc.
Sep 13 22:06:21 <msm`> seebs: hmm, ok
Sep 13 22:06:31 <msm`> seebs: i guess that makes sense
Sep 13 22:06:47 <msm`> i have a 32/64 bit compiler with a 64-bit libgcc.a
Sep 13 22:06:58 <seebs> You need both libgcc's, usually.
Sep 13 22:07:03 <msm`> but no 32-bit libgcc.a so it's somewhat problematic
Sep 13 22:07:39 <msm`> right… my 64-bit toolchain can't quite compile some things
Sep 13 22:07:48 <msm`> some things that need libgcc.a and not even lib c
Sep 13 22:07:53 <msm`> libc*
Sep 13 22:07:54 <seebs> Yeah. Configuring gcc to build for more than one target is Fancy Stuff. Not impossible, but takes some effort.
Sep 13 22:08:00 <msm`> u-boot for example
Sep 13 22:08:17 <msm`> well the biarch bits are working, and it's generating code OK
Sep 13 22:08:49 <msm`> just it generates code that references inline assembly usually provided by a 32-bit libgcc.a
Sep 13 22:09:15 <seebs> Yeah.
Sep 13 22:10:07 * msm` does not want to learn about gcc
Sep 13 22:10:11 * msm` sigh
Sep 13 22:11:24 <seebs> Code Sourcery sells toolchains pretty much for exactly that reason. :P
Sep 13 22:13:05 <msm`> you think we would hire someone ;)
Sep 13 22:20:18 <seebs> I'm crazy, I actually *like* toolchain stuff.
Sep 13 22:40:47 <msm`> what builds libgcc for gcc-cross?
Sep 13 22:41:20 <msm`> i see a libgcc recipe but it only BBCLASSEXTEND nativesdk
Sep 13 22:43:28 <seebs> I would assume that libgcc would get built as part of gcc, since it's a gcc internal.
Sep 13 22:43:48 <kergoth> wtf, why did pixman get sucked into my core-image-base build
Sep 13 22:43:51 * kergoth mutters
Sep 13 22:44:09 <sgw> kergoth: really?
Sep 13 22:44:45 <msm`> seebs: it seems like it depends on a header from libc
Sep 13 22:44:46 <msm`> gnu/stubs-32.h
Sep 13 22:44:55 <seebs> The bootstrapping order is fancy.
Sep 13 22:45:18 <msm`> which means you need both 32 and 64
Sep 13 22:45:37 <seebs> There's a multi-phase build process. I think you start with minimal headers, then build a minimal gcc, then use that to build a little bit of gcc, then use that to do some libc stuff, then do a full gcc, then a full glibc.
Sep 13 22:46:31 <msm`> seebs: i knew this
Sep 13 22:46:45 <msm`> seebs: so my previous state was correct, libgcc depends on libc (headers at least)
Sep 13 22:46:50 <seebs> ahhh, yes.
Sep 13 22:47:13 <seebs> I was thinking libc as in libc-version.so.
Sep 13 23:26:36 <kergoth> "Getting branches from remote repo None..."
Sep 13 23:26:40 <kergoth> anyone seen this one with yocto-bsp?
Sep 14 00:36:12 <msm`> seebs: what's more annoying is you need to generate gnu/stubs-32.h so it's tricky
Sep 14 00:36:22 <seebs> Yes, yes it is.
Sep 14 00:36:56 <seebs> Some years back, I put about two or three days into trying to successfully bootstrap a cross compiler by hand. I failed. I might have a chance now. :)
Sep 14 01:28:25 <msm`> seebs: why not just ask khem ;)
Sep 14 01:28:28 <msm`> te he he
**** ENDING LOGGING AT Fri Sep 14 02:59:59 2012

**** BEGIN LOGGING AT Fri Sep 14 02:59:59 2012
Sep 14 04:12:49 <msm`> anyone awake?
Sep 14 04:50:16 <msm`> RP: bitbake —dry-run does not work too well with the new knotty
Sep 14 07:04:58 <RP> msm`: hmm :/
Sep 14 07:56:34 <mertsas> how can I add my own licenses? I tried making a licenses.conf in my layers conf directory, which adds LICENSE_PATH += "${LAYERDIR}/files/licenses", but it still complains about there not existing generic license files. Works if I put the license file in oe-core/meta/files/common-licenses, so seems like it's the config file that is not picked up or wrong
Sep 14 07:59:15 <evanp> mertsas: try putting that in your layer.conf instead of licenses.conf, I don't think it looks at the latter
Sep 14 07:59:25 <mertsas> ok
Sep 14 08:00:34 <bluelightning> mertsas: looking at the code, I think it's reading LICENSE_DIR instead of LICENSE_PATH
Sep 14 08:00:43 <bluelightning> which is probably not correct...
Sep 14 08:01:54 <mertsas> bluelightning: according to licenses.conf in oe-core/meta/conf it sais LICENSE_PATH. I'll try changing it, and see if it works
Sep 14 08:02:34 <bluelightning> mertsas: yes, unfortunately that's the only reference anywhere to that variable
Sep 14 08:02:40 <mertsas> evanp: according to http://patches.openembedded.org/patch/16337/ it seems to me like it should pick up licenses.conf, reading point 5
Sep 14 08:03:04 <mertsas> ok bluelightning, seems like that might be an error there then.
Sep 14 08:03:23 <bluelightning> mertsas: indeed, I'm going to file a bug about this
Sep 14 08:03:52 <mertsas> bluelightning: do you know if it picks up licenses.conf as well, or does it only pick up local.conf?
Sep 14 08:04:52 <bluelightning> mertsas: I don't see a reference anywhere to that conf file so I suspect it won't be picked up
Sep 14 08:04:56 <bluelightning> another issue to fix...
Sep 14 08:05:06 <mertsas> ok, thanks
Sep 14 08:05:15 <evanp> mertsas: I meant that it might not look for one in your layer, but rather only the one in the poky repo...actually I can't find a "require license.conf" anywhere in the code at all...
Sep 14 08:06:56 <mertsas> evanp: ok, but true. No referene at all to licenses.conf. Strange
Sep 14 08:10:53 <mertsas> but thank you evanp and bluelightning. Putting it in local.conf and changing to LICENSE_DIR worked
Sep 14 08:11:04 <mertsas> now I can get rid of some annoying warnings:D
Sep 14 08:11:27 <bluelightning> mertsas: great! I'll file a bug to make sure we get this inconstency fixed up
Sep 14 08:12:13 <mertsas> nice, thanks
Sep 14 10:44:25 <ignus> Hello all, does anyone know if there is a (smaller) alternative to udev?
Sep 14 10:52:30 <el_robin_> ignus: maybe you can look at mdev
Sep 14 10:54:20 <bluelightning> ignus: hi - indeed, busybox's mdev would be a possibility
Sep 14 10:54:50 <bluelightning> ignus: another possibility is a pre-populated static /dev
Sep 14 10:55:25 <bluelightning> if you never expect to plug anything into the device and have it dynamically picked up, that could work
Sep 14 10:57:32 <ignus> i think we do need it to be dynamic, which udev does very well but i think its just too big (including all the things it depends on)
Sep 14 10:57:56 <bluelightning> ok, then mdev is possibly the only other option
Sep 14 10:58:06 <ignus> ill go have a look at mdev so, thanks!
Sep 14 12:10:48 <fsarbu> hello guys
Sep 14 12:10:58 <ag_> Hello fsarbu
Sep 14 12:11:21 * ag_ greets fsarbu 
Sep 14 12:11:27 <fsarbu> rburton, if you have some time I would like to ask you something about a commit I saw you made
Sep 14 12:12:11 <fsarbu> rburton, relatd to xserver and the split of modules in separate packages
Sep 14 12:12:23 <RP> bluelightning, ignus: is devtmpfs another option?
Sep 14 12:13:53 <fsarbu> rburton, RREPLACES_${PN}-module-exa = "${PN}" - what this does is that I end up having the xserver-xorg-module-exa actually providing xserver-xorg so in the rootfs the actual xserver-xorg rpm won't get installed
Sep 14 12:15:33 <fsarbu> ag_, hello
Sep 14 12:15:48 <fsarbu> ag_: how are you doing?
Sep 14 12:16:49 <ag_> fsarbu: :) rburton will help you with that. Do you have a preferred virtual/xserver?
Sep 14 12:17:25 <ignus> RP: that was suggested by DH as well but I know nothing about it, do you know of any good documentation I can look at?
Sep 14 12:17:50 <RP> ignus: offhand, no, sorry :/
Sep 14 12:18:04 <fsarbu> rburton: to mee, it looks like that RREPLACES does not fit in there and can be removed from the recipe
Sep 14 12:18:39 <fsarbu> RP: hi, any thoughts on the matter until rburton comes online? :)
Sep 14 12:19:42 <RP> fsarbu: I can see how the package manager is getting confused here. I have a worry we need this line for opkg but it breaks rpm :/
Sep 14 12:21:04 <ag_> RP: So this is broken now? Would a preferred provider virtual/xserver be a solution here?
Sep 14 12:24:48 <RP> ag_: no, virtual providers don't work at the package manager level
Sep 14 12:27:45 <fsarbu> RP: can you give me a hint how I could fix this? I was thinking, since I already have a .bbappend for xserver-xorg, I could "reverse" this in my xserver-xorg like this: RREPLACES_${PN} = "${PN}-module-exa"
Sep 14 12:27:54 <fsarbu> RP: as a quick hack :)
Sep 14 12:40:09 <fsarbu> that does not work unfortunately
Sep 14 13:13:42 <RP> fsarbu: A quick hack would be RREPLACES_${PN}-module-exa = ""
Sep 14 13:14:11 <RP> fsarbu: I think its going to need some detailed investigation of the package managers and I'm no expert in that part of them
Sep 14 13:53:09 <fsarbu> RP: thanks, that seems to do the trick
Sep 14 14:47:09 <kergoth> has anyone ever successfully made use of yocto-bsp from master?
Sep 14 14:50:54 <bluelightning> kergoth: tomz probably (although he's not online atm)
Sep 14 14:51:59 <kergoth> hmm, k, will pester him later, thanks
Sep 14 14:52:05 <kergoth> keep getting tracebacks and such
Sep 14 14:52:15 <bluelightning> kergoth: btw, do you have a reproducer for https://gist.github.com/3710487 ?
Sep 14 14:55:52 <kergoth> sadly not handy, i'll have to wait until it shows up again. i'm guessing the cache file gets truncated early by a ^C interruption during the save
Sep 14 14:56:22 <bluelightning> ok, let me know if you do find it, and I'll investigate
Sep 14 14:57:15 <kergoth> will do. its on my todo, haven't had the spare time to dig into it yet. thanks
Sep 14 15:01:45 <kergoth> seebs: do you have a current branch/patch for the var/include tracking? i swear i asked you before, but i can't find it
Sep 14 15:17:00 <ag_> Anybody saw this lately? sysroots/i686-linux/usr/bin/../../usr/lib/libospgrove.so.0: undefined symbol: _ZN14OpenJade_Grove8ClassDef12sgmlDocumentE
Sep 14 15:18:54 <bluelightning> ag_: someone else was complaining about that previously a couple of weeks ago in here or in #oe I think
Sep 14 15:20:34 <sgw> ag_: Is this simimar to bug 2972?
Sep 14 15:20:43 <bluelightning> ah yes I just found that too
Sep 14 15:20:54 <bluelightning> that was the bug reported by the user after our IRC discussion
Sep 14 15:21:31 <sgw> ag_: we just triaged, I grabbed it, but would be more than happy to have someone else look at it
Sep 14 15:21:48 <ag_> sgw: bluelightning Wanna hear something nice?
Sep 14 15:21:59 <sgw> sure
Sep 14 15:22:01 <ag_> i am not on x86_64.
Sep 14 15:22:24 <msm`> RP: 	did you see my comment last night about bitbake and —dry-run with the new knotty?
Sep 14 15:22:46 <bluelightning> ag_: I guess the reporter just made an assumption that it was an x86_64 issue
Sep 14 15:23:28 <bluelightning> msm`: I noticed that too
Sep 14 15:24:15 <bluelightning> msm`: you can pipe it through cat as a workaround
Sep 14 15:26:24 <msm`> bluelightning: yea, no big deal i wanted to make it known
Sep 14 15:26:57 <msm`> maybe i should file a bug
Sep 14 15:27:08 <bluelightning> msm`: seems reasonable
Sep 14 15:27:54 <bluelightning> msm`: if you could mention what you're using dry-run to achieve (I'm guessing to see which tasks are going to be executed?) that would be helpful as well
Sep 14 15:28:35 <msm`> bluelightning: pretty much
Sep 14 15:47:05 <RP> msm`: I did see the comment, yes. I'm just not sure how best to make the UI more useful in this area
Sep 14 15:49:54 <msm`> well the problem is
Sep 14 15:50:13 <msm`> i do a dry-run and go away, and come back and i don't see what would have been run, sort of defeating the purpose
Sep 14 15:50:22 <msm`> maybe, that's not worth just piping the output
Sep 14 15:50:28 <msm`> not worth the pain*
Sep 14 15:55:21 <_julian> hi
Sep 14 15:55:58 <_julian> if I want to setup the environment for continuing work on an existing build tree I would jusst do . oe-init-build-env my-build again? or would this overwrite the configuration?
Sep 14 15:56:48 <msm`> so, i have a question
Sep 14 15:56:51 <msm`> or a thought
Sep 14 15:56:54 <bluelightning> _julian: you can run it again, it only creates the config files if they don't yet exist
Sep 14 15:57:01 <_julian> bluelightning: ok. thanks
Sep 14 15:57:01 <bluelightning> msm`: shoot
Sep 14 15:57:22 <msm`> would it not be better to merge a XYZ_FEATURES into one VAR_FEATURES bit that way we can let machines add features they might require
Sep 14 15:57:30 <msm`> and instead of open coding DISTRO_FEATURES into recipes themselves
Sep 14 15:57:45 <msm`> for example, we really need a multiarch DISTRO_FEATURE to always be enabled for a particular machine
Sep 14 15:57:57 <msm`> so, what do we do… modify DISTRO_FEATURE in our machine.conf
Sep 14 15:58:00 <msm`> which is confusing
Sep 14 15:58:41 <msm`> this commit should sum it up
Sep 14 15:58:41 <msm`> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-ppc/commit/?id=f3469d97cef7fcd6277dfab7326f7a8e0d5bb5bd
Sep 14 15:58:44 <bluelightning> so, you should never ever be setting DISTRO_FEATURES in a machine configuration, ever
Sep 14 15:59:30 <bluelightning> if you are it may indicate either you need to actually have your own distro configuration, or there is a machine element to the item being configured, in which case we need to look at configuring it a different way (i.e. putting it within the control of MACHINE_FEATURES)
Sep 14 16:00:14 <kergoth> task-base is a good example of machine/distro feature interaction
Sep 14 16:00:16 <msm`> bluelightning: well then this particular bit is not distro specific anymore
Sep 14 16:00:18 <kergoth> or rather packagegroup-base
Sep 14 16:01:32 <msm`> heh COMBINED_FEATURES already exists
Sep 14 16:02:01 <msm`> so… im still wondering how to properly solve this problem
Sep 14 16:02:09 <msm`> is multiarch not a DISTRO_FEATURE?
Sep 14 16:02:12 <msm`> or is it?
Sep 14 16:02:25 * kergoth shrugs
Sep 14 16:02:54 <bluelightning> msm`: I don't have a good understanding of what multiarch in DISTRO_FEATURES does, myself
Sep 14 16:03:17 <msm`> bluelightning: it let's a 32-bit toolchain also build 64-bit stuff
Sep 14 16:03:35 <msm`> bluelightning: sans, libc.. so with it enabled for example I can build a 64-bit kernel on a 32-bit machine
Sep 14 16:03:55 <msm`> bluelightning: and one of our machines won't fully support a 32-bit kernel with a 32-bit root fs so the kernel always needs to be 64-bit
Sep 14 16:04:32 <bluelightning> right, this does sound like a case where this being a DISTRO_FEATURES switch isn't quite right
Sep 14 16:10:11 <jwessel> msm`: I have a whole series of patches to the knotty.py which allow it to work in the whole mode via env var or change the behavior dynamically.
Sep 14 16:10:22 <jwessel> I was going to try to post them today.
Sep 14 16:10:52 <jwessel> If in the --dry-run mode you could elect to toggle the flag to not do the squashed output, or just redirect as RP pointed out.
Sep 14 16:15:55 <RP> msm`: I'd much rather you errored out with a message about the distro needing to support that to use the machine
Sep 14 16:17:12 <msm`> RP: that's a decent option, but why error out when it's required?
Sep 14 16:17:37 <RP> msm`: I'd rather tell the user the distro is broken than silently change distro_features from under them
Sep 14 16:17:39 <msm`> RP: I can backhanded add all these bits via bbappends too, which seems like a waste of effort
Sep 14 16:18:12 <msm`> RP: but its not broken really, the toolchain should just include this
Sep 14 16:18:20 <msm`> RP: lol fine line I suppose
Sep 14 16:18:34 <RP> msm`: distro is all about policy. Your machine wants to change that policy
Sep 14 16:18:49 <RP> msm`: Presumably the distro author picked the policy for some reason
Sep 14 16:19:15 <seebs> kergoth: I don't think I have anything more recent than the seebs/ntracking (?) branch on contrib. I keep wanting to get back to that for a rewrite...
Sep 14 16:19:28 <RP> msm`: I'm having the same discussion over meta-intel and opengl
Sep 14 16:19:30 <kergoth> ah, right, forgot about that branch. that's a start
Sep 14 16:19:33 <kergoth> k
Sep 14 16:19:37 <RP> msm`: nobody would use machine X without GL, right?
Sep 14 16:19:39 <msm`> RP: yea, but then they have to enable that for the distro and it will effect ALL boards not just this one
Sep 14 16:19:51 <msm`> RP: i mean they could add a specific exception for our one board, but it seems wrong to me
Sep 14 16:19:52 <RP> msm`: not necessarily
Sep 14 16:20:09 <RP> msm`: the point is distro policy should be set by the distro
Sep 14 16:20:37 <RP> msm`: if you set a distro policy of no GL, then some machine decides to turn it on, are you going to be happy?
Sep 14 16:20:37 <msm`> RP: the other thing I don't want is for poky users to have to add this each time, so can we add it to the poky default policy?
Sep 14 16:20:49 <RP> I appreciate in this case its slightly more clearcut as it won't build
Sep 14 16:20:58 <msm`> RP: if it's required to build a kernel for the machine, i have no option, then build it
Sep 14 16:21:23 <msm`> RP: if i don't enable it, i can't build a kernel
Sep 14 16:21:43 <RP> msm`: I don't care, this needs to error
Sep 14 16:21:57 <RP> msm`: We can't condone changing DISTRO_FEATURES in a machine config
Sep 14 16:22:08 <RP> msm`: and yes, lets talk about changing the poky defaults
Sep 14 16:22:22 <msm`> RP: well, then maybe it's not a DISTRO_FEATURE in this case?
Sep 14 16:22:34 <RP> msm`: Its policy
Sep 14 16:23:23 <RP> msm`: This is the problem with all the feature controls. Some don't work together. The correct thing to do is sanity check the options and just tell the user if a given combination won't work/is insane etc
Sep 14 16:24:03 <msm`> RP: perhaps just skipping the kernel recipe if it's not enabled
Sep 14 16:24:38 <RP> msm`: a skip error from the kernel recipe if its not enabled would be fine
Sep 14 16:25:14 <msm`> RP: is a full blown multilib toolchain (libc, libgcc, etc) on the books anytime?
Sep 14 16:25:16 <RP> those cascade nicely if needed
Sep 14 16:25:26 <RP> msm`: there is an open bug about this
Sep 14 16:25:29 <msm`> RP: i remember nitin submitted patches last feb.
Sep 14 16:25:37 <RP> msm`: people keep working on it  but its hard and nobody has made it work yet
Sep 14 16:25:49 <RP> msm`: its not for want of trying :/
Sep 14 16:26:01 <msm`> RP: oh i understand
Sep 14 16:26:13 <msm`> RP: not complaining, i wish we had people to look at it ourselves
Sep 14 16:26:44 <msm`> RP: so for poky, multiarch for all or just the ones I want?
Sep 14 16:26:47 <RP> msm`: Its not going to make 1.3 at this point
Sep 14 16:27:04 <RP> msm`: I'm tempted to say for all...
Sep 14 16:27:14 * RP wonders what this will break
Sep 14 16:27:16 <msm`> RP: it's the logical step
Sep 14 16:27:27 <RP> msm`: what, worse build time?
Sep 14 16:27:34 <RP> totally logical
Sep 14 16:28:06 <RP> msm`: I just mean that no, there are downsides...
Sep 14 16:31:48 <msm`> RP: ill file a bug for 1.4 then
Sep 14 16:32:10 <msm`> RP: what do you think about turning on multilib by default too?
Sep 14 16:32:54 <msm`> RP: then we can start to have recipes with DEPENDS that include multilib bits
Sep 14 16:32:54 <RP> msm`: "turn on" in what sense?
Sep 14 16:33:10 <RP> msm`: what kind of recipe are you thinking off?
Sep 14 16:33:22 <msm`> well our u-boot recipe is a mess too
Sep 14 16:33:32 <msm`> for similiar reasons to this multiarch business
Sep 14 16:33:37 <msm`> our 64-bit machines build 32-bit u-boots
Sep 14 16:33:43 <msm`> and we need a 32-bit libgcc to build it
Sep 14 16:33:52 <msm`> which is not built by default
Sep 14 16:34:00 <msm`> and it seems like it would be a pain
Sep 14 16:34:08 <msm`> because we need some 32-bit libc bits to build the 32-bit libgcc
Sep 14 16:34:13 <msm`> so fourth and so on
Sep 14 16:34:22 <msm`> so we use multilib instead (which has it's own issues)
Sep 14 16:34:46 <msm`> mostly that it increases the build time a lot, because it's building another toolchain just for this 32-bit u-boot
Sep 14 16:34:59 <RP> multilib on by default is rather more painful in parse time alone
Sep 14 16:35:14 <msm`> RP: but just parse time, no effect after that?
Sep 14 16:35:47 <RP> we could probably include the multilib.conf file by default as I guess no extra extensions happen unless you ask for them
Sep 14 16:35:58 <RP> msm`: not really unless you build bits of it
Sep 14 16:36:27 <RP> msm`: The parse overhead isn't insignificant though (as is the hit on runqueue/task generation)
Sep 14 16:46:17 <_julian> if I want to build libav for raspberry pi I would have to add the meta-openembedded layer to my poky tree, right?
Sep 14 16:47:45 <bluelightning> _julian: I believe so yes
Sep 14 16:47:54 <bluelightning> _julian: since libav is only provided by meta-openembedded
Sep 14 16:48:09 <bluelightning> _julian: or rather, meta-oe which is a layer within the meta-openembedded repository
Sep 14 16:48:51 <_julian> bluelightning: ok, just checking out the meta-openembedded repository
Sep 14 16:57:08 <_julian> bluelightning: thanks, after adding meta-oe to bblayers and IMAGE_INSTALL_appen = " omxplayer" to local.conf another bitbake run seems to compile the missing stuff (c:
Sep 14 17:09:22 <sgw> fray: regarding the rpm multilib decoding, is MULTILIB_PREFIX_LIST the right thing to use with a for loop in the license code?  That's only valid for rpm though.
Sep 14 17:12:16 <kergoth> has anyone seen hob just hang right after starting it, while all the controls are greyed out, with no progress indication, nothing, just stalled, busy cursor, nothing
Sep 14 17:12:19 <kergoth> ?
Sep 14 17:12:29 <kergoth> i keep hitting this for some reason
Sep 14 17:14:43 <bluelightning> kergoth: I don't get any hourglass on my KDE system but I assumed that was some kind of gtk configuration issue...
Sep 14 17:17:32 <_julian> hm, now I run into an error when the rootfs is assembled:
Sep 14 17:17:34 <_julian> | Error: The location 100% is outside of the device /home/julian/dev/rpi/yoctoProject/raspberryPiBuild/tmp/deploy/images/rpi-basic-image-raspberrypi-20120914165458.rootfs.rpi-sdimg.
Sep 14 17:18:01 <_julian> is the rootfs image size too small in that case? where is it configured?
Sep 14 17:20:16 <bluelightning> ag_: ^ does that make any sense to you?
Sep 14 17:20:45 <ag_> bluelightning: Let me read...
Sep 14 17:22:10 <kergoth> hmm
Sep 14 17:23:24 <seebs> I ended up with a few cycles to think about variable/usage tracking stuff. And I need advice on Python idioms.
Sep 14 17:24:02 <seebs> In a couple of the languages I know, it's reasonably idiomatic to spell hash/dictionary objects roughly as { key = value, key2 = value2 }.
Sep 14 17:24:34 <seebs> I'm leaning towards a "logging info" dict as the right way to handle the proliferating logging arguments, but I do not know whether there's a way to express that nicely.
Sep 14 17:24:57 <seebs> My initial attempts to research this resulted in a flood of outdated pages, references to Python 3, and so on.
Sep 14 17:25:15 <_julian> http://pastebin.ca/2204282 <- this is the full build log
Sep 14 17:25:59 <kergoth> as richard suggested, keyword arguments are almost certainly a better approach
Sep 14 17:26:04 <kergoth> they're converted to a dict under the hood anyway
Sep 14 17:26:11 <ag_> _julian: That is strange
Sep 14 17:26:32 <ag_> _julian: COuld you please fill an issue in github?
Sep 14 17:26:50 <ag_> _julian: I have to go now and i wnat to took into it this weekend
Sep 14 17:27:00 <_julian> ag_: sure
Sep 14 17:27:08 <ag_> _julian: Thanks
Sep 14 17:27:13 <_julian> ag_: in which project should I add it?
Sep 14 17:27:25 <ag_> https://github.com/djwillis/meta-raspberrypi
Sep 14 17:27:37 <_julian> ok. thanks!
Sep 14 17:30:18 * ag_ goes home
Sep 14 17:32:53 <seebs> The thing I was sort of hoping to get from a dict was being able to modify parts of the dict and not have to repeat everything to pass it on to another function.
Sep 14 17:33:21 <kergoth> dicts can be converted to and from keyword arguments at will, using **
Sep 14 17:34:09 <seebs> Secondary issue: If I do that, then no one else can add kwargs without them getting entangled with the logger info. Although I don't know how likely that is to come up.
Sep 14 17:34:23 <kergoth> hm? of course they can
Sep 14 17:34:38 <kergoth> well, it depends on what you do with it
Sep 14 17:35:50 <kergoth> i'd say prototype both incarnations
Sep 14 17:35:56 <seebs> I was thinking in terms of stuff like stashing additional values (say, inferred file and line info) in the "loginfo" object, and passing that around. If loginfo is just "all the keyword args", then anything passed to one function is passed to all the others...
Sep 14 17:36:07 <seebs> Well, all the others it calls.
Sep 14 17:36:38 <seebs> I guess people who wanted to add an argument with special meaning to only one function could explicitly remove it from the hypothetical dict.
Sep 14 17:37:46 <seebs> And foo(..., a=b, b=c) is certainly easier to read than foo(..., { 'a': b, 'b': c })
Sep 14 17:41:18 <evanp> seebs: are you wishing for a way to namespace kwargs? how did you imagine doing that with a plain dict?
Sep 14 17:43:09 <seebs> Well, with the plain dict, I didn't have to. If it were setVar(name, value, loginfo), anyone adding something else would presumably not do it by shoving extra values into loginfo.
Sep 14 17:43:35 <seebs> But if it's setVar(name, value, file = foo, line = bar), and someone comes along and wants to define another keyword, it's not immediately obvious to me how to tell which keywords are "mine".
Sep 14 17:47:30 <evanp> seebs: and that's a problem because you're serializing the values into your log file, and you don't want other people's arguments showing up in the log?
Sep 14 17:50:39 <seebs> No, it's a problem because namespace clashes generically scare me. I'm only planning to use values I define, but... say there's a value which the logger wants to track internally, but which is never seen in other code calling setVar, and then someone who doesn't know about that comes along and defines it as a thing they want to pass to setVar, and this results in their value for it being passed into my code which uses that keyword...
Sep 14 17:50:58 <seebs> Basically, I got bitten by a namespace once and it swelled up really bad, and now I am afraid of them. :P
Sep 14 18:17:15 <msm`> RP: back now…. make it faster? ;) (wrt to multilib parsing speed)
Sep 14 18:25:06 <msm`> RP: ugh, skippackage still kills the build
Sep 14 18:31:24 <seebs> Okay, variable tracking's not done, but I've reworked the include history in a way I find much less offensive than the old one. Still not as pretty as I'd like, but definitely less sucky.
Sep 14 18:37:40 <khem> msm`: meta-fsl-ppc should we divided into two layers where one layer has BSP and other layer the FSL distro policies
Sep 14 18:37:58 <msm`> yea, im aware.. its on my list
Sep 14 18:38:05 <msm`> khem: ^
Sep 14 18:38:15 <khem> msm`: right now its not playing well in multi bsp scenario
Sep 14 18:38:30 <msm`> but if you are referring to the multiarch thing here again, i want this machine to build on all distros
Sep 14 18:38:35 <khem> and I was looking at the recent patches e.g. busybox and so on
Sep 14 18:38:42 <msm`> and there is a specific req regarding the toolchain
Sep 14 18:38:45 <khem> and then I saw these whole recipes-append
Sep 14 18:38:56 <msm`> khem: yea, those only apply on our distro..
Sep 14 18:39:09 <khem> exactly
Sep 14 18:39:13 <msm`> khem: but a separate layer is what we need to do, instead of the override foo
Sep 14 18:39:26 <msm`> khem: no but im saying it's working like you would expect, even now
Sep 14 18:39:32 <khem> so we have bsp+distro_layer+integration layer
Sep 14 18:39:36 <msm`> khem: its just doing it in it's own way
Sep 14 18:39:43 <khem> integration layers are right now different for different distros
Sep 14 18:39:52 <khem> brb
Sep 14 19:10:59 <seebs> Hmm. Okay, so there's something in this include tracking which I'm not liking, but I'm not at all sure how to improve it. I replaced the awful interleaved tuples and lists and such with dicts of { parent, filename, children }, where children is list of more of the same. And that's pretty easy to navigate.
Sep 14 19:11:22 <kergoth> wtf, libffi is in recipes-gnome? what an idiotic place to put it
Sep 14 19:11:46 <seebs> But I can't find a really sane way to do this without keeping a reference to the currently-in-process file. (I don't need the include stack anymore, because parent references.)
Sep 14 19:12:22 <seebs> And then for createCopy, I need to find "the thing that was a copy of the thing I have a reference to". Which is ugly.
Sep 14 19:22:03 <evanp> kergoth: dbus pulls it in, so it makes some sense historically. yeah, totally.
Sep 14 19:38:39 <seebs> further thought and consultation reveals: I should make a small class here. It will be prettier.
Sep 14 20:29:06 <kergoth> evanp: categorization shouldn't be done solely based on dependencies. it isn't in any way bound to gnome. nor is dbus exclusively used by gnome. it should never have gone there to begin with, imo
Sep 14 20:31:03 <evanp> kergoth: heh. not disagreeing ;-)
Sep 14 20:31:16 <kergoth> :)
Sep 14 20:31:44 <kergoth> its a good point, i can see how it would have been added there, wrongly, but .. ugh
Sep 14 20:31:47 * kergoth rolls eyes
Sep 14 20:32:17 <kergoth> this is a big part of why i decided not to break up the recipes by category when we started oe classic, it always seemed so arbitrary
Sep 14 20:32:26 * kergoth mutters and wanders off
Sep 14 21:09:26 <Crofton> heh
Sep 14 21:10:11 <Crofton> I am annoyed i2ctools is not in oe-core
Sep 14 21:10:12 <seebs> For reference, I sent out a draft of a dramatically less ugly version of the include file tracking. I am sort of planning to try to do the variable tracking over the weekend.
Sep 14 21:10:23 <seebs> I have gotten sick of not having this functionality. :P
Sep 14 21:40:58 <AdityaGandhi> Hi guys a simple one, where is xorg.conf located in the file system for core-image-sato
Sep 14 21:42:10 <AdityaGandhi> I thought it was in /etc/X11/xorg.conf, but its not there
Sep 14 21:42:16 <AdityaGandhi> for crownbay platform
Sep 14 22:00:41 <AdityaGandhi> HEt anyone, I am using the latest version of poky and meta-intel from git
Sep 14 22:00:44 <RP> seebs: that patch does look a lot nicer
Sep 14 22:00:53 <seebs> Yes, yes it does.
Sep 14 22:01:06 <seebs> Hoping the variable tracking one improves as much. Which I bet it will.
Sep 14 22:01:22 <AdityaGandhi> I was wondering where the xorg.conf has gone inside toe rootfs? Or has it gone completely  due to some changes?
Sep 14 23:24:42 <chackal_sjc> how's possible to create 2 filesystems with one image?
Sep 14 23:25:03 <chackal_sjc> for example, I want to have a rootfs, but the kernel I want to be in another filesystem, just with the kernel
Sep 14 23:43:16 <chackal_sjc> how can I compile my recipe with other compiler than the one that poky uses?
Sep 14 23:45:57 <evanp> chackal_sjc: look at the classes native.bbclass, nativesdk.bbclass, and base.bbclass for some insight into how to do that
Sep 14 23:46:39 <chackal_sjc> thx
Sep 14 23:46:47 <evanp> chackal_sjc: everything related to external-csl-toolchain is relevant as well
Sep 14 23:48:02 <evanp> chackal_sjc: it's quite difficult to do globally, but getting a single recipe to work isn't too terrible
Sep 14 23:51:19 <evanp> anyone ever seen do_qa_configure barf on gcc-cross-canadian because it tries to access /usr/lib/cmplrs/cc2.11?
Sep 14 23:53:12 <evanp> it's probably just my own recipes that are borked, but all I did to break it is add three lines to a header in glibc and rebuild...
Sep 15 00:24:28 <chackal_sjc> evanp: I just need it to do for two recipes
Sep 15 00:25:44 <seebs> I am wondering whether I should stash variable tracking data in the same history as the inclusion history.
Sep 15 00:26:32 <seebs> Because it turns out, that would make life a lot easier in some ways; for instance, it knows what file it's parsing even if something otherwise manages to escape that context.
Sep 15 01:03:35 <evanp> looks like the reason do_qa_configure is barfing is that configure is running the gcc_cv_collect2_libs test, despite the override in gcc-configure-common.inc
Sep 15 01:03:51 <evanp> and despite the fact that it worked just fine immediately prior to my edit
Sep 15 01:39:25 <chackal_sjc> how to use a external-csl ??
Sep 15 01:40:20 <chackal_sjc> for just one recipe?
Sep 15 01:58:20 <evanp> chackal_sjc: look at i.e. native.bbclass; it boils down to overriding the values of CC, AS, LD, and whatever other variables necessary to make it work. is your other compiler a version of GCC?
Sep 15 02:00:39 <chackal_sjc> evanp: Im using a csl toolchain just for the kernel.. but i tried to inherit the native class, but didn't work because of some LD problems
Sep 15 02:00:56 <chackal_sjc> the sysfs path os wrong, something like that
Sep 15 02:01:54 <evanp> chackal_sjc: native.bbclass is for building using the system toolchain specifically
Sep 15 02:02:59 <chackal_sjc> evanp: thats the problem,, because I would like to be my local csl toolchain inside the sandbox
Sep 15 02:05:58 <evanp> chackal_sjc: when you say "local csl toolchain", do you mean "my build machine is a Fedora 17 install, and I want to use Fedora 17's gcc, not Poky's" or something equivalent?
Sep 15 02:07:01 <chackal_sjc> not exactly
Sep 15 02:07:21 <chackal_sjc> evanp: I have a csl toolchain in my machine, under a directory tree only, not installed in the system..
Sep 15 02:07:38 <chackal_sjc> what I basically do is to add the toolchainpath/bin to PATH
Sep 15 02:08:23 <chackal_sjc> and compile the kernel with the CROSS_COMPILE=arm-none-linux-gnueabi-
Sep 15 02:09:19 <chackal_sjc> and I don't want to use this csl toolchain to build the entire rootfs, just the kernel and some kernel modules
Sep 15 02:09:37 <evanp> chackal_sjc: why _do_ you want to use it?
Sep 15 02:10:19 <chackal_sjc> evanp: its a requirement for our kernel
Sep 15 02:10:45 <chackal_sjc> actually the regular toolchain used in poky doesn't compile my kernel, gets error
Sep 15 02:11:01 <chackal_sjc> unfortunatelly is the compiler that is supported by the soc vendo
Sep 15 02:11:04 <chackal_sjc> vendor
Sep 15 02:11:22 <evanp> chackal_sjc: what sort of error
Sep 15 02:11:39 <chackal_sjc> compile-time errors, i don't remember exaclty right now
Sep 15 02:12:33 <chackal_sjc> evanp: but thats expected, since the soc vendor sux
Sep 15 02:12:47 <chackal_sjc> so thats why they only support this version of toolchain
Sep 15 02:14:35 <evanp> chackal_sjc: sometimes the kernel fails to build when it is an older version and you combine it with a quite recent GCC
Sep 15 02:15:13 <evanp> chackal_sjc: that happened to me; 2.6.34 + GCC 4.7 = kaboom
Sep 15 02:15:25 <chackal_sjc> ours is 2.6.36
Sep 15 02:15:31 <chackal_sjc> so maybe thats why
Sep 15 02:15:51 <chackal_sjc> and we need to use the poky toolchain to compile the user-space apps, because we use some C++11 features, for example
Sep 15 02:15:53 <evanp> chackal_sjc: In my case I could fix it by backporting the GCC 4.7 compatibility changes to Kbuild from...I think it was like 3.1 or something
Sep 15 02:18:08 <chackal_sjc> evanp: but i dont think I can do that
Sep 15 02:18:17 <chackal_sjc> they decided to go with this csl tool chain just for the kernel
Sep 15 02:18:46 <chackal_sjc> what im doing right now is to separate the kernel from the rootfs build
Sep 15 02:19:34 <evanp> chackal_sjc: I would say your best bet would be to replace kernel.bbclass in your layer
Sep 15 02:19:55 <chackal_sjc> im not using the kernel.bbclass acutally
Sep 15 02:20:03 <chackal_sjc> i dont need that much stuff..
Sep 15 02:21:25 <evanp> chackal_sjc: ...well, I was going to say replace it with a file that begins with "require ${COREBASE}/meta/classes/kernel.bbclass" and then has several lines overriding CC, AS, LD to point at your vendor's compiler
Sep 15 02:21:44 <evanp> chackal_sjc: but if you aren't using it, you could just stick the overrides in your .bb file
Sep 15 02:22:13 <evanp> chackal_sjc: or make your own class, "stupidvendor.bbclass" or something, and stick the overrides in it
Sep 15 02:22:38 <evanp> chackal_sjc: and then "inherit stupidvendor" in your .bb for the kernel and the modules
Sep 15 02:23:55 <evanp> chackal_sjc: once you've got it working, consult native.bbclass, nativesdk.bbclass, etc. for ideas on how to pretty it up. but you shouldn't really need to start by looking at them.
Sep 15 02:24:37 <chackal_sjc> evanp: what basically do I need?
Sep 15 02:24:41 <chackal_sjc> because what I tried, is that
Sep 15 02:24:46 <chackal_sjc> I have my machine layer
Sep 15 02:24:59 <chackal_sjc> so, machinelayer/binaries/arm2009-q1
Sep 15 02:25:11 <chackal_sjc> arm2009-q1 is the directory for the toolchain
Sep 15 02:25:43 <chackal_sjc> do I need to change any other variables?
Sep 15 02:25:56 <evanp> what variables have you changed?
Sep 15 02:26:04 <chackal_sjc> because if you use the CROSS_COMPILE the kernel should take care of it, right
Sep 15 02:26:18 <chackal_sjc> let me show my recipe
Sep 15 02:26:31 <evanp> yeah. I'm thinking probably just CROSS_COMPILE and PATH.
Sep 15 02:27:50 <chackal_sjc> evanp: http://paste.kde.org/548984/
Sep 15 02:31:19 <evanp> chackal_sjc: btw you might be able to use ${LAYERDIR} instead of ${FILE_DIRNAME}
Sep 15 02:31:29 <evanp> that looks pretty plausible though
Sep 15 02:32:32 <evanp> what doesn't work?
Sep 15 02:34:39 <chackal_sjc> let me check
Sep 15 02:34:45 <chackal_sjc> i forgot what was the error
Sep 15 02:36:20 <chackal_sjc> evanp: are you sure layerdir works?
Sep 15 02:36:25 <chackal_sjc> because its returning empty
Sep 15 02:37:32 <chackal_sjc> even using := doesn't expand
Sep 15 02:37:52 <evanp> chackal_sjc: no, I'm not. I guess the only uses I see are in copies of layer.conf.... nevermind.
Sep 15 02:38:14 <chackal_sjc> evanp: documentation states:     When used inside the layer.conf configuration file, this variable provides the path of the current layer.
Sep 15 02:38:54 <chackal_sjc> the configure step works fine
Sep 15 02:39:02 <chackal_sjc> when compiling that i get errors, let me show you
Sep 15 02:42:34 <chackal_sjc> evanp: I got this error http://paste.kde.org/548996/
Sep 15 02:42:57 <chackal_sjc> and the funny thing is that if I run the same command from a terminal, it works
Sep 15 02:43:06 <chackal_sjc> I get it could be variables
Sep 15 02:43:11 <evanp> it is
Sep 15 02:43:17 <evanp> I remember seeing that...where is it....
Sep 15 02:43:58 <chackal_sjc> evanp: I will try to unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
Sep 15 02:44:12 <evanp> TARGET_LDFLAGS in meta/conf/bitbake.conf
Sep 15 02:44:41 <chackal_sjc> unset also?
Sep 15 02:45:34 <evanp> it just gets assigned to LDFLAGS, so I'll bet clearing LDFLAGS is good enough
Sep 15 02:46:52 <chackal_sjc> evanp: now it compiled
Sep 15 02:46:54 <chackal_sjc> waw
Sep 15 02:47:11 <chackal_sjc> its 7:50 and Im still at the office hehe
Sep 15 02:47:18 <chackal_sjc> now I can go.. thanks man..
Sep 15 02:47:31 <evanp> no prob
Sep 15 02:47:34 <chackal_sjc> evanp: I have another quick question
Sep 15 02:47:58 <chackal_sjc> I want to create another fs for the kernel, but in the same image.bb
Sep 15 02:48:08 <chackal_sjc> for example, my image.bb creates a rootfs with the entire fs right
Sep 15 02:48:25 <chackal_sjc> but the kernel, I want to have another file system, with just the kernel, is that possible?
Sep 15 02:49:36 <evanp> I'd just do it with two .bb files
Sep 15 02:50:11 <evanp> trying to get a single .bb to do it will require fighting core-image.bbclass, which is probably not worth the effort....
Sep 15 02:51:17 <evanp> or, will require you doing it by hand rather than leveraging core-image.bbclass. probably not worth the effort either.
Sep 15 02:51:48 <chackal_sjc> evanp: ok, the only problem is that its relly hard to get a clean fs with core-image.bbclass
Sep 15 02:52:07 <chackal_sjc> I just want to create a .tar.gz with one file inside
Sep 15 02:52:17 <chackal_sjc> of few files
Sep 15 02:52:54 <evanp> have you tried setting IMAGE_INSTALL to "task-my-one-file" and then defining "task-my-one-file" to RDEPEND on whatever package installs it?
Sep 15 02:53:12 <chackal_sjc> evanp: yes,, still install some /etc/ crap
Sep 15 02:53:20 <chackal_sjc> well, i need to go no
Sep 15 02:53:26 <evanp> hmm.
Sep 15 02:53:26 <chackal_sjc> nice weekend
Sep 15 02:53:33 <chackal_sjc> ttyl
Sep 15 02:53:35 <evanp> you too
**** ENDING LOGGING AT Sat Sep 15 02:59:59 2012

**** BEGIN LOGGING AT Sat Sep 15 02:59:59 2012
Sep 15 03:12:10 <seebs> Okay, I did get a revised version of the tracking, but I don't trust it yet. Might get more done over the weekend, but I am a lot more tired than I expected. :)
Sep 15 17:11:29 <_julian_> ag_: hi, any thought on my rootfs build issue yet?
Sep 15 17:19:29 <thiagoss> hello, I'm trying to build an image for a raspberry pi. But I get a sanity check failure for the bblayers file. http://pastebin.com/gCfAhutX
Sep 15 17:19:39 <thiagoss> The problem is that the sample and my file have the same version already
Sep 15 17:25:49 <bluelightning> thiagoss: also note the error about "poky-rasperrypi" - this is not valid anymore
Sep 15 17:26:28 <zecke> thiagoss: use strace to check which conf/bb.. is used.. it might not be the one you think it is
Sep 15 17:26:50 <thiagoss> There's only one bblayers.conf, but I can try that anyway
Sep 15 17:28:18 <zecke> thiagoss: well, it is an app that compares a string and it is generally working quite well. ;)
Sep 15 17:34:09 <thiagoss> I only see it opening my bblayers.conf, it doesn't open the .sample version according to strace
Sep 15 17:35:22 <bluelightning> thiagoss: it doesn't, no
Sep 15 17:35:56 <bluelightning> thiagoss: please pastebin your conf/bblayers.conf
Sep 15 17:36:37 <thiagoss> http://pastebin.com/UPwAmRCQ
Sep 15 17:38:07 <zecke> thiagoss: and the output of strace -fF bitbake..
Sep 15 17:46:37 <bluelightning> thiagoss: change DISTRO = "poky" and I suspect the issue will go away
Sep 15 17:47:17 <thiagoss> looks like that worked
Sep 15 17:47:29 <bluelightning> poky bumped it's LAYER_CONF_VERSION to which this value is compared; the default was not bumped
Sep 15 17:47:47 <bluelightning> (the bump was due to splitting meta-yocto and meta-yocto-bsp)
Sep 15 17:48:25 <bluelightning> thiagoss: ensure you have also set BBMASK as mentioned in the meta-raspberrypi README
Sep 15 17:48:37 <thiagoss> Yes, did it already. Thanks
Sep 15 17:48:45 <thiagoss> I'll now start adding my own recipes :)
Sep 15 17:48:50 <bluelightning> cool, just checking :)
Sep 15 17:49:23 <bluelightning> thiagoss: note that there's a wealth of recipes already available - see http://www.openembedded.org/wiki/LayerIndex
Sep 15 17:49:34 <bluelightning> (particularly the software layer section further down)
Sep 15 17:50:11 <thiagoss> Yep. I plan to reuse as much as possible
Sep 15 17:50:31 <thiagoss> Trying to get the still to be released gstreamer-1.0 to run on the raspberry
Sep 15 17:54:49 <ag_> _julian_: Just on it right now.
Sep 15 17:55:00 <ag_> _julian_: I could reproduce it.
Sep 15 17:56:59 <_julian_> ag_: ah, good to hear (c:
Sep 15 17:59:19 <_julian_> thiagoss: nice, planing to use gst-openmax plugin on pi?
Sep 15 18:01:17 <thiagoss> _julian_, yes. After I get the basic software stuff running.
Sep 15 18:08:14 <_julian_> thiagoss: cool. I wanted to play around with gst on pi as well, if time allows...
Sep 16 00:10:55 <ag_> _julian_: Just fixed that bug in sd image creation.
**** ENDING LOGGING AT Sun Sep 16 02:59:59 2012

**** BEGIN LOGGING AT Sun Sep 16 03:00:00 2012
Sep 16 09:48:54 <_julian> ag_: thanks, your fix works (c:
Sep 16 09:49:09 <ag_> _julian: I know :)
Sep 16 09:49:18 <ag_> _julian: Glad it works for you too :)
Sep 16 09:49:22 <_julian> (c:
Sep 16 09:49:47 <_julian> have to test if the image actually boots yet, but can do that only tomorrow. no raspi at home right now.
Sep 16 09:52:36 <ag_> _julian: Ok.
Sep 16 09:53:15 <ag_> _julian: If you see anything strange mail me or issue on github.
Sep 16 09:53:31 <_julian> ag_: yep, I will. thanks (c:
Sep 16 09:55:45 <ag_> Anybody and give me a hint why "unset TARGET_ARCH" ?
Sep 16 09:55:58 <ag_> in bitbake -e
Sep 16 09:57:37 <_julian> ag_: the images boot partition does not contain a config.txt, does it?
Sep 16 09:57:51 <ag_> _julian: Nope.
Sep 16 09:58:06 <ag_> We pass kernel cmdline in kernel recipe.
Sep 16 09:58:28 <ag_> Do you need something for kernel comdline?
Sep 16 09:58:53 <_julian> I need to pass in the mepg2 license key. is this passed into kernel cmdline actually?
Sep 16 09:59:56 <ag_> _julian: Ah! Actually i don't know. Don't have one. :)
Sep 16 10:01:03 <_julian> they just add a line decode_MPG2=<key> to config.txt.
Sep 16 10:01:45 <ag_> I saw that.
Sep 16 10:01:54 <ag_> Wait a sec.
Sep 16 10:02:52 <ag_> _julian: I messed up cmdline.txt with config.txt
Sep 16 10:03:18 <_julian> ah ok. just reading myself. seems config.txt is parsed directly by the GPU core driver?
Sep 16 10:03:23 <ag_> So. config.txt is for gpu configuration
Sep 16 10:03:30 <ag_> Indeed.
Sep 16 10:03:52 <ag_> I thought you were talking about kernel cmdline.
Sep 16 10:03:58 <_julian> ok (c:
Sep 16 10:04:07 <ag_> Anyway you would need a file like that to pass the licence key to pgu
Sep 16 10:04:37 <ag_> in this way you will get codecs unlocked
Sep 16 10:04:46 <_julian> the config.txt could be copied alongwith the elf binaries in the sdcard_image-rpi.bbclass, couldn't it?
Sep 16 10:05:45 <ag_> Yes. Would be a nice thing to generate the config.txt if ppl supply a key for mpg2 or wvc1...
Sep 16 10:05:51 <_julian> well maybe it would even make more sense to create and add the config.txt with a script later to the sdcard. as the codec keys are individual for each pi anyway...
Sep 16 10:06:03 <ag_> Think about this.
Sep 16 10:06:13 <ag_> If ppl have in local.conf:
Sep 16 10:06:27 <ag_> KEY_MPG2 = "mykey"
Sep 16 10:06:44 <ag_> KEY_WVC1= "mykey"
Sep 16 10:07:08 <ag_> We can check for these variables and add them to config.txt and ship in boot partition.
Sep 16 10:07:16 <_julian> right, that would basically work. but if an image is created to be used for a bunch of pis, like 50 or so, it would be a bit uncomfortable to recreate an image file for each of the pis...
Sep 16 10:07:43 <_julian> although in that case one could use a placeholder value and run a sed on config.txt later... or something like that
Sep 16 10:08:18 <ag_> If those are not defined we can ship an empty config.txt.
Sep 16 10:08:31 <_julian> yes...
Sep 16 10:08:38 <ag_> And the user can sed / add / whatever fo with it.
Sep 16 10:08:42 <ag_> do*
Sep 16 10:08:57 <ag_> One more thing
Sep 16 10:09:01 <_julian> maybe it would make sense to add some more generic thing to local.conf to add whatever you want to config.txt?
Sep 16 10:09:21 <ag_> You can specify more than a single key. SO you can use it with bunch of pis as you said.
Sep 16 10:09:51 <ag_>  decode_XXXX=0x12345678,0xabcdabcd,0x87654321
Sep 16 10:10:20 <ag_> So, shouldn't be a problem.
Sep 16 10:10:34 <_julian> I saw that as well, but I wonder if this really makes sense if you have bigger numbers of pis. it will likely take some time to go though 50 keys until the gpu finds a matching one
Sep 16 10:11:03 <ag_> You can try and check for performance.
Sep 16 10:11:18 <ag_> Can't really say something about this as i don't have a key.
Sep 16 10:11:23 <_julian> yep, I will do that (c:
Sep 16 10:11:27 <ag_> And generally ppl have ONE key. :)
Sep 16 10:11:44 <ag_> So my scenario will be 99% valid :)
Sep 16 10:12:09 <ag_> But what you say is interesting. And needs some investigation.
Sep 16 10:12:23 <ag_> So, when you have results please sync with me.
Sep 16 10:12:23 <_julian> sure, if used in private scenario it will perfectly work. but I see several people looking at the pi for low-cost embedded projects, in that case you may even have 500 pis.
Sep 16 10:12:33 <_julian> of course, I will
Sep 16 10:12:47 <ag_> You are right.
Sep 16 10:13:19 <ag_> You have to check something first.
Sep 16 10:13:37 <_julian> another topic: is yocto able to create read-only rootfs compatible systems?
Sep 16 10:14:22 <ag_> People around might answer to that .
Sep 16 10:22:34 <bluelightning> _julian: I think the answer is sort of, depending on which packages are installed
Sep 16 10:22:41 <_julian> ok.
Sep 16 10:23:36 <bluelightning> _julian: the issue is usually with package post-install scripts that won't run at do_rootfs time; we've slowly been fixing them so that they can and thus they don't need to be run on the target first boot
Sep 16 10:23:37 <_julian> I also wonder if there are approaches to pack the rootfs in a squashfs or anything like that? I think that would be quite helpful when a device should be able to self-update. it just could move the old squashfs tmpfile into a .old file and grab a new one...
Sep 16 10:23:50 <_julian> bluelightning: ah, I see.
Sep 16 10:24:39 <bluelightning> I think people have been using squashfs but I've never used it for that purpose...
Sep 16 10:25:15 <_julian> ok. I will try to read round a bit.
Sep 16 10:29:51 <_julian> reading through the lists, it seems ericben has some squashfs/ro experience (c:
Sep 16 10:50:48 <ag_> bluelightning: Is MACHINE_KERNEL_PR deprecated? I don't understand it's purpose after all.
Sep 16 10:52:14 <bluelightning> ag_: it was never reintroduced to OE-Core
Sep 16 10:52:34 <bluelightning> ag_: meta-oe has a class to add it back in though
Sep 16 10:52:53 <ag_> bluelightning: I saw that. But are ppl still using it in meta-ti for example? I don't really understand.
Sep 16 10:53:31 <bluelightning> angstrom is still using it; meta-ti was originally designed only to work with angstrom
Sep 16 10:54:19 <ag_> I saw angstrom is using it. Anyway. Just can't see it's purpose.
Sep 16 10:56:32 <bluelightning> ag_: I believe it's a way of forcing a rebuild of the kernel + modules from the machine config
Sep 16 10:57:18 <bluelightning> really, with BB_SIGNATURE_HANDLER = "OEBasicHash" and more completely with the PR server, it's not needed anymore
Sep 16 10:58:02 <ag_> bluelightning: Hmmm... things i don't know. :)
Sep 16 18:14:05 <roric> I was to check the edid, but there were no /sys/devices/omapdss/display[0-9]+, is that changed in the ubuntu 12.04 flavour
Sep 16 19:04:43 <ag_> In raspberrypi glesv1 and glesv2 are both in glesv2 library. So a symlink libGLESv1_CM.so to glesv2 library is required by other apps linking to lGLESv1_CM.
Sep 16 19:05:34 <ag_> Would it make sense to skip the symlink qa test in this case and ship symlink inside main package?
Sep 16 19:06:35 <ag_> I need an advice here.
Sep 16 19:41:27 <ag_> _julian: Around?
Sep 16 19:53:58 <ag_> _julian: https://github.com/djwillis/meta-raspberrypi/pull/70
Sep 16 19:54:10 <ag_> _julian: Give it a try. Should be what you needed.
Sep 16 20:21:12 <ag_> ant__: Around?
Sep 16 20:27:56 <_julian> ag_: thanks, looks perfect. will ge i a ty torrow
Sep 16 20:28:05 <_julian> will give it a try tomorrow.
Sep 16 20:28:15 <ag_> _julian: Fair enough.
Sep 16 20:40:53 <ant__> ag_: hello
Sep 16 20:41:37 <ag_> ant__: Hope i'm not wrong but i think you uploaded the h file for psplash screen logo
Sep 16 20:42:29 <ant__> yes, the one from oe-classic
Sep 16 20:43:09 <ag_> ant__: Yes.
Sep 16 20:43:35 <ag_> I would like to use an append in raspberrypi with a raspberry added somewhere on that.
Sep 16 20:43:48 <ag_> Do you have the png file used in the generation process?
Sep 16 20:44:19 <ag_> Obviously if you have it and want to share :)
Sep 16 20:44:40 <ag_> I can remake it but i don't want to change things
Sep 16 20:46:10 <ant__> I don't think I've kept that one :/ iirc was scales down from a svg
Sep 16 20:46:59 <ag_> ant__: Yeah... i'd like that svg file...
Sep 16 20:48:26 <ant__> http://cgit.openembedded.org/openembedded/tree/contrib/artwork/oe.svg?h=org.openembedded.dev
Sep 16 20:49:23 <ag_> ant__: Thank you very much
Sep 16 20:49:35 <ant__> yw
Sep 16 20:49:58 <ant__> here the same for kernel logo
Sep 16 20:50:01 <ant__> http://cgit.openembedded.org/meta-handheld/tree/recipes-kernel/linux/files
Sep 16 20:52:03 <ag_> ant__: Thanks.
Sep 16 21:01:05 <ag_> ant__: Those are for oe.
Sep 16 21:01:27 <ag_> ant__: Do you have svgs for yocto too?
Sep 16 21:04:55 <ant__> no, I've just found png
Sep 16 21:17:06 <ag_> ant__: Ok. Nevermind
Sep 16 21:40:54 <ag_> ant__: Any idea why the background of my image is whiter than the background>
Sep 16 21:40:55 <ag_> ?
Sep 16 21:42:05 <ag_> https://www.dropbox.com/s/dmbvlrlhzm9hvvy/2012-09-17%2000.21.04.jpg
Sep 16 21:48:13 <ant__> iirc it is RGBA
Sep 16 21:48:57 <ag_> ant__: Thought so. Thanks
Sep 16 21:52:21 <ag_> ant__: I made it rgba and now bg is ok but the logo is very.... pixelish. :)
Sep 16 21:52:29 <ant__> heh
Sep 16 21:52:54 <ag_> Should i have vectorial draw or something?
Sep 16 21:53:30 <ant__> afaik the ppm have been originally done with imagemagic
Sep 16 21:56:17 <ag_> I see.
Sep 16 21:56:23 <Flyser> Hi, can I build a linux image and toolchain with yocto that runs on linux 2.6.31?
Sep 16 21:57:12 <Flyser> or are some parts (i.e. current glibc) dependant on the 3.x linux headers?
Sep 16 22:01:46 <ag_> ant__: aaaa... can't get rid of that ugly logo edge....
**** ENDING LOGGING AT Mon Sep 17 02:59:59 2012

**** BEGIN LOGGING AT Mon Sep 17 02:59:59 2012
Sep 17 05:13:38 <blloyd> I'm working in mainline poky.  Using crownbay as an example, I may a new bsp.  However, it seems the xorg.conf snippet is ignored.
Sep 17 05:14:01 <blloyd> how are you supposed to get the default one replaced with a custom version?
Sep 17 07:02:42 <mckoan> good morning
Sep 17 07:02:51 <blloyd> morning
Sep 17 08:11:03 <bluelightning> morning all
Sep 17 09:00:27 <mertsas> I have a package from meta-ti, which has a lot of "installed but not shipped" qa warnings. It is not supposed to be shipped in any packages, as it is a compilation tool (xdctools), so is there a way that I can make these QA warnings be ignored on this specific package?
Sep 17 09:09:41 <bluelightning> mertsas: the files should just be deleted within do_install in the recipe
Sep 17 09:28:21 <mertsas> bluelightning: ok, I'll see how I can do that for my problem
Sep 17 13:52:08 <ag_> Anybody around with a 32bit host, gcc 4.6.3 and a core-image-sato build (don't bother the arch)?
Sep 17 16:58:17 <blloyd> seems there's been some big churn in the yocto git since I last updated.  I did a quick check through the mail lists I'm subscribed to, but didn't see the discussion about changes to xserver configuration.  Anyone know what changed past 2 months that might have broken a BSP configuration for xserver?
Sep 17 16:59:19 <JaMa> e.g. xserver-xorg-lite removal?
Sep 17 16:59:59 <blloyd> that would be a big change.  :)
Sep 17 17:00:22 <JaMa> depends on what you call xserver configuration..
Sep 17 17:05:16 <blloyd> OK, first I used the intel bsp as a reference implementation.   If they did something wrong I did too.  So, they all have an xorg.conf snippet which configures the video.  With the changes, it seems the standard xorg.conf file is placed in the image instead of their custom version.  In this case, the replacement is to cause the vesa video driver to be used.
Sep 17 17:06:10 <blloyd> If I hand edit, xinit starts working.  Then I run into problem #2.  No keyboards or mice work.
Sep 17 17:15:23 <blloyd> are the intel bsp's a bad choice for examples to follow?
Sep 17 17:15:40 <kergoth> so, if core-image-minimal-initramfs is live image specific, why is it named something so generic?
Sep 17 17:15:45 <kergoth> i'm confused by this
Sep 17 17:28:34 <Crofton> hmm, I found something I do not like about the new bitbake display
Sep 17 17:28:49 <Crofton> I added meta-oe to my layer stack, so I could build i2c-tools
Sep 17 17:29:01 <Crofton> and ran bitbake i2c-tools
Sep 17 17:29:05 <Crofton> and looked away
Sep 17 17:29:13 <Crofton> and sa the completion message
Sep 17 17:29:22 <Crofton> but, no sign that i2c-tools really built
Sep 17 17:29:44 <zeddii> Crofton. +1 ... I have that same issue.
Sep 17 17:30:05 <zeddii> I just re-issue the command when I get back .. since I'm too lazy to hunt up logs.
Sep 17 17:30:17 <Crofton> mind you, I am pleased I could add meta-oe and build one recipe, and see one recipe build
Sep 17 17:30:40 <kergoth> if you saw the completion message, you should be confident that it built. if it didn't, you wouldn't have seen a successful completion :)
Sep 17 17:30:51 <blloyd> wierd: I've had a few not build, but then I get warnings that XYZ was skipped.  Haven't had XYZ be the exact package I'm trying to build though.  Usually it's a dependency.
Sep 17 17:31:03 * zeddii is "of little faith" :P
Sep 17 17:34:43 <Crofton> kergoth, I know that, I just like a little reassurance
Sep 17 17:34:58 <Crofton> was also curious if any other builds where triggered
Sep 17 17:35:19 <Crofton> I do think i2c-tools should move to oe-core, since it is useful for small test images
Sep 17 17:35:56 <Crofton> of course, this is not a reason to go back to the old way :)
Sep 17 17:37:09 <Crofton> so this is annoying
Sep 17 17:37:32 <Crofton> now i will modify my image in a bsp so that it depends on meta-oe
Sep 17 17:38:02 <Crofton> but, I really do not want that to be a hard depends
Sep 17 17:38:59 <Crofton> if meta-oe is not available, I would like maybe a warning and the image to build anyway
Sep 17 17:39:17 <Crofton> at the very least pass parsing, even though a layer is missing
Sep 17 17:39:33 <Crofton> this seems like something we need to talk about
Sep 17 17:44:48 <blloyd> If target arch doesn't change, why does changing MACHINE cause everything to rebuild?
Sep 17 17:47:23 <kergoth> bbloyd: it shouldn't cause *everything* to rebuild, but some things may rebuild due to differing compiler tuning arguments, for example
Sep 17 17:51:16 <blloyd> ok, I've tried to make it where I could use my new, not working bsp machine and a qemux86 machine to compare to.  Used to it only changed a few things.  Now, I'm getting churn across 5000 some odd packages.  Or so build times/messaging seems.
Sep 17 18:14:01 <blloyd> crofton, is your bsp somewhere it can be pulled to look at?
Sep 17 18:14:07 <blloyd> and does it use X?
Sep 17 18:14:22 <Crofton> it is a lame bsp
Sep 17 18:14:33 <Crofton> builds a kernel and an image for a dev board
Sep 17 18:14:50 <Crofton> https://github.com/balister/meta-zynq
Sep 17 18:14:50 <blloyd> which are the two things driving me CRAZY
Sep 17 18:15:03 <Crofton> I haven't messed with X lately
Sep 17 18:33:32 <blloyd> thank you for sharing crofton.  I may go the route of not using the linux-yocto kernel.
Sep 17 18:38:43 <Crofton> in this case, I build directly from the evil vendor git repo
Sep 17 18:39:31 <Crofton> linux-yocto is a nice idea, but you need sane patch sets against mainline it seems
Sep 17 18:39:51 <blloyd> I would love that: my evil vendor thinks a LTS linux distribution that support has ended for is current LINUX support.
Sep 17 18:40:26 <blloyd> and a binary release of busybox is their distribution source....
Sep 17 18:41:22 <Crofton> there are definitely different degrees of evil in the world
Sep 17 18:44:00 <blloyd> but on the flip side: the only cheaper hardware we've found is blackberry pi, and you can't say that would survive around low paid, uncaring employees that do stupid things to electronics.
Sep 17 18:44:36 <blloyd> oh, and running Windows XP SP2 is windows compatible...
Sep 17 18:52:19 <blloyd> question: can anyone recommend a consultation company to help with learning yocto?
Sep 17 18:52:28 <blloyd> (or individual)
Sep 17 18:55:50 <msm`> zenlinux: fyi im getting some build failures for denzil on atom-pc machine
Sep 17 18:55:53 <msm`> zenlinux: https://gist.github.com/3739102
Sep 17 18:56:01 <msm`> zeddii: not sure if you have seen this either ^
Sep 17 20:06:24 <msm`> anyone see this: https://gist.github.com/3739462
Sep 17 20:06:30 <msm`> after a rebase...
Sep 17 20:16:56 <bluelightning> msm`: sounds like the known m4 race situation...?
Sep 17 20:17:08 <msm`> bluelightning: bug #?
Sep 17 20:17:09 <bluelightning> msm`: try continuing the build
Sep 17 20:17:14 <msm`> bluelightning: yea, it works
Sep 17 20:17:17 <bluelightning> msm`: I don't know if one has been filed
Sep 17 20:17:26 <msm`> bluelightning: it occurs a lot, i thought one of RPs recent patches helped this
Sep 17 20:29:45 <bluelightning> I'm not sure
Sep 17 20:30:00 <bluelightning> AFAIK there has always been a race there, I see it very occasionally
Sep 17 20:36:10 <msm`> bluelightning: well a lot = after most rebases
Sep 17 21:10:30 <blloyd> anyone know what happened to the openembedded domain?
Sep 17 21:16:31 <bluelightning> blloyd: seems to be working here... ?
Sep 17 21:16:54 <bluelightning> blloyd: are you accessing openembedded.org or .net?
Sep 17 21:20:28 <kishore> Does yocto has GNU Multi Precision library gmp support?
Sep 17 21:26:56 <blloyd> openembedded.org
Sep 17 21:27:14 <Crofton> works for me
Sep 17 21:27:49 <Bagder> "Expiration Date:21-Jan-2013 23:58:22 UTC" seems to work fine
Sep 17 21:28:03 <Crofton> http://www.downforeveryoneorjustme.com/openembedded.org
Sep 17 21:33:39 <msm`> kishore libgomp?
Sep 17 21:33:59 <msm`> kishore: its part of gcc, we package it on powerpc
Sep 17 21:34:34 <kishore> msm: It is libgmp
Sep 17 21:35:00 <blloyd> personally: my check is usually nslookup www.openembedded.org B.ROOT-SERVERS.NET
Sep 17 21:35:02 <kishore> msm: libgmp for x86_64
Sep 17 21:35:10 <blloyd> (which gets no response)
Sep 17 21:36:21 <msm`> kishore: ahh, different then, sorry
Sep 17 21:39:16 <evanp> kishore: meta/recipes-support/gmp. it's actually a dependency of GCC.
Sep 17 21:52:51 <khem> gm all
Sep 17 21:54:13 <khem> anyone has some work done on python-3.x target recipes
Sep 17 21:58:19 <seebs> do_install { rm -rf ${D}; echo >&2 "Trust me. You'll thank me later." }
Sep 17 21:59:03 <seebs> Which is to say: No, but if my subconscious ever gets hold of the idea of Python 3 and Yocto being in the same room, I will doubtless have nightmares involving management asking whether I can get Yocto stable with Python 3.2 "by Friday or so?"
Sep 17 22:05:12 <kishore> evanp:  Is it built for x86 arch as well?  I don't see them building for x86 arch
Sep 17 22:10:49 <kishore> evanp:  Looks like by default gmp is not build.  I had to build it separatly.
Sep 17 22:10:58 <kishore> evanp:  Thanks for the info.
Sep 17 22:13:53 <seebs> Actually, anyone around care to kibitz on some Python design/implementation questions? I am sorta unhappy with the current state of my variable tracking, but unable to think of a good way to improve it.
Sep 17 23:35:21 <chackal_sjc> hows possible to create an empty image? by empty image I mean no file inside a rootfs.tar.gz
Sep 18 00:04:23 <seebs> Okay, I have an experimental version of the variable tracker about ready to be sent out.
Sep 18 00:05:36 <seebs> I am not at all sure it's production-quality, because it is doing some sort of arcane stuff, but I am really happy with how unintrusive it now is in the rest of the code. The tradeoff being that the recording code does Unreasonable Things like looking up the stack tree for values you probably meant to give it, so you don't have to spell them out in all the calls.
Sep 18 00:07:15 <seebs> Sorta thinking of inverting the sense of the ignore flag; it appears that of the 52 changes that affect setVar/delVar lines, 36 specify ignore.
Sep 18 00:08:46 <seebs> And several of the others wouldn't actually need to be updated if that weren't there. Hmmm.
Sep 18 02:12:03 <seebs> Okay! Variable tracking patch sent out to the list. With any luck it'll work -- the patch was tested against poky, then applied to my bitbake tree.
**** ENDING LOGGING AT Tue Sep 18 02:59:58 2012

**** BEGIN LOGGING AT Tue Sep 18 02:59:59 2012
Sep 18 04:55:54 <blloyd> I have an autotools package (wxWidgets which has a ./configure script included.  That script runs.  However, if autorun.sh is run, (many, many macros are missing), the resulting script is useless.  How can you tell bitbake not to do autoconf?
Sep 18 06:11:18 <mckoan> good morning
Sep 18 06:11:43 <mckoan> blloyd: where do you launch autorun.sh ?
Sep 18 06:12:31 <mckoan> blloyd: take a look at wxwidgets-*.inc
Sep 18 07:18:31 <_julian> morning
Sep 18 08:14:35 <bluelightning> morning all
Sep 18 09:16:30 <niro> Hi, how can I get a list of what yocto has put in my created image?
Sep 18 09:19:29 <bluelightning> niro: this may be helpful: https://wiki.yoctoproject.org/wiki/Buildhistory
Sep 18 09:20:47 <niro> That looks along the right lines. Thank you.
Sep 18 10:37:58 <mertsas> I wish to change shell on my device from bash to zsh. I see that there is a zsh recipe in meta-openemebedded, but is there a way to set default login shell to zsh?
Sep 18 10:56:06 <ag_> The pull req sent to github for meta-oe are not reviewed? I have a pull req there for 2 months and no merge / feedback.
Sep 18 10:56:45 <_julian_> ag_: I've got the rpi image up and running now. including your psplash and config.txt pull requests. works very well (c:
Sep 18 10:59:34 <_julian_> ag_: I am just trying to update the omxplayer to a recent git version. shouldn't it be enough to change the SRCREV value in omxplayer_git.bb and run bitbake rpi-basic-image?
Sep 18 11:01:54 <_julian_> it seems it won't do an git checkout automatically?
Sep 18 11:05:40 <bluelightning> ag_: I don't think those are monitored, I would recommend following what the README says about submitting changes
Sep 18 11:23:19 <_julian_> thiagoss: are you proceeding with gstreamer on rpi?
Sep 18 11:23:45 <thiagoss> I already have some bitbake recipes, but still had no time to deploy and test. I should have something by the end of the week
Sep 18 11:27:51 <_julian_> thiagoss: ok, cool.
Sep 18 11:28:41 <thiagoss> I'll put up all my recipes once they work
Sep 18 11:28:44 <niro> Is there a way I can add a program that I've forgotten to include in my image?
Sep 18 11:29:14 <_julian_> thiagoss: perfect. looking forward to try them out (c:
Sep 18 12:01:53 <_julian_> is there a yocto-compatible overlay that provides python?
Sep 18 12:03:18 <_julian_> the recipes-devtools are only for the build toolchain on the build host, aren't they?
Sep 18 12:15:39 <_julian_> ah no, seems they are usable as normal packages (c:
Sep 18 12:25:46 <_julian_> hm, python was built. but the rootfs assembly fails: unable to find package python
Sep 18 12:43:59 <_julian_> ah, python-core works...
Sep 18 13:08:21 <ag_> _julian_: Thank you. For the update a srcrev update should be enough. If you find this stable and tested you can send a pull req.
Sep 18 13:08:28 <ag_> _julian_: Let me check the recipe.
Sep 18 13:09:04 <ag_> bluelightning: From the README: "You are encouraged to fork the mirror on github https://github.com/openembedded/meta-oe/ to share your patches, this is preferred for patch sets consisting of more than one patch."
Sep 18 13:10:37 <ag_> _julian_: SRCREV should be enough. no check still on it?
Sep 18 13:10:42 <ag_> checkout*
Sep 18 13:11:12 * ag_ brb
Sep 18 14:01:11 <ag_> How can a layer add a preferred version?
Sep 18 14:57:37 * sgw YPTM: Saul is early!
Sep 18 15:00:26 <pidge> YPTM: beth is here
Sep 18 15:00:39 <laur> YPTM: LaurentiuP joined
Sep 18 15:00:40 <nitink> YPTM: Nitin is on the call
Sep 18 15:00:40 <tomz2> YPTM: Tom Z here
Sep 18 15:00:40 <ag_> sgw: Hello. What do you think about  having in oe-core a zram init script recipe? And pulled in by an image with a machine feature zram...
Sep 18 15:00:45 <Song_Liu> YPTM: Hi everyone, let's get the technical team meeting started. Please let me know who's on the bridge. Thanks!
Sep 18 15:00:49 <bogdanm> YPTM: bogdanm is here
Sep 18 15:00:52 <strassek> YPTM: Kevin Strasser is here
Sep 18 15:01:01 <AlexG> AlexG from QA Romania here :)
Sep 18 15:01:15 <Jefro> YPTM: Jefro is here
Sep 18 15:01:26 <ag_> sgw: Your're in a meeting. Talk to you later.
Sep 18 15:01:33 <moolinex> YPTM: joined
Sep 18 15:01:41 <sgw> ag_ it's Ok this one I can multi-task
Sep 18 15:01:49 <jmpdelos> YPTM: Polk is here
Sep 18 15:01:51 <denix> YPTM: Denys is here
Sep 18 15:02:31 <ag_> sgw: So i have in meta-rpi a zram service which i want to get rid of. :) Move the service in meta-systemd and have a init-script from oe-core.
Sep 18 15:02:47 <dvhart> YPTM: Darren has joined
Sep 18 15:03:10 <sgw> ag_ seems like meta-oe or a layer might be a better place to start with that, is it only for rpi?
Sep 18 15:03:12 <darknighte> YPTM: Sean dialing in
Sep 18 15:03:27 <Song_Liu> YPTM: let's collect some opens. Anyone?
Sep 18 15:03:35 <pidge> YPTM: Open 1.3_M4 status
Sep 18 15:04:03 <darknighte> YPTM: Song_Liu: I've joined
Sep 18 15:04:15 <scottrif> Scott Rifenbark joined
Sep 18 15:04:20 <ag_> sgw: This is why i what to get rid of. Is a generic modprobe and swapon for zram. Nothing special for rpi. That's why i don't find it's place in meta-rpi.
Sep 18 15:04:39 <Jefro> YPTM: Yocto Project Dev Day in Barcelona, November 8 (quick & low priority)
Sep 18 15:04:43 <ag_> sgw: But people use it. So removing it is not a intelligent thing to do.
Sep 18 15:07:34 <darknighte> who is speaking?
Sep 18 15:08:00 <halstead> Yptm: Michael Halstead, present.
Sep 18 15:08:02 <blloyd> me:
Sep 18 15:08:58 <darknighte> sgw: blloyd: perhaps we should move discussion of this concern to the end of the call?
Sep 18 15:09:08 <blloyd> works for me.
Sep 18 15:11:41 * darknighte bows to the team in homage of green builds  (especially pidge)
Sep 18 15:13:35 <darknighte> pidge: nice!
Sep 18 15:14:22 <darknighte> sgw: dvhart: is RP at Automotive Linux Conference?
Sep 18 15:16:19 <sgw> darknighte: yes
Sep 18 15:16:36 <sgw> blloyd: we can talk later if you would like
Sep 18 15:17:17 <darknighte> with all this good news, I'm getting paranoid about what's next.
Sep 18 15:18:52 <Song_Liu> https://wiki.yoctoproject.org/wiki/Yocto_1.4_Features
Sep 18 15:21:20 <pidge> darknighte: ty!
Sep 18 15:22:13 <darknighte> pidge: ty?
Sep 18 15:22:41 <pidge> darknighte: thank you.
Sep 18 15:23:50 <darknighte> pidge: clearly my leet vocab is still not all that complete.  ;)
Sep 18 15:27:29 <darknighte> Song_Liu: don't we all wish we could have cake?!
Sep 18 15:29:39 <Song_Liu> darknight: we usually have team celebration for a release. Maybe you can join us for 1.3?
Sep 18 15:29:40 * sgw YPTM: I would like to remind everyone that we are getting to release time
Sep 18 15:30:07 <darknighte> Jefro: Wow!  Yocto Dev Day sounds really interesting.  Wish I was going.  ;)
Sep 18 15:30:11 <darknighte> Song_Liu: Sure!
Sep 18 15:30:36 <Jefro> Sean Hudson: you'd better be!
Sep 18 15:32:17 <darknighte> Song_Liu: don't forget blloyd's issue for discussion.
Sep 18 15:32:25 <darknighte> scottrif: beat me to it!
Sep 18 15:33:04 <blloyd> I've more than once had to build the docs from the sources, and even then it was behind.
Sep 18 15:37:20 <scottrif> blloyd:  Sometimes the pulls from my yocto-docs/master area are a bit behind into the poky/documentation area for the master branch.  You should not have to build docs from poky.  Use the "Docs in Progress" link from the website to guarantee you have the latest docs.
Sep 18 15:42:04 <sgw> blloyd: thanks for the feedback, we look forward to your bug report.
Sep 18 15:42:15 * sgw apperciates darknighte is saying also
Sep 18 15:42:34 <sgw> darknighte: you said it for me.
Sep 18 15:43:09 <darknighte> sgw: wow, I thought I suddenly felt the desire to homebrew.  Must have been channeling you.
Sep 18 15:43:43 <sgw> darknighte: you welcome to come down here and help pick hops!
Sep 18 15:44:17 <darknighte> Song_Liu: team sharing time?
Sep 18 15:44:24 <sgw> Sharing?
Sep 18 15:44:34 <darknighte> sgw: heh.  jinx.
Sep 18 15:47:27 <blloyd> grrr: looking at denzil source I don't know how I got my package to build.  It has the same requirement.  But I swear this package built.
Sep 18 15:50:02 <Jefro> oh, the humanity!
Sep 18 15:50:47 <darknighte> Jefro: you didn't!
Sep 18 15:51:07 <Jefro> sorry
Sep 18 15:56:21 <darknighte> halstead: had to drop right as you were talking about slicehost.  Please let me know if I can help.
Sep 18 15:59:00 <moolinex> YPTM: thanks, bye
Sep 18 16:00:17 <halstead> darknighte, sure. Thank you.
Sep 18 16:01:04 <Song_Liu> darknighte: maybe we can plan a joined celebration with Mentor for 1.3. What do you think?
Sep 18 16:01:42 <Song_Liu> YPTM: thanks to everyone for joining the meeting. You guys have a nice day/evening!
Sep 18 16:02:00 <blloyd> scottrif: regarding docs: a while back (two months) I had an issue with bitbake.  Anyways, a new option had been added that could be used to troubleshoot the problem.  No mention of it in work or current docs, but the copy built from source did.
Sep 18 16:04:51 <blloyd> I don't remember who suggested I use the option (got that info via this channel) or who suggested rebuilding the docs from source for bitbake
Sep 18 16:59:05 <andyross> Is downloads.yoctoproject.org/mirrors/sources stale?  I'm doing a poky build and it's repeatedly stalling (and ultimately failing) on a svn checkout of eglibc.  It looks like oe-core commit 45c421563 (yocto 5b8e46dbd) bumped the svn version to 20393 about 3 weeks ago, but the mirrors don't have the file.  Am I doing something dumb?
Sep 18 17:32:07 <sgw> halstead: see andyross's comment above
Sep 18 17:32:17 <halstead> Looking.
Sep 18 17:38:08 <andyross> FWIW, it looks like the last two eglibc bumps failed.  There is a rev 19922 that's also missing.  I've reverted the two commits (yocto 91746bab and 5b8e46db) and am trying again.  The one previous to that is 19383 and appears to be present on the mirrors.
Sep 18 17:41:29 <bluelightning> that might explain part of bug 3119
Sep 18 17:45:10 <andyross> The core problem is that www.eglibc.org/svn is hugely slow (at least for me).  I get through about 50-100MB at just-barely-above-modem speed and then it inevitably dies with a timeout.  So if the mirrors are pulling the same way they might not be able to make it work either.  Is it possible to seed manually from a working build tree?
Sep 18 17:46:21 * andyross wonders idly if the reason for eglibc.org slowness is a thundering herd of poky builds doing unmirrored checkouts...
Sep 18 17:51:35 <msm`> zenlinux: ping
Sep 18 17:52:18 * andyross updates bug #3119
Sep 18 18:04:52 <halstead> andyross, I see some packages built from 20393 starting on August 31st. Continuing to look into it.
Sep 18 18:05:14 <halstead> andyross, Also expect eglibc to speed up enormously later this week.
Sep 18 18:07:10 <blloyd> while it's not the fastest server ever, eglibc is way over modem speeds from here.  And considering the poor internet I get at work...
Sep 18 20:29:06 <Flyser> Hi, I am having troubles compiling automake_1.12.3.bb from the 1.3_M4 branch with the following error: http://bpaste.net/show/46294/ what can I do?
Sep 18 20:44:07 <khem> andyross: eglibc.org should be hosted on same infra as yocto now
Sep 18 20:44:37 <khem> in future I think we should find a way to respin tar balls
Sep 18 20:44:53 <khem> which are then used as defualts by fetchers
Sep 18 20:49:10 <andyross> Cool, thanks.  Didn't realize you guys were taking over hosting eglibc.org.
Sep 18 20:53:06 <sgw> ag_: around?  Are you working on 2972?
Sep 18 21:01:09 <khem> andyross: http://www.yoctoproject.org/projects/eglibc
Sep 18 22:04:17 <reanguiano> andyross: Mentor/CodeSourcery handed over eglibc last year to TLF.
Sep 18 22:05:18 * reanguiano applauds all efforts to make eglibc infrastructure better (thanks halstead et all!)
Sep 18 22:06:57 <halstead> reanguiano, I'm looking forward to it too. They are helping me make sure we don't break anything in the move.
Sep 18 22:09:44 <msm`> sgw: hmm, i screwed something up on the patches i just sent - it's not showing as a series
Sep 18 22:11:13 <reanguiano> halstead: Good luck!  I'm only slightly curious about the new infrastructure.  Just a faster box or are you ditching subversion?
Sep 18 22:11:33 <halstead> reanguiano, Just much faster hardware for now.
Sep 18 22:11:41 <halstead> Bigger too.
Sep 18 22:14:27 <reanguiano> That would be the low hanging fruit.  Though subversion of that era does really poorly with large repos composed of many tiny files and no sharding.
Sep 18 22:15:42 <reanguiano> I think we made sure to turn on dir_index in the filesystem, but I don't know how much that helped.  No time to quantify.
Sep 18 22:21:02 <b1gtuna> Anyone familiar with kernel.bbclass? I'm trying to figure out what STAGING_KERNEL_DIR and some other variables are.
Sep 18 22:21:12 <b1gtuna> Help much appreciated.
Sep 19 00:25:23 <chackal_sjc> why everytime I compile connman bitbake is recompiling the cross-compiler and everything again?!
Sep 19 00:33:02 <Crofton> that seems odd
Sep 19 00:38:35 <chackal_sjc> yeah, but thats what happening
Sep 19 00:39:31 <Crofton> how are you rebuilding connman?
**** ENDING LOGGING AT Wed Sep 19 02:59:58 2012

**** BEGIN LOGGING AT Wed Sep 19 02:59:59 2012
Sep 19 08:24:59 <mdnneo> hi @ all ... I'm tring to reproduce https://wiki.yoctoproject.org/wiki/How_do_I#Q:_How_do_I_put_my_recipe_into_Yocto.3F but hello is not installed on the system? I followed all steps and bb hello works, any hints what i have done wrong?
Sep 19 08:47:14 <bluelightning> morning all
Sep 19 11:53:13 <ag_> Is there any comment in documentation or so that recipe's name must be lowercase?
Sep 19 12:46:05 <bluelightning> ag_: it's just convention; I don't believe there's a completely hard requirement
Sep 19 12:46:34 <bluelightning> ag_: but I don't think we would accept a recipe with upper-case letters in OE-Core or other OE layers
Sep 19 13:42:13 <ag_> bluelightning: My question targets a very interesting problem.
Sep 19 13:42:46 <ag_> It seems like qhen using ipk the build fails with:
Sep 19 13:42:52 <ag_> "Error: Package name contains illegal characters, (other than [a-z0-9.+-])"
Sep 19 13:43:08 <ag_> Which is true. Cause from ipk:
Sep 19 13:43:09 <ag_> Package:
Sep 19 13:43:10 <ag_> Name of the package. The name must match the regular expression [a-z0-9.+-]\+. Please note that uppercase letters are not permitted. Thus, e.g. package names like myNewSoftware are not permitted.
Sep 19 13:43:27 <ag_> So, we sould have a qa err for this don't you think so>
Sep 19 13:43:33 <bluelightning> ok, so opkg has chosen to make that a restriction (from debian maybe?)
Sep 19 13:43:56 <ag_> Probably...
Sep 19 13:45:06 <bluelightning> if it's going to fail later we should probably check earlier yes
Sep 19 13:45:46 <ag_> Yeah. Thank you.
Sep 19 13:46:29 <bluelightning> ag_: btw what happened with the echo -e issue in the end?
Sep 19 13:47:45 <ag_> bluelightning: I asked the mailing list, no answer, so i thought there is no interest in it. For me, i solved this with and extra echo in the script/
Sep 19 13:48:21 <bluelightning> ag_: I just noticed it definitely affects buildhistory on my system (which you already found at least with your search)
Sep 19 13:48:40 <bluelightning> so we should fix it I think
Sep 19 13:48:50 <bluelightning> I can fix buildhistory if you don't already have a patch
Sep 19 13:49:01 <ag_> I will do it tonight.
Sep 19 13:50:07 <bluelightning> ag_: thanks!
Sep 19 13:50:38 <ag_> bluelightning: No problem. It's good to recieve feedback when ppl send things on mailing list :)
Sep 19 13:50:47 <ag_> receive*
Sep 19 13:51:02 <bluelightning> ag_: sorry I had no objection so I didn't reply, I should have replied saying that :)
Sep 19 13:51:32 <ag_> bluelightning: https://github.com/djwillis/meta-raspberrypi/blob/master/classes/sdcard_image-rpi.bbclass
Sep 19 13:51:37 <ag_> Last line was the workaround
Sep 19 13:52:04 <bluelightning> ag_: was printf not suitable?
Sep 19 13:52:24 <ag_> it was. but i approved this as it wasn't my commit
Sep 19 13:52:30 <bluelightning> ah ok
Sep 19 13:52:43 <bluelightning> printf should be available everywhere as far as I can tell
Sep 19 14:00:22 <ag_> bluelightning: Indeed. That will be my fix in yocto
Sep 19 15:56:17 <b1gtuna> Hello! Anyone familiar with kernel.bbclass and image.bbclass? I have a problem =(
Sep 19 15:59:23 <ag_> b1gtuna: shoot
Sep 19 16:00:53 <msm`> any comments on a standard var to signify promotion of a 32-bit machine to build a 64-bit kernel?
Sep 19 16:03:41 <b1gtuna> ag_, My image does not get depmodded during bitbake
Sep 19 16:03:54 <b1gtuna> ag_, so when I first boot up, no modules are loaded as per ldmod.
Sep 19 16:04:32 <b1gtuna> ag_, I tracked down the issue and it looks like STAGING_KERNEL_DIR does not have a subdir called kernel, which should contain a file name called System.map
Sep 19 16:06:23 <b1gtuna> ag_, when I copy the files in IMAGE_ROOTFS dir (build/tmp/work/machine-name-poky-linux-gnueabi/linux-3.5/image/kernel), my image loads up the modules on the first boot fine.
Sep 19 16:06:58 <b1gtuna> ag_, btw IMAGE_ROOTFS contains a bunch of file along with System.map
Sep 19 16:07:07 <ag_> b1gtuna: I didn't say i can help. :)
Sep 19 16:07:18 <ag_> b1gtuna: Let me check you lines :)
Sep 19 16:07:23 <b1gtuna> ag_, hahahaha alright. No wories
Sep 19 16:07:30 <ag_> your*
Sep 19 16:07:35 <ag_> b1gtuna: :)
Sep 19 16:08:37 <ag_> b1gtuna: First of all. What machine and what distro?
Sep 19 16:08:44 <ag_> b1gtuna: Yocto?
Sep 19 16:10:50 <b1gtuna> Hm I'm on Yocto tracking Denzil
Sep 19 16:11:04 <b1gtuna> I'm compiling for Gumstix Overo series COMs. So OMAP3
Sep 19 16:11:39 <ag_> So in STAGING_KERNEL_DIR do you have /kernel-abiversion
Sep 19 16:11:42 <ag_> ?
Sep 19 16:11:56 <b1gtuna> I have my meta-layer in https://github.com/adam-lee/meta-gumstix
Sep 19 16:12:04 <b1gtuna> nope there is no kernel dir at all
Sep 19 16:12:11 <b1gtuna> oops
Sep 19 16:12:17 <b1gtuna> yes in STAGING_KERNEL_DIR yes I do
Sep 19 16:12:42 <b1gtuna> argg too early int he morning, I meant IMAGE_ROOTFS
Sep 19 16:12:50 <ag_> ok.
Sep 19 16:12:51 <b1gtuna> so STAGING_KERNEL_DIR does not exist
Sep 19 16:13:14 <b1gtuna> copy things from IMAGE_ROOTFS -> STAGING_KERNEL_DIR = happiness
Sep 19 16:13:48 <ag_> b1gtuna: so the problem is that in staging you don't have the sources right?
Sep 19 16:14:11 <ag_> sources = headers
Sep 19 16:14:23 <ag_> && other stuff
Sep 19 16:14:43 <b1gtuna> hmm if waht you mean is the headers/sources/others in kernel dir, I have nothing
Sep 19 16:14:50 <b1gtuna> So yes that's the problem.
Sep 19 16:15:09 <b1gtuna> FATAL: Could not open '/home/ubuntu/gumstix/adam_yocto/build/tmp/sysroots/overo/kernel/System.map-3.5.0': No such file or directory
Sep 19 16:15:48 <b1gtuna> ^ is what I get. I guess it's not fatal enough to halt bitbake
Sep 19 16:15:56 <ag_> on work / tmp / overo.... / kernel.../image/usr/src/kernel
Sep 19 16:16:09 <ag_> do you have that path above?
Sep 19 16:17:27 <b1gtuna> hm in /tmp dir, I don't have anything that pertains to the machine?
Sep 19 16:17:46 <b1gtuna> arg 1 sec
Sep 19 16:18:26 <ag_> {BUILDDIR}/tmp/work/machine-..../?
Sep 19 16:18:59 <b1gtuna> you meant /tmp/work/overo.../ I have 9 DIRs.
Sep 19 16:19:14 <b1gtuna> I think gumstix-xfce-image and linux-3.5 are important
Sep 19 16:19:34 <b1gtuna> gumstix-xfce-image does not contains kernel dir.
Sep 19 16:19:43 <ag_> so you are using lonux sakiman 3.5 right?
Sep 19 16:19:51 <b1gtuna> It only has pseudo, rootfs, and temp.
Sep 19 16:19:56 <b1gtuna> yup
Sep 19 16:20:01 <ag_> linux*
Sep 19 16:20:06 <b1gtuna> that's correct.
Sep 19 16:20:21 <ag_> Inside linux's WORKDIR/image do you have usr/src?
Sep 19 16:21:26 <ag_> usr/src/kernel?
Sep 19 16:21:52 <b1gtuna> in build/tmp/work: all-poky-linux  all-poky-linux-gnueabi  armv7a-vfp-neon-poky-linux-gnueabi  overo-poky-linux-gnueabi  x86_64-linux
Sep 19 16:21:55 <msm`> is there a standard way to turn on/off dhcp?
Sep 19 16:22:15 <ag_> b1gtuna: In overo.... / linux..../image
Sep 19 16:22:53 <b1gtuna> ah yes yes.
Sep 19 16:23:10 <ag_> good in image do you have /usr/src/kernel?
Sep 19 16:23:23 <b1gtuna> ag_: it has all the files such as System.map and kernel-abiversion
Sep 19 16:23:48 <ag_> What do you have in sysroot-destdir?
Sep 19 16:23:53 <b1gtuna> hm in linux-3.5/image/usr/src, I have one dir: linux-3.5.0
Sep 19 16:24:06 <ag_> well that is the problem
Sep 19 16:24:56 <b1gtuna> Sorry sysroot-destdir is located where?
Sep 19 16:25:09 <ag_> at the same level with image
Sep 19 16:25:16 <b1gtuna> ag_: hmm so my kernel dir should have /usr/src/kernel dir?
Sep 19 16:26:09 <b1gtuna> ag_: in linux-sakoman-3.5 deploy-linux-sakoman  image  logo_linux_clut224-generic.ppm  packages-split  pseudo   temp
Sep 19 16:26:18 <b1gtuna> ag_: defconfig             git    license-destdir                 package         pkgdata  shlibs
Sep 19 16:26:25 <b1gtuna> so no I don't have sysroot-destdir
Sep 19 16:27:44 <ag_> Strangely it seems like your kernel is not installed.
Sep 19 16:28:04 <b1gtuna> ag_: hmm is kernel.bbclass responsible for that?
Sep 19 16:28:11 <ag_> Because i checked denzil and the kernel source dir gets copied
Sep 19 16:28:29 <ag_> Check line 157 from kernel.bbclass
Sep 19 16:28:29 <b1gtuna> ag_: can you tell me the lines?
Sep 19 16:28:51 <b1gtuna> ag_: it's probable that i did something stupid, but at the moment I'm up against a wall.
Sep 19 16:29:02 <ag_> b1gtuna: I know the feeling. :)
Sep 19 16:29:14 <ag_> b1gtuna: Let's try something esle.
Sep 19 16:29:19 <b1gtuna> ag_: haha thank you sir ;)
Sep 19 16:29:41 <ag_> b1gtuna: bitbake virtual/kernel -c install -f
Sep 19 16:29:59 <b1gtuna> ag_: should i do bitbake -c cleansstate virtual/kernel first?
Sep 19 16:30:04 <ag_> no
Sep 19 16:30:12 <ag_> we will force an install
Sep 19 16:30:17 <b1gtuna> ag_: kk. Doing it now.
Sep 19 16:36:20 <b1gtuna> ag_: it finished, yet still no sysroot-destdir in linux-sakoman-3.5
Sep 19 16:36:51 <ag_> in install still no /usr/src/kernel
Sep 19 16:36:52 <ag_> ?
Sep 19 16:37:35 <ag_> check for KERNEL_SRC_PATH: bitbake -e virtual/kernel | grep KERNEL_SRC_PATH
Sep 19 16:37:58 <b1gtuna> ag_: this exsists - /build/tmp/work/overo-poky-linux-gnueabi/linux-sakoman-3.5-r0/image/usr/src$
Sep 19 16:38:19 <ag_> and /kernel
Sep 19 16:39:19 <b1gtuna> yes /kernel is in linux-sakoman-3.5-r0/image/
Sep 19 16:39:51 <b1gtuna> hmmmm bitbake -e virtual/kernel | grep KERNEL_SRC_PATH returns nothing 0_0?
Sep 19 16:40:31 <ag_> b1gtuna: maybe things work differently in denzil. I know how thing should work on master....
Sep 19 16:40:42 <ag_> b1gtuna: maybe somebody who works on denzil can help you
Sep 19 16:41:06 <b1gtuna> ag_: I see. I did try to build my image with master, but a lot of things broke
Sep 19 16:41:14 <b1gtuna> ag_: thanks for your help btw ;)
Sep 19 16:41:15 <ag_> i bet
Sep 19 16:41:24 <ag_> let's try something
Sep 19 16:41:31 <ag_> i will start a build with that kernel
Sep 19 16:41:40 <ag_> i'm working on something but i can let a build working
Sep 19 16:41:48 <b1gtuna> ag_: sweet that would be great :)
Sep 19 16:42:50 <ag_> b1gtuna: I will use: git://github.com/squirly/meta-gumstix.git
Sep 19 16:43:06 <b1gtuna> ag_: hmm that's outdated
Sep 19 16:43:20 <ag_> b1gtuna: Ok. i will use yours
Sep 19 16:43:28 <ag_> b1gtuna: git://github.com/adam-lee/meta-gumstix.git
Sep 19 16:43:58 <b1gtuna> ag_: yup I built upon squirly/meta-gumstix, but mine resembles Sakoman's xfce image
Sep 19 16:44:39 <bluelightning> I thought the canonical meta-gumstix was http://gitorious.org/schnitzeltony-oe-meta/meta-gumstix/
Sep 19 16:44:46 <b1gtuna> ag_: I am having the same result with Steve's image - http://www.sakoman.com/cgi-bin/gitweb.cgi?p=meta-sakoman.git;a=tree
Sep 19 16:45:19 <b1gtuna> bluelightning: hm we are trying to reboot meta-gumstix =D
Sep 19 16:45:52 <bluelightning> b1gtuna: have you spoken to Andreas Muller?
Sep 19 16:46:09 <b1gtuna> bluelightning: Nope. But the name seems very familiar.
Sep 19 16:46:27 <bluelightning> b1gtuna: he's the maintainer of the layer I just linked to, and seems to be keeping it up-to-date...
Sep 19 16:46:52 <b1gtuna> bluelightning: hmmmmm.....
Sep 19 16:47:06 <ag_> b1gtuna: schnitzeltony@googlemail.com
Sep 19 16:47:30 <b1gtuna> bluelightning: I didn't take a look at it. Perhaps I should've.
Sep 19 16:47:52 <b1gtuna> ag_: thanks. I will write him an email. I should try his meta-gumstix too.
Sep 19 16:48:35 <bluelightning> I'd recommend it, the ideal thing would be to avoid having more than one layer for the same thing
Sep 19 16:50:22 <b1gtuna> bluelightning: Yes that is very true. Do you know if Andreas pulls from Steve Sakoman's kernel repo?
Sep 19 16:50:36 <ag_> b1gtuna: Check his layer.
Sep 19 16:50:56 <b1gtuna> ag_: kk
Sep 19 16:51:25 <ag_> b1gtuna: ANd by the way you have a lot of bbappends broken in that layer.
Sep 19 16:51:37 <ag_> b1gtuna: So the best thing would be to check Andreas's layer.
Sep 19 16:54:30 <b1gtuna> ag_: Hmm what do you mean by broken bbappends?
Sep 19 16:54:44 <ag_> b1gtuna: outdated with master
Sep 19 16:55:25 <ag_> that's why yo can't start a build with master. renaming those to match the upstream would fix this. but as bluelightning said.... is duplicated work most probably
Sep 19 16:55:28 <ag_> you&
Sep 19 16:55:29 <b1gtuna> ag_: hmmm sorry I'm still pretty noob at this =P. Can you point me to a bbappen that's broken/outdated?
Sep 19 16:55:45 <ag_> /home/agherzan/work/personal/yocto/meta-gumstix/recipes-connectivity/networkmanager/networkmanager_0.9.2.0.bbappend
Sep 19 16:55:45 <ag_>   /home/agherzan/work/personal/yocto/meta-gumstix/recipes-core/systemd/systemd_git.bbappend
Sep 19 16:55:45 <ag_>   /home/agherzan/work/personal/yocto/meta-gumstix/recipes-core/base-passwd/base-passwd_3.5.24.bbappend
Sep 19 16:55:45 <ag_>   /home/agherzan/work/personal/yocto/meta-gumstix/recipes-core/netbase/netbase_4.47.bbappend
Sep 19 16:55:45 <ag_>   /home/agherzan/work/personal/yocto/meta-gumstix/recipes-core/gawk/gawk_4.0.0.bbappend
Sep 19 16:55:49 <b1gtuna> ag_: I see. I'm trying to stablize on denzil at the moment.
Sep 19 16:56:35 <bluelightning> b1gtuna: I don't know what the relationship is between Steve Sakoman's kernel repo and Andreas's meta-gumstix, no
Sep 19 16:56:44 <b1gtuna> ag_: I see. I will fix those soon, unless they are causing this missing kernel source issue?
Sep 19 16:57:06 <b1gtuna> bluelightning: ok thanks for letting me know
Sep 19 16:57:11 <ag_> b1gtuna: obviously not but will get you going with master
Sep 19 16:58:12 <b1gtuna> ag_: right. I guess I have more work to do. awesome =D
Sep 19 16:58:38 <ag_> b1gtuna: If i were you i would listen to bluelightning . Use that repo!
Sep 19 16:58:53 <b1gtuna> ag_: hmm the thing is
Sep 19 16:59:27 <b1gtuna> ag_: Steve is the CTO of Gumstix and Andreas seems to be a client who does a lot of nice things on Gumstix COMs
Sep 19 17:00:18 <b1gtuna> ag_: and I'm currently working for Gumstix, so my inclination is to follow Steve's direction and build a meta-gumstix inspired on his meta layer
Sep 19 17:01:05 <b1gtuna> ag_: At the moment Gumstix doesn't have a solid meta-gumstix. We are trying to better support Yocto.
Sep 19 17:02:14 <ag_> b1gtuna: good luck then
Sep 19 17:03:55 <Flyser> How can I find out which dependencies would be installed if I run bitbake somepackage?
Sep 19 17:04:05 <b1gtuna> ag_: I'm still learning. How does a meta layer get onto the layer index?
Sep 19 17:05:29 <b1gtuna> Flyser: http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#usingpoky-debugging-dependencies
Sep 19 17:05:32 <ag_> b1gtuna: .. you don;t read the documentation right?
Sep 19 17:06:06 <ag_> :)
Sep 19 17:07:04 <Flyser> b1gtuna: thanks
Sep 19 17:07:45 <b1gtuna> ag_: lol I will probably have to read the docs a couple more times before things start clicking
Sep 19 17:08:01 <b1gtuna> ag_: any docs you are specifically referring to?
Sep 19 17:08:04 <ag_> b1gtuna: :) so you are asking how to add a layer to your build?
Sep 19 17:08:43 <b1gtuna> ag_:  no i meant how does a meta layer gets listed in the layer index located in yocto project's website
Sep 19 17:10:03 <ag_> b1gtuna: Here http://git.yoctoproject.org/ ?
Sep 19 17:10:26 <b1gtuna> ag_: http://www.openembedded.org/wiki/LayerIndex
Sep 19 17:10:56 <ag_> b1gtuna: dunno who edits that wiki page
Sep 19 17:10:58 <b1gtuna> ag_: seeing there is already meta-gumstix maintained by Andreas, not sure what the best way to go from here.
Sep 19 17:11:03 <b1gtuna> ag_: okk
Sep 19 17:11:16 <b1gtuna> ag_: how's the build going?
Sep 19 17:11:39 <ag_> b1gtuna: dropped. i'm waiting for some fixes for those bbappends. :)
Sep 19 17:11:57 <b1gtuna> ag_: haha alright
Sep 19 17:14:43 <ag_> b1gtuna: In adreas's layer you have linux-sakoman_3.2.bb
Sep 19 17:14:56 <ag_> b1gtuna: isn't that what you are looking for?
Sep 19 17:16:22 <b1gtuna> ag_: I'm trying to use kernel 3.5, which Steve released http://bit.ly/Vd7IDw
Sep 19 17:17:39 <ag_> b1gtuna: things get ugly for me. what is meta-sakoman and meta-gumstix?
Sep 19 17:18:25 <b1gtuna> ag_: ahhh my bad. Didn't mean to confuse you. I get tunnel vision when I get stuck on an issue for too long.
Sep 19 17:18:56 <b1gtuna> ag_: meta-gumstix was designed with meta-sakoman as the basis
Sep 19 17:19:15 <b1gtuna> ag_: meta-gumstix's recipe-kernel is pulled from meta-sakoman's.
Sep 19 17:19:51 <b1gtuna> ag_: I see Andrea's has a recipe for kernel 3.5. I believe all the patches in that recipe has been already applied in Sakoman's kernel.
Sep 19 17:21:19 <b1gtuna> ag_: Like you suggested, I think it's worthwhile to check out Andrea's repo. Doing it now.
Sep 19 17:22:47 <ag_> b1gtuna: good
Sep 19 17:59:14 <msm`> zenlinux: around?
Sep 19 18:19:03 <msm`> how does one remove tasks?
Sep 19 18:19:08 <msm`> for example do_compile
Sep 19 18:19:12 <msm`> do we just insert a blank one?
Sep 19 18:19:38 <khem> pretty much yes
Sep 19 18:25:40 <msm`> k, or not have a Makefile works too
Sep 19 18:40:11 <otavio> Hi folks!
Sep 19 18:40:49 <kergoth> that do nothing if no makefile behavior kind of bugs me. it's quite common to forget to adjust S and end up with do_compile successfully completing a no-op.
Sep 19 18:41:18 <kergoth> s/do/"do/; s/makefile/makefile"/
Sep 19 18:43:03 <JaMa> yes or do_package sometimes creating empty packages with missing install dir (even without ALLOW_EMPTY :/)
Sep 19 19:17:44 <zenlinux> msm`, sorry, I was working from my laptop as zenlinux_ when you pinged me earlier
Sep 19 19:21:01 <zenlinux> msm`, heading out for a lunchtime run, will be around this afternoon for questions
Sep 19 19:23:04 <msm`> zenlinux: no problem
Sep 19 20:39:51 <zenlinux> msm`, back
Sep 19 20:40:34 <otavio> I am trying to solve a issue in mesa and closed gl implementation
Sep 19 20:41:38 <otavio> The biggest problem is that the gl implementation from FSL only does GL ES2
Sep 19 20:41:44 <otavio> and not GL
Sep 19 20:41:53 <otavio> so mesa-demos fail to build
Sep 19 20:46:41 <msm`> zenlinux: i was seeing an issue on denzil-next w/ atom-pc machine
Sep 19 20:46:46 <msm`> some bzImage not found
Sep 19 20:46:57 <msm`> i just rebased, so im going to rebuild again in a few hours and see if I see it again
Sep 19 20:47:18 <zenlinux> msm`, yes, I have seen this error too when I did an autobuilder run two weeks ago, I don't think it's fixed yet
Sep 19 20:47:39 <msm`> zenlinux: ok
Sep 19 20:47:59 <msm`> zenlinux: i think that was all i was going to say, all the other patches look up to date now ;)
Sep 19 20:48:14 <zenlinux> msm`, have you rebased from my denzil-next branch as of a few hours ago?
Sep 19 20:48:23 <zenlinux> I've been piling on commits to it in the last 24h
Sep 19 20:48:25 <msm`> zenlinux: oh right, i was going to ask it looks like you dropped 4 patches or so
Sep 19 20:48:33 <msm`> yea, i rebased just a few hours ago
Sep 19 20:48:52 <msm`> zenlinux: no comment on those, just asking
Sep 19 20:48:56 <zenlinux> msm`, yes, I dropped the commits which fixed the kernel menuconfig error - talking with bluelightning we need to take a different approach to fix that
Sep 19 20:49:51 <msm`> zenlinux: k
Sep 19 20:50:04 <msm`> sgw: hey, i see those replies on yocto-builds but I don't see the original emails! ;)
Sep 19 20:51:04 <otavio> msm`: got the dhcp one?
Sep 19 20:51:32 <otavio> grr
Sep 19 20:51:36 <otavio> zenlinux: ^
Sep 19 20:51:38 <otavio> :)
Sep 19 20:52:25 <sgw> msm`: really?  your seeing the replies, but not the originals?  Spam filter? halstead might be a better person to ask!
Sep 19 20:52:36 <zenlinux> otavio, yep, should be this, right? http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=sgarman/denzil-next&id=29474643ed789e0d74d58e108dee9b3d04635fca
Sep 19 20:52:51 <zenlinux> I added your SOB line as requested
Sep 19 20:53:08 <otavio> zenlinux: thx a lot!
Sep 19 20:53:11 <otavio> zenlinux: perfect
Sep 19 20:53:14 <zenlinux> no prob
Sep 19 20:53:58 <sgw> zenlinux: BTW, if you need some build time, I think you can do it after I run a mut (run a muck?)  after RC1 completes, so later this evening.
Sep 19 20:54:30 <zenlinux> sgw, excellent, I'll take you up on that
Sep 19 20:54:35 <msm`> sgw: mail server could be blocking
Sep 19 20:54:39 <msm`> sgw: its not in span
Sep 19 20:55:09 <zenlinux> sgw, do I still need to add those extra commits for the build appliance SRCREV, or have there been any autobuilder changes to make that unnecessary now?
Sep 19 20:56:32 <sgw> zenlinux: yes, you still need to manually bump SRCREV, that should be the only commit needed as far as I know!
Sep 19 21:06:27 <msm`> will buildhistory clone an already existing BUILDHISTORY_PUSH_REPO?
Sep 19 21:06:36 <msm`> as in clone, commit, push
Sep 19 21:56:14 <bluelightning> msm`: no
Sep 19 21:56:47 <bluelightning> you'd need to do that manually beforehand (or script it)
Sep 19 21:59:56 <kergoth> anyone ever seen this one? https://gist.github.com/3752576
Sep 19 22:06:45 <msm`> bluelightning: BUILDHISTORY_CLONE_REPO ?
Sep 19 22:08:03 <khem> kergoth: I remember having seen it
Sep 19 22:08:14 <khem> then I changed my shell dash->bash and it worked
Sep 19 22:08:22 <khem> It was with angstrom IIRC
Sep 19 22:08:42 <kergoth> hmm, interesting, i thought bash as /bin/sh wasn't required anymore
Sep 19 22:08:53 <khem> no it isnt in OE-Core
Sep 19 22:09:12 <khem> but then there might be some crap going on when you put other layers on top
Sep 19 22:09:17 <kergoth> ah, fair point
Sep 19 22:09:21 <kergoth> worth a shot, anyway
Sep 19 22:09:23 <khem> I did not bother to look into details
Sep 19 22:09:41 <kergoth> damn, no such luck, this box is arch, /bin/sh is bash already
Sep 19 22:09:48 * kergoth mutters and pokes at opkg-build
Sep 19 22:11:51 <kergoth> http://geoff.greer.fm/2011/12/27/the-silver-searcher-better-than-ack/ <-highly recommended
Sep 19 22:17:31 <msm`> would it also be easier to have a BUILDHISTORY_GIT_BRANCH too?
Sep 19 22:20:01 <kergoth> i wish there was a portable way to get the name of the shell script you're sourcing
Sep 19 22:21:57 <kergoth> god, this vm is so slow i think i need to switch back to the signature handler that doesn't include sstate checksums in the stamps
Sep 19 22:22:54 <kergoth> note: oe/poky builds inside a linux vm on a macbook air running osx = not so speedy ;)
Sep 19 22:28:15 <zenlinux> kergoth, at least you're presumably running it on an SSD - imaging how much slower it would be on a spinning disk!
Sep 19 22:28:25 * kergoth nods
Sep 19 22:29:28 <otavio> :)
Sep 19 22:29:39 * otavio has a macbook air too :) 
Sep 19 22:29:49 <otavio> kergoth: but I am using Debian on it
Sep 19 22:29:52 <otavio> :D
Sep 19 22:29:53 <kergoth> i'm so sick of my loud, heat generating beast of a desktop that i'm trying to use this for as much as possible
Sep 19 22:30:14 <kergoth> tempting to buy a mini-itx or mac mini or something and use that as a soso-performing compile box
Sep 19 22:30:15 <kergoth> heh
Sep 19 22:30:49 <otavio> kergoth: put a huge i7 machine in another room and use ssh
Sep 19 22:30:50 <otavio> ;)
Sep 19 22:30:58 <zenlinux> I'm running Ubuntu 12.04 on a 2012 MBA, but I find it runs so hot during builds that I use a daemon to put the CPU into powersave mode temporarily when the temp gets above 90 C
Sep 19 22:31:07 <kergoth> i'd probably hear the thing turning on even if it is in another room :)
Sep 19 22:31:14 <kergoth> zenlinux: wow, damn
Sep 19 22:31:22 <zenlinux> generally I avoid running builds on it at all, and ssh/screen to a desktop system instead
Sep 19 22:31:38 * kergoth nods
Sep 19 22:31:51 <zenlinux> the thing is, the MBA fans are working properly, they ramp up to max speed, around 6500k rpm
Sep 19 22:31:56 <kergoth> a compile here and there is no big deal, but oe/poky is not a compile here and there, it's a compile everywhere :)
Sep 19 22:32:02 <zenlinux> but the system keeps getting hotter
Sep 19 22:32:04 <kergoth> huh, interesting
Sep 19 22:32:27 <zenlinux> I've had some people tell me that their Ivy Bridge i7 MBAs also get ridiculously hot
Sep 19 22:32:42 <otavio> zenlinux: mine is Ivy
Sep 19 22:32:46 <zenlinux> I just don't see how 100 C could be safe
Sep 19 22:32:46 <otavio> zenlinux: it does indeed
Sep 19 22:33:27 <kergoth> mine is a mid '11 i5
Sep 19 22:33:29 <kergoth> heh
Sep 19 22:33:31 * zenlinux wishes he held out for the Thinkpad X1 Carbon instead, that's  beaut of a laptop
Sep 19 22:34:03 <kergoth> i wish i'd held out for the next mbp
Sep 19 22:37:35 <bluelightning> msm`: you can specify that in the BUILDHISTORY_PUSH_REPO - it's just a fragment that gets passed to git after all
Sep 19 22:41:45 <kergoth> hmm, would be nice if hob sorted the log display so the active tasks were in one place
Sep 19 22:41:48 <kergoth> rather than scattered
Sep 19 23:09:46 <otavio> zenlinux: did you see a xserver-xorg-lite build failure?
Sep 19 23:09:52 <otavio> zenlinux: or a fix for it?
Sep 19 23:12:46 <zenlinux> otavio, for denzil? it's not ringing a bell
Sep 19 23:13:01 <zenlinux> I'm hoping to run my current denzil-next branch on our autobuilder overnight, and will have some data from that in the morning
Sep 19 23:17:11 <otavio> zenlinux: I am building test it now; let's see if it changes something
Sep 19 23:19:50 <kergoth> .. qemu is the biggest package i have installed on this linux box
Sep 19 23:19:51 * kergoth shakes head
Sep 19 23:20:53 <khem> kergoth: you mean size wise ?
Sep 19 23:22:32 <kergoth> yeah
Sep 19 23:22:45 <kergoth> bigger than gcc, etc :)
Sep 19 23:25:54 <khem> on target ?
Sep 19 23:26:16 <khem> may be you can control the size by removing not needed ports
Sep 19 23:26:57 <khem> QEMU_TARGETS ?= "arm i386 mips mipsel mips64 mips64el ppc sh4 x86_64"
Sep 19 23:27:01 <khem> is too much may be
Sep 19 23:27:07 <khem> you can curtail it a bit
Sep 19 23:27:41 <kergoth> true
Sep 19 23:32:35 <khem> I just keep x86_64 since thats what I care about e.g.
**** ENDING LOGGING AT Thu Sep 20 02:59:57 2012

**** BEGIN LOGGING AT Thu Sep 20 02:59:58 2012
Sep 20 05:40:55 <fsarbu> hi everybody
Sep 20 05:41:40 <fsarbu> anybody having issues with do_fetch for gcc-cross-initial-4.7.1.0?
Sep 20 06:00:50 <moolinex> fsarbu: issues? is there an error? or it just sits there in do fetch? gcc takes longer to be fetched
Sep 20 06:03:52 <fsarbu> well, currently just sits forever as far as I can see
Sep 20 06:05:22 <fsarbu> moolinex: there was a discussion about making it fetch from svn
Sep 20 06:05:32 <fsarbu> as far as I can see, it still goes for the git repo
Sep 20 06:06:33 <fsarbu> I'll be darned, it just finished the fetch :)
Sep 20 06:06:37 <fsarbu> it took a little
Sep 20 06:06:53 <moolinex> see if you have a wget process, it might fetch the tarball
Sep 20 06:06:54 <fsarbu> but yesterday, I've had it do_fetch'ing for a few hours
Sep 20 06:07:02 <moolinex> oh well, nevermind :)
Sep 20 06:07:53 <fsarbu> would be nice to have merged khem's patch for using the svn repo for gcc
Sep 20 06:10:14 <moolinex> i'm not about svn, svn could be a pain for some environments, i would go for git from the github mirror, for gcc at least
Sep 20 06:10:23 <moolinex> i'm not sure*
Sep 20 06:18:24 <fsarbu> thing is, git is so big, that under some poor network environment it might take long enough for the do_fetch to be considered stalled, and eventually crash the build process
Sep 20 06:33:19 <kergoth> tasks aren't ever considered "stalled", from bitbake's perspective. if the tool it calls times out and returns a failure code, then sure, but otherwise no
Sep 20 07:28:55 <mertsas> Hi. I want to enable plymouth on my device, but I can't find any recipe for it in oe-core or meta-oe. Any ideas as to a layer which contains it?
Sep 20 08:01:17 <fsarbu> khem: hi, have something not clear related to binutils
Sep 20 08:01:50 <fsarbu> or to anybody who would have any idea for that matter :)
Sep 20 08:02:27 <fsarbu> so here goes: I've added ld-is-gold to my DISTRO_FEATURES, so binutils is creating ld.gold as expected
Sep 20 08:02:53 <fsarbu> thing is, in sysroot, the ld symlink does not point to ld.gold, but remains to the regular cross ld
Sep 20 08:03:32 <fsarbu> wouldn't --enable-gold=default from binutils.inc make the ld point to cross ld.gold?
Sep 20 08:05:52 <fsarbu> kergoth: I would expect that to be the case, but had a few experiences with the do_fetch issue for gcc so can't really tell myself how bitbake handles these large transfers; anyway, to be seen :)
Sep 20 08:16:01 <gotan> hi
Sep 20 08:17:03 <gotan> I'm having trouble packaging up a kernel module. or rather, its generating some packages, but not creating the main package
Sep 20 08:21:17 <gotan> if i add an explicit rule to my recipie, bitbake breaks, which implies there is a special mechanism for kernel modules, and its not confiured properly.
Sep 20 08:37:26 <gotan>  # install packages do_install_append() {     # create sbin target directorie(s) 	install -d ${D}${base_sbindir}/modules/      # copy module to sbin 	install -m 0644 ${S}/src/pbmod.ko ${D}${base_sbindir}/modules/ }   ERROR: Error executing a python function in /mnt/oldhome/home/timoc/yocto/mcgraw-yocto/meta-mcgraw/recipes-kernel/kmod-cif/kmod-cif_2.622.bb: TypeError: unsupported operand type(s) for &: 'NoneType' and 'int'  ERROR: The s
Sep 20 09:16:11 <bluelightning> morning all
Sep 20 09:28:05 <fsarbu> bluelightning: hi
Sep 20 09:28:17 <bluelightning> hi fsarbu
Sep 20 09:28:19 <fsarbu> bluelightning: got a few spare minutes to clear something up for me?
Sep 20 09:28:25 <bluelightning> fsarbu: certainly
Sep 20 09:28:48 <fsarbu> bluelightning, it's about binutils and ld
Sep 20 09:29:16 <fsarbu> I've added ld-is-gold to my DISTRO_FEATURES, so binutils is creating ld.gold as expected
Sep 20 09:29:33 <fsarbu> but in the sysroot, the ld symlink does not point to ld.gold, but remains to the regular cross ld
Sep 20 09:30:06 <fsarbu> wouldn't --enable-gold=default from binutils.inc make the ld point to cross ld.gold?
Sep 20 09:31:10 <bluelightning> fsarbu: I would have thought so, but I have no experience with ld-is-gold I'm afraid
Sep 20 09:32:07 <fsarbu> bluelightning: okay, thanks
Sep 20 09:32:09 <bluelightning> fsarbu: khem might be the person to ask, when he's awake (assuming nobody else is able to answer the question)
Sep 20 09:32:59 <fsarbu> bluelightning: I'll bug khem, asked him already but I guess he must be sleeping now :)
Sep 20 11:46:57 <gotan> Hi, I'm having trouble with installing a module. the INSTALL_MODULE_PATH is not being set correctly. and when i try to manually copy the module somewhere in the image with do_install_append, the recipe script fails.
Sep 20 11:48:19 <gotan> I'm upping the logging in the kernel makefile etc to see if i can fix the issue, and applying the patch here: http://us.generation-nt.com/answer/patch-1-2-makefile-add-install-mod-path-environment-used-by-depmod-help-206718972.html
Sep 20 11:48:37 <gotan> to ensure the variable is exported properly, but still no luck.
Sep 20 13:10:09 <ignus> hello all, does anyone know why Yocto might install a kernel version and modules which don't match into my root fs?
Sep 20 13:44:39 <bluelightning> ignus: hi, that sounds very strange...
Sep 20 13:45:45 <bluelightning> ignus: is there anything indicated in the buildhistory dependency graphs that might explain it?
Sep 20 13:48:58 <ignus>  bluelightning; i'm not sure, how would i check?
Sep 20 13:51:43 <Flyser> How are the sdk images like http://downloads.yoctoproject.org/releases/yocto/yocto-1.2.1/toolchain/x86_64/poky-eglibc-x86_64-arm-toolchain-gmae-1.2.1.tar.bz2 built? and how can I do it myself (for my distribution and architecture)
Sep 20 13:51:46 <bluelightning> ignus: so is the kernel newer or the modules?
Sep 20 13:52:39 <bluelightning> Flyser: set SDKMACHINE as desired (if different from your host architecture) and then bitbake meta-toolchain-gmae for that specific file or just meta-toolchain for a more plain one
Sep 20 13:53:04 <Flyser> what does gmae stand for?
Sep 20 13:54:52 <Flyser> SDKMACHINE is a machine from conf/machine right?
Sep 20 13:56:05 <ignus> bluelightning: its very strange, the kernel is correct (3.5.0) but the modules are _way_ older (3.1.0rc4)
Sep 20 14:01:00 <khem> fsarbu: yes ld-is-gold should make gold as default ld
Sep 20 14:01:18 <bluelightning> Flyser: actually I think SDKMACHINE is just something that is valid to pass as a -m option to gcc
Sep 20 14:01:50 <bluelightning> Flyser: gmae = Gnome Mobile And Embedded
Sep 20 14:02:59 <bluelightning> Flyser: somewhat obsolete now, if you don't need the extra stuff it adds (see meta/recipes-core/meta/meta-toolchain-gmae.bb) then just use meta-toolchain instead
Sep 20 14:10:10 <Flyser> bluelightning: thanks! I will try :)
Sep 20 14:16:26 <eFfeM_work> hi, how can I enable a fetch during image build, just adding a SRC_URI does not work
Sep 20 14:18:01 <eFfeM_work> seems this line from image.bbclass is inhibiting it:
Sep 20 14:18:02 <eFfeM_work> do_fetch[noexec] = "1"
Sep 20 14:20:08 <fsarbu> khem: this looks like a issue, as it doesn't set it as default for me
Sep 20 14:27:59 <bluelightning> eFfeM_work: that is a rather annoying limitation I think; you should be able to set it to 0 but that does not work according to a poster on the list a few months ago; I think that is probably a bug
Sep 20 14:28:29 <bluelightning> eFfeM_work: there was a suggested workaround I believe, I don't have the thread handy though
Sep 20 14:28:54 <bluelightning> eFfeM_work: is it not appropriate to put this item into a package in this case?
Sep 20 14:29:17 <eFfeM_work> bluelightning: was peeking at http://ibot.rikers.org/%23oe/20120308.html.gz
Sep 20 14:29:35 <eFfeM_work> i could not set to 0
Sep 20 14:30:57 <eFfeM_work> what my oe classic recipe did was an image postprocess cmd to generate our own packet format (which is parameterized in a config file)
Sep 20 14:31:10 <eFfeM_work> s/packet/image/
Sep 20 14:31:44 <eFfeM_work> I could probably add my own IMAGE_FSTYPE for it but still I would need the parameter file
Sep 20 14:32:31 <eFfeM_work> this is what the oe log says: kergoth: solved it by copying the image.bbclass, removing the noexec  on fetch/unpack/patch, and adding "addtask rootfs before do_build after  do_patch", and using my new class.  I'm sure there's a better way  though.
Sep 20 14:33:25 <bluelightning> eFfeM_work: hmm that's pretty drastic
Sep 20 14:33:31 <eFfeM_work> yup
Sep 20 14:33:40 <eFfeM_work> haven't found an email thread on it yet
Sep 20 14:33:43 <bluelightning> eFfeM_work: if it's a real pain for you I would suggest filing a bug and then we can look at a proper fix
Sep 20 14:34:02 <bluelightning> eFfeM_work: actually I think I misremembered, the aforementioned IRC discussion was what I was thinking of :)
Sep 20 14:34:27 <eFfeM_work> bluelightning: reading http://list-archives.org/2012/08/08/bitbake-devel-lists-openembedded-org/making-a-noexec-task-executable-again/f/1945478441 now
Sep 20 14:37:09 <bluelightning> eFfeM_work: ah, that's a less nasty workaround
Sep 20 14:37:23 <bluelightning> eFfeM_work: I'd still like to see do_taskname[noexec] = "0" working though
Sep 20 14:37:38 <eFfeM_work> bluelightning: me too
Sep 20 14:38:47 <bluelightning> eFfeM_work: re custom image formats there is a plan to reorganise some of that for the next version to make it more extensible
Sep 20 14:38:59 <eFfeM_work> nice
Sep 20 14:39:12 <eFfeM_work> bluelightning: still not fully getting there, added this to my image recipe
Sep 20 14:39:13 <bluelightning> (see Mark Hatle's post to the mailing list recently)
Sep 20 14:39:13 <eFfeM_work> addtask fetch2
Sep 20 14:39:13 <eFfeM_work> do_fetch2[dirs] = "${DL_DIR}"
Sep 20 14:39:13 <eFfeM_work> python do_fetch2() {
Sep 20 14:39:13 <eFfeM_work> bb.build.exec_func(base_do_fetch)
Sep 20 14:39:13 <eFfeM_work> }
Sep 20 14:39:31 <eFfeM_work> but that did not suffice
Sep 20 14:39:50 <bluelightning> eFfeM_work: you may want to look at meta/recipes-core/images/build-appliance-image.bb for a working example
Sep 20 14:40:01 <bluelightning> (just found)
Sep 20 14:43:30 <eFfeM_work> peeking
Sep 20 14:43:39 <eFfeM_work> shouldn;t it actually be:
Sep 20 14:44:42 <eFfeM_work> do_fetch[noexec] ?= "1"
Sep 20 14:49:12 <bluelightning> eFfeM_work: I don't think that will work, I suspect the current check just looks to see if it exists as a varflag and does not look at the value
Sep 20 14:49:40 <bluelightning> I did try to dig into bitbake when the original discussion came up to see if I could fix it but it was not obvious to me how it was being read
Sep 20 14:49:50 <eFfeM_work> bluelightning: ok anyway adding a do_fetch2 task worked
Sep 20 14:52:02 <bluelightning> eFfeM_work: ok, just a thought though - I wonder if calling d.delVarFlag("do_fetch", "noexec") in an anonymous python function would work...
Sep 20 14:52:47 <eFfeM_work> bluelightning: not sure if that would happen at the right place (after it being set and before it being used)
Sep 20 14:53:04 <eFfeM_work> would probably have to be after the inherit image or so
Sep 20 14:54:38 <eFfeM_work> anyway it seems to work as is, calling it a day for now, thanks for your help bluelightning
Sep 20 15:02:39 <bluelightning> eFfeM_work: np
Sep 20 15:03:32 <kergoth> so.. i *think* this sourcery toolchain has eglibc looking in lib64 for t he libs but lib/locale for the binary locales (not lib64/locale). is this typical? expected? sane? does eglibc always do this? It makes sense, given the binary format is probably relatively independent. but all our libc packaging bits expect it to be in ${libdir}/locale
Sep 20 15:15:39 <kergoth> khem: ping
Sep 20 15:52:44 <msm`> im seeing some new errors in master: https://gist.github.com/3756740
Sep 20 15:52:58 <msm`> it looks like it might be related to binutils according to this: http://lists.gnu.org/archive/html/bug-binutils/2011-05/msg00043.html
Sep 20 15:53:06 <msm`> it only seems to have occured on my older centos box though
Sep 20 15:55:06 <msm`> or maybe not ;) really not sure yet
Sep 20 15:56:03 <msm`> actually, im not sure  that's my problem err ;)
Sep 20 15:56:07 <kergoth> hmm, from examining the configure scripts in eglibc, it looks like the binary locales should always go to ${exec_prefix}/lib/locale/ *if* ${libdir} is ${exec_prefix}/lib, rather than ${libdir}/locale. so all our libc packaging for locales could be wrong
Sep 20 15:56:10 * kergoth mutters
Sep 20 16:02:47 <msm`> kergoth: the joy's of locales ;)
Sep 20 16:03:02 <kergoth> :)
Sep 20 16:03:39 <kergoth> https://gist.github.com/3756705
Sep 20 16:03:40 <kergoth> heh
Sep 20 16:03:59 <kergoth> hmm
Sep 20 16:19:45 <kergoth> seebs: have you worked out a sane way to map oe multilib configuration to external toolchain multilib configuration (e.g. ensuring BASE_LIB_* are correct)?
Sep 20 16:22:29 <seebs> Not entirely. I'm currently about 65% happy with my TUNEABI stuff, which has evolved since what's in the tree a bit.
Sep 20 16:22:51 <seebs> The big thing I'm doing that's a change is separating TUNE_CCARGS into TUNEABI_CCARGS and TUNE_CCARGS.
Sep 20 16:26:00 <kergoth> external toolchains are really kind of a second class citizen right now, it'd be nice to really finish fleshing it out
Sep 20 16:26:04 <kergoth> heh
Sep 20 16:27:11 <seebs> I'm on vacation next week, sometime after that I'm hoping to submit the toolchain wrapper stuff I've been working on.
Sep 20 16:27:51 <seebs> The idea is to define a base set of ccargs, sysroot, etc. that must be present for building any target app, period, and have a wrapper that automatically provides those, then leave purely-tuning arguments to the build system to pass.
Sep 20 16:29:56 <seebs> So we might have an x86-wrsrap-linux-gnu-gcc which always passes -m32 --sysroot=.../sysroots/qemux86, but the build system is still responsible for -march=i686.
Sep 20 16:30:37 <seebs> The big utility value is command-line builds. It's a heck of a lot easier to do "make CROSS_COMPILE=x86-wrswrap-linux-gnu-" or just manually run x86-wrswrap-linux-gnu-gcc -o t t.c
Sep 20 16:31:07 <seebs> And somewhere in there, I want to add a sanity mode where the wrapper confirms that you passed in needed stuff (like the hash-style=gnu). :)
Sep 20 16:42:36 <kergoth> that seems slightly odd. if you know what should be passed, why make the caller do it? just pass it yourself. unless you want to ensure they pass some value for hash-style, but don't care what the value is..
Sep 20 17:04:49 <xxiao> msm`: ping
Sep 20 17:05:33 <xxiao> msm`: "make sure package 'merge-files' in the IMAGE_INSTALL list", do I really need do that?
Sep 20 17:23:43 <msm`> xxiao: for our SDK?
Sep 20 17:24:22 <msm`> if it's being used, and it's not in the image you selected it needs to be in IMAGE_INSTALL - but only if you have extra files you want included on the rfs
Sep 20 17:28:50 <xxiao> msm`: yes, for SDK1.2.x
Sep 20 17:29:24 <xxiao> i need add a few binaries there, i barely recall last time it worked without adding merge-files to IMAGE_INSTALL
Sep 20 17:30:15 <msm`> search the image you are using and see if it's there
Sep 20 17:30:31 <msm`> or use depexp or something similiar to see if it's in the image
Sep 20 17:31:01 <xxiao> will do, that is, after i fix my broken build atm
Sep 20 18:06:04 <msm`> is there a LICENSE = for something that does not have a license?
Sep 20 18:06:11 <msm`> something that is not copyrightable?
Sep 20 18:06:21 <msm`> like a series of numbers?
Sep 20 18:06:23 <msm`> in files
Sep 20 18:51:05 <kergoth> one of these days we need to think about how to improve the interaction of package buildhistory with shared state
Sep 20 18:51:09 <kergoth> same for archiver.bbclass
Sep 20 19:08:03 <xxiao> msm`: it took a long while for me to build 1.2.1, fsl-image-core includes merge-files by default
Sep 20 19:18:45 <msm`> is there a way to disable specific compiler warnings from autoconf?
Sep 20 19:19:48 <kergoth> there's no generic mechanism, no. it's up to the person maintaining the sources
Sep 20 19:21:30 <msm`> kergoth: where are the default compiler/warnings usually specified?
Sep 20 19:22:29 <msm`> i see this CWARNFLAGS coming out of no where afaict
Sep 20 19:24:17 <seebs> msm`: You might grab the bitbake include/var tracking patches I sent out recently, that should answer you.
Sep 20 19:25:49 <msm`> seebs: ah, this is pure autotools foo
Sep 20 19:36:24 <kergoth> msm`: never heard of CWARNFLAGS, whatever it is must be specific to whatever project you're working on
Sep 20 19:36:30 <kergoth> read configure.{in,ac}
Sep 20 19:47:56 <msm`> ugh
Sep 20 19:48:18 <seebs> but autoconf is fun and makes development easy
Sep 20 19:48:30 <seebs> autoconf : programming :: ez-bake oven : cooking
Sep 20 19:49:21 <seebs> well. that is. assuming that the ez-bake oven tended to result in epic 6-day debugging sessions trying to find out why it was insisting that the cupcake pan was not available.
Sep 20 19:49:46 <seebs> The day I saw the test for sizeof(char), I died a little inside.
Sep 20 19:50:58 <msm`> i *hate* it
Sep 20 19:50:59 <msm`> ;)
Sep 20 19:51:55 <seebs> If I absolutely had to defend autotools, I could almost certainly find a thing to say about it which was not overtly negative.
Sep 20 19:52:25 <seebs> Actually, I will give it one thing: The default tests provided by autotools do not habitually assume that any output whatsoever from a compiler to stderr indicates that compilation failed and the feature test should be considered negative.
Sep 20 19:54:44 <msm`> i just find it's hard to figure out what's going on
Sep 20 19:55:00 <walters> the well developed cross compilation framework is nice
Sep 20 19:55:51 <kergoth> seebs: there's *one* thing i like about autotools. At least the crappiness is *consistent*, and there are known ways to work around it, as opposed to every random piece of software with a home-rolled make solution
Sep 20 19:56:25 <seebs> Yeah.
Sep 20 19:56:48 <seebs> I would personally not mind at all if it were a little less dogmatic about portability to a few edge cases, although a lot of them were less edgy when it got started.
Sep 20 19:57:17 <seebs> In particular, the elaborate mess around echo is probably long-dead. When I was doing the shell book, the tech reviewer and I went hunting, and neither of us could find ANY machines which didn't have printf(1).
Sep 20 19:57:32 <seebs> (Embedded targets might not, but they're not usually running autoconf either.)
Sep 20 19:57:48 <kergoth> i'd rather just assume i'm on a sane system, and leave the handling of obscure cases nobody cares about to those nobodies
Sep 20 19:57:55 <kergoth> :)
Sep 20 20:12:07 <seebs> Which reminds me: Outside of weird stuff no one cares about like embedded systems, if you want a stable and predictable printing behavior, printf(1) is your friend.
Sep 20 20:12:33 <seebs> Ludicrously widespread, been around on basically everything for a very long time (like, I think it may have been there in SunOS 4.x), predictable and well-defined, also very flexible.
Sep 20 20:14:32 <kergoth> yes, you can't rely on echo -n and the like
Sep 20 20:15:20 <seebs> And printf's behavior is consistent and reliable. And full of handy stuff.
Sep 20 20:15:35 <seebs> My sole complaint is that it was specified with %c == %.1s rather than actually doing the conversion from character values. :)
Sep 20 20:26:37 <bluelightning> makes me wonder why echo is still so ubiquitous in shell scripts
Sep 20 20:27:23 <bluelightning> for my part I have shied away from printf assuming that it wasn't necessarily portable, only to find out recently that it's actually much more portable than echo as you say
Sep 20 20:28:08 <kergoth> echo's commandline args can be a problem if what you're echoing starts with a dash, too, iirc
Sep 20 20:28:09 <kergoth> heh
Sep 20 20:50:49 <seebs> echo is ubiquitous because everyone assumes printf isn't.
Sep 20 20:51:27 <seebs> I did a portable shell scripting book. The tech reviewer was one of the autotools people. We *both* started out with the impression that printf was the best thing since sliced bread, and it was a real shame that it was only available on newish *BSD and Linux.
Sep 20 20:54:36 <kishore> How to avoid ERROR: QA Issue: mypackage rdpends on mypackage-dev?
Sep 20 20:55:11 <seebs> That is a fascinating question. We had as I recall one package on our system such that, depending on things on the host, we'd suddenly get a ton of those, but changing the host made them go away. I don't recall how it got resolved.
Sep 20 20:57:58 <kergoth> kishore: at a guess, you have a .so which isn't a symlink, and it's not in the main package, since the deault packaging puts .so files in -dev, and you have a binary in the ${PN} package which links against that .so? it'll be something along those lines. your content has such a dependency
Sep 20 20:58:12 <kergoth> course, the non-symlink .so check should have caught that, so i guess it's not that one
Sep 20 20:58:15 <kergoth> but that's the type of thing to look for
Sep 20 21:01:57 <kishore> kergoth: Thanks for the hint, looking into those lines.
Sep 20 21:47:27 <bluelightning> seebs: sounds like I should make a trip to the book shop :)
Sep 20 21:49:57 <seebs> There was humor in that I thought I was writing a book on portable shell scripting with a brief intro, and somehow the marketing folks ended up thinking it was a purely beginner-level book, so it's called "Beginning Portable Shell Scripting".
Sep 20 21:59:12 <bluelightning> seebs: looking at a lot of technical book titles they seem to want to pigeonhole them into either "beginning/learning" and "advanced"
Sep 20 21:59:19 <bluelightning> s/and/or/
Sep 20 22:14:42 <Flyser> does anyone care to apply this? http://bpaste.net/show/46660/
Sep 20 22:20:12 <bluelightning> Flyser: there's already a similar patch from Laurentiu on the mailing list that removes the names
Sep 20 22:20:20 <bluelightning> should be merged fairly soon
Sep 20 23:15:40 <fk_007> I read that i should add IMAGE_FEATURES += "package-management" for package support. Should i add this to the core-image-minimal.bb file?
Sep 20 23:19:29 <blloyd_> conf/local.conf would be a place you can add it, if you want that in all images you make.
Sep 20 23:27:25 <bluelightning> typically it would be done on a per-image basis though
Sep 20 23:28:54 <fk_007> but it would be fine to add it in the core-image-minimal.bb?
Sep 20 23:29:03 <bluelightning> yes, that's what I mean
Sep 20 23:29:05 <fk_007> because i did and its baking right now
Sep 20 23:29:16 <bluelightning> that's fine
Sep 20 23:30:01 <bluelightning> did you also remove/comment out the ROOTFS_POSTPROCESS_COMMAND in core-image-minimal.bb though?
Sep 20 23:30:12 <bluelightning> fk_007: ^
Sep 20 23:30:18 <bluelightning> if not you will need to
Sep 20 23:43:49 <fk_007> no i did not :(
Sep 20 23:44:27 <fk_007> if i stop a bitbake it never seems to want to run again until i redownload everything, is there any way to stop and then start over?
Sep 20 23:47:26 <fk_007> so let me see if i got this right, if i have package support on my device once i've got the image i want i will be able to install packages i make with bitbake like for example a helloWorld c program
Sep 21 01:35:16 <fk_007> i got an error trying to bitbake core-image-minimal, it says insecure string pickle?
Sep 21 01:39:47 <fk_007> does that mean it failed or is it still going?
**** ENDING LOGGING AT Fri Sep 21 02:59:58 2012

**** BEGIN LOGGING AT Fri Sep 21 02:59:58 2012
Sep 21 08:22:26 <bluelightning> morning all
Sep 21 09:55:44 <RP> morning all
Sep 21 09:56:21 <JaMa> morning
Sep 21 10:01:24 <bluelightning> hi JaMa#
Sep 21 10:05:15 <dcthang> hi
Sep 21 10:43:22 <jackmitchell> is there any documentation stating how to extend meta-toolchain? I've had a go by examining the source code but while waiting for it to compile I thought I would inquire...
Sep 21 10:46:56 <RP> JaMa: thanks for cleaning opkg up btw, I appreciate that
Sep 21 10:47:01 <mertsas> jackmitchell: by extending, do you think of adding packages to the toolchain?
Sep 21 10:48:53 <bluelightning> jackmitchell: if you mean to produce an extended toolchain, have a look at how meta-toolchain-qte or meta-toolchain-gmae do it
Sep 21 10:48:58 <jackmitchell> mertsas: yes, that is exactly what I mean. I have a couple of custom libraries that I need to link with when I compile locally
Sep 21 10:49:20 <jackmitchell> mertsas: so I need them available in the toolchain sysroot
Sep 21 10:51:24 <mertsas> look at packagegroup-core-standalone-sdk-target.bb. What we do is have a bbappend for that, which includes our custom libraries as well as other libraries we need. We also append to the nativesdk-packagegroup-sdk-host package for tools running on the x86 host pc
Sep 21 10:52:13 <mertsas> jackmitchell: basically all we do is add packages in RDEPENDS_${PN} += "..."
Sep 21 10:53:03 <jackmitchell> ok, I have done something similar
Sep 21 10:53:12 <jackmitchell> I created my own packagegroup with my libraries
Sep 21 10:53:32 <jackmitchell> then I have copied the meta-toolchain-qte
Sep 21 10:53:58 <jackmitchell> added my packagegroup to TOOLCHAIN_HOST_TASK
Sep 21 10:54:11 <jackmitchell> and require recipes-core/meta/meta-toolchain.bb
Sep 21 10:55:56 <jackmitchell> I am a bit confused to whether I should be adding my packagegroup to TOOLCHAIN_HOST_TASK ro TOOLCHAIN_TARGET_TASK
Sep 21 10:56:21 <jackmitchell> I want it build to so I can cross compile and link against it, not so I can compile for my host....
Sep 21 10:57:10 <mertsas> then I think it is the TOOLCHAIN_TARGET_TASK you want. As you want stuff compiled for the target and put in the target sysroot
Sep 21 10:58:28 <mertsas> yeah, populate_sdk_base.bbclass uses packagegroup-core-standalone-sdk-target for the TOOLCHAIN_TARGET_TASK, while it uses the nativesdk-packagegroup-sdk-host for TOOLCHAIN_HOST_TASK
Sep 21 12:23:27 <RagBal> Anybody experience with rpi and Yocto?
Sep 21 12:23:34 <RagBal> Raspberry PI that is =)
Sep 21 12:26:52 <jackmitchell> RagBal: I wrote a blog post on it recently
Sep 21 12:27:07 <jackmitchell> RagBal: check my website http://www.pimpmypi.com
Sep 21 12:31:04 <RagBal> Your blog helped me alot indeed!
Sep 21 12:31:13 <RagBal> Thanks for that!
Sep 21 12:31:27 <RagBal> But I want to build a image with desktop manager
Sep 21 12:32:23 <RagBal> But none of the packages work core-image-x11 etc
Sep 21 12:32:29 <jackmitchell> RagBal: No that I have no experience in unfortunately - you will have to wait for someone else to come along, or take a look at using Angsrom
Sep 21 12:32:34 <jackmitchell> Angstrom*
Sep 21 12:32:54 <jackmitchell> I believe that can ship with a desktop environment
Sep 21 12:32:55 <RagBal> Will it work in Angstrom?
Sep 21 12:33:12 <jackmitchell> I know Angstrom has meta-raspberrypi in it's layers so I would suggest just giving it a go!
Sep 21 12:33:46 <RagBal> Yea, I've tried it already and it booted
Sep 21 12:34:05 <RagBal> But then I discovered The Yocto Project and I was like.. awesome
Sep 21 12:35:03 <jackmitchell> I would give this a quick read
Sep 21 12:35:04 <jackmitchell> http://blogs.mentor.com/chrishallinan/blog/2012/04/13/yocto-versus-poky-versus-angstrom-etc/
Sep 21 12:35:28 <jackmitchell> while a little bit shaky in places it is generally a good overview of what the Yocto Project is and what it provides
Sep 21 12:35:30 <RagBal> Allready read that hehe
Sep 21 12:36:01 <RagBal> Excuses my incompetence, I just started in the embedded world
Sep 21 12:36:13 <jackmitchell> It sounds like you've done all the right things so far!
Sep 21 12:36:59 <jackmitchell> I suppose the next step would be to read through all the yocto documentation and then start figuring out how to add X and a Desktop Environment to an image
Sep 21 12:37:03 <RagBal> I really like the way Yocto 'forces' me to learn how OE works
Sep 21 12:37:26 <RagBal> Angstrom gives me a 'working
Sep 21 12:37:51 * challinan wonders where it's "shaky in places" ;)
Sep 21 12:38:12 <RagBal> I really really love hob to!
Sep 21 12:38:18 <RagBal> Very nice
Sep 21 12:39:11 <jackmitchell> challinan: I was quoting someone on the mailing list the other day - at a guess maybe Paul Eg, i'll see if I can dig it up ;)
Sep 21 12:39:22 <RagBal> Is it possible to just add the Angstrom layers and use hob to build it?
Sep 21 12:39:33 <challinan> heh, I was just poking fun, no worries
Sep 21 12:39:53 <challinan> glad to see people are actually reading that stuff
Sep 21 12:40:55 <jackmitchell> challinan: I speak a lie (apologies Paul!)
Sep 21 12:40:56 <jackmitchell> > Chris Hallinan has a blog post that might be helpful:
Sep 21 12:40:56 <jackmitchell> > http://blogs.mentor.com/chrishallinan/blog/2012/04/13/yocto-versus-poky-versus-angstrom-etc/
Sep 21 12:40:56 <jackmitchell> Heh, it's quite close, but not entirely correct all the time. And not
Sep 21 12:40:56 <jackmitchell> complete.
Sep 21 12:40:57 <jackmitchell> I would agree with and highlight the Poky is a "build system" confusion,
Sep 21 12:40:58 <jackmitchell> though!
Sep 21 12:40:59 <jackmitchell> -- Denys
Sep 21 12:41:36 <jackmitchell> RagBal: I don't think so
Sep 21 12:42:22 <jackmitchell> RagBal: HOB is nice, but IMHO you need to be working with the configuration files directly in order to gain full control over the process
Sep 21 12:42:46 <jackmitchell> RagBal: I don't know how good a job HOB would do interpreting all the Angstrom disto files etc..
Sep 21 12:42:53 <RagBal> True true
Sep 21 12:44:23 <challinan> jackmitchell: ah. well there is a recent debate on this same subject on [yocto-advocacy] which started on [meta-ti] about the confusion between the various terms
Sep 21 12:44:28 <RagBal> I'm going to try Angstrom to build a desktop manager
Sep 21 12:46:35 <jackmitchell> challinan: sigh.. yet another yocto bureaucracy list I suppose I should keep an eye on! Unless it's not public list - I thought I had them all covered
Sep 21 12:48:23 <challinan> heh, talk to jefro about getting on that one (I think)
Sep 21 12:51:16 <jackmitchell> hehe, I'm not in the inner circle - nor do I believe I would be able to add any expertise; so as an end user I'm quite happy to do as I'm told :)
Sep 21 13:04:01 <bluelightning> jackmitchell: hob is just a UI for bitbake, aside from one known bug about how images are produced it should have no trouble with different distros and their configuration
Sep 21 13:05:53 <jackmitchell> bluelightning: so is it not still true that changes in HOB don't reflect in the configuration files? Would I be able to do initial configuration in HOB then switch to the config files for finer tweaking?
Sep 21 13:06:25 <bluelightning> jackmitchell: it does use its own independent configuration yes; I'm not totally convinced about that either
Sep 21 13:06:55 <mertsas> is there a way to make a pure native package, that is a package which can only be built by <packagename>-native, and the result will be put in sysroot/x86_64-linux instead of arm
Sep 21 13:06:58 <bluelightning> something we can look at improving for 1.4
Sep 21 13:07:32 <jackmitchell> bluelightning: Ok, that's really the show stopper for me personally.
Sep 21 13:07:45 <bluelightning> mertsas: create the recipe with -native in the filename and "inherit native" - we should have a heap of examples of this as well as the BBCLASSEXTEND method
Sep 21 13:08:01 <jackmitchell> bluelightning: I would hate to get to a point where HOB couldn't do something I required - and then having to start from scratch with config files
Sep 21 13:08:46 <mertsas> ok, I tried the BBCLASSEXTEND method, but that wouldn't not build a arm package. Thansk
Sep 21 13:09:33 <bluelightning> jackmitchell: the trouble is automatically editing config files that users also edit is practically very difficult
Sep 21 13:10:13 <jackmitchell> bluelightning: it's a bit of a scary concept not having a full control over what (should hopefully be) a deterministic build. changing a few drop downs, pressing go and a black magic tar file popping out is a bit daunting
Sep 21 13:10:26 <bluelightning> jackmitchell: we could take the approach of just adding a "require" from local.conf to another file that hob edits, but then I'm sure people would complain that now their settings in local.conf aren't taking effect after they use hob
Sep 21 13:10:34 <jackmitchell> bluelightning: indeed, I can imagine auto-generated and user-modified files would be a head-ache
Sep 21 13:11:15 <bluelightning> jackmitchell: on the other hand, Hob was built to allow people for whom editing config files to get started is too much; that's the initial class of user we're targeting
Sep 21 13:11:55 <jackmitchell> bluelightning: yes, that is my impression of it - an easy starter to which when you understand the basics and terminology you can proceed to manual configuration
Sep 21 13:12:41 <jackmitchell> I am pleasantly suprised it can support the wide range of Angstroms different configs though
Sep 21 13:12:45 <bluelightning> for many beginners it will be the difference between not getting anywhere and giving up, and getting something basically usable out of the build system
Sep 21 13:13:11 <bluelightning> but I agree, what to do to progress beyond that needs work
Sep 21 13:16:11 <jackmitchell> bluelightning: indeed, and I'm not entirely convinced that it should, from spending the best part of 8 months getting to terms with OE, I certainly wouldn't feel happy trusting someone who required a GUI to manage a build, should be attempting to produce commercial builds (hobbists are a different story)
Sep 21 13:17:05 <jackmitchell> and a commercial build would almost certainly need a level of tweaking and understanding which is well beyond a pre-defined image
Sep 21 13:18:09 <bluelightning> absolutely, I don't think we're expecting to make build system experts out of people just with a UI...
Sep 21 13:23:23 * jackmitchell thinks he needs to emasculate himself and give HOB another go ;)
Sep 21 13:27:58 <bluelightning> FYI, we're right in the middle of fixing a number of bugs in Hob so you might want to wait until the release...
Sep 21 13:28:10 <bluelightning> (if you want the best experience)
Sep 21 15:24:10 <kergoth> does https://gist.github.com/3762144 seem reasonable? The goal is to switch the locale directory from libdir/locale to exec_prefix/lib/locale, but by doing this piece first, we can avoid changing anything for the 1.3 release. the output with this applied is the same as before (verified with buildhistory)
Sep 21 15:24:32 <kergoth> then can pursue the localedir change post-1.3, or can keep it in the tcmode for the external toolchain
Sep 21 15:24:59 <kergoth> this is an actual build failure for external mips64 sourcery toolchains, as the locales are in lib/locale not lib64/locale there.
Sep 21 16:13:29 <msm`> bluelightning: hello
Sep 21 16:13:36 <bluelightning> hi msm`
Sep 21 16:14:09 <msm`> i think one of your commits is causing some issues on denzil with bitbake-diffsigs
Sep 21 16:14:19 <msm`> curious if you had any ideas about missing commits
Sep 21 16:14:19 <msm`> https://gist.github.com/3762392
Sep 21 16:16:23 <bluelightning> msm`: is this denzil or denzil-next?
Sep 21 16:16:28 <msm`> err
Sep 21 16:16:33 <msm`> you know i may have spoke too soon
Sep 21 16:16:48 <msm`> im following an email from a coworker
Sep 21 16:17:13 <bluelightning> well not necessarily... I did just backport a fix for scott that touches that area, I may have broken something, let me just double-check
Sep 21 16:17:26 <msm`> nevermind
Sep 21 16:17:37 <msm`> zenlinux dropped those patches i believe
Sep 21 16:17:42 <msm`> and internally we have not rebased
Sep 21 16:17:57 <bluelightning> ah I see
Sep 21 16:17:58 <msm`> it's already taken care of on denzil-next
Sep 21 16:18:04 <msm`> so… sorry for the nois
Sep 21 16:18:09 <bluelightning> ok, np
Sep 21 16:18:26 <bluelightning> the good news is I backported the -f and menuconfig fixes without the need for the file_checksums stuff
Sep 21 16:18:43 <bluelightning> (there was no direct dependency, just a merging issue)
Sep 21 16:26:57 <msm`> if ${PN}-dev depends on ${PN} but ${PN} is empty what's the correct way to handle it?
Sep 21 16:27:00 <msm`> ALLOW_EMPTY?
Sep 21 16:27:23 <kergoth> ALLOW_EMPTY is best, though you could adjust the RDEPENDS_${PN}-dev too of course
Sep 21 16:28:47 <bluelightning> msm`: the approach I've taken is to clear out RDEPENDS_${PN}-dev
Sep 21 16:28:50 <msm`> kergoth: so that's just a default dep… problem is I don't know all the other deps, so maybe an oe_filter_out?
Sep 21 16:29:04 <bluelightning> msm`: as it happens I think that is the only one
Sep 21 16:29:08 <msm`> or a blank RDEPENDS, perhaps
Sep 21 16:29:11 <msm`> hmm ok
Sep 21 16:29:16 <kergoth> yeah, pretty sure its all there is, you can check bitbake.conf to verify
Sep 21 16:29:21 <msm`> k
Sep 21 16:29:22 <msm`> thanks
Sep 21 16:30:03 <kergoth> the depchain stuff will pull in deps from other recipes, but i think thats done via rrecommends, or at least in anonymous python so it's after the fact
Sep 21 16:30:05 * kergoth yawns
Sep 21 16:30:07 <bluelightning> maybe the dependency should be added in python code so we can skip it if PN is empty/not in PACKAGES
Sep 21 16:30:37 * bluelightning has been thinking about this lately
Sep 21 17:17:57 <kergoth> has anyone looked into standard kernel.org (rather than linux-yocto) kernel support for yocto-bsp?
Sep 21 17:22:53 <zeddii> I remember Tom poked at it once, but it's a lot of work since the fragments and features that it uses wouldn't be in the tree, and it would still need to restrict the version to have the "yocto" part of "yocto-bsp" (according to the conformance criteria).
Sep 21 17:24:37 <kergoth> what are the conformance criteria?
Sep 21 17:25:48 <zeddii> https://wiki.yoctoproject.org/wiki/Working_Draft_of_Compliance_Prop is the old link I have
Sep 21 17:25:52 <zeddii> and the kernel part was: Linux kernels are either based around LTSI kernel versions or a Yocto Project kernel version.	
Sep 21 17:26:14 <zeddii> it's a recommendation, but we can't very well have a yocto tool ignoring that recommendation :)
Sep 21 17:27:47 <kergoth> well, every bsp created by yocto-bsp is going to require some manual adjustment anyway, so even if the user inputted versions are restricted, they'd at least have an easy starting point to adjust it closer to what they need, even if it then no longer meets the recommendations, i expect
Sep 21 17:28:14 <zeddii> sure. but at that point, what's the value of switching the base.
Sep 21 17:28:28 <zeddii> it's not like we don't have yocto-custom and the pure base in linux-yocto which already matches those versions.
Sep 21 17:29:45 <zeddii> I'm obviously avoiding all arguments about values of random trees here and there, etc, it is a yocto-bsp tool that's trying to promote something in particular. it hits me in my day job as well (i.e. it isn't my kernel at work either).
Sep 21 19:08:16 <msm`> seems i have an(other) issue w/ building master on CentOS 5.x
Sep 21 19:08:32 <msm`> __isoc99_sscanf is not available on the version of libc - thus nativesdk-libx11 fails to build
Sep 21 19:16:30 <msm`> which actually does not make sense because we build nativesdk-eglibc-2.16 which should have it defined
Sep 21 19:17:10 <msm`> actually i think libx11 is sneaking in a call to the host compiler in this scenario:
Sep 21 19:17:10 <msm`> | x86_64-pokysdk-linux-libtool: link: gcc -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/opt/yocto/upstream/label/master/machine/p5020ds-64b/poky/master/tmp/sysroots/x86_64-nativesdk-pokysdk-linux/opt/poky/1.2+snapshot/sysroots/x86_64-pokysdk-linux/usr/include -isystem/opt/yocto/upstream/label/master/machine/p5020ds-64b/poky/master/tmp/sysroots/x86_64-linux/usr/include -O2 -pipe -Wl,-rpath-link -Wl,/opt/yocto/upstream/label/master/machine
Sep 21 19:17:20 <msm`> err wow that was longer than i thought ;(
Sep 21 19:48:55 <msm`> how does libtool pick which compiler to invoke?
Sep 21 19:53:29 <kergoth> we had libx11 fail in the makekeys build due to the -W args passed being incompatible with the build machine gcc
Sep 21 19:53:39 <kergoth> easy enough to work around, though
Sep 21 19:53:43 <kergoth> (also onc entos5)
Sep 21 19:57:33 <msm`> kergoth: yes, ive seen that
Sep 21 19:57:42 <msm`> kergoth: i have a patch for that, but mine is hacky
Sep 21 19:57:49 <msm`> this seems like a different issue
Sep 21 19:58:10 <msm`> maybe i made this issue occur though from my other fix
Sep 21 19:58:11 <msm`> | makekeys-makekeys.o: In function `main':
Sep 21 19:58:11 <msm`> | makekeys.c:(.text+0x85): undefined reference to `__isoc99_sscanf'
Sep 21 19:58:11 <msm`> | makekeys.c:(.text+0xa7): undefined reference to `__isoc99_sscanf'
Sep 21 19:58:16 <msm`> can you share your libx11 fix?
Sep 21 19:59:15 <msm`> kergoth: actually, this might be my own doing in my first attempt to fix the issue
Sep 21 20:00:14 <msm`> kergoth: yep, my own fault
Sep 21 20:00:29 <msm`> i was doing EXTRA_OEMAKE += "some-foo-to-get-around-W-args"
Sep 21 20:00:33 <msm`> which was removing the -e option to make
Sep 21 20:01:01 <kergoth> EXTRA_OEMAKE += "'CWARNFLAGS='" was my first attempt, but then i switched to EXTRA_OECONF += "—disable-selective-werror"
Sep 21 20:01:09 <kergoth> need to do a bit more build testing though
Sep 21 20:01:47 <kergoth> that extra-oemake bit shouldnt' result in losing anything, unless you're doing it from config metadata
Sep 21 20:02:46 <msm`> ../meta/conf/bitbake.conf:EXTRA_OEMAKE = "-e MAKEFLAGS="
Sep 21 20:02:52 <msm`> the -e bit was going away
Sep 21 20:03:20 <kergoth> i know whats in bitbake.conf, i put it there
Sep 21 20:03:22 <msm`> and CCLD was not getting set
Sep 21 20:03:39 <msm`> kergoth: i thought i tried —disable-selective-werror
Sep 21 20:09:02 <msm`> oh bother.. now it compiled makekeys as target and then tried to execute it
Sep 21 20:09:04 * msm` sigh
Sep 21 20:13:39 <kergoth> afk, food
Sep 21 20:14:10 <msm`> tried w/ the same error
Sep 21 20:14:14 <msm`> —disable-selective-werror*
Sep 21 20:50:15 <msm`> i should probably be asking myself why is nativesdk-libx11 even being built
Sep 21 20:50:22 <msm`> because that seems odd
Sep 21 20:56:40 <msm`> ahh qemu-nativesdk
Sep 21 21:19:46 <khem> is there a sample image in yocto doing multilib ?
Sep 21 21:40:40 <pidge_> khem: on the autobuilder, I build it out.
Sep 21 21:40:55 <khem> pidge cool
Sep 21 21:41:07 <khem> what do you do in local.conf for that
Sep 21 21:41:13 <khem> or do you have some other changes
Sep 21 21:50:44 <khem> pidge_: what changes do you make to do multilib
Sep 21 22:43:02 <khem> pidge_: I am trying to build lib32-meta-toolchain
Sep 21 22:43:10 <khem> and it fails
Sep 21 22:43:19 <khem> bluelightning: hi
Sep 21 22:43:32 <bluelightning> hi khem
Sep 21 22:43:36 <khem> bluelightning: Do you deal with multilibs
Sep 21 22:43:47 <bluelightning> khem: only in passing
Sep 21 22:44:05 <khem> OK I am looking to make a multilib SDK
Sep 21 22:44:19 <khem> I did try to bake lib32-meta-toolchain
Sep 21 22:44:34 <khem> but it could not find 32bit gcc-cross provider
Sep 21 22:44:53 <khem> interestingly it wanted to include external-csl recipe to provide it
Sep 21 22:45:13 <khem> so I dont know if lib32-meta-toolchain is right target
Sep 21 22:45:40 <bluelightning> to be honest I'm not sure
Sep 21 22:45:53 <khem> OK
Sep 21 22:45:57 <bluelightning> RP would probably be the best person to ask
Sep 21 22:46:08 <khem> yeah
Sep 21 22:46:15 <khem> he is kind of AWOL :)
Sep 21 22:46:43 <fray> ya, it's only 10 pm there on a Friday..
Sep 21 22:47:06 <fray> actually I'm having multilib SDK issues.. anything cross canadian can't be built multilib from what I can tell..
Sep 21 22:47:12 <fray> I'm not sure fi that affects the meta-toolchain but may..
Sep 21 22:52:05 <bluelightning> fray: try nearly midnight ;)
Sep 21 22:53:39 <khem> fray: some of us are supposed to work 24/7 and RP is one of them :)
Sep 21 22:53:54 <RP> khem: you called?
Sep 21 22:53:59 <khem> RP: haha
Sep 21 22:54:04 <khem> ROFL
Sep 21 22:54:34 <khem> RP: no I was just asking some multilib questions not urgent
Sep 21 22:54:43 <RP> khem: the trouble is that our cross canadian recipes don't support BBCLASSEXTEND at this point
Sep 21 22:54:50 <khem> I am trying to see if I can provide a multilib x86 SDK
Sep 21 22:55:01 <khem> hmmm
Sep 21 22:55:24 <RP> khem: you might get lucky with the multixxxx distro feature since you already have both sets of libs
Sep 21 22:55:51 <khem> RP: thats fine. I think I can publish two SDKs
Sep 21 22:55:57 <RP> khem: are you happy with two gccs? or just want one supporting two multilibs?
Sep 21 22:55:59 <khem> and have image  have both runtimes
Sep 21 22:56:15 <RP> khem: you can install both cross-candians in one sdk
Sep 21 22:56:21 <khem> RP: seriously, I am happy with anything thats would get this going :)
Sep 21 22:56:40 <khem> RP: hmm thats an option
Sep 21 22:57:35 <khem> RP: I think it would be fine to publish two SDKs and they live under same location
Sep 21 22:57:38 <RP> khem: if you can work with two cross-canadians, its just a case of setting BBCLASSEXTEND correctly for cross-canaidan and having the multilib class set the right TRANSLATED_ARCH
Sep 21 22:57:52 <khem> as long as the binaries generated by 32bit sdk run fine on the image
Sep 21 22:58:38 <khem> RP: for 1.4 I plan to work on making multilib SDKs sort of doing x86_64-gcc -m32 and x86_64-gcc
Sep 21 22:58:52 <khem> for generating binaries
Sep 21 22:59:15 <khem> for now I think people can live with having two different callouts
Sep 21 22:59:37 <khem> key is to get the resulting app to run on 64bit target
Sep 21 22:59:54 <khem> so as long as the 32bit runtime in image is good. It should work out fine
Sep 21 23:01:46 <RP> khem: I do want to get this fixed in 1.4. Its too much for 1.3 at this point though. I wish we'd had this interest 3 months ago
Sep 21 23:01:55 <RP> Its not hard to fix, just a steep learning curve
Sep 21 23:02:18 <khem> RP: yeah I guess
Sep 21 23:02:32 <khem> RP: but requirements show up as they do
Sep 21 23:02:51 <khem> I want it today. If I want it tomorrow I would order it tomorrow :)
Sep 21 23:02:51 <RP> khem: and we have to stop developing features at some point and stabilse
Sep 21 23:02:57 <khem> totally
Sep 21 23:03:11 <khem> I think I can live with it
Sep 21 23:03:17 <khem> e.g. I have added python3 :)
Sep 21 23:03:25 <khem> but I did not propose it for 1.3
Sep 21 23:03:34 <khem> even though it had 3 in common :)
Sep 21 23:04:07 <RP> khem: I'd love to help in lots of detail but I've been trying for the past 9 months to solve the related problem on on target multilib and have effectively had to shelve this for 1.3
Sep 21 23:04:30 <RP> khem: I just don't have the bandwidth :(
Sep 21 23:04:47 <khem> I think 1.4 is where some of more complex usecases will come from me
Sep 21 23:04:59 <khem> RP: understood
Sep 21 23:05:05 <khem> same here :)
Sep 21 23:06:25 <blloyd_> darknighte on?
**** ENDING LOGGING AT Sat Sep 22 02:59:58 2012

**** BEGIN LOGGING AT Sat Sep 22 02:59:59 2012
Sep 22 10:56:51 <_julian_> is it possible to overwrite the kernel command line from local.conf? (for rpi-basic-image)
Sep 22 12:39:08 <gizero76> Hi! Currently beta testing 1.3. After some successful builds of various images moved to building SDK for testing relocatability: this generated poky-eglibc-i686-arm-toolchain-1.2+snapshot-20120922.sh (I used HOB for this build) that I then installed somewhere in /tmp instead of default location. After sourcing environment-setup-armv7a-vfp-neon-poky-linux-gnueabi from install location I try to compile a trivial hello.c.
Sep 22 12:39:12 <gizero76> $ echo $CC
Sep 22 12:39:14 <gizero76> arm-poky-linux-gnueabi-gcc -march=armv7-a -fno-tree-vectorize -mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 --sysroot=/tmp/strange-place/sysroots/armv7a-vfp-neon-poky-linux-gnueabi
Sep 22 12:39:17 <gizero76> $ $CC --version
Sep 22 12:39:19 <gizero76> arm-poky-linux-gnueabi-gcc (GCC) 4.7.2 20120706 (prerelease)
Sep 22 12:39:21 <gizero76> Copyright (C) 2012 Free Software Foundation, Inc.
Sep 22 12:39:23 <gizero76> This is free software; see the source for copying conditions.  There is NO
Sep 22 12:39:25 <gizero76> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Sep 22 12:39:30 <gizero76> $ $CC hello.c
Sep 22 12:39:31 <gizero76> Assembler messages:
Sep 22 12:39:34 <gizero76> Fatal error: invalid -march= option: `armv7-a'
Sep 22 12:39:43 <gizero76> btw MACHINE="beagleboard" for this test
Sep 22 12:40:24 <gizero76> currently downloading pre-built toolchain to see if can be a host-related issue...
Sep 22 17:25:56 <khem> gizero76: hmmm where did you install the SDK ?
Sep 22 17:26:08 <khem> gizero76: for tests install it in default location
Sep 22 17:26:11 <khem> which is /opt
Sep 22 17:26:51 <khem> problem seems to be that gcc-cross is using wrong assembler (which is native x86)
Sep 22 20:28:57 <fray> as an FYI -- I'm working on enabling multilib cross-canadian package support....
Sep 22 20:29:59 <bluelightning> fray: I guess you saw khem asking about that the other day?
Sep 22 20:30:37 <fray> I was asking RP about it at about the same time..
Sep 22 20:30:40 <fray> coincidence..
Sep 22 20:30:58 <fray> but there are a number fo small places that need changes.. multilib.bbclass, base.bbclass..
Sep 22 20:31:03 <fray> not sure I've found them all yet..
Sep 22 20:35:16 <bluelightning> fray: btw, any suggestions on how to handle 2918 ?
Sep 22 20:35:46 <fray> looking
Sep 22 20:36:26 <fray> kernel packages are not suppossed to be multilib enabled..
Sep 22 20:36:45 <fray> there is a check in multilib.bbclass (I think) or maybe it's base.bbclass disabling remapping for kernel stuff
Sep 22 20:37:07 <bluelightning> the thing is, we don't know that at rootfs construction time
Sep 22 20:37:37 <fray> somewhere in the mapping rules (both teh multilib rules in those places) and the unmapping rules/translation rules there is a mismatch..
Sep 22 20:37:42 <fray> we need to find/fix that mismatch
Sep 22 20:38:17 <fray> I did have a question for you though..  if you look at multilib.bbclass, end of the "multilib_virtclass_handler" function
Sep 22 20:38:24 <fray>     if e.data.getVar("TARGET_VENDOR_virtclass-multilib-" + variant, False) is None:
Sep 22 20:38:25 <fray>             e.data.setVar("TARGET_VENDOR_virtclass-multilib-" + variant, e.data.getVar("TARGET_VENDOR", False) + "m$
Sep 22 20:38:25 <fray>     e.data.setVar("OVERRIDES", e.data.getVar("OVERRIDES", False) + override)
Sep 22 20:38:36 <fray> that last thing it does is set the overrides, but it never runs update_data..
Sep 22 20:38:51 <fray> is that intentional or a bug?  (I suspect the later because I noticed some errant behavior working on the cross-canadian case)
Sep 22 20:39:25 <fray> if the package 'PN' contains a variable, then the FILES_${PN} get the original value before the remapping..  if I add the update_data there.. then PN and FILES_${PN} get the right setting
Sep 22 20:39:29 <fray>     bb.data.update_data(e.data)
Sep 22 20:39:31 <fray> thats all I added
Sep 22 20:40:04 <bluelightning> hmm, but I would have thought update_data would be called later
Sep 22 20:40:21 <bluelightning> and calling it early might not always be the right thing to do I think
Sep 22 20:40:38 <fray> it does.. after FILES_${PN} is evaluated (I couldn't figure out when it was actually called.. but it was called before the package started to build, but after the FILES_${PN} was evaluated...
Sep 22 20:41:13 <fray> really easy to show the behavior.. add something in the PN to be dynamic with a recipe... then run the multilib version, you'll get hte error that none of the packages are well.. packaged..
Sep 22 20:41:20 <fray> since PACKAGES = ...new pn....
Sep 22 20:41:27 <fray> FILES_${PN} == pn is old pn..
Sep 22 21:23:28 <blloyd> question, why would the kernel require python/perf.so to install?  From linux-yocto kernel (with custom .config)
Sep 22 21:24:09 <fray> if perf is enabled there may be something there that is requiredd
Sep 22 23:05:38 <blloyd> thanks for info fray
**** ENDING LOGGING AT Sun Sep 23 02:59:58 2012

**** BEGIN LOGGING AT Sun Sep 23 02:59:59 2012
Sep 23 20:13:23 <blloyd> I've (re)created a bsp layer using yocto-bsp.  When I build that bsp, even though I selected vesa graphics I end up with a intel xorg.conf.  I've seen this both head of denzil branch and denzil 7.0.1.  Any suggestions what I may be doing wrong?
Sep 23 20:14:08 <blloyd> or how to find why the device specific xorg.conf file seems to not be found?
Sep 23 21:07:43 <RP> fray: update_data should get run later by bitbake itself so I suspect something else at play...
Sep 23 21:11:57 <bluelightning> RP: that's what I was thinking
Sep 23 23:18:51 <blloyd> I'm seeing references to FILESPATH =. "${@base_set_filespath(["${THISDIR}/${PN}"], d)}:" being obsolete as far back as 3 years ago, but yocto-bsp still creates a file using it and the meta-intel bsps use it (meta-intel/meta-crownbay/recipes-graphics/xorg-xserver).  I'm seeing a bug where the bsp specific xorg.conf file wasn't being included.  Anyone have any ideas, or is this a bug (checked bugzilla and no open bugs on it).
Sep 23 23:21:33 <bluelightning> blloyd: where have you placed your xorg.conf exactly?
Sep 23 23:22:52 <blloyd> . /meta-vortex86/recipes-graphics/xorg-xserver/xserver-xf86-config
Sep 23 23:23:58 <blloyd> . meta-vortex86/recipes-graphics/xorg-xserver/xserver-xf86-config/vortex86/xorg.conf.  Sorry paste error
Sep 23 23:25:22 <blloyd> I've built crownbay noemgd too, and it seemed to get the intel driver as well.  It's config is at meta-intel/meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay-noemgd, and the bbappend for it matches mine except for PR.
Sep 23 23:58:37 <blloyd> and thanks for the second pair of eyes, this has been driving me batty since Tuesday, and finally have it narrowed down.  Went through recreating the bsp from the beginning to make sure I hadn't broken anything.
Sep 23 23:59:01 <blloyd> but then I noted meta-intel seemed to have the same break.
Sep 24 00:06:49 <bluelightning> blloyd: so does FILESPATH cover that directory?
Sep 24 00:07:17 <bluelightning> blloyd: you can check the value using bitbake -e xserver-xf86-config | grep "^FILESPATH"
Sep 24 00:09:07 <blloyd> thanks blue: that's the kind of how to debug info I was after.  :)
Sep 24 00:16:42 <blloyd> it's in there, but after a bunch of other directories that also have xorg.conf files.
Sep 24 00:23:56 <blloyd> I lied, meta-myapps is in there, but not meta-mybsp.
Sep 24 00:25:55 <bluelightning> blloyd: that FILESPATH construction seems broken, it is missing immediate evaluation in order to get the correct value of THISDIR
Sep 24 00:26:28 <bluelightning> blloyd: I would suggest using FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
Sep 24 00:27:21 <blloyd> I'll try that.  If it works, I'll file a bug against the meta-intel stuff to fix it there too.
Sep 24 00:27:38 <blloyd> (and another against yocto-bsp).
Sep 24 00:27:48 <bluelightning> that would be great, thanks
Sep 24 00:28:11 <blloyd> thanks for double checking.  I don't trust myself yet.
Sep 24 01:28:55 <mranostay> blloyd: then who can you trust? :)
Sep 24 01:29:24 <blloyd> not sure....
Sep 24 01:30:43 <blloyd> question: does first file in path or last in path win when locating files?
Sep 24 01:32:47 <mranostay> -EPARSE
Sep 24 01:35:54 <blloyd> what's -EPARSE?
Sep 24 01:36:51 <kergoth> first is used, which is why that's a prepend, not an append
Sep 24 01:37:03 <kergoth> and -EPARSE would be a parse error. guess you're not familiar with errno :)
Sep 24 01:54:14 <blloyd> thanks kergoth: should have figured that, just on a line by itself didn't click.
**** ENDING LOGGING AT Mon Sep 24 02:59:59 2012

**** BEGIN LOGGING AT Mon Sep 24 02:59:59 2012
Sep 24 07:11:16 <mckoan> good morning
Sep 24 08:21:30 <bluelightning> morning all
Sep 24 13:06:09 <gotan> hi. I'm still having trouble getting a module to install into a root image. I've tracked it down to modules_install in the kernel makefiles, and i;m using devshell and temp/run.do_install to try and find out what is happening.
Sep 24 13:07:34 <bluelightning> gotan: is a package created for the module?
Sep 24 13:07:46 <gotan> I'm hitting a wall where it makes the extras directory in the /lib.../modules, but it is not copying the module there. I'm usinx denzil - is this something i should move to 1.3 for?
Sep 24 13:07:50 <gotan> yes
Sep 24 13:07:57 <gotan> @bluelightning
Sep 24 13:08:31 <bluelightning> gotan: so that package is definitely included in your image?
Sep 24 13:08:38 <bluelightning> (sorry, silly questions first)
Sep 24 13:09:39 <gotan> @bluelightning: yes. I had trouble at first when my image would not build beacause the module would not build, and i found the package was not generated because the module was not there to be picked up.
Sep 24 13:15:19 <gotan> @bluelightning: also possible error - when i attempted to manually copy the module to sbin in a do_install_append(), it turns out that poky chokes and dies if you try and do that.
Sep 24 13:15:49 <bluelightning> you shouldn't need to do that
Sep 24 13:16:17 <gotan> @bluelightning: e.g. "install -m 0644 ${S}/src/module.ko ${D}${base_sbindir}/modules/"
Sep 24 13:16:51 <bluelightning> gotan: perhaps I'm missing something, but shouldn't kernel modules go into /lib/modules ?
Sep 24 13:17:30 <gotan> @bluelightning understood, but when something does not work out of the box, it introduces delay :( I've been digigng into kernel makfiles for the last few days.
Sep 24 13:17:53 <bluelightning> normally this does work out of the box
Sep 24 13:18:02 <bluelightning> just so I'm understanding, this is an external module?
Sep 24 13:18:20 <gotan> @bluelightning: yes, but insmod will work from anywhere. I want to put the module on the target, to test it i can clean up the implementation later.
Sep 24 13:19:14 <bluelightning> that's true, but I would suggest putting it in the proper place
Sep 24 13:19:21 <bluelightning> gotan: are you inheriting module.bbclass ?
Sep 24 13:19:38 <gotan> @Bluelightning: external yes, the only wrinke is that it 'super makefile' because it has to build the helpers tools distributed with the module.
Sep 24 13:19:48 <gotan> @bluelightning: yes
Sep 24 13:20:19 <bluelightning> so as you may have seen, module.bbclass already has some code to do the installation - why is that not working in your case?
Sep 24 13:21:02 <gotan> @bluelightning: make modules_install is failing and not copying the module to the image folder.
Sep 24 13:21:21 <bluelightning> gotan: so what's the failure?
Sep 24 13:22:34 <gotan> @bluelightning - sorry, thats why i'm asking - any pointers. I've been digging into it, and it may be that DEPMOD is not set correctly - using V=1 in the modules_install target in the makefile, i'm told "Warning: you may need to install module-init-tools See http://www.codemonkey.org.uk/docs/post-halloween-2.6.txt"
Sep 24 13:23:07 <gotan> using V=2 i get the cryptic "DEPMOD  3.2.18-rt29 - due to target is PHONY"
Sep 24 13:24:13 <gotan> @bluelightning - which, before i start hacking into the kernel build system, i thought i'd see if someone else had come across.
Sep 24 13:27:04 <bluelightning> I'm afraid I don't know
Sep 24 13:27:18 <bluelightning> we don't have many examples of building external kernel modules it seems
Sep 24 13:28:05 <bluelightning> I see meta-ti has a couple of recipes that do, but they provide their own do_install
Sep 24 13:28:22 <gotan> @bluelightning: hmm.. looking into the the run.do_install for DEPMOD, shows that DEPMOD is set to echo "oe_runmake DEPMOD=echo INSTALL_MOD_PATH=...." which i do not understand,
Sep 24 13:29:24 <bluelightning> gotan: I suspect that's intended to prevent depmod from actually being run, because we don't want that to happen on the build system
Sep 24 13:29:46 <bluelightning> so we substitute it with "echo" so that it does nothing
Sep 24 13:34:38 <gotan> @blluelightning - would depmod being set cause this proble,?
Sep 24 13:46:48 <gotan> @bluelightning: It looks like its failing here in Makefile.modinst (http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.2/tree/scripts/Makefile.modinst?id=v3.2.18#n20), because that is where i think the mkdir is called, but the  cp command is that should populate the image
Sep 24 13:48:23 <gotan> FWIW i had to patch the kernel makefiles to handle passing INSTALL_MOD_PATH properly before it would create the extras folder in the modules directory
Sep 24 13:50:42 <gotan> @bluelightning: as per: http://us.generation-nt.com/answer/patch-1-2-makefile-add-install-mod-path-environment-used-by-depmod-help-206718972.html
Sep 24 14:03:01 <gotan> @bluelightning - thanks for the meta-ti pointer - as simple as using cp instead of install, and it works
Sep 24 14:07:43 <JaMa> what's expected behavior of "bitbake -c install A B" when A DEPENDS on B? should it run do_populate_sysroot on B too? It does and it's correct imho, just surprised me a bit
Sep 24 14:12:23 <RP> JaMa: That is what I'd expect, yes
Sep 24 14:13:09 <RP> JaMa: It correctly figures out that it can't install B without having A in the sysroot to configure B
Sep 24 14:13:21 <JaMa> ok, surprise was only because I sometimes use -c as "do exactly this task and stop there"
Sep 24 14:14:03 <JaMa> but to do more (to satisfy A) is of course better then A failing or showing error that it cannot run do_install in A
Sep 24 14:23:17 <RP> JaMa: It really means run everything needed to reach the points listed A:do_install B:do_install
Sep 24 14:23:52 <RP> JaMa: just like for example, bitbake somegitrecipe -c fetch could build git-native
Sep 24 14:25:42 <bluelightning> gotan: install should work as well - did you use install -d to create the directory first?
Sep 24 14:29:57 <gizero> hi! i'm a little concerned about kernel development workflow with linux-yocto
Sep 24 14:29:59 <gizero> I have a kernel module source file I want to test against linux-yocto kernel sources. I think I have two options here: 1. create a new recipe for an external module 2. add my source to the linux-yocto tree and patch Kconfig and Makefile accordingly.
Sep 24 14:30:01 <gizero> I'd prefer option number 2, because the module might be feasible for submission upstream in the future.
Sep 24 14:30:03 <gizero> Hence (using denzil):
Sep 24 14:30:05 <gizero> 1. bitbake linux-yocto -c unpack
Sep 24 14:30:07 <gizero> 2. add my file and patch Kconfig, Makefile
Sep 24 14:30:09 <gizero> 3. bitbake linux-yocto -c menuconfig
Sep 24 14:30:11 <gizero> 4. enable the new module (M)
Sep 24 14:30:13 <gizero> 5. bitbake linux-yocto
Sep 24 14:30:15 <gizero> Now, what's the suggested way to capture changes as patches (git workflow preferred) and, most importantly, how to iterate with bitbake in order to fix-recompile-deploy my module? ...I've read about "-c compile -f" but it's not clear to me how to trigger every other stage that's required to get the module packaged
Sep 24 14:38:05 <bluelightning> gizero: hi, which version are you using?
Sep 24 14:39:24 <gizero> bluelightning:  hi! the tip of denzil branch
Sep 24 14:41:53 <bluelightning> gizero: ok, there are patches queued for denzil to make -c compile -f trigger the other tasks when they are next called; however these are not in the denzil branch yet
Sep 24 14:43:10 <gizero> this probably explains my confusion... ;- ) I remember I read something in the list, but I was not sure it was strictly related...
Sep 24 14:44:37 <gizero> I'd like to develop my kernel patches (mainly driver and platform specification related) directly inside a yocto workflow, and I'm trying to figure out how to do that...
Sep 24 14:44:52 <gotan> @bluelighning - yes. I don't have a logfile handy, but chokes on this line (http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/package.bbclass?id=denzil-7.0.1#n204). something to do with poky vetting or similar anything that uses 'install' i think, as i tried a wildcard .k? in the install and it also dies here.
Sep 24 14:45:44 <gizero> I expected this to be the shortest path instead of having to validate the kernel work outside of yocto and than applying later
Sep 24 14:46:31 <_julian_> has anyone seen tvservice: no such file or directory on rpi-basic-image builds?
Sep 24 14:47:12 <bluelightning> gizero: I'm not totally familiar with the linux-yocto workflow myself, but perhaps zeddii can advise... ?
Sep 24 14:48:15 <gizero> bluelightning: so... should I consider my expected workflow to fail with current denzil or is there any workaroud to iterate my fix-n-deploy effort?
Sep 24 14:49:17 <bluelightning> gizero: you can run each individual step manually using -f, that's currently the only way unless you use -c cleansstate and rebuild the kernel from scratch each time
Sep 24 14:49:46 <bluelightning> the fixes for the denzil branch should be merged any day now however
Sep 24 14:50:46 <bluelightning> also, there's nothing preventing you from committing your changes with git and then using git format-patch to produce a patch which you can copy and add to SRC_URI in your kernel recipe
Sep 24 14:51:08 <bluelightning> that's not really recommended part of the linux-yocto workflow but it will work just file
Sep 24 14:51:12 <bluelightning> fine
Sep 24 14:51:34 <gizero> bluelightning: how to figure out the complete sequence of steps? I think kernel recipes are particular because they have custom steps like compile_kernelmodules
Sep 24 14:52:07 <gizero> bluelightning: I'll grab the patches as soon as they'll be merged
Sep 24 14:53:03 <zeddii> just work out of the build system if you really want to be independent, or in the devshell.
Sep 24 14:53:23 <bluelightning> gotan: when you say "dies" can you be more specific? that code you point to is about not splitting debug packages, it is not for any kind of validation
Sep 24 14:54:05 <zeddii> commit changes, dump patches, send them for merge (preferably)  or add them to a layer.
Sep 24 14:54:26 <zeddii> we also have meta-kernel-dev that builds out of a local clone if you want to make changes and stash them on branches locally.
Sep 24 14:55:55 <gizero> zeddii: devshell is something interesting I still have to explore. How about module packaging and deploying for test on real target? is it possible to trigger it from devshell also?
Sep 24 14:58:12 <gizero> I'll have to figure out pro and cons of all these approaches: I probably heard of them all, but need to have a deeper understanding... will look for more documentation
Sep 24 14:58:17 <zeddii> gizero, not that I've ever used, when I'm in devshell, I use the korg packaging or manually copy things around.
Sep 24 14:59:15 <walters> bluelightning: though ccache is used, so even "clean" builds are cached
Sep 24 14:59:52 <gizero> I'm leaving... thank you all for help!
Sep 24 14:59:53 <walters> not quite the same as pointing 'make' at a partially built tree, but a lot faster than from scratch
Sep 24 15:03:48 <_julian_> how can I clean all recipes of one layer so that they will all be rebuilt?
Sep 24 15:04:39 <msm`> bluelightning: do you know if "classes/cml1: ensure -c menuconfig forces a rebuild next time" and "bitbake: bitbake: ensure -f causes dependent tasks to be re-run" was planned to be re-added to denzil?
Sep 24 15:05:29 <bluelightning> msm`: well, "re-added" implies they were there before, I only properly backported them recently
Sep 24 15:06:16 <bluelightning> msm`: ping zenlinux to find out where he's got to with his denzil updates - those two are amongst them
Sep 24 15:07:14 <bluelightning> _julian_: there is no mechanism to do that, but that shouldn't be necessary anyway - the system should figure out what needs rebuilding if the metadata changes
Sep 24 15:08:44 <msm`> bluelightning: ok, so they are back in?
Sep 24 15:08:53 <_julian_> bluelightning: I think the tvservice problem I posted a few minutes ago is some linkage issue, that's why I wanted to do a forced rebuild
Sep 24 15:09:14 <bluelightning> msm`: I'm confused, they weren't ever in denzil in the first place...
Sep 24 15:09:30 <msm`> hmm, they were briefly in sgarmen's branch
Sep 24 15:09:38 <msm`> bluelightning: that's what i meant anyways
Sep 24 15:09:44 <bluelightning> msm`: ah, right, that's a different matter
Sep 24 15:09:45 <msm`> bluelightning: they may not have made it to official denzil
Sep 24 15:10:04 <msm`> bluelightning: so there are versions for scott to pick up now?
Sep 24 15:10:12 <bluelightning> msm`: yes
Sep 24 15:10:21 <msm`> bluelightning: sorry for the basic questions, have to keep track… thanks
Sep 24 15:10:27 <bluelightning> no worries
Sep 24 15:10:47 <bluelightning> I just wanted to be sure I knew what question I was answering :)
Sep 24 15:11:31 <msm`> bluelightning: did you post those new patches? or just tell scott?
Sep 24 15:11:45 <msm`> (trying to determine if i could have found this out on my own without asking)
Sep 24 15:13:06 <bluelightning> msm`: in this instance I did not post them, I probably should have
Sep 24 15:13:23 <zenlinux> msm`, bluelightning, I'll pull those in today
Sep 24 15:13:27 <zenlinux> and yes please post them to the ML
Sep 24 15:14:20 <msm`> bluelightning: ok, no worries.. for backports i usually don't post either
Sep 24 15:14:30 <msm`> bluelightning: but could if needed...
Sep 24 15:16:24 <zenlinux> fwiw my denzil-next branch is almost ready for a final pull request; just need to investigate the cause of some build failures for atom-pc
Sep 24 15:21:16 <gotan> @bluelightning: will try and dig out a logfile for the failure tomorrow.
Sep 24 15:26:24 <pidge> khem: You still need info on multilib?
Sep 24 15:27:06 <fray> khem, I made progress on Saturday with the multilib -- cross-canadian renaming..
Sep 24 15:42:31 <sgw> fray: ping on the RPM bug I filed late last week?
Sep 24 15:43:00 <fray> the silent stop?
Sep 24 15:43:15 <sgw> Yup!
Sep 24 15:43:49 <fray> I need more information.. if you can reproduce it, you need to run it with the set -x enabled so you know exactly what it was doing when it stopped..
Sep 24 15:44:18 <fray> I suspect that the problem is that RPM issued a failure, which got dumped to an attemptonly log -- so the message was hidden..
Sep 24 15:44:40 <fray> if thats the case, then it's as simple as adding || : after the attempt only --- attempt
Sep 24 15:44:44 <sgw> Sure thing, I now which line it was, and it was an attemptonly, is there a log I need to attach?
Sep 24 15:44:57 <fray> sec...
Sep 24 15:46:08 <sgw> fray, blasted the command to you pm
Sep 24 15:46:29 <fray> sgw -- did the system print out a message to the log?
Sep 24 15:47:36 <fray> something appears to have been reverted in Poky.. like 253 is my assumption
Sep 24 15:47:41 <fray> +                       $pkg_name >> "`dirname ${BB_LOGFILE}`/log.do_${task}_attemptonly.${PID}" 2>&1 || true
Sep 24 15:47:58 <fray> thats what it should be.. but assumping I'm looking at the right live.. it appears to be missing the 2>&1
Sep 24 15:48:52 <fray> nope -- I must have been in the wrong branch.. it is there
Sep 24 15:49:02 <fray> look at your attemptonly log..
Sep 24 15:49:22 <fray> an 'attemptonly' is followed by || true.. which -should- make it ignore any errors.. since they're not actually errors..
Sep 24 15:49:27 <sgw> fray, nothing of interest, just 3 packages
Sep 24 15:49:51 <fray> ya, figure out if it was line 368 that blew..
Sep 24 15:50:00 <fray> if you can figure out which line, then we can figure out if stopping on an error makes sense..
Sep 24 15:50:28 <msm`> can anyone wget this?
Sep 24 15:50:28 <msm`> wget http://www.thrysoee.dk/editline/libedit-20110802-3.0.tar.gz
Sep 24 15:50:38 <msm`> im trying on my build machine and it's failing with error 406
Sep 24 15:50:41 <msm`> it works in a web browers
Sep 24 15:50:42 <fray> nope
Sep 24 15:50:45 <msm`> browser*
Sep 24 15:50:48 <fray> same
Sep 24 15:50:49 <sgw> Ok, so add an || true and it works
Sep 24 15:51:12 <fray> ya.. but only add the true, if this is something that should be allowed to fail..
Sep 24 15:51:20 <fray> like 368 already has the || true....
Sep 24 15:53:26 <sgw> The failing line is 442
Sep 24 15:54:07 <sgw> So not sure if that's allowed to fail or not.
Sep 24 15:54:53 <fray> no.. 442 isn't supposed to fail
Sep 24 15:55:05 <sgw> fray: Well, then we have a problem!
Sep 24 15:55:05 <fray> no asserts or anything like that?
Sep 24 15:55:10 <sgw> Nope
Sep 24 15:55:25 <fray> I've seen a few cases where there have been asserts installing locale and -dbg files before..
Sep 24 15:55:46 <sgw> This is either dbg or dev files with multilib
Sep 24 15:55:46 <fray> I have a local patch (not sent up yet, because the RPM maintainer doesn't like it).. but you can give it a try and see if it resolves the problem..
Sep 24 15:55:54 <fray> but the propblem should be evident w/ an assert
Sep 24 15:56:28 <fray> (long story short -- there is a bug in BerkleyDB, where the DB lookup fails.. so you have to adjust your buffer size and retry until it works -- or you get an assert and just dump out)
Sep 24 15:56:50 <fray> how big is install_multilib.manifest?
Sep 24 15:56:56 <msm`> can anyone fetch that url I posted?
Sep 24 15:57:02 <msm`> wget http://www.thrysoee.dk/editline/libedit-20110802-3.0.tar.gz
Sep 24 15:57:10 <msm`> im really thinking this is a network issue for us
Sep 24 15:57:18 <fray> it doesn't work here..
Sep 24 15:57:23 <fray> Resolving www.thrysoee.dk... 94.231.109.254
Sep 24 15:57:23 <fray> Connecting to www.thrysoee.dk|94.231.109.254|:80... connected.
Sep 24 15:57:24 <fray> HTTP request sent, awaiting response... 406 Not Acceptable
Sep 24 15:57:24 <fray> 2012-09-24 10:55:27 ERROR 406: Not Acceptable.
Sep 24 15:57:31 <sgw> fray:  let me check that
Sep 24 15:58:31 <sgw> fray: Empty save 2 comments:
Sep 24 15:58:33 <sgw> # Install multilib manifest padding
Sep 24 15:58:33 <sgw> # Install multilib manifest padding
Sep 24 15:59:10 <fray> that is your error
Sep 24 15:59:19 <fray> touch ${target_rootfs}/install/install_multilib_solution.manifest
Sep 24 15:59:21 <fray> oops
Sep 24 15:59:25 <fray> pasted to RP..
Sep 24 15:59:32 <fray> look at lines 434 - 438
Sep 24 15:59:51 <fray> that file is 'touched' and should be blank.. then the if [ -s ... ] it should see it's empty and just go on
Sep 24 16:00:04 <fray> it it does make it in, it adds the padding..
Sep 24 16:00:28 <fray> so this says that it ran once, somehow "got in".. added the padding, and then added the padding a second time
Sep 24 16:00:47 <fray> RPM will do a non-zero if you ask it to install something, and there was nothing to install
Sep 24 16:01:19 <fray> (the padding is required due to historical signature issues w/ RPM.. you must have at least 15 (or something like that) in the text manifest file for it to be valid
Sep 24 16:10:52 <msm`> fray: ok, it works in a browser and not wget
Sep 24 16:11:03 <msm`> fray: which is weird
Sep 24 16:11:12 <msm`> i think we just need to drop that URL and find another mirror?
Sep 24 16:12:14 <fray> tells me they are badding wget for some reason
Sep 24 16:12:18 <fray> 'er.. banning
Sep 24 16:12:33 <fray> or there is a redirect that wget isn't honoring
Sep 24 16:19:22 <sgw> fray: building again I updated so it will be a few minutes
Sep 24 16:29:59 <msm`> fray: ok well at least i know it's not me
Sep 24 16:40:36 <zenlinux_> msm`, I just pulled bluelightning's menuconfig fix into sgarman/denzil-next: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=sgarman/denzil-next
Sep 24 16:41:20 <zenlinux_> whoops, need one more commit
Sep 24 16:41:31 <bluelightning> zenlinux_: heh, was just about to ask about that ;)
Sep 24 16:41:47 <blloyd> question about the menuconfig fix: if using the denzil branch, is it there?
Sep 24 16:42:30 <zenlinux_> blloyd, it's not in the official denzil branch yet, I have it in a staging branch that needs to get some testing first
Sep 24 16:43:05 <zenlinux_> a week or so ago I had what I thought was a fix for it but it wasn't the right approach, bluelightning just gave me a better version that I expect will be final
Sep 24 16:44:09 <blloyd> considering my hammer (cleansstate before doing menuconfig) makes for slow work, I really look forward to a fix.  Esp one that lets iterative use of menuconfig adding a few things at a time.
Sep 24 16:47:22 <zenlinux_> blloyd, I hear you, things have been slow getting things tested as the autobuilder is under heavy use for the end of 1.3
Sep 24 16:47:45 <zenlinux_> You know, I thought the git auto-packing process was supposed to work once and then not have to be run again for a while? I'm getting it all the time now
Sep 24 16:49:48 <bluelightning> zenlinux_: so am I, everty time I push to poky-contrib
Sep 24 16:49:58 <bluelightning> :/
Sep 24 16:50:34 <zenlinux_> maybe halstead needs to do something to the entire poky-contrib repo?
Sep 24 16:51:49 <halstead> I can gc the bare repo after a backup. Perhaps that would help?
Sep 24 16:52:28 <zenlinux_> not sure, I'm not intimately familiar with the cause of the problem
Sep 24 16:53:42 <zenlinux_> ok, my denzil-next branches have been rebased and should have the complete menuconfig fixes.
Sep 24 16:53:47 * zenlinux_ needs to head into the office today
Sep 24 17:13:50 <khem> fray: around ?
Sep 24 17:14:20 <khem> fray: I am playing with mulitilib and was trying to add lib32-gcc-runtime to image
Sep 24 17:14:42 <khem> fray: but rpm kept telling me that it cannot find gcc-runtime package
Sep 24 17:15:02 <khem> if I say add lib32-eglibc that works ok
Sep 24 17:15:29 <khem> all build time dependencies are resolved correctly and also the image has 32bit libs
Sep 24 17:15:46 <khem> what drive multilib packaging is not clear to me
Sep 24 17:25:13 <fray> khem, I'm back now
Sep 24 17:25:53 <fray> khem, I haven't gone that far into the multilib installs (w/ RPM).. but I suspect the debian renaming stuff isn't working properly..
Sep 24 17:26:37 <fray> For teh IMAGE_INSTALL, you need to be sure to list the lib32-... package as referenced by the 'PACKAGES' variable in that item..
Sep 24 17:26:50 <fray> if it's there, and on the disk the name is different (so it doesn't work) then it's the debian rename that is busted..
Sep 24 17:28:20 <msm`> khem: try lib32-libgcc{,-dev}
Sep 24 17:28:47 <msm`> to get a full toolchain for both multilib targets I need the following:
Sep 24 17:28:48 <msm`> images/fsl-image-full.bb:       ${@multilib_pkg_extend(d, "gcc")} \
Sep 24 17:28:48 <msm`> images/fsl-image-full.bb:       ${@multilib_pkg_extend(d, "binutils")} \
Sep 24 17:28:48 <msm`> images/fsl-image-full.bb:       ${@multilib_pkg_extend(d, "libgcc-dev")} \
Sep 24 17:28:48 <msm`> images/fsl-image-full.bb:       ${@multilib_pkg_extend(d, "eglibc-dev")} \
Sep 24 17:29:02 <msm`> in my limited playing around with these things
Sep 24 17:55:10 <khem> msm`: I tried that on friday IIRC
Sep 24 17:55:21 <khem> msm`: Lemme see again after this build is done
Sep 24 18:01:57 <msm`> there was some weird issue with libgcc being missing i had to debug
Sep 24 18:02:10 <msm`> but i think the above packages added on the ML side fixed it up
Sep 24 18:10:34 <yao> can I ask that soname file is written by bitbake or done by package itself in yocto?
Sep 24 18:15:54 <khem> yao: bitbake drives the overall build which then drives individual package builds, when package is built it calls a package backend system like rpm or dpkg or ipk to write our the packages and the sonames will be going into these pakcages based on the rules defined in the bitbake recipe for that package if you do not define the locations where it should go on the target then it will use the defaults which is usually true for 90% of 
Sep 24 18:18:21 <yao> khem: I am bitbaking a package which package itself only install realname library and bitbake do_package does recognize its soname but I don't see the soname file
Sep 24 18:19:04 <yao> in the .provides does say package.so.1 (soname) but didn't see the soname file
Sep 24 18:20:18 <yao> I can definitely write a link in the Makefile or do_install to install the soname file, but not sure who should do it, package's install or do_package function?
Sep 24 18:20:59 <khem> well. Usually bitbake does not interfere with lowlevel build of a package
Sep 24 18:21:15 <khem> and it lets the packages's own build system do the job
Sep 24 18:21:54 <khem> but we do patch stuff in do_intall; do_compile etc. to overcome some of shortcomings that a package's build system may have from OE's needs
Sep 24 18:21:59 <khem> so its upto you
Sep 24 18:22:24 <khem> if you think its necessary to patch the package's own build system and would make sense for more than OE then go for it
Sep 24 18:22:32 <khem> and you can even submit it to package upstream
Sep 24 18:22:51 <khem> if its something thats specfic to OE then better to do it in recipe rules
Sep 24 18:23:16 <yao> soname file should be generated by ldconfig but I know in yocto, it is not like a desktop system, where to do the ldconfig's job
Sep 24 18:25:27 <khem> yao: we have cross ldconfig
Sep 24 18:26:08 <khem> yao: but image creator will run it
Sep 24 18:26:16 <khem> so you may not need to do it
Sep 24 18:26:29 <yao> khem: where is this done? in which task? do_package or do_package_write_rpm
Sep 24 18:26:41 <yao> oh, it is after package built
Sep 24 18:26:45 <khem> yes
Sep 24 18:26:50 <khem> its the image building step
Sep 24 18:27:49 <yao> so if I have a package bitbaked but it only install the realname share library and the linkname, when image is created, the soname file will be generated?
Sep 24 18:28:49 <khem> yao: IIRC yes
Sep 24 18:29:04 <khem> msm`: hmm lib32-libgcc-4.7.2-r13 do_compile (pid 29100)
Sep 24 18:29:27 <khem> msm`: so its building it lets see if rpm will package it too
Sep 24 18:32:10 <yao> thanks khem! I tried to install the package again(rpm package) and the soname is installed, it is weird that the image has no this soname file created:(
Sep 24 18:40:55 <sgw> fray: that took longer then I wanted, it looks like the package_install_internal_rpm is getting called twice and that's what's causing the install_multilib.manifest to have double padding, but why is it getting the padding in the first place since the file should have been empty, I even removed it between runs
Sep 24 18:41:13 <sgw> fray: I will be back in around 1:30 ish my time.
Sep 24 18:41:35 <fray> yup.. thats the real issue.. bad 'test' binary?  something dumping in a byte?
Sep 24 18:41:37 <fray> dunno
Sep 24 18:52:06 <khem> fray: https://gist.github.com/3777598
Sep 24 18:52:14 <khem> fray: thats the problem I was seeing
Sep 24 18:52:28 <khem> so build time dependencies are resolved ok
Sep 24 18:52:37 <khem> both libgcc's are built
Sep 24 18:52:45 <khem> but when generating the rfs it complains
Sep 24 18:53:48 <fray> I don't know..  it's checking "re_64b, x86_64, all, lib32_x86" for the files.. is the libgcc (multilib) located in any of those directories?
Sep 24 18:55:07 <khem> libgcc-s1-4.7.2-r13.lib32_x86.rpm is there in lib32_x86
Sep 24 18:55:25 <fray> is the 's1' in the name?
Sep 24 18:55:47 <fray> rpm -qip <package>
Sep 24 18:55:52 <khem> fray: seems so because PV = 4.7.2
Sep 24 18:55:52 <fray> that should show the name (and other fields)
Sep 24 18:56:14 <khem> Name        : libgcc-s1
Sep 24 18:56:14 <khem> Version     : 4.7.2
Sep 24 18:56:30 <khem> hmmm
Sep 24 18:56:39 <fray> ok.. then what RPM needs to try to install is libgcc-s1...  but is libgcc the 'PACKAGES' name from the recipe?  (bitbake <recipe> -e | grep PACKAGES)
Sep 24 18:56:51 <khem> rpm -qip tmp/deploy/rpm/x86_64/libgcc1-4.7.2-r13.x86_64.rpm
Sep 24 18:56:56 <khem> Name        : libgcc1
Sep 24 18:56:56 <khem> Version     : 4.7.2
Sep 24 18:57:07 <fray> ya, it's definitely teh s1 then..
Sep 24 18:57:52 <khem> PACKAGES="lib32-libgcc lib32-libgcc-dev lib32-libgcc-dbg lib32-libgcov-dev"
Sep 24 18:58:07 <fray> ya, then lib32-libgcc is the right name to use.. it's the debian renaming that is failing..
Sep 24 18:58:11 <fray> sounds like a bug..
Sep 24 18:58:48 <khem> OK so to reproduce it enabled multilib like here https://wiki.yoctoproject.org/wiki/Multilib
Sep 24 18:59:29 <khem> and then add lib32-libgcc to IMAGE_INSTALL
Sep 24 18:59:33 <chackal_sjc> does any one has a recipe for pm-utils?
Sep 24 19:00:01 <chackal_sjc> or, at least does someone knows how to perform some tasks before and after a suspend/resume... like turning off the wifi, etc
Sep 24 19:00:05 <fray> khem, but that will only fail -if- the libgcc name is changed by the debian rename..
Sep 24 19:00:11 <fray> at least in many cases that won't happen
Sep 24 19:00:31 <fray> Can you check if the debian rename has a check for libgcc (or similar).. it might be as simple and changing the filter to include the MLPREFIX
Sep 24 19:01:55 <khem> fray:                     mlpre=d.getVar('MLPREFIX', True)
Sep 24 19:01:56 <khem>                     if mlpre:
Sep 24 19:01:56 <khem>                         if not newpkg.find(mlpre) == 0:
Sep 24 19:01:56 <khem>                             newpkg = mlpre + newpkg
Sep 24 19:01:56 <khem>                     if newpkg != pkg:
Sep 24 19:01:58 <khem>                         d.setVar('PKG_' + pkg, newpkg)
Sep 24 19:02:10 <khem> thats from debian.bbclass
Sep 24 19:02:38 <fray> this is something unique to libgcc though (most likely)
Sep 24 19:02:54 <fray> if you change your defautl lib, does the 32-bit one get named "libgcc" or "libgcc-s1"?
Sep 24 19:03:02 <fray> and can you make an image that just installs "libgcc" and does it work?
Sep 24 19:03:28 <fray> the problem is simply the mismatch from the internal runtime name (package name), and the debian renamed version..
Sep 24 19:03:38 <khem> k
Sep 24 19:03:41 <fray> something isn't doing the rename consistently -- maybe even parts of the RPM install is missing it..
Sep 24 19:04:01 <khem> I really dont need debian renaming even
Sep 24 19:04:14 <khem> is it ok to disable it ?
Sep 24 19:04:46 <fray> yup..
Sep 24 19:04:51 <fray> I usually do when I debug this stuff..
Sep 24 19:05:07 <fray> (I really hate the debian rename.. and it doesn't seem to always work, but I've not had time to diagnose it and figure out why)
Sep 24 19:05:12 <fray> just remove it from the user classes
Sep 24 19:05:20 <fray> bbiab, need food
Sep 24 19:06:58 <khem> meta/conf/distro/defaultsetup.conf:INHERIT_DISTRO ?= "debian devshell sstate license"
Sep 24 19:07:09 <khem> hmmm I dont want to get totally out of sync
Sep 24 19:07:17 <khem> so would prefer to fix it
Sep 24 19:11:33 <khem> fray: I think I found a fix let me try it
Sep 24 19:14:05 <khem> chackal_sjc: meta/recipes-bsp/pm-utils/pm-utils_1.4.1.bb
Sep 24 19:19:51 <khem> fray: I did this change https://gist.github.com/3777770
Sep 24 19:20:15 <khem> fray: and now I get
Sep 24 19:20:17 <khem> $ rpm -qip tmp/deploy/rpm/lib32_x86/libgcc1-4.7.2-r13.lib32_x86.rpm
Sep 24 19:20:17 <khem> warning: tmp/deploy/rpm/lib32_x86/libgcc1-4.7.2-r13.lib32_x86.rpm: Header V4 DSA/SHA1 Signature, key ID e990357d: NOKEY
Sep 24 19:20:20 <khem> Name        : libgcc1
Sep 24 19:20:23 <khem> Version     : 4.7.2
Sep 24 19:20:25 <khem> Release     : r13
Sep 24 19:20:28 <khem> Architecture: lib32_x86
Sep 24 19:21:55 <khem> but rpm still complains :(
Sep 24 19:21:56 <khem> | unable to find package libgcc
Sep 24 19:21:57 <khem> | ERROR: some packages were missing
Sep 24 19:22:15 <fray> thats cause it's called 'libgcc1", not libgcc
Sep 24 19:22:45 <khem> so I should change from lib32-libgcc in IMAGE_INSTALL to lib32-libgcc1
Sep 24 19:22:48 <fray> again, something is fishy w/ the renam..
Sep 24 19:22:49 <khem> ?
Sep 24 19:23:08 <fray> IMAGE_INSTALL needs to match 'PACKAGES', because it injects a runtime dependency into bitbake
Sep 24 19:23:21 <fray> if PACKAGES entry and the final name don't match, then the rename stuff should be correcting it..
Sep 24 19:23:44 <khem> hmmm packages says lib32-libgcc
Sep 24 19:24:21 <fray> yup.. thats the one you should be using in IMAGE_INSTALL
Sep 24 19:24:46 <khem> but rpm still complains
Sep 24 19:25:06 <fray> yes, because the filename doesn't match -- and the remapping isn't working
Sep 24 19:25:12 <fray> find/fix the remapping problem
Sep 24 19:25:31 <khem> OK so there are two problems here
Sep 24 19:25:33 <fray> turning off the debian crap should have removing the need for remapping
Sep 24 19:25:55 <khem> hmmm I see it
Sep 24 19:26:02 <kergoth> msm: fyi, i was never able to repro your -e/EXTRA_OEMAKE errors. we're building on centos5 on our autobuilder with EXTRA_OEMAKE += "'CWARNFLAGS='" successfully
Sep 24 19:26:22 <khem> but thats my other option since OE-Core and poky do debian renaming by default a fix is needed however
Sep 24 19:26:25 <kergoth> msm: re: libx11
Sep 24 19:26:41 <fray> khem, I agree.. it needs to be fixed
Sep 24 19:34:42 <msm> kergoth: have you tried nativesdk-libx11?
Sep 24 19:40:38 <khem> fray: I see that in non multilib case this rename from libgcc -> libgcc1 seems to work ok
Sep 24 19:40:45 <khem> fray: how could that be
Sep 24 19:41:15 <fray> I have no idea.. it's got to be something fishy in the way the mapping is called in the multilib case -- or the debian library is just broken..
Sep 24 19:41:26 <fray> I know I've had problems in the past, but never had time to track them all down..
Sep 24 19:47:54 <msm> kergoth: of which i htink i have a fix for too
Sep 24 20:00:32 <kergoth> haven't, nice
Sep 24 20:03:08 <khem> fray: how is resolvedb generated ?
Sep 24 20:03:20 <khem> fray: it seems that its missing ml info
Sep 24 20:03:23 <khem> somehow
Sep 24 20:03:35 <khem> ./tmp/sysroots/x86_64-linux/usr/bin/rpmresolve /work/yocto/poky/build/tmp/deploy/rpm/solvedb-ml_archs.conf /work/yocto/poky/build/tmp/work/re_64b-poky-linux/core-image-junos-1.0-r0/rootfs/install/ml_archs.pkglist -o /work/yocto/poky/build/tmp/work/re_64b-poky-linux/core-image-junos-1.0-r0/rootfs/install/install_multilib.manifest
Sep 24 20:03:40 <khem> unable to find package libgcc
Sep 24 20:03:45 <fray> for each directory (see the logs, near the top) it runs through and simply creates a virtual system w/ all of the packages installed in it
Sep 24 20:03:53 <khem> solvedb-ml_archs.conf has
Sep 24 20:04:00 <khem> /work/yocto/poky/build/tmp/deploy/rpm/lib32_x86/solvedb
Sep 24 20:04:01 <khem> /work/yocto/poky/build/tmp/deploy/rpm/all/solvedb
Sep 24 20:04:16 <fray> each of those is 'just' an RPM database..
Sep 24 20:04:34 <khem> how can I read whats in there
Sep 24 20:04:50 <khem> cat /work/yocto/poky/build/tmp/work/re_64b-poky-linux/core-image-junos-1.0-r0/rootfs/install/ml_archs.pkglist
Sep 24 20:04:53 <khem> eglibc
Sep 24 20:04:56 <khem> libgcc
Sep 24 20:04:58 <khem> so it has two packages in there
Sep 24 20:05:01 <khem> eglibc is fine
Sep 24 20:05:05 <khem> libgcc is not found
Sep 24 20:05:48 <fray> (using the OE version of rpm) you can do rpm -D "_dbpath <dbpath>" -D "__dbi_txn create nofsync" -qa
Sep 24 20:06:13 <fray> the <dbpath> is .../tmp/deploy/rpm/all/solvedb
Sep 24 20:06:16 <fray> adjust as needed
Sep 24 20:06:22 <fray> must be an absolute path
Sep 24 20:07:12 <khem> hmm ok it has libgcc1-4.7.2-r13.lib32_x86
Sep 24 20:07:26 <khem> and I am asking for libgcc
Sep 24 20:07:31 <fray> yup
Sep 24 20:07:33 <fray> the renaming issue
Sep 24 20:07:37 <khem> so now where does this renaming happening
Sep 24 20:07:39 <khem> before asking
Sep 24 20:08:13 <fray> is that the mapping_rename_hook?
Sep 24 20:08:18 <fray> (I'm honestly not sure)
Sep 24 20:09:14 <khem> hmm problem is that normal libgcc is not included as it seems
Sep 24 20:09:29 <khem> so I dont know if renaming works for non multilib case or not
Sep 24 20:09:40 <fray> the rename has to happen on the full 'lib32-libgcc' name, it should result in lib32-libgcc1, which should then have the mlprefixed stripped..
Sep 24 20:10:10 <khem> hmmm
Sep 24 20:10:26 <khem> https://gist.github.com/3777770
Sep 24 20:10:31 <khem> hmmm so I should make it
Sep 24 20:10:44 <khem> DEBIANNAME_${MLPREFIX}libgcc = "${MLPREFIX}libgcc1"
Sep 24 20:11:36 <fray> I -think- that will work
Sep 24 20:11:40 <khem> lemme try it
Sep 24 20:25:05 <khem> fray: DEBIANNAME_lib32-libgcc="lib32-libgcc1"
Sep 24 20:25:12 <khem> still no pie :)
Sep 24 20:28:34 <khem> oh thats being added by debian.bbclass anyway so my changing to ${MLPREFIX}libgcc1 is not needed
Sep 24 20:45:20 <gotan> hi, having trouble with ERROR: QA Issue: Architecture did not match (3 to 62)
Sep 24 20:45:39 <khem> gotan: which package ?
Sep 24 20:46:00 <gotan> which is wierd, because the other thing in the package is a kernel module and it does not complain about it.
Sep 24 20:46:09 <RP__> khem: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t5&id=4878a92990d37b7e45706d391f32f32a8ec023b2
Sep 24 20:46:15 <gotan> and builds ok for a 64 bit target,
Sep 24 20:46:37 <RP__> khem: Pieces of that might help some of the renaming issues. it was a discussion I had with someone but never got it finished
Sep 24 20:47:19 <gotan> @khem: own package that builds a kernel module and a server tool.
Sep 24 20:48:58 <khem> RP__: I am trying to fish it out
Sep 24 20:49:26 <khem> RP__: libgcc -> libgcc1 rename is detectable but not multilib one
Sep 24 20:49:34 <khem> RP__: I am currently trying to debug it
Sep 24 20:49:53 <khem> databases contain libgcc1_* rpms in both cases
Sep 24 20:50:16 <khem> its asking a map from libgcc:ml
Sep 24 20:50:20 <gotan> @khem what approach should i use to  track it down?
Sep 24 20:50:27 <khem> I am not able to figure out where the rename code is
Sep 24 20:51:35 <khem> RP__: hmm
Sep 24 20:51:36 <khem> ok
Sep 24 20:51:43 <khem> that patch could solve my issue
Sep 24 20:51:46 <khem> lemme try that
Sep 24 20:54:46 <khem> gotan: well I think you are not linking it with right set of tools
Sep 24 20:54:58 <khem> gotan: make sure it can be cross compiled
Sep 24 21:28:03 <sgw> fray: Ok, I will insert some more debugging before that test and see what happens.
Sep 24 21:29:34 <gotan> hi again,  what approach should i use to  track down "ERROR: QA Issue: Architecture did not match (3 to 62)". i'm compiling for a 'custom tuned' i586 based host on an x_64 platform - any pointers?
Sep 24 21:31:52 <fray> simple -- you ended up with a binary that didn't match the target..
Sep 24 21:32:08 <fray> if the item is a bootloader, then it may be ok, and you can disable the check.. if the item was userspace, it's wrong and you need to figure out why..
Sep 24 21:32:16 <fray> (we really need to map the numbers to names)
Sep 24 21:32:52 <fray> FYI..  62 is x86_64, while 3 is ix86
Sep 24 21:32:53 <gotan> google implies one is 586 and the other is _64
Sep 24 21:33:26 <gotan> @fray - package is a kernel module + tool the module compiles wihtout complaints, the tool generates the error.
Sep 24 21:33:32 <fray> so it says that it was '3' and got '62'  (expecting ix86 and got x86_64)
Sep 24 21:33:50 <fray> the tool is being packaged and is NOT runnable on the target, that is the error..
Sep 24 21:34:10 <gotan> @fray - which makes sense because i built the distro for a x64 first.
Sep 24 21:34:39 <gotan> and am now trying a 586 target with the same distro
Sep 24 21:36:29 <gotan> looking to see  the direcories in tmp/work it may create.
Sep 24 21:37:02 <gotan> fyi the package is supposed to be in the core image.
Sep 24 21:38:30 <gotan> and is bening built in the tmp/work/<myi586target> directrory
Sep 24 21:40:06 <ccssnet> so anyone in here goto the ESC DesignCon East 2012 expo in boston?
Sep 24 21:42:31 <khem> gotan: show us the recipe
Sep 24 21:42:37 <khem> that may lead to some clues
Sep 24 21:42:54 <khem> most probably your package is not cross compile friendly
Sep 24 21:43:17 <khem> and it picks up the build system to be the host/target systrm as well
Sep 24 21:45:36 <gotan> @khem i think i have it. It is the insidious make vs make -e problem. i've been having when using submake rules.
Sep 24 21:47:03 <gotan> @khem any pointers to find what is or isnot cross compile friendly? the sub makefile is pretty simple.
Sep 24 21:51:08 <gotan> i can tell you that most of the problems i've had with packages have been using make -C without make -e -C
Sep 24 21:54:24 <ant____> andrea.adamiant8468
Sep 24 21:55:32 <gotan> @khem - any idea if including the module class in a recipe that generates more than a module is an issue? i;ve used devshell and temp/run.do_compile, and the application uses the i586 compiler according to the logfile.
Sep 24 21:57:41 <khem> gotan: generally you could divide this up into two recipes
Sep 24 21:57:49 <khem> since I assume the userspace parts are common
Sep 24 21:57:56 <khem> and kernel module part is different
Sep 24 21:58:05 <khem> its much easier to maitain it that way
Sep 24 21:58:12 <khem> I have such usecases here
Sep 24 21:58:17 <khem> and they are divided
Sep 24 22:00:01 <gotan> i@khem the module is supplied as a tarfile with module and tools. I  could create and maintin two repo's for it, but i'd prefer to patch a tarfile/one repo
Sep 24 22:00:55 <gotan> @khem the point is though that something is broken if its building for the wrong target platform.
Sep 24 22:01:23 <gotan> @khem even if the target is the compiling host
Sep 24 22:01:40 <khem> gotan: upto you. How you want to design the recipes many times it depends on the bits you are considering
Sep 24 22:02:07 <khem> I dont know what you are doing so I can only hint
Sep 24 22:04:21 <gotan> @khem - the tarball has a master makefile which builds the various things, module - tools - etc, as sub makes. and attempts to package up the result appropratly.
Sep 24 22:05:28 <gotan> for the sake of argument the two submakes i use to make the 'kernel module' package are a kernel module submake and a userspace tool submake.
Sep 24 22:07:31 <gotan> so wthe wierd thing is that running a devshell , run.do_make shows that the package the QA compains about it compiled with the appropriate compiler.
Sep 24 22:07:43 <gotan> i586 i mean
Sep 24 22:09:47 <khem> gotan: sometimes they are not cross compiler friendly please check from that angle
Sep 24 22:12:35 <sgw> fray: If you are still around, I am not getting valid (?) data in the install_multilib.mainfest, so it adds the pad and then adds it a second time and silently fails.
Sep 24 22:13:33 <fray> what data do you get in there?
Sep 24 22:13:42 <fray> it should be empty, unless you are installing multilibs
Sep 24 22:14:10 <sgw> fray: just: /intel/poky/builds/multilib/tmp/deploy/rpm/lib32_qemux86_64/packagegroup-core-boot-1.0-r10.lib32_qemux86_64.rpm
Sep 24 22:14:24 <sgw> I am doing multilib install
Sep 24 22:14:26 <khem> RP__: hey that patch seemed to solve my problem
Sep 24 22:14:27 <fray> that looks correct (assuming the path is)
Sep 24 22:14:35 <khem> RP__: along with 1 gcc patch
Sep 24 22:14:39 <fray> the file should get just that, plus the pad
Sep 24 22:14:48 <sgw> 2 pads second time through
Sep 24 22:15:10 <fray> so is it three lines or two.. the file should never be JUST the pads..
Sep 24 22:15:26 <fray> if it is, then somehow data got dumped and ever overwritten or the data was invalid (i.e. a space or \n)
Sep 24 22:15:32 <sgw> at this point that's what it looks like, yes.
Sep 24 22:16:05 <sgw> Yea, maybe I missed something earlier, I can try and scroll back, but I am still getting the silent fail
Sep 24 22:16:21 <fray> I'd suggest just prior to the if [ -s ... ] stat the file or something (for debugging).. do the same right after you enter.. mae sure it's not a race
Sep 24 22:17:04 <sgw> sure can do that, so what's next then?
Sep 24 22:17:37 <fray> look at te log and see if you can figure out what the filesize was before it entered.. when it does if it's something stupid small, like 1 byte.. that might be a clue
Sep 24 22:18:12 <sgw> Wait, I think we are talking cross-purpose now.
Sep 24 22:20:56 <sgw> Let's back up, the install_multilib.manifest seems to now contain some vaild info, and the package_install_internal_rpm() gets called twice, first time install_multilib.manifest get the packagegroup-core-boot added to it, along with the pad, and all is OK, next time package_install_internal_rpm() gets called (I think with COMPLEMENTARY_RPM set), the install_multilib.manifest still contains the packagegroup-core plus a pad and then gets a secon
Sep 24 22:21:32 <sgw> Fray: ^^^^^
Sep 24 22:21:35 <fray> that shouldn't happen..
Sep 24 22:21:43 <fray> the complementary pass should be clearing the files..
Sep 24 22:21:56 <sgw> fray ah ha, that's the problem then!
Sep 24 22:22:09 <sgw> where should the clearing occur?
Sep 24 22:22:29 <sgw> I don't see any rm of the manifest files
Sep 24 22:22:41 <fray> when the complementary runs, one of the first thing that happens is a setting of the files and that should do it..
Sep 24 22:22:50 <fray> it's been a few weeks since I looked through it though
Sep 24 22:23:35 <fray> image.bbclass:
Sep 24 22:23:42 <fray>        if [ -s ${WORKDIR}/complementary_pkgs.txt ]; then
Sep 24 22:23:43 <fray>             echo "Installing complementary packages"
Sep 24 22:23:43 <fray>             rootfs_install_packages ${WORKDIR}/complementary_pkgs.txt
Sep 24 22:23:43 <fray>         fi
Sep 24 22:24:07 <fray> rootfs_install_packages() {
Sep 24 22:24:08 <fray>         # Note - we expect the variables not set here to already have been set
Sep 24 22:24:08 <fray>         export INSTALL_PACKAGES_RPM=""
Sep 24 22:24:08 <fray>         export INSTALL_PACKAGES_ATTEMPTONLY_RPM="`cat $1`"
Sep 24 22:24:08 <fray>         export INSTALL_PROVIDENAME_RPM=""
Sep 24 22:24:08 <fray>         export INSTALL_TASK_RPM="rootfs_install_packages"
Sep 24 22:24:08 <fray>         export INSTALL_COMPLEMENTARY_RPM="1"
Sep 24 22:24:09 <fray>         package_install_internal_rpm
Sep 24 22:24:09 <fray> }
Sep 24 22:24:11 <fray> (I'm done pasting)
Sep 24 22:24:41 <fray> something there should be clearing the values that are passed to the install..  the attemptonly_rpm should have been 'cleared'..  so then package_install_internal_rpm, should see it and write out the file
Sep 24 22:25:09 <fray> complementary packages should always bee attemptonly items BTW
Sep 24 22:25:56 <sgw> fray: are you able to look at this, because I am lost here, I mean I can follow what's going on , but I am not sure where the clearing of those files in /install or even which files (besides the install_multilib.manifest)
Sep 24 22:26:54 <fray> package_install_internal_rpm is the function that I suspect shouldbe clearing it.. that should be in package_rpm.bbclass
Sep 24 22:27:15 <sgw> fray, I am guessing in the _internal_rpm() code, do the same thing for that manifest as we doo fir initial and total soultions?
Sep 24 22:27:32 <fray> near the top of the function there is a step that clears old manifest files..
Sep 24 22:27:42 <fray> following that is the startup of others..
Sep 24 22:27:44 <sgw> yeah, we are looking at the same place
Sep 24 22:27:58 <fray> basically teh stuff should all be zeroed either implicitly as it runs, or explicitly
Sep 24 22:28:25 <fray> so I'd search that function on where that file is generated and "back-up"..
Sep 24 22:28:33 <fray> either rm -rf it, or force it to be null..
Sep 24 22:28:46 <fray> my guess is that touch (or something right before it) might need to be zeroing it instead..
Sep 24 22:30:50 <sgw> fray: why don't we pad when we create that file after the rpmresolve in process_pkg_list_rpm()?
Sep 24 22:31:04 <fray> because if the padding is there, I can't tell if it's empty or not
Sep 24 22:31:23 <fray> I use the existence of data in the file as the key that there is work to do.. then pad to make sure it's big enough
Sep 24 22:31:34 <sgw> ah yes, Ok got it, so I am going to try doing the rm -f right before that rpmresolve
Sep 24 22:32:12 <fray> just as an FYI -- I'm getting ready to propose we move to 'SMART' from Zypper.. (and it's mess)
Sep 24 22:32:25 <fray> if we do that, we'll update the package_rpm/rootfs_rpm to be more sane
Sep 24 22:32:45 <sgw> fray: can you point me at 'SMART'?
Sep 24 22:34:33 <fray> http://labix.org/smart
Sep 24 22:35:14 <fray> BTW this isn't 1.3.. this is 1.4
Sep 24 22:35:39 <sgw> fray: Yeah, I figured that much!
Sep 24 22:36:32 <sgw> nope not the right place since process_pkg_list_rpm does not get called in that complementary case!
Sep 24 22:37:52 <fray> I -really- want to gut package_rpm and rootfs_rpm..
Sep 24 22:44:06 <msm> kergoth: thanks for the _FOR_BUILD foo - i never caught on to that
Sep 24 22:51:16 <sgw> fray: Ok, I seem to have gotten past that issue, but I am still getting a failure during the actual install using the total_solution.manifest
Sep 24 22:52:36 <kergoth> msm: np. the only reason i noticed was i checked libx11 to see if we still built makekeys native manually in the do_compile/do_configure or if it had changed (obviously it had changed) :)
Sep 24 22:53:04 <fray> I almost have a (local) patch for multilib cross-canadian packages working..
Sep 24 22:53:19 <fray> I have to sync it to master, and submit it for others to look at it though...  it's funky in a few places..
Sep 24 22:53:58 <msm> kergoth: i saw those vars, i just did not think they might be used for that. it seems pretty standard… i learned something ;)
Sep 24 22:55:10 <kergoth> *_FOR_BUILD of course aren't oe/poky notions, but they are used in a number of projects. iirc they're used in the toolchain bits too. of course oe/poky has BUILD_CC & friends
Sep 24 22:55:13 * kergoth goes to get some food
Sep 24 23:15:57 <sgw> fray: the final RPM with the total solution manifest and complentary packages dies with no indications still,
Sep 24 23:16:17 <fray> add '-vvv' to the RPM call..
Sep 24 23:16:50 <sgw> can I run that rpm call standalone or does it need directory and env info ?
Sep 24 23:17:03 <sgw> exit code 64!
Sep 24 23:17:07 <fray> you SHOULD be able to.. (devshell mmaybe?)
Sep 24 23:17:24 <fray> the exit code doesn't mean anything -- unless it was installing..  then the exist code is the number of packages it tried to install
Sep 24 23:18:45 <sgw> Ok so it exited cleanly apparently, with 64 packages installed (that's the right count, but I am not seeing a echo $? that I put right after that rpm!
Sep 24 23:36:52 <khem> fray: What do you know about yocto live images
Sep 24 23:37:04 <khem> fray: its for an x86 system
Sep 24 23:37:15 <fray> very little..
Sep 24 23:37:35 <khem> may be sgw or someone from Intel could educate me a little
Sep 24 23:37:48 <khem> fray: btw. RP has a patch that fixes the multlib worries
Sep 24 23:38:03 <khem> fray: and now I have an image thats running 32bit c/c++ progs
Sep 24 23:38:17 <fray> ya, I saw..  I'm really not sure exactly what out of that is needed, but it does resolve the mapping problems?
Sep 24 23:38:25 <khem> yes
Sep 24 23:38:38 <khem> I was looking at wrong place for mapping
Sep 24 23:39:07 <khem> nitink1: you might educate me on boot images for x86 now that you do BSPs
Sep 24 23:39:15 <fray> did you just use the whole patch, or can you shrink it to just the mapping changes?
Sep 24 23:39:24 <khem> nitink: on a typical x86 system
Sep 24 23:39:26 <fray> I'd like to get them, but I haven't had time yet to dig that stuff out
Sep 24 23:39:31 <khem> fray: I did not bother to bisect
Sep 24 23:39:35 <khem> no time for that :)
Sep 24 23:46:45 <sgw> khem: what's up, I had just stepped away
Sep 24 23:49:06 <khem> sgw: hey
Sep 24 23:49:20 <khem> sgw: I am trying to build a bootable image for an x86 server
Sep 24 23:49:31 <khem> so on USB device
Sep 24 23:49:35 <khem> whats usual method ?
Sep 24 23:49:43 <khem> I have got my own image
Sep 24 23:49:49 <khem> what do I need in there
Sep 24 23:49:57 <sgw> khem: live image, take a loot at the atom-pc in meta-yocto
Sep 24 23:49:57 <khem> I think I can dd it to a device may be ?
Sep 24 23:50:04 <khem> sgw: ok
Sep 24 23:50:11 <khem> does it use grub
Sep 24 23:50:50 <sgw> yeahm you can then dd the hddimg to a usb stick
Sep 24 23:50:55 <sgw> yes it uses grub
Sep 24 23:50:58 <sgw> IMAGE_FSTYPES ?= "ext3 cpio.gz live"
Sep 24 23:51:33 <khem> cool
Sep 24 23:51:47 <khem> sgw: let me try that out
Sep 24 23:52:11 <khem> sgw: do I need all three types for IMAGE_FSTYPES
Sep 24 23:52:15 <khem> or just live
Sep 24 23:53:01 <sgw> khem, honestly I am not sure about that, since it's a ?= not a += I think you need ext3 and live for sure, not sure about cpio.gz
Sep 24 23:53:45 <sgw> fray: I tried without the IMAGE_FEATURE set to see a "good" run and the exit code is 0, but with IMAGE_FEATURES += "dev-pkgs" it's 64!
Sep 24 23:53:53 <khem> ok no worries I will try the combo out
Sep 25 01:40:57 <kergoth> the new screen sspawning stuff is pretty nifty
Sep 25 02:30:05 <msm> kergoth: what's that
Sep 25 02:30:05 <msm> ?
Sep 25 02:42:22 <kergoth> msm: see "[bitbake-devel] [PATCH 0/4] Add ability to auto spawn screen on a controlling terminal"
Sep 25 02:42:32 <kergoth> avoids the need to open a new terminal and screen -r
Sep 25 02:42:38 <kergoth> spawns directly on the ui's tty
Sep 25 02:42:42 <kergoth> (if it's interactive)
Sep 25 02:43:03 <kergoth> the patchset's been floating around for weeks now i think, but richard merged it recently
**** ENDING LOGGING AT Tue Sep 25 02:59:58 2012

**** BEGIN LOGGING AT Tue Sep 25 02:59:58 2012
Sep 25 03:01:40 <kergoth> https://bitbucket.org/kergoth/dotfiles/changeset/761b1b5 - quite a hack, but i got sick of unsetting DISPLAY, and i like to leave X11 forwarding on. heh
Sep 25 03:26:17 <msm> ahh
Sep 25 03:29:10 <msm> kergoth: wasnt there another patch to use screen on the same display if possible?
Sep 25 03:29:15 <msm> that one sounded useful
Sep 25 03:29:34 <kergoth> not sure what you mean by that
Sep 25 03:29:45 <kergoth> if you mean the same terminal you're buliding on, that's what the above bitbake patch does
Sep 25 03:41:12 <nitink> khem: I think Darren did most of this live image work, I am learning still, if you have any specific questions let me know.
Sep 25 03:49:08 <msm> kergoth: yea, i thought there were some other ones that did that oo
Sep 25 03:49:09 <msm> too*
Sep 25 03:49:25 <msm> minus the DISPLAY bits
Sep 25 03:49:44 <kergoth> still don't know what you mean. the bitbake patchset has nothing to do with DISPLAY
Sep 25 03:49:55 <kergoth> the bitbucket uri is something else
Sep 25 04:26:42 <blloyd> I have a problem, not sure how to further isolate: when I bitbake linux-yocto with no sstate-cache or tmp directory, it builds as expected.  However, if after building an image I do 'bitbake -c cleansstate linux-yocto && bitbake linux-yocto'  I get an error building the kernel.  It keeps erroring until I nuke tmp and sstate directories.
Sep 25 04:28:30 <blloyd> any suggestions how to find why the build changes after an image is built?  (I'm trying to get a kernel to fully support a device, so was rebuilding kernel with changed config fragments, but have done it without changing config fragments to see if it was my changes doing it, and it still has broken)
Sep 25 05:06:06 <blloyd> should      KERNEL_FEATURES_append_qemux86="cfg/sound" have a space between the " and c?
Sep 25 07:35:47 <mckoan> good morning
Sep 25 07:40:04 <florian> good morning
Sep 25 07:48:32 <gizero> morning!
Sep 25 08:10:54 <bluelightning> morning all
Sep 25 11:02:06 <gotan> afternoon.
Sep 25 12:43:03 <gotan> @bluelightning - you aked about replicating the install kernel module problem in denzil - Tag this on the end of hello-mod
Sep 25 12:43:08 <gotan>  do_install_append() {        install -d ${D}${base_sbindir}/modules/       install -m 0644 ${S}/hello.ko ${D}${base_sbindir}/modules/ }
Sep 25 12:43:36 <gotan> It will generate the error i mentioned yesterday.
Sep 25 12:57:54 <bluelightning> gotan: but in that case is it the install command that's generating the error or what comes before it? i.e. this is an append; you mentioned previously that there were problems with "make install" which would be called as part of the default do_install
Sep 25 13:03:44 <gotan> @bluelightning - the problem i was ans still am having is that building my out of tree kernel module works, but is not being put into the image directory. I tried to use 'install' to copy the kernel moule into /sbin/modules, and it caused bitbake to fail, in package.class
Sep 25 13:04:25 <bluelightning> gotan: what is the actual failure?
Sep 25 13:04:28 <gotan> if i use 'cp' it works, so no i use that. The code snippet is one you can append to meta-skeleton/hello-mod the example module, and it will generate the error.
Sep 25 13:04:41 <gotan> s/no/now/
Sep 25 13:07:35 <bluelightning> gotan: I'm still not seeing where the failure is, can you pastebin the actual error you're getting in package.bbclass please?
Sep 25 13:09:32 <gotan> one sec.
Sep 25 13:12:22 <heeen> I am looking for more information on https://wiki.yoctoproject.org/wiki/OpenGL_pass-through_in_QEMU
Sep 25 13:12:32 <heeen> is this stuff available as patches somewhere
Sep 25 13:13:45 <bluelightning> heeen: it has been removed in master; you'll have to look back in the denzil branch for the patches under meta/recipes-devtools/qemu/
Sep 25 13:20:47 <gotan> @bluelightning - http://pastebin.com/UuE1q6vf
Sep 25 13:23:07 <heeen> why has it been removed
Sep 25 13:26:40 <bluelightning> heeen: we were lagging behind a long way with the version of qemu we could apply the patches to, and it was deemed too hard to forward-port the patches for the moment in contrast to the usefulness of the feature
Sep 25 13:38:21 <heeen> it wasn't really useful? how come
Sep 25 13:38:36 <heeen> and did QEMU change that much?
Sep 25 13:47:15 <jwessel> bluelightning: Thanks again for the HOB_MACHINE.   Works well enough now, that it has me wondering why parse_recipes takes so long. :-)
Sep 25 13:47:51 <bluelightning> jwessel: I think we'll be putting some focus on performance inprovements for 1.4
Sep 25 13:57:29 <JaMa> RP__: why are you using deprecated bb.mkdirhier in http://git.openembedded.org/bitbake/commit/?id=1270a07713e2a6c6e6fadcc61b785aebc99ae17b ?
Sep 25 14:00:06 <RP__> JaMa: hmm, bad RP__ ;-)
Sep 25 14:01:04 <JaMa> :)
Sep 25 14:03:37 <khem> gm all
Sep 25 14:03:52 <bluelightning> hi khem
Sep 25 14:06:02 <khem> heeen: we can certainly entertain those patches if ported forward and even better submitted upstream qemu
Sep 25 14:06:12 <khem> heeen: would you mind helping out ?
Sep 25 14:07:05 <heeen> I am looking into these gl in vm solutions
Sep 25 14:07:09 <heeen> like meego has
Sep 25 14:07:32 <heeen> we use oe-classic on virtualbox so far in our project
Sep 25 14:08:43 <heeen> khem, bluelightning is there a bug or review with those patches attached? or is picking them from some repository the easiest way?
Sep 25 14:12:27 <bluelightning> heeen: I think probably looking in the repository is the easiest way
Sep 25 14:14:29 <bluelightning> heeen: have a look at these, these were where the support was removed:
Sep 25 14:14:33 <bluelightning> heeen:  http://git.openembedded.org/openembedded-core/commit/?id=e9a6df98458d9147227659d3888eff01589f2f76
Sep 25 14:14:35 <bluelightning> heeen: http://git.openembedded.org/openembedded-core/commit/?id=30af78f0db16b9f51666341c9dad0123ccf8ac85
Sep 25 14:18:58 <heeen> thanks
Sep 25 14:19:10 <heeen> where is qemugl actually developed
Sep 25 14:20:24 <heeen> I'm finding references to meego, savannah
Sep 25 14:20:34 <heeen> yocto of course
Sep 25 14:24:35 <bluelightning> RP__: any ideas? ^
Sep 25 14:28:16 <heeen> http://www.mnementh.co.uk/home/projects/collabora/qemu-gl
Sep 25 14:28:17 <RP__> heeen: It was started by OpenedHand around 2007, we kept a version of the patch going, Meego also took them and made some changes which worked well for some things and less well for others.
Sep 25 14:28:23 <heeen> http://meego.gitorious.org/meego-developer-tools/meego-emulator-qemugl-x86
Sep 25 14:28:33 <rburton> tizen has a fork too iirc
Sep 25 14:28:46 <RP__> heeen: So many people have worked on it, there are several different versions, each with advantages and disadvantages. In the end it was hurting us too much to keep the patches around though
Sep 25 14:29:48 <RP__> heeen: I did try and get people to create one good version and also work with upstream qemu, you'll see some references on the mailing list but in the end we only got so far...
Sep 25 14:29:53 <heeen> and qemu was not interested in merging it upstream?
Sep 25 14:29:59 <heeen> as part of some driver or plugin
Sep 25 14:30:02 <heeen> ?
Sep 25 14:32:56 <heeen> currently we use virtualbox
Sep 25 14:33:21 <heeen> where we don't have any GL at all
Sep 25 14:33:48 <heeen> what would you suggest to get GLES for arm and/or GL for x86 virtual machines
Sep 25 14:34:07 <heeen> we build using oe-classic and soon with oe-core
Sep 25 14:35:29 <heeen> I tried to see if one could easily rebuild the vbox guest addons
Sep 25 14:46:00 <heeen> RP__: qemugl implements GLX? would GLES2 be more simpler to maintain?
Sep 25 14:46:32 <RP__> heeen: It was glx, yes. You'd need GLES2 on the systems you were running on
Sep 25 14:46:55 <RP__> heeen: the maintenance problem doesn't go away until something gets into upstream
Sep 25 14:46:57 <heeen> there are GLES to GLX mapping libs, though, right?
Sep 25 14:47:04 <heeen> true.
Sep 25 14:47:44 <RP__> heeen: the solution we had before only worked on x86
Sep 25 14:48:10 <RP__> heeen: making it work cross architecture would require some extra work to ensure the structures worked cross arch
Sep 25 14:48:45 <rburton> also, GLX is practically deprecated these days, so you'd really want qemu to emulate EGL too
Sep 25 14:50:11 <heeen> sigh
Sep 25 14:51:41 <rburton> as doesn't glx just give you big-GL and not gles?
Sep 25 14:53:01 <RP__> heeen: I don't like the position we're in but its a hard problem and its semi-tangential to what the Yocto Project is trying to achieve
Sep 25 14:53:32 <heeen> by the way can someone clarify the relationship between yocto and OE
Sep 25 14:53:33 <RP__> heeen: As khem said, if someone can point me at a set of decent patches for qemu with some plan to maintain them and help with bugs, I'd love to take them
Sep 25 14:54:06 <RP__> heeen: The Yocto Project includes many different projects. OpenEmbedded is the build architecture we've adopted
Sep 25 14:54:16 <RP__> heeen: together we work on OE-Core for example
Sep 25 14:54:34 <heeen> does this usually include the kernel
Sep 25 14:56:03 <RP__> heeen: we have a set of tools and patches we maintain against the kernel
Sep 25 14:56:16 <RP__> heeen: with an emphasis on getting things upstream
Sep 25 14:57:14 <heeen> RP__: what do you know of the virtualbox guest additions? I noticed our build already have the vboxadd kernel object, but not the video support. when I try to install the tools manually it tells me our kernel is too old
Sep 25 14:58:52 <RP__> heeen: I'd ask zeddii, I know there some recent improvements in that area
Sep 25 15:00:08 <Song_Liu> YPTM: Hi everyone, let's get started with the tech meeting. Please let me know who's on the bridge.
Sep 25 15:00:13 <rburton> RP__: fyi, daniels just landed glx passthrough for xephyr in virtualbox in a branch
Sep 25 15:00:15 <bogdanm> YPTM: i'm on the bridge
Sep 25 15:00:17 <bluelightning> YPTM: Paul Eggleton is on the call
Sep 25 15:00:31 <cristianiorga> Cristian Iorga, Intel Romania is on the call
Sep 25 15:00:38 <strassek> YPTM: Kevin Strasser is here
Sep 25 15:00:53 * sgw YPTM Saul is here
Sep 25 15:00:57 <fusman> YPTM: Fahad Usman from Mentor Graphics, Pakistan
Sep 25 15:00:59 <scottrif> YPTM Scott is here
Sep 25 15:01:28 <jzhang> YPTM: JZhang's here
Sep 25 15:01:33 <zeddii> YPTM: Bruce is one
Sep 25 15:01:34 <nitink> YPTM nitin is on the call
Sep 25 15:01:48 <denix> YPTM: Denys is here
Sep 25 15:02:10 <pidge> YPTM: Beth is dialing
Sep 25 15:02:28 * RP__ is here
Sep 25 15:02:28 <moolinex> YPTM: Mihai is here, also standing in for Laurentiu Serban
Sep 25 15:02:48 <kergoth> YPTM: chris larson here
Sep 25 15:02:59 <RP__> rburton: interesting
Sep 25 15:03:27 <dvhart> YPTM: Darren has joined
Sep 25 15:03:39 <adamian> alex
Sep 25 15:04:50 <RP__> Song_Liu: I am here, I guess I didn't use the prefix above...
Sep 25 15:05:10 <Song_Liu> YPTM: Any opens, anyone?
Sep 25 15:06:17 <Song_Liu> YPTM: https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.3_Status#Milestone_4
Sep 25 15:06:51 <nitink> Song_Liu: open: considering yoctoproject in emgd release POR process
Sep 25 15:06:56 <rburton> YPTM: ross burton joined
Sep 25 15:06:58 <evadeflow> Dave Wolfe here (in case the anagram isn't obvious :-))
Sep 25 15:07:14 <dvhart> YPTM: can we add the relevant links to the invitation?
Sep 25 15:17:05 <rburton> RP: 12.10 surely
Sep 25 15:18:45 <RP> rburton: er, yes
Sep 25 15:19:40 <rburton> hooray voip!
Sep 25 15:19:49 <scottrif> song - ok
Sep 25 15:19:54 <scottrif> probably my phone
Sep 25 15:20:04 <RP> scottrif: you sound like some kind of robot
Sep 25 15:20:11 <scottrif> I will type my response here....
Sep 25 15:20:27 <scottrif> Docs - I am working on verifying examples at the moment
Sep 25 15:20:46 <scottrif> Nobody sees this?
Sep 25 15:20:51 <zeddii> we see it.
Sep 25 15:20:54 <sgw> yes, we see it
Sep 25 15:21:04 <scottrif> I am going to recall in on the hard line
Sep 25 15:22:26 <evadeflow> Is that 85 minutes for core-image-sato?
Sep 25 15:22:29 <scottrif> rejoined on hard line
Sep 25 15:23:13 <Song_Liu> YPTM: scottrif: do you have any concerns regarding docs for M4?
Sep 25 15:23:31 <otavio> sgw: did you see the cogl patch?
Sep 25 15:24:23 <scottrif> Song_Liu: come back to me on audio.  you should be able to understand me now.
Sep 25 15:25:35 <sgw> http://packages,yoctoproject.org
Sep 25 15:28:34 <sgw> otavio: yes, I saw it. It's queued
Sep 25 15:28:45 <otavio> sgw: ok; good
Sep 25 15:28:57 <otavio> sgw: this could be add to denzil next as well
Sep 25 15:29:39 <sgw> otavio: I know you looked into the udev 182 update, I have been testing with that patch and found the keyboard and mouse go away, so we are holding off at this late point in the release.
Sep 25 15:30:00 <otavio> sgw: Right; I agree.
Sep 25 15:30:13 <otavio> sgw: it is too late in release for it.
Sep 25 15:30:40 <otavio> sgw: but I also fail to see why it break the mouse and kbd
Sep 25 15:30:47 <RP> I'm afraid the weather in Newcastle is interfering with the phone systems
Sep 25 15:31:11 * RP suspects there is a large electrical storm heading this way
Sep 25 15:31:53 * otavio is going to have lunch ... bbl
Sep 25 15:33:07 <sgw> nitink: Did you ever build the meta-toolchain targets for x32?
Sep 25 15:34:22 <adamian> otavio: the udev not loading -> does not create entries in /dev for kbd and mouse (minimal entries are pre-built-in), so it a signal that udev doesn't load
Sep 25 15:34:58 <davest1> YPTM: davest is in the house
Sep 25 15:35:32 <otavio> adamian: right; that would explain it
Sep 25 15:35:52 <nitink> sgw: asnwered it on the call
Sep 25 15:35:56 <otavio> sgw: if you want, point me to the last version of patch and I see if I can fix it fast.
Sep 25 15:36:27 <sgw> otavio: it's the v4 version on the OE-Core list
Sep 25 15:38:54 <sgw> pidge: I think meta-toolchain may be the right place to start for x32, I am building it locally
Sep 25 15:39:58 <rburton> gotta drop
Sep 25 15:43:44 <msm> hmm, routerstationpro gcc-cross seems to not be building on my old CentOS distro
Sep 25 15:44:29 <kergoth> what's the link to this user contributed git repository stuff?
Sep 25 15:47:00 <moolinex> kergoth: the git repo is at git://git.yoctoproject.org/poky-contrib
Sep 25 15:47:48 <dvhart> no, that's not user contrib
Sep 25 15:47:49 <dvhart> one sec:
Sep 25 15:47:50 <kergoth> no, i'm familiar with poky-contrib, i'm talkingg about what was brought up on the yptm
Sep 25 15:48:08 <dvhart> http://git.yoctoproject.org/cgit.cgi/user-contrib/dvhart/
Sep 25 15:48:13 <dvhart> kergoth, ^
Sep 25 15:48:20 <dvhart> for example
Sep 25 15:48:59 <sgw> thanks Song_Liu
Sep 25 15:49:06 <halstead> kergoth, It's very basic right now https://wiki.yoctoproject.org/wiki/User-contrib
Sep 25 15:49:08 <moolinex> YPTM: thanks, bye
Sep 25 15:49:18 <Song_Liu> YPTM: thanks everyone for joining the meeting. Have a nice day/evening
Sep 25 15:49:59 <kergoth> halstead: k, thanks
Sep 25 15:51:19 <msm> bluelightning: did you ever publish a lamp layer?
Sep 25 15:54:51 <bluelightning> msm: not quite yet but should be able to any day now... actually I will just follow that up
Sep 25 15:57:19 <msm> k, just checking
Sep 25 15:57:49 <msm> bluelightning: was it going to have apache?
Sep 25 15:58:01 <bluelightning> msm: yes, and PHP
Sep 25 15:58:07 <bluelightning> well, mod-php
Sep 25 15:58:26 <msm> cool
Sep 25 16:38:40 <ag_> Anybody cand help me with a hint how to get the kernel version in a recipe which builds and installs a kernel module?
Sep 25 17:06:46 <khem> bluelightning: for lamp layer hrw was working on something smae
Sep 25 17:06:48 <khem> same
Sep 25 17:07:50 <bluelightning> khem: last I heard he used lighttpd + php-cgi in meta-oe instead of apache
Sep 25 17:08:09 <khem> see http://git.linaro.org/gitweb?p=openembedded/meta-linaro.git;a=tree
Sep 25 17:08:28 <khem> ok
Sep 25 17:08:50 <khem> I think having all of these webserver things in one layer would be better
Sep 25 17:09:02 <khem> meta-webserver something
Sep 25 17:09:15 <khem> or do we specifically want meta-lamp
Sep 25 17:09:33 <khem> well LAMP is widely known term so having meta-lamp would make sense I guess
Sep 25 17:12:36 <fray> khem did you figure out what part of the patch fixed your rename issue(s)?
Sep 25 17:12:49 <khem> fray: nope
Sep 25 17:12:53 <fray> ok
Sep 25 17:12:58 <khem> fray: too much to churn atm
Sep 25 17:13:07 <fray> Yup, I understand..
Sep 25 17:13:13 <khem> I am in midst of creating a system that should work this week
Sep 25 17:13:16 <fray> I have the cross-canadian supporting multilib builds now..
Sep 25 17:13:19 <khem> and have multilib
Sep 25 17:13:29 <fray> I'm going to forward port my patch to master.... verify and send it for comment..
Sep 25 17:13:29 <khem> thats cool
Sep 25 17:13:44 <khem> sure I will definitely give a keen loo
Sep 25 17:13:45 <khem> k
Sep 25 17:13:49 <fray> (note this doesn't fix the compiler or anything.. but it allows the infrastructure to work, which solves some of the problems I've had)
Sep 25 17:14:02 <khem> ok
Sep 25 17:14:18 <fray> since we have a binary toolchain, I just had to get it cycling correctly
Sep 25 17:14:31 <khem> hmm
Sep 25 17:15:05 <fray> also we have a cross-canadian toolchain-wrapper..  thats something that we might want to consider (post 1.3) for the SDK work..
Sep 25 17:15:05 <khem> wow thunderbird has IRC plugin too
Sep 25 17:15:13 <khem> did nt know that
Sep 25 17:15:23 <fray> the problem w/ calling ${CC} is that many things break that up.. or expect to call '${CC}' which fails..
Sep 25 17:15:53 <fray> but if the wrapper handles the nasty bits of options and --sysroot=, then ${CC} can just be a single binary no options necessary to build hello
Sep 25 17:16:05 <khem> hmmm
Sep 25 17:16:11 <khem> I am skeptical
Sep 25 17:16:14 <fray> makes the SDK infinitely more user friendly
Sep 25 17:16:20 <khem> its something like klcc
Sep 25 17:16:30 <thiagoss> _julian_, I got gstreamer-1.0 recipes in https://github.com/thiagoss/poky, but I'm still unable to test completely as I couldn't get pulseaudio to run on the raspberry yet
Sep 25 17:16:31 <kergoth> DISTRO = "poky"
Sep 25 17:16:32 <kergoth> DISTRO_NAME = "Yocto (Built by Poky 7.0)"
Sep 25 17:16:33 <khem> can env script do that
Sep 25 17:16:38 <kergoth> this confuses me. is the distro yocto or poky?
Sep 25 17:16:46 <kergoth> it's poky.conf, and DISTRO is poky, yet the distro name is yocto?
Sep 25 17:16:56 <fray> when the wrapper is built, it knows the required options and where it is on the disk.. and then it just passes whatever it was called, with the built in options, to the real compiler
Sep 25 17:16:58 <dvhart> kergoth, huh...
Sep 25 17:17:14 <fray> huh?
Sep 25 17:17:23 <fray> the reference distribution for the Yocto Project is poky..
Sep 25 17:17:28 <fray> if it says 'yocto' somewhere that is a bug..
Sep 25 17:17:31 <kergoth> thats what i thought, so DISTRO_NAME is wrong
Sep 25 17:17:32 <fray> there is a meta-yocto layer though
Sep 25 17:17:33 <kergoth> okay, thanks
Sep 25 17:17:42 <fray> file a bug
Sep 25 17:17:42 <kergoth> this is poky.conf in meta-yocto, yes
Sep 25 17:17:44 <kergoth> k
Sep 25 17:17:44 <fray> (or fix it)
Sep 25 17:17:48 <khem> I feel we should drop using poky
Sep 25 17:18:00 <khem> its causing more confusion than what exists
Sep 25 17:18:02 <dvhart> khem, me too
Sep 25 17:18:05 <fray> I have no objection to 'poky' when it refers to ther eference distribution
Sep 25 17:18:18 <fray> thats how I spin it in the presentations I make to newbies
Sep 25 17:18:22 <kergoth> yeah, i dont mind it being the distro, but everywhere else..
Sep 25 17:18:24 <khem> folks here were utterly confused when I gave them yocto SDK with poky in it
Sep 25 17:18:33 <khem> and everyone was asking now what is poky
Sep 25 17:18:36 <khem> wherre is yocto
Sep 25 17:18:37 <fray> I also mention Angstrom and others have a similar format (and compatibility) but use their own distribution confgiuration
Sep 25 17:18:54 <khem> are they some divorced couple or just estranged
Sep 25 17:19:24 <fray> Yocto Project can be compatible with -other- distributions, Poky is just the reference.. (i get and answer that question at conferences)
Sep 25 17:19:45 <fray> WR Linux is a 'distribution', we don't use 'poky'..
Sep 25 17:19:57 <khem> fray: if you pull out poky whats left
Sep 25 17:20:05 <fray> we don't remove it
Sep 25 17:20:11 <fray> if the user wants to use Poky they can..
Sep 25 17:20:17 <fray> but we supply the wrlinux.conf  configurationf ile
Sep 25 17:20:30 <fray> (in our own wrlinux layer)
Sep 25 17:20:48 <fray> any meta-yocto actually contains three distros.. poky, poky-lsb and poky-tiny
Sep 25 17:21:06 <khem> I think they act as nice references
Sep 25 17:21:12 <fray> yes they do
Sep 25 17:21:12 <khem> but somehow name confuses
Sep 25 17:21:18 <rob_w_> wow i  was just about to ask that thing
Sep 25 17:21:27 <kergoth> mentor embedded linux is poky based as well. mel.conf requires poky.conf
Sep 25 17:21:46 <fray> we don't require or use poky.conf in any way..  (but we did start with that to create the wrlinux.conf)
Sep 25 17:32:40 <sgw> fray: I have had no luck chasing down that silent failure from RPM with multilib, I did confirm it does not happen with standard build (non-multilib) with IMAGE_FEATURES, I also confirmed that in the "bad" case the exit code is the package installed count but in the good case exit code is 0
Sep 25 17:33:50 <fray> ok.. I'm working on a couple of presentations right now (and the multilib problem for cross-canadian) if I get through that, I'll try to reproduce what you are seeing.. are your reproducer steps in the bug?
Sep 25 17:34:13 <sgw> Yup should be I will double check
Sep 25 17:34:53 <sgw> fray: yes the info is in there.
Sep 25 17:35:05 <fray> ok..  I'll try to get to it
Sep 25 18:04:13 <msm> kergoth: do you build routerstationpro (or mips?) on your centos 5.x box?
Sep 25 18:09:46 <khem> has anyone tried embedding two images into one ?
Sep 25 18:09:49 <khem> using yocto
Sep 25 18:10:19 <khem> e.g. one is sort of firmware generated by yocto itself and other one is larger image with contains this firmware too
Sep 25 18:11:53 <khem> msm: there is centos 6.x now a days :)
Sep 25 18:12:00 <khem> msm: get rid of 5.x
Sep 25 18:12:34 <fray> khem, we still have customers on 5.x.. (and a few that have asked about 4.6)  :P
Sep 25 18:14:15 <khem> ugh
Sep 25 18:14:56 <kergoth> msm: we build a couple mips machines, but mostly 64 bit. never built routerstationpro
Sep 25 18:15:00 <kergoth> have built qemumips also of course
Sep 25 18:15:03 <khem> you should say we charge N/(Centos version) in terms of money :)
Sep 25 18:15:39 <khem> kergoth, fray any experience generating multi images
Sep 25 18:15:40 <kergoth> nice thing about building on centos5, the native/cross binaries run pretty much everywhere, making the produced sstates very useful
Sep 25 18:15:46 <kergoth> khem: nope, sorry
Sep 25 18:16:10 <fray> Not a lot recently.. mostly it's just IMAGE_INSTALL_append = "something additional I need"
Sep 25 18:16:10 <khem> kergoth: I agree on sstate part
Sep 25 18:16:20 <khem> hmm ok
Sep 25 18:16:23 <kergoth> wuld be nice if we could use the lsb tools or something for that..
Sep 25 18:16:24 <kergoth> heh
Sep 25 18:16:29 <fray> pretty common to specify either 'eglibc' or 'mysql' or something like that
Sep 25 18:16:43 <fray> package groups work well for some of the multilib stuff..
Sep 25 18:17:02 <khem> fray: I was thinking of generating say an arm image and then bundling it into an x86 image
Sep 25 18:17:14 <fray> ohh ...  no I've not done that
Sep 25 18:17:14 <khem> :)
Sep 25 18:17:30 <msm> yea, im staying with 5.x if i can
Sep 25 18:17:32 <kergoth> khem: shouldn't be too hard to pull off, just make use of some depends flags
Sep 25 18:17:33 <khem> and I dont think we can drive that kind of builds
Sep 25 18:17:43 <fray> what I'd suspect is needed is a multi-machine build (which at least used to work), and then a special deployment that copies one to the other
Sep 25 18:17:46 <kergoth> khem: we use a recipe for our release of our product that builds an image, archives it up with the layers, etc
Sep 25 18:17:55 <fray> (or packages the image of one, and deploys in the other...)
Sep 25 18:17:56 <kergoth> oh, different machine, right..
Sep 25 18:18:06 <kergoth> yeah, fray's right, ic an't think of anything else that'd work
Sep 25 18:18:23 <msm> khem: i've done something like this: http://fpaste.org/OUyw/
Sep 25 18:18:36 <fray> you SHOULD be able to do that..  I thought about that a while back with some of the ATCA chasis w/ (different) cpu coprocessor cards
Sep 25 18:18:46 <fray> but I've never had to do it..
Sep 25 18:19:05 <kergoth>  i'm thinking someone broke knotty - https://gist.github.com/3783539
Sep 25 18:19:10 <kergoth> heh
Sep 25 18:19:37 <kergoth> not seeing that everywhere though
Sep 25 18:20:12 <khem> msm: thats same arch image right
Sep 25 18:20:33 <fray> I've seen that once before.. we chalked it up to a UFO
Sep 25 18:20:38 <fray> we could never reproduce it to debug it
Sep 25 18:20:59 <fray> if you can actually reproduce it, please do so.. I'd love to know what happened..
Sep 25 18:21:00 <kergoth> hmm
Sep 25 18:21:07 <khem> fray: how to go about mutli machine
Sep 25 18:21:07 <fray> (we saw it last about 30-45 days ago)
Sep 25 18:21:20 <khem> are there examples
Sep 25 18:21:26 <fray> first see if it's even possible.. can you even build two machines at once?
Sep 25 18:21:35 <khem> fray: I dont think we can
Sep 25 18:21:37 <khem> as of now
Sep 25 18:21:42 <fray> it USED to work.. you just did a space separated list in MACHINE=
Sep 25 18:21:50 <kergoth> multimachine builds still work great in a single tmpdir, but at once i doubt
Sep 25 18:21:54 <fray> (and if it didn't used to work, my memory is even fuzzier then I though)
Sep 25 18:22:14 <fray> may have been that I iterated a multimachine build..
Sep 25 18:22:26 <fray> (cause you can set MACHINE on the CLI)
Sep 25 18:22:45 <khem> fray: thats normal
Sep 25 18:23:06 <khem> fray: I was thinking MACHINE=a bitbake myimage
Sep 25 18:23:19 <khem> and now myimage could invoke build of another image
Sep 25 18:23:25 <khem> which is build for machine b
Sep 25 18:23:39 <khem> through deps
Sep 25 18:23:47 <fray> your 'myimage' (or your machine conf) should have somethign that deposits the image somewhere that MACHINE=b 's image recipe knows about..
Sep 25 18:23:52 <fray> then it can copy/package/etc the results of 'a
Sep 25 18:24:04 <fray> (or error and tell you to build 'a' first) ;)
Sep 25 18:24:17 <khem> fray: yeah its going to be sequential
Sep 25 18:24:19 <khem> thats the point
Sep 25 18:25:03 <fray> Uhh oh
Sep 25 18:25:05 <fray> ERROR: Fetcher failure: Fetch command failed with exit code 129, output:
Sep 25 18:25:05 <fray> error: option `mirror' takes no value
Sep 25 18:25:05 <fray> usage: git remote add [<options>] <name> <url>
Sep 25 18:25:05 <fray>     -f, --fetch           fetch the remote branches
Sep 25 18:25:05 <fray>     --tags                import all tags and associated objects when fetching
Sep 25 18:25:05 <fray>                           or do not fetch any tag at all (--no-tags)
Sep 25 18:25:06 <fray>     -t, --track <branch>  branch(es) to track
Sep 25 18:25:06 <fray>     -m, --master <branch>
Sep 25 18:25:07 <fray>                           master branch
Sep 25 18:25:07 <fray>     --mirror              no separate remotes
Sep 25 18:25:20 <fray> did the git version check fail ro something?
Sep 25 18:25:54 <fray> it did -not- build me a local copy of git..
Sep 25 18:26:06 <msm> khem: same arch
Sep 25 18:26:20 <khem> msm: yeh thats doable
Sep 25 18:27:15 <khem> I guess I have to treat it as a bin blob that fetched using a recipe
Sep 25 18:27:40 <khem> and then have mechanics to invoke bitbake in sequence
Sep 25 18:28:02 <fray> thats exactly what I think you'll need..
Sep 25 18:28:18 <khem> thats fine though
Sep 25 18:28:26 <fray> ok.. to 1.7.3.4 (git) doesn't work, but the 'git-replacement-native' 1.7.7 works..
Sep 25 18:28:26 <khem> this is just image generation issue
Sep 25 18:28:27 <fray> whee
Sep 25 18:28:39 <khem> it all doesnt have to build all at once
Sep 25 18:29:10 <fray> # Need git >= 1.7.5 for git-remote --mirror=xxx syntax
Sep 25 18:29:10 <fray> version_compare $GITVERSION ">=" 1.7.5 && needgit="0"
Sep 25 18:29:17 <fray> hmm.. that should work.. whyd idn't it
Sep 25 18:34:49 <khem> fray: whats your host
Sep 25 18:35:03 <khem> sometimes package needs that git-native to build first
Sep 25 18:36:21 <kergoth> khem: the bitbake wrapper automatically builds git-replacement-native if git is old.. thats what *should* happen, anyway.. one would hope nothing needed to build git-replacement-native fetches from git :)
Sep 25 18:36:40 <khem> yeah heh
Sep 25 18:36:52 <khem> time for some free yahoo food today
Sep 25 18:36:55 <khem> bbl
Sep 25 18:37:08 <fray> the one I'm curently using is an old FC13..
Sep 25 18:37:19 <fray> (intentionally using an old host.. I fina  lot of bugs this way)
Sep 25 18:37:49 <fray> when my build is over, I'm going to check and see what it thoguht it was doing
Sep 25 18:38:05 <fray> manually building the replacement worked BTW
Sep 25 18:39:30 <fray> python -c "from distutils.version import LooseVersion; import sys; sys.exit(not (LooseVersion('1.7.3.4') >= LooseVersion('1.7.5')))" ; echo $?
Sep 25 18:39:31 <fray> 1
Sep 25 18:39:33 <fray> ya thats all right
Sep 25 18:40:51 <fray> ohh I think I know what happened!
Sep 25 18:41:04 <fray> I started the build, something was configured wrong.. and I killed the build (during hte initial stage)
Sep 25 18:41:41 <fray> I then fixed the config, and restarted the build.. the system finished the initial stage, but never build git-replacement-native... there is a check that if the pseudo stuff has been build, we don't rebuild git-native... even though it wasn't built before.. :P
Sep 25 19:02:46 <fray> khem?
Sep 25 19:03:39 <kergoth> fray: ah, guess it should only create the pseudo stamp after all the builds are succesfully completed for the prep stuff
Sep 25 19:03:42 <kergoth> heh
Sep 25 19:03:46 <kergoth> kind of surprised it doesnt do that already
Sep 25 19:03:53 <fray> ya.. it appears to just create them after the end of the build.. :P
Sep 25 19:04:04 <fray> it then checks the stamp, finds it's invalida and rebuilds pseudo, but not tar/git
Sep 25 19:04:23 <kergoth> ah
Sep 25 19:34:33 <sgw> Anyone else seeing gcc fail to patch correctly, I saw it yesterday, and it's back again today. Seems to be related to work-shared, RP thought it might be stamps related
Sep 25 19:37:23 <fray> if it attempts to 'repatch' it'll fail.. cleansstate is the only fix I've found
Sep 25 19:37:36 <fray> but I thought RP and someone else were working on fixing it.. maybe not?
Sep 25 21:28:34 <RP> sgw: have you looked at the stamps directory?
Sep 25 21:28:41 <RP> sgw: see what is amiss?
Sep 25 21:39:28 <sgw> RP: I looked, the problem was the offending stamp was empty!
Sep 25 21:39:48 <RP> sgw: empty?
Sep 25 21:39:59 <RP> sgw: all stamp files are empty
Sep 25 21:40:32 <sgw> no just the one task that was failing, I guess you write it when it's complete, which would make sense
Sep 25 21:41:00 <sgw> I ended up doing a cleansstate, I needed to get the build appliance built out
Sep 25 21:41:23 <RP> sgw: it doesn't make any sense
Sep 25 21:47:11 <sgw> RP: sorry had a call, I wish it made more sense and I could reproduce it more consistently.
Sep 25 22:18:47 <msm> does immediate expansion with with variables not yet created?
Sep 25 22:21:48 <kergoth> msm: it'll behave the way expansion always does
Sep 25 22:22:00 <kergoth> if a variable is referenced that's undefined, the ${} is left unexpanded
Sep 25 22:22:23 <kergoth> so that variable would be left unexpanded, and could be expanded later at getVar time, presumably
Sep 25 22:22:44 <kergoth> i really dislike this behavior, incidentally. it should just error on expansion of a var that isnt defined -- it's not that hard to define defaults
Sep 25 22:22:51 <kergoth> would catch some bugs, i bet
Sep 25 22:22:53 <kergoth> heh
Sep 25 22:22:55 <bluelightning> kergoth: interesting, I had not appreciated that aspect of unexpanded variable behaviour...
Sep 25 22:23:19 <kergoth> iirc originally it was that way to let the shell expand it, since there was no way to escape a ${}
Sep 25 22:23:34 <kergoth> but that just makes the parse time vs shell time expansion even more confusing tha ti talready is :)
Sep 25 22:23:47 <bluelightning> I was about to suggest warning on unexpanded variables but the shell issue would make that difficult
Sep 25 22:23:56 <bluelightning> or impractical, to be precise
Sep 25 22:24:14 <kergoth> 90% of the time $foo works, but if the shell var has odd chars in it, or the like..
Sep 25 22:24:21 <msm> kergoth: thanks for the extra info
Sep 25 22:24:22 <bluelightning> indeed
Sep 25 22:24:28 <kergoth> course, we could add the ability to escape it. \${foo}
Sep 25 22:24:36 <kergoth> then add the expansion error later down the road
Sep 25 22:24:49 <kergoth> msm: np
Sep 25 22:25:13 <bluelightning> someone asked me just today if there was a way to escape references like that (for the purposes of modifying a conf file from a python function)
Sep 25 22:25:52 <bluelightning> the workaround was to split the string i.e. '$' + '{VARNAME}'
Sep 25 22:25:55 <kergoth> just the other day i got bit by this in our 'release' recipe. was emitting a ${} bit into a .conf for later use, ended up using printf to assemble the reference piecemeal :)
Sep 25 22:26:00 * kergoth nods
Sep 25 22:26:22 <bluelightning> something we might want to look at handling in future perhaps
Sep 25 22:32:07 <kergoth> expansion is just a regex atm, could presumably just use a simple lookbehind assertion, as long as we check for potential performance impact
**** ENDING LOGGING AT Wed Sep 26 02:59:58 2012

**** BEGIN LOGGING AT Wed Sep 26 02:59:58 2012
Sep 26 08:00:36 <gotan> morning.  any idea where i can fix this? libopts.so.25()(64bit) - i'm having trouble with an autoopts application.
Sep 26 08:04:54 <RP> morning all
Sep 26 08:05:21 <gizero> morning!
Sep 26 08:14:54 <gotan> I'm building a package, it uses autoopts (part of autogen), so i need to have auto-gen native in the rependencies, but now during image creation it is looking for libopts.so.25()(64bit) which would seem to be built only for the host not the target having a -native name
Sep 26 08:23:23 <bluelightning> morning all
Sep 26 08:27:34 <JaMa> hmm FetchError: Fetcher failure for URL: 'https://eula-downloads.yoctoproject.org/index.php'. URL https://eula-downloads.yoctoproject.org/index.php doesn't work
Sep 26 08:28:11 <JaMa> and network sanity test fails, but wget works, any idea? except it's too slow and fetcher timeouts while wget has longer timeout limit?
Sep 26 08:28:36 <JaMa> real    0m7.507s
Sep 26 08:28:38 <JaMa> is a bit long
Sep 26 08:28:50 <bluelightning> hmm, downloads a lot quicker here...
Sep 26 08:30:11 <JaMa> my connection is slower for sure, but it was good enough for sanity check until today
Sep 26 08:30:29 <bluelightning> hmm, could just be a temporary server load issue
Sep 26 08:30:41 <bluelightning> or is it still slow if you try it now?
Sep 26 08:30:46 <bluelightning> here I get: real    0m1.438s
Sep 26 08:31:41 <JaMa> yup tried 10 times already or so
Sep 26 08:31:55 * JaMa disabled sanity check already
Sep 26 08:32:39 <bluelightning> I'm not really sure what we can do; I think the server is functioning OK
Sep 26 08:32:58 <bluelightning> and we have to have some form of test so people find out sooner that their proxy settings are incorrect
Sep 26 08:35:26 <JaMa> no problem, just wanted to check if it works fast for you..
Sep 26 08:47:17 <jackmitchell> bluelightning: re: meta-lamp, I think it should be meta-webserver (I also thought meta-web but that implies client side material also so it's not quite right). meta-lamp implies (to me anyway) that it will contain Apache, mySQL and PHP - which from what I've gathered you are aiming for a much more generic layer?
Sep 26 08:47:39 <bluelightning> jackmitchell: yep, I'm planning on calling it meta-webserver :)
Sep 26 08:48:14 <jackmitchell> bluelightning: ah, good - no need for me to stick my horn in then ;)
Sep 26 08:48:38 <bluelightning> jackmitchell: I was going to post the patches to add the layer under meta-openembedded last night
Sep 26 08:48:58 <bluelightning> unfortunately I found at the last minute that modphp can't build on ARM (and probably other platforms) because a native include path is being injected into CFLAGS
Sep 26 08:49:55 <bluelightning> in fact I'm not sure how it could have worked when building on x86-64 for x86 either... still, it just needs to be fixed, hopefully I can get to that today
Sep 26 08:50:28 <jackmitchell> bluelightning: sounds good, I hope to be able to make a contribution or two in the future as I am (planning) on using a few web technologies in a commercial enviornment
Sep 26 08:50:43 <bluelightning> jackmitchell: that would be great!
Sep 26 08:51:19 <jackmitchell> bluelightning: I'd love to bring PHP up to scratch, but man, that is one wieldy program
Sep 26 08:51:44 <bluelightning> yeah... just getting building apache to build correctly has been a bit of a pain
Sep 26 08:52:31 <jackmitchell> bluelightning: I have a webserver build which is a bit more suited to lower power and constrained systems almost ready to go, so that can be my first foray
Sep 26 08:52:48 <jackmitchell> he recently chaned to cmake though which has made it a bit more of a pain in the neck
Sep 26 09:43:49 <gotan> hi again - this is gettnig a bit painful - can anyone point to a working example that uses autoopts?
Sep 26 09:53:32 <hrw> hello
Sep 26 09:54:35 <ag_> cheers
Sep 26 14:13:51 <gotan> hi - what is the best practice for deling with a tarball that has a native and non native part and is glommed together by configure?
Sep 26 14:14:55 <bluelightning> gotan: usually we try to build native and target versions of the recipe and make the latter depend upon the former
Sep 26 14:15:03 <bluelightning> qt being one example
Sep 26 14:18:14 <gotan> @BL - reason i ask - I've been trouble with autogen - it only comes out of the box in native form, but it has a libopts component, which needs to be non-native.
Sep 26 14:19:19 <bluelightning> gotan: ah ok... I did check, I don't see many things depending on autogen-native (only grub-efi-*) so I can only assume it's not a common case
Sep 26 14:25:35 <gotan> @bluelightning: i have a package that requires libopts, which seems to require me to configure and build autogen for the target before i can build libopts. Does this native-local dependency approach help here? which depends on which - non natve - native?
Sep 26 14:28:08 <gotan> @bluelightning: FWIW I've searched as many recpies, and performed a "find build/tmp -name *.[ch] -print0 | xargs -0 grep -inH autoopts" but found nothing that needs autoopts that i can use for reference.
Sep 26 14:33:45 <RP> gotan: You probably need to add an autoopts recipe which just builds the autoopts piece (and can depend on autogen-native)
Sep 26 14:36:35 <gotan> now do you un-native then? because by then it will have incldued the native class
Sep 26 14:36:43 <gotan> @bluelightning:now do you un-native then? because by then it will have incldued the native class
Sep 26 14:37:15 <bluelightning> gotan: you'd need to create a new recipe
Sep 26 14:37:43 <bluelightning> gotan: possibly based on the autogen-native recipe but modified to just build autoopts
Sep 26 14:48:49 <gotan> @bluelightning  - which is what i am working on. but it seems i cannot build autoopts on its own - or at least cannot configure it on its own.
Sep 26 14:49:54 <bluelightning> gotan: I'm not sure, you may have to hack the configure script... it should be able to depend on autogen-native for the native parts it needs
Sep 26 15:02:50 <gotan> @bluelightning -  ouch - configure my enemy of old. Its now complaining that there is no libregex, which interestingly i cannot find  a recipe for.
Sep 26 15:03:38 <bluelightning> hmm, I'm not familiar with libregex...
Sep 26 15:11:42 <gotan> @bluelightning: as an aside, is there a single place where a guy can search for recipes other than using local git clones and googlefoo such as for example "allinurl:guile filetype:bb"
Sep 26 15:12:15 <bluelightning> gotan: the only central place we have is the layer index: http://www.openembedded.org/wiki/LayerIndex
Sep 26 15:12:53 <bluelightning> gotan: at some point in the near future I'd like to set up a web-based searchable index that goes down to the recipe level, but so far nobody has had a chance to write a web app to make that possible
Sep 26 15:21:24 <gotan> @bluelightning: FWIW "A POSIX compliant regcomp/regexec routine is required... configure: error: Cannot find working POSIX regex library" is there an alternative?
Sep 26 15:22:20 <bluelightning> gotan: I'm not sure, a cursory search suggests pcre is capable of being POSIX compliant
Sep 26 15:22:24 <bluelightning> though
Sep 26 15:25:05 <otavio> perl native seems broken: Can't locate XML/Simple.pm in @INC (@INC contains: /etc/perl
Sep 26 15:25:13 <otavio> ...
Sep 26 15:25:21 <otavio> but no sysroot dir in @INC
Sep 26 15:26:01 <otavio> Easy to reproduce; remove libxml-simple-perl from host and try to build sato-icon-theme
Sep 26 15:31:39 <gotan> @bluelightning tracking down what the autotools-native uses, but its not in the dependecies.
Sep 26 15:50:05 <gotan> @bluelightning - is there a mechanism to find the source directory of another recipe?
Sep 26 15:51:09 <bluelightning> gotan: if you mean from one recipe to another, no - if you need to borrow files in that way they need to be staged - that happens mostly automatically after installing them in do_install
Sep 26 15:55:43 <gotan> @bluelightning: there is only the kernel staging variable mentioned in the docs  -  there are two others mentioned in passing, ( STAGING_DIR_HOST STAGING_DIR_TARGET) are they usable? turns out autogen-native creates a libopts tarball
Sep 26 16:02:40 <gotan> @bluelightning- or even better copying it to the downloads directory?
Sep 26 16:04:54 <bluelightning> gotan: is that tarball actually needed though or is it simply derived from the autogen sources?
Sep 26 16:06:52 <gotan> @bluelightning - as far as i can tell - the tarball is generated by the autoopts sub-package - it seems to be the source for the libopts i need for the package i should be working on.
Sep 26 16:07:23 <bluelightning> that's an extremely unusual way to do things...
Sep 26 16:08:01 <gotan> @bluelightning- from the readme "        THIS TARBALL IS NOT A FULL DISTRIBUTION.  The contents of this tarball is designed to be incorporated into software packages that utilize the AutoOpts option automation package and are intended to be installed on systems that may not have libopts installed.  It is redistributable under the terms of either the LGPL (see COPYING.lgpl) or under the terms of the advertising clause free BSD license (
Sep 26 16:09:20 <gotan> @bluelightning: so its built inside autogen. So i;m hoping all i need to do is copy it to DL_DIR in a do_install_append, and create a libopts.bb recipe
Sep 26 16:10:05 <gotan> @bluelightning: assuming DL_DIR is globally set.
Sep 26 16:10:35 <bluelightning> it is... I feel a little bit uncomfortable about the idea of putting stuff into DL_DIR anywhere outside of do_fetch though
Sep 26 16:13:57 <gotan> @bluelightning: even more fun, its supposed to be embedded in your project directory and built alongside your project, so i guess i can just include is as a patch in the SRC_URI
Sep 26 16:14:06 <fray> khem ?
Sep 26 16:15:41 <bluelightning> gotan: my gut tells me it ought to be
Sep 26 16:15:44 <bluelightning> argh
Sep 26 16:15:54 <bluelightning> staged, was what I meant to say
Sep 26 16:20:20 <gotan> @bluelightning: i preferred argh,
Sep 26 16:21:10 <bluelightning> gotan: my muscle memory still has trouble with the difference in the size of the enter key between US and UK keyboards, so my sentences occasionally get cut off on IRC :)
Sep 26 16:24:39 <gotan> @bluelightning - yeh i get that too - only US boards in europe. so the next point is if libopts-tarball is created by  autogen-native, its presumably dependent on the version, and must copy/track, or bork whenever  autogen-native version changes.
Sep 26 16:29:39 <bluelightning> gotan: if you're using signature-based stamps a rebuild will be triggered automatically
Sep 26 16:29:59 <bluelightning> (which is the default with denzil onwards)
Sep 26 16:31:42 <gotan> @bluelightning: what i mean is that there is still a requirement to either add the generated libopts tarball to DL_DIR, or copy it to staging or something, so that the downastream package can pick it up and use it in source form - or create a package for it.
Sep 26 16:33:33 <bluelightning> gotan: sure; you'd have to modify autogen-native to do that
Sep 26 16:33:52 <bluelightning> gotan: another alternative would be to upload the generated libopts tarball somewhere and then just fetch that
Sep 26 16:34:22 <bluelightning> depends on how version-dependent it is
Sep 26 16:35:20 <gotan> @bluelightning: presumably very - or why bother with all of this madness? is there a recommended STAGING_FILES or something?
Sep 26 16:38:06 <bluelightning> gotan: this is an unusual situation, most of the time the things we stage are executables, libraries or headers; so the code to do the staging is fairly explicit about which locations and file types get staged
Sep 26 16:40:46 <gotan> @bluelightning: unless there is a fn that i can call to peer into the $S dir or $WORKDIR of any recipe, or even a $WORKDIR_autogen generated for the DEPENDS, then i have to copy the src somewhere to pick it up later.
Sep 26 16:41:04 <bluelightning> gotan: yeah I understand that
Sep 26 16:42:24 <gotan> @bluelightning: or get the recipe to bork when the upstream version of autogen-native changes from
Sep 26 16:43:16 <gotan> @bluelightning: whatever - assuming i can do that without the same problem as sharing the src
Sep 26 16:43:22 <bluelightning> I can't think of a way to make this work that isn't absolutely horrible
Sep 26 16:44:59 <gotan> @bluelightning - generating a src package? some mechanism to allow native generated source to be mixed into the target recpies?
Sep 26 16:45:17 <bluelightning> gotan: not in this manner, no
Sep 26 16:45:37 <bluelightning> gotan: other than ignoring the tarball completely and just building a target version of autogen that hacks the configure script in whatever way is necessary to actually build libopts as a proper shared/static library
Sep 26 16:47:53 <gotan> @bluelightning: well my package works now i'm untarring the libopts into its src tree. Not sure how well making libopts a separate target recipe will work, because essentially as it is dependent on autogen-native, the same mucking about in hyperspace rules apply for
Sep 26 16:48:04 <Flyser> is it possible to build an arm toolchain for 32bit hosts on a 64bit machine? if so, how?
Sep 26 16:48:15 <gotan> @bluelightning: it as for the original package.
Sep 26 16:48:50 <gotan> @bluelightning: hacking autogen for the target was my first approach - it was painfull.
Sep 26 16:49:59 <gotan> @Flyser: as far as i know, your target depends entirely on your MACHINE setting in your local.conf
Sep 26 16:50:37 <gotan> @Flyser: bitbake handles the cross compiler generation etc.
Sep 26 16:51:10 <bluelightning> gotan: I'm not sure there's any non-painful way to handle this particular piece of software...
Sep 26 16:52:59 <gotan> @bluelightnint: i personally would go either: defn to check the version of $package, and bork in do_compile where i untar the local copy from $WORKDIR/files
Sep 26 16:54:33 <gotan> @bluelightning: or something like defining a STAGING_SRC, and leaving it at that.
Sep 26 16:54:58 <bluelightning> gotan: how do you know which version of the libopts tarball to look for though?
Sep 26 16:55:02 <gotan> @bluelightning: s/compile/configure/
Sep 26 16:55:43 <bluelightning> or do you just hardcode it for now?
Sep 26 16:59:15 <gotan> @bluelightning: an interesting question - would require a src manifest or a mechanism to set some kind of globals so tightly coupled recipes can pass it downstream... thats pre-optimisation speaking. As i seem to be the only one who has this issue then i'm going the hardcode route for the moment. I don't know enough about bitbake to properly comment on how to do this, but a mechanism for sharing no-arch sources between recipes would be
Sep 26 17:00:05 <gotan> @bluelightning: for example if i wanted to share a PSK or other information that i want to embed  in different tools.
Sep 26 17:00:27 <bluelightning> it's probably something to raise on the mailing list
Sep 26 17:00:43 <b1gtuna> ag_: Couple days ago you were helping me getting module dependency built during bitbake. I figured out
Sep 26 17:01:54 <gotan> @bluelightning: I'll add it to my list of things i've broken while trying to do seemingly simple stuff :)
Sep 26 17:02:41 <Flyser> gotan: MACHINE determines the target architecture
Sep 26 17:03:16 <bluelightning> Flyser: SDKMACHINE might be the variable you want to set
Sep 26 17:03:23 <Flyser> gotan: What I want is a toolchain, which can be used on 32 bit (i686) systems to compile programs for arm
Sep 26 17:03:31 <b1gtuna> Has anyone used qemu without X server?
Sep 26 17:03:39 <bluelightning> Flyser: right, definitely SDKMACHINE then
Sep 26 17:03:46 <bluelightning> b1gtuna: yep
Sep 26 17:03:58 <b1gtuna> I need some pointers. I'm using EC2 to build my images and I want to run it through QEMU to check.
Sep 26 17:04:26 <bluelightning> b1gtuna: we only had a patch in recent master to actually make the qemu-native build not fail without x11 headers installed on the host though
Sep 26 17:04:31 <b1gtuna> bluelightning: awesome! Enabling IMAGETEST = "qemu" switch isn't enough it seems.
Sep 26 17:05:00 <b1gtuna> bluelightning: oh... do you think I can patch my Denzil branch with it? or is it something much more significant?
Sep 26 17:05:25 <bluelightning> b1gtuna: well, in denzil we still had the OpenGL passthrough stuff which needs to be disabled as well
Sep 26 17:05:55 <bluelightning> b1gtuna: that can be hacked out though
Sep 26 17:06:55 <bluelightning> b1gtuna: also I'm not sure if IMAGETEST = "qemu" would be passing the right options to make qemu operate in console-only mode, that may also need to be addressed if you wanted to use that method
Sep 26 17:07:13 <bluelightning> b1gtuna: (the alternative being just running runqemu manually with the appropriate options)
Sep 26 17:07:34 <b1gtuna> bluelightning: hmmm I see. I was hoping IMAGETEST switch is all I needed.
Sep 26 17:07:43 <ag_> b1gtuna: Shoot
Sep 26 17:08:12 <b1gtuna> bluelightning: yup running it manually is certainly an option. How far are we away from post-denzil? I don't want to spend too much time hacking Denzil if post-Denzil is just around the corner!
Sep 26 17:08:58 <b1gtuna> ag_: it's kinda silly. I had to add DEPENDS = "virtual/kernel"
Sep 26 17:09:04 <b1gtuna> ag_:  to my image
Sep 26 17:09:38 <bluelightning> b1gtuna: if you mean the next stable release, it's just around the corner - we're in bugfixing mode for it atm
Sep 26 17:11:56 <b1gtuna> bluelightning: awesome. I will do it manually until then =).
Sep 26 17:12:23 <b1gtuna> ag_: that line puts the kernel source in /tmp/sysroots/your_machin/kernel
Sep 26 17:12:35 <ag_> i see
Sep 26 17:12:38 <ag_> nice done
Sep 26 17:13:47 <b1gtuna> ag_: I'm not sure why specifying the kernel version in the machine configuration file doesn't do this job though
Sep 26 17:13:52 <b1gtuna> bluelightning: thanks for your input
Sep 26 17:14:33 <Flyser> bluelightning: seems to work, thanks. where should I set this variable if I want to compile the toolchain for both x86_64 and x86_32 each time? creating two meta-toolchain recipes or is there a better way?
Sep 26 17:16:13 <ag_> b1gtuna: indeed strange
Sep 26 17:17:45 <gotan> @bluelightning: just had the idea $STAGING_DIR_NATIVE/usr/src/{packagename} linking to  $STAGING_DIR_NATIVE/usr/src/{packagename}-package-version. that should not interfere with anything right?
Sep 26 17:22:44 <gotan> @bluelightning: anyway, thanks for all your help with this will think more on it and post to the list.
Sep 26 17:32:03 <JaMa> rburton: see my 2 commits about xserver-xorg exa
Sep 26 17:32:25 <JaMa> rburton: your doesn't work for layers with PRINC in xserver-xorg (unless they change RCONFLICTS line too
Sep 26 17:33:01 <JaMa> rburton: this thread http://lists.linuxtogo.org/pipermail/openembedded-core/2012-September/030014.html
Sep 26 17:37:01 <bluelightning> Flyser: you have to do two separate builds and set it prior to each build, but it is whitelisted through from the environment so you can do e.g.: SDKMACHINE="i686" bitbake meta-toolchain
Sep 26 17:45:05 <Flyser> bluelightning: thanks!
Sep 26 17:45:13 <bluelightning> np
Sep 26 18:06:05 <kergoth> anyone seen bitbake hang for an odd amount of time after seeing the tasks summary at the end of a build?
Sep 26 18:06:10 <kergoth> hrm
Sep 26 18:06:13 <kergoth> nevermind, think i found it
Sep 26 18:06:23 <kergoth> slow event handler from my layer, i think
Sep 26 18:08:48 <JaMa> kergoth: here it's usually slow git used by buildhistory
Sep 26 18:09:02 <kergoth> hm, will check that too, thanks for the pointer
Sep 26 18:38:35 <fray> I've only seen it on buildhistory work, or if I terminate bitbake w/ ctl-c.. something it seems to hang for a very long time.. (I assume it's trying to flush a pipe or something)
Sep 26 19:21:33 <rburton> JaMa: wasn't that error due to missing whitespace between the < and the version?
Sep 26 19:22:12 * rburton curses oe
Sep 26 19:23:26 <rburton> JaMa: i just worry that declaring such wide conflicts (<PV) will bite us in the future somehow
Sep 26 19:24:05 <rburton> JaMa: but re that rootfs error, i presume you still get it? try adding whitespace between < and PV
Sep 26 19:29:03 <JaMa> rburton: have you read whole thread?
Sep 26 19:29:12 <rburton> JaMa: not for a few days :)
Sep 26 19:29:26 <rburton> JaMa: <insert dependency based rage here>
Sep 26 19:29:30 <JaMa> just read the thread including those 2 patches from me
Sep 26 19:31:54 <rburton> JaMa: what's the semantics of EXTENDPKGV?
Sep 26 19:32:03 <rburton> the real PV that's actually being used?
Sep 26 19:32:35 <JaMa> yes the version how it's seen from package manager
Sep 26 19:32:56 <JaMa> e.g. Version: 2:1.11.2-r10
Sep 26 19:33:14 <rburton> i forgot that it was you who pointed out the whitespace fix
Sep 26 19:34:48 <rburton> deps are hard, lets just delete it
Sep 26 19:40:18 <Flyser> Is there an easy way to append my own stuff (e.g. changing the shell prompt, adding aliases or printing some help message) to the end of the environment-setup script in the sdk tarballs?
Sep 26 19:41:03 <rburton> JaMa: grumbling acceptance that maybe extendpkgv is the only way of actually solving this
Sep 26 19:41:14 <rburton> in the future, no more moving files around :)
Sep 26 19:45:04 <rburton> ok, seriously odd.  autobuilt core-image-sato for atom boots fine, local build from master fails to boot with syslinux problems
Sep 26 19:45:11 <rburton> no obvious local.conf breakage
Sep 26 19:45:24 <rburton> "no default or ui directives found"
Sep 26 19:45:26 <rburton> same usb stick
Sep 26 19:47:25 <Flyser> can I create a .bbappend file for a .bbclass file?
Sep 26 19:48:27 <kergoth> nope
Sep 26 19:52:30 <Flyser> crap :-/
Sep 26 19:53:22 <kergoth> best bet is to just copy it into your layer and change it there, and get those changes upstream asap
Sep 26 19:58:26 <JaMa> do we want upgrade qt-4.8.1 to qt-4.8.3 before release or should I add 4.8.3 with negative D_P?
Sep 26 19:59:07 <JaMa> already pushed in contrib/jansa/qt4-4.8.3 if someone is interested
Sep 26 20:00:56 <Flyser> these changes are specific to my distribution, so upstreaming is not really an option
Sep 26 20:01:16 <kergoth> Flyser: which class is it?
Sep 26 20:01:32 <kergoth> in some cases you can just add a new class which appends to vars, etc from the first, and get that inherited
Sep 26 20:01:41 <Flyser> ./classes/toolchain-scripts.bbclass
Sep 26 20:01:54 <kergoth> for example, i just added a class to my INHERIT_DISTRO after license called license-extra, which does a create_license_manifest_append()
Sep 26 20:02:00 <Flyser> I want to append to toolchain_create_sdk_env_script
Sep 26 20:02:03 <kergoth> thereby avoiding copying license.bbclass over
Sep 26 20:04:11 <Flyser> what is INHERIT_DISTRO (sorry for asking silly questions, but I couldn't find it in the documentation)
Sep 26 20:04:44 <msm> just rebased on master, and seeing this now
Sep 26 20:04:44 <msm> https://gist.github.com/3790243
Sep 26 20:05:32 <kergoth> Flyser: it's the var used to inherit some of the default classes, but a direct += to INHERIT would work just as well, if what you're altering  is a class that's always inherited. if not, you'd need to inherit it elsewhere (e.g. from bbappends)
Sep 26 20:15:51 <msm> well it seems like the above issue has gone away
Sep 26 20:16:03 <msm> after bitbake -c cleanall dbus-native
Sep 26 20:22:07 <rburton> msm: seen a few reports like that, looks like the "no x please" logic isn't quite right for -native
Sep 26 20:22:09 <chackal_sjc> When there is no LICENSE file on a source code that is GPLv2 for example, what should I populate LIC_FILES_CHKSUM with?
Sep 26 20:23:28 <rburton> msm: confirmed, it's not working entirely right. sending a fix now
Sep 26 20:27:25 <rburton> msm: fixed, hopefully.
Sep 26 20:31:22 <msm> rburton: cool
Sep 26 20:31:46 <rburton> (well, on the list)
Sep 26 20:32:17 <rburton> not that anyone could reproduce it reliably, but i suspect its due to strict linking at our end but not strict on the host libs, so you got missing symbols
Sep 26 20:33:47 <kergoth> chackal_sjc: at a minimum you s hould capture e.g. the license/copyright header in one of the files, so the fact that it's gplv2 is captured, even if hte ful license text isn't
Sep 26 20:35:52 * rburton finally works out that it's the crappy bios on this box that can't boot a 1.6G hddimg
Sep 26 20:36:19 <fray> crappy bios on a board?  that never happens.. :P
Sep 26 20:37:38 <rburton> i know, i was very surprised
Sep 26 20:37:57 <rburton> i just hope the same reason is why this cdt netbook was totally refusing to even look at a hddimg
Sep 26 20:38:23 <fray> one of the reasons the /lib and /usr/lib split is still needed on some systems
Sep 26 20:38:40 <rburton> let's not start that again ;)
Sep 26 20:38:47 <fray> <grin>
Sep 26 20:39:06 <rburton> an initramfs still seems like a better idea for the "my bios is made of string" use-case
Sep 26 20:39:15 <fray> ;)
Sep 26 20:39:15 <rburton> but i said i won't start that again!
Sep 26 20:39:24 * rburton -> crisps, wine, etc
Sep 26 20:45:18 <fray> anyone here know what "gcc-crosssdk" is?
Sep 26 20:45:28 <fray> I know what -nativesdk is.. and I know what -cross-canadian- is..
Sep 26 20:45:32 <fray> what but is crosssdk?!
Sep 26 20:45:33 <evanp> Flyser: I didn't end up doing this, but creating a .bbclass in your later and then "require"ing the original seems to work, at least for simple cases
Sep 26 20:46:01 <evanp> Flyser: later=layer
Sep 26 20:46:09 <fray>  /configure  --build=x86_64-linux            --host=x86_64-linux             --target=x86_64-oesdkmllib32-linux
Sep 26 20:46:12 <kergoth> evanp: you'd have to hardcode the path/structure, though
Sep 26 20:46:22 * fray is still confused
Sep 26 20:46:41 <evanp> kergoth: it's not too ugly if you do it relative to ${COREBASE}
Sep 26 20:50:41 <evanp> fray: I used to know this...I think it's the native->sdk cross compiler. used to build the nativesdk compiler. Something like that....
Sep 26 20:51:20 <fray> what I'm trying to understand.. what is the target?  is it building a compiler that can build for the -host- or for the -target- or?
Sep 26 20:51:28 <fray> 'crosssdk' really doesn't mean anything to me and it's confusing me..
Sep 26 20:51:37 <fray> is it building for an SDK that is NOT the same as the host?
Sep 26 20:52:01 <fray> the problem is when I have multilibs enabled, and I try to build the SDK, it blows up cause crosssdk is being attempted for a multilib.. which I think is wrong in some way
Sep 26 20:52:12 <fray> (just not sure in what way)
Sep 26 20:52:30 <fray> I'm wondering if everything -nativesdk is checked, if -crosssdk should also be checked
Sep 26 20:52:40 <evanp> fray: if I remember correctly, it's a compiler that builds for the -sdk- but runs on the -host-. it's built as a cross compiler, even though -sdk- and -host- are usually "the same" in practice
Sep 26 20:53:06 <fray> ok, in that case it should have the same 'protection' as a nativesdk package
Sep 26 21:31:56 <kergoth> http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/commit/?id=99f65be - /me thinks its useful to have the license manifest in deploy
Sep 26 21:31:59 <kergoth> evanp: true, good point
Sep 26 22:08:10 <Flyser> evanp: I don't think I entirely understood what you are suggesting. Here is what I did: create a classes/toolchain-scripts-append.bbclass file in my layer with http://bpaste.net/show/47833/ as its content. the build should fail due to the exit 1, but it doesn't. It never gets executed
Sep 26 22:08:28 <Flyser> What am I doing wrong here?
Sep 26 22:08:44 <kergoth> no, it'd have to be named toolchain-scripts.bbclass, unless you adjusted things to inherit the new class?
Sep 26 22:08:51 <kergoth> it wont magically know to parse toolchain-scripts-append
Sep 26 22:09:38 <Flyser> that makes sense, but wouldn't require "classes/toolchain-scripts.bbclass" be recursive that way?
Sep 26 22:09:54 <kergoth> yeah, thats why you'd have to require it using an explicit path with COREBASE
Sep 26 22:09:57 <kergoth> as we discussed earlier
Sep 26 22:10:03 <kergoth> [13:46:11] <kergoth> evanp: you'd have to hardcode the path/structure, though
Sep 26 22:10:03 <kergoth> [13:46:41] <evanp> kergoth: it's not too ugly if you do it relative to ${COREBASE}
Sep 26 22:10:10 <Flyser> I c
Sep 26 22:10:27 <Flyser> sorry, I missed those lines
Sep 26 22:10:40 <kergoth> so require ${COREBASE}/meta/classes/toolchain-scripts.bbclass, or what have you
Sep 26 22:10:45 <kergoth> not ideal, but .. could get the job done
Sep 26 22:14:44 <Flyser> http://bpaste.net/show/47834/ doesn't work either
Sep 26 22:16:35 <kergoth> use bitbake -e to inspect toolchain_create_sdk_env_script
Sep 26 22:24:02 <Flyser> nevermind ... it turns out that I can override toolchain_create_sdk_env_script with a custom toolchain recipe
Sep 26 23:47:09 <msm> fray: ping
Sep 27 01:25:17 <Foray|2> hey ya! Is anyone here? Go Yocto!
Sep 27 01:25:54 <Foray|2> So... I got a noob question about make I was hoping to ask someone around here with some more exp points than myself.
Sep 27 01:27:37 <Foray|2> my Makefile has a target "all:" but when I run it, I get an error that says
Sep 27 01:28:28 <Foray|2> "No rule to make target 'PCIe'. Stop."
Sep 27 01:29:40 <Foray|2> My source is for a PCIe driver, sure, but I'm confused as to where the target "PCIe" is specified if it's NOT called out in my Makefile. ??  Any ideas?
Sep 27 01:30:28 <Foray|2> Oh and I guess this has to do with Yocto because I'll be putting the driver in my build...  any help would be much appreciated!
**** ENDING LOGGING AT Thu Sep 27 02:59:57 2012

**** BEGIN LOGGING AT Thu Sep 27 02:59:57 2012
Sep 27 03:07:51 <msm> Foray|2: where is your recipe?
Sep 27 03:08:07 <Foray|2> what do you mean?
Sep 27 03:08:14 <Foray|2> I don't have one.
Sep 27 03:08:20 <Foray|2> Just a Makefile
Sep 27 03:12:41 <Foray|2> I just sort of figured it out.  The name of my Kconfig files was wrong. Now it finishes with no errors, however, I don't get the output files I'd expect.
Sep 27 03:12:58 <Foray|2> such as a .ko file or a .o
Sep 27 03:13:44 <evanp> Foray|2: are you trying to build an out-of-tree module?
Sep 27 03:14:37 <Andy44> yes. but right now I'm not even including the build into my Yocto project.  I just want to build it under Linux.  I was really just a question about make.  Not Yocto.
Sep 27 03:18:56 <kergoth> the gnu make manual is actually excellent. highly recommended
Sep 27 03:19:29 <Andy44> haha yeah.  I'm thinking that's going to need a nice sit-down read pretty soon here.
Sep 27 03:20:42 <evanp> well...is your Makefile a Makefile, or a Kbuild file named "Makefile"?
Sep 27 03:39:54 <Andy44> The test driver comes with a "Makefile" and a "Kconfig" file.
Sep 27 03:41:58 <Andy44> ahh this is a pretty deep problem I think.  I just did a make -d...
Sep 27 03:42:20 <Andy44> well I guess I'm not super sure actually
Sep 27 03:48:56 <kergoth> make -d is pretty useless, really
Sep 27 03:49:33 <evanp> I didn't think out-of-tree modules were allowed to use Kconfig....
Sep 27 03:49:33 <kergoth> on a related note, http://bashdb.sourceforge.net/remake/ looks interesting
Sep 27 03:49:57 <Andy44> yeah this might as well be latin...
Sep 27 03:49:57 <evanp> I have a collegue who loves remake
Sep 27 08:08:31 <RP> kergoth: I think we even have a remake recipe
**** ENDING LOGGING AT Thu Sep 27 08:14:33 2012

**** BEGIN LOGGING AT Thu Sep 27 08:16:20 2012
Sep 27 08:16:38 <JaMa> hrw: are you looking into nativesdk-perl issue?
Sep 27 08:17:14 <hrw> no, have more important tasks now
Sep 27 08:17:27 <JaMa> ok
Sep 27 08:17:51 <RP> JaMa: Its the sed expressions in the perl recipe :/
Sep 27 08:18:05 <hrw> RP: I love how OE got improved in last two years. All those "recipe change, please rebuild all automatically" etc stuff
Sep 27 08:18:43 <hrw> I added SERIAL_CONSOLE to machine config, built image and sysvinit got rebuilt
Sep 27 08:19:04 <RP> hrw: :)
Sep 27 08:23:10 <JaMa> RP: I know you said that when I reported it on ML..
Sep 27 09:00:36 <JaMa> hmm lots of staging warnings like
Sep 27 09:00:37 <JaMa> WARNING: The recipe is trying to install files into a shared area when those files already exist. Those files are: /OE/shr-core/tmp-eglibc/deploy/ipk/armv7a-vfp-neon/busybox_1.20.2-r4_armv7a-vfp-neon.ipk
Sep 27 09:00:43 <JaMa> is it expected?
Sep 27 09:01:25 <JaMa> seems like every do_package_write_ipk_setscene does that
Sep 27 09:31:05 <bluelightning> morning all
Sep 27 11:26:17 <rburton> JaMa: i just showed RP my logs where it does that, but he's had to pop out
Sep 27 12:27:27 <hrw> rburton: you scared him away
Sep 27 12:27:40 <hrw> hi Ross btw ;)
Sep 27 12:31:23 <mertsas_> is there an easy way to make a debug image from a given image?
Sep 27 12:31:37 <mertsas_> that is, an image with debug symbols for everything
Sep 27 12:37:12 <bluelightning> mertsas_: yep, just add dbg-pkgs to IMAGE_FEATURES
Sep 27 12:37:47 <bluelightning> mertsas_: if you want you can create a second image recipe that just "require"s the first and does IMAGE_FEATURES += "dbg-pkgs"
Sep 27 12:39:08 <mertsas_> thanks bluelightning, that did the trick:D
Sep 27 12:39:15 <bluelightning> np
Sep 27 13:03:38 <rburton> hi hrw!
Sep 27 13:15:11 <otavio> I am having problem installing xserver-xorg-module-exa
Sep 27 13:15:21 <otavio> it conflicts with PV
Sep 27 13:16:56 <otavio> | Collected errors:
Sep 27 13:16:56 <otavio> |  * check_conflicts_for: The following packages conflict with xserver-xorg-module-exa:
Sep 27 13:16:59 <otavio> |  * check_conflicts_for:       xserver-xorg *
Sep 27 13:17:01 <otavio> |  * opkg_install_cmd: Cannot install package packagegroup-core-x11-base.
Sep 27 13:45:46 <rburton> otavio: put a space between < and ${PV} in xserver-xorg.inc
Sep 27 13:46:09 <otavio> rburton: is it fixed in master?
Sep 27 13:46:29 <rburton> there are patches but nothing merged yet afaik
Sep 27 13:47:17 <ant_work> rburton: hi there. How's going with the unification with meta-oe xserver btw?
Sep 27 13:47:28 <rburton> ant_work: the init scripts?
Sep 27 13:47:43 <ant_work> yes, x11-common vs xserver-common afaik
Sep 27 13:48:07 <rburton> nothing yet
Sep 27 13:48:13 <ant_work> and the rdeps (xinput-calibrator for one)
Sep 27 13:48:33 <ant_work> I see. Keep on !
Sep 27 13:48:38 <ant_work> tia
Sep 27 14:12:15 <otavio> rburton: This would be nice to be merged so ... :-(
Sep 27 14:12:41 <rburton> otavio: yes. tell rp.
Sep 27 14:13:06 <rburton> otavio: lots of patches were flying around, and it took a while to decide on the right one
Sep 27 14:14:04 <otavio> rburton: Yes but the breakness is since 17th of September ... so a revert would have been good ;-)
Sep 27 14:14:17 <rburton> otavio: reverting would break too
Sep 27 14:14:24 <rburton> otavio: revert the patch before that, still broken
Sep 27 14:21:33 <RP> otavio: its merged
Sep 27 14:21:45 <RP> I still think its wrong
Sep 27 14:21:51 <otavio> RP: thx a lot
Sep 27 14:22:05 <otavio> RP: well, putting a space makes it work for me ;)
Sep 27 14:22:23 <RP> otavio: having the version float is still wrong though
Sep 27 14:22:39 <otavio> RP: it is not merged (or not pushed)
Sep 27 14:22:46 <otavio> RP: I am checking poky
Sep 27 14:23:01 <otavio> RP: have you merged it on oe-core only?
Sep 27 14:23:09 <RP> otavio: refresh, the scripts were still running I suspect
Sep 27 14:24:56 <otavio> RP: works fine now :) thx a lo
Sep 27 14:25:03 <otavio> RP: thx a lot
Sep 27 14:44:18 <otavio> RP: are you aware of problems in perl-native?
Sep 27 15:23:14 <fray> hey I have a Cedar Trail board (EMBCDTNMCCDVK) and was wondering if anyone knows if I can, and how to get into the EFI shell
Sep 27 16:19:11 <ag_> Any via processor support there in yocto/oe?
Sep 27 16:21:54 <hrw> ag_: define via
Sep 27 16:22:07 <hrw> via has arm and x86 at least
Sep 27 18:46:13 <msm> xxiao: hey was if you who told me about this error: /usr/lib/perl5: Cannot create symlink to `perl': File exists
Sep 27 18:54:08 <otavio> RP: the fix did not work on opkg
Sep 27 18:57:26 <otavio> RP: I send a new patch for it. It works for me.
Sep 27 19:07:04 <RP> otavio: thanks. I really need Martin's view on it but we need something I agree
Sep 27 19:07:15 <RP> otavio: what kind of problems in perl-native?
Sep 27 19:07:43 <otavio> RP: sato-icons-theme doesn't build if libxml-simple-perl is not installed on host
Sep 27 19:08:01 <otavio> RP: so perl-native is not really working regarding INC handling
Sep 27 19:08:14 <RP> otavio: does it actually inherit perlnative ?
Sep 27 19:08:33 <otavio> RP: what?
Sep 27 19:08:40 <otavio> sato-icons-theme?
Sep 27 19:08:54 <RP> otavio: yes
Sep 27 19:09:06 <otavio> RP: will check
Sep 27 19:09:24 <RP> otavio: it doesn't depend on libxml-simple-perl at all
Sep 27 19:09:42 <otavio> RP: the icon-naming doe
Sep 27 19:09:43 <otavio> does
Sep 27 19:09:53 <RP> otavio: ah, ok
Sep 27 19:10:59 <RP> otavio: Does the perl patch posted on the mailing list help?
Sep 27 19:11:18 <otavio> RP: which one?
Sep 27 19:11:37 <RP> otavio: [OE-core] Fail in perl-native_5.14.2.bb
Sep 27 19:15:12 <otavio> RP: will try
Sep 27 19:16:18 <JaMa> RP: I've alternative patch, but otavio said it didn't work for him (weird old version worked for me) and I cannot really test upgrade path anymore
Sep 27 19:16:24 <JaMa> I've tested upgrade path with opkg only when it was with RREPLACES.. all my targets are upgraded past that "dangerous" point since then..
Sep 27 19:16:43 <RP> JaMa: So what do I do?
Sep 27 19:16:54 <JaMa> RP: https://github.com/shr-distribution/oe-core/commit/38da3ce32acdf8bea1a8594e6a8d21f05f329f1b
Sep 27 19:18:00 <RP> JaMa: hmm, I'm not sure rpm will like that :/
Sep 27 19:18:02 <JaMa> RP: please give me few more minutes to finish do_rootfs again this time with '<<'
Sep 27 19:18:04 <RP> fray: any idea?
Sep 27 19:18:09 <RP> JaMa: ok
Sep 27 19:18:25 <otavio> RP: JaMa: This patch does not work.
Sep 27 19:18:25 <fray> which item?
Sep 27 19:18:36 <otavio> rootfs fail to build here
Sep 27 19:18:38 <JaMa> RP: at least we should learn, how to use RCONFLICTS with < VER
Sep 27 19:18:46 <otavio> JaMa: lol
Sep 27 19:18:49 <otavio> indeed
Sep 27 19:18:50 <otavio> :)
Sep 27 19:18:57 <JaMa> otavio: did you cleansstate it and make sure it's not in any SSTATE_MIRROR?
Sep 27 19:19:07 <fray> RPM supports:  < > <= >= =
Sep 27 19:19:17 <JaMa> fray: not << ?
Sep 27 19:19:18 <fray> what does '<<' mean?
Sep 27 19:19:22 <JaMa> EARLIER
Sep 27 19:19:29 <JaMa> < is EARLIER_EQUAL
Sep 27 19:19:31 <fray> how is that different then <
Sep 27 19:19:47 <JaMa> at least for dpkg, (opkg source says)
Sep 27 19:19:49 <fray> so "<" on opkg/deb is the same as <= in RPM?
Sep 27 19:20:00 <JaMa> yes, deprecated version of <=
Sep 27 19:20:12 <fray> how confusing..
Sep 27 19:20:33 <JaMa> agreed (been there few minutes ago :))
Sep 27 19:20:40 <fray> I'd recommend that code be put into the package_*.bbclass to normalize this and use the format that bitbake uses..
Sep 27 19:20:50 <fray> (I'd also say <= is a hell of a lot more obvious then <<)
Sep 27 19:21:07 <fray> I read << and think bitshift
Sep 27 19:21:23 <JaMa> are you 100% sure about <</< in RPM world (did you check source?)
Sep 27 19:21:25 <RP> I'm surprised dpkg would go with that
Sep 27 19:21:33 <fray> I can check it..
Sep 27 19:21:36 <otavio> But rconflicts is not working for opkg
Sep 27 19:21:42 <otavio> with <<
Sep 27 19:21:50 <JaMa> fray: please do
Sep 27 19:22:55 <JaMa> http://debian-handbook.info/browse/stable/sect.package-meta-information.html
Sep 27 19:23:26 <JaMa> really says that << is LESS (doesn't say if < is LESS_EQUAL)
Sep 27 19:23:36 <fray>     RPMSENSE_LESS       = (1 << 1),
Sep 27 19:23:37 <fray>     RPMSENSE_GREATER    = (1 << 2),
Sep 27 19:23:37 <fray>     RPMSENSE_EQUAL      = (1 << 3),
Sep 27 19:23:44 <JaMa> 5.2.1.1. Dependencies: the Depends Field
Sep 27 19:24:24 <fray> <spam>
Sep 27 19:24:25 <fray>     { "<=", (rpmsenseFlags) (RPMSENSE_LESS ^ RPMSENSE_EQUAL) },
Sep 27 19:24:26 <fray>     { "=<", (rpmsenseFlags) (RPMSENSE_LESS ^ RPMSENSE_EQUAL) },
Sep 27 19:24:26 <fray>     { "==", (rpmsenseFlags) (RPMSENSE_EQUAL) },
Sep 27 19:24:26 <fray>     { "!=", (rpmsenseFlags) (RPMSENSE_NOTEQUAL) },
Sep 27 19:24:26 <fray>     { ">=", (rpmsenseFlags) (RPMSENSE_GREATER ^ RPMSENSE_EQUAL) },
Sep 27 19:24:26 <fray>     { "=>", (rpmsenseFlags) (RPMSENSE_GREATER ^ RPMSENSE_EQUAL) },
Sep 27 19:24:29 <JaMa> The relations allowed are <<, <=, =, >= and >> for strictly earlier, earlier or equal, exactly equal, later or equal and strictly later, respectively. The deprecated forms < and > were confusingly used to mean earlier/later or equal, rather than strictly earlier/later, and must not appear in new packages (though dpkg still supports them with a warning).
Sep 27 19:24:34 <fray>     { "<",  (rpmsenseFlags) (RPMSENSE_LESS) },
Sep 27 19:24:34 <fray>     { "=",  (rpmsenseFlags) (RPMSENSE_EQUAL) },
Sep 27 19:24:34 <fray>     { ">",  (rpmsenseFlags) (RPMSENSE_GREATER) },
Sep 27 19:24:38 <fray> that is the supported set
Sep 27 19:25:18 <JaMa> heh nice
Sep 27 19:25:30 <JaMa> so we need to normalize it somewhere :/
Sep 27 19:25:41 <fray> place to do it is in the package_*.bbclass
Sep 27 19:26:03 <fray> and 'what' we need to normalize IMHO depends on the format that bitbake cares about..
Sep 27 19:26:15 <JaMa> yes but it should be easier to use dpkg/opkg syntax in bitbake and replace <</< >>/> in package_rpm
Sep 27 19:26:18 <fray> (if it doesn't care at all, then we figure out something else)
Sep 27 19:26:41 <fray> ya.. I just don't see "<<" or ">>" as being meaningful though w/o documentation..
Sep 27 19:26:49 <fray> I see that and really have no clue what it means
Sep 27 19:27:09 <fray> < and > are arthmatic.. so they're "obvious" (and debians deprecated usage is very odd)
Sep 27 19:27:24 <JaMa> It's documented in debian manual and opkg code
Sep 27 19:27:42 <fray> but I ask someone working on a recipe in the yocto project won't ever look at either -- unless I'm having a problem
Sep 27 19:27:44 <JaMa> so if we add ERROR when < or > is used, then we can add explaining docs to it
Sep 27 19:28:03 <fray> I don't know where this code would be in bitbake
Sep 27 19:28:18 <JaMa> e.g. bb.utils.deps_explode
Sep 27 19:28:45 <otavio> http://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts <= oficial policy
Sep 27 19:29:34 <JaMa> or it can be warning like dpkg does "< is deprecated option with the same meaning as <="
Sep 27 19:29:45 <JaMa> otavio: that's from where I copy&pasted it
Sep 27 19:30:44 <JaMa> RP: WARNING: The recipe is trying to install files into a shared area when those files already exist.
Sep 27 19:30:59 <JaMa> RP: does it mean that it detected WARNING and then overwritten those files right?
Sep 27 19:31:35 <fray> still havn't found the code -- other then what checks that it's " <>="
Sep 27 19:31:52 <otavio> fray: <> is different
Sep 27 19:31:55 <otavio> fray: for dpkg
Sep 27 19:32:04 <fray> I'm looking in bitbake
Sep 27 19:32:18 <fray> it just checks that the only legal chars in the optional chunk are "<>="
Sep 27 19:34:00 <fray> ya.. I can't find where bitbake does the actual parsing of the expression (and then comparison)
Sep 27 19:34:22 <RP> JaMa: they get overwritten, yes
Sep 27 19:34:53 <RP> fray: I'm not sure bitbake does anything with the version information tbh
Sep 27 19:34:57 <fray> RP -- is there something in bitbake that looks at the comparison operator of RDEPENDS and DEPENDS?
Sep 27 19:35:18 <fray> I see where it can look at the version, but don't see anything that actually does anything with it..
Sep 27 19:35:19 <fray> Hmm
Sep 27 19:35:19 <RP> fray: I suspect we just made it accept versions in the hope someday that we'd add version support
Sep 27 19:35:29 <fray> gotcha
Sep 27 19:35:36 <RP> which was better than throwing parsing errors
Sep 27 19:35:53 <RP> That way you could put the metadata there
Sep 27 19:36:10 <fray> ok.. then any opinion.. deb/opkg style, "rpm style", or arthmatic style?  ;)  I don't care.. but if we deviate we need to detect it and document for the recipe author..
Sep 27 19:36:17 <fray> I still content "<<" and ">>" is very confusion..
Sep 27 19:36:51 <RP> fray: have we confirmed that << is dpkg ?
Sep 27 19:36:53 <fray> sounds like this is at least a simple thing to check for in the recipe sanity checks
Sep 27 19:36:56 <fray> I have not
Sep 27 19:36:59 <RP> I don't 100% trust the opkg source
Sep 27 19:38:15 <RP> "The relations allowed are <<, <=, =, >= and >> for strictly earlier, earlier or equal, exactly equal, later or equal and strictly later, respectively.  The deprecated forms < and > were confusingly used to mean earlier/later or equal, rather than strictly earlier/later, and must not appear in new packages (though dpkg still supports them with a warning). "
Sep 27 19:38:19 <RP> http://www.debian.org/doc/debian-policy/ch-relationships.html
Sep 27 19:39:07 <hollisb> lol
Sep 27 19:39:16 <fray>      if (strcmp(op, "<=") == 0 || strcmp(op, "<") == 0) {
Sep 27 19:39:16 <fray>           return r <= 0;
Sep 27 19:39:22 <fray>      if (strcmp(op, ">=") == 0 || strcmp(op, ">") == 0) {
Sep 27 19:39:22 <fray>           return r >= 0;
Sep 27 19:39:26 <fray>      if (strcmp(op, "<<") == 0) {
Sep 27 19:39:27 <fray>           return r < 0;
Sep 27 19:39:31 <fray>      if (strcmp(op, ">>") == 0) {
Sep 27 19:39:31 <fray>           return r > 0;
Sep 27 19:39:34 <fray>      if (strcmp(op, "=") == 0) {
Sep 27 19:39:34 <fray>           return r == 0;
Sep 27 19:39:38 <fray> (from opkg sources)
Sep 27 19:39:55 <fray> hollisb -- way way too confusing.. :P
Sep 27 19:40:08 <hollisb> even worse than .= and =.
Sep 27 19:40:08 <hollisb> ;)
Sep 27 19:40:23 <RP> I doubt anyone realises <  means <=
Sep 27 19:40:40 <fray> maybe it should we should do:  DEPENDS = "package (lessthan 12.3)"
Sep 27 19:40:48 <fray> thats less confusing to me then "<<"  :P
Sep 27 19:41:16 <mranostay> fray: my eyes are bleeding :)
Sep 27 19:41:23 <RP> Hmm, JaMa beat me to it above
Sep 27 19:41:46 <fray> << and >> I read as 'bitwise' shift.. which mean nothing in the context of versions..
Sep 27 19:42:09 <RP> I think I'd prefer to support "<" and ">" with sane meaning and translate them for opkg/deb
Sep 27 19:42:16 <RP> since I think opkg/deb are insane
Sep 27 19:42:47 <fray> we should probably have a sanity check that looks for '<<' and '>>' then and does a translation -- or error they're not valid
Sep 27 19:43:02 <RP> fray: I've never seen them...
Sep 27 19:43:11 <RP> fray: I think I'd have rejected them as being invalid...
Sep 27 19:43:39 <fray> seems reasonable to me
Sep 27 19:44:35 <JaMa> fray: which opkg source do you read?
Sep 27 19:44:57 <JaMa> fray: mine looks like this https://github.com/shr-distribution/oe-core/commit/38da3ce32acdf8bea1a8594e6a8d21f05f329f1b
Sep 27 19:45:07 <JaMa> and mine is what's exactly in oe-core
Sep 27 19:45:29 <fray> the version in my tmp working directory... ;)
Sep 27 19:45:38 <msm> this command: tar -cf - -C /local/home/b08248/Work/tmp/sdk-devel/build_p4080ds_release/tmp/work/ppce500
Sep 27 19:45:38 <msm> mc-fsl-linux/perl-5.14.2-r6/sysroot-destdir/ -ps . | tar -xf - -C /local/home/b08248/Work/tmp/sdk-devel/build_p4080ds_
Sep 27 19:45:38 <msm> release/tmp/sysroots/p4080ds/
Sep 27 19:45:42 <fray> libopkg/pkg.c -- line 927+
Sep 27 19:45:42 <msm> is just copying?
Sep 27 19:45:57 <msm> its tar to stdout, and the untarring from stdin?
Sep 27 19:46:03 <JaMa> RP: all R* deps go through bb.utils.explode_dep_versions AFAIK
Sep 27 19:46:05 <fray> yes.. but it uses tar to preserve special files
Sep 27 19:46:22 <JaMa> RP: so it's only one place to verify and error out if needed IMHO
Sep 27 19:46:48 <RP> JaMa: yes, that would seem reasonable
Sep 27 19:46:59 <JaMa> fray: and repo?
Sep 27 19:47:15 <msm> fray: ok, so there is a reason
Sep 27 19:47:17 <fray> this was build from head of oe-core not too long ago..
Sep 27 19:47:30 <fray> msm -- definitely....
Sep 27 19:47:42 <RP> msm: yes, its permissions, owners and special files preservation
Sep 27 19:47:45 <msm> so this: output tar: ./usr/lib/perl5: Cannot create symlink to `perl': File exists
Sep 27 19:48:04 <JaMa> fray: this is current: http://paste.debian.net/193726/
Sep 27 19:48:04 <msm> means some symlink was already in the sysroot, but why would it be there? (note: this is the perl recipe)
Sep 27 19:48:06 * RP tries to remember what he was doing
Sep 27 19:48:11 <fray> that means that something else created a file or else...  basically something is broken -- might be pseudo?
Sep 27 19:48:55 <fray> JaMa -- different file..  I was looking at opkg's "pkg_version_satisfied" function
Sep 27 19:50:40 <JaMa> fray: ah ok, then it's even worse
Sep 27 19:50:41 <msm> fray: this is the sysroot, could the file have already been there?
Sep 27 19:51:07 * RP supposes rewriting half of packagedata at -rc2 might be a bad idea :/
Sep 27 19:51:39 <JaMa> fray: but libopkg/pkg_depends.c is right file for "opkg upgrade"
Sep 27 19:51:59 <JaMa> fray: libopkg/pkg.c is used only if you ask to compare versions "1.0 <= 1.1" etc
Sep 27 19:53:46 <fray> msm, I'm not sure.. I'd have to see it in place..
Sep 27 19:54:08 <fray> JaMa, well my assumption is they'd do the same thing.. ;)
Sep 27 19:54:19 <fray> On the surface it looks like they do
Sep 27 19:54:36 <fray> opkg and deb appear to work the same way in regards to the '<<' vs '<' syntax..
Sep 27 19:55:03 <fray> RP -- what needs to be rewritten?
Sep 27 19:55:45 <RP> msm: tmp/sstate-control/manifest* should tell you what was in the sysroot
Sep 27 19:55:46 <fray> for this stuff, it looks fairly simply to me.. add translation code into the package_*.bbclass files.. add a validation to stop '<<' and '>>' (or '<' and '>')
Sep 27 19:56:01 <RP> fray: correct, doesn't look hard
Sep 27 19:57:34 <fray> RP -- BTW perl still has a problem.. it won't build for me if I have multilib enabled (and I'm targeting a system that has lib != lib
Sep 27 19:57:50 <fray> this is as of the regex refactoring from this morning..  yesteray it just didn't work with nativesdk.. ;)
Sep 27 19:58:46 <JaMa> and when we're there also add whitespace check to bb.utils.explode_dep_versions
Sep 27 19:59:02 <RP> fray: patches welcome?
Sep 27 19:59:05 <fray> does whitespace matter?
Sep 27 19:59:22 <fray> RP -- for the perl thing.. I've been screwing with it for the last hour and made no progress..
Sep 27 19:59:27 <fray> I can't figure out why either
Sep 27 19:59:38 <RP> fray: :(
Sep 27 19:59:45 <JaMa> fray: yes, it's completely ignored without, see http://patchwork.openembedded.org/patch/37069/
Sep 27 19:59:48 <RP> fray: I have other problems atm :/
Sep 27 19:59:58 <RP> fray: all the stray warnings for a start
Sep 27 20:00:42 <JaMa> I can cook patch for bb.utils.explode_dep_versions
Sep 27 20:00:45 <fray> JaMa, is it bitbake having problems -- or deb/opkg?
Sep 27 20:00:52 <fray> if it's deb/opkg.. we should add it to the translation there
Sep 27 20:01:01 <JaMa> fray: bitbake
Sep 27 20:01:06 <JaMa> see that commit message
Sep 27 20:01:22 <fray> then I'd still vote to support w/o spaces (inside of the '(' and ')')
Sep 27 20:01:22 <JaMa> it's not passed to package metadata at all
Sep 27 20:01:33 <fray> odd
Sep 27 20:02:04 <fray> ohh I bet it's using 'split'....
Sep 27 20:02:57 <fray> here is already a defined set of comparison values in one of the explode functions.. we can reuse that and strip them off the front
Sep 27 20:03:25 <fray> JaMa, how do you run the function directly?
Sep 27 20:03:36 <blloyd_> what could I do to make it where 'bitbake core-image-sato' succeeds, but if I do a 'bitbake core-image-sato-dev' immediately after it fails.
Sep 27 20:10:38 <fray>     l = s.replace(",", "").split()
Sep 27 20:10:42 <fray> ya.. it's splitting on spaces..
Sep 27 20:10:53 <JaMa> fray: . ./setup-env (or whatever setup you use) python; inherit bb; run it
Sep 27 20:11:07 <fray> ok.. never tried that before..
Sep 27 20:12:02 <JaMa> <</< and >>/> is easier to replace imho (no need to check if it's >= or just >)
Sep 27 20:13:42 <RP> blloyd_: fails how?
Sep 27 20:16:56 <JaMa> blloyd_: core-image-sato-dev isn't provided?
Sep 27 20:29:12 <fray> JaMa -- inherit bb doesn't work for me
Sep 27 20:29:32 <fray> should I have some environment variable sset?
Sep 27 20:29:40 <JaMa> sorry import
Sep 27 20:29:58 <fray> >>> import bb
Sep 27 20:29:58 <fray> Traceback (most recent call last):
Sep 27 20:29:59 <fray>   File "<stdin>", line 1, in <module>
Sep 27 20:29:59 <fray> ImportError: No module named bb
Sep 27 20:30:08 <fray> it can't find it.. what do I need to do to show it the path?
Sep 27 20:30:31 <fray> (I'm still very much a python newbie)
Sep 27 20:33:02 <JaMa> bb.utils.explode_dep_versions('xserver-xorg (<1.11.2)')
Sep 27 20:33:05 <JaMa> ups
Sep 27 20:33:14 <fray> it's the import bb.. I can't get that to work
Sep 27 20:35:07 <fray> got it to work.. had to change my cwd
Sep 27 20:35:30 <fray> >>> bb.utils.explode_dep_versions('xserver-xorg (<1.11.2)')
Sep 27 20:35:30 <fray> {'xserver-xorg': '< 1.11.2'}
Sep 27 20:35:34 <fray> (after my change)
Sep 27 20:45:18 <msm> RP: the offending /usr/lib/perl5 is included in the manifest
Sep 27 20:48:05 <msm> and clean does remove the offending file
Sep 27 20:48:16 <msm> my best guess is someone ctrl-c'ed in the wrong spot?
Sep 27 20:57:39 <fray> JaMa:
Sep 27 20:57:39 <fray> >>> bb.utils.explode_dep_versions('xserver-xorg (<1.11.2)')
Sep 27 20:57:39 <fray> {'xserver-xorg': '< 1.11.2'}
Sep 27 20:57:39 <fray> >>> bb.utils.explode_dep_versions('xserver-xorg (<1.11.2 )')
Sep 27 20:57:39 <fray> {'xserver-xorg': '< 1.11.2'}
Sep 27 20:57:40 <fray> >>> bb.utils.explode_dep_versions('xserver-xorg (< 1.11.2 )')
Sep 27 20:57:40 <fray> {'xserver-xorg': '< 1.11.2'}
Sep 27 20:57:41 <fray> >>> bb.utils.explode_dep_versions('xserver-xorg ( < 1.11.2 )')
Sep 27 20:57:41 <fray> {'xserver-xorg': '< 1.11.2'}
Sep 27 20:57:48 <fray> there we go.. space agnostic now
Sep 27 20:59:10 <JaMa> good
Sep 27 21:02:24 <fray> JaMa, want me to send the patch to you?  I'd like someone to look at it before I send it to bitbake-devel
Sep 27 21:02:49 <blloyd_> RP: linux-yocto fails to build, requiring perf.so.  But that just built successfully one command above.
Sep 27 21:03:03 <fray> that is very strange
Sep 27 21:03:21 <fray> zedd is likely the one to know more about that, but I don't believe he's here curently..
Sep 27 21:05:03 <blloyd_> I don't have a small change yet to isolate it, but it appears that my custom kernel is only building successfully from a clean build.  As soon as everything builds the first time (all the way to the image), it wants to rebuild and then hands on the missing library.
Sep 27 21:05:34 <blloyd_> *hands -> hangs/fails
Sep 27 21:07:06 <JaMa> fray: only this space agnostic change or also <</< warning/error?
Sep 27 21:08:01 <JaMa> I'm leaving in few minutes so please send it to bitbake-devel and I'll test it tomorrow if possible
Sep 27 21:08:21 <msm> actually, the manifest itself must be wrong, because the file is not getting deleted
Sep 27 21:09:58 <fray> havn't put in a warning yet.. still working..
Sep 27 21:10:00 <fray> ok.. will do
Sep 27 21:22:05 <RP> msm: which manifest?
Sep 27 21:22:15 <RP> msm: ignore master.list, that is now a dead file
Sep 27 21:22:51 <RP> blloyd_: that sounds very strange :/
Sep 27 21:23:16 <RP> blloyd_: are you using some kind of AUTOREV for the kernel?
Sep 27 21:23:30 <RP> blloyd_: Does cleaning it and rebuilding help?
Sep 27 21:23:56 <RP> blloyd_: ah, you confirmed that already
Sep 27 21:24:18 <msm> RP: populate-sysroot - in the failing case it must have missed that symlink in the manfest file
Sep 27 21:24:20 <RP> blloyd_: sounds like something in your custom config of the kernel isn't getting on well with the rest of the system, maybe autorev related...
Sep 27 21:24:29 <blloyd_> not intentionally if I am.
Sep 27 21:24:37 <RP> msm: cleaning it should remove it in that case...
Sep 27 21:25:01 <msm> from sysroot?
Sep 27 21:25:08 <ant__> zeddii: ping
Sep 27 21:25:08 <RP> blloyd_: you have the SRCREVs specified to specific revisions?
Sep 27 21:25:11 <RP> msm: yes
Sep 27 21:25:26 <msm> RP: because of it's presence in the manifest file?
Sep 27 21:25:30 <blloyd_> 'rm -rf cleansstate tmp' followed by 'bitbake core-image-sato' or 'bitbake core-image-sato-dev' seems to work every time.
Sep 27 21:25:35 <RP> msm: I wonder if its dereferencing the symlink or something? :/
Sep 27 21:25:46 <msm> tar?
Sep 27 21:26:05 <RP> blloyd_: what about "bitbake linux-yocto -c clean" or -c cleansstate ?
Sep 27 21:26:09 <blloyd_> RP: I don't override those from the standard bb file, so they should be fixed, right?
Sep 27 21:26:15 <RP> msm: the deletion code
Sep 27 21:26:22 <RP> blloyd_: correct
Sep 27 21:26:26 <msm> RP: 	ahh, it generally works though
Sep 27 21:26:36 <msm> RP: its just sometimes usr/lib/perl5 is not removed
Sep 27 21:26:49 <msm> RP: maybe in the case it's not working it dereferneces it
Sep 27 21:26:52 <RP> msm: I'm open to other ideas...
Sep 27 21:26:53 <blloyd_> I'll do it again, but I'm 99% sure once it breaks only the super rm hammer fixes it again.
Sep 27 21:27:12 <RP> blloyd_: you could also try rm tmp/cache/* -rf
Sep 27 21:27:36 <RP> blloyd_: figuring out a smaller hammer will likely help figure out where the problem is too :)
Sep 27 21:28:25 <msm> RP: slow process, im emailing back and fourth with coworker who has seen the issue
Sep 27 21:29:06 <blloyd_> yup, why I'm asking for help.  Wasn't sure where to go from there.  The kernel fragment basically adds a few kernel config files for the machine, nothing fancy.  But I get this behavior that goes against my understanding of the system (which generally indicates I don't understand the system).
Sep 27 21:31:37 <blloyd_> and to add to I probably don't understand the system, I've seen this behavior on head of master, poky-denzil 7.0.1, and poky-denzil head.
Sep 27 21:33:38 <blloyd_> msm: why is perl5 removed?  Could this be why on first build I get success and later builds are missing a file (perf.so, but logs also mention perl).
Sep 27 21:38:34 <msm> blloyd_: this is related to populate_sysroot
Sep 27 21:38:47 <msm> its trying to copy from staging to sysroot and some file is already there so it fails
Sep 27 21:41:18 <blloyd_> ok, I'm dealing with a file not there, so different problem.  Thanks for explanation.
Sep 27 21:54:31 <blloyd_> RP: I'll try the /cache/ clear as well as recheck that cleansstate doesn't work this evening.  And get back on in the morning.  Afraid I'm about to lose internet.  Thanks for the suggestions.
Sep 27 21:54:50 <RP> blloyd_: np, hope it helps
Sep 27 21:56:58 <blloyd_> I hope it narrows down how sstate can be broken.  I don't mind working around it short term, but to my mind I shouldn't be able to make a command 'bitbake linux-yocto && bitbake -c cleansstate && bitbake linux-yocto' have a success, success, and failure.  (And guess that says cleansstate doesn't work, as that is a test script I ran several tiems trying to figure out what I had done)
Sep 27 21:58:21 <RP> blloyd_: Is this against master?
Sep 27 21:59:39 <RP> blloyd_: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=db82b42cdde211c67e7affb9da3b20b2514a714a might help if you don't have that
Sep 27 21:59:47 <RP> blloyd_: I'm just guessing mind...
Sep 27 22:00:05 <blloyd_> I first hit it in master, switched to poky-denzil 7.0.1, doing most of my testing against poky-denzil head right now
Sep 27 22:01:45 <blloyd_> that would be assuming SRCPV changes, I'm unchanging between.   I can see why you would think that, though.
Sep 27 22:02:33 <RP> blloyd_: As I said, just a random guess as it bares some similarities
Sep 27 22:03:51 <blloyd_> The work-around for that bug is to cleansstate after changing SRCPV (I did hit it before).  But cleansstate isn't working now.
Sep 27 22:04:35 <RP> blloyd_: It also results in the stamp files being inaccurate and not changing when they should, but yes
Sep 27 22:17:52 <msm> RP: seems like that symlink got dereferenced somehow
Sep 27 22:18:18 <RP> msm: hmm, not good
Sep 27 22:18:40 <msm> its quite odd, i build a lot on the same machine
Sep 27 22:19:04 <msm> anyways, its wiped now… i doubt we will see it again for a while
Sep 27 22:21:28 <RP> msm: I'll see if I can find any way to make this happen...
Sep 27 22:23:55 <b1gtuna> Anyone familiar with Yocto Autobuilder? I'm trying to setup my own.
Sep 27 22:28:17 <RP> b1gtuna: You've found the autobuilder repo?
Sep 27 22:35:05 <b1gtuna> RP: I cloned the repo into my machine
Sep 27 22:35:23 <b1gtuna> RP: Trying to set it up with my meta-layers
Sep 27 22:35:34 <b1gtuna> RP: Thoroughly counfused =D
Sep 27 22:36:36 <RP> b1gtuna: You really want pidge...
Sep 27 22:36:54 <RP> b1gtuna: Elizabeth Flanagan
Sep 27 22:37:29 <b1gtuna> RP: ? pidge?
Sep 27 22:37:44 <RP> b1gtuna: She's not online atm
Sep 27 22:38:05 <b1gtuna> RP: oh I seee.
Sep 27 22:38:30 <b1gtuna> RP: Is she usually online?
Sep 27 23:57:27 <msm> RP: apparently it happened to the same guy again, i need to check his sstate-cache now… should be able to tell you more
Sep 27 23:57:34 <msm> RP: err i forgot to mention this is denzil too btw
Sep 27 23:57:40 <msm> RP: not sure if it's occuring on master
Sep 28 00:10:55 <msm> RP: i see what;s going on
Sep 28 00:11:04 <msm> we have a recipe libhugetlbfs that expanded this for some reason
Sep 28 00:11:13 <msm> this = /usr/lib/perl5
Sep 28 00:12:19 <msm> and it's got FILES_${PN}-perl = "${libdir}/perl5"
Sep 28 00:12:35 <msm> RP: maybe we need a warning about ${libdir}/perl5 being a symlink?
Sep 28 00:13:17 <msm> or some sort of dependency on the populate_sysroot steps between the two?
Sep 28 00:21:01 <msm> err or even just add it to DEPENDS since it's not there
Sep 28 00:21:29 <msm> good talk some more lame duck programming, ask khem all about it ;)
Sep 28 01:33:17 <Crofton> anyone have a clue why orc in meta-baryon is ancient?
Sep 28 01:52:59 <mranostay> nobody has updated it?
Sep 28 01:53:05 <mranostay> that would be my guess
Sep 28 01:57:57 <Crofton> someone just updated th elicense
Sep 28 01:58:00 <Crofton> seems wierd
Sep 28 01:58:13 <Crofton> oh well, need to find next plane
Sep 28 02:46:07 <msm> is there a way to easily remove a recipe from all images?
Sep 28 02:46:25 <msm> for example, i want to skip easily enable skipping the QT builds in lsb since they take so long
**** ENDING LOGGING AT Fri Sep 28 02:59:56 2012

**** BEGIN LOGGING AT Fri Sep 28 02:59:56 2012
Sep 28 05:11:27 <khem> msm: well actually it is rubber duck debugging but it usually is lame :)
Sep 28 05:13:47 <msm> khem: heh
Sep 28 06:27:45 * abogani waves all
Sep 28 06:27:49 <abogani> Could Yocto works if I use an Mac OS X as host?
Sep 28 06:27:50 <abogani> Thanks in advance!
Sep 28 07:12:56 <mckoan> good morning
Sep 28 07:14:29 <mckoan> abogani: AFAIK no support for products purchased from grocery :-)
Sep 28 07:49:07 <mertsas_> abogani: I don't think so, but would love it if you could make it work and push it upstream :D Have tried some on lion, but not had time to really do anything about the failures.
Sep 28 08:30:28 <bluelightning> morning all
Sep 28 08:31:46 <mertsas> morning
Sep 28 08:42:56 <mertsas> is there a way to supress warnings for a given package? I have a package which should not populate any packages, and it spits out a lot of warnings about stuff being installed but not shipped. Previously we could do do_package_qa () {} to supress these warnings, but not any more.
Sep 28 09:00:33 <rburton> abogani: not known to work, i'm sure we make some linux assumptions in places, but patches welcome
Sep 28 09:00:40 <bluelightning> mertsas: the easiest way to suppress those warnings is to delete those files in do_install
Sep 28 09:04:38 <mertsas> bluelightning: yeah, thing is, I don't want them in my image, but need the files to be able to compile a package at a later stage, which will be put in the image. I can't put them in FILES_${PN}-native, as they are arm packages. Doesn't seem to be an easy way to remove those warnings :(
Sep 28 09:05:38 <bluelightning> mertsas: so the files are going into the sysroot then?
Sep 28 09:05:55 <mertsas> in the x86-64 sysroot, for native
Sep 28 09:06:46 <mertsas> hmmm... maybe it's just some files it warns about. Shouldn't be put in sysroot if they are not in FILES, should they?
Sep 28 09:08:24 <bluelightning> mertsas: I don't think the staging code looks at FILES at all
Sep 28 09:08:36 <mertsas> ok
Sep 28 09:08:38 <bluelightning> so unpackaged files can still be staged
Sep 28 09:08:41 <bluelightning> hmm
Sep 28 09:09:25 <mertsas> what I do in install is: "cp -pPrf ${S}/* ${D}, and it then puts it in /usr/share in the ${WORKDIR}/image directory
Sep 28 09:11:02 <bluelightning> mertsas: you can do INSANE_SKIP += "installed_vs_shipped" in this instance
Sep 28 09:11:39 <bluelightning> but note to everyone: don't even think about submitting patches to add recipes with this in it ;)
Sep 28 09:12:11 <bluelightning> the best option is almost always to just put the files into an appropriate package; this *might* be an exception
Sep 28 09:13:22 <bluelightning> actually might need to be INSANE_SKIP_${PN}
Sep 28 09:14:00 <mertsas> bluelightning: yeah. it's an ugly way of doing it, but I really can't see a nice way to fix this. Only other way I can see is put every one of the 10 packages or so that I have to do this with into the same recipe. Which would make that recipe a nightmare.
Sep 28 09:14:04 <mertsas> ok
Sep 28 09:15:50 <mertsas> love the name of the skip as well. kind of says it all
Sep 28 09:19:49 <bluelightning> mertsas: it relates to insane.bbclass which handles most of the QA tests
Sep 28 09:23:38 <mertsas> ok, just felt the name told me what I'm doing is so wrong. Worked though, but feel I have to take some time and think of a way to make those recipes less ugly some day.
Sep 28 12:32:47 <otavio> RP: You merged my patch but you did not applied it complete. You left the RCONFLICTS
Sep 28 12:32:58 <otavio> RP: for xserver-xorg
Sep 28 13:14:03 <RP> otavio: I just took what sgw sent me
Sep 28 13:14:06 <RP> otavio:  :/
Sep 28 13:16:26 <otavio> RP: want me to send it?
Sep 28 13:16:51 <RP> otavio: please
Sep 28 13:17:11 <RP> otavio: been busy trying to fix perl once and for all
Sep 28 13:17:32 <otavio> RP: will send it. I ping you
Sep 28 13:24:45 <Crofton|work> bluelightning, why does meta-baryon have such an old orc?
Sep 28 13:25:17 <bluelightning> Crofton|work: parts of it are really in need of cleanup
Sep 28 13:25:45 <Crofton|work> ok :)
Sep 28 13:25:50 <Crofton|work> just thought I'd mention that
Sep 28 13:25:54 <bluelightning> Crofton|work: I'm thinking of just dropping all of the multimedia packages since they're only there to support thumbnailing in mediatomb which is hardly a critical feature
Sep 28 13:26:02 <Crofton|work> I sw a license patch, but it was against something really old
Sep 28 13:27:06 <bluelightning> in fact what I'd like to do is move everything there into OE layers and then combo-layer them back in from there
Sep 28 13:27:28 <Crofton|work> I suspetc orc is in meta-oe already also
Sep 28 13:27:29 <bluelightning> haven't had time to do that yet though
Sep 28 13:27:55 <bluelightning> it is I think, but ultimately it's only there to support ffmpeg which will probably be dropped
Sep 28 13:29:44 <Crofton|work> gnuradio uses orc, which is how I am a little familiar with the versions
Sep 28 13:31:45 <otavio> RP: sent
Sep 28 13:37:21 <bluelightning> Crofton|work: ah, I see
Sep 28 14:22:48 <gotan> hi. question about configure. I'm having trouble where the autoconf is complainaing that there is no c compiler available.
Sep 28 14:24:12 <gotan> the configure script fails, and i do not know how to go about fixing it.
Sep 28 14:25:33 <gotan> according to the googling i've done it seems to be about cross compiling, and not being able to find the right toolchain, so how does that work?
Sep 28 14:36:47 <gotan> or rather any ideas on how to guarentee the toolchain works for a configure script.
Sep 28 14:48:45 <zeddii> gotan. if you have a look at existing recipes in meta, look for the ones that "inherit autotools" the classes that they inherit make sure that the right path, options, etc are passed to configure to have it find the toolchain and configure (most of time), the docs have this and the ways you can pass extra parameters to configure, etc.
Sep 28 15:43:26 <RP> gotan: looking at the config.log file might provide more clues about how its failing
Sep 28 15:46:00 <gotan> @zeddi: I've been doing that. i've also tried the pkg-config to see if that will fix the autoconf problems
Sep 28 15:46:58 <gotan> @RP: i;ve checked it, its something to do with the c compiler - it failed at the test for a c compiler. i've had to stop working on it for the moment though.
Sep 28 15:54:26 <adam__> exit
Sep 28 16:40:26 <b1gtuna> Morning everyone, where does Yocto keep precompiled packages? I'd like to add package repo in my image :)
Sep 28 16:41:10 <RP__> b1gtuna: we don't provide package repos
Sep 28 16:42:16 <b1gtuna> RP__: I see. That's why I couldn't find it. Thanks!
Sep 28 16:49:18 <bluelightning> b1gtuna: you can produce and provide your own package feeds though
Sep 28 16:49:57 <bluelightning> b1gtuna: in fact, for testing you can make the tmp/deploy/(ipk,rpm) into a feed (possibly deb to if that's what you're using)
Sep 28 16:51:43 <b1gtuna> bluelightning: at the moment, it doesn't matter what I use between ipk, rpm and deb. I just want to add a repo source, so the users can have access to as many packages as possible
Sep 28 16:52:03 <b1gtuna> bluelightning: setting up my own package repo is an option, but I can't possibly maintain it at the moment =(
Sep 28 16:53:48 <bluelightning> b1gtuna: there's always the option of using an existing binary distro built on top of OE-Core; angstrom for example
Sep 28 16:53:54 <bluelightning> b1gtuna: depends how much flexibility you need
Sep 28 16:58:00 <b1gtuna> bluelightning: Yes Angstrom repo is what I'm looking into currently. Thanks for the suggestion. I guess I was on the right track
Sep 28 16:58:27 <blloyd_> when bitbake gets in a circular mirror lookup, does it ever respond to a ctrl-c or do I need to hard kill it?  If I have to kill it, it there any extra cleanup required?
Sep 28 16:58:39 <bluelightning> b1gtuna: I would caution against using the angstrom repo with self-built images that do not use the angstrom distro config though
Sep 28 16:59:13 <bluelightning> blloyd_: you should be able to ctrl+c it
Sep 28 16:59:56 <bluelightning> blloyd_: FYI the fix for that bug has now been merged into the denzil branch
Sep 28 17:00:03 <bluelightning> (just today)
Sep 28 17:00:17 <b1gtuna> bluelightning: I see. Dependency issues??
Sep 28 17:01:52 <bluelightning> b1gtuna: it's hard to predict but the angstrom distro config is different from the default OE-Core or Poky distro config, so you can expect there to be subtle and not-so-subtle differences
Sep 28 17:02:05 <bluelightning> in the output
Sep 28 17:02:28 <blloyd_> it is?  Since when?
Sep 28 17:02:52 <b1gtuna> bluelightning: I seee. Appreciate the insight
Sep 28 17:02:55 <blloyd_> (I have bad news for any answer besides this morning)
Sep 28 17:03:18 <bluelightning> blloyd_: about 70 minutes ago :)
Sep 28 17:03:33 <bluelightning> blloyd_: http://git.yoctoproject.org/cgit/cgit.cgi/poky/log/?h=denzil
Sep 28 17:03:36 <blloyd_> goodie.
Sep 28 17:04:00 <bluelightning> along with a bunch of other fixes as you can see
Sep 28 17:04:01 <blloyd_> I had seen the message about the bug fixed.
Sep 28 17:04:12 <bluelightning> that reminds me, I need to resolve a few bugs now
Sep 28 17:05:30 <blloyd_> thank you blueligtning
Sep 28 17:06:07 <bluelightning> np
Sep 28 17:06:46 <blloyd_> That bug marked fixed/resolved and had a 2012-09-14 15:10 UTC last modified date, so I would have assumed it was fixed.  Is there an easy way to find what commit actually fixed a bug when looking in bugzilla?
Sep 28 17:07:01 <blloyd_> fixed [before today].
Sep 28 17:08:57 <blloyd_> I know the ctrl-c handler has a soft and then hard (second ctrl-c).  What issues should I look for when having to do a hard stop.  (Been waiting 10 minutes on the first ctrl-c to end it.)
Sep 28 17:12:09 <blloyd_> thanks, btw, I missed the (just today) you sent earlier.  Not sure how I could be so blind.
Sep 28 17:12:26 <bluelightning> blloyd_: the bug number is normally in the commit message of the commit(s) that fixed the issue
Sep 28 17:12:55 <blloyd_> so search git for the bug id?
Sep 28 17:12:59 <bluelightning> yeah
Sep 28 17:13:32 * blloyd_ goes and starts looking for a new git cheat sheet discussing log browsing
Sep 28 17:14:17 <bluelightning> blloyd_: you may already know this, but you can just do "git log" then press / and type the search term
Sep 28 17:14:36 <bluelightning> (it's output via "less" after all)
Sep 28 17:16:20 <blloyd_> nope, yocto is the first thing I've done anything more than git clone with.  Most projects I've helped with are subversion now.
Sep 28 17:16:35 <blloyd_> (not that I've been much help here yet)
Sep 28 17:18:36 <blloyd> or more aptly, wasn't sure what git log reports across.  Does it span multiple branches?
Sep 28 17:19:15 <evanp> is there a reason ${SYSROOT_DESTDIR}/kernel doesn't get packaged (at usr/src/kernel or something)? wanting that is atypical for embedded, I'll grant you....
Sep 28 17:19:59 <b1gtuna> evanp:
Sep 28 17:20:19 <b1gtuna> evanp: you need to include virtual/kernel in your image
Sep 28 17:21:03 <evanp> b1gtuna: no, not what I meant. I mean I want an rpm/ipkg/deb with a kernel build tree in it that can be used to build an out-of-tree module.
Sep 28 17:21:16 <blloyd> so, I now have three tries on ctrl-c, it's still not exitted.  What is likely to be corrupted if I take the big kill hammer out?
Sep 28 17:22:13 <b1gtuna> evanp: oh i see. Nvm!
Sep 28 17:22:48 <blloyd> include kernel-dev in your image?
Sep 28 17:23:06 <bluelightning> blloyd: just the current branch if no other is specified on the git log command line
Sep 28 17:23:22 <bluelightning> blloyd: should be OK to just kill it
Sep 28 17:25:31 <evanp> in kernel.bbclass there's a PACKAGE_PREPROCESS_FUNCS function that does rm -rf ${PKGD}/kernel\
Sep 28 18:25:58 <fray> found one..
Sep 28 18:26:04 <fray> ValueError: Error, item libgpg-error appeared in dependency string 'libgpg-error (>= 1.10) pkgconfig libgpg-error (= 1.10-r2) eglibc (>= 2.16)' multiple times.  explode_dep_versions cannot cope with this.
Sep 28 18:44:29 <waynr> howdy folks
Sep 28 18:44:37 <bluelightning> waynr: hi
Sep 28 18:44:48 <waynr> i am interested in helping with the yocto project
Sep 28 18:44:55 <bluelightning> awesome!
Sep 28 18:45:29 <waynr> : ) i figure offering to help with documentation or something low-hanging might be a good way for me to learn more about it myself
Sep 28 18:46:22 <bluelightning> well, we welcome help in any area - you could help with the documentation, or there's also a list of janitor jobs to get started with as well
Sep 28 18:46:39 <waynr> okay
Sep 28 18:47:31 <bluelightning> there are bugs marked with the severity "janitor" in the bug tracker and there's this page: https://wiki.yoctoproject.org/wiki/Janitors
Sep 28 18:47:42 <bluelightning> I'm not sure how up-to-date that page is though
Sep 28 18:49:01 <bluelightning> but it's not mandatory to start there, if you see something else you'd like to work on, that would also be fine - might be worth sending out an RFC on the mailing list though
Sep 28 18:50:08 <waynr> looks like the janitors page was last updated May 2011
Sep 28 18:50:24 <bluelightning> ah ok, probably a little old in that case
Sep 28 18:51:24 <bluelightning> I think of those tasks, perhaps the documentation ones haven't been looked at yet
Sep 28 18:53:01 <waynr> okay
Sep 28 18:55:58 <waynr> rewriting bbvars.py to use bitbake sounds useful
Sep 28 18:56:39 <bluelightning> yeah, it's a useful tool to make sure we have all of our variables documented
Sep 28 18:57:07 * fray is way too tired.. I'm making stupid typos in my code
Sep 28 18:57:12 <waynr> so does it only display variables that are not currently documented?
Sep 28 18:58:10 <bluelightning> https://bugzilla.yoctoproject.org/buglist.cgi?list_id=15217&bug_severity=janitors&query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ACCEPTED&bug_status=REOPENED&bug_status=NEEDINFO&bug_status=WaitForUpstream
Sep 28 18:58:40 <bluelightning> waynr: I'm not entirely sure, I have to admit I have not used it myself
Sep 28 19:01:08 <waynr> okay i found bitbake/lib/bb/codeparser.py, does that sound right? aren't recipes kind of a mixture of python and shell script?
Sep 28 19:01:35 <waynr> i ask the second question because in that file i see a PythonParser and a ShellParser
Sep 28 19:02:27 <waynr> erh, that is to say those are the main classes i see
Sep 28 19:04:04 <waynr> i suppose the work of bbvars.py then would be to determine what is shell, what is python, pass those strings to the corresponding parser, and grab the variables from whatever the resulting object is
Sep 28 19:04:22 <waynr> that must happen somewhere in the bitbake code already
Sep 28 19:06:30 <waynr> i don't know if i have time for this while at work :'(, i am supposed to be researching yocto as a candidate for our next build system
Sep 28 19:07:44 <bluelightning> waynr: ah ok, in that case if you haven't already I would suggest just having a go at doing a build, customising it, adding a new recipe etc. - that's probably more worthwhile at this point
Sep 28 19:11:39 <waynr> probably a good idea
Sep 28 19:12:09 <waynr> is there a yocto release cycle?
Sep 28 19:13:24 <waynr> nvm just found FAQ
Sep 28 19:23:00 <blloyd> for all those that put in bug fixes to danzil branch recently: thank you!
Sep 28 19:25:04 <bluelightning> blloyd: I was just talking with scott earlier, there may be a few more to come as well
Sep 28 19:25:14 <bluelightning> (already posted to the mailing list but not yet merged)
Sep 28 19:26:30 <blloyd> I'm checking to see if my problem is resolved by them.  Using my big hammer rm -rf tmp sstate-cache and will see if I end up with the builds first time and just the first time issue after this.
Sep 28 19:27:14 <blloyd> unfortunately, big hammer is SLOW.  (Both for the delete step and in the must rebuild everything stages)
Sep 28 19:27:53 <zenlinux_> blloyd, if you're hoping for the kernel menuconfig fix, that's just missed the timing for my pull request
Sep 28 19:28:13 <zenlinux_> However I'm planning on sending out my next pull request first thing next week, and that will include the menuconfig fix
Sep 28 19:34:31 <blloyd> you talking about where it forces a rebuild after running?
Sep 28 19:38:29 <zenlinux_> blloyd, correct, this was a specific bug that was happening when building the kernel and manually editing the kernel config options
Sep 28 19:40:38 <zenlinux_> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=sgarman/denzil-next&id=48b10173bbecdf5d7adcea027e45114c323de6ec
Sep 28 19:41:01 <zenlinux_> That's one of three required patches for the fix.
Sep 28 19:50:30 <blloyd> zenlinux_: my problem is the kernel rebuilding with NO changes to the kernel.
Sep 28 19:51:00 <zenlinux_> blloyd, oh? Which MACHINE are you building for?
Sep 28 19:51:27 <waynr> i am updating the yocto wiki FAQ to organize it a little differently (i guess if no one likes it they can revert it)
Sep 28 19:51:47 <waynr> but the information i am most interested in and which i want to put on this wiki is concrete release cycle information
Sep 28 19:51:58 <blloyd> my problem is best summarized as 'bitbake core-image-sato && bitbake -c cleansstate linux-yocto && bitbake core-image-sato' from a new build folder builds one and only one sato image.
Sep 28 19:52:12 <waynr> I understand that there is a six month release cycle with a 6 week freeze on the kernel version prior to that
Sep 28 19:52:13 <blloyd> waynr: I'm using a custom machine.
Sep 28 19:52:17 <bluelightning> waynr: https://wiki.yoctoproject.org/wiki/Planning
Sep 28 19:52:26 <waynr> okay maybe i should just linke there
Sep 28 19:52:39 <blloyd> zenlinux_: I'm using a custom machine.
Sep 28 19:52:43 <blloyd> sorry, waynr
Sep 28 19:52:48 <bluelightning> waynr: it is a question we get frequently asked so it should be in there as a question I agree
Sep 28 19:53:37 <blloyd> https://wiki.yoctoproject.org/wiki/Yocto_1.3_Schedule, bad gateway?
Sep 28 19:54:26 <zenlinux_> blloyd, I'm going to make a note of looking into that
Sep 28 19:56:01 <blloyd> zenlinux_, if this doesn't fix the problem, there will be a gemini created, with scripts attached to do exactly my steps to reproduce it.
Sep 28 19:56:59 <bluelightning> halstead: ^^^
Sep 28 19:57:04 <bluelightning> any ideas?
Sep 28 19:59:18 <blloyd> RP gave me suggestions yesterday, which I was trying to see the results of last night.  that's when I hit the new infinite loop bug.  I decided to start 100% clean, so it was even having to redownload  all the files, so none of my broke configuration was used, so it was taking a while.
Sep 28 19:59:32 <halstead> blloyd, bluelightning, Perhaps a PHP problem. I'll have it up in a moment.
Sep 28 20:00:00 <blloyd> np, hal, figured someone just needed to know something had broken.
Sep 28 20:00:01 <bluelightning> halstead: great, thanks
Sep 28 20:01:18 <halstead> Thank you. The php worker pool is returning incorrectly sized headers.
Sep 28 20:02:04 <halstead> But only for that page.
Sep 28 20:02:20 <waynr> https://wiki.yoctoproject.org/wiki/FAQ
Sep 28 20:02:30 <halstead> This probably has to do with the bugzilla integration.
Sep 28 20:02:59 <waynr> uh whoops, i forgot about what "^ " means in mediawiki language
Sep 28 20:03:02 <waynr> will fix
Sep 28 20:04:21 <blloyd> btw, anyone else using massively parrallel builds?  I'm using BB_NUMBER_THREADS = "16" and PARALLEL_MAKE = "-j 16" and was wondering if that might have anything to do with it (tasks not being parallellable and just most people get them serialized because less running in parallel).
Sep 28 20:07:11 <waynr> https://wiki.yoctoproject.org/wiki/FAQ
Sep 28 20:09:02 <zenlinux_> blloyd, that's not massively parallel - our autobuilders run with variables around that
Sep 28 20:09:52 <zenlinux_> I occasionally have access to a 40-core server...now that enables some parallelism. ;)
Sep 28 20:14:54 <msm> hmm, how can I always reparse a recipe?
Sep 28 20:15:48 <waynr> even if the recipe does not change?
Sep 28 20:16:39 <msm> right
Sep 28 20:16:49 <msm> i have a anonymous python function i want to always run
Sep 28 20:17:48 <fray> isn't there an event that if its false causes a reparse
Sep 28 20:17:49 <fray> ?
Sep 28 20:18:05 <msm> fray: hmm, i can search for this
Sep 28 20:18:55 <fray> I'm not sure, I might be thinking of something else.. but I thought it was a setup even of some kind that was fired for each recipe, before parsing..
Sep 28 20:19:10 <fray> if it's false then it reparses.. if it's true to goes through the normal steps
Sep 28 20:20:15 <halstead> https://wiki.yoctoproject.org/wiki/Yocto_1.3_Schedule is back up. I've bypassed the error but have not fixed the root cause. It is in the code for http://www.mediawiki.org/wiki/Extension:Bugzilla_Reports
Sep 28 20:22:55 <blloyd> thanks halstead.
Sep 28 20:23:40 <halstead> blloyd, Thanks for reporting it. Rigth now not all Bugzilla bugs will be displayed in the tables. I'm working on it though.
Sep 28 20:27:23 <blloyd> might I suggest malformed html from the gateway?  (Not escaping the 'input' properly come to mind, as the bad html output can throw a bad gateway by the consumer of the gateway app (mediawiki).  & is a big culprit of this.
Sep 28 20:27:32 <ccssnet> hi all. anyone here happen to be at the design con east 2012 expo in boston? i was talking to someone there that supposidly is a lead dev for yocto. looking to connect. private message prefered
Sep 28 20:28:11 <ccssnet> s/to be/have been/
Sep 28 20:44:28 <fray> ccssnet -- I'm the one who gave the talk at ESC / Design East Boston 2011 and 2012
Sep 28 20:44:56 <ccssnet> ok thanks. i wasnt there for the talk actually
Sep 28 20:45:07 <ccssnet> but i talked to you in person at the intel booth?
Sep 28 20:45:35 <fray> BTW the presentation has been posted: https://wiki.yoctoproject.org/wiki/images/f/fb/DesignEast_Boston_2012.pdf
Sep 28 20:45:47 <fray> It was probably me then
Sep 28 20:46:25 <ccssnet> ok
Sep 28 21:23:05 <b1gtuna> Has anyone bitbaked mplayer2 recently? It fails while fetching libdvdread.
Sep 28 21:24:24 <b1gtuna> i'm on denzil btw
Sep 28 21:30:07 <RP__> halstead: ping?
Sep 28 21:30:21 <halstead> RP__, pong.
Sep 28 21:30:28 <RP__> halstead: I'm seeing errors which would suggest the clocks are badly screwed on the autobuilders :/
Sep 28 21:30:46 <RP__> er, skewed :)
Sep 28 21:30:55 <RP__> but screwed is probably appropriate too :)
Sep 28 21:30:57 <halstead> RP__, Eitehr way.
Sep 28 21:31:15 <halstead> Let's see they are all running ntp but...
Sep 28 21:31:39 <RP__> halstead: this could be iabXX* :/
Sep 28 21:32:36 <b1gtuna> git.debian-maintainers.org seems to be down. This is where libdvdread is hosted
Sep 28 21:32:41 <halstead> RP__, ab10.yp is 2 minutes off.
Sep 28 21:32:59 <halstead> And the timezone is set incorrectly on ab04-ab06.
Sep 28 21:33:15 <halstead> I'll get them all on UTC time and sync ab10.
Sep 28 21:34:13 <RP__> halstead: thanks, that sounds about right for this error. I saw one about 2 minutes off, I did see an older error that was more like a day off too but that doesn't seem to have reoccurred
Sep 28 21:34:22 <RP__> halstead: http://autobuilder.yoctoproject.org:8010/builders/sys940x-noemgd/builds/71/steps/shell_32/logs/stdio in case you're interested
Sep 28 21:34:30 <RP__> (that was the 2 minute one)
Sep 28 21:35:17 <RP__> perhaps the other issue was TZ related
Sep 28 21:37:24 <halstead> RP__, Thanks for the link to the log. AB10 is synced with world time now.
Sep 28 21:38:35 <RP__> halstead: http://autobuilder.yoctoproject.org:8010/builders/fri2-noemgd/builds/208/steps/shell_58/logs/stdio was the other (18574s in the future)
Sep 28 21:38:49 <RP__> halstead: I'm hoping this is from the clock skew ;-)
Sep 28 22:40:37 <blloyd> ok, my problem with do_install_perf isn't fixed.
**** ENDING LOGGING AT Sat Sep 29 02:59:57 2012

**** BEGIN LOGGING AT Sat Sep 29 02:59:57 2012
**** BEGIN LOGGING AT Sat Sep 29 06:04:57 2012
Sep 29 10:26:46 <RP__> halstead: space problems on the autobuilders?
Sep 29 10:27:57 <RP__> blloyd: which problem exactly?
Sep 29 10:28:21 <halstead> RP__,  yes.
Sep 29 10:28:44 <RP__> halstead: looks like the sqlite database is now corrupted too :/
Sep 29 10:29:27 <halstead> RP,  I freed 50GB and I'm provisioning a new partition to split out the downloads.
Sep 29 10:30:04 <halstead> RP__ the sqlite db for packages?
Sep 29 10:30:36 <RP__> halstead: http://autobuilder.yoctoproject.org:8010/builders/nightly-x86-64/builds/671/steps/shell_72/logs/stdio the bb_persist_data.sqlite3 file
Sep 29 10:32:12 <halstead> Does it need to be repaired or can it be regenerated?
Sep 29 10:34:16 <RP__> halstead: Lets move it out the way and see how badly things break...
Sep 29 10:34:58 <RP__> halstead: if its not there, the build should regenerate it. There are some reasons this is bad but we don't have much choice at the moment
Sep 29 18:58:12 <waynr> howdy folks
Sep 29 19:02:29 <waynr> i am about to work on bbvars.py to try to use bitbake to parse recipes for variables rather than regular expressions as per the "janitors" wiki page
Sep 29 19:13:01 <waynr> if anyone has any advice... : D
Sep 29 19:24:12 <waynr> i actually have a question about upstream source location
Sep 29 19:25:30 <waynr> on the FAQ page it states the yocto project only supports one previous release at a time
Sep 29 19:25:46 <waynr> in terms of security fixes that is
Sep 29 19:26:22 <waynr> so suppose a given release is no longer supported, does that mean that the upstream source location will not be updated if it changes?
Sep 29 19:34:57 <waynr> is there a coding style/guidelines for yocto?
Sep 29 19:53:24 <Jake9xx> waynr: you mean do we have regulation how to write recipes?
Sep 29 19:53:53 <Jake9xx> waynr: recipe has some mandatory fields but otherwise I guess you're free to do what you want
Sep 29 19:54:13 <Jake9xx> waynr: the rule in general OSS is that once you publish stuff things get interesting
Sep 29 19:56:36 <waynr> Jake9xx: well i am talking about the scripts/contrib/bbvars.py script
Sep 29 19:57:19 <waynr> https://wiki.yoctoproject.org/wiki/Janitors
Sep 29 19:57:54 <waynr> this page mentions that it is somewhat desirable for the bbvars.py script to use bitbake code to parse recipes for variable counts (in a given meta directory)
Sep 29 20:00:05 <waynr> also, as far as coding guidelines go i guess i will just write it and like you say, see what happens
Sep 29 20:04:57 <Jake9xx> waynr: exactly. world shall teach you
Sep 29 20:19:30 <otavio> I noticed mesa-xlib has been dropped ... how targets with no dri will work?
Sep 29 21:52:11 <waynr> window move right
Sep 29 21:52:19 <waynr> how embarassing
**** ENDING LOGGING AT Sun Sep 30 02:59:59 2012

**** BEGIN LOGGING AT Sun Sep 30 02:59:59 2012
Sep 30 08:19:15 <rburton> otavio: did you really expect mesa-xlib to count as "work"?
Sep 30 11:27:49 <_julian_> hi
Sep 30 11:28:08 <_julian_> thiagoss: have you got gstreamer-1.0 working on raspberry pi in the meantime?
Sep 30 14:57:59 <thiagoss> _julian_: it works, but I'm blocked because I couldn't get alsa/pulseaudio to work on it yet. But the recipes work and install correctly: http://github.com/thiagoss/poky
Sep 30 14:58:05 <thiagoss> Still need to test openmax, though
Sep 30 15:47:24 <_julian_> thiagoss: ah ok. in case of omx output that one could be used for audio as well, couldn't it?
Sep 30 18:51:24 <thiagoss> _julian_: I think so. gst-1.0 has frames/planes paddings/offsets in GstBuffers. I can't see why it wouldn't work
Sep 30 18:53:40 <_julian_> thiagoss: I might give it a try tomorrow
Sep 30 18:54:57 <thiagoss> _julian_: do you have a recipe/task/image that has pulseaudio working? I could use that
Sep 30 18:55:18 <_julian_> thiagoss: no. only using direct audio output through omxplayer so gar
Sep 30 18:55:19 <_julian_> far
**** ENDING LOGGING AT Mon Oct 01 02:59:59 2012

**** BEGIN LOGGING AT Mon Oct 01 03:00:00 2012
Oct 01 07:14:28 <bluelightning> morning all
Oct 01 07:42:53 <mckoan> good morning
Oct 01 07:43:04 <mertsas> morning
Oct 01 07:45:01 <gizero> morning!
Oct 01 08:06:22 <RP__> morning all
Oct 01 08:38:22 <rburton> thiagoss: guacamayo has alsa/pulse/gst0.10 working on poky
Oct 01 09:02:21 <_julian> morning
Oct 01 09:03:05 <_julian> can anyone tell me how to overwrite the kernel cmdline for the rpi-basic-image?
Oct 01 09:53:24 <_julian> where does yocto place the toolchain? for testing it would be handy to be able to build programs manually outside of bitbake
Oct 01 09:56:15 <_julian> or can I point bitbake to use a local source tree instead of a package or git link for a specific package?
Oct 01 09:59:57 <bluelightning> _julian: you can use devshell for testing within the build system
Oct 01 10:00:10 <bluelightning> _julian: otherwise, for an externally usable toolchain, build meta-toolchain
Oct 01 10:01:06 <_julian> bluelightning: ah, devshell sounds interesting. let me try if this is what I need
Oct 01 10:12:21 <_julian> bluelightning: hm, I try to build omxplayer with this, but the build of internal ffmpeg fails because it says gcc can't create executables )c:
Oct 01 10:12:44 <_julian> http://pastebin.com/ZduDAbKx
Oct 01 10:13:04 <_julian> it seems it misses the proper prefix in front of gcc?
Oct 01 10:14:26 <_julian> ah, I have to set HOST I think...
Oct 01 10:15:15 <_julian> hm, still does not help:
Oct 01 10:15:20 <_julian> arm-poky-linux-gnueabi-gcc is unable to create an executable file.
Oct 01 10:15:20 <_julian> C compiler test failed.
Oct 01 10:20:37 <bluelightning> _julian: does your recipe inherit autotools ?
Oct 01 10:22:41 <_julian> bluelightning: yes it does, but right now I try to build manually from the devshell. not thorugh bitbake
Oct 01 10:24:29 <_julian> I just startet a devshell moved into a omxplayer checkout and did a make
Oct 01 10:34:46 <_julian> should HOST be the target host or the build host?
Oct 01 10:41:50 <_julian> tried both. none of them is working
Oct 01 10:43:16 <_julian> I could try the other way round: is it possible to let bitbake build from a local checkout instead of a remote-git repository?
Oct 01 11:33:02 <thiagoss> rburton: great, will look at it :)
Oct 01 11:48:40 <gotan> hi,
Oct 01 13:14:51 <RagBal> Is there a list or guide on how to use MACHINE_FEATURES in a machine config?
Oct 01 13:16:57 <RagBal> Ah wait, I found it already
Oct 01 13:17:29 <RagBal> I was searching for OpenEmbedded MACHINE_FEATURES, but yocto has it nicely on its website. http://www.yoctoproject.org/docs/1.0/poky-ref-manual/poky-ref-manual.html#ref-features-machine
Oct 01 13:49:49 <RP__> fray: ping?
Oct 01 13:53:13 <RagBal> Will it affect my build if I didn't specify touchscreen or screen as machine feature?
Oct 01 13:53:34 <RagBal> startx returns that it can't find a screen
Oct 01 13:53:49 <RagBal> But that was before I build with the extra machine features
Oct 01 13:54:09 <JaMa> did you provide working xorg.conf in your layer?
Oct 01 13:54:42 <_julian> any ideas how to overwrite kernel command line for rpi-basic-image?
Oct 01 13:55:07 <RagBal> I haven't specified a xorg.conf
Oct 01 13:55:40 <RagBal> I just started using this actually, I grabbed a machine config out of the old OE and made it work under new OE-core
Oct 01 13:56:46 <JaMa> RagBal: default xorg.conf probably doesn't work on your device, grap one from oe-classic and add it with .bbappend in your BSP layer
Oct 01 13:58:37 <RagBal> Where can I find the xorg.conf?
Oct 01 14:04:01 <RagBal> JaMa I don't think there's a xorg.conf in OE-classic for my device. http://cgit.openembedded.org/openembedded/tree/conf/machine/ea3250.conf is the device I'm trying to get X to run
Oct 01 14:04:37 <RagBal> I was pretty proud I got a new kernel working with it actually =) But X is a lot more difficult
Oct 01 14:16:19 <RagBal> Or is there any way I can configure it after the system is booted? I can access it with a serial console
Oct 01 15:26:20 <msm> so guys, im seeing this on my old centos build machine again:
Oct 01 15:26:21 <msm> https://gist.github.com/3812492
Oct 01 15:26:28 <msm> this has come and gone, before...
Oct 01 15:27:32 <fray> what is your filesystem?
Oct 01 15:27:54 <fray> we've only had that issue when we do builds on SANS
Oct 01 15:28:12 <fray> they sometimes get really slow and the locking time suffers.. since there is no no relay in retrying the lock
Oct 01 15:37:18 <msm> hmm
Oct 01 15:38:25 <fray> msm:  http://gate.crashing.org/~fray/shadow-native-block-groupadd-and-useradd.patch
Oct 01 15:38:29 <fray> thats the hack we're using
Oct 01 15:38:46 <msm> fray: its ext3
Oct 01 15:38:48 <fray> and it's just that, a nasty hack to deal with delays over SAN, NAS/NFS infrastructure
Oct 01 15:39:26 <msm> this is local
Oct 01 15:39:36 <msm> but, could be the same issue
Oct 01 15:39:41 <fray> we've never seen it locally..
Oct 01 15:39:46 <msm> we are extending the delay a lot since this machine is loaded to the brim
Oct 01 15:39:54 <fray> it's always been on a shared disc, on a build with a large number of builders
Oct 01 15:40:02 <fray> that may be it
Oct 01 15:41:20 <msm> fray: i wonder if i move over to ext4 if some things will improve
Oct 01 15:41:29 <msm> fray: ive had some users of ubuntu (probably in a VM) see the same issue
Oct 01 15:43:44 <msm> fray: do you have that patch in a yocto style patch anywhere?
Oct 01 15:44:07 <fray> nope.. we've got it in our local layer
Oct 01 15:44:26 <fray> we just add it to the SRC_URI in a bbappend
Oct 01 15:45:34 <cristianiorga> RP: Hello
Oct 01 15:48:03 <msm> fray: k, thanks for the help… im going to try some ext3 mount options that should speed things up anyways
Oct 01 15:48:07 <msm>  and see if we can get this error to go away
Oct 01 15:48:37 <msm> given these are all "local" disks
Oct 01 16:11:55 <rburton> should our libpcap depend or not on libnl?
Oct 01 16:14:37 <florr> hi all
Oct 01 16:14:46 <florr> I want to add the glx extension to xserver
Oct 01 16:14:54 <florr> but complains about missing glproto package
Oct 01 16:15:10 <florr> any idea who privides this glproto?
Oct 01 16:16:04 <rburton> the package is cunningly called "glproto"
Oct 01 16:16:06 <florr> nevermind, just found it in xorg-proto
Oct 01 16:16:29 <florr> yeah, I'm a bit tired at the moment
Oct 01 18:05:57 <waynr> exit
Oct 01 18:06:02 <waynr> ...
Oct 01 19:07:34 <msm> fray: what exactly does a multilib SDK have?
Oct 01 19:07:45 <msm> is it multilibs or toolchain too?
Oct 01 19:08:01 <msm> is it the same as just building one of each?
Oct 01 19:40:57 <_julian> hm, any ideas how to achive a system that reads the rootfs from a file (ie squashfs) from a ext-partition on boot? (without loading the whole image as ramfs)
Oct 01 19:50:59 <_julian> or otherway round: how do you deal with in-field updates of yocto-based systems? I think it would be handy to have the whole rootfs in a file for this
Oct 01 19:55:59 <walters> _julian: i think the current primary story is via one of the package systems
Oct 01 19:56:53 <_julian> walters: I kinda dislike that approach, because it gives more options to break things. actually I'd like to have a read-only rootfs, which can only be replaced as a whole.
Oct 01 19:56:56 <walters> _julian: i am working on https://live.gnome.org/OSTree which uses yocto to generate the base system, and attempts to address atomic upgrades
Oct 01 19:59:28 <_julian> walters: just reading, looks interesting
Oct 01 20:01:19 <walters> _julian: but it's really easy to take the rootfs as a tarball and do whatever custom system you want with it
Oct 01 20:01:24 <walters> as i'm doing
Oct 01 20:02:41 <_julian> walters: well my question was more low-level at first place. of course I know how to make a squashfs image out of the tarball. but how would I be able to  use this as root filesystem? I think this requires an intrd, right?
Oct 01 20:03:06 <_julian> because it's actually two-stage mounting. at first mount the partition that contains the rootfs, then mount the rootfs itself
Oct 01 20:03:48 <walters> well i am doing a general purpose system, and for that kind of thing an initramfs is pretty much required
Oct 01 20:04:02 <walters> there's a lot of architectural benefits to having one
Oct 01 20:05:21 <_julian> so then the question raises how to design the initramfs. are there any images in yocto yet that fit in well? (especially when running on a raspi)
Oct 01 20:55:28 <khem> _julian: look at meta-initramfs
Oct 01 20:57:51 <rburton> there's plenty of prior art on swapping rootfs for upgrades
Oct 01 20:58:02 <rburton> olpc/sugar has one that's been deployed
Oct 01 21:00:39 <walters> http://wiki.laptop.org/go/Olpc-update
Oct 01 21:01:24 <walters> TL;DR version: rsync
Oct 01 21:02:49 <_julian> khem: just looking at it. that layer only includes klibc and stuff, right?
Oct 01 21:02:57 <_julian> rburton: taking a look
Oct 01 21:03:25 <fray> msm you still here
Oct 01 21:03:26 <fray> ?
Oct 01 21:04:50 <msm> ya
Oct 01 21:05:23 <fray> single lib SDK -- setup file(s), toolchain and sysroot can only support one target ABI type..
Oct 01 21:05:27 <fray> i.e. ia32..
Oct 01 21:05:48 <fray> multilib SDK -- setu file(s), toolchain and sysroot can support multiple (compatible) ABI types..  i.e. ia32 and x86_64
Oct 01 21:20:22 <khem> fray: I tried the multilib patches
Oct 01 21:20:33 <khem> fray: failed for an unrelated reason
Oct 01 21:20:42 <khem> I have to do it.
Oct 01 21:20:52 <khem> I took whole patchset
Oct 01 21:20:53 <fray> 'k
Oct 01 21:20:56 <khem> I guess I only need few
Oct 01 21:24:17 <khem> fray: I guess I dont need the perl-nativesdk patch anymore do I ?
Oct 01 21:25:24 <fray> nope
Oct 01 21:26:08 <khem> ok
Oct 01 21:28:55 <khem> fray: will meta-toolchain have the 32bit compiler/libs or I have to add lib32-* parts myself
Oct 01 21:45:49 <blloyd> questions about the PR variable.  What exactly is it for?  Why do bbappend files modify it?
Oct 01 21:52:54 <waynr> blloyd, PR is the revision of the package: http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#var-PACKAGE_ARCH
Oct 01 21:54:22 <waynr> i am not as familiar with newer versions of OE/Yocto but at least in OE stable-2009.03 (which is what I am currently most familiar with) this number would get appended to the package's build directory name
Oct 01 21:55:21 <waynr> whenever you run bitbake commands on the package, or attempt to use the package's name to install using ipkg, the latest revision number of the package is used (at least, if the package index is up to date)
Oct 01 21:55:51 <waynr> uh i am going to stop before i start making more confusing statements
Oct 01 21:58:52 <blloyd> so, why would a bbappend modify it?  For instance, yocto_linux_3.0.bbappend's.  Esp since in theory all bbappends are parsed every time, and those bbappends only should affect the build for a given machine.
Oct 01 22:00:04 <JaMa> upgrade path on target
Oct 01 22:00:52 <waynr> because bbappend modifies the package, the package revision ought to reflect this?
Oct 01 22:02:08 <blloyd> so, if we have 4 bbappend files, what's the package version?  1.1.1.1.1 seems kind of messy....
Oct 01 22:02:25 <JaMa> blloyd: that's why they should use PRINC instead
Oct 01 22:02:33 <blloyd> (and that is what it was when I added 4 bsps)
Oct 01 22:02:51 <blloyd> OK, where can I learn about PRINC?
Oct 01 22:03:08 <JaMa> grep other BSP layers for examples
Oct 01 22:03:15 <JaMa> nothing complicated about that
Oct 01 22:03:20 <waynr> http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#customizing-a-recipe-for-a-bsp
Oct 01 22:05:10 <blloyd> ok, my confusion is coming from yocto-bsp produced files again.  Will file another bug against that.  (It doesn't use PRINC.)
Oct 01 22:07:03 <blloyd> and thanks JaMa and waynr
Oct 01 22:07:27 <waynr> :D I learned something too
Oct 01 22:08:17 <blloyd> I note that intel bsps don't use PR or PRINC, which was the other bsps I looked at.
Oct 01 22:09:24 <JaMa> blloyd: check this thread https://lists.yoctoproject.org/pipermail/yocto/2012-September/011354.html (and reply there or include it in bug report)
Oct 01 22:10:52 <blloyd> thanks  have to d/c from net for bit   back later, and will look then
Oct 01 22:42:02 <ag_> Hello.
Oct 01 22:43:11 <ag_> I need a hint. I have 2 layers which both bring a certain recipe. This is identical. And i want to instruct the built to take the recipe from layer 2 if both are in BBLAYER and from and from layer 1 if just layer 1 is in BBLAYER
Oct 01 22:43:22 <ag_> Hopw i made myself clear
Oct 01 22:45:39 <ag_> BBLAYERS*
Oct 01 22:52:25 <ag_> priority doesn't work
Oct 01 22:53:34 <ag_> proffered - can't be used as the name and the version are the same...
Oct 01 22:55:27 <JaMa> try to change order of layer recipes in BBPATH
Oct 01 22:56:32 <JaMa> most layers (layer.conf) are appending to BBPATH, but few don't
Oct 01 22:56:36 <ag_> What do you mean? To have the layer with a bigger priority first?
Oct 01 22:57:27 <bluelightning> JaMa: BBPATH doesn't affect recipes...
Oct 01 22:57:39 <JaMa> right now I'm too sleepy to remember which one affects order of which one
Oct 01 22:57:50 <ag_> pfff
Oct 01 22:58:12 <JaMa> bluelightning: .bbappends, right?
Oct 01 22:59:07 <bluelightning> BBPATH is just for inc / conf / bbclass files
Oct 01 22:59:19 <ag_> Yes.
Oct 01 22:59:42 <ag_> bluelightning: Is there any solution you can think of?
Oct 01 23:01:08 <bluelightning> the best solution would be to not try to support both situations at all - try to have the recipe only in one layer
Oct 01 23:01:14 <bluelightning> (obviously)
Oct 01 23:01:19 <ag_> obviously
Oct 01 23:01:37 <ag_> But right now i can't. Is an internal thing so... i must deal with it.
Oct 01 23:01:53 <ag_> It must be a way... somehow.
Oct 01 23:03:56 <bluelightning> setting layer 2's priority higher would be one way
Oct 01 23:04:16 <ag_> I have those different: 5 and 6.
Oct 01 23:04:18 <ag_> No change.
Oct 01 23:07:03 <bluelightning> ag_: layer 2 has priority 6?
Oct 01 23:07:22 <bluelightning> and why can't you use a bbappend?
Oct 01 23:07:25 <ag_> yes
Oct 01 23:08:07 <ag_> to make long story short: to avoid a layer dependency a recipe was copied in another layer.
Oct 01 23:08:25 <ag_> an append is not possible here.
Oct 01 23:08:41 <ag_> i need to make it work with priorities / bbmask / something
Oct 01 23:08:45 <bluelightning> hmm, well it does kind of sound like you've made a rod for your own back
Oct 01 23:08:48 <chackal_sjc> how to rebuild my entire image ?
Oct 01 23:08:56 <chackal_sjc> without doing a cleanall to all packages ?
Oct 01 23:09:22 <ag_> bluelightning: hmmmm.... i know... so there is no option for this...
Oct 01 23:09:38 <ag_> bluelightning: what about a bbmask in local.conf?
Oct 01 23:10:09 <bluelightning> ag_: of course you can set bbmask but that's not automatic of course...
Oct 01 23:10:33 <ag_> bbmask on what? cause i still want that package. i just want to avoid this error
Oct 01 23:10:52 <ag_> if there is no automatic way (which i don't think it is) a bbmask would be just fine
Oct 01 23:10:55 <bluelightning> ag_: what is the error?
Oct 01 23:11:10 <ag_> Multiple .bb files are due to be built which each provide
Oct 01 23:11:19 <ag_> This usually means one provides something the other doesn't and should.
Oct 01 23:11:32 <ag_> Classics :)
Oct 01 23:12:47 <ag_> Both recipes are named ipcamera and are version 0.1. One from layer1/recipes-graphics/ipcamera/ipcamera.bb
Oct 01 23:12:59 <ag_> another one from : layer2/recipes-graphics/ipcamera/ipcamera.bb
Oct 01 23:13:11 <ag_> ipcamera_0.1.bb*
Oct 01 23:13:25 <bluelightning> hmm, one should be overlaying the other...
Oct 01 23:13:34 <ag_> bingo :|
Oct 01 23:16:43 <ag_> bluelightning: SO i guess bbmask won't help here as well...
Oct 01 23:29:18 <bluelightning> ag_: nothing immediately springs to mind I'm afraid
Oct 01 23:29:27 <bluelightning> gotta get some sleep, night all
Oct 01 23:29:35 <ag_> bluelightning: Thanks. Good night.
**** ENDING LOGGING AT Tue Oct 02 02:59:58 2012

**** BEGIN LOGGING AT Tue Oct 02 02:59:58 2012
Oct 02 06:47:43 <mertsas> I have a systemd service which is started at boot when using the release image. However, when using our dbg image, I don't want it to start it at boot. I tried to add a IMAGE_FEATURE += "dont-start-service" in the dbg-image recipe, and in the recipe that provides the service I had: SRC_URI += ${@base_contains('IMAGE_FEATURES', 'dont-start-service', '', 'myservice.service', d)}
Oct 02 06:47:57 <mertsas> this does not work however, any idea on how to accieve the same?
Oct 02 06:51:18 <bluelightning> mertsas: you can't do that at a recipe level from the image that way, no
Oct 02 06:51:44 <mertsas> ok, damn
Oct 02 06:52:08 <bluelightning> mertsas: either you need to make the service file separate and not install it in the debug image case; or, you need to somehow disable the service at image postprocessing time
Oct 02 06:52:29 <mertsas> ok
Oct 02 06:53:21 <florr> hi, I have a defconfig in a bbappend for a kernel recipe
Oct 02 06:53:42 <florr> problem is I get this:
Oct 02 06:53:43 <florr> DEBUG: Executing python function sysroot_cleansstate
Oct 02 06:53:43 <florr> DEBUG: Python function sysroot_cleansstate finished
Oct 02 06:53:43 <florr> DEBUG: Executing shell function do_configure
Oct 02 06:53:43 <florr> NOTE: make -j 4 oldconfig
Oct 02 06:53:43 <florr>   HOSTCC  scripts/basic/fixdep
Oct 02 06:53:45 <florr>   HOSTCC  scripts/kconfig/conf.o
Oct 02 06:53:48 <florr>   SHIPPED scripts/kconfig/zconf.tab.c
Oct 02 06:53:49 <florr>   SHIPPED scripts/kconfig/zconf.lex.c
Oct 02 06:53:51 <florr>   SHIPPED scripts/kconfig/zconf.hash.c
Oct 02 06:53:53 <florr>   HOSTCC  scripts/kconfig/zconf.tab.o
Oct 02 06:53:57 <florr>   HOSTLD  scripts/kconfig/conf
Oct 02 06:53:59 <florr> scripts/kconfig/conf --oldconfig Kconfig
Oct 02 06:54:01 <florr> *
Oct 02 06:54:03 <florr> * Restart config...
Oct 02 06:54:05 <florr> and then my configure log gets to 6 GB
Oct 02 06:54:05 <mertsas> bluelightning: so in something like a image_do_rootfs_append? where I can delete it?
Oct 02 06:54:07 <florr> and craches
Oct 02 06:54:17 <florr> my kernel bbappend points to a full defconfig
Oct 02 06:54:41 <florr> is there a way with current poky master that in my bbappend I can only point to a kernel fragment config file?
Oct 02 07:03:10 <bluelightning> mertsas: there's a pre-existing mechanism - ROOTFS_POSTPROCESS_COMMAND +=
Oct 02 07:04:23 <bluelightning> florr: if you name your fragment with a .cfg extension it should be treated as a fragment automatically
Oct 02 07:04:45 <bluelightning> florr: what you're describing does sound like a bug though... was the file called "defconfig" ?
Oct 02 07:08:21 <florr> bluelightning: yes it is; but I don't know what to make of it; now I've removed the whole bbappend and still see the issue
Oct 02 07:08:27 <florr> it is with a meta-ti kernel
Oct 02 07:08:45 <florr> changed the recipe to use omap-3.4.0 kernel and the configure log goes nuts
Oct 02 07:18:28 <mertsas> bluelightning: thanks, that was exactly what I was looking for:D
Oct 02 07:20:35 <mertsas> florr: are you using the 3.4 kernel from dev.omapzoom?
Oct 02 07:21:35 <florr> yes
Oct 02 07:23:18 <mertsas> you most likely don't need the whole linux.inc file from meta-ti, it is really big. All we basically do is inherit kernel and siteinfo. and have a SRC_URI and defconfig. We also started with the meta-ti kernel, but removed it in favor of a minimal kernel recipe like that
Oct 02 07:24:36 <mertsas> we have an append on compile_kernelmodules, but other then that we only use what bitbake gives us from kernel and siteinfo
Oct 02 07:24:55 <florr> what kernel version are you sing from dev.omapzoom?
Oct 02 07:24:58 <mertsas> that is using the ti-ubuntu-3.4-1487.2 tag from dev.omapzoom
Oct 02 07:25:00 <florr> using
Oct 02 07:25:11 <mertsas> also used the 1487.10 tag
Oct 02 07:25:17 <mertsas> 1486*
Oct 02 07:25:42 <mertsas> and are using the same inc file for a 3.2 kernel from linaro
Oct 02 07:27:35 <florr> hm, thanks for the info; will try that to see where it would lead me
Oct 02 07:28:10 <mertsas> we stripped it down after we had some issues with the meta-ti kernel if I remember correctly, which we required previously. After looking at it we felt it was bloated, so we did this and our problems at least went away. Don't know if the problems are the same though
Oct 02 07:28:31 <mertsas> hope it helps
Oct 02 07:28:47 <florr> thank you
Oct 02 07:29:00 <mertsas> I can give you our kernel recipes though, so you don't need to use more time than necessary
Oct 02 07:31:08 <florr> that sounds great
Oct 02 07:33:06 <mertsas> http://pastebin.com/YuFymMMV
Oct 02 07:33:35 <mertsas> All you would need with that is possibly change the COMPATIBLE_MACHINE, and use your defconfig
Oct 02 07:34:28 <florr> thanks
Oct 02 07:34:35 <mertsas> no problem
Oct 02 07:34:36 <florr> and what about the kernel modules changes?
Oct 02 07:34:38 <mertsas> hope it works for you
Oct 02 07:34:40 <florr> what did that involve?
Oct 02 07:35:18 <mertsas> those are just to install some sample programs for dce
Oct 02 07:35:41 <florr> I see; probably I won't need that then
Oct 02 07:36:03 <mertsas> all it is is: oe_runmake ${PARALLEL_MAKE} modules samples CC=${KERNEL_CC} LD=${KERNEL_LD} in do_compile_kernelmodules_append
Oct 02 07:36:14 <mertsas> yeah, most likely, if you don't want to test you dce stuff
Oct 02 07:38:36 <mertsas> tell me if you have any problems with it
Oct 02 07:41:13 <florr> will do
Oct 02 07:41:17 <florr> thank you again
Oct 02 07:43:20 <mertsas> no problem
Oct 02 09:09:35 <mertsas> florr: did it solve your problem?
Oct 02 09:14:11 <florr> mertsas: it's in my queue; looking at some other stuff now
Oct 02 09:14:25 <florr> mertsas: will let you know how it went when I get to it
Oct 02 09:18:49 <mertsas> ok, cool
Oct 02 10:59:49 <RagBal> I have a development board (ea3250) wich has a touchscreen on it, I'm able to run Poky on it build with Yocto but I'm unable to get X11 running on it. After startx it returns that there are no screens. It has a framebufer device and the console with penguin apear on the display. Is there a guide or something available wich can help me to run X11 on it?
Oct 02 11:10:03 <mertsas> which graphics driver are you using?
Oct 02 11:10:30 <RagBal> cdcl or something, if I remember correctly
Oct 02 11:11:25 <RagBal> I think it was included in the kernel patch provided on lpclinux.com
Oct 02 11:11:39 <RagBal> One second, I'll try to look it up
Oct 02 11:12:02 <mertsas> ok
Oct 02 11:12:36 <mertsas> might be that it needs an xorg.conf though. At least you will get a message that there are no screens if the xorg.conf is wrong or missing on some cards.
Oct 02 11:14:24 <RagBal> amba-clcd is the driver I think
Oct 02 11:14:47 <RagBal> Yea, I haven't configured the xorg.conf
Oct 02 11:14:57 <RagBal> I have no idea how I should configure it =)
Oct 02 11:16:08 <mertsas> that makes two of us, but that might be a place to look
Oct 02 11:16:16 <mertsas> at least my guess
Oct 02 11:16:32 <RagBal> Ok thank you
Oct 02 11:16:39 <mertsas> no problem
Oct 02 11:18:06 <RagBal> It is a ARM device
Oct 02 11:18:26 <rburton> if fbdev works then you can try the xorg fbdev driver
Oct 02 11:20:24 <RagBal> rburton how do I know if fbdev works? I have a fb0 in my /dev
Oct 02 11:20:37 <rburton> RagBal: if you saw a penguin, fbdev works
Oct 02 11:20:44 <RagBal> Then it works
Oct 02 11:21:20 <RagBal> Do I need to install a specific module for xorg then?
Oct 02 11:21:39 <florr> fbdev maybe?
Oct 02 11:22:24 <RagBal> Sorry I just started working with embedded linux, it's all pretty new to me actually so sorry for my newbness
Oct 02 11:23:53 <florr> xf86-video-fbdev
Oct 02 11:24:17 <florr> you could try compiling that package and use the fbdev_drv that it makes
Oct 02 11:24:35 <RagBal> Cool thank you
Oct 02 11:24:58 <RagBal> And I need to customize and add a xorg.conf to my BSP?
Oct 02 11:25:42 <florr> yes you would need a xorg.conf file
Oct 02 11:25:51 <florr> you could start with a simple one with only the driver section
Oct 02 11:26:15 <RagBal> That would be my first try yest
Oct 02 11:27:57 <ant__> in your-machine.conf you need smthg like
Oct 02 11:27:58 <ant__> XSERVER = "xserver-xorg xf86-video-fbdev xf86-input-keyboard xf86-input-mouse xf86-input-evdev"
Oct 02 11:28:33 <RagBal> Then it will auto compile it with the x package I guess?
Oct 02 11:28:53 <ant__> depends on the image
Oct 02 11:29:00 <ant__> try core-image-sato
Oct 02 11:29:13 <RagBal> Testing with that yest
Oct 02 11:29:17 <RagBal> Great thanks!
Oct 02 12:23:44 <ag_> Anybody around who played a little inside chromium?
Oct 02 12:26:22 <JaMa> meta-browser did
Oct 02 12:48:10 <ag_> I'm looking for the right position in code where the main x11 window is created...
Oct 02 14:17:20 <sgw1> LaurentiuSerban: maybe you can assign someone to start looking into package updating from a feed
Oct 02 14:42:57 <msm> anyone see this: https://gist.github.com/3819680
Oct 02 15:00:30 <rburton> msm: find out why that file is invalid
Oct 02 15:01:07 <davest> YPTM: davest on the call
Oct 02 15:01:26 <Zagor> YPTM: bjorn is here
Oct 02 15:01:31 <bluelightning> YPTM: Paul Eggleton & Belen Barros Pena are on the call
Oct 02 15:01:32 <jzhang> YPTM: jzhang's her
Oct 02 15:01:40 <rburton> YPTM: ross on the call
Oct 02 15:01:44 <sgw1> YPTM: Saul's here
Oct 02 15:01:50 <strassek> YPTM: Kevin Strasser is here
Oct 02 15:02:01 <pidge> YPTM: Beth Flanagan is here
Oct 02 15:02:02 <cristianiorga> YPTM: Cristian Iorga is in the call
Oct 02 15:02:10 <RP__> YPTM: Richard is here
Oct 02 15:02:10 <zeddii> YPTM: Bruce Ashfield is on the call.
Oct 02 15:02:18 <nitink> YPTM: Nitin Kamble is on the bridge
Oct 02 15:02:25 <RP__> pidge: can you look at the licence email on OE-Core please?
Oct 02 15:02:53 <scottrif> scottrif has joined the meeting
Oct 02 15:02:55 <laur> YPTM: LaurentiuP joined
Oct 02 15:03:24 <pidge> RP__: looking
Oct 02 15:03:27 <jmpdelos> YPTM: Jeff Polk joined
Oct 02 15:03:31 <scottrif> YPTM: scottrif joined
Oct 02 15:03:32 <denix> YPTM: Denys finishing another call, will join in a bit
Oct 02 15:04:25 <Song_Liu> YPTM: Please let me know if you have opens
Oct 02 15:06:48 <Song_Liu> https://bugzilla.yoctoproject.org/buglist.cgi?bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_status=NEW&bug_status=ACCEPTED&bug_status=REOPENED&bug_status=NEEDINFO&bug_status=WaitForUpstream&columnlist=short_desc%2Ctarget_milestone%2Cbug_severity%2Cpriority%2Cassigned_to%2Cbug_status%2Cstatus_whiteboard&known_name=All%20Med%2B%20bugs&list_id=15340&priority=Medium%2B&query_format=advanced&target_m
Oct 02 15:08:18 <Song_Liu> https://bugzilla.yoctoproject.org/buglist.cgi?bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_status=NEW&bug_status=ACCEPTED&bug_status=REOPENED&bug_status=NEEDINFO&bug_status=WaitForUpstream&columnlist=short_desc%2Ctarget_milestone%2Cbug_severity%2Cpriority%2Cassigned_to%2Cbug_status%2Cstatus_whiteboard&known_name=All%20Med%2B%20bugs&list_id=15340&priority=Medium%2B&query_format=advanced&target_m
Oct 02 15:08:46 <Zagor> it ends with "&target_"
Oct 02 15:08:47 <dvhart> YPTM: Darren has joined
Oct 02 15:12:40 * moolinex YPTM: Mihai Lindner joined
Oct 02 15:16:35 <pidge> RP__: done.
Oct 02 15:17:03 * zeddii has some Kconfig changes, I'll rush them out.
Oct 02 15:20:27 * rburton back, hope i didn't miss anything about me
Oct 02 15:23:56 <zeddii> what's the number ? on that one ?
Oct 02 15:24:34 <sgw1> RP__: are you going to merged that bblayers change from cons
Oct 02 15:25:48 <msm> rburton: yea, the file is not there
Oct 02 15:26:13 <msm> rburton: nor the entire git repo
Oct 02 15:26:48 <RP__> sgw: I need to look at it again
Oct 02 15:31:10 <rburton> msm: well there's the problem.  presumably it got renamed, or something.
Oct 02 15:31:35 <msm> rburton: this has been happening on rebuilds for u-boot for a while
Oct 02 15:31:39 <dvhart> zeddii, 3186
Oct 02 15:31:40 <msm> not sure why it's even rebuilding
Oct 02 15:31:58 <rburton> msm: rebuilds only? maybe something is deleting that file.
Oct 02 15:32:54 <msm> rburton: the whole git source is not getting deployed properly
Oct 02 15:45:58 <msm> rburton: anyways, i was just curious if someone had seen it
Oct 02 15:51:04 <msm> RP__: did you see my replies to my binutils multiarch patch?
Oct 02 15:52:48 <msm> another fun looking one: https://gist.github.com/3820343
Oct 02 15:52:51 <msm> rpm bus error
Oct 02 15:56:43 <RP__> msm: I did, we should probably merge the patch
Oct 02 15:57:38 <msm> RP__: k, just checking ;)
Oct 02 15:58:44 <Song_Liu> YPTM: thanks for joining the meeting, you guys have a nice day or evening!
Oct 02 15:59:04 <msm> RP__: any comments on the insane.bbclass one?
Oct 02 15:59:10 <msm> ahh, the meeting is still on
Oct 02 15:59:25 <RP__> msm: I am nervous about it and we have the same problem on other archs :/
Oct 02 15:59:45 <msm> RP__: yea, i don't really like that one either
Oct 02 16:00:39 <msm> RP__: perhaps I can just skip that QA in my own kernel recipe?
Oct 02 16:04:21 <RP__> msm: that is another option. I'm probably going to hold off that one until we come up with a better test
Oct 02 16:28:28 <JaMa> does this syntax actually work? TUNE_FEATURES ??= "${TUNE_FEATURES_tune-${DEFAULTTUNE}}"
Oct 02 16:30:36 <JaMa> I've tried to use something similar for ARMPKGARCH ??= "${ARMPKGARCH_tune-${DEFAULTTUNE}}" but outer ${} is not actually expanded causing TUNE_PKGARCH (${ARMPKGARCH_tune-armv5te}te).
Oct 02 16:34:34 <hrw> what is easiest way to run do_package for all packages? cause my world build ended but there are many packages which did not finished all tasks
Oct 02 16:35:08 <JaMa> and it was added by RP in 5f9d56bd64997b93ed7e46c117851002a0556654
Oct 02 16:35:37 <JaMa> hrw: there was buildall task before, but it was removed
Oct 02 16:36:16 <JaMa> hrw: and BB_DEFAULT_TASK = "build" doesn't look like buildall did before
Oct 02 16:36:31 <JaMa> s/look/look to work/
Oct 02 16:36:52 <hrw> ;(
Oct 02 16:40:53 <JaMa> I usually notice this when I build some target, clean WORKDIR in tmpfs (e.g. reboot) and then it tries to run do_package_write_ipk in empty directory :/
Oct 02 16:41:40 <hrw> ;)
Oct 02 16:42:45 <hrw> I created list from stamps/*/*install* and gave it to bitbake
Oct 02 16:43:06 <RP__> hrw: I'm surprised do_package isn't run for everything. Have you an example target which didn't run?
Oct 02 16:43:55 <RP__> JaMa: empty WORKDIR is not supported. I think we've made that really clear...
Oct 02 16:44:02 <hrw> RP__: 'bitbake world -k' was what I called. it had 11K tasks to run but next runs of bitbake called do_package_write_ipk on already built^wcompiled recipes
Oct 02 16:44:08 <RP__> Its why rm_work doesn't simply wipe WORKDIR
Oct 02 16:44:37 <RP__> hrw: something changed. Was there some DATE/TIME dependency for example?
Oct 02 16:44:58 <RP__> hrw: If you find the two stamps, you can do bitbake-diffsigs <sigdataA> <sigdataB>
Oct 02 16:45:09 <RP__> hrw: that will tell you why it felt the need to rebuild
Oct 02 16:45:14 <hrw> RP__: ok
Oct 02 16:47:01 <JaMa> RP__: yes I'm aware of that
Oct 02 16:47:52 <RP__> JaMa: we could probably add something alongside workdir that sstate uses to clearly separate the files I guess
Oct 02 16:49:10 <JaMa> RP__: my workdir has 41G even with rm_work used.. so it's too big for tmpfs
Oct 02 16:50:40 <JaMa> RP__: so I'm aware that I'm doing something unsupported locally, but without OEBasicHash and with buildall it worked quite fine (do_package_write_ipk wasn't reexecuted without PR bump and PR bump caused all tasks to reexecute..)
Oct 02 16:51:45 <RP__> JaMa: we need to do something about disk usage, no question there
Oct 02 16:53:10 <JaMa> RP__: thanks for merging qt, btw
Oct 02 16:53:32 <RP__> JaMa: I will probably get into trouble over it ;-)
Oct 02 16:53:36 <bluelightning> JaMa: thanks for doing all that cleanup, quite an effort :)
Oct 02 16:54:09 <bluelightning> JaMa: FYI I'm going to send the pending patches upstream soon
Oct 02 16:54:24 <hrw> next week I should make cleanup of my hacks/changes and send pull request for oe-core and meta-oe
Oct 02 16:54:27 <JaMa> RP__: so I guess those tune-* changes are already out of question, right?
Oct 02 16:54:38 <RP__> JaMa: yes
Oct 02 16:55:07 <RP__> hrw: keep in mind we're at -rc stage at the moment so those changes won't be going in until we branch
Oct 02 16:55:17 <JaMa> ok then please send some feedback in next cycle :)
Oct 02 16:55:30 <hrw> RP__: sure, but they can get review from people
Oct 02 16:55:40 <RP__> hrw: yes, that is fine
Oct 02 16:56:03 <RP__> JaMa: will do, I'm just trying to concentrate on the release. Too many problems with that alone atm :(
Oct 02 16:58:32 <hrw> building is fun. gcc got one revision commited. 5k tasks to run ;)
Oct 02 17:00:00 <RP__> hrw: you can customise the sstate policy if it bothers you :)
Oct 02 17:02:04 <hrw> for me they may just go - I end work so no need to wait for it
Oct 02 17:03:07 <hrw> complete cmdline is "bitbake 630-names-of-recipes -k" to force it to package everything
Oct 02 17:05:05 <hrw> Currently 8 running tasks (2057 of 9649):
Oct 02 17:05:07 <hrw> ;D
Oct 02 17:05:31 <bluelightning> hrw: er, why not just create a packagegroup recipe?
Oct 02 17:07:28 <JaMa> hrw: even better is to create image with all of them included
Oct 02 17:07:40 <JaMa> hrw: that will test all postinst etc too
Oct 02 17:07:59 <bluelightning> indeed
Oct 02 17:08:45 <JaMa> I'm building such image which installs all .ipk files I have in feed on jenkins..
Oct 02 17:09:37 <hrw> bluelightning: I do not need them at once anywhere. its just kind of random list
Oct 02 17:19:00 <bluelightning> hrw: well, it's entirely up to you :)
Oct 02 17:20:28 <hrw> yep
Oct 02 17:24:25 <hrw> WARNING: The recipe is trying to install files into a shared area when those files already exist. Those files are:
Oct 02 17:24:28 <hrw>    /home/hrw/HDD/devel/canonical/aarch64/build/tmp-eglibc/sysroots/genericarmv8/usr/lib/libpython2.7.so.1.0
Oct 02 17:24:31 <hrw>    /home/hrw/HDD/devel/canonical/aarch64/build/tmp-eglibc/sysroots/genericarmv8/usr/lib/libpython2.7.so
Oct 02 17:24:34 <hrw>    /home/hrw/HDD/devel/canonical/aarch64/build/tmp-eglibc/sysroots/genericarmv8/usr/lib/python2.7/config/Makefile
Oct 02 17:24:37 <hrw>    /home/hrw/HDD/devel/canonical/aarch64/build/tmp-eglibc/sysroots/genericarmv8/usr/include/python2.7/pyconfig.h
Oct 02 17:24:40 <hrw> is it normal or error?
Oct 02 17:26:46 <JaMa> hrw: it's known, see "[poky] New warning" on ML
Oct 02 17:26:49 <hrw> ok
Oct 02 17:26:54 <hrw> time for dinner
Oct 02 17:27:03 <hrw> see you tomorrow
Oct 02 18:21:52 <msm> is there an easy way to do insane_skip for all packages and packages_dynamic?
Oct 02 18:54:05 <msm> does it make sense to have do_split_package inherit INSANE_SKIP bits?
Oct 02 19:09:46 <msm> can I fire an event to run a python function if a variable changse?
Oct 02 19:24:54 <msm> best option seems to just strip the QA test from error_qa
Oct 02 19:25:04 <msm> or rather an option that works
Oct 02 19:25:27 <msm> sgw: i think the last two patches are ok to merge (http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=mattsm/master) i've dropped the other insane.bbclass change
Oct 02 19:26:24 <sgw> msm: Ok, will look at them shortly.
Oct 02 19:28:26 <msm> sgw: no rush on my end ;)
Oct 02 19:28:29 <msm> fray: wrt to http://gate.crashing.org/~fray/shadow-native-block-groupadd-and-useradd.patch
Oct 02 19:28:38 <fray> ya
Oct 02 19:28:47 <msm> i really need a fix that works, im curious how to handle this
Oct 02 19:28:56 <msm> just apply in our own layer?
Oct 02 19:29:00 <fray> workaround is the best I got.. something funky is happening..
Oct 02 19:29:02 <msm> or somehow try to fix globally.. just not sure
Oct 02 19:29:04 <fray> we put that in our own layer
Oct 02 19:29:12 <msm> fray: does it happen on all distros?
Oct 02 19:29:17 <fray> we never found a way to universally fix it, because we never found a cause
Oct 02 19:29:31 <msm> ya, me too...
Oct 02 19:29:38 <msm> is there a bug for this?
Oct 02 19:29:44 <fray> I wasn't involved so I'm not sure the exact distros... but our build enironment contains multiple distros with a SAN/NAS connection..
Oct 02 19:29:58 <fray> Not sure..
Oct 02 19:30:28 <msm> i'd be curious
Oct 02 19:30:35 <msm> i ONLY seem to see this on our CentOS 5.x box
Oct 02 19:31:02 <msm> not SAN/NAS
Oct 02 19:31:15 <msm> maybe start a bug to do some brain dumps on?
Oct 02 19:31:30 <fray> go ahead..  if you open it, I'll point my build people to it
Oct 02 19:33:30 <msm> k
Oct 02 19:43:31 <msm> fray: looks like it's already there 2779
Oct 02 19:47:25 <sgw> fray: any news on your med+ bug (the multilib / -dbg issue)?  You dropped before Song could ask
Oct 02 19:48:14 <msm> can you add http:// to SRC_URI for patches?
Oct 02 19:49:33 <fray> I was able to reproduce it while working on the other stuff this past weekend.. but no progress on finding the cause.
Oct 02 19:50:06 <fray> it was certainly nothing obvious, and the RPM patches I applied din't fix it
Oct 02 19:55:30 <fray> BTW I did find a bug, I need to report..
Oct 02 19:55:37 <fray> enable multilibs..  try to run "bitbake world"
Oct 02 19:55:47 <fray> wait many hours.. and finally cancel it since it didn't do anything.. :P
Oct 02 20:20:58 <sgw> fray: really bitbake world for multilib fails ?  I think I ran this recently along with x32
Oct 02 20:21:05 * sgw gives it a try again!
Oct 02 20:22:14 <fray> doesn't 'fail', it just runs forever
Oct 02 20:22:38 <fray> require conf/multilib.conf
Oct 02 20:22:43 <fray> MULTILIBS = "multilib:lib32"
Oct 02 20:22:44 <fray> DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
Oct 02 20:22:46 <fray> (build for x86_64)
Oct 02 20:23:10 <fray> bitbake world runs forever.. from what I can guess.. each of the multiples is again turned into a multilib, etc.. it gets stuck in a loop
Oct 02 20:23:16 <fray> change th MULTILIBS = "" and the problem goes away..
Oct 02 20:23:32 <sgw> fray: that's what I have also
Oct 02 20:23:45 <fray> revert the change to the multilib.conf file so each thing has to be explicitly listed -- and the problem goes away
Oct 02 20:24:01 <fray> BBCLASSEXTEND_append = " ${MULTILIBS}"
Oct 02 20:24:10 <fray> thats the bad line.. which I think causes the recursion
Oct 02 20:30:55 <fray> which seems very wrong
Oct 02 20:32:28 <sgw> fray: yeah, something is wrong there, I got the same thing
Oct 02 21:31:32 <khem> anyone has some intstruction on booting x86 using initramfs ( a big initramfs )
Oct 02 21:31:48 <khem> using yocto images
Oct 02 21:32:08 <khem> I am looking for if someone has experience doing it
Oct 02 21:43:54 <RP__> sgw, fray: I have a lead on this world problem...
Oct 02 21:44:11 <sgw> RP__: great!
Oct 02 21:46:34 <sgw> RP__: BTW, I have a reproducible configure whitespace problem, krb5 seems to think CC and CPP have changed during it's do_configure, the only difference I see is whitespace and I can do a cleansstate and make it happen again!
Oct 02 21:47:01 <RP__> sgw: whitespace will make a difference
Oct 02 21:47:07 <RP__> sgw: have you the exact error?
Oct 02 21:47:14 <mranostay> save the spaces!
Oct 02 21:49:31 <sgw> http://pastebin.com/XemwB79W
Oct 02 21:50:33 <RP__> sgw: when you say make it happen again, what do you mean?
Oct 02 21:51:12 <sgw> I can reproduce it at will, bitbake -c cleansstate krb5; bitbake -c configure krb5 will reproduce it.
Oct 02 21:54:05 <RP__> sgw: I think krb5 must be doing something odd with the variables to lose whitespace
Oct 02 21:55:33 <sgw> RP__: yeah, not sure why I am starting to see this, I am going to continue to dig
Oct 02 22:09:34 <RP__> sgw: can you see if http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t1&id=22373ab2afec616e1f3ec76e4fa8699635e2ba5f fixes your multilib problem?
Oct 02 22:09:42 <RP__> sgw: I have a similar fix for meta-qt3
Oct 02 22:09:57 <RP__> sgw: just disable meta-qt3 to test
Oct 02 22:10:14 <RP__> bluelightning: not sure if your around but I'm breaking qt4 ;-)
Oct 02 22:10:28 <RP__> er, I mean fixing of course
Oct 02 22:12:05 <JaMa> what's wrong with it?
Oct 02 22:12:39 <RP__> JaMa: circular dependencies with multilib
Oct 02 22:13:11 <JaMa> ah nothing related to my changes :)
Oct 02 22:13:40 <RP__> JaMa: no :)
Oct 02 22:15:00 <JaMa> RP__: btw those DEPENDS_prepend are hard to remove later http://lists.linuxtogo.org/pipermail/openembedded-core/2012-September/029407.html so this QT4EDEPENDS could be usefull elsewhere too
Oct 02 22:15:35 <RP__> JaMa: right :)
Oct 02 22:20:28 <bluelightning> RP__: ?
Oct 02 22:23:15 <bluelightning> RP__: ah I see what you did there, your fix is much better than the original :)
Oct 02 22:23:53 <RP__> bluelightning: You're ok with it and a corresponding change to qt3?
Oct 02 22:24:23 <bluelightning> RP__: I haven't seen it but if it's of a similar nature, absolutely
Oct 02 22:24:37 <RP__> bluelightning: as JaMa points out, this probably has other uses too
Oct 02 22:24:51 <bluelightning> right
Oct 02 22:25:01 <bluelightning> FWIW that code is ancient...
Oct 02 22:25:20 <JaMa> I've already fixed my use case, but maybe someone else will find some more :)
Oct 02 22:25:22 <bluelightning> (not to imply it doesn't need fixing, of course)
Oct 02 22:25:24 <RP__> bluelightning: I was amused that qt3, qt4 and qt4e each had a different way of doing it
Oct 02 22:25:29 <RP__> and they all broke
Oct 02 22:26:44 <bluelightning> RP__: they're all very similar though...
Oct 02 22:27:46 <RP__> bluelightning: right, the subtle differences were just interesting
Oct 02 22:31:35 <Crofton|work> If meta-yocto was called meta-poky, things would make more sense
Oct 02 22:34:15 <hollisb> Crofton|work: yeah, the labels are unfortunately confusing
Oct 02 22:38:38 <dvhart> anywone here familiar with how wpa_supplicant is meant to be spawned when used with connmand?
Oct 02 22:38:51 <dvhart> erm s/anywone/anyone/
Oct 02 22:39:16 <dvhart> I currently have to start it manually or the wifi config doesn't appear
Oct 02 22:39:39 <dvhart> I'm wondering if this is a regression in the connman package or if we somehow dropped an init script to start wpa_supplicant before connman
Oct 02 22:44:01 <RP__> Crofton|work: In many ways I wish I'd renamed it when I did the layer split...
Oct 02 22:53:11 <bluelightning> dvhart: it's done via dbus activation I think
Oct 02 22:53:47 <dvhart> I was suspecting so - I'm reverting the last two wpa-supplicant patches - one of which seems dbus related
Oct 02 22:54:57 <bluelightning> dvhart: is there an /etc/dbus-1/system.d/wpa_supplicant.conf and if so what are its permissions?
Oct 02 22:55:25 <bluelightning> if its permissions are set to allow writing for anyone except root I think dbus will ignore it
Oct 02 22:55:35 <dvhart> doh, I had just power cycled
Oct 02 22:55:41 <dvhart> one moment
Oct 02 22:56:52 <dvhart> root@fri2:~# ls -la /etc/dbus-1/system.d/wpa_supplicant.conf
Oct 02 22:56:52 <dvhart> ls: /etc/dbus-1/system.d/wpa_supplicant.conf: No such file or directory
Oct 02 22:56:52 <dvhart> root@fri2:~# ls -la /etc/wpa_supplicant.conf
Oct 02 22:56:52 <dvhart> -rw-------    1 root     root           113 Oct  2 19:31 /etc/wpa_supplicant.conf
Oct 02 22:57:37 <dvhart> aha, there is a dbus-wpa_supplicant.conf in that dir
Oct 02 22:57:58 <dvhart> root@fri2:~# ls -la /etc/dbus-1/system.d/dbus-wpa_supplicant.conf
Oct 02 22:57:58 <dvhart> -rw-r--r--    1 root     root          1232 Oct  2 19:31 /etc/dbus-1/system.d/dbus-wpa_supplicant.conf
Oct 02 22:58:06 <dvhart> only root can write
Oct 02 22:59:33 <sgw> RP__: sorry had a call to deal with, back now looks like that qt4 patch fixes the multilib issue
Oct 02 23:03:50 <dvhart> bluelightning, sgw, reverting the last two wpa-supplicant patches fixed the connman wireless bug
Oct 02 23:03:58 <dvhart> going to figure out which one now
Oct 02 23:04:55 <bluelightning> dvhart: ok, I'm not sure the filename is significant, so that should be OK; I guess you've already found that the fault lies elsewhere
Oct 02 23:05:53 <dvhart> bluelightning, not necessarily:
Oct 02 23:05:54 <dvhart> 0baa071 wpa-supplicant: fix paths in dbus/systemd *.service files
Oct 02 23:05:54 <dvhart> 4f2da78 wpa-supplicant: upgrade to 1.0
Oct 02 23:06:02 <dvhart> those are the two I reverted
Oct 02 23:06:16 <dvhart> so the dbus service file could be the issue
Oct 02 23:06:41 <bluelightning> hmm, ok
Oct 02 23:07:10 <dvhart> really hoping it isn't the upgrade to 1.0 :-/
Oct 02 23:16:16 <xxiao> msm: yes it was me on the perl-perl5 symlink thing, i had to change libhugetlbfs.bb to rename perl5 to perl to fix it
Oct 02 23:16:51 <msm> xxiao: the real fix is just to make it depend on perl i think
Oct 02 23:17:48 <xxiao> msm: maybe, i'm struggling with a broken 5040 board so no time to really check into that yet
Oct 02 23:23:34 <dvhart> boooo - it's the 1.0 update
Oct 02 23:26:15 <bluelightning> dvhart: :(
Oct 02 23:26:38 <dvhart> moar testing please
Oct 02 23:27:35 <sgw> dvhart: thanks for chasing that down, we will have to get rburton and cristianiorga involved
Oct 02 23:28:36 <dvhart> I'll keep ogling until soccer, then it's on them ;-)
Oct 02 23:28:57 <dvhart> and then I have to start doing all that other work I mentioned booking the day with this morning
Oct 02 23:29:01 <dvhart> doh
Oct 02 23:31:14 <sgw> dvhart: put what you know in the bug, I might dig into it also if I can get my image to build again!
Oct 02 23:31:30 <dvhart> yeah, the bug is completely current
Oct 02 23:31:39 <dvhart> it's been my twitter feed for the day ;-)
Oct 02 23:32:10 <sgw> dvhart: here's my failure:
Oct 02 23:32:16 <sgw>  Multiple matches for busybox:
Oct 02 23:32:16 <sgw> | unable to find package busybox
Oct 02 23:32:16 <sgw> | ERROR: some packages were missing
Oct 02 23:32:29 <dvhart> haha
Oct 02 23:32:31 <dvhart> that's a nice one
Oct 02 23:32:47 <dvhart> there's too many, wait there's none, ok well, some aren't there
Oct 02 23:32:50 <dvhart> say what now?
Oct 02 23:33:16 <dvhart> sgw, possible mismatched poky/intel releases and mismatched busybox bbappends?
Oct 02 23:33:22 <sgw> yeah think!  So question for you is it possible to build 2 fri2 images in the same build area (emgd/non-emgd)?  I think that's what's causing me greif
Oct 02 23:33:51 <bluelightning> that sounds like an error from rpmresolve
Oct 02 23:33:59 <dvhart> should be fine.
Oct 02 23:34:09 <dvhart> certainly no difference to busybox
Oct 02 23:34:29 <sgw> that was my thinking also
Oct 02 23:35:09 <sgw> I am going to try something tricky (silly), rebuild ipk instead of rpm of just one target and see what happens.
Oct 02 23:35:24 <dvhart> that is how I build
Oct 02 23:35:38 <sgw> ah maybe you should try an RPM!
Oct 02 23:35:44 <dvhart> pffff
Oct 02 23:37:14 <bluelightning> not a particularly useful error I'll admit; after the "multiple matches" it's supposed to print the list; I can't see how it couldn't have looking at the code
Oct 02 23:37:40 <bluelightning> the "unable to find package busybox" would be more correct if it said "unable to resolve package busybox", that would make slightly more sense
Oct 02 23:39:16 <bluelightning> oh, wait, now I see it
Oct 02 23:39:47 <bluelightning> it's sending the package origin to the output file instead of stderr, which is wrong
Oct 02 23:40:29 <sgw> bluelightning: so where should I look?  In the temp/log....
Oct 02 23:41:23 <bluelightning> sgw: the output file will be in ${target_rootfs}/install/base_archs.pkglist
Oct 02 23:41:41 <bluelightning> or ml_archs.pkglist for multilib
Oct 02 23:42:08 <bluelightning> I can fix how the error is reported if you like, it won't get you past the failure though
Oct 02 23:42:19 <sgw> it's gone already since I did an ipk build, let me get this to finish so I can help dvhart out then I will rebuild the rpm version.
Oct 02 23:42:36 <sgw> bluelightning: that would probably be appropriate
Oct 02 23:42:55 <bluelightning> ok, I'll put together a patch tomorrow
Oct 02 23:43:02 <sgw> thanks
Oct 03 00:09:53 <dvhart> sgw, ok, I'm done for a bit
Oct 03 00:10:15 <dvhart> dinner/soccer/budget meeting/aforementioned work - then see you in the A.M.
Oct 03 00:10:20 <sgw> dvhart, I will review the bug, I have working build again!
Oct 03 00:11:27 <dvhart> small victories :-)
Oct 03 00:42:50 <msm> xxiao: what's not working?
Oct 03 01:58:33 <xxiao> msm: a new fman ucode broken 10G PHY
Oct 03 01:58:43 <xxiao> s/broken/broke/
Oct 03 01:59:09 <msm> you might ping on #mklinux
Oct 03 01:59:21 <msm> xxiao: ^
Oct 03 02:00:59 <xxiao> yeah waiting for hw team , they fixed one issue, and broke more
Oct 03 02:50:53 <blloyd> I have a workspace that at one time was located at $HOME/workspace.  This workspace was checked into svn and later checked out to $HOME/workspaces/{projectname}.  Works fine except that .metadata/.plugins/org.eclipse.cdt.ui/{projectname}.build.log is still produced under $HOME/workspace.  How can I fix that path?
Oct 03 02:51:49 <blloyd> technically, the project in the workspace was what was checked in/checked out into a new workspace, but anyways I can't find where the original path is from.  Any suggestions?
**** ENDING LOGGING AT Wed Oct 03 02:59:59 2012

**** BEGIN LOGGING AT Wed Oct 03 02:59:59 2012
Oct 03 03:03:05 <blloyd> sorry, wrong channel for that.
Oct 03 03:52:04 <evanp> sigh. SDK_ARCH=i686 SDK_OS=mingw32 was too much to hope for....
Oct 03 04:36:34 <matthias____> hello
Oct 03 04:38:16 <matthias____> I have a question about the remote debugging
Oct 03 04:38:55 <matthias____> anyone?
Oct 03 05:19:16 <matthias_overo> hello
Oct 03 07:27:19 <mckoan> good morning
Oct 03 08:22:12 <gizero> morning all!
Oct 03 08:23:06 <_julian> morning
Oct 03 08:23:14 <_julian> ping ag_
Oct 03 08:23:29 <gizero> do you know of any available schedule for Yocto Project Developer Day at ELCE in Barcelona?
Oct 03 08:46:14 <hrw> thx for reminding
Oct 03 09:26:36 <bluelightning> morning all
Oct 03 09:26:42 <hrw> hi bluelightning
Oct 03 10:11:25 <ag_> bluelightning: Cheers
Oct 03 10:12:17 <_julian> ag_: have you had a look at my reworked patchset?
Oct 03 10:13:19 <ag_> _julian: Let the weekend come for that. I have a VERY busy week now. Hope it can be put on hold.
Oct 03 10:15:13 <_julian> sure, I have it in my local tree so everything's fine. just wanted to be sure you saw it
Oct 03 10:15:58 <_julian> hm, I think I read of an image option to check for read-only compatibility somewhere. can't find it anymore right now. any hints for me?
Oct 03 10:32:10 <RP__> gizero: I think its close to being finalised but its not published yet
Oct 03 10:33:56 <JaMa> RP__: morning, have you changed your mind about PE in kernel image name in deploy?
Oct 03 10:34:31 <JaMa> RP__: and can we get those do_rootfs vardepsexclude in?
Oct 03 10:34:48 <RP__> JaMa: I'm not doing it before release as it could easily break the autobuilder and release scripts
Oct 03 10:35:00 <RP__> JaMa: I'm still not 100% sure we need PE in the kernel image name
Oct 03 10:35:12 <RP__> JaMa: This is the DATETIME thing?
Oct 03 10:35:24 <JaMa> yes
Oct 03 10:35:40 <JaMa> and PE is only in kernel name with version, not in the link to latest
Oct 03 10:36:28 <RP__> JaMa: I am not changing output names at -rc3 before a release
Oct 03 11:25:59 <gizero> RP__:  thank you! Looking forward to see it! ;-)
Oct 03 11:58:45 <JaMa> RP__: do we need ${S} in do_package or is ${D} enough? I'm thinking about adding ${S} cleanup to rm_work between do_install and do_package (would help a lot with WORKDIR space usage
Oct 03 11:59:17 <RP__> JaMa: ${S} isn't needed, I thought rm_work removed that
Oct 03 11:59:34 <RP__> JaMa: ah, you mean remove it earlier
Oct 03 12:01:04 <JaMa> yes
Oct 03 12:01:12 <JaMa> before do_package is executed
Oct 03 12:01:51 <JaMa> because do_package takes a lot of space (and twice as much with sstate package creation enabled)
Oct 03 12:02:14 <RP__> JaMa: We could always try and improve that
Oct 03 12:02:22 <RP__> but I guess hacking around the issue and deleting stuff is "easy"
Oct 03 12:03:04 <JaMa> for qt4 I alwasy had to delete {S} befor do_package is executed in my 16G tmpfs.. so making it automatic with rm_work would be nice
Oct 03 12:03:57 <JaMa> and it works for me, just not sure if that feature to pack source for debug is using S or D (afaik those files are not part of D)
Oct 03 12:14:19 <rburton> JaMa: building in a huge tmpfs?  i'm curious as to the performance increase there.
Oct 03 12:18:47 <jackmitchell> JaMa: ditto, ram is cheap these days...
Oct 03 12:19:44 <JaMa> rburton: I've sent my benchmarks some time ago, try to find "sstate.bbclass: allow to disable sstate package creation" patch on ML
Oct 03 12:20:14 <JaMa> I'm retesting this patch right now btw with bigger image
Oct 03 12:21:16 <JaMa> RP__: I still don't get why we keep that package* dirs in workdir when we can recreate them from just created sstate package (like we do when building from sstate-cache after removing tmpdir)
Oct 03 12:22:27 <JaMa> it could be less effective (all tasks would need setscane first) but we can remove it with rm_work only when some option like RM_WORK_REALLY_ALL is set
Oct 03 12:31:30 <RP__> JaMa: I know we can recreate them, its the actual "running the creation code at the right times" which is the hard bit
Oct 03 12:32:24 <RP__> JaMa: rather than use a large tmpfs, use ext4 on a dedicated partition and set commit=10000 or similar
Oct 03 12:32:40 <RP__> JaMa: You should find it works about the same speed but doesn't have space issues
Oct 03 12:33:08 <rburton> hm, i should try changing commit
Oct 03 12:33:31 <_julian> hm, any tips how to deal with populate-volatile on read-only rootfs? actually some parts can be solved by just using a tmpfs for /var/volatile. but creating links for /etc/resolv.conf, etc. obviously won't work...
Oct 03 12:33:59 <JaMa> RP__: I've tried already on dedicated raid0 on 3 disks and tmpfs is still faster
Oct 03 12:38:54 <JaMa> bluelightning: now with last issues with xserver-xorg-module-exa, would you add RCONFLICTS/RREPLACES to buildhistory data?
Oct 03 12:40:12 <bluelightning> JaMa: yes I think so
Oct 03 12:40:34 <bluelightning> also, does RPROVIDES actually make it into the final package?
Oct 03 12:40:44 <RP__> bluelightning: yes
Oct 03 12:40:56 <bluelightning> right, I guess we probably ought to be including that as well
Oct 03 13:26:45 <_julian> ag_: is systemd usable with meta-raspberry? I have it in BBMASK, but am unsure if that is really needed anymore...
Oct 03 13:41:13 <JaMa> rburton: xorg drivers sometimes fails to build when xorg-xserver is reused from sstate-cache
Oct 03 13:41:16 <JaMa> 11:56 < JaMa> what could cause pkg_cv_XORG_CFLAGS -> XORG_CFLAGS in config.log like this: http://pastie.org/4700673, I had to cleansstate virtual/xserver to get input/video drivers building again
Oct 03 13:41:20 <JaMa> 11:56 < JaMa> and xorg-server.pc seems the same
Oct 03 13:41:43 <JaMa> it doesn't happen always, but on one host I got this for 3rd time
Oct 03 13:42:25 <JaMa> actuall error will look like this:
Oct 03 13:42:27 <JaMa> | pnp.c:27:25: fatal error: xorg-server.h: No such file or directory
Oct 03 13:42:44 <JaMa> and all drivers included in my image fail:
Oct 03 13:42:45 <JaMa>   /var/lib/jenkins/jobs/shr-core/workspace/shr-core/openembedded-core/meta/recipes-graphics/xorg-driver/xf86-input-mouse_1.7.2.bb, do_compile
Oct 03 13:42:48 <JaMa>   /var/lib/jenkins/jobs/shr-core/workspace/shr-core/openembedded-core/meta/recipes-graphics/xorg-driver/xf86-input-keyboard_1.6.1.bb, do_compile
Oct 03 13:42:51 <JaMa>   /var/lib/jenkins/jobs/shr-core/workspace/shr-core/meta-openembedded/meta-oe/recipes-graphics/xorg-driver/xf86-video-glamo_git.bb, do_compile
Oct 03 13:42:54 <JaMa>   /var/lib/jenkins/jobs/shr-core/workspace/shr-core/openembedded-core/meta/recipes-graphics/xorg-driver/xf86-input-evdev_2.7.0.bb, do_compile
Oct 03 13:43:06 <JaMa> cleansstate of xserver works
Oct 03 13:59:22 <rburton> how strange
Oct 03 14:31:18 <mertsas> is it possible to use a specific toolchain for a specific package? And use the internal toolchain for every other package?
Oct 03 14:42:07 <hrw> mertsas: it was possible in OE classic. no idea about OE-Core
Oct 03 14:59:22 <mertsas> ok
Oct 03 15:04:47 <dvhart> rburton++
Oct 03 15:04:59 <rburton> dvhart: works?
Oct 03 15:05:21 <dvhart> yup, patch acked
Oct 03 15:05:24 <rburton> wo
Oct 03 15:05:24 <dvhart> thank you kindly
Oct 03 15:05:35 <dvhart> \o/ for testing patches
Oct 03 15:06:53 <dvhart> afk for a bit
Oct 03 17:01:28 <khem> runqemu does not setup the image to get its ip using dhcp and if I change that it does not work either. in classic/OE the runqemu scripts in contrib could bridge the eth0/1 on host and let qemu machine talk out
Oct 03 17:01:47 <khem> is there some way to achieve same with current runqemu without hackery
Oct 03 17:02:43 <khem> currently, I can talk to VM  from host its running on but not from other machines on the network
Oct 03 17:03:22 <khem> I would like to hear if someone has done something in this area
Oct 03 17:07:10 <khem> btw pidge bzip lic changes are now yielding
Oct 03 17:07:11 <khem> WARNING: bzip2-native: No generic license file exists for: bzip2 in any provider
Oct 03 17:07:11 <khem> WARNING: bzip2: No generic license file exists for: bzip2 in any provider
Oct 03 17:07:11 <khem> WARNING: busybox: No generic license file exists for: bzip2 in any provider
Oct 03 17:07:28 <khem> so I guess we need something in common-licenses ?
Oct 03 17:21:09 <davest> darknighte: ping
Oct 03 17:22:00 <davest> darknighte: ping
Oct 03 17:25:19 <Crofton|work> obviously, the darknighte is sleeping after a long night of fighting crime
Oct 03 17:30:48 <hrw> bye
Oct 03 17:55:38 <davest> Crofton|work: I couldn't see my lines show up in my IRC client, thought it wasn't working. (no, just scrolled out of view. Oy)
Oct 03 18:07:56 <khem> pidge: WARNING: bzip2-native: No generic license file exists for: bzip2 in any provider
Oct 03 18:11:14 <pidge> khem: I'll look at it.
Oct 03 18:12:45 <pidge> khem: ah, I see. I forgot to push a commit
Oct 03 18:16:19 <khem> pidge thx
Oct 03 18:52:26 <Crofton|work> RP__, you around
Oct 03 19:33:33 <michael_e_brown> I have what I hope is not a silly question: I am porting a firmware over to yocto (denzil) and have my image based on core-image-minimal as we have some very restrictive size limitations (48MB). I'd like to try to get systemd in as the startup manager, though. What is the best way to get a minimal system startup added to core-image-minimal?
Oct 03 19:37:52 <michael_e_brown> I'm going to port to yocto 1.3 in november after it's released.
Oct 03 19:38:40 <michael_e_brown> I'm not really seeing much in the way of documentation relating to the overall process of pulling in systemd
Oct 03 19:43:43 <ag_> Good night ppl
Oct 03 19:44:01 <ag_> Or good they or other ppl :)
Oct 03 20:29:10 <evanp> michael_e_brown: grep for VIRTUAL-RUNTIME_init_manager, pretty sure it's relevant
Oct 03 20:47:12 <michael_e_brown> it looks like 1.2 doesn't have systemd yet, and I'm trying to puzzle out how this is supposed to fit together in 1.3.
Oct 03 20:47:33 <michael_e_brown> thanks, evanp I apparently was grepping for the OE equivalent of that and not finding anything
Oct 03 20:48:32 <khem> michael_e_brown: systemd is present as a layer
Oct 03 20:49:05 <khem> its not included in as reference init system yet which still is good ol sysvinit
Oct 03 20:53:49 <michael_e_brown> khem, I'm seeing refs to meta-systemd, references which say that meta-systemd is deprecated, and references to a layer in meta-oe
Oct 03 20:54:16 <michael_e_brown> khem, which is the correct one to pull in to get system for (a) denzil (which I'm currently on) and (b) 1.3 when it's released?
Oct 03 20:54:22 <michael_e_brown> *systemd
Oct 03 20:55:13 <michael_e_brown> I've been reading tons and tons of mailing list posts trying to figure out what is the most recent good info and am a bit confused
Oct 03 20:56:17 <khem> from meta-openembedded
Oct 03 21:01:17 <michael_e_brown> khem, so, poky + https://github.com/openembedded/meta-oe  'meta-systemd'. Thanks, I will take a look. It says it depends on openembedded-core, so does that mean I'll have to have poky, oe-core, and meta-oe?
Oct 03 21:05:55 <khem> well it does not need meta-oe
Oct 03 21:06:05 <khem> but you need to clone meta-openembedded repo
Oct 03 21:07:41 <michael_e_brown> so are 'meta-oe' and 'meta-openembedded' different repos?
Oct 03 21:08:14 <michael_e_brown> or did you just typo 'oe-core' as 'meta-oe' above?
Oct 03 21:09:01 <michael_e_brown> https://github.com/openembedded
Oct 03 21:11:56 <michael_e_brown> I think I got it. I will fire it up tomorrow and see how it goes. Thanks for the pointers.
Oct 03 21:35:22 <otavio> So denzil+1 == danny?
Oct 04 00:19:23 <pidge> otavio: Yup. danny it is
Oct 04 00:20:44 <khem> denzil was 6 letters danny is 5 I guess 1.4 will be dewy
Oct 04 00:21:13 <khem> or kilimanjaro
Oct 04 00:38:28 <mranostay> what is yoctos name scheme exactly?
Oct 04 01:52:09 <otavio> Does people know how will be the merging policy? like danny and master will be the same code for some time or master is open?
Oct 04 02:41:41 <Crofton|work> mranostay, RP__ goes to the pub and comes up with something
Oct 04 02:50:57 <mranostay> ok good plan
**** ENDING LOGGING AT Thu Oct 04 02:59:58 2012

**** BEGIN LOGGING AT Thu Oct 04 02:59:58 2012
Oct 04 03:00:37 <otavio> Crofton|work: \m/
Oct 04 03:03:47 <msm> danny?
Oct 04 03:03:50 <msm> really
Oct 04 03:03:58 <msm> RP__: ….
Oct 04 03:03:59 <msm> hehe
Oct 04 03:04:08 <msm> clearly not "drunk" enough
Oct 04 03:09:53 <otavio> hahah
Oct 04 04:04:31 <otavio> jackmitchell: I just sent the changes for libav update to the mailing list
Oct 04 06:10:16 <mertsas> is it currently possible to list all packages installed in an image?
Oct 04 09:01:33 <rburton> msm: the name game is guessing the theme
Oct 04 11:00:08 <Crofton|work> RP__, I need a feature for th enext release
Oct 04 11:08:47 <RP__> Crofton|work: which is?
Oct 04 11:09:03 <Crofton|work> so in a bsp we want to build only against oe-core
Oct 04 11:09:07 <Crofton|work> right?
Oct 04 11:09:27 <Crofton|work> but, a bsp may want to contain recipes for "interesting" images that depend on other layers
Oct 04 11:09:32 <RP__> Crofton|work: that is desirable
Oct 04 11:09:36 <Crofton|work> without those ayers, parsing fails
Oct 04 11:09:42 <Crofton|work> layers damn it
Oct 04 11:09:55 <Crofton|work> so I would like a way to say :
Oct 04 11:10:17 <Crofton|work> this recipe depends on this layer, but if it is not present do not fail parsing
Oct 04 11:10:35 <Crofton|work> and if the user tries to build it, you get an errror saying a layer is missing
Oct 04 11:10:39 <Crofton|work> make sense?
Oct 04 11:10:48 <RP__> Crofton|work: To be honest I think BSPs should not be adding images like that, its entering the realms of distro policy
Oct 04 11:11:06 <Crofton|work> I am speaking about reality
Oct 04 11:11:24 <Crofton|work> then we have to add another layer for these
Oct 04 11:11:32 <Crofton|work> layer madness
Oct 04 11:11:40 <JaMa|Off> what about MACHINE_EXTRA_RDEPENDS MACHINE_EXTRA_RRECOMMENDS for tools shared in some other layer then oe-core?
Oct 04 11:11:51 <Crofton|work> I have the immediate issue of i2c-tools
Oct 04 11:11:58 <Crofton|work> (which should go into oe-core)
Oct 04 11:12:14 <Crofton|work> something a long those lines
Oct 04 11:12:16 <RP__> Crofton|work: there is certainly a case for that
Oct 04 11:12:33 <Crofton|work> my first question is, is this technically doable without madness in bitbake?
Oct 04 11:12:51 <JaMa> Crofton|work: add them as RRECOMMENDS
Oct 04 11:13:02 <RP__> Crofton|work: I just worry that adding such mechanisms (which actually isn't hard) is just going to open things up for abuse and condone lots of images in BSPs
Oct 04 11:13:15 <RP__> Crofton|work: rather than fix real problems like why isn't i2c-tools in oe-core?
Oct 04 11:13:40 <RP__> Crofton|work: Its technically doable right now
Oct 04 11:13:52 <Crofton|work> I have other possible use cases
Oct 04 11:14:10 <Crofton|work> what I am trying to avoid is pressure to move EVERYTHING into oe-core :)
Oct 04 11:14:21 <Crofton|work> so it is worth floating on the list
Oct 04 11:14:42 <RP__> Crofton|work: I'm fine with discussing it
Oct 04 11:15:02 <Crofton|work> basically, we need to see if this would help solve real problems
Oct 04 11:15:18 <Crofton|work> I would like our bsp for customers to ahve simple and complex images
Oct 04 11:16:08 <RP__> python () { if not d.getVar("MAGICLAYERPRESENT", True): raise bb.SkipParse("Foo cannot be build as layer X isn't present") }
Oct 04 11:16:09 <JaMa> Crofton|work: why not specify dependency on meta-oe in README?
Oct 04 11:16:39 <RP__> Crofton|work: You'd have to find the right event name but you can do something like that today
Oct 04 11:16:59 <Crofton|work> JaMa, the idea is you can start work with a couple of layers and add layers as you need more stuff
Oct 04 11:17:21 <Crofton|work> I would like this to be straight forward and documented :)
Oct 04 11:17:48 <RP__> Crofton|work: so take the above, make a working example, write a paragraph about it and send it to Scott?
Oct 04 11:18:08 <Crofton|work> let's see what people say
Oct 04 11:18:19 <Crofton|work> I am curious how many thers run into this osrt of thing
Oct 04 11:19:25 <Crofton|work> how do I set the var btw?
Oct 04 11:19:40 <JaMa> Crofton|work: saying that your BSP depends on oe-core and meta-oe is still just only 3 layers
Oct 04 11:20:00 <Crofton|work> yeah, but I am thinking of the general case :)
Oct 04 11:20:12 <RP__> Crofton|work: in MAGICLAYER's layer.conf, set something to idenotfy the layer
Oct 04 11:20:35 <Crofton|work> ok I ahve notes
Oct 04 11:20:56 <RP__> Crofton|work: e.g. LAYERVERSION_core is set for OE-Core
Oct 04 11:21:13 <RP__> Crofton|work: setting versions in other layers would be nice and then you could detect and use that
Oct 04 11:21:17 <Crofton|work> If the seminat about debugging with modern oscilloscopes is dull, I'll send an email
Oct 04 11:21:23 <bluelightning> note that BBFILE_COLLECTIONS is also available to be checked, if that helps
Oct 04 11:21:36 <RP__> ah, yes, that too :)
Oct 04 11:21:45 <RP__> Lots of options...
Oct 04 11:21:56 <bluelightning> depends if your collection names are sufficiently distinctive of course
Oct 04 11:22:14 <RP__> I'd hope we don't get collisions...
Oct 04 11:22:17 <Crofton|work> heh
Oct 04 11:23:24 <Crofton|work> ok, I need to run
Oct 04 11:23:26 <RP__> Crofton|work: Its  raise bb.parse.SkipPackage fwiw
Oct 04 11:23:34 <Crofton|work> I just wanted to get a sanity check on the thought
Oct 04 11:23:40 <RP__> other places use it for examples
Oct 04 12:08:16 <mertsas> would it be possible to get the license of a package when running bitbake myimage -g? that is, adding a depend_tree["pn"][pn]["license"] = self.status.pkg_license[fn] in the generateTaskDepTreeData in cooker.py. At least a way to simply get the packages build, along with versions and licenses for an image would be great
Oct 04 12:18:02 <bluelightning> mertsas: we do write out a license manifest to tmp/deploy/licenses
Oct 04 12:18:50 <bluelightning> the actual packages installed are determined by the package manager, so it has to be done during actual image generation
Oct 04 12:21:27 <mertsas> ok
Oct 04 12:27:24 <mertsas> guess I should just make a script that parses the pn-buildlist and cross checks that with deploy/licenses.
Oct 04 12:29:22 <bluelightning> the thing is, pn-buildlist only tells you what was built, not what is going to be installed
Oct 04 12:29:41 <bluelightning> the license manifest for the image lists exactly what is in your image
Oct 04 12:52:25 <mertsas> bluelightning: aaah... didn't know it had it's own manifest file. That's fantastic. Actually exactly what I was looking for
Oct 04 12:52:46 <bluelightning> great :)
Oct 04 12:53:33 <mertsas> thanks
Oct 04 12:57:13 <hrw> which recipe I need to add to DEPENDS to get cross Fortran compiler?
Oct 04 12:58:27 <rburton> hrw: 1970 is calling and wants its compilers back
Oct 04 12:58:45 <rburton> bluelightning: i thought you were away today
Oct 04 13:01:58 <hrw> rburton: there is an option --with-f90 ;)
Oct 04 13:44:18 <bluelightning> rburton: I am :)
Oct 04 13:44:31 <bluelightning> going out shopping now in fact
Oct 04 14:57:45 <sgw> fray: any update on the multilib/IMAGE_FEATURES issue?
Oct 04 15:00:46 <fray> I was able to reproduce it over the weekend.. it no longer reproduced for me yesterday.. still working on it
Oct 04 15:01:18 <sgw> fray: so you think it's fixed in master now with the other changes?
Oct 04 15:20:43 <eren> http://www.aosabook.org/en/yocto.html
Oct 04 15:20:51 <eren> nice article for newcomers to Yocto
Oct 04 15:21:03 <eren> plus, it's good to see female hackers around here, hack like a girl, hehe
Oct 04 15:40:50 <eren> is there anyone working with ALIX 3D3 board, which has AMD Geode LX 800 processor
Oct 04 17:22:23 <hrw> eren: MACHINE=alix in oe classic
Oct 04 17:22:44 <hrw> eren: it was for alix.1c but should work on any geode lx
Oct 04 17:53:56 <eren> hrw: will try, thank you
Oct 04 17:55:09 <hrw> eren: basically you can treat it as i586 and just use own kernel config to get some special geode things
Oct 04 17:58:56 <hrw> bye
Oct 04 18:04:20 <sgw> fray: just to confirm, I tested the multilib issue again with master and it still fails, make sure you use the lib32 prefix (ie: lib32-core-image-minimal)
Oct 04 18:05:24 <fray> Ya.. I'm stuck in meetings today.. (for another hour or so).. but then I should be able to get back to this
Oct 04 18:08:46 <eren> hrw: I've stripped down packages from a linux distro developed here, we aimed at i686
Oct 04 18:09:02 <sgw> fray: Ok again, let me know if I can be of any help, we would like to see this fixed in 1.3 if it's not too invasive!
Oct 04 18:09:07 <eren> hrw: however, video/audio codecs were not working properly because of some lacking instruction
Oct 04 18:09:24 <fray> ya I know..
Oct 04 18:09:35 <eren> hrw: video driver for X was problematic as well, I don't know if framebuffer works in ALIX 3D3 with newer kernels
Oct 04 18:09:41 <fray> we fixed a bunch of ancillary stuff, but the main issue seems to still be there
Oct 04 18:09:45 <eren> I tried 2.6.38 series 1 year ago
Oct 04 18:17:39 <khem> good morning all
Oct 04 18:27:02 <RagBall> If I want to build a image with XFCE as desktop-manager, will I need to use xfdesktop in my IMAGE_INSTALL?
Oct 04 18:28:27 <RagBall> Because the kernel boots and is waiting on "Freeing init memory: 128k" forever
Oct 04 18:28:43 <RagBall> When I build core-image-sato it works perfectly
Oct 04 18:41:30 <chackal_sjc> how to check dependencies via the GUI?
Oct 04 18:41:34 <khem> RagBall: well you could add meta-xfce to your layer and then build xfce-image
Oct 04 18:42:17 <chackal_sjc> -g -u depexp right?
Oct 04 18:42:26 <RagBall> I didn't know there was a specific xfce-image available
Oct 04 18:44:33 <khem> RagBall: always look at http://www.openembedded.org/wiki/LayerIndex
Oct 04 18:44:40 <khem> for possible options
Oct 04 18:46:59 <chackal_sjc> hows possible to remove a DISTRO_FEATURE that is been added by some recipe that I don't know
Oct 04 18:47:46 <RagBall> khem: Offcourse I have that layer in my config, xfdesktop build nicely
Oct 04 18:48:09 <RagBall> But I don't know if I build the correct image
Oct 04 18:56:51 <khem> RagBall: hmm I think its angstrom specific image xfce-nm-image
Oct 04 18:57:08 <khem> so I guess you can model something on that line
Oct 04 18:59:09 <bluelightning> chackal_sjc: DISTRO_FEATURES are set by the distro config, not a recipe
Oct 04 18:59:23 <bluelightning> chackal_sjc: i.e. conf/distro/distroname.conf
Oct 04 19:11:19 <chackal_sjc> bluelightning: yes, but I'm not setting 3g and a bunch of other features that when  I check the environment, they are there
Oct 04 19:11:57 <chackal_sjc> and also... there is this task-base that is adding a bunch of dependencies that I don't need... and when I see the depexp, it says that the compiler calls task-base
Oct 04 19:12:02 <chackal_sjc> it doesn't make sense..
Oct 04 19:22:50 <blloyd_> is your new distro somewhere it can be looked at?  I've felt your pain in trying to puzzle out how this works.
Oct 04 19:28:20 <RagBall> Isn't there any packagegroup or recipe I can bake for a standard gnome image?
Oct 04 19:43:32 <rburton> chackal_sjc: sounds like your distro is inheriting poky
Oct 04 20:22:53 <khem> bluelightning: have you experience with bootimg.bbclass
Oct 04 20:46:48 <zenlinux> anyone know which recipe build xterm? On my desktop distros, xterm is usually its own package, so I'm not sure what parent it would be associated with (xorg-utils? xorg-common?)
Oct 04 20:48:16 <ag_> zenlinux: .... uh... xterm_X.bb?
Oct 04 20:48:20 <ag_> :)
Oct 04 20:48:37 <ag_> zenlinux: You can find it in meta-oe/meta-oe/recipes-graphics/xorg-app
Oct 04 20:48:56 <zenlinux> ag_, ah, does that mean we don't include it in oe-core?
Oct 04 20:49:10 <zenlinux> I thought we did.
Oct 04 20:49:13 <ag_> zenlinux: Don't think so.
Oct 04 20:49:34 <zenlinux> ok, well that explains it - thanks ag_
Oct 04 20:50:08 <ag_> zenlinux: No probs
Oct 04 20:59:19 <chackal_sjc> rburton: how can I be sure if my distro is inheriting poky?
Oct 04 21:00:00 <chackal_sjc> the only thing that i see is this:
Oct 04 21:00:04 <chackal_sjc> # Override these in poky based distros to modify DISTRO_EXTRA_R*
Oct 04 21:00:06 <chackal_sjc> G2_DEFAULT_EXTRA_RDEPENDS = "task-core-boot"
Oct 04 21:00:23 <chackal_sjc> maybe this task-core-boot is doing that?
Oct 04 21:15:30 <chackal_sjc> how to start hob?
Oct 04 21:21:10 <chackal_sjc> i found there is something like this in meta/conf/distro/include/default-distrovars.inc
Oct 04 21:21:19 <chackal_sjc> DISTRO_FEATURES ?= "alsa argp bluetooth ext2 irda largefile pcmcia usbgadget usbhost wifi xattr nfs zeroconf pci 3g x11 ${DISTRO_FEATURES_LIBC}"
Oct 04 21:27:03 <chackal_sjc> why in the world there is this in bitbake.conf?
Oct 04 21:27:07 <chackal_sjc> DISTRO_FEATURES_BACKFILL = "pulseaudio"
Oct 04 21:27:15 <chackal_sjc> DISTRO_FEATURES_append = "${@oe.utils.distro_features_backfill(d)}"
Oct 04 21:27:33 <chackal_sjc> so pulseaudio is always in my DISTRO_FEATURES?
Oct 04 21:40:44 <bluelightning> chackal_sjc: because it was always enabled before and disabling it by default would be changing people's existing configs
Oct 04 21:40:56 <bluelightning> if you don't want it, add it to DISTRO_FEATURES_BACKFILL_CONSIDERED
Oct 04 21:42:16 <bluelightning> khem: not a huge amount no
Oct 04 21:42:26 <chackal_sjc> bluelightning: yes, I just saw in meta/lib/oe/utils.py
Oct 04 21:42:29 <chackal_sjc> thanks anyway
Oct 04 21:43:07 <chackal_sjc> bluelightning: but you know that that's the kind of thing that makes someone that don't know that freaks out
Oct 04 21:43:13 <bluelightning> hmm, I think I need to get scott to add that to the docs
Oct 04 21:43:57 <chackal_sjc> bluelightning: do you know if its possible to integrate poky with buildbot, or similar?
Oct 04 21:44:32 <bluelightning> chackal_sjc: we do that on the autobuilder; our autobuilder setup is available for download as well
Oct 04 21:44:54 <bluelightning> http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder/
Oct 04 21:46:42 <chackal_sjc> bluelightning: ok, i will take a look on that later... about the cross-prelink, how does that work?
Oct 04 21:49:00 <bluelightning> it's not an area I'm especially familar with, but I believe fray is our local expert on that however...
Oct 04 21:49:27 <chackal_sjc> in gst-plugins-base recipe there is a line
Oct 04 21:49:33 <chackal_sjc> DEPENDS += "alsa-lib freetype liboil libogg libvorbis libtheora avahi util-linux tremor"
Oct 04 21:49:38 <chackal_sjc> why avahi is there??!
Oct 04 21:49:53 <bluelightning> that's a good question
Oct 04 21:49:55 <chackal_sjc> it suppose to check zeroconf in DISTRO_FEATURES, right?
Oct 04 21:50:11 <bluelightning> almost certainly, yes
Oct 04 21:51:45 <chackal_sjc> bluelightning: in master they removed that
Oct 04 21:52:10 <bluelightning> that doesn't sound right
Oct 04 21:52:58 <chackal_sjc> problem is, how can I fix that in my version? since im using poky 7.0.0 and i dont want to change any poky source
Oct 04 21:53:31 <chackal_sjc> maybe adding a .bbappend and redefining DEPENDS ? does it will work?
Oct 04 21:53:39 <bluelightning> yep I was just about to suggest that
Oct 04 21:53:50 <bluelightning> that would be the easiest approach
Oct 04 21:53:50 <chackal_sjc> k
Oct 04 21:54:12 <chackal_sjc> since we are talking about that.. is there any easy way to update poky versions?
Oct 04 21:54:36 <chackal_sjc> because I tried use the master branch, was crashing a lot of recipes that I have.. lots of changes in classes and stuff
Oct 04 21:54:37 <bluelightning> ah, right... I see why avahi was there from the master commit that removed it
Oct 04 21:54:53 <chackal_sjc> bluelightning: so, why?
Oct 04 21:55:27 <bluelightning> chackal_sjc: apparently something to do with gnome-vfs previously but gnome-vfs is deprecated and has been removed, so we don't need avahi for gst-plugins-base anymore
Oct 04 21:56:07 <chackal_sjc> yeah, just saw
Oct 04 21:56:23 <bluelightning> chackal_sjc: the biggest change is the python function tabs to spaces change, that requires fixes to any recipe that adds or appends/prepends python functions
Oct 04 21:56:50 <chackal_sjc> hm
Oct 04 21:57:22 <bluelightning> not too difficult a change to make though
Oct 04 22:01:08 <chackal_sjc> yes, just time consuming
Oct 04 22:43:04 <b1gtuna> hello everyone, how do i make a recipe out of a source with makefiles ?
Oct 04 22:43:38 <b1gtuna> autotool is failing with "config.mak: No such file or directory"
Oct 04 22:58:28 <bluelightning> b1gtuna: you probably don't want "inherit autotools" in your recipe
Oct 04 22:58:46 <bluelightning> b1gtuna: there's an example of a basic makefile-only recipe in the manual I think
Oct 04 23:02:02 <b1gtuna> bluelightning: yup i found it. Following thru =). Thank you (i remember seeing it, but it took me awhile to find it again)
Oct 04 23:02:56 <bluelightning> b1gtuna: the main thing to take care of with makefiles is that they use all the correct paths and tools, since autotools (and our bbclass for it) is not there to handle that
Oct 04 23:10:43 <b1gtuna> bluelightning: Will becareful with that. Ty
**** ENDING LOGGING AT Fri Oct 05 02:59:57 2012

**** BEGIN LOGGING AT Fri Oct 05 02:59:58 2012
Oct 05 08:29:13 <gotan> morning.
Oct 05 08:48:55 <gizero76> morning
Oct 05 09:21:05 <gizero76> while doing my last few test for the 1.3 beta I noticed this strange thing:
Oct 05 09:21:08 <gizero76> after some command line based builds for qemuppc, I moved to testing latest hob. Here I switched to a different architecture (beagleboard) and built an image (qt4-demo-image). Now I notice that every successive run of the same build configuration does indeed re-trigger the build of u-boot. I see workdirs beeing differently named every time, even if the git revision that's being used is always the same (as expected for a
Oct 05 09:21:10 <gizero76> frozen release to be beta-tested). Is this expected to happen? What does this mean?
Oct 05 09:27:36 <gizero76> here is my workdir after a few run of this workflow:
Oct 05 09:27:39 <gizero76> 1. open hob
Oct 05 09:27:41 <gizero76> 2. select beagleboard
Oct 05 09:27:43 <gizero76> 3. select qt4-demo-image
Oct 05 09:27:45 <gizero76> 4. build
Oct 05 09:27:47 <gizero76> 5. select "New image"
Oct 05 09:27:49 <gizero76> 6. goto 2.
Oct 05 09:27:51 <gizero76> gizero@gizdesk:/srv/vmachines/yp-beta/yp-beta-build/tmp/work/beagleboard-poky-linux-gnueabi$ ll
Oct 05 09:27:53 <gizero76> total 84
Oct 05 09:27:55 <gizero76> drwxrwxr-x 13 gizero gizero 4096 Sep 21 19:21 alsa-state-0.2.0-r3
Oct 05 09:27:57 <gizero76> drwxrwxr-x 14 gizero gizero 4096 Oct  5 08:36 base-files-3.0.14-r71
Oct 05 09:27:59 <gizero76> drwxrwxr-x  6 gizero gizero 4096 Sep 22 12:51 hob-image-1.0-r0
Oct 05 09:28:01 <gizero76> drwxrwxr-x 15 gizero gizero 4096 Sep 21 19:24 linux-yocto-3.0.32+git1+bf5ee4945ee6d748e6abe16356f2357f76b5e2f0_1+3ab688a78cac7b2e32afc83376a53370f2bd13b7-r4.0
Oct 05 09:28:03 <gizero76> drwxrwxr-x 13 gizero gizero 4096 Sep 21 19:20 netbase-5.0-r0
Oct 05 09:28:05 <gizero76> drwxrwxr-x 13 gizero gizero 4096 Sep 21 19:20 opkg-config-base-1.0-r1
Oct 05 09:28:07 <gizero76> drwxrwxr-x 12 gizero gizero 4096 Sep 21 17:25 pointercal-0.0-r11
Oct 05 09:28:09 <gizero76> drwxrwxr-x  6 gizero gizero 4096 Oct  5 11:04 qt4e-demo-image-1.0-r2
Oct 05 09:28:11 <gizero76> drwxrwxr-x 13 gizero gizero 4096 Sep 21 17:25 shadow-securetty-4.1.4.3-r1
Oct 05 09:28:13 <gizero76> drwxrwxr-x 13 gizero gizero 4096 Sep 21 17:25 sysvinit-inittab-2.88dsf-r7
Oct 05 09:28:15 <gizero76> drwxrwxr-x 13 gizero gizero 4096 Sep 21 19:20 task-base-1.0-r75
Oct 05 09:28:17 <gizero76> drwxrwxr-x 13 gizero gizero 4096 Sep 21 19:20 task-core-boot-1.0-r9
Oct 05 09:28:19 <gizero76> drwxrwxr-x  3 gizero gizero 4096 Sep 21 21:00 u-boot-v2011.06+git11+b1af6f532e0d348b153d5c148369229d24af361a-r2
Oct 05 09:28:21 <gizero76> drwxrwxr-x 13 gizero gizero 4096 Sep 21 21:07 u-boot-v2011.06+git14+b1af6f532e0d348b153d5c148369229d24af361a-r2
Oct 05 09:28:23 <gizero76> drwxrwxr-x  3 gizero gizero 4096 Sep 21 23:19 u-boot-v2011.06+git21+b1af6f532e0d348b153d5c148369229d24af361a-r2
Oct 05 09:28:25 <gizero76> drwxrwxr-x 13 gizero gizero 4096 Sep 22 13:08 u-boot-v2011.06+git24+b1af6f532e0d348b153d5c148369229d24af361a-r2
Oct 05 09:28:27 <gizero76> drwxrwxr-x  3 gizero gizero 4096 Oct  5 08:37 u-boot-v2011.06+git29+b1af6f532e0d348b153d5c148369229d24af361a-r2
Oct 05 09:28:29 <gizero76> drwxrwxr-x 13 gizero gizero 4096 Oct  5 08:49 u-boot-v2011.06+git33+b1af6f532e0d348b153d5c148369229d24af361a-r2
Oct 05 09:28:31 <gizero76> drwxrwxr-x  3 gizero gizero 4096 Oct  5 10:58 u-boot-v2011.06+git40+b1af6f532e0d348b153d5c148369229d24af361a-r2
Oct 05 09:28:33 <gizero76> drwxrwxr-x 13 gizero gizero 4096 Oct  5 11:21 u-boot-v2011.06+git43+b1af6f532e0d348b153d5c148369229d24af361a-r2
Oct 05 09:28:41 <gizero76> no changes where made to any configuration between builds
Oct 05 10:43:03 <JaMa> is bitbake logging working correctly now? I'm debugging fetcher issues (not using PREMIRROR) and it does not show any debug output
Oct 05 10:43:22 <JaMa> I've even downgraded bitbake rev to point where it worked and still no output
Oct 05 10:45:41 <JaMa> ah now it shows debug output from trying SSTATE_MIRRORS but then no output at all for do_fetch
Oct 05 11:23:20 <RP__> JaMa: That suggests its finding the file in DL_DIR and not doing much
Oct 05 11:25:37 <JaMa> no I remove that file before trying it
Oct 05 11:32:06 <JaMa> RP__: the problem is that all debug output is redirected to log.do_fetch
Oct 05 11:32:20 <JaMa> RP__: so nothing is shown on knotty
Oct 05 11:32:28 <JaMa> while sstate fetching is
Oct 05 11:32:34 <RP__> JaMa: This was a conscious decision a while ago
Oct 05 11:32:48 <RP__> JaMa: mainly as multiple processes made the output on knotty very confusing
Oct 05 11:33:16 <JaMa> was there some knob to change this? IIRC BB_LOGS or something like that?
Oct 05 11:35:49 <JaMa> btw there is one icon only in upstream bitbake (not in poky copy)
Oct 05 11:35:50 <JaMa> Only in /OE/bitbake/lib/bb/ui/icons/indicators: info.png
Oct 05 11:38:55 <JaMa> ah BBINCLUDELOGS is used only on failure it seems
Oct 05 11:40:11 <RP__> JaMa: yes, that only happens on failure
Oct 05 15:54:43 * mranostay pokes khem 
Oct 05 16:27:52 <chackal_sjc> im trying to check the license withon a file, but it not working
Oct 05 16:28:10 <chackal_sjc> LIC_FILES_CHKSUM = "file://plugin.cpp;beginline=1;endline=40;md5sum=8a7c0fabef2047fae80b52aa220e8ab9"
Oct 05 16:28:37 <chackal_sjc> i did the checksum like this: head -n 40 plugin.cpp | md5sum
Oct 05 16:28:40 <chackal_sjc> is it ok?
Oct 05 16:29:53 <chackal_sjc> and there is another case where I have a LICENSE file, i did the md5sum in it and still not passing the check license task
Oct 05 16:29:55 <Daemon404> depends if the first line is 0 or 1
Oct 05 16:31:46 <chackal_sjc> Daemon404: still not working
Oct 05 16:40:10 <Daemon404> i couldnt tell without grepping through the bitbake code
Oct 05 16:41:12 <chackal_sjc> Daemon404: what you mean?
Oct 05 16:42:28 <Daemon404> i couldnt tell how the build system does it without read its code
Oct 05 16:43:37 <chackal_sjc> Daemon404: i read it
Oct 05 16:44:02 <chackal_sjc> it seems ok.. the only thing is that bitbake uses python hashlib to generate the md5sum
Oct 05 16:44:33 <chackal_sjc> but i guess its fine, since when I use md5sum to check my .tar.gz's bitbake matches the hash
Oct 05 16:49:13 <chackal_sjc> Daemon404: i found the error
Oct 05 16:49:40 <chackal_sjc> the param insabe.bbclass checks is md5 and not md5sum
Oct 05 17:09:43 <chackal_sjc> is there any way a reciep can skip the package generation? (if you don't set FILES_X for example?)
Oct 05 17:11:39 <khem> mranostay: whats up
Oct 05 17:11:42 <khem> gm all
Oct 05 17:23:16 <zenlinux_> msm, I had a failure building the kernel for mpc8315e on my denzil-next branch. Are you the champion of that board?
Oct 05 17:23:55 <zenlinux_> http://autobuilder.yoctoproject.org:8010/builders/nightly-ppc-lsb/builds/82/steps/shell_52/logs/stdio
Oct 05 17:39:09 <mranostay> khem: i'm having trouble getting a mip64 denzil to build
Oct 05 17:39:46 <mranostay> has this been done sucessfully? :)
Oct 05 18:10:37 <msm> zenlinux: hmm, not really
Oct 05 18:10:51 <msm> zenlinux: we've not really done anything for that board
Oct 05 18:11:14 <msm> zenlinux: although for that error, i submitted an upstream kernel fix
Oct 05 18:11:44 <msm> http://patchwork.ozlabs.org/patch/182260/
Oct 05 18:11:51 <msm> http://patchwork.ozlabs.org/patch/184816/
Oct 05 18:12:02 <msm> they probably need to be added to linux-yocto
Oct 05 18:12:06 <msm> zedii	^
Oct 05 19:42:15 <msm> is it possible for a do_compile step to depend on intermediate files from a previous recipe?
Oct 05 19:42:29 <msm> such that sstate will then need to go back and rebuild the previous recipe too?
Oct 05 19:42:44 <msm> it seems like my sstate for eglibc is the same, but gcc-cross is wanting to rebiuld
Oct 05 19:42:50 <msm> and somehow it's retrigger eglibc?
Oct 05 19:42:56 <msm> anyways, im still investigating
Oct 05 20:16:23 <msm> zenlinux: when is the next denzil release?
Oct 05 20:16:35 <msm> zenlinux: (just curious since you already have another pull request)
Oct 05 20:17:36 <zenlinux> msm, we haven't set a firm date yet, probably need to start discussing that soon
Oct 05 20:17:40 <zenlinux> hopefully sometime in december
Oct 05 20:20:36 <msm> zenlinux: ok, we will make a release soon on denzil
Oct 05 20:20:59 <msm> so it might be a  weird mix between releases
Oct 05 20:21:18 <msm> but there are not major issues so far so i don't really expect many more fixes
Oct 05 20:21:22 <msm> (from me at least)
Oct 05 20:24:28 <zenlinux> msm, sounds good
Oct 05 21:01:40 <mranostay> heh so the git tarball of the gcc release is 1.6G? :)
Oct 05 21:38:09 <seebs> Hey, was wondering whether anyone had feedback for me on the recentish (September 17th, I guess) round of include/variable tracking patches I sent out.
Oct 05 21:38:31 <fray> seebs, I thought I emailed you -- but there was a bug in the one place..
Oct 05 21:38:34 <seebs> I'd like to clean them up and improve them more, but I am still a little too close to the code to really get a clear look at it.
Oct 05 21:38:51 <seebs> You totally did, yes. I should go find that email again and fix it.
Oct 05 21:39:14 <fray> other then the one bug it was working.. the only thing though is nothing appear to track override switching..
Oct 05 21:39:19 <fray> (which is what I was trying to use it for)..
Oct 05 21:39:29 <fray> I couldn't figure out how/where something was being set..
Oct 05 21:39:38 <seebs> Oh, that's an interesting thought.
Oct 05 21:39:40 <seebs> Hmm.
Oct 05 21:39:56 <fray> was something to do with the multilib configurations..  I don't remember exactluy what..
Oct 05 21:39:58 <seebs> Yes, that would be a really nice thing for it to do.
Oct 05 21:40:16 <fray> but I believe enablign multilibs and then using bitbake -e lib32-... exposed the issue..
Oct 05 21:40:32 <fray> or maybe it was foo-cross-canadian-<translated target arch>
Oct 05 21:40:45 <fray> it was during the processing of the multilib SDK stuff I did that I was tying to use it
Oct 05 21:40:48 <seebs> Yeah. I think right now it should show what overrides it ended up applying, but it wouldn't show why those were the overrides it applied.
Oct 05 21:41:01 <seebs> And I can't find your email about the bug, although I totally remember there being one.
Oct 05 21:41:20 <fray> it was a one-line typo.. wrong variable was referenced
Oct 05 21:41:44 <seebs> Oh! The var/base thing. I remember.
Oct 05 21:44:48 <seebs> Well, hmm. I do track changes to $OVERRIDES.
Oct 05 21:45:03 <seebs> But that doesn't really tell you all that much.
Oct 05 21:45:36 <fray> ya.. it's when the update runs, the tracking is that to the line that performed the update (not on the OE side, but the bitbake side).. doesn't tell ya much
Oct 05 21:45:37 <seebs> Well, hmm. It looks to me as though things which have overrides which are used are getting somewhat reported on.
Oct 05 21:46:19 <seebs> The weakness is that being told that it was set to "${TARGET_OS}:..." doesn't tell you that much until you go look up all the changes to the variables included there.
Oct 05 21:47:06 <fray> what I wanted was something that says FOO_override was transfered to FOO by....
Oct 05 21:47:19 <seebs> Well, that all happens in finalize.
Oct 05 21:47:48 <seebs> So for a specific example, $PREFERRED_VERSION_linux_yocto was overridden, and I show:
Oct 05 21:47:56 <fray>         bb.data.update_data(e.data)
Oct 05 21:47:59 <fray> thats the magic....
Oct 05 21:48:03 <seebs> override[qemux86]:set? /path/to/distro/poky.conf
Oct 05 21:48:14 <seebs> finalize override[qemux86]: "3.4%"
Oct 05 21:48:21 <fray> I got a link basically to teh d.setVar.... :P
Oct 05 21:48:29 <seebs> So that says that it was set by the _qemux86 value which was set from poky.conf.
Oct 05 21:48:42 <fray> it would be nice if what called the update_data was captured -- if a change occured
Oct 05 21:49:33 <seebs> update_data() appears to do nothing but finalize().
Oct 05 21:50:03 <seebs> Hmm. That makes sense, though. In finalize(), I could stash information about the caller, and then if anything is overridden, I could add that to the information saying it was overridden.
Oct 05 21:50:15 <seebs> Lemme see if I can hack that on real quick, it would definitely increase value.
Oct 05 21:51:10 <fray> the key thing is to look at the -e output of a multilib package..
Oct 05 21:51:44 <fray> look for 'DEPENDS' and 'PROVIDES'..  I was trying to figure out where that stuff is configured..
Oct 05 21:52:02 <fray> ...and PACKAGES
Oct 05 21:52:27 <seebs> k!
Oct 05 21:52:45 <fray> all I was getting was references into bitbake itself.. nothing from OE..
Oct 05 21:52:50 <fray> (I'm pretty sure thats it)
Oct 05 21:55:45 <seebs> I shall investigate. Thanks! This is really useful.
Oct 05 21:56:56 <seebs> argh
Oct 05 21:57:11 <fray> the thing running finalize or setVar.. all would have been very useful..
Oct 05 21:57:14 <seebs> I should never try to work with a cold. I am apparently unable to edit config files competently today. :)
Oct 05 21:57:21 <fray> (wouldn't surprise me if some of the stuff was 'appendVar' as well
Oct 05 21:57:50 <seebs> Right now, the default is to ignore them, but I added modifiers to make it track some. I was trying not to over-report on internals, but some should get reported.
Oct 05 21:58:15 <seebs> Okay, so. Can you give me a trivial set of lines to add to local.conf to have a working multilib package? I thought I knew how to do this, but apparently I am wrong.
Oct 05 21:58:19 <fray> it took a lot of hacking to figure out where the update happened and the multilib transforms occured.. :P
Oct 05 21:58:45 <fray> MACHINE = 'qemux86-64'
Oct 05 21:58:52 <fray> require conf/multilib.conf
Oct 05 21:58:56 <fray> MULTILIBS = "multilib:lib32"
Oct 05 21:58:56 <fray> DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
Oct 05 21:59:47 <seebs> That looks like what I have. (Well, I had it going the other way, so just in case I've inverted it.)
Oct 05 22:02:14 <seebs> So, what do I do to add a package? I thought it was IMAGE_INSTALL += "lib32-busybox", and then "bitbake -e lib32-busybox". But Nothing PROVIDES that.
Oct 05 22:02:50 <fray> don't need to..
Oct 05 22:02:55 <fray> seebs, are you using master?
Oct 05 22:03:24 <seebs> Probably a month back by now. I should update. I'm also using a poky tree because that's what I had handy. So I should probably migrate to Newer Stuff.
Oct 05 22:03:35 <fray> ya.. update to latest master
Oct 05 22:03:39 <seebs> k
Oct 05 22:03:59 <fray> odd.. I'm getting the same thing
Oct 05 22:05:56 <seebs> I looked at it, so it broke. :P
Oct 05 22:07:03 <seebs> ... and it worked for me now using oe-core/bitbake master. :)
Oct 05 22:08:00 <seebs> And you're right, DEPENDS and PROVIDES are nearly empty.
Oct 05 22:08:41 <seebs> I'll set the default to not-ignore, and see what I get.
Oct 05 22:10:08 <fray> wow.. this is awesome
Oct 05 22:10:09 <fray> http://www.youtube.com/watch?feature=player_embedded&v=6ti2S7Py25w
Oct 05 22:10:41 <seebs> Ah-hah! oe-core's map_variable is a source of many changes.
Oct 05 22:10:54 <fray> bingo.. thats what I saw..
Oct 05 22:11:23 <seebs> A lot of the calls from setVar are already being reported in some other way.
Oct 05 22:11:52 <seebs> oooh.
Oct 05 22:12:02 <seebs> And that appears to be calling a data object's setVar, not a dataSmart's.
Oct 05 22:12:18 <fray> d.setVar or?
Oct 05 22:13:08 <seebs> Yeah.
Oct 05 22:13:21 <seebs> So if I add another argument, it errors out rather than doing what I want.
Oct 05 22:14:46 <seebs> Hmm.
Oct 05 22:15:07 <fray> d.setVar is the way everything in OE works.. so you need a way to figure out the caller and add that
Oct 05 22:16:19 <seebs> Within bitbake, everything was calling it on datasmart objects, not data objects.
Oct 05 22:16:37 <seebs> Wait... this is weirder than I thought.
Oct 05 22:16:53 <seebs> I may be on the wrong branch. It is a DataSmart. I wonder if I'm using the wrong bitbake branch.
Oct 05 22:17:48 <seebs> oh
Oct 05 22:17:59 <seebs> Forgot. { 'foo': bar } and foo = bar are not interchangeable.
Oct 05 22:27:39 <JaMa|Off> :se noai
Oct 05 22:27:39 <JaMa|Off> a:se ai
Oct 05 22:27:45 <JaMa|Off> ups
Oct 05 22:27:50 <seebs> this is why I have a .exrc
**** ENDING LOGGING AT Sat Oct 06 03:00:01 2012

**** BEGIN LOGGING AT Sat Oct 06 03:00:02 2012
Oct 06 11:38:22 <cib0> Hm, it seems a few packages that are listed in the ubuntu apt-get list don't exist anymore
Oct 06 11:39:54 <cib0> Wait nevermind, the other way around, I'm not recent enough
Oct 06 14:05:03 <cib0> Is it possible to get yocto to work with distcc or something similar?
Oct 06 20:55:45 <seebs> http://www.escapistmagazine.com/news/view/119981-IT-Security-Mag-Tricked-Into-Publishing-Hilarious-Nonsense <-- a room full of programmers has to contain people who will find this hilarious.
**** ENDING LOGGING AT Sun Oct 07 02:59:58 2012

**** BEGIN LOGGING AT Sun Oct 07 02:59:58 2012
**** ENDING LOGGING AT Mon Oct 08 02:59:58 2012

**** BEGIN LOGGING AT Mon Oct 08 02:59:59 2012
Oct 08 04:07:46 <sakoman_> gm
Oct 08 04:08:21 <sakoman_> I've given my sstate cache lots of benign neglect on one of my dev machines
Oct 08 04:09:40 <sakoman_> I noticed today that it is using massive amounts of disk space, so I decided (finally) to run sstate-cache-management.sh to clean out the duplicates
Oct 08 04:09:57 <sakoman_> sadly it appears that I may have waited too long:
Oct 08 04:10:12 <sakoman_> sstate-cache-management.sh: line 138: /bin/ls: Argument list too long
Oct 08 04:10:32 <sakoman_> any advice on the best way to handle this?
Oct 08 04:11:13 <sakoman_> is it safe to delete just the sstate directory?
Oct 08 04:37:39 <daniels> sakoman_: it's safe to delete it, but you'll end up doing a full rebuild
Oct 08 04:38:06 <sakoman_> I expected that :-(
Oct 08 04:38:42 <sakoman_> Need to be better about running the tool regularly in the future so things don't get out of hand
Oct 08 08:16:27 <mckoan> good morning
Oct 08 08:18:10 <bluelightning> morning mckoan, all
Oct 08 09:03:44 <likewise> gm
Oct 08 09:47:32 <RP__> morning all
Oct 08 09:48:34 <RP__> sakoman_: the sstate layout change should help that problem in future
Oct 08 11:01:06 <FunkyPenguin> moaning all
Oct 08 11:03:10 <FunkyPenguin> could someone advise on the rough content of the Yocto Developer day at ELCE please?
Oct 08 11:04:00 <slaine> morning FunkyPenguin
Oct 08 11:04:21 <FunkyPenguin> aloha slaine
Oct 08 11:04:38 <FunkyPenguin> you not taking rburton's rubbish anymore?
Oct 08 11:05:29 <slaine> never took any of his rubbish
Oct 08 11:07:59 <FunkyPenguin> ah that explains why it's all built up and he's getting desperate to sling it all :)
Oct 08 11:10:41 <likewise> FunkyPenguin: Can only find this: http://events.linuxfoundation.org/events/embedded-linux-conference/yocto-project-developer-day
Oct 08 11:14:33 <likewise> FunkyPenguin: Sorry, wrong link, that was the ELC one...
Oct 08 11:15:03 <FunkyPenguin> likewise: well that's all i could find too
Oct 08 11:15:32 <FunkyPenguin> likewise: and as the next developer day is with ELCE it kind of makes sense that it would be similar
Oct 08 11:15:48 <FunkyPenguin> likewise: so no need to apologise - thanks for confirming :)
Oct 08 11:17:48 <likewise> FunkyPenguin: How did you found out about there being a similar day at ELCE?
Oct 08 11:19:13 <FunkyPenguin> likewise: http://events.linuxfoundation.org/events/linuxcon-europe
Oct 08 12:48:34 <RP__> FunkyPenguin: I'd suggest asking about this on the yocto mailing list
Oct 08 12:48:46 <RP__> FunkyPenguin: Jefro should have an answer for you
Oct 08 12:49:04 <RP__> he's not online at the moment (US based)
Oct 08 12:49:08 <FunkyPenguin> RP__: will do, thanks
Oct 08 12:49:32 * FunkyPenguin is trying to work out whether to go or not
Oct 08 12:50:51 <likewise> FunkyPenguin: at least Barcelona is nice. :)
Oct 08 12:52:29 <FunkyPenguin> likewise: it is, but I need $EMPLOYER to send me
Oct 08 12:52:44 <FunkyPenguin> and as with everything they want a business case
Oct 08 12:53:44 <RP__> FunkyPenguin: http://dan.rpsys.net/DevDaySchedule.png is an old version, I know changes have been made
Oct 08 12:53:58 <RP__> FunkyPenguin: I'm dredging email archives
Oct 08 12:54:50 <FunkyPenguin> RP__: thanks, I'll send a mail in a sec once I finish listening to kernel devs have a moaning session
Oct 08 12:59:03 <likewise> FunkyPenguin: Yeah, the $EMPLOYER == $EMPLOYEE case works better, at least at the convincing side. On the finance side, $EMPLOYER != $EMPLOYEE is better.
Oct 08 13:32:25 <sakoman_> RP__: I had been using denzil on that machine, so it was the denzil version of sstate-cache-management.sh that failed with a huge sstate cache
Oct 08 13:32:49 <RP__> sakoman_: ok, hopefully the new layout in master will be better
Oct 08 13:32:50 <sakoman_> RP__: I tried the current head sstate-cache-management.sh and that worked
Oct 08 13:33:01 <RP__> sakoman_: good to know too :)
Oct 08 13:33:13 <sakoman_> so both new layout and new tools ought to be a double win ;-)
Oct 08 13:34:05 <ag_> Hello.
Oct 08 13:34:23 <ag_> I was looking in meta-systemd's readme and saw this:
Oct 08 13:34:28 <RP__> sakoman_: the new layout is nicer on the filesystem
Oct 08 13:34:29 <ag_> To make BBMASK'ing per layer possible the following directory structure is
Oct 08 13:34:29 <ag_> used:
Oct 08 13:34:29 <ag_>                                                                                                                                                                                                                
Oct 08 13:34:29 <ag_> $[LAYERDIR}/<layer name>/recipes-<group-name>/<recipe-name>/<recipe-name>.bbappend
Oct 08 13:34:52 <ag_> How can i do this?
Oct 08 13:35:12 <RP__> ag_: Its talking about the items in that specific layer
Oct 08 13:35:37 <ag_> I know. But how can i bbmask a lyer?
Oct 08 13:37:53 <ag_> It makes no sense...
Oct 08 13:39:28 <JaMa> ag_: layout of make-systemd .bbappends is that they are in layer specific subdirectory
Oct 08 13:40:08 <JaMa> ag_: so if you don't have meta-efl layer then you mask meta-efl subdirectory
Oct 08 13:40:15 <ag_> Indeed.
Oct 08 13:40:28 <ag_> Is this possible for an entire subdirectory?
Oct 08 13:40:33 <ag_> (news for me... :)
Oct 08 13:41:01 <ag_> I thought bbmask is used to mask packages - one? For example BBMASK = "mypackage"
Oct 08 13:41:14 <RP__> ag_: It works against paths
Oct 08 13:41:27 <ag_> RP__: Nice. Ok. Thank you
Oct 08 13:43:16 <ag_> RP__: So, something like this would actually work? BBMASK = "meta-efl/*|meta-gnome/*|meta-multimedia/*"
Oct 08 13:45:28 <kergoth> morning
Oct 08 13:53:55 <RP__> ag_: I can't remember if it uses regexps but something like that
Oct 08 13:54:02 <RP__> hi kergoth
Oct 08 13:54:09 <ag_> RP__: Worked. Thank you.
Oct 08 15:37:38 <hrw> hi
Oct 08 15:37:48 <hrw> when is release date for Yocto?
Oct 08 15:47:11 <seebs> You might have to be more specific. I think Yocto has already had a couple of releases...
Oct 08 16:01:08 <hrw> seebs: iirc Yocto is now at release phase which means freeze for serious updates
Oct 08 16:06:49 <ant_work> hrw: thinking about 3.6.1 ? No way :)
Oct 08 16:07:43 <hrw> ant_work: ? I do not care about kernel in Yocto
Oct 08 16:08:02 <hrw> ant_work: for aarch64 I use our one
Oct 08 16:08:15 <ant_work> no? IMHO it's one of the outstanding features...
Oct 08 16:08:50 <hrw> ant_work: I have newer gnu-config, autotools/insane/siteinfo/kernel-arch classes and some recipes
Oct 08 16:09:02 <ant_work> ok, special case then
Oct 08 16:12:03 <bluelightning> halstead: is the yoctoproject.org mailing list server under load at the moment? the patch series I sent out about half an hour ago took a while to come through and patch 10/11 seems to have got stuck somewhere
Oct 08 16:14:15 <bluelightning> doesn't seem to have made it to the mailman archive either
Oct 08 16:24:30 <hrw> ok, gnu-config update sent
Oct 08 16:28:38 <halstead> bluelightning, Load is low right now. Traffic is a little high but not high enough to slow down e-mail.
Oct 08 16:29:47 <bluelightning> halstead: hmm, could be something between the mailing list server and my machine I guess... can you tell if 10/11 got recieved? should I just re-send it?
Oct 08 16:30:09 <halstead> bluelightning, Yes. One minute.
Oct 08 16:32:43 <hrw> sent few new patches
Oct 08 18:34:45 <msm> was there ever a list of reasonings behind building the toolchain from source all the time?
Oct 08 18:34:59 <msm> some sort of pros / cons
Oct 08 18:41:46 <seebs> I suspect the main thing is that it simplifies life a lot if you know your toolchain is configured for the options you want.
Oct 08 18:41:58 <seebs> Believe me, trying to make it all work with a prebuilt binary toolchain has its own excitements. :)
Oct 08 18:44:35 <hollisb> I know we created a meta-sourcery layer, which is needed in order to build Yocto with a CodeSourcery binary toolchain...
Oct 08 18:46:31 <kergoth> it's also quite nice to be able to build the c library from source. also, it's just the way things are done in the project, everything built from source, so that was just the default approach
Oct 08 18:46:41 * kergoth remembers making the first recipes for the toolchain
Oct 08 19:17:03 * mranostay pokes kergoth 
Oct 08 19:43:43 <zenlinux> This is perplexing....I have created a custom image based on core-image-sato to do a demo with (using a recent master). It boots fine when I make no modifications to the image, but if I add IMAGE_INSTALL += " xterm", it won't boot. "sh: cannot set terminal process group (-1)
Oct 08 19:43:54 <zenlinux> ...Inappropriate ioctl for device"
Oct 08 19:44:01 <zenlinux> has anyone seen this?
Oct 08 19:44:33 <zenlinux> then it dumps me to a recovery shell with no job control
Oct 08 19:48:46 <hollisb> ouch, that sucks :)
Oct 08 20:04:05 <msm> seebs: hollisb: kergoth: thanks for the above info ;)
Oct 08 21:11:42 <RP__> kergoth: still giving you nightmares? :)
Oct 08 21:11:43 <RP__> kergoth: we never did get the 2.95.3 toolchain to build iirc :/
Oct 08 21:11:43 * RP__ is pleased that is history now
Oct 08 21:11:43 <kergoth> indeed. stupid 2.4.6 kernel
Oct 08 21:41:33 <mranostay> gcc 2.95? what year did i wake up in?
Oct 08 21:51:37 <Crofton> zaurus land
Oct 08 21:51:40 <Crofton> I assume
Oct 08 21:57:22 <kergoth> msm: side note, oe-lite builds its own toolchain too, but they use a recipe that just runs crosstool-ng to do it, rather than a pile of individual recipes, which is an interesting alternative approach
Oct 08 22:06:48 <RP__> kergoth: I wonder if its faster/slower...
Oct 08 22:07:06 <kergoth> good question
Oct 08 22:07:48 <RP__> I was intrigued by some comparisons with buildroot toolchain building a while back
Oct 08 22:08:08 <RP__> We're a lot more careful about dependencies which hurts our wall time
Oct 08 22:08:51 <RP__> It also brought home how much slower modern gcc is to build :(
Oct 08 22:09:04 <RP__> mpfr and all that stuff which gcc 3.x never had
Oct 08 22:09:14 <RP__> or had less of anyway
Oct 08 22:24:37 <chackal_sjc> does anyone tried bitbake running under jython or other python vm?
Oct 08 22:31:13 <kergoth> chackal_sjc, I tried PyPy ages ago, and corrected a couple cpythonisms (e.g. __builtins__ vs import __builtin__), but I doubt anyone has tested it recently
Oct 08 22:54:42 <msm> kergoth: RP__: i was just more curious from a how do I convince people to support the yocto method
Oct 08 22:54:54 <msm> several folks inside FSL want to just use a binary toolchain
Oct 08 22:55:15 <msm> im finding it hard to come up with solid one liner reasons why
Oct 08 23:26:06 <Crofton> msm, what is their end goal?
Oct 08 23:37:08 <flynn378> man, as a user and buyer of their arm products I would have to evaluate other products
Oct 08 23:37:26 <msm> Crofton: to not do work
Oct 08 23:37:37 <msm> or not change anything about how they current do things
Oct 08 23:37:58 <flynn378> man,  would that be a good enough one liner
Oct 08 23:38:08 <Crofton> heh
Oct 08 23:38:13 <Crofton> I undertand that
Oct 08 23:40:12 <Crofton> msm I mean what are they supposed to do :)
Oct 08 23:41:03 <flynn378> man, I understand their desire but trying to use the binary compiler has caused me trouble in the past
Oct 08 23:41:07 <Crofton> people love toiolchains, because they undertand how to build hello, world with them
Oct 08 23:41:24 <Crofton> sadly, the rest oof us work on stuff for more involved
Oct 08 23:42:04 <flynn378> msm,  sorry about the auto correct
Oct 08 23:43:40 <msm> it is what it is...
Oct 08 23:43:50 <msm> just trying to effectively change things is almost impossible
Oct 08 23:44:00 <Crofton> I take it you aer having a bad day :)
Oct 08 23:44:23 <Crofton> I am staring at PlanAhead
Oct 09 00:23:17 <waynr> howdy folks
Oct 09 00:25:22 <waynr> i did a little work on a new bbvars.py script but got sidetracked with another project
Oct 09 00:27:21 <kergoth> msm: we use the external sourcery toolchain by default at mentor, only rarely build the internal one
Oct 09 00:31:14 <msm> you guys have lots more compiler resources too ;)
Oct 09 00:31:27 <msm> or rather i suspect
Oct 09 00:31:32 <msm> kergoth: could be wrong
Oct 09 00:38:21 <kergoth> true, but we don't like to bother them unless we really have to :)
Oct 09 00:38:41 * kergoth clones ct-ng to see how well it works nowadays
**** ENDING LOGGING AT Tue Oct 09 02:59:59 2012

**** BEGIN LOGGING AT Tue Oct 09 02:59:59 2012
Oct 09 04:08:13 <thaytan> hmm
Oct 09 04:08:32 <thaytan> I don't understand why including pulseaudio to my distro is pulling in gtk+
Oct 09 04:08:42 <thaytan> it seems that should require DISTRO_FEATURES=x11
Oct 09 04:08:48 <thaytan> but I don't know where x11 is getting added
Oct 09 04:13:17 <thaytan> oh, or maybe it's only a build depend
Oct 09 04:14:07 <evanp> thaytan: did you mean you have your own distro created from scratch? does it define DISTRO_FEATURES?
Oct 09 04:15:02 <evanp> thaytan: I ask because there definition in default-distrovars.inc includes x11....
Oct 09 04:15:19 <evanp> s/there/the
Oct 09 04:15:54 <thaytan> evanp: derived from conf/distro/poky.conf
Oct 09 04:16:45 <kergoth> thaytan: pretty sure there's a recent patch for the pulseaudio/x11 issue..
Oct 09 04:17:11 <kergoth> thaytan: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=5e1f39e
Oct 09 04:21:48 <thaytan> kergoth: yeah, that looks relevant
Oct 09 04:23:53 <thaytan> I'm building against denzil, so don't have that patch
Oct 09 04:40:36 <kergoth> ah, thatd explain it :)
Oct 09 06:09:16 <mranostay> well these isn't good
Oct 09 06:09:19 * mranostay pokes kergoth 
Oct 09 06:24:24 <mertsas> is there a way to add something to a SRC_URI for a recipe only if it is a special machine?
Oct 09 06:24:50 <mranostay> yeah
Oct 09 06:26:21 <mertsas> how? I have tried with a bbappend in the bsp layer, but my thought was to have several bsp layers, and just change MACHINE in my auto.conf file. But then the bbappend will be picked up, regardless of the machine, and my other machines will complain that it can't find the patch
Oct 09 06:35:29 <mertsas> might of course be that I shouldn't do this, and instead change the bsp layer for every time I want to build for a new machine, but would love to avoid that
Oct 09 06:47:15 <mertsas> ofcourse, damn. I can of course do SRC_URI_mymachine += "<patch>" for some reason I thought that only worked for stuff like arm, x86 etc.
Oct 09 07:54:25 <hrw> ;D
Oct 09 07:54:47 <hrw> you can override with: MACHINE, DISTRO, HOST arch, TARGET arch and several others
Oct 09 08:08:08 <mertsas> yeah, I need a duck to talk to before asking to many obvious questions:P
Oct 09 08:14:03 <bluelightning> morning all
Oct 09 08:14:29 <mckoan> good morning
Oct 09 08:14:58 <mertsas> morning
Oct 09 08:23:52 <likewise> gm
Oct 09 08:48:23 <hrw> hi guys
Oct 09 09:02:57 <RP__> morning all
Oct 09 09:03:52 <RP__> JaMa: I have a suspicion the issue you've reported in https://bugzilla.yoctoproject.org/show_bug.cgi?id=3250 is due to excluding DATE from the sstate checksum :/.
Oct 09 09:06:04 <JaMa> RP__: it's DISTRO_VERSION, but I've seen the same errors with different recipes (which don't have DATE in it)
Oct 09 09:07:08 <RP__> JaMa: Can you easily reproduce? The cooker log with -DDD would probably be useful along with the setscene failure log
Oct 09 09:07:37 <RP__> JaMa: A version of this without DATE confusing things would also be helpful
Oct 09 09:07:59 <JaMa> not right now, but I'll attach logs to that bug when I get them
Oct 09 09:08:52 <JaMa> and both cases are with SSTATE_MIRROR defined
Oct 09 09:18:51 <RP__> JaMa: thanks, I'm just at a loss as how to debug/fix it :/
Oct 09 09:19:09 <RP__> JaMa: THe issue isn't that the errors show up, its that it shoudn't be running the setscene task at all
Oct 09 10:52:00 <daniels> RP__: heya, did you see the mesa patch series?
Oct 09 12:15:49 <RP__> daniels: I did, looks good, thanks. Its just waiting on -rc4 being cut and then master and the release branch will separate
Oct 09 12:28:03 <mertsas> RP__: any estimates on when that happens?
Oct 09 12:28:27 <RP__> mertsas: well, -rc4 should be today/tomorrow
Oct 09 12:28:46 <RP__> I really don't want to dive straight back into full steam ahead on master though :/
Oct 09 12:29:13 <mertsas> ok
Oct 09 12:39:23 <daniels> RP__: cool, thanks!
Oct 09 15:00:00 <pidge> YPTT: Beth is here
Oct 09 15:00:15 <tomz1> YPTT: Tom Z here
Oct 09 15:00:22 <evadeflow> David Wolfe of Magneti Marelli here.
Oct 09 15:00:46 <strassek> YPTM: Kevin Strasser is here
Oct 09 15:01:21 <davest> YPTM: davest is in the house
Oct 09 15:01:37 <jzhang> YPTM: jzhang's on
Oct 09 15:01:50 <sgw> TPTM: Saul is dialing!
Oct 09 15:01:58 <darknighte> YPTM: Sean's here
Oct 09 15:01:58 <nitink1> YPTM: nitin is on the bridge
Oct 09 15:01:59 <davest> YPTM: all, Song should be joining soon
Oct 09 15:02:13 <scottrif> YPTM: Scott Rifenbark has joined
Oct 09 15:02:14 <RP__> YPTM: Richard is here...
Oct 09 15:02:18 <darknighte> davest: is it a yocto house?
Oct 09 15:02:27 <RP__> Someone is driving :)
Oct 09 15:02:28 <msm> is saw this on denzil: https://gist.github.com/3859386
Oct 09 15:02:43 <darknighte> RP__: I thought the same thing.  hmmm, it sounds like a left turn to me.
Oct 09 15:03:00 <evadeflow> Oh, yeah--I'm on 'the bridge', too, I guess. But not in, like, a Star Trek way.
Oct 09 15:03:04 <davest> YPTM: "It's a big big house, with lots and lots of room." Sp not a yocto-house
Oct 09 15:03:05 <RP__> darknighte: must be heavy traffic to be sitting that long...
Oct 09 15:03:49 <sgw> Ah our driver!
Oct 09 15:03:51 <bluelightning> YPTM: Paul E is here
Oct 09 15:03:58 <darknighte> RP__: hah.  must be
Oct 09 15:03:58 <Song_liu> YPTM: Please let us know who's on the bridge
Oct 09 15:03:59 <fusman> YPTM: Fahad Usman has joined
Oct 09 15:04:02 <bluelightning> YPTM: and Belen as well
Oct 09 15:04:03 <darknighte> Song_liu: hi
Oct 09 15:04:11 <evadeflow> David Wolfe of Magneti Marelli here, on the bridge.
Oct 09 15:04:19 <darknighte> sgw: I think you're right.
Oct 09 15:04:21 <denix> YPTM: Denys is on the call
Oct 09 15:04:30 <AlexG> Hi
Oct 09 15:04:35 <darknighte> Song_liu: yep
Oct 09 15:04:48 <AlexG> Song_liu: On call also
Oct 09 15:05:28 <darknighte> Song_liu: Amit from MontaVista
Oct 09 15:05:36 * darknighte grins
Oct 09 15:05:38 <rburton> YPTM: ross here
Oct 09 15:06:25 <denix> darknighte always grins - that's his signature trademark... :)
Oct 09 15:06:58 <darknighte> denix: heh, it's good to be known for something.
Oct 09 15:07:40 <Song_liu> YPTM: any opens?
Oct 09 15:14:19 <Song_liu> YPTM: https://bugzilla.yoctoproject.org/buglist.cgi?bug_status=NEW&bug_status=ACCEPTED&bug_status=REOPENED&bug_status=NEEDINFO&bug_status=WaitForUpstream&list_id=16013&priority=Medium%2B&query_format=advanced&target_milestone=1.3&target_milestone=1.3%20M1&target_milestone=1.3%20M2&target_milestone=1.3%20M3&target_milestone=1.3%20M4&target_milestone=1.3%20M5&target_milestone=1.3.1&target_milestone=1.3.2&order=assigned_to%20DESC%2Cprior
Oct 09 15:15:00 <darknighte> now that's a link!
Oct 09 15:15:14 * darknighte grins again
Oct 09 15:17:24 <darknighte> RP__: re: 3080 how does that impact x32 support in 1.3?
Oct 09 15:18:18 <sgw> fray: you around?  On the call?
Oct 09 15:19:07 <sgw> darknighte: I am looking into that one still
Oct 09 15:19:31 <darknighte> sgw: k.
Oct 09 15:19:32 <sgw> darknighte: I can't reproduce it locally, but I am getting access to the QA machine that fails
Oct 09 15:21:08 <RP__> darknighte: It looks like something that can only be reproduced in some circumstances. Still trying to track it down.
Oct 09 15:22:43 <darknighte> k.  i was wondering if it gets moved to 1.4 what that means for X32 in 1.3.
Oct 09 15:23:15 <sgw> darknighte: I am hoping it will be fixed in 1.3, are you seeing this also?
Oct 09 15:23:36 <darknighte> I saw a report internally, but haven't tried it personally
Oct 09 15:26:40 <davest> YPTM: davest needs to drop for another meeting. Sorry sportsfans.
Oct 09 15:27:09 <sgw> darknighte: that's not good, please keep me posted also, if you have any details or can get those details that would be helpful
Oct 09 15:27:20 <darknighte> sgw: will do
Oct 09 15:28:40 <sgw> thanks
Oct 09 15:32:41 <thaytan> any ideas what this is?
Oct 09 15:32:41 <thaytan> ERROR: Function failed: pulseaudio: LIC_FILES_CHKSUM points to an invalid file: /blah/...../pulseaudio-2.1-r7/pulseaudio-2.1/src/pulsecore/vector.h
Oct 09 15:34:01 <darknighte> bluelightning: you said you were going to send an update to the list today?
Oct 09 15:34:22 <darknighte> on the build history django app?
Oct 09 15:34:51 <bluelightning> darknighte: indeed I will
Oct 09 15:35:09 <darknighte> cool.  I will take a look
Oct 09 15:37:39 <darknighte> pidge: you're such a dictator
Oct 09 15:39:46 <pidge> darknighte: I'm working on the funny military uniform decked out with lots of of cool medals I give myself.
Oct 09 15:40:12 <darknighte> pidge: make sure and wear it while piloting the blimp!  ;)
Oct 09 15:40:46 <pidge> darknighte: Hrmmm... the blimp company does make big blimps... /me goes to check out lift capacity.
Oct 09 15:43:17 <darknighte> evadeflow: are you worried about how to carry patches locally?
Oct 09 15:43:20 <denix> who's talking now?
Oct 09 15:43:27 <rburton> denix: evadeflow
Oct 09 15:44:37 <denix> thanks
Oct 09 15:46:07 <rburton> clearly we need a "how to develop using yocto and git" section in the quick start
Oct 09 15:46:20 <bluelightning> rburton: well, the dev manual
Oct 09 15:46:27 <rburton> yeah, or that
Oct 09 15:46:33 <bluelightning> rburton: we have some stuff on that already I think
Oct 09 15:46:41 <rburton> we should just drop the tarball release, it encourages people to use tarballs
Oct 09 15:46:46 <bluelightning> might just need expansion
Oct 09 15:47:04 <rburton> when they really want to be using the stable git branch and branching from that
Oct 09 15:50:37 <darknighte> sgw: evadeflow <<<<---
Oct 09 15:50:40 <evadeflow> This is David Wolfe.
Oct 09 15:50:59 <bluelightning> that's very clever :)
Oct 09 15:51:02 <darknighte> evadeflow: nice anagram
Oct 09 15:51:16 <rburton> yeah, it took me about a week to realise
Oct 09 15:53:56 <msm> so i'll ask again since the call is over, anywhere ever see this: https://gist.github.com/3859386
Oct 09 15:53:57 * thaytan doesn't volunteer for an anagrammatic nickname
Oct 09 15:54:01 <msm> anyone*
Oct 09 15:54:40 <darknighte> msm: fyi: call is still in progress...
Oct 09 15:54:40 <sgw> darknighte: looks like the 3080 issue (x32 eglibc failure) might be a dash/bash issue, that's the first obvious difference I see
Oct 09 15:55:11 <darknighte> sgw: really? interesting.
Oct 09 15:55:13 <msm> darknighte: ahhhhhh
Oct 09 15:55:29 <rburton> evadeflow: i can tell you how my pet project handles using yocto and release if you want
Oct 09 15:55:50 <evadeflow> Sure!
Oct 09 15:56:14 <thaytan> rburton: even your pets have projects?? good delegating!
Oct 09 15:56:32 <rburton> thaytan: [groan]
Oct 09 15:57:00 <pidge> msm: what is the du on the machine.
Oct 09 15:57:01 <rburton> thaytan: shouldn't you be in bed?  clearly it too late for humour ;)
Oct 09 15:57:28 <thaytan> rburton: weekly 9am conf call coming up!
Oct 09 15:57:53 <rburton> thaytan: 9am for who? :)
Oct 09 15:58:26 <thaytan> rburton: well, not me obviously
Oct 09 16:00:06 <rburton> thaytan: that sucks. i have a 6am call on thursday but it's what, 3am for you?
Oct 09 16:00:26 <thaytan> *nod*
Oct 09 16:00:32 <thaytan> thanks to daylight savings
Oct 09 16:00:40 <thaytan> oh well, it'll be 4am in another few weeks
Oct 09 16:02:03 <evadeflow> ::SIGH:: I have to turn off my WIFI tether and get back on the company LAN.
Oct 09 16:02:13 <evadeflow> rburton: Can you email me your pet project setup
Oct 09 16:02:16 <msm> pidge: you mean free space? still plenty
Oct 09 16:02:19 <rburton> evadeflow: sure
Oct 09 16:02:50 <evadeflow> Cool -- thanks. (evadeflow .AT. gmail)
Oct 09 16:03:20 <evadeflow> Bye, all...
Oct 09 16:03:56 <Song_liu> YPTM: thanks everyone for joining the meeting. You have a nice day/evening!
Oct 09 17:14:07 <sgw> darknighte: confirmed (finally), it's a bash/dash issue in the make-syscalls.sh script
Oct 09 17:14:24 <sgw> khem: you around for an eglibc consult
Oct 09 17:15:06 <darknighte> sgw: good news.  glad it was something straightforward after all
Oct 09 17:16:04 <sgw> darknighte: there's the culprit if you are a dash basher:     vdso_symver="${vdso_symver//./_}"
Oct 09 17:16:42 <hollisb> I added dbg-pkgs to EXTRA_IMAGE_FEATURES, and now get a build failure with eglibc-locale-dbg looking for virtual-locale-zh-tw
Oct 09 17:16:46 <hollisb> http://fpaste.org/UtKF/
Oct 09 17:17:06 <kergoth> hollisb: i think that may have been fixed in a patch recently, check the lists
Oct 09 17:17:09 <kergoth> at least, its ringing a bell
Oct 09 17:17:40 <hollisb> looking
Oct 09 17:19:43 <hollisb> kergoth: hmm, I'm not seeing anything
Oct 09 17:20:28 <hollisb> oh wait, I'm not subscribed to the poky@ list
Oct 09 17:21:34 <hollisb> nope, still not seeing anything
Oct 09 17:21:58 <kergoth> [OE-core] [PATCH] package: Recommend virtual-locale-*, don't depend on it
Oct 09 17:22:15 <kergoth> not sure if that'll fix that issue, but it's obviously related
Oct 09 17:23:00 <khem> sgw: whats up
Oct 09 17:24:16 <sgw> khem, I have just tracked down a bash
Oct 09 17:24:55 <sgw> khem: try again: I have tracked down a possible bash'ish in the make-syscalls.sh script in eglibc, is it supposed to be dash compliant or not?
Oct 09 17:26:02 <sgw> Khem: here's the test script (from around lines 250 in make-syscalls.sh):
Oct 09 17:26:05 <sgw> vdso_syscall="__vdso_gettimeofday@LINUX_2.6"
Oct 09 17:26:05 <sgw>     # In the shared library, we're going to emit an IFUNC using a vDSO function.
Oct 09 17:26:05 <sgw>     # $vdso_syscall looks like "name@KERNEL_X.Y" where "name" is the symbol
Oct 09 17:26:05 <sgw>     # name in the vDSO and KERNEL_X.Y is its symbol version.
Oct 09 17:26:05 <sgw>     vdso_symbol="${vdso_syscall%@*}"
Oct 09 17:26:06 <sgw>     vdso_symver="${vdso_syscall#*@}"
Oct 09 17:26:06 <sgw>     vdso_symver="${vdso_symver//./_}"
Oct 09 17:26:43 <sgw> khem: the last line passes bash, but fails with a Bad substitution in dash
Oct 09 17:29:41 <khem> eglibc no
Oct 09 17:29:47 <khem> its full of bashism
Oct 09 17:29:58 <khem> but if you can clean it up that ok
Oct 09 17:30:52 <sgw> khem, thanks! I wonder why we have not stumbled on this before, I thought folks where doing full dash builds.
Oct 09 17:32:44 <khem> dash also has fixes
Oct 09 17:32:53 <khem> so depends on with version of dash is in use
Oct 09 17:32:58 <khem> and distro
Oct 09 17:34:23 <sgw> khem: and in this case what our target is, only triggers with x32!
Oct 09 17:34:44 <khem> hmmm that makes it clear
Oct 09 17:35:08 <sgw> khem: so core arches/multilib works but x32 fails!
Oct 09 17:35:31 <khem> since that syscall script is depending on syscalls the target arch supports
Oct 09 17:35:51 <khem> cook up a fix it will be accepted
Oct 09 18:03:53 <sgw> t
Oct 09 18:14:58 <sgw> khem: BTW, what happened with the other eglibc issue that I reported to the list, I never got any feedback on the LIBM_BIG issue (sent to eglibc-issues)
Oct 09 18:43:03 <khem> sgw: I should have replied :)
Oct 09 18:43:06 <khem> but I did not
Oct 09 18:43:11 <khem> time
Oct 09 18:43:22 <khem> pidge: I still get this warning
Oct 09 18:43:23 <khem> WARNING: bzip2: No generic license file exists for: bzip2 in any provider
Oct 09 18:43:23 <khem> WARNING: busybox: No generic license file exists for: bzip2 in any provider
Oct 09 18:43:41 <khem> both on master and danny
Oct 09 18:49:05 <sgw> khem no worries, things slide!
Oct 09 18:49:19 <hollisb> amusing typo of the day: "debubbing" (http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#workflow-using-the-adt-and-eclipse)
Oct 09 18:54:44 <chackal_sjc> where can I send a patch? mainling list?
Oct 09 18:55:03 <sgw> khem: I am going down a slippery slop with the de-bashing and x32, one lead to another to ..., lovely little bit of code gen going on in make-syscall.sh!
Oct 09 19:32:59 <pidge> khem: I just put the patch in.
Oct 09 19:33:34 <pidge> khem: what happens when I get called away in the middle of trying to fix something :/
Oct 09 22:23:25 <zenlinux_> Which oe-core package provides /sbin/init? I'm using coreutils, so no busybox.
Oct 09 22:26:55 <bluelightning> zenlinux_: surely sysvinit?
Oct 09 22:27:37 <zenlinux_> bluelightning, thanks, I really should have thought of that
Oct 09 22:27:56 <kergoth> zenlinux_: also, installing coreutils doesn't necessarily mean you don't have busybox installed also :)
Oct 09 22:27:59 * kergoth yawns
Oct 09 22:28:57 <zenlinux_> kergoth, yes, but apparently including it in an image made it unbootable - I'm running through a trivial image customization step and was surprised I could so easily create an image that wouldn't boot (no init found)
Oct 09 22:30:10 <bluelightning> zenlinux_: I'm assuming you didn't just completely override IMAGE_INSTALL and thus removed packagegroup-core-boot, which is what pulls in sysvinit?
Oct 09 22:30:48 <zenlinux_> bluelightning, just used IMAGE_INSTALL += in my custom image recipe
Oct 09 22:31:08 <bluelightning> zenlinux_: did you do that before the inherit core-image line ?
Oct 09 22:31:21 <zenlinux_> aha! yes
Oct 09 22:31:35 <zenlinux_> and I did that because that's what was in the core-image-sato recipe that I copied my custom recipe from
Oct 09 22:31:42 <bluelightning> that ?= has been somewhat troublesome...
Oct 09 22:31:51 <zenlinux_> I may recall we fixed that in master? I'm doing this demo with denzil
Oct 09 22:31:53 <bluelightning> really? that's probably wrong then
Oct 09 22:33:03 <zenlinux_> I'll make a note this needs to get fixed in denzil
Oct 09 22:33:15 <zenlinux_> move the inherit line before IMAGE_INSTALL gets appended
Oct 09 22:33:27 <bluelightning> zenlinux_: er, core-image-sato doesn't even set IMAGE_INSTALL in denzil...
Oct 09 22:33:58 <zenlinux_> bluelightning, oh, you're right. I just inserted it myself at the wrong location.
Oct 09 22:34:32 <bluelightning> I do wonder if we should change our examples so that they're less confusing in that regard though
Oct 09 22:34:47 <bluelightning> i.e. move the inherit as close to the top as possible
Oct 09 22:35:01 <zenlinux_> yes, that seems wise
Oct 09 22:35:26 * zenlinux_ has to jet
Oct 09 22:39:59 <mranostay> anyone getting this with a powerpc build? --> undefined reference to `feraiseexcept'
Oct 09 23:07:41 <nitink1> rburton: ping
Oct 10 00:10:47 <b1gtuna> hello everybody, does anyone know if it's normal for some files in build/tmp/sysroots/MACHINE/ not to become part of the final image?
Oct 10 00:11:00 <b1gtuna> I'm missing some shared objects in my tar
Oct 10 02:18:24 <kergoth> sysroots have nothing to do with what goes into the image
Oct 10 02:18:30 <kergoth> they're used to build things, thats it
Oct 10 02:18:38 <kergoth> if you want something in your image, add the appropriate package to the image
**** ENDING LOGGING AT Wed Oct 10 02:59:58 2012

**** BEGIN LOGGING AT Wed Oct 10 02:59:58 2012
Oct 10 06:13:08 <mranostay> kergoth: around still? :)
Oct 10 08:48:39 <mertsas> mranostay: just ask, guess there are quite a few people here who can answer :)
Oct 10 09:02:46 <mckoan> good morning
Oct 10 09:49:05 <hrw> mranostay: like old irc rule says: "do not ask to ask but ask" and taking timezone differences in mind you should just ask instead of waiting for someone from USA to became alive on channel
Oct 10 09:55:00 <likewise> gm
Oct 10 13:36:11 <jwessel> bluelightning: Ping.
Oct 10 13:36:31 <bluelightning> jwessel: hi, just in a meeting - can I get back to you?
Oct 10 13:36:37 <jwessel> But of course.
Oct 10 13:37:22 <jwessel> Since you were the last one poking at the hob, I had a generic question or two to point me in the right direction. :-)
Oct 10 14:15:30 <likewise> Did anybody try a build for TI AM3730 EVM using denzil? I probably run into gcc 4.6.x problems. This is without distro.
Oct 10 15:04:19 <bluelightning> jwessel: ok, I'm back - fire away
Oct 10 15:04:53 <jwessel> I am trying to figure out how the HOB builds it list of packages to install to the target file system.
Oct 10 15:05:29 <jwessel> I want to be able to obtain the list, not through the hob, so as to create a static IMAGE_INSTALL_forcevariable := ....  later on.
Oct 10 15:06:09 <jwessel> in hob terms, you do select target, select image (smallest available in this case), then edit image
Oct 10 15:06:24 <jwessel> Next click build packages.
Oct 10 15:06:43 <jwessel> Somehow at this point the hob now knows what will be installed to the target and it is in a giant list.
Oct 10 15:07:34 <jwessel> I had hoped it was as simple as doing something like bitbake -e "image" -c some_rule_that_does_not_appear_to_exist
Oct 10 15:07:45 <bluelightning> well, at that point we're talking about recipes that need to be built; it can use bitbake's internal code to work out the dependencies
Oct 10 15:08:49 <jwessel> I figure I might have to write a do_dump_something possibly in the image.bbclass or packages.bbclass, but it is not obvious to me where to put this.
Oct 10 15:09:58 <jwessel> I had just assumed the hob was asking bitbake / oe-core to do things the same way they get computed for what goes to the target for installed packages.
Oct 10 15:10:23 <jwessel> I know we talked about this a while back, and there is an easy way to get what is built, but how do I get what is going to be installed?
Oct 10 15:10:39 <jwessel> It doesn't matter that we have to build all the packages first in this case.
Oct 10 15:13:42 <bluelightning> jwessel: there are really only two approaches; either you interpret the output of bitbake -g to produce the list which as we've discussed is not necessarily accurate (since the rootfs construction is largely under the control of the package manager i.e. rpm in your case)
Oct 10 15:14:05 <kergoth> why not just save hob's image out and edit it?
Oct 10 15:14:14 * kergoth is confused as to the goal here
Oct 10 15:14:22 <jwessel> kergoth: I do that, and it works, but I don't  want to use the hob.
Oct 10 15:14:28 <kergoth> and?
Oct 10 15:14:37 <kergoth> once you have the image, you dont need to use it with hob
Oct 10 15:14:38 <bluelightning> jwessel: or you get the package manager to tell you what it installed during do_rootfs
Oct 10 15:14:45 <jwessel> I want to just emit the list of what the HOB was going to install.
Oct 10 15:15:02 <kergoth> so look at the image it created
Oct 10 15:15:05 <kergoth> problem solved.
Oct 10 15:15:09 <jwessel> kergoth: The use case is a system where I cannot run the hob.
Oct 10 15:15:49 <kergoth> so create your own image with your  own package list, or copy the hob created image from one machine to another, or examine the rootfs buildhistory, or any number of other options
Oct 10 15:18:04 <jwessel> Somewhere in the bitbake code it and or hob it makes the leap to expand IMAGE_INSTALL, and I just want to be able to print that without actually calling do_rootfs() (something that can be quite time consuming with a 3-4gig rootfs).
Oct 10 15:18:08 <RP> jwessel: Hob is basically interpreting data files which are in the build directories. We don't currently abstract that functionality
Oct 10 15:18:12 <jwessel> Because the first thing I am going to do is customize the list.
Oct 10 15:18:53 <RP> jwessel: It is something that probably should get abstracted. The complexity is that its maintained as a gtk treeview iirc :/
Oct 10 15:19:00 <jwessel> RP does that imply that that there is enough data after building the packages but not calling do_rootfs() that everything you need is there?
Oct 10 15:19:42 <RP> jwessel: you can query the rdepends, rrecommends and so on of all the packages. Whether you use the same algorithm as any give package manager is questionable though
Oct 10 15:20:05 <RP> jwessel: hob is making a "best guess" which is probably close enough
Oct 10 15:20:27 <fray> that has always been the issue.. we can guess as to what will be on the image, but only the package management system can do the final image
Oct 10 15:21:19 <jwessel> The element of removing a simple package from the install image seems way to overly complex.
Oct 10 15:21:29 <jwessel> Is there a filter or some mechanism I just don't see?
Oct 10 15:21:57 <fray> you can manipulate the IMAGE_INSTALL and IMAGE_FEATURES.. but that is about it..
Oct 10 15:22:10 <fray> if the item is a dependency, it will come in, there is no way to stop it that isn't package manager specific..
Oct 10 15:22:51 <RP> jwessel: it depends what you mean by "remove" as fray says
Oct 10 15:23:01 <jwessel> fray:  There is an element missing here.
Oct 10 15:23:35 <jwessel> I'll provide an example.
Oct 10 15:23:49 <jwessel> % bitbake -e $DEFAULT_IMAGE |grep ^IMAGE_INSTALL
Oct 10 15:23:49 <jwessel> IMAGE_INSTALL="task-core-boot     kernel-modules      task-core-tools-debug memstat"
Oct 10 15:23:51 <fray> i.e. if INSTALL_IMAGE says packagegroup-boot (and that is it).. then all you can 'remove' is that one item..
Oct 10 15:24:11 <jwessel> But the hob expands all this in its "guess the rootfs phase".
Oct 10 15:24:36 <jwessel> The .hob file has an explanded INSTALL_IMAGE which you can copy out and remove things, if you put it in your local.conf.
Oct 10 15:24:36 <fray> but it's just a guess.. you can't actually remove anything AFAIK..
Oct 10 15:24:42 <jwessel> I want the expansion.
Oct 10 15:25:15 <fray> any dependencies will still come back in.. there is no way to stop a dep..  (except for package manager specific ways.. i.e. RPM you can tell it that something is already provided)
Oct 10 15:25:49 <jwessel> And it seems the only way to get it, is to write a do_show_me_the_fs()  { that just calls do_rootfs() and doesn't bother with the install phase and instead prints what it would have done }
Oct 10 15:26:12 <bluelightning> if you want something that is not a guess, yes
Oct 10 15:26:27 <RP> jwessel: hob does have a way to emulate what rpm or other package mamagers would do as a resolution. Its not perfect though and things could get added back in
Oct 10 15:27:12 <jwessel> RP that does me little good.  I just want a line of packages not some gtk-laiden application.
Oct 10 15:27:46 <RP> jwessel: we do not have an easy solution to hand to you for this right this second
Oct 10 15:28:17 <RP> jwessel: yes, hob can do it but not in a way you could use right now
Oct 10 15:29:16 <bluelightning> as I mentioned earlier, the inaccurate but possible fix right now would be to expand IMAGE_INSTALL using the package graph from bitbake -g (or the code behind it)
Oct 10 15:29:45 <fray> that should at least give you a graph of what is being built for an image..
Oct 10 15:29:50 <bluelightning> that's pretty much going to end up with the list that Hob produces if I'm not mistaken
Oct 10 15:30:07 <RP> bluelightning: hob uses the pkgdata so its a bit different
Oct 10 15:30:28 <bluelightning> RP: right, you could resolve using pkgdata, actually that's much more likely to be accurate
Oct 10 15:31:22 <bluelightning> jwessel: you could extend oe-pkgdata-util to have a mode that does the resolution
Oct 10 15:31:43 <fray> one possible way is to construct a dummy - empty package that provides/rprovides everything you want to skip..
Oct 10 15:31:56 <fray> then use PREFERRED_PROVIDER to force that item to be used..
Oct 10 15:32:07 <fray> not completely sure it'll work though with the packaging back-ends..
Oct 10 15:32:28 <bluelightning> fray: the trouble with that is, giving a user a way to blindly elide any particular dependency without satisfying or removing it properly is a recipe for broken images...
Oct 10 15:32:55 <bluelightning> we do need to improve our tools around this issue, no argument with that
Oct 10 15:33:03 <fray> absolutely.. here is the rope.. BTW it's coated in glass shards.. don't hang yourself.. :P
Oct 10 15:33:07 <bluelightning> :)
Oct 10 15:33:36 <fray> in the end I think the answer to this kind of question comes down to distro configuration..  if you can lead the user through the distro configuration, you can eliminate the things we 'support' eliminating..
Oct 10 15:33:40 <fray> i.e. pam, acl, etc..
Oct 10 15:34:36 <bluelightning> what I think would be ideal would be a tool that allowed you to easily track down the recipe and dependency chain of how a specific package got pulled in; at the moment getting that information can be an involved manual exercise
Oct 10 15:35:21 <bluelightning> fray: right, that would help a great deal as well
Oct 10 15:42:34 <ant_work> http://www.gentoo.org/doc/en/gentoolkit.xml
Oct 10 15:42:50 <ant_work> I think most code could be taken from there
Oct 10 15:57:35 <kergoth> RP: is the 1.3 release schedule on the wiki? specifically, when the rc's will hit, and when the final is expected to hit (estimated)
Oct 10 15:58:11 <RP> kergoth: https://wiki.yoctoproject.org/wiki/YoctoCalendar ?
Oct 10 15:58:29 <RP> kergoth: in short -rc4 today and its hoped to be the final rc that becomes release
Oct 10 15:58:42 <kergoth> ah, thanks
Oct 10 15:59:23 <RP> kergoth: we do have a -rc5 slot but its emergency use only
Oct 10 16:01:24 <bluelightning> graphic on that page is not up-to-date of course, you have to click on the link to get to the actual calendar
Oct 10 16:02:15 <kergoth> not sure how i missed that wiki page
Oct 10 16:02:18 * kergoth nods
Oct 10 16:03:14 <bluelightning> well there's no link to it from the 1.3 page I don't think
Oct 10 16:03:24 <bluelightning> it would be easiest if the dates were just spelled out
Oct 10 16:03:37 <kergoth> ah
Oct 10 16:46:23 <khem> gm all
Oct 10 17:09:18 <b1gtuna> Good morning, does anyone know if every file in build/tmp/sysroots/MACHINE should become part of the rootfs image? Some files aren't getting copied over
Oct 10 17:09:48 <kergoth> i explained this yesterday
Oct 10 17:09:58 <kergoth> no, the contents of sysroots do not go into the image
Oct 10 17:09:59 <b1gtuna> kergoth: erg, sorry I must have left
Oct 10 17:10:06 <b1gtuna> kergoth: i see..
Oct 10 17:10:08 <kergoth> the sysroots are used for building, only
Oct 10 17:10:16 <kergoth> if you want soemthing in your image, you need to add the correct binary package to the image
Oct 10 17:10:35 <kergoth> the files aren't copied over, they're packaged into ipk, deb, or rpm and are then installed into the root filesystem for the image
Oct 10 17:10:48 <b1gtuna> kergoth: hmmm
Oct 10 17:11:00 <kergoth> look i tmp/deploy/ipk/ (or rpm)
Oct 10 17:11:15 <b1gtuna> kergoth: ok I will look at my packages first
Oct 10 17:11:21 <b1gtuna> kergoth: thanks for clarification
Oct 10 17:11:46 <b1gtuna> kergoth: bascially some lib files that exist in sysroots are required in my rootfs to get gstreamer working with my image sensor
Oct 10 17:12:00 <b1gtuna> kergoth: I thought it was a bug.. but I guess it's expected.
Oct 10 17:14:45 <kergoth> images install what the image recipe asks for, along with what's added via mechaisms like EXTRA_IMAGE_FEATURES and CORE_IMAGE_EXTRA_INSTALL, that's all
Oct 10 17:24:47 <mranostay> so "Unknown package 'task-core-standalone-sdk-target'."
Oct 10 17:25:31 * kergoth knows nothing about the sdk stuff, need to play with that one of these days
Oct 10 17:25:45 <mranostay> crap :)
Oct 10 17:26:01 <mranostay> this was working till i updated the repo :)
Oct 10 17:26:43 <zenlinux_> sato / matchbox experts - I'm running a demo to auto-launch an application when sato starts. Is there a better mechanism to do this than from the ~/.matchbox/session script?
Oct 10 17:27:31 <bluelightning> mranostay: the reference probably needs to be changed to packagegroup-core-standalone-sdk-target
Oct 10 17:27:35 <zenlinux_> specifically I'd like to avoid the two-step process of creating the session file from /etc/matchbox/session and then modifying it. Would like a standalone file I can add to my image.
Oct 10 17:29:15 <mranostay> bluelightning: i figured as much would be nice to be backwards compatiable
Oct 10 17:30:53 <bluelightning> mranostay: actually, we do have RPROVIDES/RREPLACES/RCONFLICTS set up for that recipe so I'm not sure how you're getting that error...
Oct 10 17:38:09 <RP> bluelightning: we were seeing that from the values in hob too so there is some problem with the provides
Oct 10 17:38:23 <RP> bluelightning: could it be rpmresolve isn't looking at those correctly?
Oct 10 17:39:28 <bluelightning> RP: "unknown package" is not an rpmresolve error
Oct 10 17:40:40 <bluelightning> RP: though it may be possible as a separate limitation that it won't resolve runtime provides that aren't actual package names
Oct 10 17:42:07 <mranostay> and if i bitbake that task it finds it
Oct 10 17:45:13 <bluelightning> mranostay: what poky (or OE-Core) revision are you using?
Oct 10 18:03:10 <zenlinux_> What's the current best practice for setting LICENSE when you have a custom recipe that, for example, just crates a custom config file?
Oct 10 18:04:09 <Crofton> is they schedule for dev day up yet?
Oct 10 18:04:33 <zenlinux_> Jefro would be the one to answer that
Oct 10 18:04:42 <zenlinux_> I know it's not up yet, not sure when it will be
Oct 10 18:50:14 <fray> I've got a space seperated list, is there an easy way to remove duplicates?
Oct 10 18:52:42 <kergoth> if order doesn't matter, just split and pass to set(). if order matters, you'll need an iterator to do it
Oct 10 18:53:54 <fray> split -- set and then join?
Oct 10 18:54:06 <fray> (ya order does not matter.. I just want to get rid of the duplicates)
Oct 10 18:56:37 <Jefro> Crofton Dev Day schedule should be posted today
Oct 10 18:58:21 <Crofton> thanks
Oct 10 18:58:31 <Crofton> there was a question in #beagle
Oct 10 19:01:32 <kergoth> fray: yeah. ' '.join(set(foo.split()))
Oct 10 19:01:36 <kergoth> that's what i'd do, anyway
Oct 10 19:01:44 <fray> excellent.. thanks
Oct 10 19:55:15 <seebs> Am I right to think that bitbake is running shell stuff under 'set -e'?
Oct 10 20:17:47 <msm> seebs: there is still the wrapper script
Oct 10 20:19:50 <seebs> I note that it starts out #!/bin/sh -e.
Oct 10 20:20:46 <seebs> I am wondering whether this is negotiable, because I sort of hate -e. It works pretty well much of the time, but when it fails, it fails silently and without explanation, and there are a heck of a lot of programs out there which use exit statuses to indicate things which are not really "failure".
Oct 10 20:30:24 <kergoth> whew, finally have a shell script that spawns bitbake and handles SIGINT well. has to brute force shut down bitbake, though, as it doesn't respond well to SIGTERM
Oct 10 20:31:02 <kergoth> http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/tree/scripts/reloc-tests?id=e2b7b9a
Oct 10 20:31:31 <kergoth> given a target, rebuilds every recipe up to that, linearly (where possible), from scratch, with all of its deps prebuilt from a different tmpdir
Oct 10 20:32:11 * kergoth cleans it up a bit
Oct 10 20:32:45 <kergoth> seebs: i think it's better to have a problem case of failing out when you dont want it to, than continue and silently do the wrong thing :)
Oct 10 20:33:15 <seebs> I would probably feel better about it if the -e produced a failure diagnostic of some sort.
Oct 10 20:33:56 <kergoth> it'd e nice if there was a way to set -x, but redirect the extra output elsewhere unless we encounter a failure, somehow :)
Oct 10 20:34:01 <seebs> I guess... My experience with -e overall has been that it's not a very *good* safety net. Too many silent failures, and I'm not sure it catches very many real problems, because a surprising number of programs either are expected to "fail" or don't use exit statuses.
Oct 10 20:34:03 <seebs> Huh.
Oct 10 20:34:16 <seebs> That we can probably do. Although merging it is hard. Hmmmmm.
Oct 10 20:34:32 <seebs> The hard part would be getting the stderr/stdout interleaved correctly again.
Oct 10 20:34:34 <kergoth> right, but a silent failure is better than silently doing something wrong
Oct 10 20:34:36 <kergoth> right
Oct 10 20:34:42 <kergoth> would probably have to capture the timing or something
Oct 10 20:34:43 <kergoth> nontrivial
Oct 10 20:38:00 <seebs> Huh.
Oct 10 20:38:44 <seebs> You know, overall, I am not sure it would be that bad to just have -x on all the time; it's not that many lines of output.
Oct 10 20:39:17 <seebs> Anyone object to a change to the wrapper to diagnose exits with something like "Exiting prematurely due to failed command, status $?."?
Oct 10 20:39:54 <seebs> It would solve my biggest problem with the set -e, which is the lack of any indication of what went wrong. If we are comfortable assuming bash, I think we can get a backtrace, but I am not super happy with that assumption.
Oct 10 20:40:28 <kergoth> seebs: the thing i dislike about set -e is this pattern i end up using everywhere: local ret=0; do_something || ret=$?; cleanup; if [ $ret -eq 0 ]; then :;fi
Oct 10 20:40:33 <kergoth> s/fi/ fi/
Oct 10 20:40:38 <seebs> Yeah.
Oct 10 20:40:43 <seebs> Hmm.
Oct 10 20:40:57 <kergoth> heh
Oct 10 20:41:01 <seebs> What if we had a flag for actions that indicated not to use -e?
Oct 10 20:41:20 <kergoth> sounds like it'd be more trouble than its worth, its easy enough to set +e in your task if you need to..
Oct 10 20:41:23 * kergoth shrugs
Oct 10 20:41:40 <seebs> But also easy to forget to set it back. :)
Oct 10 20:43:30 <kergoth> doesn't need to stay temporary, unless you're concerned about appends. just handle the failures explicitly
Oct 10 20:43:40 <seebs> Oooh.
Oct 10 20:43:47 <seebs> What if we used trap ERR instead of set -e?
Oct 10 20:45:17 <kergoth> would that actually buy us anything, though?
Oct 10 20:45:18 <seebs> Part of the issue is that -e semantics are... wobbly.
Oct 10 20:45:33 <seebs> Well, it'd let us do more flexible things. Hmm.
Oct 10 20:45:43 <seebs> e.g., the behavior of -e and pipes varies between bashes.
Oct 10 20:46:20 <kergoth> does ERR handling change in that regard too, or just -e?
Oct 10 20:46:25 <kergoth> that's an interesting idea though
Oct 10 20:46:26 * kergoth ponders
Oct 10 20:46:59 <seebs> ERR probably does too. But! It gives us an option for stuff like "*** WARNING: Command at foo.sh line 23 yielded exit status 1 ***".
Oct 10 20:47:04 <kergoth> http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/tree/scripts/reloc-tests?id=e2b7b9a#n59 - hehe. this is not the prettiest code..
Oct 10 20:47:08 <kergoth> ah, good point
Oct 10 20:47:12 <kergoth> that would indeed be cool
Oct 10 20:50:42 <seebs> ah-hah
Oct 10 20:51:16 <RP> kergoth: I'd also meant to try the opposite of that script, do a world population of the sysroot, build it, then compare with buildhistory against a version with on the minimal DEPENDS installed
Oct 10 20:51:21 <kergoth> aside: <3 http://www.cons.org/cracauer/sigint.html
Oct 10 20:51:32 <kergoth> RP: that's a good idea
Oct 10 20:51:38 <RP> kergoth: keeping a build history of the output of that script would be handy
Oct 10 20:52:45 <seebs> Hmm.
Oct 10 20:52:50 <seebs> Okay, I have a suggestion.
Oct 10 20:52:56 <seebs> Which is to use an ERR trap instead of -e.
Oct 10 20:53:26 <seebs> Because then, in bash, we can generate WARNING: /path/to/run.do_compile.xxx:76 exit 1 from "command"
Oct 10 20:53:57 <seebs> Hmm. That's bash-only, though.
Oct 10 20:56:09 <seebs> Well, I can make it prettier everywhere, and much prettier in bash.
Oct 10 21:07:59 <mranostay> so what magic does this relocatable SDK do?
Oct 10 21:09:45 <b1gtuna> kergoth: Are you here? =D I asked a question earlier about missing files in my rootfs. I found the missing file in an rpm package. I could manually install it on my deployed image, but do you know if there is a more correct way? (ie nothing manual involved?)
Oct 10 21:17:59 <kergoth> b1gtuna: as i said earlier, there's the image itself, and there's CORE_IMAGE_EXTRA_INSTALL in local.conf
Oct 10 21:24:50 <b1gtuna> kergoth: oh.. wasn't aware of CORE_IMAGE_EXTRA_INSTALL!!! thank youu
Oct 10 22:12:23 <seebs> I sent out a patch for that set -e thing. Lightly tested; it diagnoses what happened if I add a "false" in the middle of a rule, anyway.
Oct 10 22:22:07 * RP is getting a little distracted by the autobuilder choosing -rc4 to find new ways of host contamination 
Oct 10 22:29:00 <kergoth> seebs: might be more obvious to trap the named signal rather than 0, unless thats a portability concern?
Oct 10 22:29:11 <kergoth> that is, EXIT
Oct 10 22:29:23 * kergoth gets food
Oct 10 22:52:45 <seebs> I am not sure how portable the name EXIT for signal 0 is. There's no actual SIGEXIT.
Oct 10 22:53:33 <kergoth> afaik there's no signal 0 either, it's just shell internal
Oct 10 22:53:36 <seebs> I think the EXIT name is a bash alias for 0.
Oct 10 22:54:04 <seebs> Hmm. dash doesn't seem to document it, but it seems to work.
Oct 10 22:54:15 * kergoth checks SuSv4
Oct 10 22:55:44 <seebs> Huh, apparently it's not portable to assume that $? is correct in a trap handler.
Oct 10 22:55:49 <kergoth> so EXIT/0 isn't in susv4, so we're just lucky that both dash and bash support it
Oct 10 22:55:51 <kergoth> huh, interesting
Oct 10 22:56:11 <seebs> Note that "portable" in that case is from my shell book, so it's a much much broader range than we likely care about.
Oct 11 01:08:09 <kergoth> <3 mosh (http://mosh.mit.edu/)
Oct 11 01:08:21 <kergoth> if only it had auth agent forwarding..
Oct 11 01:19:12 <chackal_sjc> scenario: i have 2 recipes that declaries the same packages but different versions, one is git with AUTOREV and another with a specific commit
Oct 11 01:19:42 <chackal_sjc> how can I select which one to include into a image?
Oct 11 01:19:58 <chackal_sjc> I know that I can use a PREFERRED_VERSION in a distribution.conf
Oct 11 01:20:21 <chackal_sjc> is it the only way?
Oct 11 01:21:01 <chackal_sjc> because then I would have to create a new distro.conf and change the local.conf right?
Oct 11 01:24:47 <seebs> kergoth, that is a really, really, cool app. Thanks for the link.
Oct 11 01:25:46 <kergoth> np
Oct 11 01:26:10 <kergoth> i love having my laptop suspending, then resuming, and my session just comes back and i continue where i left off
**** ENDING LOGGING AT Thu Oct 11 02:59:58 2012

**** BEGIN LOGGING AT Thu Oct 11 02:59:58 2012
Oct 11 03:52:25 <hollisb> if I create a new /var/default/volatiles/99_foo file after first boot, and put the right contents in there, it should be found and used by populate-volatile.sh at the next reboot, right?
Oct 11 03:55:20 <hollisb> never mind... had to open up populate-volatile.sh to figure it out
Oct 11 03:55:39 <hollisb> (this system is, shall we say, "ripe for documentation" ;)
Oct 11 09:42:50 <jackmitchell> are their some network issues on going, whenever I try to build I get the following error message:     Failed to fetch test data from the network. Please ensure your network is configured correctly.
Oct 11 09:44:35 <JaMa> jackmitchell: test urls are sometimes slow and then this test timeouts and fails
Oct 11 09:46:04 <jackmitchell> JaMa: the error pops up after a few seconds, surely the timeout should be longer than that?
Oct 11 09:47:06 <JaMa> meta/conf/bitbake.conf:FETCHCMD_wget = "/usr/bin/env wget -t 2 -T 30 -nv --passive-ftp --no-check-certificate"
Oct 11 13:41:03 <sgw> fray: you awake yet?
Oct 11 15:07:27 <bluelightning> can anyone think of anything that might be missing from this: https://wiki.yoctoproject.org/wiki/Yocto_Project_1.3_Migration_notes
Oct 11 15:16:17 <ag_> Anybody experienced issues with dbus while having /var/volatile mounted as tmpfs?
Oct 11 15:16:50 <ag_> It seems like while mounting the corresponding directories in volatile can't be accessed.
Oct 11 15:16:56 <ag_> This makes dabus fail.
Oct 11 15:17:00 <ag_> dbus*
Oct 11 15:20:02 <ag_> I'm talking of a case where systemd is the init process.
Oct 11 18:06:28 <Crofton> bluelightning, by companion sdk for image, do you mean a cross or native sdk?
Oct 11 18:07:48 <bluelightning> Crofton: that's actually one of Mark's features, but the feature item should be clear, good point
Oct 11 18:08:24 <Crofton> yep
Oct 11 18:08:37 <bluelightning> bbl
Oct 11 18:08:41 <Crofton> l8r
Oct 11 18:44:40 <zenlinux> RP, I just sent a denzil pull request to the poky ML. I had forgotten that my poky branch included two important bitbake commits that still need to be merged.
Oct 11 18:47:37 <RP> zenlinux: ah, ok
Oct 11 20:03:36 <msm> zenlinux: ping
Oct 11 20:03:46 <zenlinux> msm, hello
Oct 11 20:03:57 <msm> zenlinux: i just read your message, are the two bitbake commits these:
Oct 11 20:03:58 <msm> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mattsm/denzil
Oct 11 20:04:08 <msm> i was going to confirm what happened to those
Oct 11 20:04:12 * kergoth ponders
Oct 11 20:04:18 <zenlinux> msm, yep, that's them
Oct 11 20:04:27 <msm> zenlinux: k, thanks
Oct 11 20:21:57 * kergoth thinks about how to get reloc-tests to also be able to do RP's idea for greedy-dep testing
Oct 11 20:29:51 <ag> Is there any doc about PACKAGECONFIG?
Oct 11 20:30:02 <ag> I try to understand the way it works...
Oct 11 20:34:37 <kergoth> it's just a space separated list of words. if a word is set there, then the PACKAGECONFIG[thatword] is obeyed. the latter is a comma separated list. autoconf disable arg, autoconf eanble arg, dependencies if enabled, rdependencies if enabled
Oct 11 20:34:42 <kergoth> thats all tehre is to it
Oct 11 20:34:52 <kergoth> often the default value of a recipe's PACKAGECONFIG will obey DISTRO_FEATURES, but that's not a requirement
Oct 11 20:40:35 <ag> kergoth: Ok. But if i want for example xorg without glx.
Oct 11 20:40:40 <ag> Where to specify this PACKAGECONFIG?
Oct 11 20:40:49 <ag> kergoth: In an append right?
Oct 11 20:41:34 <kergoth> PACKAGECONFIG_pn-somerecipe = 'bar' in local.conf
Oct 11 20:41:35 <kergoth> done.
Oct 11 20:41:39 <kergoth> or a bbappend, sure
Oct 11 20:41:41 <kergoth> up to you
Oct 11 20:42:30 <ag> What if i want to have something in PACKAGECONFIG based on the machine.
Oct 11 20:42:40 <ag> For m1 have glx and for m2 don't have it,
Oct 11 20:43:57 <kergoth> so go ahead and do that then
Oct 11 20:44:19 <ag> kergoth: So can be modified from machine conf as well right?
Oct 11 20:44:39 <kergoth> that would be extremely bad. only local.conf should be using pn- overrides, as a matter of correctness
Oct 11 20:45:14 <kergoth> if something is truly controlled by machine, it should be a feature in MACHINE_FEATURES. or your distro should conditionally modify distro features based on machine, or something.
Oct 11 20:45:54 <ag> Yeah i know the story... thought this PACKAGECONFIG was taking into consideration machine aspects as well..
Oct 11 20:47:10 <ag> kergoth: thanks
Oct 11 20:47:36 <kergoth> as i said, it's a simple mechanism. what it 'takes into consideration' is whatever the recipe puts in its PACKAGECONFIG variable
Oct 11 20:48:20 <ag> kergoth: thanks once again
Oct 11 20:48:38 <kergoth> np
Oct 11 20:53:38 <pablo_> hello
Oct 11 20:54:10 <pablo_> is there any document on remote debugging using the yocto-generated toolchain+gdb?
Oct 11 20:54:28 <pablo_> im trying to do it on an armv5 machine
Oct 11 20:56:53 <sorvats> hello, sorry. i am pablo_ :)
Oct 11 21:07:46 <seebs> I may be missing something.
Oct 11 21:08:13 <seebs> siteinfo.bbclass says that mips64 uses "endian-big bit-64 mips64-common" siteinfo files. But there is no mips64-common siteinfo file; just a mips-common.
Oct 11 21:08:31 <seebs> Long story short, this ultimately results in screen failing to configure because of missing values which are present in mips-common.
Oct 11 21:08:49 <seebs> Is this something that is expected to work? If so, what hilarious slapstick humor have I engaged in this time?
Oct 11 21:09:53 <kergoth> sounds like its time to create a mips64-common
Oct 11 21:12:46 <seebs> It probably is, I just figured I'd check in case, say, it's working in upstream because of a patch I haven't backported. Or I'm just being sorta clueless.
Oct 11 21:13:36 <seebs> In theory I'm pretty smart, but I am sufficiently spectacularly error-prone that my first checklist item is roughly at the level of "did I remember to plug this in?"
Oct 11 21:19:22 <hollisb> are the contents of build/tmp/deploy/images/modules*.tgz contained in core-image-base*.tar.bz2? seems like some modules are in the image, and some aren't?
Oct 11 21:19:46 <kergoth> just as with anything else, *packages* go in an image
Oct 11 21:19:50 <kergoth> kernel modules get split out into separate packages
Oct 11 21:19:58 <kergoth> if you want them all, add the kenrel-modules package to your image
Oct 11 21:21:37 <hollisb> so the default behavior is that modules produced by the kernel-modules recipe are *not* in the image, but modules produced by other recipes are?
Oct 11 21:21:56 <kergoth> huh?
Oct 11 21:22:03 <hollisb> that's what I said :)
Oct 11 21:22:09 <kergoth> modules produced by a recipe get packaged. those packages dont go int an image unless you ask for it
Oct 11 21:22:13 <kergoth> like every other package that exists, anywhere
Oct 11 21:22:17 <kergoth> theya ren't going to magically show up
Oct 11 21:22:42 <kergoth> if some are required to boot a certain machine, then they get added to MACHINE_ESSENTIAL_RDEPENDS or MACHINE_ESSENTIAL_RRECOMMENDS in the machine .conf
Oct 11 21:22:46 <kergoth> but taht's it
Oct 11 21:23:49 <hollisb> so since I have e.g. ./lib/modules/3.1.0/kernel/fs/jfs/jfs.ko in my image, that must mean the image recipe already includes all kernel modules
Oct 11 21:24:25 <kergoth> no, it means the image recipe or something it includes, or anything else in the runtime dependency graph pulled in a packge taht provided it
Oct 11 21:24:40 <kergoth> see bitbake -g or bitbake -g -u depexp
Oct 11 21:26:04 <hollisb> so there's no standard practice here? no policy like "all poky-defined images include all kernel modules"?
Oct 11 21:26:51 <kergoth> repeat after me. kernel packages are not special, nor are they magic
Oct 11 21:26:57 <kergoth> if you want a package in your image, add it to your image.
Oct 11 21:27:49 <hollisb> kergoth: I understand, but poky provides a bunch of image recipes. yes, these can be overridden, ignored, whatever... but what is their normal behavior?
Oct 11 21:28:05 <kergoth> if you want to know what goes into an image, *read the image*
Oct 11 21:28:12 <kergoth> again, the handling of the kernel modules is no different than any other package
Oct 11 21:29:18 <hollisb> kergoth: you can say "read the source" for everything, but ultimately documentation exists for a reason, and people answer questions on IRC too... :)
Oct 11 21:29:46 <kergoth> you really expect people to have a per-image package list for every recipe ready off the top of their head?
Oct 11 21:29:50 <kergoth> that's ridiculous.
Oct 11 21:29:57 <hollisb> no no
Oct 11 21:31:46 <hollisb> just wondering if there's a general policy like "all images in poky/meta include kernel modules"
Oct 11 21:32:52 <kergoth> that'd just bloat up the images, so no. the machine controls which essential modules get installed, otherwise its up to the images/packagegroups
Oct 11 21:33:50 <hollisb> ok, thanks!
Oct 11 21:34:05 <kergoth> np
Oct 11 21:34:11 <seebs> So speaking of siteinfo: Shouldn't a specification of a site info file which doesn't exist trigger an error or failure?
Oct 11 22:10:32 <RP> seebs: not really
Oct 11 22:10:46 <RP> seebs: mips64 hasn't been developed so far at this point
Oct 11 22:10:55 <RP> seebs: its not on the official test list for example
Oct 11 22:11:53 <seebs> Yes, but imagine that I have a toolchain with mips64 bits, and I specify it. And siteinfo.bbclass asks for a mips64-common. Shouldn't I get some kind of diagnostic that I've requested a site config file which doesn't exist?
Oct 11 22:12:28 <RP> seebs: That would seem logical until you realise the wild west those files came out of
Oct 11 22:12:44 <RP> seebs: I'm not sure if we're at a point where they'd all exist yet
Oct 11 22:13:25 <seebs> Ahh, makes sense.
Oct 11 22:14:02 <seebs> I have an inkling to propose a new option, called "sane.bbclass", which imposes additional sanity checks to verify not merely that configurations are not overtly insane, but that they actually seem solid and complete. :)
Oct 11 22:14:22 <RP> seebs: sanity.bbclass is already taken
Oct 11 22:14:48 <RP> insane, sane and sanity would seem like overkill
Oct 11 22:15:31 <RP> I'm looking forward to totally-insane.bbclass along with totally-and-utterly-insane.bbclass
Oct 11 22:15:53 <RP> The last time I joked about this we ended up with the tinfoil module :/
Oct 11 22:16:00 <seebs> Heh.
Oct 11 22:16:38 <seebs> Along with stuff like feature/build-libc and feature/build-toolchain, I once proposed that we implement a requested thing under the name feature/over-my-dead-body.
Oct 11 22:17:09 <RP> seebs: :)
Oct 11 22:21:05 <seebs> Worse yet, it eventually shipped (though not under that name).
Oct 11 22:21:29 <RP> seebs: that would be annoying
Oct 11 22:21:58 <seebs> It was the on-target compiler, and my fears were ultimately mostly unjustified.
Oct 11 22:22:13 <seebs> Although I was right: We now get asked why it's x86-only.
Oct 11 22:22:54 <RP> seebs: ah, that is hopefully a problem OE addresses?
Oct 11 22:24:07 <seebs> Not for our purposes (prebuilt binary toolchains).
Oct 11 22:24:27 <RP> seebs: right, I can see the issue there
Oct 11 22:24:55 <kergoth> i'd say just make the siteinfo bits fail if the file doesn't exist, and either let the failed cases fail, or touch empty site files or remove from the list if they really aren't required :) (after the 1.3 release)
Oct 11 22:25:47 <bluelightning> RP: I thought you liked tinfoil as a name...
Oct 11 22:25:59 <RP> bluelightning: I do :)
Oct 11 22:26:37 <RP> naming just has so much potential for trouble
Oct 11 22:27:05 <bluelightning> insane.bbclass is something we're stuck with, that wasn't the best choice
Oct 11 22:27:36 <RP> We could probably rename it, its not widely used
Oct 11 22:27:40 <RP> (the name that is)
Oct 11 22:27:49 <bluelightning> yeah, I guess not
Oct 11 22:28:02 <bluelightning> renaming it was suggested a few years ago, I don't remember who by
Oct 11 22:28:14 <bluelightning> maybe even you :)
Oct 11 22:28:16 <RP> I've had my share of renaming grief for now though ;-)
Oct 11 22:28:18 <RP> wasn't me...
Oct 11 22:28:22 <RP> I'm not opposed though
Oct 11 22:28:27 <bluelightning> heh, yes we've done quite a bit in this cycle
Oct 11 22:29:14 <bluelightning> RP: though making people use INSANE_SKIP to disable checks somehow seems fitting :)
Oct 11 22:29:26 <RP> :)
Oct 11 23:17:21 <seebs> Huh, that worries me a bit. There's a couple of values in *-common files like the size of ssize_t, and there are no files which give a value other than 4 for that value, even though obviously at least some targets, it's 8.
Oct 11 23:30:25 <seebs> woot, I have an apparently-working mips64-common.
Oct 11 23:30:48 <seebs> Unfortunately, I don't think I can test it against oe-core correctly right now because my toolchain integration is woefully out of sync.
**** ENDING LOGGING AT Fri Oct 12 03:00:01 2012

**** BEGIN LOGGING AT Fri Oct 12 03:00:02 2012
Oct 12 08:54:54 <mckoan> good morning
Oct 12 09:50:51 <bluelightning> hi all
Oct 12 11:12:35 <pablo__> hi
Oct 12 11:12:37 <pablo__> ?
Oct 12 11:25:59 <pablo__> hi?
Oct 12 12:23:08 <jackmitchell> hi
Oct 12 13:39:22 <pablo__> someone there?
Oct 12 13:50:26 <bluelightning> pablo__: we're all here :)
Oct 12 14:19:43 <pablo__> :)
Oct 12 14:19:55 <pablo__> probably this is a stupid question
Oct 12 14:19:57 <pablo__> but
Oct 12 14:20:10 <pablo__> is possible to install git in a yocto image?
Oct 12 14:20:22 <pablo__> I mean, I just installed yocto on a machine
Oct 12 14:20:32 <pablo__> I'm a complete newbie on this
Oct 12 14:20:41 <pablo__> and since it is basically Linux
Oct 12 14:20:51 <pablo__> I was wondering if I could use git
Oct 12 14:21:19 <bluelightning> so, you mean you want to run git on the target machine?
Oct 12 14:21:30 <pablo__> yes
Oct 12 14:21:36 <bluelightning> sure, that's very easy
Oct 12 14:22:09 <pablo__> I am used to using yum
Oct 12 14:22:11 <pablo__> or apt-get
Oct 12 14:22:19 <bluelightning> just add "git" to the list of packages to be installed
Oct 12 14:22:21 <bluelightning> http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#usingpoky-extend-customimage
Oct 12 14:23:15 <pablo__> so basically
Oct 12 14:23:38 <pablo__> once I have installed Yocto, I can't install a new package?
Oct 12 14:23:49 <bluelightning> if your image has package management enabled you can do "bitbake git" and that will produce a package you can install into an existing image
Oct 12 14:24:07 <bluelightning> which image are you currently building/using?
Oct 12 14:25:42 <pablo__> It is a customized image for Intel Atom
Oct 12 14:25:44 <pablo__> processor
Oct 12 14:26:04 <pablo__> but I didn't create it by myself
Oct 12 14:26:04 <bluelightning> ok, so it would depend on whether package management is enabled in that image
Oct 12 14:26:07 <pablo__> I was given it
Oct 12 14:26:18 <pablo__> how can I know it? :S
Oct 12 14:27:07 <bluelightning> well, can you run rpm or opkg (or dpkg) in the target, do those commands exist?
Oct 12 14:27:29 <pablo__> rpm
Oct 12 14:28:18 <bluelightning> right, what about zypper?
Oct 12 14:28:41 <bluelightning> does that command work?
Oct 12 14:28:46 <pablo__> yes :)
Oct 12 14:30:23 <pablo__> but not bitbake
Oct 12 14:42:38 <bluelightning> pablo__: right, I meant you would be running bitbake on your build (host) system
Oct 12 14:43:04 <pablo__> all right
Oct 12 14:43:07 <pablo__> hehe
Oct 12 14:43:24 <pablo__> thanks :)
Oct 12 14:43:42 <bluelightning> ideally you would be doing customisation based on the recipes that produced this image, not by live-modifying the image itself
Oct 12 14:43:57 <pablo__> I see
Oct 12 14:44:21 <pablo__> well, it makes sense for embedded systems, where you are not supposed to change them too much
Oct 12 14:44:30 <pablo__> am I right?
Oct 12 14:44:54 <bluelightning> actually embedded systems can be changed/customised quite a lot
Oct 12 14:45:26 <bluelightning> to handle storage/memory/other hardware limitations, or to handle custom hardware, etc.
Oct 12 14:45:26 <pablo__> but those changes are made externally?
Oct 12 14:46:04 <bluelightning> depends what you mean by externally... ?
Oct 12 15:32:44 <kergoth> RP: did a quick script (based on reloc-tests, but much simpler) which just builds a specified target to completion (core-image-base, world, whatever), then iterates over all the recipes from pn-buildlist and builds each from scratch in that populated tmpdir, monitoring buildhistory for changes after each recipe build. testing it now. pretty trivial, really, but as you suggested, could be useful
Oct 12 15:32:50 <kergoth> heh
Oct 12 15:32:52 * kergoth taps foot
Oct 12 15:32:59 * kergoth glares at build
Oct 12 15:40:52 * kergoth thinks someone should give bluelightning and RP a medal for buildhistory (and packagehistory before it)
Oct 12 15:44:57 <bluelightning> kergoth: thanks :) koen deserves some credit as well as the original author of testlab.bbclass which I also incorporated into buildhistory
Oct 12 15:45:48 <kergoth> good point, him too
Oct 12 15:46:08 <kergoth> seems like at least a few times a month i end up relying on it for something or other
Oct 12 17:09:45 <bluelightning> fray: ping
**** ENDING LOGGING AT Fri Oct 12 17:18:10 2012

**** BEGIN LOGGING AT Fri Oct 12 17:20:22 2012
Oct 12 17:51:39 <zenlinux_> msm, those two poky denzil patches have been merged FYI
Oct 12 17:59:52 <bluelightning> zenlinux_: hi, regarding runqemu - I noticed today that I can't seem to get the boot messages (i.e. from initscripts) on the console with nographic or serial, is that expected?
Oct 12 18:00:48 <zenlinux_> bluelightning, no, you should be able to see post-init boot messages with nograhic
Oct 12 18:00:59 <zenlinux_> bluelightning, which machine?
Oct 12 18:01:03 <bluelightning> zenlinux_: qemuarm
Oct 12 18:01:19 <zenlinux_> let's see if I have a qemux86 image to test with here
Oct 12 18:02:30 <zenlinux_> hmmm....I think it's working for me
Oct 12 18:03:09 <zenlinux_> bluelightning, do you get a login prompt? or is it just the output from init scripts that are missing?
Oct 12 18:03:34 <eren> what's the size of the typical minimal build?
Oct 12 18:03:51 <eren> I mean the image size, kernel + packages
Oct 12 18:04:24 <zenlinux_> eren, I think  around 6-8 MB or so for core-image-minimal, but you can go much smaller (while making things much less practical) if you use the poky-tiny reference distro
Oct 12 18:04:53 <zenlinux_> poky-tiny is less than 4 MB for the rootfs + kernel
Oct 12 18:06:41 <eren> well, 6-8MB is good enough for my platform
Oct 12 18:07:00 <eren> I will need to enable kernel options for hamradio use
Oct 12 18:07:06 <eren> I guess kernel size will go up a bit
Oct 12 18:07:30 <eren> I'm still crawling in wiki pages and development documents of Yocto
Oct 12 18:07:43 <zenlinux_> eren, have you watched the intro developer tutorial video?
Oct 12 18:07:51 <eren> zenlinux_: no
Oct 12 18:08:19 <eren> zenlinux_: I've proof-read getting started, and developer manual
Oct 12 18:08:59 <zenlinux_> eren, http://vimeo.com/36450321
Oct 12 18:09:19 <zenlinux_> just a video resource for understanding some basic concepts if that's useful to you
Oct 12 18:09:42 <eren> I looked at 'buildroot' but it seems that Yocto is more community-centric that buildroot
Oct 12 18:10:07 <bluelightning> zenlinux_: yeah I get the prompt but I'm just missing the output from initscripts; with serial it goes to the graphical display and with nographic I don't see it at all
Oct 12 18:10:39 <eren> s/that/than
Oct 12 18:11:07 <zenlinux_> bluelightning, that's really odd, I wonder what console the initscripts are trying to write to that would be different
Oct 12 18:12:11 <bluelightning> zenlinux_: not sure... docs I found indicated that output from init scripts should end up going to the last console= specified, but that is ttyS0 in this case so it should be going to the serial port and yet apparently it isn't
Oct 12 18:12:16 <bluelightning> something else at work here no doubt
Oct 12 18:14:09 <eren> I've looked at the .bb and .bbappend files and I realize that I lack some shell scripting. Do you have a good resource for getting used to packaging for yocto?
Oct 12 18:14:40 <eren> at least, I don't know what the statement , FOOBAR ?= "bar baz", is
Oct 12 18:15:37 <zenlinux_> eren, the ?= is a conditional assignment, it means assign FOOBAR to "bar baz" if FOOBAR has not already been set.
Oct 12 18:15:55 <zenlinux_> otherwise it won't make the assignment and leave FOOBAR as it was previously set to
Oct 12 18:16:23 <eren> oh nice
Oct 12 18:16:37 <zenlinux_> One of the more complex things about the Yocto Project is we have a layer architecture and one must be mindful of when certain stacks of the metadata get parsed
Oct 12 18:16:55 <zenlinux_> But it allows us a lot of flexibility too
Oct 12 18:17:10 <eren> yeah I've read the article on 'architecture of open source projects'
Oct 12 18:17:30 <eren> I didn't spend time on how bitcake parses metadata information, though
Oct 12 18:17:30 <zenlinux_> cool, my teammate pidge wrote that
Oct 12 18:18:11 <eren> I've done packaging work for 3 years, but our package management system was based on python and xml
Oct 12 18:18:20 <eren> python for configure, make, install actions
Oct 12 18:18:22 <eren> xml for metadata
Oct 12 18:18:52 <eren> yocto's metadata resembles ebuild in gentoo, though
Oct 12 18:19:07 <zenlinux_> for good reason, it was heavily influenced by ebuild ;)
Oct 12 18:19:30 <eren> i've never touched an ebuild file except when I was searching for patches to steal :P
Oct 12 18:25:51 <mranostay> zenlinux_: peer pressure? :)
Oct 12 18:27:23 <zenlinux_> mranostay, about the ebuild influence? perhaps, of course I wasn't involved with things that early on in the project (which btw is OpenEmbeeded technology to be precise)
Oct 12 18:27:35 <zenlinux_> er. OpenEmbedded
Oct 12 18:28:05 <mranostay> famous excuse used "i wasn't involved then" :)
Oct 12 18:28:55 <kergoth> we still have the original wiki pages where we discussed the available options and decided that portage was the best starting point
Oct 12 18:28:58 <kergoth> heh
Oct 12 18:31:30 <eren> why portage?
Oct 12 18:31:33 <eren> easy to parse? :)
Oct 12 18:32:22 <kergoth> we intentionally ditched their file format because what they had *wasnt* easy to parse
Oct 12 18:32:30 <kergoth> there aren't a lot of shell parsing projects again :)
Oct 12 18:32:32 <kergoth> ebuilds are shell scripts
Oct 12 18:33:37 <eren> as far as I see, ebuilds include metadata as well as code for building, patching, installing etc
Oct 12 18:34:43 * zenlinux_ goes foraging for food
Oct 12 18:44:26 <kergoth> eren: which is what our recipes include, yes, but in a directl yparsable format, and with the ability to use python
Oct 12 18:45:37 <bluelightning> our recipes seem much more declarative than ebuilds, outside of clearly demarcated functions at least
Oct 12 18:46:21 <bluelightning> last time I looked at an ebuild it seemed a bit crazy from my perspective, but I'm completely biased :)
Oct 12 18:48:00 <bluelightning> bbl
Oct 12 19:04:34 <eren> oh nice
Oct 12 19:05:07 <eren> so bitkake generates deb, or rpm files and make a repository out of them (it's called package feed)
Oct 12 19:05:37 <eren> that's what I understood from the screencast
Oct 12 19:06:22 <eren> in that way, you can use the capabilities of .deb (dependency resolving, updating the system, etc) inside the embedded system with a networking capability?
Oct 12 19:40:17 <seebs> So, vague thought: What if we distinguished between "cheap checks that are totally worth making often" and "expensive checks that probably don't need to be re-run" in some way?
Oct 12 19:41:04 <seebs> I was thinking about some of the paranoid and "this can't happen but just in case" stuff, and it occurs to me there's a lot of tests that I wouldn't mind running once when I start on a project, but which probably don't need to be run every time bitbake starts up.
Oct 12 19:42:05 <seebs> And this actually leads to a thought: What if we had a category of "expensive checks", and the default behavior was to run them only if something fails. So, if there's a failure, we go do all the expensive checks for things that could cause failures. Hmm.
Oct 12 19:42:14 <seebs> This is probably not yet anywhere near well-thought-out.
Oct 12 21:05:35 <likewise> gm
Oct 12 21:06:08 <likewise> What was the URI for GIT over SSH?  I forgot and am lost finding a good example or documentation on it.
Oct 12 21:18:27 <seebs> ssh://user@host/... works fine with git.
Oct 12 21:52:54 <likewise> seebs: I found git://git@git.server.com/repo.git;protocol=ssh works for me, haven't tried your variant yet.
Oct 12 21:53:31 <likewise> seebs: I mean in a bitbake recipe.
Oct 12 21:54:21 <seebs> Ohhh. I hadn't been thinking about bitbake. :)
Oct 12 21:54:29 <kergoth> the url scheme determines which bitbake fetcher is used, and therefore what tool is run. this is why you can't use http:// or ssh:// for a git uri in SRC_URI, but instead have to use protocol= against the git fetcher
Oct 12 21:57:21 <likewise> kergoth: thanks for explaining it that way, maybe I will remember next time.  Whenever ssh comes up, I tend to use the SSH syntax.
Oct 12 22:23:38 <likewise> nite all
**** ENDING LOGGING AT Sat Oct 13 03:00:02 2012

**** BEGIN LOGGING AT Sat Oct 13 03:00:02 2012
Oct 13 06:37:10 <eren> hi folks, morning
**** ENDING LOGGING AT Sun Oct 14 03:00:02 2012

**** BEGIN LOGGING AT Sun Oct 14 03:00:03 2012
Oct 14 03:15:28 <bsmucker> Hello, I'm a yocto newbie, and have a question about the differences between the libraries in the directory from the deploy images directory and the meta-ts72xx3/tmp/work/armv4t-poky-linux-gnueabi/eglibc-2.15-r7+svnr17386/package/lib/ directory
Oct 14 03:17:30 <bsmucker> If I do readelf -h on the deploy version it gives an error : readelf: Error: no .dynamic section in the dynamic segment, it also segfaults if I try to use it.  The libc in the package/lib directory is fine and does not give the readelf error.  What could be going on?
**** ENDING LOGGING AT Mon Oct 15 03:00:01 2012

**** BEGIN LOGGING AT Mon Oct 15 03:00:02 2012
Oct 15 06:48:46 <tolbrino> Hi there, I'm having trouble compiling the kernel using the latest poky tag 1.3_M5.rc3 and yocto linux kernel 3.2. Getting the following error:
Oct 15 06:48:46 <tolbrino>  make[2]: *** No rule to make target `zImage'.  Stop.
Oct 15 06:48:46 <tolbrino> Any idea where the config might be wrong?
Oct 15 07:32:45 <mckoan> good morning
Oct 15 08:50:55 <ant_work> bluelightning: I fear I may have discovered a new issue about git-native
Oct 15 08:51:08 <bluelightning> hi ant_work
Oct 15 08:51:15 <bluelightning> ant_work: oh, what's that?
Oct 15 08:52:02 <ant_work> on mysetup, the kernel tools do not find the git-core scripts
Oct 15 08:54:04 <ant_work> so it's necessary to bitbake git-replacement-native to stage the git-core scripts in sysroot
Oct 15 08:58:24 <ericben> good morning
Oct 15 08:58:52 <ant_work> bluelightning: the problem is apparent in do_patch on linux-yocto:
Oct 15 08:58:52 <bluelightning> ant_work: that has to be a problem with the way git is installed by your distro though
Oct 15 08:58:56 <ant_work> 29: /oe/oe-core/build/tmp-eglibc/sysroots/i686-linux/usr/bin/../libexec/git-core/git-sh-setup:
Oct 15 08:58:57 <ant_work> No such file or directory
Oct 15 08:59:30 <ant_work> seems relative to the sysroot,  ../libexec should be /usr/libexec
Oct 15 09:00:26 <ant_work> to point to the host's git
Oct 15 09:01:14 <bluelightning> ant_work: if it was a fresh build though what is expecting git-core scripts to be in the sysroot?
Oct 15 09:01:24 <bluelightning> ant_work: nothing should be installing those
Oct 15 09:01:48 <ant_work> kernel tools depend on git-native and guilt-native
Oct 15 09:02:07 <ant_work> git-native is ASSUME_PROVIDED
Oct 15 09:02:19 <bluelightning> yes
Oct 15 09:02:31 <ant_work> so, yes, sysrott is empty :)
Oct 15 09:02:55 <ant_work> somehow, the kernel devs expect the git-core scripts there...
Oct 15 09:03:21 <bluelightning> but even in my configuration that path does not exist, so something else is going on
Oct 15 09:05:20 <ant_work> seem sdebian may be installing in /usr/lib/git-core/git-sh-setup
Oct 15 09:11:41 <bluelightning> ant_work: /usr/libexec/git-core/git-sh-setup on my ubuntu system
Oct 15 09:11:53 <bluelightning> and the same on my centos 6.3 system
Oct 15 09:12:12 <ant_work> bluelightning: doh  http://packages.ubuntu.com/lucid/i386/git-core/filelist
Oct 15 09:18:08 <bluelightning> er, yes, I was in the wrong terminal... on my ubuntu system it is in /usr/lib not /usr/libexec
Oct 15 09:18:12 <bluelightning> but it still works just fine...
Oct 15 09:19:28 <ant_work> ideally you should check the do_patch logs of one linux-yocto build
Oct 15 09:21:03 <bluelightning> ant_work: what would I be looking for?
Oct 15 09:21:20 <ant_work> "No such file or directory"
Oct 15 09:21:54 <bluelightning> nope, that's not in there...
Oct 15 09:22:31 <bluelightning> nor in another build on my other system
Oct 15 09:23:09 <ant_work> ok, I'm using the master of kernel-tools, setup is a bit different
Oct 15 09:32:57 <mertsas> is it possible to have a bbappend which specifies a branch from a SRC_URI? I want to use the same SRC_URI as what I'm appending, but change the branch
Oct 15 09:33:13 <mertsas> preferably without having to write a new SRC_URI
Oct 15 09:34:36 <bluelightning> mertsas: you could achieve that by setting SRCREV to a revision on that branch
Oct 15 09:34:42 <bluelightning> that should work
Oct 15 09:37:06 <mertsas> ok, thanks
Oct 15 09:43:27 <jackmitchell> is anyone having issues with gmp and gettext on latest master, building for armv7a?
Oct 15 09:59:56 <jackmitchell> it is the native recipes for x86_64 which are posing problems
Oct 15 20:45:21 <msm> how should header file conflicts be handled?
Oct 15 20:45:54 <msm> do you make a separate PACKAGE for a specific header within a recipe and use RCONFLICTS RREPPLACES on that recipe-subpkg package?
Oct 15 20:46:14 <mranostay> with extreme prejudice
Oct 15 20:53:54 <msm> hmmm
Oct 15 20:54:47 <tolbrino> Hi there, I'm having a hard time debugging a do_package_qa issue when compiling a linux-yocto-3.2 kernel. The errors says that the architecture is wrong, thus I'm suspecting a problem with the BSP's scc file. Could somebody point me to the place where I can find the file which yocto is trying to use? I can only find autogenerated files which would suggest Yocto can't even find my scc?
Oct 15 21:36:53 <hollisb> bluelightning: what happened to meta-webserver? relocated?
Oct 15 21:37:57 <bluelightning> hollisb: if you mean the one in my github account, yes, that was super-temporary - the real layer is now available in meta-openembedded: http://cgit.openembedded.org/meta-openembedded/tree/meta-webserver
Oct 15 21:38:17 <hollisb> ah, thanks. google still has the old one
Oct 15 21:38:19 <bluelightning> with a bunch of additional fixes as well :)
Oct 15 21:38:42 <bluelightning> hmm, hopefully that will disappear in time
Oct 15 21:38:49 <bluelightning> the layer index points to the right location at least
Oct 15 21:39:33 <hollisb> thanks
Oct 15 21:45:41 <hollisb> bluelightning: what PHP apps have you run using that layer?
Oct 15 21:45:54 <bluelightning> hollisb: only phpmyadmin which is in there
Oct 15 21:46:15 <bluelightning> so it hasn't had heavy testing
Oct 15 21:46:58 <hollisb> bluelightning: ah ok. I assumed you had some app you really wanted working, which is why you had to build out the infrastructure layer first :)
Oct 15 21:47:09 <bluelightning> note that if you want mysql support you need to add meta-oe and set PACKAGECONFIG_pn-modphp = "mysql" (or PACKAGECONFIG = "mysql" in a modphp bbappend in your own layer, whichever suits)
Oct 15 21:47:57 <bluelightning> hollisb: actually I was asked to get phpmyadmin working as a demo
Oct 15 21:48:30 <bluelightning> but I'm sure it will come in useful for all sorts of applications
Oct 15 21:49:11 <hollisb> yeah
Oct 15 21:50:01 <hollisb> bluelightning: what's the actual demo though? "and look, phpMyAdmin works now"? :)
Oct 15 21:57:18 <bluelightning> hollisb: more like "here's a real application working, hence PHP as we build it can clearly be used to run real apps"
Oct 15 21:57:35 <hollisb> yup, I see
Oct 15 22:12:13 <Crofton> we need a tool that can tell me what layer provides what package
Oct 15 22:12:21 <Crofton> as in layers I have not added yet ......
Oct 15 22:17:55 <bluelightning> Crofton: I've added a feature request for 1.4 to create a database-backed layer index webapp
Oct 15 22:18:19 <bluelightning> Crofton: https://bugzilla.yoctoproject.org/show_bug.cgi?id=3272
Oct 15 22:18:53 <bluelightning> hmm, it's been set as Future but I hope it can be done for 1.4
Oct 15 22:20:32 <hollisb> bluelightning: the SF download link for phpmyadmin doesn't seem to work, I guess due to the "wait for your download" page?
Oct 15 22:22:00 <bluelightning> hollisb: just tried it again here, seemed to work...
Oct 15 22:22:23 <bluelightning> (did a -c cleanall phpmyadmin followed by -c fetch phpmyadmin)
Oct 15 22:22:35 <hollisb> hm
Oct 15 22:23:56 <hollisb> somehow I got sent to http://sources.openembedded.org/phpMyAdmin-3.5.2.2-all-languages.tar.xz, then http://www.angstrom-distribution.org/unstable/sources/phpMyAdmin-3.5.2.2-all-languages.tar.xz
Oct 15 22:24:30 <hollisb> local mirror misconfiguration, I guess.. no idea
Oct 15 22:26:45 <bluelightning> hollisb: those are mirrors I guess
Oct 15 22:27:08 <hollisb> yeah, we have an internal sources mirror that must be tripping me up
Oct 15 22:27:32 <bluelightning> possibly, but it should have tried the sourceforge URL as well
Oct 15 22:27:38 <hollisb> one would think
Oct 15 22:27:39 <bluelightning> you can tell by looking at log.do_fetch
Oct 15 22:28:02 <hollisb> yeah, the last attempt was to http://www.angstrom-distribution.org/unstable/sources/phpMyAdmin-3.5.2.2-all-languages.tar.xz
Oct 15 22:28:18 <bluelightning> so that was from MIRRORS I guess which is fine
Oct 15 22:28:22 <bluelightning> what about before that?
Oct 15 22:29:05 <hollisb> http://sources.openembedded.org/phpMyAdmin-3.5.2.2-all-languages.tar.xz, preceeded by http://autobuilder.yoctoproject.org/sources/phpMyAdmin-3.5.2.2-all-languages.tar.xz, http://downloads.yoctoproject.org/mirror/sources/phpMyAdmin-3.5.2.2-all-languages.tar.xz, ...
Oct 15 22:29:11 <hollisb> I don't see it trying the original link :)
Oct 15 22:29:37 <hollisb> oops no
Oct 15 22:29:39 <hollisb> it's there
Oct 15 22:29:54 <hollisb> WARNING: Failed to fetch URL http://downloads.sourceforge.net/phpmyadmin/phpMyAdmin/3.5.2.2/phpMyAdmin-3.5.2.2-all-languages.tar.xz, attempting MIRRORS if available
Oct 15 22:30:11 <hollisb> DEBUG: Fetcher failure: Fetch command failed with exit code 4, output:
Oct 15 22:30:11 <hollisb> Read error (Connection timed out) in headers.
Oct 15 22:31:02 <Crofton> bluelightning, good idea
Oct 15 22:31:11 <Crofton> based off the layer index page I hope :)
Oct 15 22:31:24 <bluelightning> Crofton: the idea would be to replace that
Oct 15 22:31:34 <bluelightning> Crofton: initial data would be populated from that page though yes
Oct 15 22:59:26 <Crofton> so replace layer index with a web app, with the added feature you can search for a package/recipe
Oct 15 23:04:16 <kergoth> curl -s http://www.openembedded.org/wiki/LayerIndex|sed -n 's,.*<td>\([a-z]\+://[^<]\+\).*,\1,
Oct 15 23:04:20 <kergoth> p'|sed 's,\.git$,,; s,$,.git,'|grep -v cgit|sort -u|while read url; do git cached-clone $url arc
Oct 15 23:04:23 <kergoth> hive/$(basename $url); done
Oct 15 23:04:26 <kergoth> blah, stupid wrap
Oct 15 23:04:33 <kergoth> anyway, thast what i use to pull down a local dir of the layers for grepping
Oct 15 23:04:38 <kergoth> not pretty, but..
Oct 15 23:04:39 <kergoth> heh
Oct 15 23:14:34 <hollisb> wow mysql5 takes a long time to build
Oct 15 23:14:55 <hollisb> looks like its build system is only single-threaded, too :(
Oct 15 23:30:23 <mranostay> hollisb: don't you love those....
Oct 16 00:51:53 <mranostay> so it is normal for static libraries not be included into a SDK image?
Oct 16 00:54:33 <Crofton> pretty sure
Oct 16 01:00:07 <mranostay> ok how can i have *staticdev pulled in?
Oct 16 01:00:43 <mranostay> ah IMAGE_FEATURES
**** ENDING LOGGING AT Tue Oct 16 03:00:01 2012

**** BEGIN LOGGING AT Tue Oct 16 03:00:02 2012
Oct 16 04:05:34 <evanp> anyone know what oe.classextend.ClassExtender is all about?
Oct 16 04:07:13 <evanp> it looks very similar to blobs of code in various virtclass handlers, but the only thing that uses it is multilib
Oct 16 04:08:22 <evanp> (at least on denzil, I suppose I should take a look at a more recent branch)
Oct 16 08:01:06 <RP> evanp: It replaces the virtclass handler code in master
Oct 16 08:01:16 <mckoan> good morning
Oct 16 08:01:18 <RP> evanp: at least for nativsdk
Oct 16 08:01:20 <RP> nativesdk
Oct 16 08:32:37 <bluelightning> morning all
Oct 16 08:56:55 <blloyd> morning
Oct 16 15:00:08 <RP> Song_Liu: YPTM: RP is on the call
Oct 16 15:00:19 <Song_Liu> YPTM: Hello everyone, welcome to the meeting. Please let me know who's on the bridge. Thanks!
Oct 16 15:00:21 <sgw> YPTM: Saul is here
Oct 16 15:00:21 <tomz2> YPTM: Tom Z here
Oct 16 15:00:29 <strassek> YPTM: Kevin Strasser is here
Oct 16 15:00:34 <bluelightning> YPTM: Paul Eggleton is here
Oct 16 15:00:57 <nitink> YPTM: Nitin is on the bridge
Oct 16 15:01:29 <darknighte> YPTM: Song_Liu: hey.  I'm on the bridge.
Oct 16 15:01:36 <scottrif> YPTM: Scott Rifenbark joined
Oct 16 15:01:48 <zeddii_home> YPTM: Bruce on the bridge, but muted since I'm in transit.
Oct 16 15:01:56 <darknighte> Song_Liu: you might suggest that he uses IRC to identify himself.
Oct 16 15:02:22 <bluelightning> YPTM: Belen is also in the same room
Oct 16 15:02:26 <Zagor> YPTM: Bjorn here
Oct 16 15:02:30 * darknighte waves
Oct 16 15:03:32 <jmpdelos> YPTM: Jeff Polk joined
Oct 16 15:03:45 <rburton> YPTM; ross joined
Oct 16 15:04:20 <darknighte> Song_Liu: none from me.
Oct 16 15:04:26 <Song_Liu> YPTM: Any opens?
Oct 16 15:04:30 <scottrif> OPEN:  Final date to submit a change to docs
Oct 16 15:04:40 <pidge> YPTM: Dialing in
Oct 16 15:05:39 <denix> YPTM: dialing in now...
Oct 16 15:05:58 * fp amit from MontaVista, dropped off... re-dialing..
Oct 16 15:06:26 <darknighte> Song_Liu: I believe that the poor audio connection was from amit of MV.
Oct 16 15:06:57 <davest> #YPTM: davest is here
Oct 16 15:06:57 * darknighte knods
Oct 16 15:07:10 <darknighte> Song_Liu: see ^^^ fp
Oct 16 15:07:14 <fp> darknighte, yes ;)
Oct 16 15:08:01 <darknighte> RP: you had it right.  I couldn't find my un-mute to tell Song_Liu.
Oct 16 15:08:06 * darknighte chuckles
Oct 16 15:08:24 <evadeflow> David Wolfe of Magneti Marelli here.
Oct 16 15:08:36 <darknighte> evadeflow: welcome back.
Oct 16 15:08:53 <evadeflow> Thanks!
Oct 16 15:11:46 <darknighte> scottrif: you're *very* faint
Oct 16 15:12:04 <darknighte> scottrif: yep
Oct 16 15:18:47 <evadeflow> ::SIGH:: My wifi tether isn't working very well this morning.
Oct 16 15:19:22 <evadeflow> 64 bytes from 74.125.225.135: icmp_seq=1 ttl=50 time=7309.929 ms 64 bytes from 74.125.225.135: icmp_seq=2 ttl=50 time=7327.949 ms
Oct 16 15:19:28 <evadeflow> If I haven't dropped off yet, it's only a matter of time. :-(
Oct 16 15:19:49 <darknighte> evadeflow: ouch.
Oct 16 15:21:38 <zeddii_home> I'm on mute still.
Oct 16 15:21:46 <zeddii_home> we have a bug/enhancement for this.
Oct 16 15:22:36 * fp back in
Oct 16 15:22:49 <zeddii_home> the white noise on my phone would blow everyone off the call :)
Oct 16 15:23:22 <zeddii_home> I think that's a different bug.
Oct 16 15:23:50 <zeddii_home> features -> fragments./
Oct 16 15:24:08 <zeddii_home> but the board has the last say. i.e. no hardware, it turns it off.
Oct 16 15:26:24 <zeddii_home> http://git.yoctoproject.org/cgit/cgit.cgi/yocto-kernel-tools/commit/?h=master-next&id=e71f0e27842a6c99d1f682ce00352b6c51addd37
Oct 16 15:26:37 <bluelightning> zeddii_home: that's probably where COMBINED_FEATURES could come in (influenced from both MACHINE_FEATURES and DISTRO_FEATURES)
Oct 16 15:36:25 <dvhart> YPTM: Darren has joined (meeting conflict this morning)
Oct 16 15:36:42 <dvhart> Song_Liu, ^
Oct 16 15:46:30 <darknighte> YPTM: who was speaking from WindRiver?
Oct 16 15:48:34 <jmpdelos> yes
Oct 16 15:50:23 <darknighte> jmpdelos: I'm trying to recall.  did you attend the Yocto BSP Summit?
Oct 16 15:50:24 <Song_Liu> YPTM: thank you all for joining the meeting. Bye now
Oct 16 15:51:13 <jmpdelos> darknighte: no, I haven't been to any of the recent meetings
Oct 16 17:17:03 <thaytan> can I make yocto ignore bbappends for missing layers?
Oct 16 17:17:46 <kergoth> you mean avoid the fatal error that resutls whe you bbappend to a nonexistent file?
Oct 16 17:17:48 <thaytan> that is, bbappends in a higher layer, for packages in a lower (disabled) layer
Oct 16 17:17:56 <thaytan> kergoth: correct
Oct 16 17:18:19 <kergoth> higher vs lower isn't relevent, nor is the layering, even, at that level bitbake doesn't care wehre it comes from, it only cares that you tried to append to a file that doesn't exist
Oct 16 17:18:29 <kergoth> there's a varaible you can set to make it non-fatal, just a warning, thats about the only option
Oct 16 17:18:45 <kergoth> see http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/tree/conf/layer.conf#n8
Oct 16 17:18:55 <kergoth> not ideal, but better tha nothing
Oct 16 17:20:09 <thaytan> kergoth: I guess I probably need a better structuring of my layers
Oct 16 17:20:15 <eren> anyone who has packaged E17?
Oct 16 17:20:26 <thaytan> but that will fix it for now
Oct 16 17:20:28 <thaytan> thanks :)
Oct 16 17:20:42 <eren> I couldn't find metadatas for enlightenment
Oct 16 17:21:40 <bluelightning> eren: there's meta-efl in the meta-openembedded repo
Oct 16 17:21:49 <bluelightning> see http://www.openembedded.org/wiki/LayerIndex
Oct 16 17:25:41 <eren> bluelightning: nice, thank you
Oct 16 17:25:56 <eren> has anybody used e17 on their projects, btw?
Oct 16 17:26:21 <bluelightning> not me, but judging by the amount of work that's gone into it I think others have been
Oct 16 17:27:15 <eren> I have a feeling that E17 will have a great performance on embedded devices
Oct 16 17:27:29 <eren> I've read a lot of good reviews
Oct 16 17:27:40 <eren> but, unfortunately, E17 does not seem to be popular
Oct 16 17:27:58 <otavio> bluelightning: Did you see the toolchain issue I pointed yestarday?
Oct 16 17:29:14 <hollisb> heh, "[Enlightenment] Version 0.17, also referred to as DR17 or E17, has been in development since December 2000"
Oct 16 17:29:48 <bluelightning> otavio: I'm not sure I have, no
Oct 16 17:34:50 <bluelightning> bbl
Oct 16 17:34:55 <morphis> eren: we're using it in the SHR distribution: see http://shr-project.org/
Oct 16 18:22:08 <mranostay> so i see staticdev packages getting globbed for but they don't seem to get installed
Oct 16 18:41:51 <eren> morphis: it looks really cool
Oct 16 18:43:28 <eren> I guess that e17 will work seamlessly under alix 3d3 board, which has 500MHz x86 compatible AMD CPU and 256MB of ram
Oct 16 18:51:26 <msm> is there a preferred way to update .bashrc for all users?
Oct 16 18:51:30 <msm> including root
Oct 16 18:58:12 <morphis> eren: it should
Oct 16 18:58:26 <morphis> eren: if you have any questions about SHR you can ask me or JaMa
Oct 16 18:58:44 <eren> msm: it's a personal file, why are you trying to update a personal file without a user consent?
Oct 16 19:00:02 <eren> morphis: thanks. I'm on the research phase of my embedded project, I will first need to get board working, package some application, and think about the user interface
Oct 16 19:00:25 <eren> but I will most probably use E for developing new applications on it
Oct 16 19:00:36 <morphis> should the best choice for this
Oct 16 19:01:49 <eren> it does not include a touchscreen, so I won't think about the design much :)
Oct 16 19:02:26 <mranostay> kergoth: poke poke
Oct 16 19:07:35 <msm> eren: i meant for new users
Oct 16 19:19:32 <eren> msm: /etc/skel
Oct 16 19:19:55 <eren> The /etc/skel directory contains files and directories that are automatically copied over to a new user's home directory when such user is created by the useradd program.
Oct 16 19:20:07 <eren> please look at http://www.linfo.org/etc_skel.html
Oct 16 19:23:34 <msm> eren: yea, i was curious if there was a way to modify this but as far as I can tell no current recipe packages these
Oct 16 19:25:40 <eren> msm: what's the possibility of making a recipe for it, then?
Oct 16 19:25:50 <eren> patching "useradd" program to allow /etc/skel
Oct 16 19:25:56 <eren> if required, of course
Oct 16 19:26:06 <eren> most of the current linux distributions support it
Oct 16 19:40:49 <mranostay> is it possible to put a single staticdev pacakge in  IMAGE_INSTALL?
Oct 16 19:52:21 <msm> is there a recipe alias? if I want to change one and keep backwards compat?
Oct 16 20:45:13 <msm> ha, i guess just a PROVIDES would do it
Oct 16 20:49:52 <evanp> anyone know why native.bbclass's virtclass handler checks for both that ${PN} ends in '-native' _and_ ${BBCLASSEXTEND} includes classextend? I'm having trouble picturing the scenario where one test is true but the other is false.
Oct 16 20:50:26 <evanp> s/classextend/"native", typing and reading at the same time -> crossed wires
Oct 16 20:54:46 <msm> what if you have a recipe named recipe-native which extends nativesdk?
Oct 16 20:55:11 <kergoth> evanp: the latter would be false if native was inherited directly, rather than through the bbclassextend mechanism, but in that case the bbclassextend check would seem to be sufficient, rather than both
Oct 16 20:55:12 * kergoth shrugs
Oct 16 20:55:15 <fray> there are a set of -native's that don't end in "-native"
Oct 16 20:55:25 <fray> (the cross packages)
Oct 16 20:56:07 <msm> is there an easy way to extract the SRCREV for a package which AUTOREVS? E.g. what SHA would be used for a git based recipe at that point in time?
Oct 16 20:56:27 <kergoth> msm: it gets stored in the persist_data db
Oct 16 21:00:49 <msm> kergoth: is there a quick way to dump that to console?
Oct 16 21:00:51 * msm goes googling
Oct 16 21:01:38 <kergoth> i'm sure you can use the sqlite command to do so. you can certainly inspect it that way, interactively
Oct 16 21:01:52 <kergoth> worst case you could use a python script with the sqlite package
Oct 16 21:14:27 <msm> sqlite3 bb_persist_data.sqlite3 '.dump'
Oct 16 21:14:30 <msm> seems useful
Oct 16 21:21:46 <msm> except it does not seem to store the sha for my recipe...
Oct 16 21:22:01 <msm> maybe, i need to let it finish building
Oct 17 00:51:39 <msm> kergoth: this db does not seem to store the sha's built for AUTOREV packages
Oct 17 00:52:15 <kergoth> huh, thats odd, considering thats what i was going to use to lock them down, specifically, to avoid BB_NO_NETWORK issues with mel releases
Oct 17 00:52:18 <msm> i suppose i can come up with a git command to show me something based off the SRC_URI
Oct 17 00:52:18 * kergoth shrugs
Oct 17 00:52:45 <msm> hmm, maybe im missing something
Oct 17 00:52:48 <msm> let me try another recipe
**** ENDING LOGGING AT Wed Oct 17 03:00:01 2012

**** BEGIN LOGGING AT Wed Oct 17 03:00:01 2012
Oct 17 05:35:13 <thaytan> that took me far too long to figure out that 'DEFAULTTUNE' is the setting to use to configure the target architecture
Oct 17 07:37:57 <mckoan> good morning
Oct 17 08:38:45 <bluelightning> morning all
Oct 17 08:50:18 <florian> hi bluelightning
Oct 17 08:50:26 <bluelightning> hi florian
Oct 17 10:04:41 <_julian_> ping thiagoss
Oct 17 11:46:56 <thaytan> why might I get a 'Unable to find package kernel-modules" from the do_rootfs task
Oct 17 11:47:10 <thaytan> my kernel recipe looks like the the sample ones, so I'm not sure what's wrong
Oct 17 11:55:58 <thaytan> hmm, because it's not choosing my kernel recipe I guess
Oct 17 13:16:26 <_julian_> thaytan: obviously it did not build a package named kernel-modules (c:
Oct 17 15:39:52 <msm> i've recently seen this on danny: https://gist.github.com/3906231
Oct 17 15:39:56 <msm> not sure what it might be
Oct 17 16:15:04 <_Lucretia_> hi, what does .= mean?
Oct 17 16:17:12 <kergoth> append, immediately, with no separator
Oct 17 16:17:19 <_Lucretia_> ah
Oct 17 16:17:19 <_Lucretia_> ta
Oct 17 16:17:25 <_Lucretia_> couldn't find the docs
Oct 17 16:17:27 <zenlinux_> I'm developing a presentation slide to describe the order of parsing bitbake does as a prelude to describing override operators and variable overrides. Is this accurate? http://pastebin.com/0LEJRMYU
Oct 17 16:19:06 <zenlinux_> _Lucretia_, I was just looking up the bitbake manual myself and was annoyed that it is no longer available online  - you have to build it yourself from the bitbake sources. :-/
Oct 17 16:21:30 <_Lucretia_> k
Oct 17 16:21:38 <_Lucretia_> at least i know where it's supposed to be now :D
Oct 17 16:23:02 <_Lucretia_> ok, so i'm going to add a layer so we can add apps, at the moment, i'm using the official meta-gumstix, which has priority 7, should i set my pri to 7 or higher?
Oct 17 16:23:49 <kergoth> that depends. the only time your priority matters is if you duplicate recipes that exist in another layer, so bitbake knows to prefer yours over theirs
Oct 17 16:24:04 <bluelightning> right, what kergoth said :)
Oct 17 16:24:20 <_Lucretia_> ok, so it's not going to matter then
Oct 17 16:24:32 <_Lucretia_> as our stuff is just for apps
Oct 17 16:24:35 <_Lucretia_> at the moment
Oct 17 16:24:45 <_Lucretia_> we will be requiring another layer to extend gcc into adding gnat
Oct 17 16:25:31 <_Lucretia_> first layer (private) will be a quick hello world app test, then i'll be looking into adding another layer (public) for gnat
Oct 17 16:25:53 <_Lucretia_> then the first layer will add apps written in Ada and will use the recipes in the second
Oct 17 16:49:12 <msm> OK, it seems like we are looking for sstate-cache now in AB/${HOSTDSISTRO}/sstate-cache-foo
Oct 17 16:49:29 <msm> but on the mirror we are still just looking $http_mirror
Oct 17 16:49:40 <kergoth> use PATH in your mirror uris in SSTATE_MIRRORS
Oct 17 16:49:42 <msm> not $http_mirror/AB/${HOSTDSISTRO}/
Oct 17 16:49:54 <msm> example?
Oct 17 16:50:13 <kergoth> file://.* http://someuri/PATH
Oct 17 16:50:25 <msm> kergoth: ok… just PATH
Oct 17 16:50:26 <msm> got it
Oct 17 16:50:59 <kergoth> we use http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/tree/classes/sstate-reuse.bbclass
Oct 17 16:51:35 <kergoth> does hte hostdistro fallback to compatible hosts thing on the mirror, but as a side effect the user doesn't have to set SSTATE_MIRRORS directly, they set SSTATE_MIRROR_SITES
Oct 17 16:51:38 <kergoth> not ideal, but..
Oct 17 16:52:12 <msm> hmm, im just looking at this all again
Oct 17 16:52:18 <msm> getting curoius why builds are going so slow ;)
Oct 17 16:52:23 <kergoth> heh
Oct 17 16:53:29 <msm> so your sstate-reuse lets me use my CentOS 5 sstate?
Oct 17 16:53:45 <msm> on a newer distro?
Oct 17 16:53:50 <msm> gotta run, bbiab
Oct 17 16:53:53 <kergoth> thats the idea, just automatically checks both the hostdistro and fallback distros ont he mirror
Oct 17 16:53:56 * kergoth nods
Oct 17 16:53:58 <kergoth> later
Oct 17 16:57:45 <khem> sgw: around ?
Oct 17 16:58:41 <sgw> Hi Khem, what's up?
Oct 17 16:58:57 <khem> sgw: I have created a blessed tarball for eglibc that I want someone to upload to http://downloads.yoctoproject.org/releases/
Oct 17 16:59:25 <sgw> khem: that would be halstead
Oct 17 16:59:34 <khem> I am trying to get rid of svn-native dep
Oct 17 16:59:40 <khem> ok
Oct 17 16:59:46 * khem pokes halstead 
Oct 17 17:01:30 <khem> halstead: you around ?
Oct 17 17:04:45 <_Lucretia_> so to install a new app into an image, i have to create a custom image bb file deriving from the one i'm currently using? i.e. gumstix-console-image.bb
Oct 17 17:09:09 <khem> sgw: Can .iso created by hob install onto hdd ?
Oct 17 17:09:33 <khem> sgw: so if I hand an .iso to someone is there some sort of installer builtin ?
Oct 17 17:12:50 <sgw> khem: I think you want the live image, it adds the install for syslinux
Oct 17 17:13:45 <mranostay> PACKAGE_INSTALL += " eglibc-staticdev" doesn't seem to work
Oct 17 17:14:09 <mranostay> aka not pulling those static libraries into my SDK build
Oct 17 17:14:18 <sgw> khem: live will create hddimg and iso
Oct 17 17:14:25 <khem> sgw: ok,
Oct 17 17:14:36 <khem> sgw: yes I am able to boot an hddimg
Oct 17 17:14:50 <khem> how can I install it to local hd if I want to
Oct 17 17:15:04 <khem> right now I dd the hddimg into USB stick
Oct 17 17:15:18 <khem> and boot the device from USB all that works fine
Oct 17 17:15:28 <khem> now I want to install that image to local hd
Oct 17 17:15:43 <khem> if there is some doc on that point me to that
Oct 17 17:16:10 <rburton> khem: it depends on how it boots - my cdt boots from hddimg on usb and gives me a menu for boot or install
Oct 17 17:16:20 <sgw> khem: looking, I know that Dvhart did some work there, but he's not around.
Oct 17 17:17:10 <khem> rburton: hmm I see
Oct 17 17:17:24 <khem> rburton: let me find out
Oct 17 17:20:32 <sgw> khem, I thought darren did a wiki page, but I can't find it!
Oct 17 17:21:15 <_Lucretia_> confused: ERROR: Nothing PROVIDES 'koparo-gumstix-console-image' - http://pastebin.com/svxUhVav
Oct 17 17:22:26 <khem> _Lucretia_: do you have a recipe for that ? if not then the complain is right
Oct 17 17:22:29 <khem> sgw: ok
Oct 17 17:22:54 <khem> btw. whats the best machine (nearest match) for sandy bridge based boards
Oct 17 17:22:56 <_Lucretia_> wem
Oct 17 17:22:58 <_Lucretia_> erm
Oct 17 17:23:21 <_Lucretia_> that pastbin is the recipe
Oct 17 17:23:57 <khem> check inherit gumstix-console-image
Oct 17 17:24:05 <khem> may be overwriting IMAGE_NAME
Oct 17 17:24:51 <sgw> nitink: see khem's question regarding sandy bridge
Oct 17 17:25:43 <nitink> sgw: khem: sugarbay
Oct 17 17:26:07 <_Lucretia_> third line in that  gumstix-console-image.bb is inherit image
Oct 17 17:33:13 <halstead> khem, Here.
Oct 17 17:40:08 <khem> nitink: yeah google was converging
Oct 17 17:40:11 <khem> at samr :)
Oct 17 17:40:12 <khem> thanks
Oct 17 17:40:47 <khem> nitink: btw. it would be helpful info if meta-intel/README carried some info on codenames to chipsets and so on
Oct 17 17:41:01 <khem> nitink: or even the product versions
Oct 17 17:41:08 <khem> halstead:
Oct 17 17:41:16 <khem> I have eglibc tarballs
Oct 17 17:41:25 <khem> that we should put in release area
Oct 17 17:42:11 <GNUtoo> hi khem
Oct 17 17:44:24 <nitink> khem: good point, I will check the readmes to see if such information is absent
Oct 17 17:47:36 <khem> GNUtoo: hi
Oct 17 17:48:50 <GNUtoo> khem, chromium works now but firerox still segfault....
Oct 17 17:49:34 * nitink was on the call
Oct 17 17:50:14 <nitink> khem: did you get ur answers?
Oct 17 17:52:04 <nitink> khem: meta-sugarbay/README has these lines: The 'Sugar Bay' platform consists of the Intel Sandy Bridge processor,
Oct 17 17:52:04 <nitink> plus the Cougar Point PCH (Q67 Express or B65 Express chipsets).  This
Oct 17 17:52:04 <nitink> BSP assumes that the Sandy Bridge integrated graphics are being used.
Oct 17 17:52:17 <GNUtoo> hmmmm
Oct 17 17:53:32 <GNUtoo> I've a BSP for a generic mainboard + more comming(if time permits), basically the goal is to generate initramfs with it for x86 mainboards (for instance it could be used for booting real fast, to be chainloaded by ipxe or even to be a coreboot payload). what should I do with it
Oct 17 17:54:51 <_Lucretia_> sooo, it didn't like recipes-test/hello_c as a package name, why?
Oct 17 18:07:56 <fray> _c indicates it's 'version c'
Oct 17 18:08:06 <fray> the underscore is used as a name and version seperator
Oct 17 18:08:18 <fray> name_version.bb  is the formation -- version is optional
Oct 17 18:34:51 <khem> nitink: yes cool
Oct 17 18:35:02 <khem> nitink: btw. I have Cave Creek chipset
Oct 17 18:35:05 <khem> will it wotk for it
Oct 17 18:35:21 <khem> and Sandy Bridge Gladden
Oct 17 18:38:04 <ag> Hello.
Oct 17 18:38:30 <ag> i see a lot of bsp with mfloat-abi=softfp in conjunction with mfpu=vfp.
Oct 17 18:39:18 <ag> Why is this preferred generally and not the mfloat-abi=hard - obviously where the case applicable
Oct 17 18:59:40 <blloyd> is there a way to use relative paths in bblayers.conf?
Oct 17 19:03:32 <blloyd> (ie, the files on an external HD, where the mount point is different on the two machines it is used on)
Oct 17 19:03:49 <_Lucretia_> fray: ok thanks, but what if our packages have underscores in them?
Oct 17 19:04:14 <rob_w> change em ;-)
Oct 17 19:04:31 <_Lucretia_> not Ada naming compliant :D
Oct 17 19:04:34 <fray> they should be replaced by a '-'
Oct 17 19:04:58 <_Lucretia_> fray: ah, good
Oct 17 19:05:03 <fray> foo_name = foo-name..  you can rename the packages in the recipes.. but that is the recipe format
Oct 17 19:05:18 <_Lucretia_> similar to GNAT naming convention then
Oct 17 19:05:27 <_Lucretia_> that's ok then
Oct 17 19:08:17 <khem> sgw: ping
Oct 17 19:08:37 <khem> sgw: I just sent an eglibc patch to use tarball instead of svn
Oct 17 19:08:56 <khem> I have only tried it on one arch ppc
Oct 17 19:09:01 <khem> so please give it a whirl
Oct 17 19:09:05 <khem> and use V2
Oct 17 19:27:39 <_Lucretia_> before i do it, even though i've not found it, has anyone manged to add a layer to integrate gnat? I did find a reference on a mail list a while back, but can't find that now
Oct 17 19:27:56 <thiagoss> _julian_, pong, hopefully is not too late
Oct 17 19:36:33 <_Lucretia_> actually, if I want to add ada, can't I just add LANGUAGES ?= ",ada" to my conf/local.conf ?
Oct 17 19:44:24 <blloyd> _Lucreatia_: Is ada the only language you want to support?  That construct you used says default LANGUAGES to ",ada" if it isn't specifically set to something else.
Oct 17 19:45:06 <_Lucretia_> nope
Oct 17 19:45:16 <_Lucretia_> ah, should use .= ?
Oct 17 19:45:25 <_Lucretia_> or +=
Oct 17 19:45:58 <_Lucretia_> blloyd: thanks
Oct 17 19:46:16 <_Lucretia_> no, going to need c and c++ too, but definitely need Ada
Oct 17 19:47:38 <_Lucretia_> also, what's the best way of passing the correct gcc to use to bitbake?
Oct 17 19:47:57 * _Lucretia_ is on debian and has to use a specific gcc to enable ada, gcc-4.6 I think
Oct 17 19:49:55 <blloyd> += would be my guess.
Oct 17 19:50:28 <kergoth> langauges isn't space separated
Oct 17 19:50:33 <kergoth> so += will likely give you something broken
Oct 17 19:50:40 <kergoth> as it adds a space separator
Oct 17 19:50:54 <kergoth> you'll want .= or _append, depending on how LANGUAGES is used in the recipe(s)
Oct 17 19:50:56 <blloyd> Then it's LANGUAGES_append, right?
Oct 17 19:51:24 <kergoth> .= an d_append both concatenate without separator, the latter is applied at th eend of the parse, while .= is immediate
Oct 17 19:51:37 <kergoth> if ht erecipe does a ?=, then using .= in the confi gmetadata will result in that ?= not being applied
Oct 17 19:51:42 <kergoth> so in that case you'll want _append, yes
Oct 17 19:52:08 <_Lucretia_> i think i'm going to have t have a gnat specific layer, as there will need to be recipes on how to build apps using gnatmake and gnatbuild
Oct 17 19:52:09 <blloyd> also, kergoth knows 1000x more than me.  Also, the gcc from debian shouldn't matter.  you compile gcc as part of the build process.
Oct 17 19:52:37 <_Lucretia_> the gcc does matter as 4.7.1 that's provided doesn't know Ada, 4.6 does
Oct 17 19:53:32 <_Lucretia_> can I set CC= and CXX= as usual?
Oct 17 19:53:51 <_Lucretia_> kergoth: thanks
Oct 17 19:55:07 <blloyd> the end links will not be good.  gcc is built to link programs against specific libraries that are specific to the build.  The version of those support libraries will be different on the yocto image versus what your debian builds against.  It's very hard to make a program that compiles and runs on multiple linux distributions.
Oct 17 19:55:27 <blloyd> (and the yocto image is basically a custom distribution)
Oct 17 19:56:11 <blloyd> from experience, it may appear to work and then get strange behavior during operation because the binary API mismatches just slightly.
Oct 17 19:56:19 <_Lucretia_> but the compilers are all built by debian and installed via apt, they are all provided by them
Oct 17 19:56:31 <_Lucretia_> i don't know what links you mean
Oct 17 19:56:54 <blloyd> you are using bitbake packages, right?
Oct 17 19:57:02 <_Lucretia_> yeah
Oct 17 19:57:15 <_Lucretia_> but the initial build needs a system compiler like any cross compiler
Oct 17 19:57:49 <blloyd> Yes, so your system compiler is used to build the cross compiler, that is then used to build the rest.
Oct 17 19:57:52 <_Lucretia_> all i'm saying is, i need to tell the initial bitbake that the gcc to use is different to the one that's got the links set up now, which 4.7.1
Oct 17 19:58:14 <_Lucretia_> but debian has multiple compilers installed by default
Oct 17 20:02:16 <blloyd> I have a i586-poky-linux/gcc-cross-initial-4.6.3+svnr184847-r29 that is created and then used to compile everthing else.  That's the compiler that is probably building your ada files.
Oct 17 20:02:39 <blloyd> (yours would probably not be i586 as you probably build for different hardware)
Oct 17 20:03:37 <_Lucretia_> yeah, you're not understanding what I'm saying
Oct 17 20:04:02 <blloyd> you are doing a bitbake yourneatpackage, right?
Oct 17 20:04:20 <_Lucretia_> no
Oct 17 20:04:22 <_Lucretia_> done that
Oct 17 20:04:45 <_Lucretia_> I'm talking about getting the cross compiler to include ada and install that
Oct 17 20:05:21 <_Lucretia_> debian system compiler by default is 4.7.1, which does not include ada, but gnat when installed is 4.6.3 and the gcc that understands that is gcc-4.6
Oct 17 20:06:45 <blloyd> when things are set up right, the debian system compiler shouldn't matter.  Ada isn't necessary to build gcc that understands ada.
Oct 17 20:07:39 <_Lucretia_> yes it is
Oct 17 20:07:50 <_Lucretia_> and it is set up right
Oct 17 20:08:22 <_Lucretia_> you cannot configure gcc --enable-languages=c,ada if your gcc was not built with ada
Oct 17 20:08:45 <blloyd> Hopefully kergoth or another can shed some light on our misunderstandings.
Oct 17 20:09:02 <_Lucretia_> your
Oct 17 20:10:36 <blloyd> ouch, I see gnat is making cross compiling harder.
Oct 17 20:11:28 <_Lucretia_> luckily i have built a 4.7.x gcc with gnat and have it locally installed
Oct 17 20:13:38 <_Lucretia_> ah no i dont :(
Oct 17 20:13:54 <zenlinux> What's the current hotness for filesystems to run on NAND flash?
Oct 17 20:14:05 <zenlinux> e.g, ones that can do write balancing or throttling
Oct 17 20:19:14 <kergoth> pretty sure ubifs is the way to go nowadays
Oct 17 20:19:19 <kergoth> but i'm a bit out of the loop
Oct 17 20:21:17 <zenlinux> that's what I've heard too
Oct 17 20:26:30 <rob_w> kergoth, yeah ubifs rocks
Oct 17 20:26:55 <rob_w> _Lucretia_, what thoought is we want to build gcc-native with ada and go from there
Oct 17 20:27:36 <_Lucretia_> native already has Ada, well on our machines, we need to get gcc-cross-initial to build Ada too for arm
Oct 17 20:27:41 <rob_w> so you are not using your hosts compiler but build inside bitbake your gcc-native and then build your gcc-cross .. same for ada i guess
Oct 17 20:28:09 <_Lucretia_> but to build that cross, you already need native
Oct 17 20:28:44 <rob_w> but your talking about native as in your hosts own compiler and not the bitbake native ones ??
Oct 17 20:29:02 <_Lucretia_> i didn't realise bitbake built native gcc as well
Oct 17 20:29:09 <rob_w> yes it does
Oct 17 20:29:20 <_Lucretia_> hmmm
Oct 17 20:29:32 <_Lucretia_> where is this documented?
Oct 17 20:29:47 <rob_w> http://patches.openembedded.org/patch/463/  u saw this , right ? i think that is the correct approach
Oct 17 20:30:09 <kergoth> bitbake doesn't normally build gcc-native, no. cross, yes, native, no, unless you're doing sdk stuff
Oct 17 20:31:06 <rob_w> hmm
Oct 17 20:31:41 <_Lucretia_> that night be what i saw ages ago
Oct 17 20:31:53 <_Lucretia_> ah, what i thought :D
Oct 17 20:32:16 * rob_w is confused 
Oct 17 20:32:21 <_Lucretia_> where can I read about the gcc recipes and how they work, please don't say the recipes
Oct 17 20:39:21 <khem> rburton: hmm I am booting .iso image and menu fo install does not come up
Oct 17 20:40:06 <khem> rburton: is it specific to .hddimg
Oct 17 21:17:56 <RP__> khem: For the eglibc tarball, do we need to add something more than 2.16 like the svn revision?
Oct 17 21:46:02 <PortaLu> bluelightning: where do i need to be looking manual-wise on how the compilers work with poky/yocto?
Oct 17 21:46:29 <bluelightning> I don't think that is laid out in the manual
Oct 17 21:47:10 <PortaLu> arse
Oct 17 21:47:13 <PortaLu> :(
Oct 17 21:47:16 <PortaLu> any pointers
Oct 17 21:47:28 <bluelightning> well, what do you want to know?
Oct 17 21:47:51 <bluelightning> ultimately our compiler of choice is gcc
Oct 17 21:47:55 <PortaLu> yup
Oct 17 21:47:59 <PortaLu> ok, i'm on debian
Oct 17 21:48:29 <PortaLu> this means there are essentially 2 compiler builds, 1 which includes Ada (gcc-4.6) and one which doesn't (gcc-4.7)
Oct 17 21:48:37 <PortaLu> they are installed alongside each other
Oct 17 21:48:45 <PortaLu> you can build with either
Oct 17 21:49:05 <PortaLu> using CC and CXX doesn't get picked up by poky
Oct 17 21:49:09 <PortaLu> that's 1 issue
Oct 17 21:49:14 <PortaLu> second
Oct 17 21:49:44 <PortaLu> I need to build an Ada compiler, so either need to extend via a layer or something, so need to know where to start
Oct 17 21:49:46 <PortaLu> thanks
Oct 17 21:50:31 <bluelightning> the compiler on the host system is only used to build native targets, i.e. software to run on the host itself
Oct 17 21:51:00 <PortaLu> it's used to build the cross compiler's and other host tools, yes
Oct 17 21:51:17 <bluelightning> otherwise it's the cross-compiler and toolchain that is used for the target
Oct 17 21:52:12 <bluelightning> I don't know anything specific about Ada I'm afraid; but if it's something that can be optionally enabled in gcc then it shouldn't be too hard to add the appropriate options to enable it
Oct 17 21:52:23 <PortaLu> yes, but you have to have an Ada compiler to be able to build an Ada compiler
Oct 17 21:53:13 <bluelightning> well, as far as CC and CXX are concerned or indeed any other variable from the environment we only allow specific variables through into the environment used for the build
Oct 17 21:53:19 <PortaLu> so surely, poky builds gcc1 for c, then uses that to build the cross compilers c, c++, etc.
Oct 17 21:59:46 <PortaLu> so are there any variables I can use to set the host compilers?
Oct 17 22:02:31 <khem> BUILD_CC
Oct 17 22:02:38 <khem> and BUILD_LD and so on
Oct 17 22:05:01 <PortaLu> r
Oct 17 22:08:09 <PortaLu> thanks
Oct 18 00:14:15 <blloyd> is there a variable I can use in .bb files that holds the sysroot?
Oct 18 00:24:14 <kergoth> read bitbake.conf
Oct 18 00:26:59 <blloyd> ok, meta/conf/bitbake.conf.  Thanks for the pointer to file to read.
Oct 18 00:27:44 <kergoth> it's the main config file. all the others (e.g. local.conf) are included by it. the main global variable definitions are there
Oct 18 00:31:34 <blloyd> thank you.  I appreciate the better understanding of the tool I'm using.
Oct 18 00:44:03 <msm> is there a way to run a python function before calculating task signatures?
Oct 18 00:44:18 <msm> mostly im trying to change vardeps conditionally
Oct 18 00:44:37 <msm> but if I dp a setVarFlag it's too late in an anonymous python function
Oct 18 00:52:51 <kergoth> signatures should only be calculated after the data is finalized, so that sounds odd
Oct 18 00:57:45 <msm> kergoth: i think you are right
Oct 18 00:57:52 <msm> kergoth: after more playing around
Oct 18 00:58:06 <msm> i dont know what state I was in when thought it was not
Oct 18 01:00:04 <msm> kergoth: however, if I set vardeps flag in anon python - the function does not always get rerun hence it never determines it needs to rerun a specific task
Oct 18 01:00:14 <msm> e.g. if the task is already complete
Oct 18 01:00:30 <msm> im probably confusing myself though
Oct 18 01:01:15 <msm> if I do vardeps with pure bitbake it works OK
Oct 18 01:06:10 <msm> ugh, i think i'm just doing some bits wrong
Oct 18 01:06:11 <msm> please ignore me
Oct 18 01:23:57 <kergoth> msm: heh, we need to get -e to dump flags, or add a new argument to do so
Oct 18 01:54:08 <blloyd> ok, I'm trying to integrate a new library (pion), and it's tossing an error: This autoconf log indicates errors, it looked at host include and/or library paths while determining system capabilities
Oct 18 01:55:16 <blloyd> My problem is I can't find where that error is generated from so I can't see what is being read to indicate that.  Any hints on where to find error checks.  My first assumption was autotools.bbclass, but a search of it turned up nothing.  Trying an all sources grep didn't find it either.  :(
Oct 18 01:56:01 <kergoth> i'd say config.log, which is the only config file autoconf configure scripts emit
Oct 18 01:56:14 <kergoth> s/config file/log file/
Oct 18 01:57:17 <blloyd> insane.bbclass.  Finally found what generates the error.
Oct 18 01:59:28 <blloyd> now I know what it is looking at in config.log, so I can look at that.  It said one thing, searches for another thing.
**** ENDING LOGGING AT Thu Oct 18 03:00:01 2012

**** BEGIN LOGGING AT Thu Oct 18 03:00:02 2012
Oct 18 03:31:12 <blloyd> I have a funny problem: I have a third party library with two components.  One uses GNU Affero and the libraries use Boost.  How can I split this in a package so say pion-net knows it needs the boost license and pion-core knows the Affero license applies to it?
Oct 18 03:32:40 <blloyd> also, is there an easy way to exclude files from inclusion in the final packages?  (I looked but I don't know what I may be looking for.)
Oct 18 03:33:00 <kergoth> see bitbake.conf again, this time the PACKAGES and FILES_* variables
Oct 18 03:33:17 <kergoth> the former is a space separated list of packages to emit, the latter are per package lists of files or globs to include in that package
Oct 18 03:33:28 <kergoth> any given file will only go into one package — the first one to include it
Oct 18 03:33:59 <blloyd> I understand that much.  What if you don't want a file to go into any package?
Oct 18 03:34:15 <kergoth> then it'll warn. or you modify your do_install to either not install it or remove it
Oct 18 03:34:34 <kergoth> the packaging code has no mechanism to exclude files by design. if you dontw ant them packaged, don't install them
Oct 18 03:35:34 <blloyd> their is a default package that gets everything else.  Is it OK to defines FILES for that one too?
Oct 18 03:35:54 <blloyd> or do I just not understand this (I'm starting to think I'll never learn this)
Oct 18 03:37:23 <blloyd> reading bitbake.conf.  Hopefully I'll go Oh, that makes sense in a few minutes.
Oct 18 03:37:35 <kergoth> you're just not understanding
Oct 18 03:37:40 <kergoth> there is not a default package that "gets everything else"
Oct 18 03:37:56 <kergoth> there is a specific set of packages to be emitted, with specific defined lists of paths to be included
Oct 18 03:40:33 <blloyd> now I'm really confused.  One of the specifically defined packages is ${PN}.  That has most everything I think of as in a package.  The documents I read said you can split by doing PACKAGES += "${PN}-sub1" and then files places in ${PN}-sub1 wouldn't be in ${PN}.  But I don't see why not now.
Oct 18 03:41:10 <kergoth> that wouldn't do what you describe, but PACKAGES += would
Oct 18 03:41:25 <kergoth> becuase of this, which I already mentioned:[20:33:27] <kergoth> any given file will only go into one package — the first one to include it
Oct 18 03:41:41 <kergoth> order of entries in PACKAGES matters
Oct 18 03:41:51 <blloyd> OH.
Oct 18 03:42:22 <blloyd> So prepend, and it gets the file instead of where it would go.
Oct 18 03:42:23 <kergoth> erm "but PACKAGES =+ would", i meant
Oct 18 03:42:27 <kergoth> yep
Oct 18 03:42:31 <blloyd> thank you.
Oct 18 03:42:43 <kergoth> thats assuming there's overlap. if it's in a path taht isn't included in PN, it wouldnt' matter
Oct 18 03:42:45 <kergoth> np
Oct 18 03:43:13 <blloyd> there's overlap.
Oct 18 03:43:59 <blloyd> And things are slowly starting to make sense.  Hopefully my questions seem less dumb.  Usually it's I know what I want is in this source somewhere, but I haven't figured out where now.  :)
Oct 18 03:44:33 * kergoth nods
Oct 18 03:44:53 <blloyd> there's an awful lot of source with this.  :)
Oct 18 03:45:20 <kergoth> bitbake -e is invaluable, but it can be hard to track down what got set where. peter seebach's bitbake patches are helpful for that, hopefully they'll get merged at some point here
Oct 18 03:46:00 <kergoth> (they mark up the bitbake -e output showing exactly what lines of what files set what variables/flags)
Oct 18 03:46:14 <blloyd> cool, that will be very helpful.
Oct 18 03:52:17 <blloyd> unfortunately, I need to understand this stuff 2 months ago, so waiting on patches isn't a viable option.
Oct 18 04:22:04 <kergoth> you're free to apply them yourself if you find them helpful. http://patches.openembedded.org/project/bitbake/list/ - see the two data_smart.py patches
Oct 18 04:22:15 <kergoth> i don't need them often, but from time to time it can be useful
Oct 18 04:54:27 <blloyd> ok, I understand why autotools does an autoreconf, and it has some merrit.  Problem is without some modifications autoreconf runs autoheader, and pion-net uses a hand crafted library header.hpp.in file.  The way I know to fix this is to do "export AUTOHEADER=/bin/true" before running autoreconf or configure.  Would that mean write a custom replace for the step that does the autoreconf so I can set that or is there some way to have it preset for just the one
Oct 18 04:54:28 <blloyd> package?
Oct 18 04:55:48 <evanp> export AUTOHEADER = "/bin/true" outside any do_* should do that
Oct 18 04:59:37 <blloyd> and it will only affect that package?
Oct 18 05:00:13 <evanp> blloyd: if you only do it in that package's .bb file
Oct 18 05:01:59 <blloyd>  unparsed line: 'export AUTOHEADER=/bin/true'
Oct 18 05:03:43 <kergoth> unquoted value
Oct 18 05:03:49 <blloyd> uh, dumb.  Just noted that
Oct 18 05:04:12 <kergoth> error message should probably mention it more explicitly, but..
Oct 18 05:04:26 <evanp> blloyd: yeah, it's deceptively similar to shell syntax, but the grammar is different
Oct 18 05:04:38 <blloyd> yup, that's what got me.
Oct 18 05:04:56 <blloyd> I'd just fixed and ran with quotes.
Oct 18 05:17:38 <blloyd> order matters is also giving me trouble.
Oct 18 05:25:48 <blloyd> I have a question: when digging into other bb packages, I'm seeing a lot of require XYZ.inc from the bb file, and almost all the logic is in the inc.  But that .inc file is not used except in the one bb file, so what is the advantage?
Oct 18 05:26:58 <kergoth> either in the past we had multiple recipes, or the split exists for use by recipes from other layers
Oct 18 05:27:12 <kergoth> oe-core/poky don't exist in isolation
Oct 18 05:30:04 <blloyd> OK, so a 3.6 file could be used as baseline for 3.6.1 later if necessary without dup.  Makes sense, thanks.
Oct 18 05:30:36 <blloyd> there much if any overhead incurred by said split (like 10 stats of yet another file in a very slow build system).
Oct 18 05:30:43 <blloyd> ?
Oct 18 05:49:55 <blloyd> I seem to not understand RDEPENDS and DEPENDS, and their descriptions seemed so simple.  My understanding is DEPENDS is compile time only dependencies.  Packages specified here would be in the sysroots/machine-... sysroot used to build applications.  RDEPENDS are DEPENDS which also ensure their files are in the final image when that is created.  That right?  (If so, why wouldn't my RDEPENDS packages' files be in sysroot?)
Oct 18 05:56:30 <daniels> blloyd: correct in that DEPENDS are for build-time and RDEPENDS are for runtime
Oct 18 05:56:57 <daniels> blloyd: RDEPENDS won't get installed during build time tho
Oct 18 05:57:24 <daniels> blloyd: so you could have an RDEPENDS on python if you need to run python during execution, but it wouldn't be in sysroot unless you put it in DEPENDS also, as you might not need it at build time
Oct 18 05:58:38 <blloyd> ok, so how do libraries work?  You need them for both build and runtime.
Oct 18 05:59:04 <daniels> yep, and RDEPENDS is automatically populated behind the scenes with any library dependencies your executables have
Oct 18 05:59:13 <daniels> so for the most part you don't need to explicitly set it
Oct 18 06:00:00 <evanp> blloyd: yocto builds things for your MACHINE; it never runs them--because it can't, in general (build on x86, MACHINE is arm)
Oct 18 06:00:30 <evanp> blloyd: therefore there's no need for it to ever put RDEPENDS into the sysroot
Oct 18 06:02:45 <blloyd> DEPENDS should list packages, right?  Not .bb files?
Oct 18 06:05:06 <evanp> blloyd: DEPENDS lists bb files, but I think RDEPENDS lists packages
Oct 18 06:05:10 <blloyd> Specific example, icu_3.6 creates the normal packages + 7 more.  3 of those extra packages have the libraries I need.
Oct 18 06:05:47 <daniels> yeah, DEPENDS is bb, RDEPENDS is packages
Oct 18 06:06:09 <blloyd> ok, reading the document closer.  I can see that now.
Oct 18 06:06:14 <blloyd> thank you.
Oct 18 06:06:46 <blloyd> it's there in black and white, I just misread it I don't know how many times.  Oh, well.
Oct 18 06:07:47 <evanp> blloyd: I didn't find the phrasing in the documentation very helpful either
Oct 18 06:09:09 <evanp> I found it made sense only _after_ I knew what it meant....
Oct 18 06:10:18 <blloyd> that was my problem.
Oct 18 06:10:47 <blloyd> I promise: I do read the manuals first.  Often multiple times until my eyes glaze over.
Oct 18 08:46:40 <bluelightning> morning all
Oct 18 09:06:39 <rburton> blloyd: weeeeell, DEPENDS could be satisfied by another .bb that PROVIDES the name that the depends is looking for
Oct 18 10:32:32 <_Lucretia_> has anyone managed to build the offical gumstix-xfce-image?
Oct 18 13:00:26 <Zagor> hmm, I'm getting a lot more post-install actions in danny than I did with denzil
Oct 18 13:01:30 <Zagor> this is the punishment for not following the mailing lists more closely :-)
Oct 18 15:07:17 <kergoth> bluelightning: so, turns out that intermittent TypeError with the index of cmdline.. command.py's runCommand() can in certain unusual circumstances return a string, an error message, but none of the UIs know how to handle that. doesn't explain how/why we got into that state (e.g. server already running an async command), but does explain how a string could end up in cmdline
Oct 18 15:07:22 * kergoth thinks about how to clean tha tup
Oct 18 15:07:44 <bluelightning> kergoth: aha, interesting
Oct 18 15:08:18 <bluelightning> kergoth: actually I noticed something similar to that happening when I triggered events too early within hob code
Oct 18 15:08:46 <bluelightning> my solution at the time was to just not do that, but clearly there is something funny going on internally
Oct 18 15:11:23 <kergoth> hmm, interesting
Oct 18 15:14:23 <_Lucretia_> ok, does poky/yocto remove all aliases as well as env vars? it seems to going by my tests, it keeps defaulting to system gcc
Oct 18 15:14:35 <_Lucretia_> I want to specify the build cc
Oct 18 15:40:46 <_Lucretia_> how do I override this BUILD_CC variable? everything I do fails
Oct 18 15:43:52 <kergoth> just set it in local.conf. done.
Oct 18 15:45:16 <_Lucretia_> so why does the configure scripts in say gcc-4.7.1?
Oct 18 15:45:21 <_Lucretia_> for example ../../build/tmp/work/x86_64-linux/quilt-native-0.51-r1/quilt-0.51/config.log
Oct 18 15:46:35 <_Lucretia_> I've had to set up links to the right compiler in a different dir and export PATH it first, that has worked
Oct 18 15:46:46 <_Lucretia_> I tried BUILD_CC := ?= = all failed
Oct 18 15:46:52 <_Lucretia_> I tried exporting that var
Oct 18 15:47:05 <_Lucretia_> having it on the cmdline before bitbake
Oct 18 15:47:10 <_Lucretia_> aliasing gcc
Oct 18 15:47:13 <_Lucretia_> all failed
Oct 18 15:49:00 <_Lucretia_> this should be 1) easy to do, 2) documented
Oct 18 15:49:29 <kergoth> "failed" tells me absolutely nothing
Oct 18 15:49:34 <kergoth> if you want help, try giving some useful information
Oct 18 15:49:42 <kergoth> whining isn't going to solve it
Oct 18 15:50:18 <_Lucretia_> failed means, it wasn't picked up
Oct 18 15:50:22 <_Lucretia_> or was removed from env
Oct 18 15:51:18 <_Lucretia_> well I've wasted a day on this, more even, so i'm annoyed
Oct 18 15:52:06 <_Lucretia_> and I stated above, the configure script logs stated gcc 4.7.1 when it listed the version, therefore it's not picked up
Oct 18 15:52:19 <_Lucretia_> so that tells you what you need
Oct 18 15:55:52 <_Lucretia_> plus, I've elaborated on what i've needed since yesterdayand got no useful response
Oct 18 15:58:34 <_Lucretia_> ok, now i've added in the variables again and bitbake -e now shows them? WTF?
Oct 18 15:59:32 <rburton> _Lucretia_: it sounds like it's best to start with *what* you want to do
Oct 18 15:59:44 <_Lucretia_> did that yesterday
Oct 18 15:59:57 <rburton> not everyone in the room right now is here 24/7
Oct 18 16:00:22 <_Lucretia_> true
Oct 18 16:00:23 <_Lucretia_> ok
Oct 18 16:00:31 <_Lucretia_> aim: get Ada compiler working
Oct 18 16:00:54 <_Lucretia_> problem, I'm on Debian which has 3 system compilers, 4.4, 4.6.x, 4.7.x
Oct 18 16:01:01 <_Lucretia_> 4.7 does not have Ada enabled
Oct 18 16:01:05 <_Lucretia_> can't use it
Oct 18 16:01:09 <_Lucretia_> 4.6 does, can use it
Oct 18 16:01:18 <_Lucretia_> gcc is linked to gcc-4.7
Oct 18 16:01:21 <_Lucretia_> same for g++
Oct 18 16:01:39 <_Lucretia_> therefore need to use gcc|++-4.6
Oct 18 16:01:45 <rburton> change the link? :)
Oct 18 16:02:04 <_Lucretia_> could do, but that could cause problems for the rest of my system, might not, but i'm not sure
Oct 18 16:02:22 <_Lucretia_> and tbh, why should i when i should be able to force yocto which compiler to use
Oct 18 16:03:34 <rburton> yeah, looks like BUILD_CC in local.conf will do that
Oct 18 16:04:55 <JaMa> rburton: how do you handle reproducible builds after removing xprint?
Oct 18 16:05:12 <rburton> JaMa: clarify pls
Oct 18 16:05:35 <JaMa> rburton: you've removed recipes and changed DEPENDS, but even with OEBasicHash those libs (which were depending on xprint) before will find xprint again in sysroot
Oct 18 16:06:01 <JaMa> rburton: so unless you -c cleansstate all removed recipes before merging newer oe-core (because you cannot cleannsstate it without recipe)
Oct 18 16:06:04 <rburton> JaMa: good point - should throw a few --without-xprints around
Oct 18 16:06:16 <JaMa> you'll get xprint autodetected again
Oct 18 16:06:25 <rburton> not if --without-xprint is doing its job
Oct 18 16:06:30 <JaMa> true
Oct 18 16:06:40 <rburton> semantics of without in autoconf is hard no
Oct 18 16:06:58 <rburton> JaMa: much appreciated if you'd file a bug for me, in a meeting at the moment
Oct 18 16:06:58 <JaMa> I know, but the patch which is now in oe-core does not have those --without
Oct 18 16:07:24 <_Lucretia_> still doesn't explain why it wasn't being picked up when I had it in there before with all the different operators tried...oh well, seems to be picking up now
Oct 18 16:07:29 * _Lucretia_ will destress now
Oct 18 16:07:53 <JaMa> rburton: I'm also doing something else now.. I'll ping you in few days if you forget :)
Oct 18 16:07:55 <rburton> _Lucretia_: ?= definitely won't work, and := and = would be identical. = is what you want.
Oct 18 16:08:10 <_Lucretia_> I thought .= is append
Oct 18 16:08:22 <rburton> hm vague
Oct 18 16:08:29 <_Lucretia_> I currently have BUILD_CC := "gcc-4.6"
Oct 18 16:08:29 <_Lucretia_> BUILD_CXX := "g++-4.6"
Oct 18 16:08:29 <rburton> that . was the end of the sentence :)
Oct 18 16:08:47 <_Lucretia_> and bitbake -e|grep \_CC brings back what I want
Oct 18 16:08:51 <_Lucretia_> oh
Oct 18 16:09:30 <_Lucretia_> yet in quilt: configure:2221: ccache gcc --version >&5
Oct 18 16:09:30 <_Lucretia_> gcc (Debian 4.7.1-2) 4.7.1
Oct 18 16:09:33 <_Lucretia_> WTF?
Oct 18 16:10:06 <rburton> _Lucretia_: try BUILD_CCLD
Oct 18 16:10:20 <_Lucretia_> add that too?
Oct 18 16:10:32 <rburton> hm, no, its using cache, so it's not that one
Oct 18 16:10:41 <rburton> _Lucretia_: evil hack: edit meta/conf/bitbake.conf
Oct 18 16:11:27 <msm> is there a way to completly ignore rebuilding dependencies if a tasks signature changes?
Oct 18 16:11:39 <msm> i want to repackage linux-header for example, and not rebuild the world
Oct 18 16:11:58 <bluelightning> msm: not as a one-off, only for every time it changes
Oct 18 16:12:26 <msm> bluelightning: hmm the package itself is not the issue, its the deps
Oct 18 16:12:37 <msm> bluelightning: its rebuilding libc, gcc, etc when I change headers
Oct 18 16:12:50 <msm> that's a huge pain for a developer modifying headers and doing the whole development thing
Oct 18 16:12:57 <bluelightning> yes, that's what I mean
Oct 18 16:13:38 <bluelightning> what I meant was, either the task signature goes into the tasks that depend on it or it doesn't, it can't be skipped once for one change
Oct 18 16:14:09 <msm> bluelightning: right, i'd like something like assume the sig did not change, forcibly rebuild the package
Oct 18 16:15:11 <_Lucretia_> rburton: ta, but would rather not hack it if possible
Oct 18 16:15:47 <rburton> _Lucretia_: very true. my bitbake-fu isn't strong. but changing there would demonstrate that you are attempting to change the right variable
Oct 18 16:16:15 <bluelightning> msm: I think the only way we could handle it would be some kind of signature equivalence, so we can tell the system to assume that the output of the new signature is the same as the old
Oct 18 16:16:23 <_Lucretia_> got all 3 set now, will check the config.log's to make sure
Oct 18 16:16:24 <bluelightning> msm: but there's nothing like that implemented
Oct 18 16:16:36 <msm> bluelightning: right, i can't really think of a hacky way to work around this
Oct 18 16:16:56 <msm> like make a separate package, linux-headers2 and somehow have it replace linux-headers on the rfs?
Oct 18 16:18:34 <_Lucretia_> rburton: should these flags be used to build the initial stuff like quilt?
Oct 18 16:18:41 <bluelightning> msm: but then it sounds like you're replacing it with something where the output genuinely is different, in which case are you sure that doesn't influence anything in the build?
Oct 18 16:20:34 <msm> bluelightning: never sure, i just want a workaround for devs
Oct 18 16:20:58 <msm> think of:  make small header change, rebuild and hours later, make small header change, rebuild...
Oct 18 16:21:17 <msm> mostly, the header bits we change don't effect libc, etc too but it's an educated guess
Oct 18 16:21:19 <rburton> _Lucretia_: yes, they'll be used when building "native" recipes
Oct 18 16:21:32 <_Lucretia_> nope, still picking up 4.7.1
Oct 18 16:21:37 <_Lucretia_> which is gcc
Oct 18 16:22:04 <_Lucretia_> bitbake -e shows correct values tho
Oct 18 16:22:09 <rburton> _Lucretia_: i'd check that quilt is actually doing the right thing and not ignoring your argument
Oct 18 16:22:22 <_Lucretia_> from the recipe?
Oct 18 16:23:40 <_Lucretia_> hmm, sqlite does the same, thing, just checked, seems to be using BUILD_CC, etc.
Oct 18 16:24:05 <_Lucretia_> rburton: so you're saying definitely use BUILD_CXX = "g++-4.6" instead of BUILD_CXX := "g++-4.6"
Oct 18 16:24:06 <_Lucretia_> >?
Oct 18 16:24:18 <bluelightning> _Lucretia_: if you do bitbake -e quilt-native rather than just bitbake -e does it make a difference to the reported value of BUILD_CC ?
Oct 18 16:24:31 <_Lucretia_> will try
Oct 18 16:28:32 <_Lucretia_> bluelightning: nope, it's showing the gcc-4.6
Oct 18 16:28:38 <_Lucretia_> and g++-4.6
Oct 18 16:35:29 <_Lucretia_> bluelightning: I can paste the log if you want to see it, somehow it's getting /usr/bin/gcc when it should be using BUILD_*
Oct 18 16:36:26 <rburton> _Lucretia_: the full do_configure log might be useful
Oct 18 16:36:38 <_Lucretia_> which one?
Oct 18 16:36:43 <_Lucretia_> quilt? sqlite?
Oct 18 16:36:53 <rburton> whatever one isn't doing what you want
Oct 18 16:37:51 <_Lucretia_> ../../build/tmp/work/x86_64-linux/sqlite3-native-3.7.10-r2/sqlite-autoconf-3071000/config.log -> http://pastebin.com/VGGSM031
Oct 18 16:40:40 <msm> why am I getting an error for this
Oct 18 16:40:41 <msm> ERROR: Fetcher failure: Unable to find file file://9a/sstate-u-boot-beagleboard-poky-linux-gnueabi-v2011.06+git7+b1af6f532e0d348b153d5c148369229d24af361a-r3-beagleboard-2-9ad2aeaa56646fd10f5e267def702489_populate-sysroot.tgz anywhere. The paths that were searched were:
Oct 18 16:40:54 <msm> does not seem like this should ever ERROR
Oct 18 16:53:20 <_Lucretia_> what should CC be set to? native or host?
Oct 18 16:53:30 <_Lucretia_> I mean, build or target?
Oct 18 17:12:19 <msm> CC should be set automatically by oe-core
Oct 18 17:12:23 <msm> CC would be the cross compiler
Oct 18 17:12:39 <msm> you can look at bitbake -e somerecipe and see what the defaults are
Oct 18 17:13:44 <_Lucretia_> right, I think that there is a problem with the native stuff not picking up BUILD_CC|CXX|etc
Oct 18 17:14:24 <_Lucretia_> and HOST_* should be for the built target right?
Oct 18 17:15:02 <_Lucretia_> no, that's TARGET
Oct 18 17:15:11 <_Lucretia_> HOST should be same as BUILD in my case
Oct 18 18:53:17 <JaMa> Andrei Dinu here?
Oct 18 19:08:55 <JaMa> rburton: branch is also part of persistent db key, see http://lists.linuxtogo.org/pipermail/openembedded-devel/2012-October/041969.html
Oct 18 19:09:08 <JaMa> rburton: so just removing it will break stuff
Oct 18 19:40:35 <JimNH> How can I get a recipe to be built first/early in the bitbake process? eg we have one area that is under development so build breakage is most likely in this area, which is why we want to build it early.. I didnt see a way to affect the runqueue weightling from a recipe in this way....
Oct 18 19:41:26 <Crofton> bitbake recipe-name
Oct 18 19:42:16 <JimNH> yeah bu then they need to do somehting like bitbake recipe-name; bitbake core-image-minimal...    was hoping to get it in one swoop
Oct 18 19:42:43 <JaMa> rburton: libxaw in meta-oe does not support --disable-xprint or --without-xprint :/
Oct 18 19:42:49 <Crofton> add garbage DEPENDS then
Oct 18 19:43:05 <Crofton> but I would do it as to steap
Oct 18 19:43:08 <Crofton> stpes
Oct 18 19:43:12 <Crofton> steps damn it
Oct 18 19:43:13 <chackal_sjc> is it possible to run python code inside a .conf file
Oct 18 19:43:15 <chackal_sjc> ?
Oct 18 19:44:36 <JaMa> rburton: but all support for that was already removed in libxaw it seems, so fine
Oct 18 20:03:48 <khem> nitink: have you built core-image-lsb with sugarbay using 1.3
Oct 18 20:03:59 <khem> nitink: glib-2.0 pukes on me
Oct 18 20:04:13 <khem> ERROR: QA Issue: package glib-2.0-utils contains bad RPATH /work/yocto/poky/build/tmp-eglibc/sysroots/sugarbay/usr/lib in file /work/yocto/poky/build/tmp-eglibc/work/x86_64-poky-linux/glib-2.0-1_2.32.4-r6/packages-split/glib-2.0-utils/usr/bin/gobject-query
Oct 18 20:04:15 <nitink> khem, didn't try lsb image
Oct 18 20:04:30 <khem> which images do you try
Oct 18 20:04:32 <nitink> khem: will give it a try here and see how it goes
Oct 18 20:04:39 <khem> I need a server kind of image
Oct 18 20:04:39 <nitink> khem: i try core-image-sato
Oct 18 20:04:47 <khem> sato is not interesting for me
Oct 18 20:04:51 <nitink> server?
Oct 18 20:04:55 <khem> yeah
Oct 18 20:05:01 <nitink> what does it mean?
Oct 18 20:05:04 <khem> headless
Oct 18 20:05:07 <khem> no GUI
Oct 18 20:05:13 <khem> but lot of other stuff
Oct 18 20:05:23 <nitink> i see
Oct 18 20:05:29 <nitink> for us graphics in important
Oct 18 20:05:45 <nitink> khem: I will try the lsb image here and see if I can reproduce the issue here
Oct 18 20:05:54 <khem> nitink: ok
Oct 18 20:06:00 <khem> core-image-lsb is what I was trying
Oct 18 20:08:55 <khem> nitink: btw. its all on danny
Oct 18 20:09:06 <chackal_sjc> does anyone knows why I'm getting problems when applying a patch to openjade?
Oct 18 20:09:14 <nitink> khem: I am trying master
Oct 18 20:09:18 <chackal_sjc> btw, some recipe add this dependency that I dont know
Oct 18 22:25:14 <nitink> khem: core-image-lsb builds fine here for sugarbay
Oct 18 22:56:58 <hollisb> is there a video transcoder readily available? the meta-intel ffmpeg recipe doesn't seem to end up packaging the ffmpeg binary
Oct 18 22:57:25 <hollisb> (after reading that recipe, I don't understand why not)
Oct 18 23:00:19 <blloyd_> by main binary do you mean ffplay or ffserver?
Oct 18 23:00:54 <hollisb> I meant ffmpeg(1), but I see it in my image now! so ignore me :-/
Oct 19 01:41:41 <blloyd_> why does core-image-sato get /boot/bzImage but core-image-minimal doesn't?
**** ENDING LOGGING AT Fri Oct 19 03:00:01 2012

**** BEGIN LOGGING AT Fri Oct 19 03:00:01 2012
Oct 19 08:41:25 <bluelightning> morning all
Oct 19 08:54:57 <blloyd_> morning
Oct 19 09:31:28 <phragment> i'm trying to get my own kernel recipe running, but i get do_calidate_branches errors
Oct 19 09:52:02 <RagBal> Can somebody help me with shadow-native? It keeps crying about not being able to stat tmp/sysroots/x86-64-linux/usr/share/gettext/config.rpath
Oct 19 09:52:17 <RagBal> I tried to build gettext manually and it succeeds
Oct 19 09:52:36 <RagBal> But I can't find the file shadow-native asks about
Oct 19 10:27:52 <RagBal> Problem fixed, I needed to clean and rebuild gettext-minimal-native
Oct 19 10:30:47 <JaMa> RagBal: see http://git.openembedded.org/openembedded-core/commit/?id=6b12d4cd39bacb087654b59e25f5052a4e839b26
Oct 19 10:35:58 <RagBal> Ahh
Oct 19 10:37:31 <RagBal> Thanks for your help
Oct 19 10:38:16 <JaMa> yw
Oct 19 10:39:31 <RagBal> Weird that the files were available in another project I build
Oct 19 10:39:58 <JaMa> it depends on order of tasks
Oct 19 10:40:03 <RagBal> Build was before the change in gettext
Oct 19 10:40:20 <RagBal> Hmm I see
Oct 19 10:41:10 <JaMa> gettext-native depends on gettext-minimal-native, so gettext-minimal-native installs own config.rpath to sysroot (when gettext-native "owns" it too)
Oct 19 10:41:37 <JaMa> then gettext-native is built and before populting sysroot it removes own files there (including config.rpath)
Oct 19 10:43:15 <RagBal> How handy =)
Oct 19 10:43:28 <JaMa> and because sstate assumes that every file in sysroot is provided by exactly one recipe, gettext-minimal-native looses his config.rpath
Oct 19 10:43:52 <RagBal> Yes I'm starting to understand
Oct 19 10:44:32 <JaMa> now there is at least warning when 2 recipes are installing the same file to sysroot, but that doesn't resolve this issues when some file is "moved" betweee recipes
Oct 19 10:44:52 <RagBal> Can I use a central place for downloads? Like so I don't need to download and unpack every package in a new project
Oct 19 10:45:10 <RagBal> I didn't receive such warning
Oct 19 10:45:37 <JaMa> RagBal: it's now shown in this gettext case
Oct 19 10:45:44 <RagBal> Only that it couldn't find the desired file from the gettext folder
Oct 19 10:45:52 <RagBal> Ahh ok
Oct 19 10:47:13 <JaMa> because gettext-minimal-native is only recipe installing it
Oct 19 10:47:22 <JaMa> and gettext-native is only removing it :)
Oct 19 10:49:58 <RagBal> So a recipe removes files in its sysroot folder before populating it?
Oct 19 10:50:52 <JaMa> yes
Oct 19 10:51:20 <RagBal> Then I understand =)
Oct 19 10:52:30 <RagBal> So what happens to a package if I build it manually, it gets placed in the sysroot. Will it be put in the rootfs image when I build a complete image by?
Oct 19 10:55:11 <RagBal> Because that is a proces I do not yet understand correctly I think
Oct 19 10:56:14 <JaMa> no sysroot and rootfs are created different
Oct 19 10:56:54 <JaMa> rootfs is created from runtime packages (e.g. ipk files) by package manager (e.g. opkg) and what goes in rootfs is defined in image recipe
Oct 19 10:57:35 <RagBal> Ok, so the sysroot is there only for dependencies?
Oct 19 11:03:06 <bluelightning> RagBal: build time dependencies (mostly libraries and include files) yes
Oct 19 11:03:47 <RagBal> Ok thanks
Oct 19 12:21:46 <ag> Hello ppl.
Oct 19 12:22:21 <ag> It seems like after some lately submitted patches bison is failing.
Oct 19 12:22:48 <ag> In it's aclocal.m4 AM_MKINSTALLDIRS doesn't get defined anymore.
Oct 19 12:23:00 <ag> RP__: Could this be after your changes in autotools?
Oct 19 12:28:02 <RP__> ag: the gplv2 bison?
Oct 19 12:28:16 <ag> RP__: Yes.
Oct 19 12:28:31 <RP__> ag: We know about this problem...
Oct 19 12:28:39 <RP__> ag: It is the autotools changes
Oct 19 12:29:02 <ag> RP__: I knew it.
Oct 19 12:29:12 <ag> RP__: Somebody on this?
Oct 19 12:29:40 <RP__> ag: me...
Oct 19 12:29:56 <ag> RP__: Ok. meta-ivi is broken now because of this.
Oct 19 12:30:10 <RP__> ag: It will get fixed imminently
Oct 19 12:30:31 <ag> RP__: Ok thanks.
Oct 19 12:30:44 <ag> In the meanwhile i will revert your patches locally
Oct 19 13:06:23 <RP__> ag: should be fixed now
Oct 19 13:14:36 <ag> i will check
Oct 19 13:14:40 <ag> RP__: Thanks
Oct 19 13:51:55 <RagBal> Do I need to recompile the rootfs image after rebuilding a virtual/kernel?
Oct 19 13:52:10 <RagBal> I added a driver to the kernel
Oct 19 15:06:37 <halstead> We saw some high network traffic and slow page loads during the last 10 minutes.
Oct 19 15:08:11 <halstead> Everything appears to be fine now but there is a chance that page loads  or downloads from *.yoctoproject.org could have timed out for some users.
Oct 19 15:11:40 <bluelightning> fray: ping
Oct 19 15:24:14 <msm> RP__: more fetcher errors… this is on danny
Oct 19 15:24:23 <msm> RP__: some reason im getting ERRORS when trying to fetch
Oct 19 15:24:53 <RP__> msm: related to halstead's comment above?
Oct 19 15:25:16 <msm> RP__: no this is internal
Oct 19 15:25:29 <msm> RP__: although it could be from our internal mirror being flaky
Oct 19 15:25:41 <RP__> msm: I have no idea...
Oct 19 15:26:52 <msm> ERROR: Fetcher failure: Unable to find file file://3b/sstate-tzdata-all-poky-linux-2012d-r2-allarch-2-3bdc92c07b2c1bd4bf68d5b7e65130ff_package.tgz anywhere. The paths that were searched were:
Oct 19 15:27:02 <msm> any idea why that's getting promoted to an ERROR sometimes?
Oct 19 15:27:28 <msm> seems like fetching sstate-cache failure should not ever be an error?
Oct 19 15:27:47 <kergoth> i've seen that once in a blue moon too
Oct 19 15:30:25 <msm> its occuring a decent amount for me
Oct 19 15:31:20 <kergoth> right now i'm only using a local sstate mirror, not sure if thats a factor
Oct 19 15:33:52 <kergoth> so, i've noticed that danny and master seem to have separated now. is that right?
Oct 19 15:34:01 <kergoth> just want to be sure
Oct 19 15:36:43 <bluelightning> kergoth: yes
Oct 19 15:37:19 <bluelightning> the branch happened a week or two ago, and stuff has now been merged into master that is not going into danny (or at least, unless it is later proposed for backporting)
Oct 19 15:37:28 <bluelightning> AIUI
Oct 19 15:38:14 <kergoth> k, thanks
Oct 19 15:38:21 <kergoth> yeah i knew about the branch, just it was being updated in sync until recently
Oct 19 15:38:24 <kergoth> so wanted to verify :)
Oct 19 15:41:53 <kergoth> what the thell..
Oct 19 15:41:56 <kergoth> the hell, even
Oct 19 15:41:57 <kergoth> Summary: There were 2 WARNING messages shown.
Oct 19 15:41:58 <kergoth> Couldn't get default commandline! None
Oct 19 15:42:02 * kergoth scratches head
Oct 19 15:45:17 <kergoth> the automated builds always fail in ways ordinary builds enver seem to, i swear
Oct 19 16:11:26 <RP__> kergoth, msm: There can be "odd things" happen with sstate if you've excluded things like DATE/TIME from the sstate checksum yet they change
Oct 19 16:11:54 <RP__> kergoth, msm: At least that is one case I've seen the sstate fetch fail as DATE changes from under bitbake
Oct 19 16:12:12 <RP__> The initial sstate code searches for one sstate filename, the fetch then tries to get something different
Oct 19 16:12:37 <RP__> How it would do that for tzdata I'm not sure though
Oct 19 16:14:09 <msm> RP__: another hint - that sstate-cache file does exist on my http mirror
Oct 19 16:14:28 <msm> so it's prob http / network issues
Oct 19 16:14:37 <msm> which means wget error codes
Oct 19 16:14:43 <msm> which means actual bitbake error
Oct 19 16:14:49 <msm> that's my guess so far anyway
Oct 19 16:15:32 <RP__> msm: right, that sounds like a network issue and is why bitbake is actually erroring
Oct 19 16:15:42 <RP__> it thought it should exist and then couldn't get it
Oct 19 16:16:13 <kergoth> the error he showed was about the file:// path. if it doesn't realize that the fetch failed, then that's a bitbake bug
Oct 19 16:16:16 <msm> right, but even if a fetch fails… what should occur?
Oct 19 16:16:45 <RP__> msm: well, whilst bitbake will show the error, it will recover and continue the build
Oct 19 16:16:48 <kergoth> a fetch failure from an sstate mirror should jsut result in a rebuild, not a bitbake failure
Oct 19 16:17:32 <RP__> kergoth: It outputs an ERROR message since something unexpected happend which in turn sets the exit code but the build itself will succeed
Oct 19 16:17:46 <RP__> perhaps we should just reset the error counter setscene -> runqueue
Oct 19 16:18:16 <RP__> kergoth: I'm not defending the behaviour, just pointing out it does actually do mostly the right things apart from the exit code
Oct 19 16:18:24 <kergoth> we shouldn't show an error if it was a 404. it's *expected* that most of thed time a sstate mirror wont have the current archive
Oct 19 16:18:30 <kergoth> other than that, i'd agree
Oct 19 16:19:02 <RP__> kergoth: except that it checked and it previously verified the url, then it was later 404
Oct 19 16:19:14 <kergoth> ah, right
Oct 19 16:19:32 <RP__> kergoth: The code does an initial batch check of which sstate objects it can get. It only runs the sstate fetch if the quick verifications succeed
Oct 19 16:19:49 <kergoth> right, forgot about that, my mistake
Oct 19 16:21:42 <msm> RP__: I don't like ERROR codes if the build succeeds - but then again it was a real error
Oct 19 16:22:06 <RP__> msm: We probably should leave the ERROR message but clear the exit code for this...
Oct 19 16:22:40 <kergoth> i don't like the exit code vs ERROR handling, personally. if it says it failed, then it should have failed, not continued on its merry way :)
Oct 19 16:28:54 <blloyd_> my two cents: that's an issue (it's recoverable in an automated manner).  If it recovers, log it as an ISSUE not as an ERROR and continue on.  The logging lets you track it continue, the lack of ERRORS allows for a sane double check that everything worked.  I don't want to trust a build where the log has ERROR in it.  :)
Oct 19 16:29:45 <blloyd_> (WARNING would work for this)
Oct 19 16:30:09 <kergoth> yeah, i think we should drop the non-fatal error in favor of warnings for anything taht can be automatically handled, where the build continues
Oct 19 16:33:28 <khem> nitink1: to reproduce that glib-2.0 failure you need to build two x86_64 machines in same build dir
Oct 19 16:33:59 <khem> nitink1: e.g. MACHINE=qemux86-64 bitbake glib-2.0;MACHINE=sugarbay bitbake glib-2.0
Oct 19 16:34:07 <khem> nitink1: second one will always fail
Oct 19 16:34:38 <khem> its all due to libtool
Oct 19 16:34:44 * kergoth tries to figure out why the returned commandline is sometimes None, sometimes an error mesage,a nd sometimes successful
Oct 19 16:34:51 <khem> can we get rid of .la files once for all
Oct 19 16:35:10 <kergoth> khem: pb posted a patch to make it optional according to the distro
Oct 19 16:36:59 <RP__> khem: why aren't the .la files being processed correctly though? That worries me more...
Oct 19 16:40:24 <blloyd_> Something to look into: .la have a lot of system validation in them.  It may be that anything that uses .la files should go in the MACHINE work directory, not a generic x86_64 directory because the sanity checks could be making use of an unexpected items (anyone know what the sanity checks are?)
Oct 19 16:42:32 <nitink1> khem: I generally don't build 2 machines in one builddir
Oct 19 16:43:40 <blloyd_> Considering the glitches I get, I had assumed multiple machines one build directory is unsupported...
Oct 19 16:43:45 <nitink1> khem: sugarbay & qemux86-64 also need different layer configuration
Oct 19 16:44:58 <khem> kergoth: hmm may be I should try it
Oct 19 16:45:11 <khem> nitink1: that does not alleviate the problem
Oct 19 16:45:30 <ant_work> fwiw I do regulary build for machines living in the same layer, even mixing armv4 and armv5
Oct 19 16:45:30 <blloyd_> nitink1: why?  sugarbay needs MORE layers, not different ones.  But those layers shouldn't be making changes when it is not a sugarbay build.  (IE, I've seen no problems building a qemu test with the same config as long as it was done with clean sstate and tmp folders).
Oct 19 16:45:37 <kergoth> nitink1: good bsp layers can be added even when not targeting the machine they include, by leveraging overrides
Oct 19 16:45:40 * kergoth nods at blloyd_ 
Oct 19 16:46:12 <khem> the problem is actually in glib-2.0 rebuild
Oct 19 16:47:25 <khem> sugarbay even though x86_64 triggers rebuild of glib-2.0 then glib-2.0 has libtool magic which it totally screws up since now sysroot is something else and does not add proper paths to dependencies and so on
Oct 19 16:47:35 <nitink1> kergoth: blloyd_: meta-intel layers also extend some common recipes, which is not tested for qemu machines, so it may work, but it is not officially tested regularly
Oct 19 16:48:32 <khem> nitink1: having single tmpdir for every machine is not a solution real users are using
Oct 19 16:48:42 <khem> you have more than one machine to cater to usually
Oct 19 16:48:55 <khem> it works out ok if they are totally different
Oct 19 16:49:25 <khem> someone needs to dig into glib-2.0 and see why it creates different .la files on rebuild
Oct 19 16:49:27 <nitink1> khem: I understand your point, if there are issues, then bugs should be opened for these kind of issues
Oct 19 16:50:07 <khem> nitink1: my setups may not be same thats why I was reconfirming
Oct 19 16:50:09 <blloyd_> a quick perusal of the .bbappend files has proper _machine_name_here on the lines.
Oct 19 16:50:17 <khem> I have many x86 variants to build
Oct 19 16:50:28 <nitink1> but for the priority of issues, it may not get as much attention because the problem can be avoided easily
Oct 19 16:50:32 <khem> and its way better to build them in common tmpdir
Oct 19 16:51:08 <khem> nitink1: meta-intel recommends using separate tmpdir for each machine ?
Oct 19 16:51:22 <nitink1> khem: there are also advantage to this approach, but the testing is not done that way yet
Oct 19 16:51:32 <khem> I bet if you chose two x86_64 machines from meta-intel problem with exhibit
Oct 19 16:51:37 <khem> you dont have to chose qemu
Oct 19 16:51:48 <khem> hmm
Oct 19 16:52:06 <nitink1> khem: I think we do not have a recommendation for it yet, but good to bring this to RP and others for discussion
Oct 19 16:52:12 <blloyd_> guess I should be thankful my hardware is radically different.
Oct 19 16:52:32 <khem> yocto doesnt use $MACHINE to quality tmpdir
Oct 19 16:52:45 <khem> which means it expect such combination to work
Oct 19 16:52:53 <nitink1> there are also issues with this approch
Oct 19 16:53:36 <nitink1> even for x86_64 arch there are different tunes, and one package may be build differently for different machine
Oct 19 16:53:41 <kergoth> hmm, http://pypi.python.org/pypi/datadiff looks cute. that'd be useful for the sstate sig diff
Oct 19 16:54:03 <blloyd_> ok, there are at least two lines in meta-intel without machine specific overrides, so guess it has unexpected side affects.
Oct 19 16:54:16 <nitink1> khem: I am seeing build of qemux86-64 is failing when run from the sugarbay build dir
Oct 19 16:54:25 <khem> nitink1: ok
Oct 19 16:54:38 <nitink1> khem: it is different issue though
Oct 19 16:55:31 <nitink1> I would like to stress, that such combinations are not part of our regular testing
Oct 19 16:56:25 <nitink1> but it would be nice to get this working, so opening of bugs for these issues is welcome
Oct 19 16:57:04 <khem> nitink1: I can open the issue
Oct 19 16:57:14 <kergoth> nitink1: not sure what you're reerring to with tuning. if a pcakge is specific to a machine, it's marked as such, and its files go in the machine specific areas of the tmpdir
Oct 19 16:58:49 <blloyd_> I'm lost on what includes the files in the /boot directory.  core-image-sato usually gets a kernel, but core-image-minimal doesn't (though linux-yocto is build for the minimal).
Oct 19 17:00:00 <nitink1> kergoth: that is the idea, but it may not work that way for all the recipes
Oct 19 17:00:35 <kergoth> nitink1: welll, we've supported mutlimachine bulids in tmpdir for >5 years
Oct 19 17:00:40 <kergoth> so if any don't, they're broken
Oct 19 17:01:11 <nitink1> kergoth: yes if it is broken we would like to know, so we can fix it
Oct 19 17:11:14 <khem> kergoth: the problem is CFLAGS change
Oct 19 17:11:22 <khem> kergoth: e.g. -march and -mtune
Oct 19 17:14:13 <khem> for x86 though I would choose -march=natve -mtune=native and be done with all variant
Oct 19 17:28:29 <blloyd_> khem: if you build on an x86_64 for a x86, that doesn't do what you want...
Oct 19 17:30:38 <blloyd_> unless you do a specific compiler for every machine, where the cross compiler knows the tune and arch, but then EVERYTHING would be MACHINE specific (as $MACHINE would need to be used to find the compiler).
Oct 19 17:31:38 <khem> of course not
Oct 19 17:32:43 <blloyd_> IE, -mtune=native causes the compiler to auto-detect the CPU of the
Oct 19 17:32:43 <blloyd_>            build computer
Oct 19 17:33:07 <blloyd_> auto-detection doesn't work so well for cross compiling.
Oct 19 17:39:02 <khem> sgw: around ?
Oct 19 17:39:25 <khem> sgw: how do you build for many machines on autobuilder
Oct 19 17:39:48 <khem> Do you build and clean tmpdir each time
Oct 19 17:40:01 <sgw> khem: that would be a pidge question, I will do my best to answer
Oct 19 17:40:09 <khem> sure
Oct 19 17:40:26 <khem> I am interested to know if you use same tmpdir to build more than one machine
Oct 19 17:40:29 <khem> thats all
Oct 19 17:40:53 <sgw> khem: each machine has it's own tmp dir, so arm and arm-lsb are build in 2 different tmp dirs.  qemuarm and beagleboard are built together
Oct 19 17:41:37 <sgw> Also since we build across multiple hardware, we share the sstate and DL_DIR on an NFS server, so we get the sstate gains.
Oct 19 17:42:11 <sgw> khem:  does that all make sense?
Oct 19 17:45:32 <khem> kind of :) but you confused me
Oct 19 17:45:40 <khem> arm and arm-lsb are separate
Oct 19 17:45:52 <khem> but qemuarm and beagle arent
Oct 19 17:45:56 <khem> why is that
Oct 19 17:46:21 <khem> it seems there is no homogenous policy on multimachine builds then as it seems
Oct 19 17:47:55 <kergoth> as long as you use sstate, builds with separate tmpdirs aren't too horrible. heh, right now our autobuilder isn't even leveraging sstate
Oct 19 17:47:58 <kergoth> it's painful :)
Oct 19 17:48:06 <kergoth> (our = mentor)
Oct 19 18:03:31 <sgw> khem: the lsb variant needs to be separate because of the changes in core distro flags, you can have multiple machines together, but not multiple distros.
Oct 19 18:04:30 <sgw> khem, we could build multiple machines in the same tmp dir if we wanted, but then it would start to serialize the build, so we do it in different tmp dirs to get more parallel builds.
Oct 19 18:05:35 <sgw> khem: we run 2 builds in parallel on each build machine across I think 5 or 6 build machines
Oct 19 18:09:00 <khem> sgw: ok distro is clear
Oct 19 18:09:26 <khem> sgw: I am interested in multimachine which you hinted you do for qemuarm and beagel
Oct 19 18:09:29 <khem> beagle
Oct 19 18:09:47 <khem> but how about similar machines e.g. qemux86-64 and sugarbay
Oct 19 18:10:09 <khem> kergoth: yes I am setting up for individual machine builds
Oct 19 18:10:22 <khem> and hoping that sstate delivers
Oct 19 18:11:33 <khem> sgw: on the other hand core-image-lsb are they only suitable for poky-lsb
Oct 19 18:12:55 <sgw> khen: you you can do qemux86-64 and sugarbay together no problems, I am building all sorts of different qemu* and hw targets in the same tmp dir, we just built out the autobuilder for performance.
Oct 19 18:13:09 <sgw> khem: sstate works well for this.
Oct 19 18:13:22 <sgw> khem: correct about the lsb side.
Oct 19 18:14:59 <sgw> khem: just saw the bug you filed, I will try here in a clean build area!
Oct 19 18:21:55 <mranostay> kergoth: hey you going to E-ELC?
Oct 19 18:35:53 <blloyd_> should there be differences between say the .ext3 and .hddimg contents?
Oct 19 18:36:43 <mranostay> ah
Oct 19 18:40:57 <khem> blloyd_: hddimage has kernel and stuff in it
Oct 19 18:41:11 <khem> its raw disk image
Oct 19 18:43:38 <mranostay> khem: something you can dd onto a hard drive i take?
Oct 19 18:59:33 <hutchman> Hi
Oct 19 19:00:34 <hutchman> I'm stuck bad.  Trying to bitbake meta-toolchain-sdk with poky 1.1.  Keep getting errors on gnome-doc-utils
Oct 19 19:01:18 <hutchman> ... stuff like: | warning: failed to load external entity "db2omf.lang" | cannot parse db2omf.lang | make[2]: *** [gnome-doc-make-C.omf] Error 1
Oct 19 19:02:23 <khem> mranostay: yep
Oct 19 19:05:32 <hutchman> I'm on Ubuntu 10.04.  I see where a patch was put in to gnome-desktop.inc to turn off docs with --disable-desktop-docs and my .inc has that but I still have the problem.  Google doesn't help much.
Oct 19 19:09:46 <hutchman> I think my irc client is hosed .. I don't see anybody talking.
Oct 19 19:28:58 <khem> kergoth: re the sstate stuff
Oct 19 19:29:34 <khem> kergoth: are you able to share the same sstate for native builds across distrinct host distros
Oct 19 19:32:04 <kergoth> khem: we do our automated builds on an old distro (centos5.4) and then reuse them on newer distros, yes
Oct 19 19:32:14 <khem> kergoth: nice
Oct 19 19:32:18 <khem> whats your setup like
Oct 19 19:32:23 <khem> i need something like that
Oct 19 19:32:42 <khem> right now I am struggling between different versions of ubuntu
Oct 19 19:32:50 <kergoth> http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/tree/classes/sstate-reuse.bbclass sets up the sstate mirrors to check the compatible distro paths
Oct 19 19:33:25 <kergoth> http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/tree/conf/distro/include/sstate.inc is our config
Oct 19 19:33:33 <khem> hmm
Oct 19 19:34:10 <hutchman> Chris, is there a howto on sstate? I have questions about that too (I'm Brian Hutchinson, sat with you a few times at ELC SF).
Oct 19 19:36:24 <kergoth> i'm not sure if there's a howto on it in general
Oct 19 19:37:58 <hutchman> Is there another way to generate a sysroot other than bitbake meta-toolchain-sdk?  bitbake meta-toolchain worked no problem but has no sysroot.  I'm trying to spin a x86 toolchain that has the sysroot.
Oct 19 19:38:57 <hutchman> Thanks.  Last time I looked I think I found some emails Hart wrote.  I'll have to check them out again.  I could probably use sstate to share my work with others here at work.
Oct 19 19:51:31 <JaMa> RP_: I've noticed that 2 PACKAGES_DYNAMIC patches are now in master without that fix for kernel-modules which is only in master-next (kernel.bbclass: add kernel-modules to PACKAGES)
Oct 19 20:07:22 <msm> hutchman: your best bet is to ask questions here
Oct 19 20:12:25 <hutchman> I did but everyone must be asleep! :)
Oct 19 20:14:20 <hutchman> Is there a way for me to exclude gnome desktop from bitbake meta-toolchain-sdk?  I don't even care about gnome stuff in our build.
Oct 19 20:14:44 <fray> there is no way to exclude, the only thing you can do is copy and re-write the rules..
Oct 19 20:14:48 <fray> (hob does this)
Oct 19 20:15:08 <fray> if you just want an SDK that matches a given image, one that doesn't include gnome..
Oct 19 20:15:14 <fray> bitbake -c populate_sdk <image>
Oct 19 20:16:11 <hutchman> I don't know that I can use hob ... I don't think it worked so well with the first release (we are currently stuck using Edison/Poky 1.1)
Oct 19 20:16:33 <fray> if you are on edison, then your only choice is to copy and change -- or backport the populate_sdk changes
Oct 19 20:17:15 <fray> this is one of the reasons that populate_sdk was implemented.. (we, wind river) have customer requirements that the SDK match the filesystem image that they have created.. the meta-toolchain* SDKs are not useful to us
Oct 19 20:18:10 <hutchman> OK, so I have an ARM image that generates a rootfs that I'm happy with.  The same app needs to run on Debian x86.  I wanted to generate an external toolchain that had the sysroot since a "rootfs" isn't generated for the x86, only the application .debs so that is why I was trying to build meta-toolchain-sdk
Oct 19 20:18:39 <fray> if I understand correctly.. that is what the procedure was in 1.1
Oct 19 20:20:08 <hutchman> bitbake -c populate_sdk <image> is a new one on me.  Where can I learn more about it?  My only other thought was to install the -dev packages on Debian and build our app native.
Oct 19 20:20:17 <fray> it's avaialble in 1.3
Oct 19 20:20:33 <fray> (which will be released 'soon'..  it's in master of oe-core/yocto project - poky
Oct 19 20:20:49 <fray> it simply creates an SDK from the image recipe.. using hte results of the image recipe to generate the sysroot
Oct 19 20:21:55 <hutchman> I'll have to setup a "latest" sandbox and check it out.  I normally only focus on embedded targets, this is the first time I've had to have something run on an embedded target AND the x86.
Oct 19 20:22:36 <fray> ya the populate_sdk does not need a constructed 'image'.. it just uses the image recipe to specify what will be in the SDK
Oct 19 20:22:52 <fray> if you look at:
Oct 19 20:22:55 <fray> http://git.yoctoproject.org/cgit/cgit.cgi/poky/log/?qt=grep&q=populate_sdk
Oct 19 20:23:09 <fray> the 5 commits from 2012-07-03 implement it
Oct 19 20:23:18 <hutchman> So will I get a tarball that I extract to /opt and it will have sysroot populate with all the /usr/include /usr/lib stuff?
Oct 19 20:23:45 <fray> with the 1.3 stuff the SDK is a .shar (sh installed) self extracting archive.. it will install anywhere you want it
Oct 19 20:23:59 <fray> for pre 1.3 yes, it will be the same as any SDK (if you back port it)
Oct 19 20:24:13 <fray> at Wind River we back ported it to 1.2, as that is the basis of our commerical product
Oct 19 20:25:59 <hutchman> That sounds like that is what I need.  Did it suck to back port it or was it not too bad?  I figure we are stuck with 1.1 for a while.
Oct 19 20:26:25 <fray> for 1.1, I don't know if you'll be able to.  There were some changes to bitbake as well to enable some dependency resolution issues..
Oct 19 20:26:44 <fray> in 1.2 (release) and before, bitbake assumes any dependency is needed, even if you don't execute that task in a given recipe..
Oct 19 20:27:01 <fray> in the 1.3 development we fixed that, and dependencies are only evaluated if the task will be executed
Oct 19 20:27:26 <hutchman> Great!  Maybe I should just try my native build approach and install the -dev packages that are needed.
Oct 19 20:27:27 <fray> (more or less the side effect is if you back port this to raw 1.2, w/o the bitbake change, you end up always building the nativesdk components..
Oct 19 20:27:52 <fray> it just wastes build time for people who do NOT want an SDK
Oct 19 20:28:19 <fray> all of it though should be pretty easy to backport to 1.2, I don't remember how much of the SDK/Image generation changed between 1.1 and 1.2 though
Oct 19 20:28:55 * fray has to run.. he has a flight in a bit..
Oct 19 20:29:01 <fray> Hopefully this helpd.
Oct 19 20:30:33 <hutchman> I think that is part of my problem now.  bitbake meta-toolchain-sdk for me fails on gnome-doc-utils-native.  So I thought I was slick and removed that depends and then it fails on gnome-doc-utils with some crazy stuff about | warning: failed to load external entity "db2omf.lang" | cannot parse db2omf.lang | make[2]: *** [gnome-doc-make-C.omf] Error 1
Oct 19 20:30:58 <hutchman> Thanks Fry .. you're the man!
Oct 19 20:33:47 <hutchman> anybody else got multi-arch external toolchain wisdom?
Oct 19 20:38:35 <Crofton> hutchman, I still bet on some tool trying to fetch from outside
Oct 19 20:38:43 <Crofton> pastebin a larger section of the failyre
Oct 19 20:39:43 <hutchman> OK, Phil, you asked for it .... wait for it ....
Oct 19 20:40:55 <hutchman> NOTE: package gnome-doc-utils-0.20.6-r5: task do_compile: Started ERROR: Function 'do_compile' failed (see /home/hutch/ion-u/yocto/build/tmp/work/i586-poky-linux/gnome-doc-utils-0.20.6-r5/temp/log.do_compile.13516 for further information) ERROR: Logfile of failure stored in: /home/hutch/ion-u/yocto/build/tmp/work/i586-poky-linux/gnome-doc-utils-0.20.6-r5/temp/log.do_compile.13516 Log data follows: | DEBUG: SITE files ['endian-little',
Oct 19 20:41:30 <hutchman> Wow, that didn't work so well.  I'll email it to you.
Oct 19 20:43:23 <hutchman> Phillip, I guess I couldn't past that much so check your email.
Oct 19 20:46:33 <Crofton> try running the xsltproc command by hand
Oct 19 20:46:54 <Crofton> also restart the build and see if it gets past that point and fails later in a similar way
Oct 19 20:47:04 <Crofton> it is not quite what I recall though
Oct 19 20:47:52 <hutchman> Roger, wait one.
Oct 19 20:49:24 <otavio> Can someone update the LayerIndex entry of meta-fsl-arm to Yocto's git server?
Oct 19 20:56:19 <kergoth> hmmm, bitbake doesn't check PKG_<pkg> when determining what runtime bits are provided. i guess it expects the expressed rdepends to be the un-altered name, rather than the altered one.
Oct 19 20:56:23 * kergoth ponders
Oct 19 21:01:44 <hutchman> Phillip, I smoked my shell by accident and kicked off a new build.  It fails on the same package but in a different way.  I posted it to the mailing list.
Oct 19 21:07:16 <Crofton> something evil is in there
Oct 19 21:10:18 <kergoth> i think hutchman is cursed
Oct 19 21:10:29 <hutchman> I wonder if I hosed something up.  I copied and pasted that xsltproc line that failed and I think I copied too much and that exit killed my shell.  Now I'm getting a segfault in there so I wonder if it is the result of me trying to run that xsltproc command by hand.
Oct 19 21:11:13 <kergoth> msm, RP__: just hit one of the sstate fetch failure issues. quite odd, since the mirror is local. file:// uri.
Oct 19 21:11:17 * kergoth scratches head
Oct 19 21:11:59 <hutchman> You are probably right Chris.  I should probably hang out with you guys more on here but it is such a pain.  This IRC stuff is blocked from work so I have to nomachine to my home box and go out that way.  Kinda sucks.
Oct 19 21:12:33 <hutchman> I don't think I've talked with you guys much since the conference :(
Oct 19 21:13:21 <Crofton> hutchman, actually, that is pretty normal for many people
Oct 19 21:13:41 <kergoth> it is relatively common, sadly
Oct 19 21:13:43 <kergoth> :(
Oct 19 21:13:44 <Crofton> there is a -nonet in there, which may address the issue I was having
Oct 19 21:14:11 <Crofton> I am inside u-boot atm
Oct 19 21:15:42 <hutchman> Well, it is getting close to quitting time here on the "Right" coast :)  I'm already getting calls on where am I for dinner.  Good chatting with you guys!  Have a good weekend.  I'll have another go at this later and I'll try to do better hanging out here so you guys can attempt to school me!
Oct 19 21:15:47 <msm> kergoth: hmmmm
Oct 19 21:15:50 <Crofton> l8r
Oct 19 21:15:51 <msm> kergoth: is this your old centos box?
Oct 19 21:20:22 <kergoth> not this particular build, nope. this one is u12.04
Oct 19 21:22:38 <msm> hmm
Oct 19 21:22:40 <msm> maybe mine was local too
Oct 19 21:23:15 <kergoth> quite odd
Oct 19 21:23:41 <msm> i should probably look closer
Oct 19 21:24:04 <msm> kergoth: clearly mine were local too
Oct 19 21:24:11 <msm> $ git grep 'anywhere. The paths that were search'
Oct 19 21:24:11 <msm> bitbake/lib/bb/fetch2/local.py:            msg = "Unable to find file " + url + " anywhere. The paths t
Oct 19 21:24:43 <msm> i just assumed too much before w/o looking
Oct 19 21:26:46 <msm> the file is local
Oct 19 21:26:58 <msm> but it looks corrupt
Oct 19 21:27:26 <msm> the sstate tgz file looks to contain a directory output
Oct 19 21:28:32 <msm> well
Oct 19 21:28:51 <msm> i get one thing if i cat $sstatefile vs. less $sstatefile
Oct 19 21:29:39 <kergoth> less can handle compression, iirc
Oct 19 21:29:43 <kergoth> maybe thats it
Oct 19 21:30:16 <msm> ah
Oct 19 21:30:35 <msm> well the two files are different:
Oct 19 21:30:35 <msm> $ md5sum /opt/yocto/upstream/label/master/machine/mpc8315e-rdb/poky/danny/sstate-cache/c3/sstate-blktool-ppce300c3-poky-linux-4-6-r0-ppce300c3-2-c323cee914ba9a650ef741ec484637b3_populate-lic.tgz /mnt/yocto/sstate-cache/c3/sstate-blktool-ppce300c3-poky-linux-4-6-r0-ppce300c3-2-c323cee914ba9a650ef741ec484637b3_populate-lic.tgz
Oct 19 21:30:36 <msm> ae1ccc3f1feedb0a618b1e0e4bfb7473  /opt/yocto/upstream/label/master/machine/mpc8315e-rdb/poky/danny/sstate-cache/c3/sstate-blktool-ppce300c3-poky-linux-4-6-r0-ppce300c3-2-c323cee914ba9a650ef741ec484637b3_populate-lic.tgz
Oct 19 21:30:36 <msm> d43d087dbf0452b98632423c16ac1b61  /mnt/yocto/sstate-cache/c3/sstate-blktool-ppce300c3-poky-linux-4-6-r0-ppce300c3-2-c323cee914ba9a650ef741ec484637b3_populate-lic.tgz
Oct 19 21:30:43 <msm> (one is my http mirror)
Oct 19 21:31:24 <kergoth> huh
Oct 19 21:33:14 <msm> just comparting the sstate in the build vs. what's on the mirror
Oct 19 21:33:22 <msm> the content looks the same though
Oct 19 21:42:38 <blloyd_> https://wiki.yoctoproject.org/wiki/How_do_I#Q:_How_do_I_put_Yocto_on_a_hard_drive.3F implies that the .ext3 images should have a kernel on them.  sato does.  Can anyone tell me what I need to do to make sure a kernel makes it into the image?
Oct 19 21:43:03 <blloyd_> this is using latest danzil.
Oct 19 23:02:39 <kergoth> Hmm, either callers of runCommand need to use isinstance() o its result, or I need to change it to do a multiple return (result, error), or we need to let it raise exceptions
**** ENDING LOGGING AT Sat Oct 20 03:00:02 2012

**** BEGIN LOGGING AT Sat Oct 20 03:00:03 2012
Oct 20 06:20:09 <blloyd_> I keep running out of disk space with 60GB left on the system (outside bitbake I'm creating and deleting files just fine).  Is there a way to recover from what the break did to sstate-cache and/or tmp?  Or is blow them away and recreate them?
Oct 20 06:20:33 <blloyd_> It's happened twice now, first time I just blew everything away and tried again.
Oct 20 06:21:27 <evanp> blloyd_: there's an optional thing you can enable that tries to clean up the workdirs as it builds to reduce footprint
Oct 20 06:21:35 <evanp> blloyd_: think it was rm_work...
Oct 20 06:22:29 <blloyd_> I have plenty of disk space.  360GB disk, < 90GB used typically.  60GB+ free when it dies....
Oct 20 06:22:45 <blloyd_> ok, 360GB partition.
Oct 20 06:24:31 <evanp> blloyd_: Oh.... You're not low on inodes or something are you...?
Oct 20 06:25:43 <blloyd_> (I'd kind of like to figure why it dies so horribly claiming out of space)  Anyways, both times it happens I get can't process config when I try to run bitbake again.
Oct 20 06:28:55 <blloyd_> 4GB worth of ready to use inodes without allocating more space for inodes (which there's 60GB it could allocate from).  Anyone done much with btrfs?
Oct 20 06:30:58 <evanp> blloyd_: maybe you have an absurdly high block reservation for root?
Oct 20 06:33:23 <evanp> blloyd_: I have a vague memory of some email/blog/something from the btrfs author talking about how the free space calculation was very difficult to extract meaning from
Oct 20 06:33:59 <evanp> blloyd_: I could be misremembering though. Google before you beleive me.
Oct 20 06:37:37 <blloyd_> df -h .   is pretty useless for btrfs, but it has other options btrfs fi df .  is more helpful.
Oct 20 06:38:07 <blloyd_> That's how I knew there were 4GB available I node space already allocated but unused.
Oct 20 08:24:58 <abuibrahim> hello everyone
Oct 20 08:25:27 <abuibrahim> has anyone heard of cavium-bsp for yocto?
Oct 20 15:16:30 <_Lucretia_> hi, I don't want X on my build, just want OpenGLES
Oct 20 15:16:55 <_Lucretia_> so we can run a GL app directly
Oct 20 15:16:57 <_Lucretia_> what do I need to get this?
Oct 20 15:16:58 <_Lucretia_> thanks
Oct 20 20:16:48 <agherzan> Hello.
Oct 20 20:17:37 <agherzan> I saw that for ipk opkglibdir is removed if IMAGE_FEATURES has no package-management.
Oct 20 20:18:42 <agherzan> What i don't understand is why do we keep the the duplicate action here (rootfs_ipk_do_rootfs) and in remove_packaging_data_files?
Oct 20 20:19:55 <agherzan> RP__: I would like to skip running remove_packaging_data_files from core-image-minimal. As it would get removed anyway if there is no package-management in IMAGE_FEATURES.
Oct 20 20:20:16 <agherzan> And to be honest i would remove the whole function...
Oct 20 20:20:32 <agherzan> RP__: Is something i don't get here?
Oct 20 20:34:49 <agherzan> RP__: Aaaa... i realized now that what i say it's applicable only for ipk.
Oct 20 20:35:10 <agherzan> RP__: So i will add an extra check for IMAGE_FEATURES in ipk's remove_packaging_data_files.
Oct 20 20:52:14 <blloyd_> _Lucretion_: core-image-minimal is a non-X image.  You could copy that into your layer and rename to start a custom image for your device.  Of course, I don't see OpenGLES in my repository, so you may need to make a recipe for it.
Oct 20 20:52:37 <blloyd_> oops: _Lucretia_: ^
Oct 20 21:20:00 <_Lucretia_> yeah...
Oct 20 21:20:08 <_Lucretia_> there is meta-ti  but it doesn't build
Oct 20 21:20:47 <_Lucretia_> plus i've no idea if it'll work with the meta-gumstix
Oct 20 21:23:39 <blloyd_> dive in: it's not to painful to make a recipe for a library, assuming the library is made to be cross-compiled.  If not, expect pain.
Oct 20 21:24:04 <_Lucretia_> TI stiuff is pain
Oct 20 21:24:35 <_Lucretia_> i spose i could give it a bash :/
Oct 20 21:25:33 <blloyd_> good luck
Oct 20 21:25:36 <_Lucretia_> plus, I have no real clue how it's all supposed to fit as there are GLES libs for Qt and for some reason there is always X with GL and GLES and GL is not accelerated but GLES is, surely, I just need directfb + GLES/EGL libs
Oct 20 21:26:16 <_Lucretia_> or should i use X+GLES/EGL?
Oct 20 21:26:20 <_Lucretia_> dunno
Oct 20 21:27:26 <_Lucretia_> will have a look into it
Oct 20 21:27:32 <_Lucretia_> ta
Oct 20 21:27:34 <_Lucretia_> bbiab
Oct 20 21:27:39 <blloyd_> that's a call you will have to make yourself.  I have multiple images for multiple devices.  Some are X based, some use directfb, and some are headless.
Oct 20 21:27:52 <blloyd_> depends what you need.
**** ENDING LOGGING AT Sun Oct 21 02:59:58 2012

**** BEGIN LOGGING AT Sun Oct 21 02:59:59 2012
Oct 21 07:50:18 <eren> how is OpenEmbedded and Yocto compatible, and how do they differ?
Oct 21 09:10:24 <agherzan> eren: http://www.yoctoproject.org/projects/openembedded-core
**** ENDING LOGGING AT Mon Oct 22 03:00:00 2012

**** BEGIN LOGGING AT Mon Oct 22 03:00:00 2012
Oct 22 08:18:33 <mckoan> good morning
Oct 22 08:45:12 <bluelightning> morning mckoan, all
Oct 22 08:49:28 <mckoan> hi bluelightning
Oct 22 09:04:08 <leo_> when I 'bitbake fsl-image-minimal'. I met this error "../meta/recipes-devtool/gcc/gcc-cross-initial_4.6.bb failed with exit code '0' ". Would you plz give me any advices?
Oct 22 09:05:53 <bluelightning> leo_: could you use pastebin to post the full error? thanks
Oct 22 09:10:55 <leo_> on the terminal I can't get more error info.   My os is ubuntu 10.04.  I want to make the image about freescale P4080DS , I download the SDK v1.2 from freescale.com
Oct 22 09:12:39 <bluelightning> leo_: that's unusual, there should be a proper error message
Oct 22 09:13:25 <bluelightning> leo_: can you run: bitbake -e gcc-cross-initial | grep ^WORKDIR=
Oct 22 09:13:57 <bluelightning> leo_: then look at temp/log.<failed taskname> under that directory
Oct 22 09:15:32 <leo_> ok   wait a moment
Oct 22 09:20:04 <gotan> morning.
Oct 22 09:26:56 <leo_> "/HOME/LUCID/QORIQ-SDK-V1.2-20120624-YOCTO/BUILD-P4080DS-RELEASE/TMP/WORK/PPCE500MC-FSL-LINUX/GCC-CROSS-INITIAL_4.6.2+SVNR180516-R25+FSL.4/SSTATE-BUILD-POPULATE-LIC/GCC-CROSS/GENERIC-GPL-3: no such file or directory"
Oct 22 09:27:36 <leo_> "/HOME/LUCID/QORIQ-SDK-V1.2-20120624-YOCTO/BUILD-P4080DS-RELEASE/TMP/WORK/PPCE500MC-FSL-LINUX/GCC-CROSS-INITIAL_4.6.2+SVNR180516-R25+FSL.4/SSTATE-BUILD-POPULATE-LIC/GCC-CROSS/generic-GPL2-3.0-with-GCC-exception: no such file or directory"
Oct 22 09:28:03 <leo_> I found this . How to fix then ? thank you
Oct 22 09:35:30 <gotan> hi - I want to boot my yocto build over nfs but cannot find any docs on it. or at least not on how to do it without adding an NFS boot to the initrd scritps.
Oct 22 11:26:53 <BjornArnelid> Hi, I'm getting an "C compiler cant compile executables " error when i try to crosscompile in eclipse even though it seems to work in commandline, in the log i can find the following message "i586-poky-linux-gcc: error: unrecognized option '-V'" wich seems strange. Does anyone know what i might be doing wrong?
Oct 22 11:39:54 <_Lucretia_> BjornArnelid: usually that's a result of the compiler not being able to find libs or startup code
Oct 22 11:45:07 <_Lucretia_> dunno
Oct 22 11:45:54 <_Lucretia_> if the compiler doesn't handle -V either - have you tried to execute this yourself? <path to>/bin/gcc -V?
Oct 22 11:46:16 <_Lucretia_> er,  yeah, if it doesn't handle that, it's broken somewhere.
Oct 22 11:46:18 <_Lucretia_> what os?
Oct 22 11:47:31 <BjornArnelid> I am running Ubuntu 12.04 LTS
Oct 22 11:47:49 <BjornArnelid> And my local gcc will recognise that
Oct 22 11:48:44 <BjornArnelid> However this does not work "i586-poky-linux-gcc -V"
Oct 22 11:51:32 <_Lucretia_> what does it say?
Oct 22 11:52:13 <BjornArnelid> i586-poky-linux-gcc: error: unrecognized option '-V'
Oct 22 11:52:16 <BjornArnelid> i586-poky-linux-gcc: fatal error: no input files
Oct 22 11:52:42 <BjornArnelid> but -v (small v) works and gives version
Oct 22 11:52:59 <_Lucretia_> ah, try v
Oct 22 11:53:05 <_Lucretia_> yeah, that's right
Oct 22 11:53:19 <_Lucretia_> -V is not an option
Oct 22 11:57:34 <BjornArnelid> Hm ok so it seems that always happens
Oct 22 11:58:55 <_Lucretia_> yeah
Oct 22 12:00:05 <BjornArnelid> It still fails though.
Oct 22 12:02:53 <_Lucretia_> what else does the log say
Oct 22 12:03:26 <BjornArnelid> "cannot find crtbegin.o"
Oct 22 12:03:52 <_Lucretia_> thought so - see above
Oct 22 12:04:01 <_Lucretia_> http://gcc.gnu.org/onlinedocs/gcc-4.6.3/gcc/Option-Summary.html#Option-Summary <- no -V in there
Oct 22 12:05:32 <_Lucretia_> now I've been having this with a different build of gcc (not yocto) due to debian being multlib and gcc needing a patch as it cannot find the files inside /usr/lib/x86_64-linux-gnu as this is where all the libs and stratup code are placed now
Oct 22 12:05:42 <_Lucretia_> yet, yocto doesn't fail on this for me
Oct 22 12:06:03 <B4gder> well, gcc _does_ have a -V option mention in my man page
Oct 22 12:06:35 <B4gder> "The argument version specifies which version of GCC to run."
Oct 22 12:06:50 <BjornArnelid> the odd thing is that its working in autogen.sh but not in "reconfigure project"
Oct 22 12:07:09 <BjornArnelid> isnt the same toolchain used in both?
Oct 22 12:07:39 <_Lucretia_> B4gder: -v is for version
Oct 22 12:08:08 <B4gder> yes to _show_ version
Oct 22 12:08:11 <B4gder> -V is to ask for version
Oct 22 12:08:54 <B4gder> listed under "Target Options"
Oct 22 12:11:01 <BjornArnelid> Seems like i am getting that error when building from commandline as well though and it works there.
Oct 22 12:12:10 <_Lucretia_> ahh, for cross compiler's only
Oct 22 12:12:11 <BjornArnelid> looking in config it seems like yocto is trying both commands and uses the one that works
Oct 22 12:44:21 <BjornArnelid> I mysteriously got it working. dont know how though.
Oct 22 15:21:12 <BjornArnelid> Im getting errors again now when using "autogen.sh" as well, it says "rm: invalid option -- 'l'"
Oct 22 15:25:25 <paulg> dvhart, made it home ok?
Oct 22 15:28:56 <dvhart> paulg, hey. Tired, but in one piece.
Oct 22 15:29:04 <dvhart> paulg, you?
Oct 22 15:29:25 <paulg> same thing!
Oct 22 15:29:26 <zeddii> paulg is online from the county jai's free WIFI.
Oct 22 15:29:32 <dvhart> :-)
Oct 22 15:29:35 <zeddii> s/jai/jail/
Oct 22 15:29:49 <dvhart> zeddii, I'm looking to push tiny support for fri2 today - just a heads up.
Oct 22 15:30:03 <dvhart> zeddii, this will be for meta-intel 1.3 release
Oct 22 15:30:55 <zeddii> np. I'm sitting on some kernel updates for when the coast is clear, so I can make any changes you need ahead of that stuff.
Oct 22 15:31:42 * dvhart nods - I'll get on it then so I don't hold you up. The biggest hurdle here is the physical hardware reboot/test cycle
Oct 22 15:32:08 <paulg> you should buy a rack of kit for that.  :)
Oct 22 15:32:17 <dvhart> ;-)
Oct 22 15:32:33 <dvhart> should be about mid-atlantic right about now I guess
Oct 22 15:35:57 <mranostay> country jail's have free wifi now? who knew?
Oct 22 15:36:32 <paulg> yeah, but the "click to accept" conditions are not so great.
Oct 22 15:36:57 <zeddii> paulg. "no escape pages". "no bomb making" .. that sort of thing ?
Oct 22 15:37:14 <paulg> that, and things I won't type here.
Oct 22 15:43:38 <RP__> halstead: ping?
Oct 22 15:45:32 <BjornArnelid> Is there any way to repair autogen.sh?
Oct 22 15:46:38 <BjornArnelid> Or repair an eclipse yocto installation?
Oct 22 15:59:22 <dvhart> zeddii, I just did a git pull in linux-yocto-3.4/meta:
Oct 22 15:59:24 <dvhart> Receiving objects: 100% (2447974/2447974), 508.11 MiB | 3.34 MiB/s, done.
Oct 22 15:59:36 <dvhart> any ideas what might have happened there?
Oct 22 16:00:06 <kergoth> looks like success, to me ;)
Oct 22 16:00:32 <dvhart> heh
Oct 22 16:01:21 <zeddii> dvhart. I don't see anything strange here. I was worried the branch was no longer orphaned .. but it looks fine from a quick check here.
Oct 22 16:01:39 <dvhart> yeah that was my first thought too, but not the case
Oct 22 16:01:51 <dvhart> but 500 MB ?!?
Oct 22 16:01:54 * davest wonders if there is a phone number for the AB meeting that he missed...
Oct 22 16:02:11 <dvhart> $ du -hs meta/
Oct 22 16:02:12 <dvhart> 27M	meta/
Oct 22 16:02:17 <dvhart> I mean.... come on!
Oct 22 16:02:47 * davest nm
Oct 22 16:03:21 <zeddii> dvhart, it's a problem with needing to keep it fast forward. just apply and revert -rt a few times.
Oct 22 16:04:01 <zeddii> if we move to not keeping a copy of the patches in there .. then the size goes way down. I can put that back into play in 1.4.
Oct 22 16:04:07 <dvhart> hrm.... got to be more to it than that
Oct 22 16:04:43 <dvhart> OK, well it didn't fail or anything, so not critical, but the 500 MB incremental pull really surprised me
Oct 22 16:05:30 <davest> The Advisory Meeting is on 888-875-9370 / 916-356-2663, Bridge: 2, Passcode: 4514030
Oct 22 16:05:44 <msm> im assuming backporting the fixes for this: https://gist.github.com/3921973 to denzil will be too invasive? or is it easier than I think?
Oct 22 16:08:23 * zeddii takes SIGFOOD
Oct 22 16:19:54 <_darknighte_> davest: did you send the slides?
Oct 22 16:20:33 <Crofton|work> I do not think so
Oct 22 16:25:04 <otavio> I am not getting how to use the proposed patchset for the sdk (with multilib) ...
Oct 22 16:27:02 <otavio> Can someone help me ?
Oct 22 18:19:47 <dvhart> zeddii, this is weird. I'm seeing a source for linux-yocto-tiny that did not checkout the meta branch specified in the directory:
Oct 22 18:19:50 <dvhart> dvhart@rage:/build/poky/tiny/fri2/tmp/work/fri2_noemgd-poky-linux/linux-yocto-tiny-3.4.11+git1+24bb64dace79aa82a624555d4d51a39bcdbe8c45_1+449f7f520350700858f21a5554b81cc8ad23267d-r4.0/linux/meta/cfg/kernel-cache/bsp/fri2 [standard/tiny/base]
Oct 22 18:19:50 <dvhart> $ git branch --contains 24bb64dace79aa82a624555d4d51a39bcdbe8c45
Oct 22 18:20:24 <dvhart> note that the meta SRC_REV is 24bb64dace79aa82a624555d4d51a39bcdbe8c45 which has the bits I need, but the checked out sources do not have that commit, and the files are clearly missing from the checkout.
Oct 22 18:20:46 <zeddii> that's a commit local to your tree ?
Oct 22 18:20:46 <dvhart> zeddii, I used the linux-yocto-tiny_3.4 bbappend in meta-kernel-dev... ever seen something similar?
Oct 22 18:21:05 <dvhart> zeddii, it's in my local bare clone called publish, which the SRC_URI is pointing to
Oct 22 18:21:15 <zeddii> only when the fetcher isn't pulling my changes into the git2/downloads.
Oct 22 18:21:20 <dvhart> the checkout has the commit in the repo, but not in the checked out branch
Oct 22 18:21:44 <zeddii> and bitbake -e shows what as your SRCREV_meta ?
Oct 22 18:21:47 <dvhart> sorry, the bitbake workdir clone has the commit in the repo, but not in the checked out branch
Oct 22 18:21:48 <dvhart> yes
Oct 22 18:22:12 <dvhart> well... no, it shows AUTOINC
Oct 22 18:22:20 <dvhart> $ bitbake linux-yocto-tiny -e | grep SRCREV_meta=
Oct 22 18:22:20 <dvhart> # SRCREV_meta=${AUTOREV}
Oct 22 18:22:20 <dvhart> SRCREV_meta="AUTOINC"
Oct 22 18:22:35 <dvhart> but it's clearly using it as it's used in the workdir dirname
Oct 22 18:22:39 <zeddii> that's fine. and you don't see that blob anywhere in ${S} ?
Oct 22 18:23:00 <dvhart> it's in the repo, git show ... works, but git branch --contains returns nothing
Oct 22 18:23:12 <dvhart> and the meta dir clearly does not have the new fri2-tiny.scc and associated changes
Oct 22 18:23:40 <zeddii> git branch  shows what ? do you see a reset meta branch in ${S} ?
Oct 22 18:24:21 <dvhart> git branch shows all the bsp, feature, and the meta branches
Oct 22 18:24:35 <dvhart> with the correct machine branch, standard/tiny/base, as checked out
Oct 22 18:24:55 <dvhart> git log on the other hand is strange, HEAD is at:
Oct 22 18:24:57 <dvhart>     Merge commit 'v3.4.6' into standard/base
Oct 22 18:25:25 <zeddii> hmm. it's not the kernel scripts then, they won't touch the branch if you are running AUTOREV.
Oct 22 18:25:37 <zeddii> that's on your standard/tiny/base ? hmm.
Oct 22 18:28:01 <dvhart> yeah
Oct 22 18:28:03 <dvhart> something is fubar
Oct 22 18:28:14 <dvhart> I'm setting the SRCREV's explicitly to see what happens
Oct 22 18:31:34 <dvhart> this makes no sense... the publish has the branches and the commits, setting them explicitly results in validate_branches complaining that it can't find the machine commit in any branch
Oct 22 18:31:49 <kergoth> so.. who broke imx6qsabrelite? it sucks in imx-base.inc, which in turn pulls in imx-lib, but that only builds for mx5 machines, not mx6
Oct 22 18:32:11 <dvhart> I can't even spell imx6qsabrelite?
Oct 22 18:32:37 <zeddii> dvhart: that's what I expected, given what you were describing. something in sstate is probably being fed to you that is preventing the update. if I had to guess.
Oct 22 18:32:56 <dvhart> I've just done a cleanall and that warning went away
Oct 22 18:33:14 <dvhart> but this is sure to be a problem:
Oct 22 18:33:16 <dvhart> WARNING: Can't find any BSP hardware or required configuration fragments.
Oct 22 18:33:16 <dvhart> WARNING: Looked at meta/cfg/tiny/fri2/hdw_frags.txt and meta/cfg/tiny/fri2/required_frags.txt in directory: meta/cfg/tiny/fri2
Oct 22 18:34:18 <zeddii> yup. I'd have to see your layer to know more, but it normally means it autogenerated you a BSP description.
Oct 22 18:35:12 <dvhart> after the cleanall the fri2-tiny.scc is there
Oct 22 18:35:40 <dvhart> but the .config makes it clear it isn't being used
Oct 22 18:38:50 <hollisb> what does it mean when bitbake says "NOTE: ['foo/a.bbappend', 'bar/a.bbappend'] to ['foo/a.bbappend']" right at the beginning?
Oct 22 18:38:54 <hollisb> I have two .bbappend files, in different layers, for the same recipe... is one of them losing to the other?
Oct 22 18:41:28 <blloyd_> you can have more than one bbappend file for a recipe.
Oct 22 18:42:36 <hollisb> ok, great. I'll have to dig deeper to find out why it's not looking in the second layer's "files" directory for this recipe then
Oct 22 18:42:45 <hollisb> but what is that NOTE message about?
Oct 22 18:43:55 <blloyd_> FILES = can cause trouble.  FILES_append := would be a better construct.
Oct 22 18:47:44 <khem> why FILES_append ?
Oct 22 18:47:57 <khem> avoid append if you can always
Oct 22 18:48:05 <khem> try += or =+
Oct 22 18:48:23 <khem> and you can also use some intermdiate vars with overrides
Oct 22 18:48:49 <khem> eg VAR_<overide> = "a b c" VAR ?= "" FILES += "${VAR}"
Oct 22 18:52:16 <hollisb> are you talking to me? the problematic .bbappends file just does SRC_URI += "file://hz.cfg"
Oct 22 18:52:26 <msm> zenlinux: hi
Oct 22 18:53:13 <msm> zenlinux: i have two more commits on my denzil branch
Oct 22 18:53:14 <hollisb> oops, I think it was a typo in the directory name
Oct 22 18:55:05 <hollisb> hmm no
Oct 22 18:56:17 <hollisb> hmm, do I have to manually do this in my .bbappend? FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}"
Oct 22 19:20:23 <kergoth> if you plan to use file:// files that live next to the bbappend, yes
Oct 22 19:30:41 <hollisb> hmm, ok
Oct 22 19:31:26 <hollisb> OE usually does so much automatic stuff like that for me, it's a surprise to have to do it by hand
Oct 22 20:47:33 <khem> hollisb: yes I was responding to "FILES = can cause trouble.  FILES_append := would be a better construct."
Oct 22 20:48:08 <hollisb> khem: I think you guys were two steps ahead of me. :) I didn't even know I had a problem with FILE paths yet...
Oct 22 20:54:24 <zenlinux> msm, thanks, I'll take a look
Oct 22 23:36:33 <wmat> Jefro: ping
Oct 23 00:57:23 <wmat> Jefro: disregard ping ;)
Oct 23 02:42:11 <victsou_> Adding python to the packages I want to install gets me an error at the end of the baking process (do_rootfs of last task): "Unable to resolve package python". As it shows a different message from those from packages with wrong names, It leads me to believe that python is indeed a package, but there's something wrong with it. Any suggestions?
**** ENDING LOGGING AT Tue Oct 23 03:00:00 2012

**** BEGIN LOGGING AT Tue Oct 23 03:00:01 2012
Oct 23 03:10:21 <victsou_> brb
Oct 23 06:19:03 <BjornArnelid> Hi, im getting the following error when i try to start an image i built in qemu "Cannot register service: RPC: Unable to receive; errno = Connection refused" What does that mean?
Oct 23 06:24:09 <BjornArnelid> Im guessing it has to do with TCF since im not able to setup debugging on that image.
Oct 23 08:30:02 <bluelightning> morning all
Oct 23 09:26:53 <mckoan> good morning
Oct 23 11:56:15 <victsou_> Still facing yesterday's problem: Adding python to the packages I want to install gets me an error at the end of the baking process (do_rootfs of last task): "Unable to resolve package python". As it shows a different message from those from packages with wrong names, It leads me to believe that python is indeed a package, but there's something wrong with it. Any suggestions?
Oct 23 15:00:07 <RP__> Song_Liu: YPTM: RP is on the call
Oct 23 15:00:20 <bluelightning> YPTM: Paul Eggleton is on the call
Oct 23 15:00:31 <jmpdelos> YPTM: Jeff Polk is on the call
Oct 23 15:00:40 <jzhang> YPTM: jzhang's here
Oct 23 15:00:49 <halstead> Yptm: Michael Halstead present.
Oct 23 15:00:50 <tomz1> YPTM: Tom Z is on hte call
Oct 23 15:01:02 <_darknighte_> YPTM: Sean Hudson is on the call
Oct 23 15:01:07 <strassek> YPTM: Kevin Strasser is here
Oct 23 15:01:35 <nitink> YPTM: Nitin on the bridge
Oct 23 15:01:41 <scottrif> YPTM: Scott Rifenbark joined the call
Oct 23 15:01:49 <fp> YPTM: Amit is here
Oct 23 15:01:58 <mihai1> YPTM: Mihai Lindner is on the call
Oct 23 15:02:22 <_darknighte_> Song_Liu: YPTM: very quiet on the call
Oct 23 15:02:23 <kergoth> YPTM: Chris Larson present
Oct 23 15:02:48 <zeddii> YPTM: Bruce A here.
Oct 23 15:03:09 <Song_Liu> YPTM: Hi everyone, welcome to the Yocto Project technical team meeting, please let me know who's on the bridge.
Oct 23 15:03:15 <davest> YPTM: davest here
Oct 23 15:03:37 <sgw> YTPM: Saul is here but heading to Jury service!
Oct 23 15:03:50 <denix> YPTM: Denys will be few minutes late to the call...
Oct 23 15:05:11 <_darknighte_> Song_Liu: YPTM: No opens from me.
Oct 23 15:05:24 <Song_Liu> YPTM: Any opens from the audience?
Oct 23 15:05:26 <scottrif> OPEN: 3.1 Release Notes
Oct 23 15:05:29 <_darknighte_> sgw: have a fun day!
Oct 23 15:05:30 <davest> YPTM: no opens (I think)
Oct 23 15:05:49 <_darknighte_> davest: is that your "last" comment?  ;)
Oct 23 15:06:03 <RP__> scottrif: planning ahead? :)
Oct 23 15:06:24 <scottrif> RP:  :)  Need them
Oct 23 15:07:06 <scottrif> oops... 1.3 :)
Oct 23 15:07:29 <scottrif> where did 3.1 come from?  Been a long week
Oct 23 15:07:42 <zeddii> _darknighte_, on the spot!
Oct 23 15:08:13 <rburton> YPTM: ross on the call
Oct 23 15:10:32 <Song_Liu> YPTM: https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.3_Status#Milestone_5_.281.3_release.29
Oct 23 15:13:23 <Song_Liu> YPTM: https://wiki.yoctoproject.org/wiki/Yocto_1.3_Milestone_Test_Report#Yocto_1.3_M5_Build_Test_Report
Oct 23 15:18:16 * _darknighte_ cheers for the team
Oct 23 15:18:22 <mihai1> yay! :)
Oct 23 15:18:35 <mihai1> we would like to thank the Acadamy...
Oct 23 15:18:44 * _darknighte_ queues the music
Oct 23 15:20:36 <_darknighte_> scottrif: Release Notes?
Oct 23 15:20:51 * mckoan is amazed to see the huge infrastructure behind the project
Oct 23 15:21:56 <_darknighte_> scottrif: Song_Liu: cool, got that open done with already
Oct 23 15:22:54 <_darknighte_> pidge: do you maintain historical information on build times?
Oct 23 15:24:51 <pidge> I have the ability to. I don't currently
Oct 23 15:25:05 <pidge> it's 15 minutes to set it up
Oct 23 15:33:14 <scottrif> last minute stuff for "docs" is website update
Oct 23 15:35:04 <Jefro> Congrats everyone!
Oct 23 15:35:11 <_darknighte_> woot!
Oct 23 15:35:21 <Jefro> scottrif I'll help with the website
Oct 23 15:35:35 <RP__> _darknighte_: There are build times in previous test reports FWIW
Oct 23 15:35:38 <scottrif> Jefro: it is very simple and I can do it in about 10 minutes
Oct 23 15:35:48 <mihai1> congrats all!
Oct 23 15:36:02 <Jefro> scottrif sounds good - I'll want to mirror whatever you do on the new site as well
Oct 23 15:36:13 <scottrif> Jefro: although we will need a new download link for the actual tarball
Oct 23 15:38:01 <pidge> scootrif: http://downloads.yoctoproject.org/releases/yocto/yocto-1.3/poky-danny-8.0.tar.bz2 I need to fix the actual link.
Oct 23 15:38:42 <scottrif> pidge: good on the link.  What I was referring to to jefro was the actual new page in drupal for the website
Oct 23 15:38:58 <_darknighte_> Song_Liu: you had me share already!  ;)
Oct 23 15:39:07 <Jefro> scottrif can do this afternoon
Oct 23 15:39:17 <scottrif> Jefro: cool
Oct 23 15:39:23 <pidge> scottrif: got it
Oct 23 15:45:51 <victsou_> bump: Adding python to the packages I want to install gets me an error at the end of the baking process (do_rootfs of last task): "Unable to resolve package python". As it shows a different message from those from packages with wrong names, It leads me to believe that python is indeed a package, but there's something wrong with it. Any suggestions?
Oct 23 15:47:21 <RP__> btw, is anyone seeing issues accessing the autobuilder? connections hanging or dropping?
Oct 23 15:47:52 <_darknighte_> halstead: woot to http access
Oct 23 15:48:19 <_darknighte_> halstead: thx to your wife for her help.
Oct 23 15:51:09 <halstead> _darknighte_, I'll pass that on. :)
Oct 23 15:51:24 <scottrif> pidge: that is in the dev manual Beth
Oct 23 15:52:04 <pidge> scottrif: thanks. did I say qs?
Oct 23 15:52:13 <scottrif> pidge: :)  yes
Oct 23 15:53:10 * pidge needs coffee obviously
Oct 23 15:59:07 <Song_Liu> YPTM: thank you all for joining the meeting. Have a nice day or evening!
Oct 23 15:59:26 <bsmucker> I'm a yocto newbie and have searched the docs for what probably is a very simple thing, but I can't seem to find a simple answer.  I've created a new layer with yocto-bsp, bitbake, and everything works great. Now I need to patch the kernel so I cloned the kernel git repo (yocto version). Question:  How do I switch my layer to use the local git repo rather than the remote one?
Oct 23 16:02:01 <mihai1> bsmucker: you can look at http://www.yoctoproject.org/docs/1.3/dev-manual/dev-manual.html#patching-the-kernel
Oct 23 16:21:17 <yocto945> Hello Yocto
Oct 23 16:21:47 <yocto945> I am looking for some information on Qt5 recipe
Oct 23 16:22:37 <yocto945> any one who can provide me with some info on if its available?
Oct 23 16:22:41 <yocto945> and where?
Oct 23 16:23:13 <bluelightning> otavio: ^
Oct 23 16:24:30 <yocto945> bluelightning: Do you mean otavio is the one developing it?
Oct 23 16:24:49 <bluelightning> yocto945: I understand he has been looking into it recently yes
Oct 23 16:25:28 <bluelightning> I'm the one who has been maintaining the qt4 recipes (with a fair bit of help from others)... I haven't had time to look at qt5 yet though
Oct 23 16:25:44 <yocto945> bluelightning: thanks for the information, do you have any information on where i can find it?
Oct 23 16:26:02 <JaMa> yocto945: are you from hp? :)
Oct 23 16:26:02 <yocto945> otavio: can you please point me to it?
Oct 23 16:26:12 <bluelightning> yocto945: I don't think otavio has published anything yet
Oct 23 16:26:23 <yocto945> JaMa: Yes :)
Oct 23 16:26:40 <JaMa> good
Oct 23 16:26:44 <bluelightning> yocto945: there is a very preliminary set of recipes here: https://github.com/martiert/meta-qt5
Oct 23 16:26:54 <bluelightning> yocto945: but that was from before otavio started looking at this
Oct 23 16:27:44 <yocto945> JaMa: You've been contributing quite a bit, thanks :)
Oct 23 16:28:39 <yocto945> bluelightning: Thanks, but i think it is only building tools like moc, qmake etc
Oct 23 16:29:02 <yocto945> I am trying to bring-up Qt5 recipe
Oct 23 16:29:09 <bluelightning> I've not looked very closely
Oct 23 16:29:40 <yocto945> but i fail to get thru opengl dependency
Oct 23 16:30:13 <yocto945> bluelightning: any idea on how to implement mesa on openembedded platform?
Oct 23 16:30:45 <bluelightning> yocto945: we have mesa recipes that have been looked at recently; rburton is our local expert on that
Oct 23 16:31:15 <rburton> yocto945: what embedded board?
Oct 23 16:31:16 <daniels> the short story is 'it works'
Oct 23 16:31:31 * rburton can't read
Oct 23 16:31:34 <rburton> yocto945: what target?
Oct 23 16:31:40 <yocto945> qemux86
Oct 23 16:31:50 <yocto945> emulator
Oct 23 16:32:23 <rburton> we removed gl-through-qemu because it was broken
Oct 23 16:32:40 <rburton> so you'll get software GL - i've heard that its actually broken on qemux86 though.
Oct 23 16:33:59 <bsmucker> hello again
Oct 23 16:34:03 <yocto945> rburton: All i am looking for is a way to get QEMUX86 emulator compile and link qt5 which need opengl libraries
Oct 23 16:34:20 <yocto945> i understood that mesa is one alternative
Oct 23 16:35:09 <yocto945> rburton: so, please brief me on what i can do to achieve my requirement
Oct 23 16:35:16 <rburton> yocto945: for building, just depend on virtual/libgl
Oct 23 16:35:19 <rburton> and you'll get mesa built
Oct 23 16:35:26 <rburton> (see qt4, which does this)
Oct 23 16:35:52 <bsmucker> So trying to answer my own prior question as to how to switch to using a local git kernel repo
Oct 23 16:36:22 <bsmucker> I changed the SRC_URI from #SRC_URI = "git://git.yoctoproject.org/linux-yocto-3.0;protocol=git;bareclone=1;branch=${KBRANCH},meta;name=machine,meta"
Oct 23 16:36:42 <bsmucker> to  SRC_URI = "file:///home/bsmucker/work/scratch/linux-yocto-3.0/;protocol=git;bareclone=1;branch=${KBRANCH},meta;name=machine,meta"
Oct 23 16:36:44 <yocto945> rburton: can you please give me the pointer to qt4, you are referring to?
Oct 23 16:37:46 <JaMa> yocto945: http://git.openembedded.org/openembedded-core/tree/meta/recipes-qt/qt4
Oct 23 16:38:07 <bsmucker> and I get an error. Can someone help me with my problem:  Error is
Oct 23 16:38:09 <bluelightning> bsmucker: you may wish to use externalsrc.bbclass; that's intended to help with that exact situation
Oct 23 16:38:10 <bsmucker> ERROR: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher failure: SRCREV was used yet no valid SCM was found in SRC_URI
Oct 23 16:39:04 <bluelightning> bsmucker: for some documentation, see the "Building Software from an External Source" section of the development manual
Oct 23 16:39:05 <bsmucker> bluelightning: Can you point me to some docs about how to do that?
Oct 23 16:39:13 <rburton> thanks JaMa
Oct 23 16:39:41 <bsmucker> thanks bluelightning.  Will check it out.
Oct 23 16:41:06 <yocto945> JaMa: how do i clone it?
Oct 23 16:43:30 <JaMa> yocto945: what do you mean?
Oct 23 16:43:50 <JaMa> you have oe-core already in build-webos.. just old version with 4.8.1 only
Oct 23 17:20:20 <otavio> yocto960: I am starting packaging the separated sources
Oct 23 17:20:41 <otavio> yocto960: I opted to start from scratch
Oct 23 17:22:46 <yocto960> otavio: when do u expect to merge Qt5 recipe to oe-core?
Oct 23 17:24:04 <kergoth> RP: ping
Oct 23 17:26:22 <otavio> yocto960: is the goal
Oct 23 17:26:30 <otavio> yocto960: but it is not near it yet
Oct 23 17:27:18 <yocto960> otavio: what is the goal?
Oct 23 17:27:39 <otavio> yocto960: merge it
Oct 23 17:28:30 <yocto960> otavio: ok, so you cant comment on any expected dates?
Oct 23 17:29:39 <yocto960> for me Qt5 is a dependency to build webkit2, so i am not really looking to wait till it is merged, any Qt5 recipe "that builds" would do for me
Oct 23 17:29:59 <otavio> yocto960: I see
Oct 23 17:30:35 <otavio> yocto960: it is not yet build. My goal is to have qtbase package separated and base on that for other modules
Oct 23 17:31:10 <JaMa> bluelightning: is this worth enhancement bug report: with SSTATE_MIRROR fully populated, bitbake hangs on "NOTE: Preparing runqueue" for really long time without showing any output - downloading lots of sstate packages on background
Oct 23 17:31:54 <kergoth> interesting. ideally we'd have some sort of progress indicator like the parsing, probably..
Oct 23 17:32:41 <bluelightning> JaMa: yes, I think it should show something to let you know what's happening in that case
Oct 23 17:34:28 <yocto960_> otavio: i am trying to build all the componenets of Qt5 as a general Qt5 build does
Oct 23 17:34:38 <yocto960_> and i am able to build qtbase
Oct 23 17:34:40 <pidge> halstead: ping
Oct 23 17:34:48 <pidge> ab02 is having dns issues
Oct 23 17:35:09 <yocto960_> otavio: but when i try to build qtdeclarative, the build fails due to opengl dependency
Oct 23 17:35:39 <yocto960_> otavio: did u face that problem?
Oct 23 17:36:12 <otavio> yocto960_: I did not got on it yet
Oct 23 17:38:10 <JaMa> kergoth: maybe progress bar is not enough, as some packages are very quick, but e.g. 2GB webkit should be probably shown alone
Oct 23 17:38:26 <JaMa> kergoth: but on otherside another Download queue is probably too much
Oct 23 17:38:51 <JaMa> maybe something like knotty2 does with showing current task to show current package being downloaded
Oct 23 17:39:16 <yocto960_> otavio: ok, thanks for the update any ways
Oct 23 17:43:26 <JaMa> bluelightning: kergoth: https://bugzilla.yoctoproject.org/show_bug.cgi?id=3328
Oct 23 17:46:08 <bluelightning> JaMa: thanks
Oct 23 18:23:52 <yocto960_> rburton: so using virtual/libgl as a dependency will enable mesa, or provide all the gl libraries for Qt5 to compile, or both?
Oct 23 18:24:20 <rabryn> hello all, is there a way to include the kernel source in a toolchain sdk?
Oct 23 18:25:01 <rabryn> i'm trying to build a kernel module outside of yocto using my toolchain sdk...
Oct 23 18:25:14 <JaMa> query yocto960_:
Oct 23 18:30:49 <halstead> pidge, It was permissions errors on resolv.conf. Fixed.
Oct 23 18:31:42 <halstead> pidge, My mistake coping files with a bad UMASK set. I'll check the others to make sure they're okay.
Oct 23 18:37:52 <pidge> halstead: did you change the yocto-slave/buildbot.tac file?
Oct 23 18:38:03 <pidge> halstead: because someone did and they did it wrong
Oct 23 18:38:15 <halstead> pidge, No.
Oct 23 18:38:35 <pidge> halstead: interesting and worrisome
Oct 23 18:38:50 <halstead> pidge, I'm working on the website right now. Except for the fix to resolv.conf no server changes from me.
Oct 23 18:39:04 <pidge> halstead: I just had to change back what the buildhost name was
Oct 23 18:39:07 <halstead> pidge, Which machine did the file change on?
Oct 23 18:39:25 <pidge> ab02
Oct 23 18:39:36 <pidge> someone changed slavename = 'ab02.i.yoctoproject.org' to slavename = 'ab01.i.yoctoproject.org'
Oct 23 18:40:33 <pidge> halstead: not a big issue. could have been changed a long time ago
Oct 23 18:41:19 <halstead> pidge, I'll add auditing to those configuration files. So we'll know who & when next time.
Oct 23 18:41:46 <pidge> halstead: ty. I get worried when people touch those.
Oct 23 18:43:03 <halstead> pidge, And rightly so. I last mucked with the one an ab10 when I was looking at issues there a while back. In case you want to double check it. (I was careful though.)
Oct 23 19:36:48 <rburton> yocto960_: virtual/libgl will be provided by mesa, which will obviously give you GL libraries
Oct 23 20:19:31 <RP> kergoth: pong
Oct 23 20:26:29 <kergoth> RP: command.py's runCommand can sometimes return a string error message, yet none of our UIs handle it, which can result in an attempt to index a string with a non-numberic index, resulting in a TypeError. these cases are few and far between, but can happen. we need a better way to handle this. either the uis need to isinstance(), which is ugly, or runcommand needs to return a result and an error, or we need to pass an exception
Oct 23 20:26:30 <kergoth>  across to the ui and raise it from the ui side runcommand
Oct 23 20:26:35 <kergoth> thoughts?
Oct 23 20:26:44 <kergoth> s/numberic/numeric/
Oct 23 20:27:21 <kergoth> i have a first pass of the latter, but the traceback will be wrong right now, as it only passes the exception, not the trb
Oct 23 20:27:24 <kergoth> s/trb/tb/
Oct 23 20:28:13 <RP> kergoth: hmm, there was an open bug about this too :/
Oct 23 20:28:23 <RP> kergoth: I thought it got fixed for hob at least
Oct 23 20:28:47 <kergoth> could be, we're hitting it intermittently in our automated builds with knotty
Oct 23 20:29:06 <RP> kergoth: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=8202e49c5fa03822adf3a4d75bc87d33b23a7f65 - horrible :(
Oct 23 20:29:09 <kergoth> no idea what the underlying cause is, but the real problem is being masked by the type error right now
Oct 23 20:29:14 * RP wonders why he let that pass
Oct 23 20:29:37 <kergoth> heh, i can look into the cleaner exception passing for runcommand further, if you think that's a decent route
Oct 23 20:29:54 <kergoth> none of the solutions are very clean..
Oct 23 20:29:57 <RP> kergoth: do you think we can make the exception handling work better?
Oct 23 20:30:17 <RP> kergoth: my big worry is that even if we get the exception, the options we have are limited in the UI
Oct 23 20:30:26 <RP> kergoth: other than print it and exit
Oct 23 20:30:38 <kergoth> that'd be better than what we have now :) but i agree
Oct 23 20:30:50 <kergoth> i think the least ugly answer would be, runCommand in the cooker can raise an exception, and the server can catch it and pass it along to the ui, and the server connector can re-raise it
Oct 23 20:31:00 <kergoth> but i'm not 100% happy with that either
Oct 23 20:31:41 <RP> kergoth: so what would returning a status + error do by comparison ?
Oct 23 20:31:57 <RP> kergoth: I think that might make UI people at least think about what to do with the error
Oct 23 20:32:08 <RP> as they get a value they have to do something with
Oct 23 20:32:14 <kergoth> i'm thinking implicit tuple unpacking, aka python's version of multiple returns
Oct 23 20:32:22 <kergoth> result, error = runCommand(); if error ..
Oct 23 20:32:26 * kergoth shrugs
Oct 23 20:32:43 <kergoth> i don't really have a strong opinion on either solution, so if you prefer one or the other, i'm willing to dive in
Oct 23 20:32:43 <RP> kergoth: right, on reflection that might be the least nastiest solution for this right now
Oct 23 20:33:05 <RP> kergoth: I'm leaning that way as it makes people think about this in a place they really do need to think about it
Oct 23 20:33:25 <kergoth> either way the uis will all need to be modified where they run runCommand, just its easy with exceptions to not think about what a given function might raise
Oct 23 20:33:25 <RP> not exactly pythonic but with the exception complications, it is probably good enough
Oct 23 20:33:48 <kergoth> i like golang's error handling in some ways, lacking exceptions, just multiple returns
Oct 23 20:33:54 <kergoth> even if it does have its annoyances
Oct 23 20:33:58 <RP> kergoth: I'm assuming we'd just pass a string about the exception in the "unknown" case
Oct 23 20:34:39 <RP> kergoth: so I'm leaning towards the tuple result, error although I'm open to persuasion. I don't think there is one good solution
Oct 23 20:36:15 <kergoth> there's also a rare case where it can return None due to a timeout communicating with the server, should probably make the uis handle that case a bit better in the long term. check the server, if not dead, keep trying, or similar
Oct 23 20:36:40 <kergoth> okay, i'll prototype the multiple return approach
Oct 23 21:08:06 <msm> is all the 1.4 planning done?
Oct 23 21:40:59 <bluelightning> msm: I think there's still time for additions/adjustments
Oct 23 21:41:47 <msm> bluelightning: ah, dont really have major suggestions but...
Oct 23 21:41:58 <msm> i was wondering if kernel version, gcc, eglibc, binutils versions have been decided
Oct 23 21:42:08 <msm> i see a binutils 2.23 enhancement so far
Oct 23 21:44:14 <msm> are these pages autogenerated? https://wiki.yoctoproject.org/wiki/Yocto_1.4_Features
Oct 23 21:44:30 <msm> seems to be...
Oct 23 21:57:33 * mranostay yawns
Oct 23 21:58:15 <JaMa> does someone have simple script to search sysroot if there are any files not tracked by sstate manifest? e.g. if someone touched sysroot from do_install directly?
Oct 23 21:59:34 <mranostay> heh
Oct 23 22:00:39 <mranostay> doesn't insane.bbclass check that?
Oct 23 22:01:49 <JaMa> mranostay: no it does not afaik
Oct 23 22:02:48 <JaMa> mranostay: it can be more hidden then in metadata directly.. e.g. wrong prefix passed to qmake etc..
Oct 23 22:11:27 <JaMa> hmm quite a lot of differences
Oct 24 01:45:49 <chackal_sjc> guys
Oct 24 01:46:07 <chackal_sjc> im trying to do someting like: WILLOW_VERSION="${@datetime.datetime.now().strftime('%Y%m%d%H%M')}"
Oct 24 01:46:10 <chackal_sjc> but wont work
Oct 24 01:46:28 <chackal_sjc> does anyone knows how to do what I want? assign a date to a variable in a recipe
Oct 24 01:47:18 <kergoth> the problem is, most likely, that it won't automagically import the datetime module.
Oct 24 01:47:28 <kergoth> define a function with def and call that from ${@} instead
Oct 24 01:47:40 <kergoth> and import datetime in the function
Oct 24 01:48:49 <chackal_sjc> define inside the recipe?
Oct 24 01:48:58 <kergoth> wherever makes sense
Oct 24 01:49:07 <chackal_sjc> like a python functoin?
Oct 24 01:49:14 <kergoth> well, not a perl one
Oct 24 01:49:16 <kergoth> obviously, yes
Oct 24 01:49:24 <kergoth> def willow_version(d):
Oct 24 01:49:26 <kergoth> import datetime
Oct 24 01:49:29 <kergoth> return datetime.blahblah()
Oct 24 01:49:37 <kergoth> WILLOW_VERSION = "${@willow_version(d)}"
Oct 24 01:49:42 <kergoth> what have you
Oct 24 01:49:47 <kergoth> there are lots of examples of this in the metadata
Oct 24 01:50:02 <kergoth> whenever you need to do more than will fit in a single line of python, this is what is done
Oct 24 01:50:16 <chackal_sjc> i didnt know that a recipe supports a python definition
Oct 24 01:50:35 <kergoth> cd poky; git grep '^def.*:$'
Oct 24 01:56:13 <chackal_sjc> kergoth: does it work in a .conf file? like a distro.conf?
Oct 24 01:56:50 <kergoth> nope. but you can include a .inc from a .conf and do it there
Oct 24 01:57:07 <chackal_sjc> nice
Oct 24 01:57:07 <kergoth> .conf is a slightly simpler version of the .inc/.bb/.bbclass format. no functions, no tasks, etc
Oct 24 01:58:11 <chackal_sjc> kergoth: i have a bunch of recipes that if I dont declare a global variable with a version, will use a ${AUTOREV} in git
Oct 24 01:58:38 <chackal_sjc> is it a better approach to use a PV with this version or not?
Oct 24 01:58:49 <chackal_sjc> because it will change the WORKDIR always, right?
Oct 24 02:08:28 <kergoth> not sure what you mean by that. if you dont want autorev, then set SRCREV. it doesn't have to be global, it can be in the recipe itself (and often is)
Oct 24 02:08:34 <kergoth> then use SRCPV in the PV, and you're set
Oct 24 02:08:40 <kergoth> there are plenty of examples in the poky repostiroy
Oct 24 02:08:44 <kergoth> i'd really suggest reading some of the recipes
Oct 24 02:09:10 <chackal_sjc> i didnt express myself correctly
Oct 24 02:09:43 <chackal_sjc> im saying that I'm using AUTOREV and SRCPV in PV
Oct 24 02:10:11 <chackal_sjc> i was asking if this is a correct aproach to get always the latest stuff without have to cleanall the package
Oct 24 02:20:41 <kergoth> that's what autorev is for.
Oct 24 02:22:08 <blloyd_> why would a statement IMAGE_INSTALL += "omcaudioint"  stop grub from being installed in an image?
Oct 24 02:23:48 <blloyd_> (is that the correct syntax to add a package to the image?)
Oct 24 02:24:47 <victsou> +1 for blloyd_'s last question
Oct 24 02:25:30 <kergoth> if you defined that in a .conf, and your recipe uses ?=, it wouldn't do that definition, as ?= means set if unset, and the variable woudln't be empty/unset at that point
Oct 24 02:25:59 <kergoth> this is why you should use IMAGE_INSTALL_append or CORE_IMAGE_EXTRA_INSTALL += if you want to add packages from local.conf
Oct 24 02:26:07 <blloyd_> so IMAGE_INSTALL_append?
Oct 24 02:26:18 <kergoth> if your'e doing the += in the recipe, be aware of where you're doing it, e.g. before or after a rquire/inherit
Oct 24 02:26:40 <kergoth> if it's a core- image, this is why CORE_IMAGE_EXTRA_INSTALL exists, as it's less error prone than direct IMAGE_INSTALL manipulation
Oct 24 02:26:41 <blloyd_> in a recipe.  :)   I'm learning something.  Boy, can this confuse me.
Oct 24 02:26:49 <kergoth> inherit and require occur where they are
Oct 24 02:26:55 <kergoth> as though the lines from those files were inserted at that location
Oct 24 02:27:07 <kergoth> so ordering is very important there
Oct 24 02:27:22 <kergoth> and no, if it's in a recipe, you shouldn't use append/prepend, there should be no need
Oct 24 02:27:51 <blloyd_> that I had already learned the hard way.  The fact += inserts into whatever is in that variable right at that point, so ?= gets unused is new though.
Oct 24 02:29:04 <blloyd_> question though, let's say I have 4 IMAGE_INSTALL_append = lines.  Would they all get appended or just the last?  Would the last just overwrite the other 3 before the variable was used?
Oct 24 02:29:56 <victsou> I used IMAGE_INSTALL += "packages" for several things, but I'm having trouble with a single one: python
Oct 24 02:30:27 <victsou> I get "unable to resolve package python", even though it exists. do you have any suggestions of what the problem could be, kergoth ?
Oct 24 02:30:39 <victsou> (it's in the recipe)
Oct 24 02:34:07 <blloyd_> did you create your own package for python or are you using the ones provided?
Oct 24 02:34:11 <kergoth> blloyd_: all. it's an operation, not part of the variable name
Oct 24 02:34:18 <kergoth> consider it a lazy equivalent of .=
Oct 24 02:34:28 <kergoth> postponed, that is. its processed at hte end of the parsing, instead of immediately
Oct 24 02:35:19 <blloyd_> OK, _append and _prepend are operations, and so checking for a variable with that in them shouldn't find anything because they are never set?
Oct 24 02:35:37 <blloyd_> (and if this is in the manual, I sure don't remember reading it)
Oct 24 02:39:42 <blloyd_> nm, I can do an easy run of three and find out myself.  Be a fun excercise anyways.
Oct 24 02:46:17 <victsou> provided one, blloyd_
**** ENDING LOGGING AT Wed Oct 24 03:00:01 2012

**** BEGIN LOGGING AT Wed Oct 24 03:00:02 2012
Oct 24 06:11:01 <BjornArnelid> Good morning, why would my cross compile complain if i change the sysroot but keep the toolchain?
Oct 24 06:15:12 <BjornArnelid> "C Compiler cannot create executables"
Oct 24 07:30:05 <mckoan> good morning
Oct 24 08:00:06 <bluelightning> morning all
Oct 24 09:02:52 <b737_800> hi all
Oct 24 09:03:52 <b737_800> I have a question on bitbake run queue
Oct 24 09:03:59 <bluelightning> b737_800: hi
Oct 24 09:04:03 <bluelightning> sure, fire away
Oct 24 09:05:16 <b737_800> i have noticed that in some cases bitbake builds fails and on other cases runs with success with the same target
Oct 24 09:06:00 <b737_800> i have found that the order of task executions is very important
Oct 24 09:06:30 <bluelightning> b737_800: that usually indicates some dependencies haven't been declared
Oct 24 09:07:27 <b737_800> i found a tricky case
Oct 24 09:08:18 <b737_800> for example during  pulseaudio configure it checks for gconf if it found it it build module-gconf package and if not it will not
Oct 24 09:09:20 <b737_800> now if  bitbake schedules gconf after pulseadio the build fails
Oct 24 09:09:43 <b737_800> my question is to know of there is a way to 1
Oct 24 09:09:57 <bluelightning> b737_800: hmm, yes... it looks like it may be missing gconf in DEPENDS
Oct 24 09:10:13 <b737_800> 1.capture the execytion order from a successfull run and 2.force bitbake to follow a given order
Oct 24 09:10:46 <bluelightning> the thing is you don't need to force the order, if bitbake knows about the dependency relationship it will do the right thing
Oct 24 09:14:18 <b737_800> my problem is that with my project i'm not sure i have captured all dependecies, in my case i absolutely must  deliver a solution that builds every time
Oct 24 09:14:51 <b737_800> this is teh reason i wont to capture the execution order from a successfull build and for bitbake to follow it
Oct 24 09:16:17 <bluelightning> the task ordering is determined by the scheduler, I do not believe there is a way of forcing a particular order
Oct 24 09:17:26 <b737_800> thank you very much , i will try to track all  dependecies
Oct 24 09:17:29 <bluelightning> heading to the office, back shortly
Oct 24 09:43:12 <Zagor> ahh, how annoying. I missed yesterdays yptm meeting and of course that's when you discuss package testing :-)
Oct 24 09:44:37 <B4gder> "Will contact Bjorn (Enea) for this." sounds like your not completely ignored though =)
Oct 24 09:44:47 <B4gder> "you're" even
Oct 24 09:44:53 <Zagor> true
Oct 24 09:46:10 <mihai1> Zagor: ping!
Oct 24 09:46:10 <mihai1> :)
Oct 24 09:46:22 <Zagor> mihai1: pong! :-)
Oct 24 09:47:26 <mihai1> Zagor: you were indeed summoned in the meeting yesterday for the package testing stuff
Oct 24 09:49:25 <Zagor> mihai1: the minutes say "Just published yesterday", but I didn't see it on the list?
Oct 24 09:51:10 <mihai1> Zagor: that referred to meta-tpm, which was published, i.e. made public, still experimental though. not sure if it should be announced in this stage.
Oct 24 09:52:39 <Zagor> ok
Oct 24 11:08:27 <BjornArnelid> I'm not sure if anyone is interested, but i found out why my compiler was complaining - it turned out that some dependencies were missing in one of the sysroots.
Oct 24 11:38:19 <BjornArnelid> ct9
Oct 24 11:38:36 <BjornArnelid> sorry, mistype
Oct 24 14:38:22 <exosyst> How do I find out what packages are available in a yocto/poky build? In my case, I want the 'file' command - how do I know what package provides it?
Oct 24 14:39:46 <bluelightning> exosyst: in that case the recipe is called "file"
Oct 24 14:40:23 <exosyst> bluelightning, So I just want IMAGE_INSTALL += " file "?
Oct 24 14:40:23 <bluelightning> bitbake -s or bitbake-layers show-recipes will list all recipe targets (and bitbake-layers show-recipes can take a wildcard)
Oct 24 14:40:45 <bluelightning> exosyst: in this case file is also the runtime package name, so yes
Oct 24 14:41:26 <exosyst> bluelightning, and what happens when they differ? (I don't have an example at this moment in time). Do I just grep through bitbkake -s output?
Oct 24 14:41:34 <bluelightning> of course both of those commands only cover the metadata currently enabled in your configuration
Oct 24 14:41:57 <kergoth> exosyst: -s shows recipes, not packages, though.
Oct 24 14:42:02 * kergoth yawns
Oct 24 14:42:12 <bluelightning> kergoth: indeed
Oct 24 14:42:40 <bluelightning> exosyst: you kind of just have to know what the package name is; sometimes the package names aren't fully determined until after packaging is done (e.g. kernel modules are dynamically packaged)
Oct 24 14:43:02 <bluelightning> exosyst: "git grep" can be helpful though for ones that are defined
Oct 24 14:43:31 <exosyst> bluelightning, kergoth So, as a layperson, how would I know that I need "file"? There's nothing like "yum search file" I take it?
Oct 24 14:44:20 <kergoth> bluelightning: heh, it'd be nice to have a bitbaek arg to request a runtime provide, instead of build time. can't think of any reason we couldn't pull that off
Oct 24 14:44:23 <kergoth> ah well, eventually
Oct 24 14:45:24 <exosyst> I read that it was packages, not recipes, that are used to build up file systems?
Oct 24 14:45:48 <kergoth> this is true, yes
Oct 24 14:45:51 <bluelightning> exosyst: "yum search" operates from a binary distro level, where your packages have already been produced; so there the database of packages is already determined; unfortunately we can't completely provide that before the build
Oct 24 14:47:47 <exosyst> bluelightning, that seems a bit mad given that you have all these layers and meta info - adding that sort of thing would be a huge win surely?
Oct 24 14:49:12 <kergoth> apparently you think we have a crystal ball in our pocket to know what the buil will produce :)
Oct 24 14:49:36 <bluelightning> exosyst: it's not too bad, 95% of the time the main package for a recipe is the same name as the recipe (at least as far as what you put in IMAGE_INSTALL is concerned)
Oct 24 14:50:47 <exosyst> kergoth, Oh not at all, sorry if I'm rehashing stuff you've had to answer before. I just see how a distro has things like yum search X and yum provides X and wondered why that wouldn't be available
Oct 24 14:51:08 <exosyst> bluelightning, in what scenarios does it differ so I know in future before asking dumb questions :D
Oct 24 14:51:09 <kergoth> he just explained this
Oct 24 14:52:13 <bluelightning> exosyst: well, some recipes use a different name or don't really have a main package; e.g. qt is split up into various components and you really need to just select the components you want individually or you get a whole bunch of stuff you won't need on the target
Oct 24 14:52:27 <exosyst> kergoth, I appreciate the answer but, for example, gentoo doesn't need to know this and I could still use portage/emerge to get 'file'. I'm not trying to be difficult - honestly
Oct 24 14:53:07 <exosyst> bluelightning, so it would be " qt-core qt-webkit " etc, rather than just " qt "?
Oct 24 14:53:37 <bluelightning> exosyst: the package names are slightly different, but yes that's the principle
Oct 24 14:54:18 <exosyst> bluelightning, but there would also be a kinda, meta-package for all of Qt?
Oct 24 14:54:53 <bluelightning> exosyst: yes, for qt the main package (qt-x11-free for the X11 version, qt-embedded for the framebuffer version) is that meta-package
Oct 24 14:54:59 <bluelightning> but you almost always don't want everything
Oct 24 14:55:25 <bluelightning> the main package dragging in everything trips a few people up, I have wondered if it would be worth renaming
Oct 24 14:55:43 <bluelightning> anyway, the qt packaging is somewhat specific
Oct 24 14:55:53 <bluelightning> most recipes don't do that sort of thing
Oct 24 14:55:57 <exosyst> bluelightning, indeed. Ok, well I guess that's what IRC is for - asking those in the know. A database would be really useful though as this must come up a lot no?
Oct 24 14:56:53 <bluelightning> I guess "git grep", "bitbake -s" and "bitbake-layers show-recipes" are able to find most things for simple cases
Oct 24 14:57:28 <bluelightning> a couple of things that would be practical for us to provide: 1) a report of projected package names (including what recipes declare in PACKAGES and PACKAGES_DYNAMIC)
Oct 24 14:57:50 <bluelightning> 2) a searchable database produced from a world build on the autobuilder
Oct 24 14:58:36 <bluelightning> however, 1) suffers from the dynamic packaging issue I mentioned earlier and 2) would only cover our default configuration and the core metadata and not any customisations/extensions the user has done within their configuration
Oct 24 14:58:51 <bluelightning> so there's no magic bullet unfortunately
Oct 24 14:59:21 <bluelightning> FYI, once you have done a build you can get a bunch of information in tmp/pkgdata
Oct 24 14:59:51 <bluelightning> also, if you enable buildhistory it will output some information about the content of packages as well
Oct 24 15:00:24 <bluelightning> however, the caveat for these is that both pkgdata and buildhistory can only provide information after a recipe has been built
Oct 24 15:05:16 <ant_work> bluelightning: I'm pretty sure some gentoo tools can be enlightning. You can query th emetadata and not the packages.
Oct 24 15:05:51 <ant_work> unfortunately I'm not a python guy
Oct 24 15:06:28 <bluelightning> ant_work: I'm not sure they do anything special that we couldn't do fairly easily if we sat down to do it; the real question is what kind of queries do people want to be able to do and are they practical to do with the way our build system works...
Oct 24 15:06:46 <ant_work> they already answered tose questions :)
Oct 24 15:07:12 <ant_work> tools have been polished in the years
Oct 24 15:07:25 <bluelightning> I don't know a lot about emerge, it's been years since I used gentoo... but I suspect it does not work exactly like our system
Oct 24 15:07:40 <ant_work> not emerge, the tools
Oct 24 15:07:42 <ant_work> http://www.gentoo.org/doc/en/gentoolkit.xml
Oct 24 15:07:52 <ant_work> (the tools about portage metadata)
Oct 24 15:08:09 <bluelightning> does gentoo separate the output of a single ebuild into components as we do with packages?
Oct 24 15:08:17 <bluelightning> IIRC it doesn't...
Oct 24 15:10:17 <ant_work> you have to tell it to keep the binary pkgs
Oct 24 15:10:39 <bluelightning> but is there ever more than one for an ebuild?
Oct 24 15:11:01 <ant_work> http://www.gentoo.org/doc/en/handbook/handbook-ppc64.xml?part=2&chap=3#doc_chap4
Oct 24 15:11:32 <ant_work> it's different anyway...
Oct 24 15:11:51 <bluelightning> I doubt gentoo would be able to support that since it expects to have the dev headers for everything so that you can continue to source build after partially constructing the system from binary packages
Oct 24 15:12:38 <bluelightning> although one assumes that gentoo-embedded (is that still going) has some way around that
Oct 24 15:16:32 <ant_work> anyway, the set of queries done by equery seems a good starting point to me
Oct 24 15:17:14 <ant_work> revdep-rebuild tools is in some ways 'superseded' by sstate
Oct 24 15:19:32 <bluelightning> indeed, we shouldn't need to scan for library dependencies
Oct 24 15:20:53 <JaMa> and also by @preserved-rebuild set :)
Oct 24 15:22:58 <ant_work> JaMa: yes, we appreciate your efforts against unneeded rebuildings :)
Oct 24 15:23:58 <bluelightning> while we're talking, if anyone has any feature requests for 1.4 that haven't already been filed, please do so as soon as possible
Oct 24 15:24:03 <JaMa> bluelightning: I usually query for "which package/recipe provides some/path/file", what are build/runtime dependencies of some package/recipe
Oct 24 15:25:22 <bluelightning> I have been thinking for a while about a generic bitbake query tool which can look up useful things in the metadata
Oct 24 15:25:24 <ant_work> wouldn't it be a bitbake feature?
Oct 24 15:25:29 <ant_work> exactly :)
Oct 24 15:25:42 <JaMa> bluelightning: or from this list http://paste.debian.net/203307/ commands b d g f l w
Oct 24 15:25:48 <bluelightning> well, it would use bitbake's code but it wouldn't be built into the bitbake executable itself
Oct 24 15:26:06 <bluelightning> a la bitbake-layers
Oct 24 15:26:35 <ant_work> sure, I meant if it does pertain to Yocto or bitbake
Oct 24 15:26:43 <bluelightning> we can't know about package contents before building though
Oct 24 15:27:17 <bluelightning> ant_work: well, within the Yocto Project we consider changes to the overall build system, whether they need to be in bitbake, OE-Core or elsewhere
Oct 24 15:27:19 <JaMa> bluelightning: but you can show manifest from sstate-control if it was already
Oct 24 15:27:28 <JaMa> bluelightning: or error that it wasn't built yet
Oct 24 15:27:37 <JaMa> equery in gentoo does the same
Oct 24 15:27:40 <ant_work> why? a query to PROVIDES ?
Oct 24 15:27:42 <bluelightning> JaMa: hmm possibley
Oct 24 15:27:46 <bluelightning> er, possibly
Oct 24 15:28:06 <ant_work> JaMa: yes, like equery
Oct 24 15:28:25 <bluelightning> brb
Oct 24 15:28:31 <ant_work> bbquery ?
Oct 24 15:28:46 <bluelightning> ant_work: my prototype is called that funnily enough :)
Oct 24 15:28:50 <ant_work> lol
Oct 24 15:29:11 <bluelightning> atm it only queries variable values slightly faster than bitbake -e | grep
Oct 24 15:30:08 <ant_work> make it -native, well'find someone to write it in assembly :)
Oct 24 15:31:10 <ant_work> bluelightning: an sql database maybe? portage has it
Oct 24 15:31:24 <ant_work> an extra cache
Oct 24 15:33:10 <ant_work> JaMa: http://www.gentoo.org/news/en/gwn/20061106-newsletter.xml#doc_chap4
Oct 24 15:33:25 <ant_work> "searching for ebuilds in overlays that are not locally available"
Oct 24 15:35:01 <JaMa> eix is more like https://bugzilla.yoctoproject.org/show_bug.cgi?id=3272
Oct 24 15:35:34 <JaMa> at least in remote mode
Oct 24 15:35:43 <ant_work> eix is commandline
Oct 24 15:36:15 <JaMa> I know but now bluelightning_ was talking about queriing build metadata
Oct 24 15:36:19 <ant_work> but yes, one other question was to find which layer contains foo
Oct 24 15:36:27 <ant_work> right
Oct 24 15:36:30 <JaMa> and #3272 is about indexing like eix does
Oct 24 15:39:47 <ant_work> eix has own separate cache,though
Oct 24 15:40:24 <kergoth> hmm, core-image-base defaults to no package-management?
Oct 24 15:40:39 <kergoth> seems like a slightly odd choice -- core-image-minimal i can see, but..
Oct 24 15:40:57 <ant_work> iirc core-image-base had it...
Oct 24 15:41:47 <kergoth> doesn't seem to. i thought it did, too. core-image-sato, etc explicitly add it to image features, core-image-base does not
Oct 24 15:44:37 <ant_work> I remember having verified that pb's patch did in fact avoid "rootfs pollution" but yes, I did not enable P_M explicitely
Oct 24 15:44:39 <ant_work> "[OE-core] [PATCH v2] rootfs_ipk: Avoid leaving run-postinsts around if online package management is disable"
Oct 24 15:54:12 <Crofton|work> bluelightning_, is there an easy way to find proposed features for 1.4
Oct 24 15:54:39 <bluelightning_> Crofton|work: I think it's summarised dynamically on the 1.4 wiki page, one sec
Oct 24 15:55:03 <bluelightning_> Crofton|work: https://wiki.yoctoproject.org/wiki/Yocto_1.4_Features
Oct 24 15:58:46 <Crofton|work> bluelightning_, send that to the lists with begging for more input since not everyone reads this
Oct 24 16:01:57 <ant_work> bbl
Oct 24 16:08:09 <bluelightning_> Crofton|work: we should do that yes... it has been mentioned during the tech calls as well although that's an even smaller audience
Oct 24 16:09:53 <bluelightning_> Crofton|work: actually it did get sent out already: https://lists.yoctoproject.org/pipermail/yocto/2012-October/012052.html
Oct 24 16:11:04 <Crofton|work> a reminer would be good, since you were asking people to get off their asses :)
Oct 24 16:15:01 <bluelightning> Crofton|work: sure, now just to find the original email in my inbox...
Oct 24 16:18:30 <JaMa> bluelightning: what about patches like https://bugzilla.yoctoproject.org/show_bug.cgi?id=3220 ?
Oct 24 16:18:32 <Crofton|work> I've got it
Oct 24 16:18:42 <Crofton|work> Do you want me to resend it
Oct 24 16:18:43 <JaMa> bluelightning: it's not in list but also not reported as "enhancement"
Oct 24 16:18:49 <Crofton|work> when does the process need to wrap up?
Oct 24 16:19:53 <bluelightning> JaMa: well, that's filed so it should be taken care of as with any other bug
Oct 24 16:20:04 <bluelightning> Crofton|work: I'm about to reply
Oct 24 16:20:11 <Crofton|work> k
Oct 24 16:20:44 <Crofton|work> thanks
Oct 24 16:26:03 <fray> t
Oct 24 16:26:38 <bluelightning> fray: I'll put the kettle on... ;)
Oct 24 16:39:31 <fray> kettle on the hob?
Oct 24 16:40:31 <bluelightning> fray: cooking with gas! :D
Oct 24 21:40:09 <ant__> khem: I see abroken symlink in sysroot
Oct 24 21:40:32 <ant__>  arm-oe-linux-gnueabi-g77 -> /oe/oe-core/build/tmp-eglibc/sysroots/i686-linux/usr/bin/arm-oe-linux-gnueabi-gfortran
Oct 24 21:41:04 * JaMa too
Oct 24 21:41:20 <ant__> iirc was once fixed couple of years ago :)
Oct 24 21:41:36 <JaMa> I've noticed it when running sstate-sysroot-cruft.sh
Oct 24 21:42:10 <mranostay> wb challinan
Oct 24 21:42:22 <challinan> hi mraonstay
Oct 24 21:42:27 <challinan> all ready for barcelona?
Oct 24 21:42:34 <mranostay> think so
Oct 24 21:42:44 <challinan> should be fun
Oct 24 21:43:21 * challinan has made a note to heckle^Wattend your presentation
Oct 24 21:43:38 <ant__> JaMa: and at least on Gentoo (I don't think it is specific, though) the git-core scripts are missing
Oct 24 21:43:54 <ant__> linux-yocto seems needing the compat scripts
Oct 24 21:44:47 <ant__> somehow I need to bitbake git-replacement-native
Oct 24 21:46:02 <ant__> (/oe/oe-core/build/tmp-eglibc/sysroots/i686-linux/usr/bin/../libexec/git-core/git-sh-setup: No such file or directory)
Oct 24 21:46:39 <JaMa> it works for me without git-replacement-native
Oct 24 21:46:43 <ant__> note this was even true before libexec->lib move
Oct 24 21:47:29 <ant__> are you building linux-yocto?
Oct 24 21:48:33 <ant__> my Gentoo has the scripts in /usr/libexec/git-core
Oct 24 21:48:58 <mranostay> challinan: what day you get in?
Oct 24 21:49:32 <challinan> pobably monday, have yet to make flight arrangements
Oct 24 21:49:40 <challinan> you?
Oct 24 21:51:27 <mranostay> sunday afternoon
Oct 24 21:51:27 <kergoth> sheesh, elce is here already? time flies
Oct 24 21:53:24 <mranostay> kergoth: you going?
Oct 24 21:54:53 <khem> ant__: I once fixed it
Oct 24 21:55:02 <khem> we might need to fix it again
Oct 24 21:55:43 <khem> Spanish embassy agreed to get some economic help from me and let me spend some money in SPain
Oct 24 21:56:10 <challinan> heh
Oct 24 21:57:01 <kergoth> hmm, odd, https://gist.github.com/3949177
Oct 24 21:57:18 <kergoth> fresh qemuarm build. *scratches head*
Oct 24 21:57:22 <JaMa> ant__: yes
Oct 24 21:58:14 <JaMa> khem: any idea about this: http://lists.linuxtogo.org/pipermail/openembedded-core/2012-October/031325.html ?
Oct 24 23:16:02 <ant__> Jefro1: hi, is it possible to attend to YPPD w/out attending to ELCE ?
Oct 24 23:16:38 <Jefro1> ant__ yes indeed.  the hands-on labs are currently full, but you can attend for all of the presentations
Oct 24 23:16:42 <Jefro1> link in just a sec
Oct 24 23:17:00 <ant__> I read it, thx
Oct 24 23:17:19 <ant__> I'll have a flight at 19.30 though :/
Oct 24 23:17:59 <Jefro1> ah, you'll miss snacks in the evening :)
Oct 24 23:18:14 <Jefro1> here is the registration form for DevDay if you aren't going to ELCE: http://www.regonline.com/Register/Checkin.aspx?EventID=1115598
Oct 24 23:18:35 <ant__> great, thx
Oct 24 23:24:12 <ant__> hm, so the labs seems closed?
Oct 24 23:25:23 <ant__> choice is given between "presentation only (no labs)" and "staff member"
Oct 24 23:41:04 <ant__> gn
Oct 25 01:22:16 <ftonello> why the save-rtc is in only runlevel 0 and 5?
Oct 25 01:22:21 <ftonello> 0 is nevel called at boot time
Oct 25 01:22:28 <ftonello> it should be in S also, right?
**** ENDING LOGGING AT Thu Oct 25 03:00:00 2012

**** BEGIN LOGGING AT Thu Oct 25 03:00:01 2012
Oct 25 10:19:20 <JaMa> btw: USERADD_PARAM_${PN} = "--create-home" causes /home/foo to be created in sysroot, bypassing sstate
Oct 25 10:22:55 <JaMa> together with changes to passwd/passwd-/group/group-
Oct 25 10:23:16 <JaMa> I mean't it's correctly installed from sstate, but sstate-control manifest's don't know about it
Oct 25 10:24:15 <bluelightning> surely we don't actually need useradd to be affecting the sysroot at all?
Oct 25 10:27:47 <JaMa> it needs to have matching UID/GID afaik
Oct 25 10:28:06 <JaMa> but I don't remember which passwd/group is actually used :)
Oct 25 10:35:29 <RagBal> Why does packagegroup-xfce-base in meta-xfce have no dependencies to x11-server?
Oct 25 10:39:58 <RagBal> And where can I find libxp? It is required by libxaw but nowhere to be found
Oct 25 10:42:24 <JaMa> RagBal: it was removed from oe-core
Oct 25 10:42:28 <JaMa> RagBal: you need newer meta-oe
Oct 25 10:43:25 <RagBal> Ok I'll pull the latest
Oct 25 10:48:00 <RagBal> But to verify my working order, I want to build XFCE
Oct 25 10:48:37 <RagBal> Is it correct that I select the following packagegroups: core-boot, core-ssh-dropbear, xfce-base, core-x11-xserver, core-x11
Oct 25 13:09:52 <RagBal> warning, the recipe ... is trying to isntall files into a shared area when those files already exist. After I pulled from git. Do I have to remove all of those folder manually or is there a command for this? I tried cleaning the corresponding packages
Oct 25 13:18:55 <bluelightning> RagBal: can you pastebin the full warning text?
Oct 25 13:22:40 <RagBal> WARNING: The recipe libmatchbox is trying to install files into a shared area when those files already exist. Those files are:
Oct 25 13:22:46 <RagBal> And then a bunch of files
Oct 25 13:23:01 <RagBal> And that goes for a lot of packages
Oct 25 13:26:32 * Zagor spots an 1.3 tag
Oct 25 13:37:19 <MrBar> hi
Oct 25 13:37:34 <MrBar> bitbake: line 44: python: command not found
Oct 25 13:53:29 <mihai1> MrBar: well, that's a tough one :)
Oct 25 14:16:25 <RagBal> Ugh it's driving me crazy. Either I'm a complete retard or I just don't understand the whole OE concept
Oct 25 14:16:45 <RagBal> I just want to build a simple image with XFCE desktop for raspberry pi
Oct 25 14:17:03 <Crofton|work> RagBal, try to do it without OE, then you will understand :)
Oct 25 14:17:39 <RagBal> I'm not going to compile everything by hand =P
Oct 25 14:18:21 <bluelightning> RagBal: you can mostly ignore the warnings... I'm surprised you see any to be honest but they're not a serious problem
Oct 25 14:18:43 <RagBal> Yeah, it buided successfully
Oct 25 14:18:46 <RagBal> builde
Oct 25 14:18:46 <RagBal> d
Oct 25 14:19:12 <RagBal> But I just can't get my image to work with XFCE, I don't understand what I need to include
Oct 25 14:19:35 <RagBal> IMAGE_FEATURES += "ssh-server-dropbear splash x11-base package-management"
Oct 25 14:19:49 <RagBal> IMAGE_INSTALL += "packagegroup-xfce-base"
Oct 25 14:20:20 <RagBal> Is there anything not correct in that for generating a XFCE enabled image? =(
Oct 25 14:21:14 <RagBal> Any other desktop manager is fine also, as long as it is not sato, just for reference
Oct 25 14:23:28 <bluelightning> isn't there an example image provided in meta-xfce?
Oct 25 14:24:41 <RagBal> I checked all the folders, there is no "images" folder anywhere
Oct 25 14:25:59 <RagBal> There are some packagegroups though
Oct 25 14:26:38 <bluelightning> ah ok
Oct 25 14:27:15 <bluelightning> RagBal: I've never built xfce but I know many people do build it with OE; if nobody can help here I would recommend posting to the mailing list
Oct 25 14:28:40 <RagBal> Will try that, thank you
Oct 25 14:29:40 <bluelightning> (probably the openembedded-devel mailing list for the most appropriate audience for xfce)
Oct 25 14:32:03 <RagBal> We have received a request from 127.0.0.1 for subscription  <-- lol
Oct 25 14:32:38 <RagBal> When subscribing at the Yocto mailing list
Oct 25 14:33:38 <B4gder> =)
Oct 25 14:33:57 <B4gder> with Yocto, you always feel at home! :-P
Oct 25 14:34:34 <RagBal> Seems like that
Oct 25 14:34:49 <RagBal> Or... the mailing list daemon runs on my local computer =o
Oct 25 14:34:59 <RagBal> Without my knowledge
Oct 25 14:40:11 <MrBar> yocto supports only qemu targets?
Oct 25 14:43:10 <bluelightning> MrBar: we also have 4 reference BSPs for real hardware
Oct 25 14:43:31 <bluelightning> MrBar: for other hardware support you need to have a BSP layer for your target
Oct 25 14:43:54 <bluelightning> a number of them can be found here: http://www.openembedded.org/wiki/LayerIndex
Oct 25 14:44:27 <bluelightning> there's also documentation and tools to create new BSP layers as well
Oct 25 14:45:03 <MrBar> great point, thanks
Oct 25 15:10:37 <MrBar> it is good idea to run two copy of bitbake in different nodes in same build tree shared by nfs?
Oct 25 15:11:35 <bluelightning> if you mean against the same metadata, no problem
Oct 25 15:12:36 <MrBar> yeah
Oct 25 15:13:13 <kergoth> just don't keep the build *output* in nfs ;)
Oct 25 15:13:55 <bluelightning> yeah, if you mean sharing TMPDIR, that is not a good idea and probably will be prevented by the lockfile
Oct 25 15:16:35 <MrBar> wait i mean to build *one* image on two nodes in parallel
Oct 25 15:17:30 <MrBar> like on cluster
Oct 25 15:24:43 <kergoth> you can only run one copy of bitbake against one build directory at a time. they can share metadata, but not state. we can distribute jobs within a single build across cpus, but not machines
Oct 25 15:27:46 <MrBar> strangely
Oct 25 15:28:46 <Zagor> we accept patches :-)
Oct 25 15:31:51 <MrBar> task lock implemented by state shared that is memory cached, so need a file backend for state share
Oct 25 20:07:56 <fray> BTW the RFC for the zypper -> smart change went out..
Oct 25 21:05:06 <MrBar> Failed to fetch test data from the network. Please ensure your network is configured correctly.
Oct 25 21:08:15 <kergoth> i've seen that failure on a machine that has perfectly fine networking before
Oct 25 21:14:15 <JaMa|Off> MrBar: it is using short timeout so it timeouts here too (while it downloads fine manually with wget)
Oct 25 21:16:51 <MrBar> sanity too strict
Oct 25 21:23:04 <JaMa|Off> use faster URIs
Oct 26 00:07:56 <pidge> Yocto Project 1.3 is officially released!
Oct 26 00:21:49 <kergoth> woo!
Oct 26 00:21:53 <kergoth> grats all around
Oct 26 00:39:15 <halstead> pidge, downloads.yp
**** ENDING LOGGING AT Fri Oct 26 03:00:01 2012

**** BEGIN LOGGING AT Fri Oct 26 03:00:01 2012
Oct 26 07:11:54 <RagBal> Is it recommended to work and stick to a specific branch?
Oct 26 07:12:04 <RagBal> Like the 1.3 release
Oct 26 07:12:23 <RagBal> And does it stick to a specific meta-openembedded commit?
Oct 26 07:14:27 <mertsas> RagBal: For making e.g.a distro on top of oe-core and meta-oe? What I would do was to keep on master/HEAD, and branch out when oe-core and meta-oe does that to make a release. This way you can make your own release "together" with upstream, and still keep updating you distro.
Oct 26 07:15:02 <mertsas> RagBal: I don't think I would have taken a release and stuck with it, as you would only benefit from the work that have been done up to that release, and disregarded all work that will be done in the future
Oct 26 07:16:35 <RagBal> oe-core is the meta folder?
Oct 26 07:16:54 <mertsas> yeah, the recipes is in oe-core/meta
Oct 26 07:17:00 <mertsas> if that was what you asked
Oct 26 07:18:07 <RagBal> No, I was trying to understand what you mean with oe-core, meta-oe is met-openembedded what I cloned manually
Oct 26 07:18:18 <RagBal> Right?
Oct 26 07:18:38 <mertsas> oe-core is git://git.openembedded.org/openembedded-core.git
Oct 26 07:19:24 <RagBal> I only cloned the poky.git doesn't it include oe-core?
Oct 26 07:20:36 <RagBal> Perhaps I'm completely setup wrong or I'm just seeing everything in the wrong terms =)
Oct 26 07:20:41 <mertsas> RagBal: seems like that is the meta directory, yes, but I have not used poky.git myself, so really don't know
Oct 26 07:21:11 <mertsas> but a quick look in the classes section seems to confirm that they are the same
Oct 26 07:21:29 <RagBal> The readme states that there only are differences in the scripts folder
Oct 26 07:21:53 <RagBal> But what is your default setup then? A clone of oe-core with meta-yocto in it?
Oct 26 07:22:00 <mertsas> RagBal: then meta is meta-oe
Oct 26 07:22:43 <mertsas> my setup is quite different than yocto. Don't really have meta-yocto at all. I only have manually clone openembedded-core and meta-openembedded
Oct 26 07:22:58 <mertsas> and bitbake of course
Oct 26 07:23:11 <RagBal> Ok so you have a basic basic setup
Oct 26 07:23:23 <mertsas> yes
Oct 26 07:23:25 <RagBal> What is the advantage of that? Not to judge you or anything, just to learn
Oct 26 07:23:41 <RagBal> Because I'm experimenting with the whole oe scene
Oct 26 07:23:51 <RagBal> Trying to make something for my raspberrypi
Oct 26 07:25:29 <RagBal> Like what distribution do you use then? OE doesn't include one right
Oct 26 07:29:16 <mertsas> I don't really see a huge advantage with it compared to using yocto, except that it is smaller. My plan is to make a simple distribution myself, which is really minimal. What I want is to, at least as default, don't even have X11, but use stuff like KMS and wayland if the board supports it
Oct 26 07:31:04 <RagBal> Sounds pretty cool
Oct 26 07:34:59 <mertsas> I hope it will be. At least it will be fun to work a bit on:P
Oct 26 07:36:42 <RagBal> Yea I find it pretty worth while finding things out
Oct 26 07:45:32 <RagBal> Is it a good thing to share DL_DIR and SSTATE_DIR amongst projects?
Oct 26 07:45:44 <JaMa|Off> yes
Oct 26 07:46:20 <RagBal> So it has no issues when building multiple architectures and dists?
Oct 26 07:49:20 <RagBal> TMPDIR should be left alone by each project I guess?
Oct 26 07:49:31 <JaMa> usually no and when it has, it's worth fixing
Oct 26 07:49:44 <JaMa> depends how different those projects are
Oct 26 07:49:56 <JaMa> e.g. cannot use different DISTRO in same TMPDIR
Oct 26 07:50:31 <RagBal> Ok, will leave it with the project then
Oct 26 08:21:24 <aggurio> morning, is there an official yocto build server where I can find prebuild documentation (like the latest usermaual.xml in the source)?
Oct 26 08:22:41 <jackmitchell> aggurio: the yocto wensite has all the latest documentation
Oct 26 08:22:49 <jackmitchell> s/wensite/website
Oct 26 08:23:25 <aggurio> Is that the release documentation? I was hoping to be able to get the latest from the git head..
Oct 26 08:24:46 <jackmitchell> aggurio: yes if you look at the section which says documents in progress or something similart
Oct 26 08:24:57 <aggurio> Thanks, I'll try that
Oct 26 08:25:09 <jackmitchell> aggurio: http://www.yoctoproject.org/documentation/docs-in-progress
Oct 26 08:26:20 <aggurio> Thanks, I was looking for a pdf version of ./bitbake/doc/manual/usermanual.xml, is that in the bitbake site instead?
Oct 26 08:27:49 <aggurio> That's why I thought a build server might have it, I couldn't find it in the yoctoproject.org page
Oct 26 08:30:50 <aggurio> Finally found it here, http://docs.openembedded.org/bitbake/html/, Thanks!
Oct 26 08:32:56 <bluelightning> unfortunately that may not be completely up-to-date; I'm not sure if it is built regularly
Oct 26 08:33:04 <bluelightning> (the bitbake manual on openembedded.org)
Oct 26 08:33:27 <slaine> Congrats on the release folks
Oct 26 08:37:02 <aggurio> bluelightning: Is bitbake rebuild in yocto? In other words, how would I build its documentation locally?
Oct 26 08:37:49 <bluelightning> aggurio: just cd into bitbake/doc/manual and run make
Oct 26 08:38:05 <aggurio> Thanks, I'll give that a go.
Oct 26 08:39:01 <aggurio> To my original question, is there no public build server where you can check this document without having to download yocto locally?
Oct 26 08:45:39 <bluelightning> aggurio: we don't build and publish the bitbake manual I don't think, no
Oct 26 08:46:31 <bluelightning> aggurio: the content really needs expanding and updating, hopefully we'll be able to take care of that in this cycle
Oct 26 08:47:22 <bluelightning> many bitbake concepts are covered in the Yocto Project documentation that is up-to-date however
Oct 26 08:49:03 <aggurio> Thanks bluelightning, I appreciate your help
Oct 26 08:49:16 <bluelightning> you're welcome :)
Oct 26 09:00:56 <mertsas> bluelightning: still plans for writing qt5 recipes?
Oct 26 09:01:23 <bluelightning> mertsas: I still plan to, yes, haven't looked into it yet though
Oct 26 09:01:32 <bluelightning> mertsas: I understand otavio has started working on them though
Oct 26 09:01:39 <mertsas> ok, cool
Oct 26 09:02:22 <mertsas> looking forward to playing around some more with new qt, which is built more properly than what we have used:P
Oct 26 09:46:01 <ignus> Hello all, is there a way to remove kmod as a dependency of the kernel recipe without breaking the kernel build?
Oct 26 09:46:42 <bluelightning> ignus: hi
Oct 26 09:47:19 <ignus> bluelightning, hey, good morning
Oct 26 09:47:30 <bluelightning> ignus: is it the fact that it's building that's an issue or just that it ends up in the runtime dependencies?
Oct 26 09:48:35 <ignus> bluelightning, just that it ends up in the file system - i think we can get the same functionality from the busybox lsmod/modprobe/... applets so kmod is just taking up space which could be used for something else... make sense?
Oct 26 09:50:16 <bluelightning> ignus: right, absolutely... hmm
Oct 26 09:51:03 <ignus> bluelightning, really im just curious how much space would be saved by ripping it out. it might well be insignificant and not worth the effort...
Oct 26 09:53:43 <ignus> bluelightning, would it help if you could see my kernel recipe?
Oct 26 09:53:59 <bluelightning> ignus: actually I think it might not be the kernel that's the important bit
Oct 26 09:54:36 <bluelightning> ignus: if busybox can provide depmod then it should be pretty easy to fix
Oct 26 09:55:35 <ignus> bluelightning,  in pn-depends.dot: "linux-yocto-blah" -> "kmod-native"
Oct 26 09:56:07 <bluelightning> that's kmod-native though, that's for when the image is built
Oct 26 09:56:45 <ignus> ah ok, not the bits that get installed so...
Oct 26 09:56:52 <bluelightning> I'm looking at the dependencies within a built image (using the graphs output by buildhistory)... afaict the chain is (kernel module) -> update-modules -> kmod
Oct 26 09:58:16 <ignus> so, it looks like all the module utilities are in busybox: insmod rmmod lsmod modprobe and depmod
Oct 26 09:58:46 <bluelightning> ok, in that case assuming they are enabled you should just be able to bbappend update-modules to not depend on module-init-tools-depmod
Oct 26 09:59:55 <bluelightning> judging by the buildhistory output it'll probably save about 160k (minus anything added to busybox)
Oct 26 10:00:33 <ignus> so, compressed is probably about half that?
Oct 26 10:03:38 <bluelightning> yep, looks like it
Oct 26 10:03:51 <ignus> is this the line which creates the dependency? RDEPENDS_${PN} = "module-init-tools-depmod"
Oct 26 10:03:58 <bluelightning> yep
Oct 26 10:04:26 <ignus> so just replacing that with RDEPENDS_${PN} = "" will get rid of it?
Oct 26 10:04:37 <bluelightning> yes
Oct 26 10:05:00 <bluelightning> I did wonder about adding that to RPROVIDES in your busybox bbappend but I think just removing the RDEPENDS in update-modules is probably easiest
Oct 26 10:05:39 <ignus> ok cool, well ill see if it works now in a sec..
Oct 26 10:09:42 <jackmitchell> bluelightning: if I make a change to a recipe without changing the version, should I do a PR bump? (oe-core)
Oct 26 10:33:06 <ignus> bluelightning, saved 72K, thanks!!
Oct 26 10:33:28 <bluelightning> ignus: np
Oct 26 10:34:29 <bluelightning> jackmitchell: almost always the answer is PR should be bumped, unless it doesn't alter the output or fix a blocking bug that wouldn't be able to be got past on re-exec
Oct 26 10:41:53 <jackmitchell> bluelightning: ok, well the changes I am making are related to stripping out x11 libs when x11 is not a distro feature so it doesn't really effect the output unless you were doing a non-x11 build
Oct 26 10:42:36 <bluelightning> jackmitchell: hmm... I'd err on the side of bumping PR in that case, but it's not totally clear-cut
Oct 26 10:45:20 * jackmitchell needs a faster hdd :(
Oct 26 10:55:34 <Zagor> something seems to have changed in denzil->danny regarding use of IMAGE_FEATURES in recipes. when I echo ${IMAGE_FEATURES} in a do_compile statement, I only get the content of EXTRA_IMAGE_FEATURES from my local.conf, not the IMAGE_FEATURES set in the image
Oct 26 10:57:39 <Zagor> this is with pure poky, branch danny. building core-image-minimal-dev with >>echo foo "${IMAGE_FEATURES}"<< added to do_compile in zlib_1.2.7.bb
Oct 26 10:58:57 <Zagor> output is "foo  debug-tweaks". I had thought "dev-pkgs" should be included there too.
Oct 26 11:05:47 <mihai1> Zagor: features set by an image should come up when you target the image recipe itself with bitbake, e.g. bitbake -e core-image-base
Oct 26 11:06:04 <Zagor> exactly. and they don't.
Oct 26 11:06:26 <mihai1> what image are you trying?
Oct 26 11:06:33 <Zagor> core-image-minimal-dev
Oct 26 11:07:09 <Zagor> this breaks my ptest work, since I do some things only if ptest-pkgs is set in image_features
Oct 26 11:08:04 <Zagor> correction: it looks ok when I run -e, but it doesn't work when the recipe runs
Oct 26 11:08:20 <mihai1> weird, i have dev-pkgs in core-image-minimal-dev
Oct 26 11:08:27 <mihai1> ah, ok
Oct 26 11:09:47 <mihai1> indeed for a single package target, image features takes only after extra image features
Oct 26 11:10:09 <Zagor> yes but that makes sense since we then don't specify which image is built
Oct 26 11:10:50 <Zagor> the problem is that even when I build the image, the image_features from the image definition is not set then the recipe runs
Oct 26 11:10:58 <Zagor> s/then/when
Oct 26 11:11:46 <mihai1> oh, that, yes
Oct 26 11:11:47 <Zagor> there's an extra leading space in the variable, which leads me to suspect there is some filtering somewhere
Oct 26 11:12:48 <bluelightning> Zagor: the leading space comes from using += in bitbake.conf
Oct 26 11:14:22 <Zagor> bluelightning: right, which produces the IMAGE_FEATURES="debug-tweaks dev-pkgs" I get with -e
Oct 26 11:16:04 <bluelightning> Zagor: you should not be looking at IMAGE_FEATURES anywhere outside of an image, btw
Oct 26 11:16:11 <Zagor> ah right, if an evil filter was involved it makes no sense to leave a space *in front* of debug-tweaks
Oct 26 11:16:22 <mihai1> maybe you can use extra image features for both setting the feature and testing in recipes
Oct 26 11:16:33 <mihai1> testing it*
Oct 26 11:16:49 <bluelightning> I'm not sure I understand what is going on here though
Oct 26 11:19:28 <ignus> bluelightning, is it possible to remove a dependency from a list rather than overwriting the entire list?
Oct 26 11:19:28 <Zagor> mihai1: I could, but then I could not make test images
Oct 26 11:20:11 <bluelightning> Zagor: so where do you have references to the value of IMAGE_FEATURES?
Oct 26 11:20:35 <bluelightning> ignus: you can use ${@oe_filter_out(...)} with :=
Oct 26 11:20:41 <bluelightning> ignus: its a bit messy though
Oct 26 11:21:11 <Zagor> bluelightning: I use it in package recipes to determine when to build/install ptest files
Oct 26 11:21:37 <Zagor> *ptest packages
Oct 26 11:21:38 <bluelightning> Zagor: you should be using a feature in DISTRO_FEATURES for that
Oct 26 11:22:08 <bluelightning> IMAGE_FEATURES should only control the content of the image
Oct 26 11:22:16 <bluelightning> (based on already built packages)
Oct 26 11:22:17 <ignus> bluelightning, is it worth doing in case someone adds something else to the list which im overwriting in the future?
Oct 26 11:23:03 <bluelightning> ignus: possibly, yes
Oct 26 11:24:27 <Zagor> are -dev and -dbg package building also DISTRO_FEATURES?
Oct 26 11:25:10 <ignus> bluelightning, so it would look like this?  RDEPENDS := ${@oe_filter_out( "module-init-tools-depmod" )}
Oct 26 11:25:21 <bluelightning> Zagor: they would be disabled at the distro configuration level, yes
Oct 26 11:26:03 <Zagor> bluelightning: that makes sense then. I'll go that route instead. thanks.
Oct 26 11:26:45 <bluelightning> ignus: oh, right... for that case, I would just set it outright, it's not likely that any further RDEPENDS would be added to that recipe you'd care about for your case
Oct 26 11:27:19 <bluelightning> ignus: but for reference it would need to be RDEPENDS_${PN} := ${@oe_filter_out( "module-init-tools-depmod" )}
Oct 26 11:27:35 <bluelightning> pressed enter too early
Oct 26 11:28:37 <bluelightning> ignus: for reference it would need to be RDEPENDS_${PN} := '${@oe_filter_out("module-init-tools-depmod", "RDEPENDS_${PN}" d)}'
Oct 26 11:29:23 <bluelightning> brb
Oct 26 11:29:33 <ignus> bluelightning, ok, thanks!
Oct 26 12:29:59 <BjornArnelid> Hi, im trying to launch oprofile from  eclipse, but it seems like it is looking for opreport that did not get installed when i installed oprofileui.
Oct 26 12:30:13 <BjornArnelid> Do i need to install something besides oprofileui to get opreport?
Oct 26 12:33:37 <bluelightning> BjornArnelid: AFAICT the oprofile package should contain /usr/bin/opreport
Oct 26 12:36:50 <BjornArnelid> bluelightning:  So i need to install oprofile on host to run oprofileui?
Oct 26 12:37:09 <BjornArnelid> From within eclipse.
Oct 26 12:37:13 <bluelightning> BjornArnelid: I think you may yes
Oct 26 12:37:27 <bluelightning> we were missing a dependency that I added for the 1.3 release I think
Oct 26 12:38:05 <bluelightning> BjornArnelid: which version are you using?
Oct 26 12:38:28 <BjornArnelid> 0.2.0
Oct 26 12:41:21 <bluelightning> BjornArnelid: sorry, I meant yocto project version
Oct 26 12:42:02 <BjornArnelid> I picked it up with "git clone git://git.yoctoproject.org/oprofileui" so it should be latest from master right?
Oct 26 12:43:08 <BjornArnelid> bluelightning: Oh sorry, Its equal to 1.2.1 i think
Oct 26 12:43:39 <bluelightning> ok, yeah, in that version there wasn't a dependency to pull in oprofile when installing oprofileui
Oct 26 12:43:56 <bluelightning> but I'm told both the UI client and server need oprofile to run
Oct 26 12:45:19 <BjornArnelid> Its actually EneaLinux 1.2.1 but i think they are fairly similar.
Oct 26 12:46:05 <BjornArnelid> So i need to install oprofile on host and i should be good to go.
Oct 26 12:46:15 <BjornArnelid> Thank you bluelightning !
Oct 26 12:54:00 <bluelightning> BjornArnelid: np
Oct 26 13:38:36 <jackmitchell> ah man, that last patchset went so badly wrong!
Oct 26 14:13:05 <kergoth> RP__: https://gist.github.com/3959034 - not sure i like it, but that's a first pass at the sync command error bits
Oct 26 14:14:44 <kergoth> RP__: erm, forgot to change the fatals to logger.error+return, but you get the idea
Oct 26 14:14:47 <kergoth> heh
Oct 26 14:15:54 <RP__> kergoth: yes, its an improvement on where we are now
Oct 26 14:17:08 <kergoth> k, i'll polish it up and adjust the other uis and send to the list
Oct 26 14:19:56 <RP__> kergoth: sounds good, thanks
Oct 26 14:20:10 <kergoth> np, thanks for the feedback
Oct 26 15:12:16 <kergoth> gah, the numer of runCommand calls in hobeventhandler.py is insane
Oct 26 15:12:29 * kergoth adjusts
Oct 26 15:15:46 <kergoth> ah, right, most are already wrapped by a method, good :)
Oct 26 15:16:05 <bluelightning> kergoth: there are a number of troubling things in that code, I hope we can clean it up for 1.4 - I have a todo list item to at least identify the issues
Oct 26 15:16:19 <kergoth> sounds good
Oct 26 15:17:12 <bluelightning> I'd like to abstract out as many of the OE references as possible, but for some cases that's going to be quite difficult...
Oct 26 16:28:14 <kergoth> Hmm, think I should dig into populate_sdk stuff to either exclude the cross-canadian toolchain from it entirely, or re-distribute the xternal toolchain, when using an external toolchain
Oct 26 17:26:41 <zyga> hi
Oct 26 17:27:05 <zyga> I'm trying to build the current yoto release for beagle board, I ran into a build issue with python-setuptools
Oct 26 17:27:54 <zyga> http://paste.ubuntu.com/1307670/
Oct 26 17:29:53 <zyga> build issue aside, should yocto not use distribute instead?
Oct 26 17:32:41 <mranostay> ?
Oct 26 18:13:37 <ftonello> anyone interested in a position for middleware/build system linux engineer in california? more information please, pvt
Oct 26 18:22:18 <kergoth> Hmm, there's quite a bit of duplicated content between our various UIs still. boilerplate around certain actions
Oct 26 18:27:43 <zyga> could anyone hint me on the correct component for python-setuptools build error?
Oct 26 18:45:25 <kergoth> damn, the hob 'checking build system setup' on this vm is taking forever
Oct 26 18:45:30 <kergoth> so much for 'this shouldn't take long' :)
Oct 26 18:51:44 <kergoth> seems stalled :\
Oct 26 18:57:40 * kergoth sighs
Oct 26 20:30:49 <kergoth> yeah, hob has been running its sanity check for about an hour and a half now
Oct 26 20:31:13 <sgw1> kergoth: oww yuck, is the networking check at startup?  We know about this issue!
Oct 26 20:31:26 <kergoth> hmm, not sure. think i'll punt and touch conf/sanity.conf fo rnow
Oct 26 20:32:52 <kergoth> ah, no, that wont' do it
Oct 26 20:32:56 * kergoth checks for networking
Oct 26 20:36:46 <kergoth> yeah, how exactly do i disable the hob sanity checks?
Oct 26 20:37:00 <kergoth> killing sanity.conf in oe-core seems to do squat
Oct 26 20:44:31 <sgw1> kergoth: sorry, not really familiar with that part.
Oct 26 20:45:44 <kergoth> hrm
Oct 26 20:52:42 <kergoth> finally. had to edit sanity.bbclass to force it to fire the network sanity and regular sanity successs events
Oct 26 20:52:51 <kergoth> otherwise the ui fires the test and waits for a completion that never arrives
Oct 26 20:52:55 * kergoth shakes head
Oct 26 20:54:34 <kergoth> gah, i just changed machines and it's rebuilding autoconf-native
Oct 26 20:54:40 * kergoth sighs
Oct 26 20:55:06 * kergoth tweaks
Oct 26 20:56:58 <kergoth> nevermind, spoke too soon on teh sanity check, still hanging
Oct 26 21:53:27 <ftonello> anyone interested in a position for middleware/build system linux engineer in california? more information please, pvt
Oct 26 22:12:23 <mranostay> heh this a job board now?
Oct 26 22:13:57 <thaytan> mranostay: recruiter spambots wanted, elsewhere. for more information foad?
**** ENDING LOGGING AT Sat Oct 27 03:00:01 2012

**** BEGIN LOGGING AT Sat Oct 27 03:00:02 2012
Oct 27 12:13:14 <JaMa> FYI: last floss weekly podcast was about baserock and they mentioned OE/yocto too, maybe someone should volunteer for interview about yocto http://twit.tv/show/floss-weekly/230
Oct 27 12:51:08 <bluelightning> JaMa: yes, we should definitely look at doing that
Oct 27 12:51:49 <bluelightning> watching it now... a few fair points but he's claiming that it takes days to build an image with our system... more than a slight exaggeration :/
Oct 27 12:53:16 <JaMa> true, that's why I wanted to mention that here
Oct 27 13:19:24 <Crofton|work> Yet another buildsystem promoting itself by making up problems with other build systems
Oct 27 13:22:29 <Crofton|work> also somewhat amused they started by targeting x86 :)
Oct 27 13:24:26 <bluelightning> Crofton|work: given they don't cross-compile they probably had no choice until their build box was ready
Oct 27 13:24:33 <Crofton|work> rofl
Oct 27 13:33:44 <Crofton|work> he really said days
Oct 27 13:33:55 <Crofton|work> obviously has no recent experience
Oct 27 13:35:26 <Crofton|work> they seem to be talking with the car people?
Oct 27 13:37:09 <Crofton|work> apparently they need an arm server
Oct 27 13:37:25 <Crofton|work> are you on G+?
Oct 27 13:53:52 <bluelightning> Crofton|work: I'm not on google+ no
Oct 27 13:56:36 <Crofton|work> If you sell custom hardware to run your embedded build system on, you are not an embedded developer.
Oct 27 13:58:52 <JaMa> :)
Oct 27 14:00:11 <Crofton|work> although, I think Intel likes OE because it drives demand for fast intel build hardware
Oct 27 14:02:01 <bluelightning> other build hardware is available ;)
Oct 27 14:04:43 <Crofton|work> true
Oct 27 14:05:41 <Crofton|work> did you ge to the part where they talk about building the arm server to run baserock on so they could support arm
Oct 27 14:06:58 <bluelightning> they've answered a few questions on it, not too much in-depth though
Oct 27 14:07:44 <Crofton|work> basically, it sounds like the typical native build problem
Oct 27 14:08:04 <Crofton|work> and their solution is sell arm servers
Oct 27 14:08:33 <Crofton|work> we should get an arm server and run oe on it
Oct 27 14:09:02 <bluelightning> I'm sure hrw will get his hands on some armv8 hardware at some point...
Oct 27 14:09:19 <bluelightning> (AArch64)
Oct 27 14:09:26 <Crofton|work> yeah
Oct 27 14:09:44 <Crofton|work> I should mention this to the ab that we seek such a thing for demonstration/testing
Oct 27 14:10:24 <Crofton|work> just to show we are not depenednent on x86 based build hardware
Oct 27 14:11:19 <bluelightning> is PPC big iron easy to get hold of these days?
Oct 27 14:12:24 <bluelightning> hmm, googling suggests perhaps not
Oct 27 14:16:36 <Crofton|work> hadn't thought of that
Oct 27 14:16:44 <Crofton|work> we should ask msm
Oct 27 14:23:55 <bluelightning> I think the biggest advantage we have is that you can get started and build something usable for any of a number of platforms more or less with whatever you already have
Oct 27 14:24:09 <Crofton|work> yep
Oct 27 14:24:16 <Crofton|work> and, it does not take days to build an image
Oct 27 14:24:17 <bluelightning> as long as you've got plenty of disk space free
Oct 27 14:24:30 <bluelightning> :)
Oct 27 14:24:48 <bluelightning> (well, 30G isn't that much these days)
Oct 27 16:08:58 <msm> you could probably build on a p4080ds in a resonable amount of time
Oct 27 16:09:19 <msm> Crofton: bluelightning: but we don't have access to big old POWER machines
**** ENDING LOGGING AT Sun Oct 28 03:00:02 2012

**** BEGIN LOGGING AT Sun Oct 28 03:00:03 2012
Oct 28 22:02:59 <walters> problem with categories: e2fsprogs is "devtools" ?
Oct 28 22:09:33 <bluelightning> walters: there are a few things in devtools that probably could be in some other category... I guess we could move them around without much penalty
Oct 28 22:10:06 <bluelightning> (apart from backports being made a little more difficult)
Oct 28 22:11:01 <walters> it's not really a big deal, just an observation =)
Oct 28 22:11:59 <walters> we faced perennial confusion in GNOME with: is Evolution in "Internet" or "Office"?
Oct 28 22:12:50 <bluelightning> indeed, it's hard to categorise things sometimes
Oct 28 23:16:06 <kergoth> whenever i try to find a recipe, i miss the old flat layout :) have to use find/ack every time
Oct 28 23:28:51 <bluelightning> I guess I already mentioned my web index idea
Oct 28 23:29:05 <bluelightning> hopefully we'll do that for 1.4
Oct 28 23:29:24 <bluelightning> s/do/implement/
Oct 28 23:33:58 <bluelightning> kergoth: you could always use bitbake-layers show-recipes -f <somename>
Oct 28 23:34:25 <kergoth> cool, didn't know about that option. clearly i'm out of date on bitbake-layers functionality :)
Oct 29 00:02:14 <kergoth> wtf
Oct 29 00:02:15 <kergoth> COMPATIBLE_MACHINE_$MACHINE = "$MACHINE"
Oct 29 00:02:19 <kergoth> is in a recipe in meta-fsl-ppc
Oct 29 00:02:21 <kergoth> this makes me sad
Oct 29 00:02:39 <kergoth> particularly since it doesn't actually do anything, since the reference in the variable name doesn't use bitbake variable syntax
Oct 29 00:02:42 * kergoth scratches head
Oct 29 00:03:47 <bluelightning> yocto-bsp script seems to be adding that
Oct 29 00:05:22 <bluelightning> if COMPATIBLE_MACHINE was invalid without being overridden then it would work, somewhat unorthodox though
Oct 29 00:05:48 <kergoth> it isn't using ${MACHINE}, it's using $MACHINE
Oct 29 00:05:55 <kergoth> won't expand to anything until it hits shell
Oct 29 00:07:08 <bluelightning> oh dear :(
Oct 29 02:42:52 <msm> kergoth: that compatible machine has been there for a long time, i think it was back when trying to use linux-yocto possibly and it's compatible machine was not compatible
**** ENDING LOGGING AT Mon Oct 29 03:00:01 2012

**** BEGIN LOGGING AT Mon Oct 29 03:00:01 2012
Oct 29 04:52:13 <mranostay> morning
Oct 29 04:52:23 <mranostay> well EST morning
Oct 29 09:11:50 <mckoan> good morning
Oct 29 09:26:03 <bluelightning> morning all
Oct 29 09:50:58 <mertsas> morning
Oct 29 17:57:52 <kos_tom> hello
Oct 29 17:58:12 <kos_tom> is it expected that the poky Git repository has no tag for the 8.0.0 release ?
Oct 29 17:59:18 <kos_tom> or maybe 1.3 is the tag ?
Oct 29 17:59:56 <bluelightning> kos_tom: 1.3 is the tag yes
Oct 29 18:01:09 <kergoth> what's 8.0.0?
Oct 29 18:01:47 <bluelightning> kergoth: poky has its own version scheme since the beginning
Oct 29 18:04:14 <kergoth> ahh
Oct 29 18:04:20 <kergoth> makes sense, thanks
Oct 29 18:08:57 <kos_tom> getting http://code.bulix.org/9kpg2w-82380?raw when starting a core-image-minimal build
Oct 29 18:10:58 <kos_tom> aah, might be /dev/shm missing.
Oct 29 18:11:20 <bluelightning> indeed, that's likely the issue
Oct 29 18:12:00 <bluelightning> kos_tom: are you running on an unusual distro?
Oct 29 18:13:10 <kos_tom> bluelightning: no, I'm running under Debian, but it's inside a chroot, so the environment might be a bit funky.
Oct 29 18:13:24 <bluelightning> ah, I see
Oct 29 18:23:36 <kos_tom> why does Poky builds stuff such as openssl-native, gdbm-native or apr-native, just to build core-image-minimal ?
Oct 29 18:25:28 <bluelightning> these are needed by some of the utilities we need as part of the buld process
Oct 29 18:25:41 <bluelightning> e.g. git / svn
Oct 29 18:26:05 <bluelightning> the reason we build these rather than relying upon the host is we have to be compatible with distros whose versions of such tools are too old
Oct 29 18:26:31 <bluelightning> in some cases we need to apply patches to certain tools, so the host versions are not suitable
Oct 29 18:27:13 <kergoth> kos_tom: missing a bind mount? i highly, highly recommend using schroot :)
Oct 29 18:27:23 <kos_tom> ok. Do you have a tool that draws the dependency graph or something that would help understand why so many things get fetched and built?
Oct 29 18:28:14 <bluelightning> kos_tom: absolutely, bitbake -g core-image-minimal will produce full dependency graphs
Oct 29 18:28:35 <bluelightning> kos_tom: they are quite large; too large for most tools to visualise so you need to look at them directly
Oct 29 18:29:14 <mranostay> bluelightning: or a huge monitor :)
Oct 29 18:29:34 <kergoth> someday it'd be cool to mark up the edges of the graph with *why/where* the dep came in/from
Oct 29 18:29:40 <kergoth> heh
Oct 29 18:31:05 <bluelightning> mranostay: unfortunately it's not that simple, there are multiple problems - running out of memory during image generation, layout being incomprehensible, or image being too large for most tools to handle
Oct 29 18:31:55 <kos_tom> and now, same question for ncurses or expat for the target? why for a minimal image ?
Oct 29 18:31:55 <bluelightning> I think we ought to look at bundling some tools to make sense of these graphs e.g. filtering
Oct 29 18:32:00 <kergoth> re: layout, you'd almost have to explore it in 3d or something. flattening it spreads everything out so much
Oct 29 18:32:04 <kergoth> heh
Oct 29 18:32:15 <kergoth> kos_tom: read the graph, or run bitbake -g -u depexp core-image-minimal
Oct 29 18:32:43 <bluelightning> kos_tom: often, tools have build-time requirements that end up being optional at runtime; we err on the side of enabling a lot of these but that does not mean those end up in the target image
Oct 29 18:33:06 <bluelightning> kos_tom: we do not customise recipe builds based on the image contents, that prevents the need to rebuild when you add packages to the image
Oct 29 18:34:38 <kos_tom> where does 'bitbake -g core-image-minimal' generate the graph?
Oct 29 18:35:06 <kos_tom> aah, it didn't run in fact, sorry.
Oct 29 18:35:20 <kos_tom> I have another bitbake running in the same directory, so cannot generate the dependency graph at the same time. Makes sense.
Oct 29 18:35:55 <kos_tom> bluelightning: on the other end, it makes the first build very long even though you won't need any of some things.
Oct 29 18:36:42 <walters> RP, doing a rebase on top of danny, i'm still hitting  https://lists.yoctoproject.org/pipermail/poky/2012-January/007421.html
Oct 29 18:36:53 <walters> i don't understand how you guys aren't hitting this when doing a full self-hosting rebuild
Oct 29 18:37:40 <walters> i wonder if a QA check to grep binaries for staging paths would be useful
Oct 29 18:38:15 <bluelightning> kos_tom: depends what you are doing. we set the system up for the general case but allow configuration; if you want to disable parts of it that is not too difficult
Oct 29 18:38:56 <kos_tom> now seeing alsa-lib-native. While I could understand apr-native or openssl-native for subversion/git, alsa-lib-native really doesn't make sense.
Oct 29 18:39:30 <kergoth> could be needed for qemu-native. just check the graph :)
Oct 29 18:40:24 <kos_tom> ok, I guess I need to stop asking questions and do a bit of homework first by reading the graph :)
Oct 29 18:42:26 <bluelightning> bbl
Oct 29 19:30:55 <msm> can anyone suggest a layer for libvirt?
Oct 29 19:32:16 <kergoth> msm: looks like it's in meta-xen, no other layers from layerindex
Oct 29 19:34:19 <kergoth> msm: https://gist.github.com/3975974
Oct 29 19:34:38 <msm> kergoth: ooooh
Oct 29 19:34:42 <msm> neat
Oct 29 19:34:52 <msm> maybe we need a meta-virt somewhere?
Oct 29 19:34:55 <kergoth> the html mangling isn't exactly pretty, but it gets the job done
Oct 29 19:39:30 <msm> kergoth: some of these repos are slow to clone
Oct 29 19:39:38 <kergoth> indeed
Oct 29 19:40:47 <kergoth> hmm, think we might need to keep udev 164 around a bit longer, don't think all our bsps are on new enough kernels with devtmpfs enabled
Oct 29 19:40:50 * kergoth adds to todo
Oct 29 19:41:05 <kergoth> (where 'we' is mentor, naturally, not yocto)
Oct 29 20:12:45 * kergoth thinks about populate_sdk vs external toolchain
Oct 29 21:02:53 <seebs> kergoth, do you have any idea what the function of the sed operations on libc.so/libpthread.so in external-sourcery-toolchain is? I ask because they actually caused us occasional failures, and we took them out, and nothing's gone wrong that I know of.
Oct 29 21:04:09 <seebs> I'm looking at all this more closely because I'm trying to update our branch of this to let it optionally rebuild glibc from source instead of using the prebuilts.
Oct 29 21:04:23 <seebs> Well, I'm intending to try. Right now I'm staring at all the bits and trying to figure out when this code runs and why. :)
Oct 29 21:09:06 <kergoth> seebs: i can't recall. I think perhaps certain versions had absolute paths there, resulting in links to the bits on the host
Oct 29 21:09:27 <seebs> Well, that's the thing. The prebuilt binaries do have absolute paths by default. These work, because they're sysroot-relative.
Oct 29 21:09:58 <seebs> The ../.. names actually DO pick up host directories in rare cases (but only really if you end up with the compiler being invoked from a directory that's /a/b from root, usually).
Oct 29 21:11:52 <kergoth> ah, i see. okay, then those lines absolutely should go away, since it makes it escape the sysroot
Oct 29 21:12:08 <kergoth> unless there was some other reason for them, but i can't think of anything
Oct 29 21:12:21 <seebs> Yeah. I believe I went back through the git history to see, and they just showed up as part of one of the checkins, with no specific comments. Was 3-4 years ago.
Oct 29 21:12:57 <seebs> I'm currently trying to figure out whether some of the stuff in the external-foo-toolchain.bb should really be in external-foo-toolchain-cross.bb, because it looks like some of it is really finishing up target setup stuff.
Oct 29 21:13:02 <seebs> Er, host setup stuff, I mean.
Oct 29 21:13:49 <seebs> We have both -cross and -cross-canadian recipes in ours now.
Oct 29 22:09:11 <mranostay> for an x86 build is parted only used for native side image creation?
Oct 29 22:10:08 <mranostay> i want to confirm before adding an incompatible license override
Oct 29 23:27:49 <agherzan> Hello.
Oct 29 23:27:59 <agherzan> Anybody around who can help me with with hob?
Oct 29 23:28:22 <agherzan> Is there any way i can get a variable from machine.conf in hob?
**** ENDING LOGGING AT Tue Oct 30 02:59:57 2012

**** BEGIN LOGGING AT Tue Oct 30 02:59:58 2012
Oct 30 09:20:13 <mckoan> good morning
Oct 30 14:59:50 <bluelightning> YPTM: Paul Eggleton is on the call
Oct 30 14:59:55 <Song_Liu> YPTM: Welcome to the Yocto Project technical team meeting everyone, please let me know who's on the bridge
Oct 30 15:00:00 <strassek> YPTM: Kevin Strasser is on the call
Oct 30 15:00:10 <bogdanm> YPTM: Bogdan Marinescu is on the bridge
Oct 30 15:00:19 * mihai Lindner joined
Oct 30 15:00:23 * nitink YPTM: nitin is on the bridge
Oct 30 15:00:25 <tomz2> YPTM: Tom Z here
Oct 30 15:00:45 <zenlinux> YPTM: Scott Garman is here
Oct 30 15:01:21 <jmpdelos> YPTM: Jeff P here
Oct 30 15:01:48 <rburton> YPTM: Ross here
Oct 30 15:01:52 <fray> YPTM: Mark H in
Oct 30 15:02:02 <sgw1> YTPM: Saul is with Alex in Romania
Oct 30 15:02:10 * rburton curses timezone changes, only just realised it was now
Oct 30 15:02:12 <zeeblex> AlexP here
Oct 30 15:02:13 <scottrif> YPTM:  Scott rifenbark joined the call
Oct 30 15:02:17 <bramming> Brian Ramming here
Oct 30 15:02:30 <kergoth> YPTM: Chris Larson here
Oct 30 15:02:57 <zeddii> YPTM: Bruce Ashfield here.
Oct 30 15:03:20 * zeddii just made it with a second to spare ;)
Oct 30 15:03:24 <mihai> Song, i'm here also :)
Oct 30 15:04:02 <Song_Liu> YPTM: Any opens?
Oct 30 15:04:04 <zenlinux> Song_Liu, 1.2.2 release status
Oct 30 15:04:11 <fray> YPTM: RPM and SMART -- RFC was sent to the list
Oct 30 15:04:17 <fray> (replacing Zypper)
Oct 30 15:04:26 <cristianiorga> YPTM: Cristian Iorga is on the call
Oct 30 15:05:14 * sgw1 pull requests over the next week or so
Oct 30 15:06:50 * sgw1 hung up instead of unmuted
Oct 30 15:06:56 <zeeblex> :))
Oct 30 15:07:07 <sgw1> Song_Liu: Please check the schedule at the end of the year M2 is at a bad time!
Oct 30 15:10:03 <mihai> YPTM: Song_Liu: any links to share? :D
Oct 30 15:14:38 <jzhang> YPTM:  jzhang's here
Oct 30 15:16:41 <rburton> YUM?!
Oct 30 15:16:44 <zeddii> did the call just end ?
Oct 30 15:16:46 <zeddii> hmmm.
Oct 30 15:16:51 <zeddii> my phone is dead.
Oct 30 15:16:52 <bluelightning> zeddii: still going...
Oct 30 15:16:54 <zeddii> how interesting.
Oct 30 15:17:03 <zeddii> fray, was talking and then .. silence.
Oct 30 15:17:10 * zeddii looks out the window for a hurricane.
Oct 30 15:17:15 <sgw1> zeddii: mark must of out SMARTed you.
Oct 30 15:17:15 <rburton> zeddii: we all heard a drop
Oct 30 15:17:38 <zeddii> I was just minding my own business and listening. I hope the pbx isn't busted .. again.
Oct 30 15:17:41 * zeddii tries to redial.
Oct 30 15:17:52 <fray> hahah..  wasn't me for once..
Oct 30 15:18:50 <zeddii> yep. that was me.
Oct 30 15:19:00 <Zagor> oh darn, foiled by the winter time shift again
Oct 30 15:22:47 <evadeflow> David Wolfe of Magneti Marelli here (finally)
Oct 30 15:26:11 * rburton wishes irc was less rubbish
Oct 30 15:26:26 * sgw1 sez congrats to all!
Oct 30 15:28:04 <Zagor> Song_Liu: Björn Stenberg from Enea connected now
Oct 30 15:28:23 <sgw1> Zagor: do you want to talk about package testing?
Oct 30 15:28:58 <Zagor> sgw1: I don't have anything concrete to discuss at the moment. it's probably best done on the list(s).
Oct 30 15:29:10 <Zagor> unless you have questions?
Oct 30 15:29:33 <sgw1> Zagor: ok, just chceking, no not at this time.  We are just looking forward to see a rebased/updated patchset to play with
Oct 30 15:30:17 <Song_Liu> YPTM: https://www.google.com/calendar/embed?height=600&wkst=1&bgcolor=%23FFFFFF&src=mg0m150m30gs891eqqhtfu5jgg%40group.calendar.google.com&color=%238C500B&src=sc7rov4ck552t2f0pav120t7r0%40group.calendar.google.com&color=%23528800&src=theyoctoproject%40gmail.com&color=%23182C57&ctz=America%2FLos_Angeles
Oct 30 15:30:22 <Zagor> sgw1: yeah. getting closer :)
Oct 30 15:33:05 <rburton> Zagor: glib-2.0  has a good automated test suite, i'd love to see that in ptest :)
Oct 30 15:33:30 <zeeblex> Song: Thanks for the link :)
Oct 30 15:34:37 <Zagor> rburton: yes, the glib test are integrated
Oct 30 15:35:01 <rburton> Zagor: *sweet*. is this work in a branch i can see?
Oct 30 15:35:44 <Zagor> rburton: not yet, unfortunately. I hope to get time to publish some parts Real Soon Now.
Oct 30 15:35:52 <rburton> Zagor: looking forward to it
Oct 30 15:36:16 <rburton> Zagor: i think you'd get a medal if you made the dbus test suite work in ptest
Oct 30 15:37:01 * jackmitchell already despises g_varient
Oct 30 15:37:13 <rburton> jackmitchell: awwww
Oct 30 15:37:27 <jackmitchell> rburton: after only one afternoon!
Oct 30 15:37:29 <rburton> jackmitchell: haha
Oct 30 15:37:44 <rburton> jackmitchell: it's not raw libdbus, so you're winning
Oct 30 15:37:54 <Zagor> rburton: we have it running, but it's not terribly elegant at the moment
Oct 30 15:38:08 <rburton> Zagor: i bet, but that's great news
Oct 30 15:38:25 <Zagor> chief ugliness is do_install is 30+ lines of cp and sed :-)
Oct 30 15:38:26 <jackmitchell> rburton: I have managed to start (baby) talking to connman, so it's not all pain over here
Oct 30 15:38:47 <rburton> jackmitchell: considered something higher-level than C? :)
Oct 30 15:39:13 <jackmitchell> rburton: possibly, but I've already written the majority of my application in C
Oct 30 15:39:43 <jackmitchell> rburton: I almost started with C++ but I have zero experience with it, so decided against it
Oct 30 15:40:16 <rburton> jackmitchell: that would probably be a bad move, yeah
Oct 30 15:40:38 <rburton> jackmitchell: i've written a few connman UIs if you get confused
Oct 30 15:40:53 <jackmitchell> rburton: are they in the new GDBus format?
Oct 30 15:41:21 <rburton> jackmitchell: no, they used dbus-glib or a home-grown node-dbus library
Oct 30 15:42:00 <rburton> jackmitchell: my main advise is to use dfeet to find out what the dbus prototypes actually are, as the docs are a bit lame with their pseudo-IDL
Oct 30 15:42:40 * zeddii has to drop the call.
Oct 30 15:43:01 * mckoan is testing danny core-image-minimal on atom-pc
Oct 30 15:43:23 <jackmitchell> rburton: ok, cheers - I may nag you later on the process if I get particularly stuck!
Oct 30 15:44:36 <rburton> np
Oct 30 15:45:43 <zeeblex> we're gonna upload small videos?
Oct 30 15:45:52 <mihai> screen-casts :))
Oct 30 15:46:03 <evadeflow> #Caturday
Oct 30 15:46:05 <mihai> even yocto images
Oct 30 15:46:24 <mihai> YPTM: bye all
Oct 30 15:46:28 <zeeblex> bye
Oct 30 15:46:50 <Song_Liu> YPTM: thank you all for joining the meeting. Have a nice day or evening!
Oct 30 15:47:08 <evadeflow> Bye, all...
Oct 30 15:53:11 <mckoan> core-image-minimal on atom-pc works smoothly
Oct 30 15:53:49 <mckoan> unfortunately bitbake core-image-sato fails so I have no chance to see something graphic :-(
Oct 30 15:54:42 <bluelightning> mckoan: fails how?
Oct 30 15:56:27 <mckoan> bluelightning: Im resoving it, a stupid No space left on device :-|
Oct 30 15:56:44 <bluelightning> ah, right
Oct 30 15:57:25 <mckoan> bluelightning: I have a couple of OE and 4/5 different yocto build on my poor 500GB HD
Oct 30 15:58:12 <mckoan> I always forget to clean after a test
Oct 30 15:59:19 <mckoan> maybe a df -h in the bitbake header message may be useful ;-)
Oct 30 16:00:35 <mckoan> bluelightning: BTW are you going to ELCE ?
Oct 30 16:03:11 <bluelightning> mckoan: there's a disk space monitoring feature now in current bitbake but it's not enabled by default
Oct 30 16:03:21 <bluelightning> mckoan: I am yes, are you?
Oct 30 16:07:26 <mckoan> bluelightning: yes I am too
Oct 30 16:07:35 <bluelightning> awesome :)
Oct 30 16:07:59 <mckoan> bluelightning: is the disk space monitoring feature activated with any flag?
Oct 30 16:08:24 <mckoan> flag = keyword
Oct 30 16:10:06 <bluelightning> mckoan: some more info here: http://cgit.openembedded.org/bitbake/commit/?id=4d173d441d2beb8e6492b6b1842682f8cf32e6cc
Oct 30 16:12:46 <mckoan> bluelightning: thx
Oct 30 16:25:10 <allanx> (on denzil) is it possible to create a native SDK which includes e.g. device nodes in the target sysroot? so the sysroot used to compile against can also be booted via NFS?
Oct 30 16:40:17 <kergoth> sigh, changed a couple SDK variables and now nativesdk-eglibc is rebuilding?
Oct 30 16:40:47 * kergoth checks which one did it
Oct 30 17:00:24 <mckoan> have a nice rest of the day
Oct 30 17:58:47 <b1gtuna> Goood morning everybody! Is there a quick and easy way to delete all build logs?
Oct 30 17:59:00 <b1gtuna> such as cooker.log and buildstats?
Oct 30 18:00:48 <kergoth> why?
Oct 30 18:01:03 <pidge> b1gtuna: for buildstats just rm $TMPDIR/buildstats
Oct 30 18:02:43 <b1gtuna> kergoth: hmm i get too many of them when i am testing my images =(
Oct 30 18:03:02 <b1gtuna> pidge: i see. i was sort of hoping to bitbake -ccleanlog or something like that
Oct 30 18:03:50 <pidge> b1gtuna: Not that I know of. But, I guess I second kergoth. Why do you need to rm them?
Oct 30 18:04:31 <b1gtuna> pidge: i just want to keep my build dir tidy, nothing major
Oct 30 18:04:59 <kergoth> there's a ton of other temporary stuff in your temp directory
Oct 30 18:05:08 <kergoth> those two are just small parts of that
Oct 30 18:05:12 <b1gtuna> yup that's true too
Oct 30 18:05:31 <b1gtuna> so i guess you guys just keep them?
Oct 30 18:05:32 <pidge> b1gtuna: ah, ok. Yeah, rm-ing the buildstats dir shouldn't cause any issues. I'd just watch what you rm in TMPDIR.
Oct 30 18:05:41 <kergoth> if you really want to start fresh, move bits you need (e.g. deploy/images) out of tmpdir, and wipe tmpdir
Oct 30 18:05:49 <kergoth> disk space is cheap.
Oct 30 18:05:51 <b1gtuna> pidge: ya i'd be careful to remove TMPDIR too
Oct 30 18:05:53 <kergoth> and sstate is lovely
Oct 30 18:05:56 <kergoth> why?
Oct 30 18:06:16 <b1gtuna> kergoth: isn't that where my sources and binarys reside?
Oct 30 18:06:36 <b1gtuna> kergoth: i just want the logs to be gone, not the downloaded packages
Oct 30 18:06:39 <kergoth> output is in tmp/deploy/, which i already explained you can pull out. i'd suggest pointing DL_DIR and SSTATE_DIR out of tmpdir
Oct 30 18:06:59 * pidge seconds kergoth's suggestion.
Oct 30 18:07:09 <b1gtuna> kergoth: that's a good idea. will do that
Oct 30 18:07:16 <b1gtuna> thanks pidge and kergoth
Oct 30 18:07:39 <pidge> b1gtune: yw
Oct 30 19:02:29 <dvhart> zeddii, poke
Oct 30 20:56:54 <evanp> if two (related) recipes are using shared-work, what keeps (for example) their do_unpack steps from executing concurrently (assuming high enough BB_NUMBER_THREADS)? Is there somehow only actually _one_ unpack step?
Oct 30 21:02:46 <kergoth> they share a common stamps directory, so only one gets run, yes
Oct 30 21:02:54 <kergoth> see line 63 of gcc-common.inc
Oct 30 21:15:28 <evanp> kergoth: how does that work, exactly? does bitbake stuff all tasks into a dictionary keyed with their stamp, so identical stamps get implicitly collapsed (or something functionally equivalent)? or do identical stamps cause tasks to use identical lockfiles at runtime?
Oct 30 22:35:29 <kergoth> hmm, the use of CONFIGURE_FLAGS isn't working as expected
Oct 30 22:35:57 <kergoth> i have to unexport it, then run eval ./configure $CONFIGURE_FLAGS. if i export it, configure fails to pick up that we're crosscompiling, acting like --host wasn't passed, even though it did show it in config.log wheere it shows the arguments
Oct 30 22:36:07 <kergoth> (context: populate_sdk)
Oct 30 22:41:48 <kergoth> ah, think it's working now..
**** ENDING LOGGING AT Wed Oct 31 02:59:58 2012

**** BEGIN LOGGING AT Wed Oct 31 02:59:58 2012
Oct 31 03:37:02 <denix> what's the right way to escape ${VAR} to prevent bitbake from expanding it?
Oct 31 08:10:15 <mckoan> good morning
Oct 31 08:15:37 <bluelightning> morning mckoan, all
Oct 31 11:02:28 <aggurio> Morning, thinking of buying a supported yocto reference design (hardware), recommendation?
Oct 31 11:04:28 <mckoan> aggurio: the less painful are here http://www.yoctoproject.org/documentation/hardware-support
Oct 31 11:05:32 <aggurio> Thanks mckoan, will have a look
Oct 31 11:07:52 <mckoan> aggurio: aldo ISEE http://www.isee.biz/component/zoo/item/igep-yocto-toolcahin-sdk
Oct 31 12:20:30 <rburton> mckoan: does that sdk come with the gpu drivers?
Oct 31 12:41:00 <Guest14216> morning
Oct 31 13:33:15 <mckoan> rburton: actually I don't know
Oct 31 13:41:10 <mckoan> bluelightning: core-image-sato works on Asus eeePC ;-)
Oct 31 13:41:33 <bluelightning> mckoan: indeed, I've also used it on the eeeeeee :)
Oct 31 13:41:48 <mckoan> I was not so lucky with Mini-ITX N270 neither D2250
Oct 31 13:42:07 <mckoan> with 945GSE and NM10
Oct 31 13:42:23 <mckoan> what a pity!
Oct 31 13:44:55 <bluelightning> mckoan: what happened on those machines?
Oct 31 13:53:52 <Zagor> is there already a mechanism for building more than one kernel in an image? or rather more than one kernel configuration. such as "debug" and "release"
Oct 31 14:00:28 <mckoan> bluelightning: xorg problems with dri
Oct 31 14:01:17 <mckoan> I tried to change xorg settings without success
Oct 31 14:01:22 <bluelightning> mckoan: I don't think we necessarily have drivers for every atom-based platform...
Oct 31 14:01:35 <mckoan> bluelightning: of course
Oct 31 14:01:45 <bluelightning> not within the atom-pc machine config, I mean
Oct 31 14:02:13 <mckoan> but a VESA generic platform would be a great bump to yocto adoption
Oct 31 14:02:40 <bluelightning> I thought it was supposed to fall back to vesa already
Oct 31 14:03:23 <bluelightning> Zagor: not out of the box, no
Oct 31 14:04:42 <ant_work> Zagor: in oe-classic there was recipes/linux/multi-kernel.inc but you could have as well built another image
Oct 31 14:04:47 <ant_work> http://permalink.gmane.org/gmane.comp.handhelds.openembedded/37503
Oct 31 14:05:10 <Zagor> bluelightning: ok. we have written a bbappend that uses a second set of KERNEL_FEATURES for a second build of the same kernel.
Oct 31 14:05:35 <bluelightning> Zagor: presumably you are packaging the two kernels separately?
Oct 31 14:07:01 <Zagor> bluelightning: not in this case. we're simply adding/installing a second binary to the recipe. it's rather ad-hoc... :-)
Oct 31 14:07:31 <bluelightning> Zagor: ah, ok... that would avoid a bunch of issues
Oct 31 14:07:47 <Zagor> that's why I wondered if this was solved already
Oct 31 14:09:19 <Zagor> ant_work: that looks interesting. thanks.
Oct 31 15:57:16 <fray> unset PSEUDO_UNLOAD
Oct 31 15:57:22 <fray> unset PSEUDO_DISABLED
Oct 31 15:57:24 <fray> oops
Oct 31 16:00:07 <zeddii> fray: YOU'VE KILLED FREENODE
Oct 31 16:00:16 <fray> 'er?
Oct 31 16:00:23 <zeddii> you unloaded pseudo.
Oct 31 16:00:26 <fray> ah
Oct 31 16:07:26 <fray> hey it kind of worked.. but there is a problem
Oct 31 16:07:31 <fray> damnit.. wrong channel again
Oct 31 19:23:39 <gebi> hi all :)
Oct 31 20:16:14 <msm> is yocto-docs repo equivalent to the docs in poky?
Oct 31 20:17:14 <msm> seems to be the case
Oct 31 20:18:40 <mranostay> so is the Yocto Day thursday at E-ELC?
Oct 31 20:19:10 <gebi> how is the future way of systemd in yocot? from the bug reports i could find it doesn't seem to be set in stone what well be done
Oct 31 20:19:37 <walters> are there any flamewars to read?
Oct 31 20:28:54 <gebi> walters: no, not yet *g*
Oct 31 20:29:07 <gebi> s/well/will/
Oct 31 20:44:05 <fray> mranostay Yocto Project Dev Day is Thursday -- all day
Oct 31 20:44:36 <fray> starts 9am and goes to 19:30
Oct 31 20:44:54 <fray> last two hours are a wrap-up and reception
Oct 31 20:45:18 <Crofton|work> w00t reception!
Oct 31 20:45:33 <fray> Join the entire Yocto Project team for feedback and refreshments. Beer, wine, and hors d'oeuvres provided.
Oct 31 20:45:37 <fray> according to the schedule I have.. ;)
Oct 31 20:51:48 <mranostay> hmm do_bootdirectdisk errors out with "disk full"
**** ENDING LOGGING AT Thu Nov 01 02:59:58 2012

**** BEGIN LOGGING AT Thu Nov 01 02:59:58 2012
Nov 01 10:09:57 <bluelightning> morning all
Nov 01 13:56:44 <walters> rburton: fyi: https://mail.gnome.org/archives/gnome-os-list/2012-November/msg00000.html
Nov 01 13:59:05 <walters> rburton: if you have a bit of time, there are two patches to core i still have outstanding that need a bit of massaging/testing but i'd like to get upstream
Nov 01 13:59:13 <walters> https://github.com/cgwalters/poky/commit/43040b65e78db14f52119024622bd74fe81cae4d
Nov 01 13:59:14 <walters> and https://github.com/cgwalters/poky/commit/0d582f6d0dd1ce99efddbcc17ae7f7570fb8410e
Nov 01 13:59:43 <walters> the first one you may not notice, but the gnulib getcwd() fallback is *slow* - it calls stat() on each parent!
Nov 01 14:05:04 <kergoth> so the BISON_PKGDATADIR bit isn't needed anymore? you remove that from the wrapper also, and that isn't mentioned in the commit message that i can see
Nov 01 14:05:09 * kergoth yawns
Nov 01 15:26:07 <msm> has anyone seen this error (on denzil): https://gist.github.com/3994314
Nov 01 15:26:13 <msm> it's *very* rare
Nov 01 15:39:42 <bluelightning> msm: kergoth: looks like this might be the bitbake command return issue...
Nov 01 15:40:04 <bluelightning> in this case the code expects a dict, but a string is being returned
Nov 01 15:41:10 <kergoth> looks like it, yeah
Nov 01 15:41:42 <bluelightning> kergoth: did you have any luck figuring it out by any chance?
Nov 01 15:41:47 <ka6sox> I ran into that last night
Nov 01 15:41:56 <kergoth> msm: a bitbake bug is concealing the real problem. command.py is returning a failure to issue the command, but the uis don't handle it, so you never see the error message
Nov 01 15:42:18 <ka6sox> http://jenkins.nas-admin.org/job/webos-ports_setup_webos-dev-image_qemux86/31/console
Nov 01 15:43:01 <kergoth> i emailed a patch to the list, but oddly it doesn't look like it made it, though i got no bounce or hold message.. hmm
Nov 01 15:44:52 <kergoth> or, if it did, it didnt get picked up by patchwork
Nov 01 15:45:14 <kergoth> apparently gmane never got updated for the new bitbake list, so can't check that
Nov 01 15:45:14 <ka6sox> let me see if patchwork is hung
Nov 01 15:45:44 <kergoth> the patch is 'command: add error to return of runCommand', which at least fixes the bug that was hiding teh other bug, so we can see what's really failing when this crops up
Nov 01 15:45:50 * kergoth gets caffeine
Nov 01 15:50:39 <kergoth> there it is, https://github.com/kergoth/bitbake/compare/runcommand-error
Nov 01 15:50:47 <kergoth> i'll resend to the list a bit later
Nov 01 15:51:13 <bluelightning> kergoth: thanks
Nov 01 15:56:27 <kergoth> oh, i see richard got there ahead of me, it's merged
Nov 01 15:56:30 * kergoth chuckles
Nov 01 15:58:33 <bluelightning> ah, right... heh...
Nov 01 15:58:37 * ka6sox waits for the real bug to reveal itself.
Nov 01 16:00:13 <kergoth> ka6sox: I don't think I've ever seen this happena nywhere but the automated builds, but that could just be due to the # of them occuring :)
Nov 01 16:00:19 * kergoth will wait and see also
Nov 01 16:01:12 <ka6sox> thanks...the automated builds are quite helpful for rooting out issues.
Nov 01 16:02:40 <ka6sox> (and breaking things)
Nov 01 16:03:05 <kergoth> indeed
Nov 01 16:06:23 <msm> kergoth: there is a patch?
Nov 01 16:09:14 <kergoth> msm: the latest commit on bitbake master, and the above bitbake branch
Nov 01 16:18:51 <msm> http://cgit.openembedded.org/bitbake/commit/?id=717831b8315cb3904d9b590e633000bc897e8fb6
Nov 01 16:18:56 <msm> what bitbake branch?
Nov 01 16:20:49 <kergoth> ?
Nov 01 16:21:07 <kergoth> that page says exactly what branches it's the tip of. i'm not sure what else you want to know
Nov 01 16:21:07 <ka6sox> updated...lets see where it takes us to.
Nov 01 16:22:34 <msm> kergoth: i was just confused by the mention of branch in the first place, it's really just the one commit you are talking about?
Nov 01 16:22:53 <kergoth> as i said, it's the commit that's the tip of the master branch
Nov 01 16:22:56 <kergoth> one commit, yes
Nov 01 16:23:32 <msm> k thanks
Nov 01 16:34:29 <fray> kergoth, are you going to Barcelona? (ELC-E)?
Nov 01 16:39:35 <kergoth> sadly not this time around, didn't get it arranged with work in time
Nov 01 16:47:17 <msm> kergoth: backported to denzil here: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=mattsm/denzil&id=3f44f22868c0203649bc5a6fd7a52a5a9926b7a4
Nov 01 16:47:21 <msm> doing more testing now
Nov 01 16:48:44 <kergoth> cool. here's hoping you manage to hit the issue again, so we can try to dig into what's really going on
Nov 01 18:02:06 <msm> kergoth: might take a few weeks
Nov 01 18:02:52 * kergoth nods, we haven't seen it often either
Nov 01 18:03:11 <fred23> Hi guys, I'm now maintaining xoo, which is part of the yocto project.
Nov 01 18:03:27 <fred23> I'd like to update a new source release tarball and was wondering how ?
Nov 01 18:04:01 <fred23> should I just get myself subscribed to yocto and ask for upload access to http://downloads.yoctoproject.org/releases/xoo/   ??
Nov 01 18:04:02 <fred23> thanks a lot
Nov 01 18:23:45 <msm> rburton: zenlinux: I sort of screwed up CC'ing you guys and the subject on the danny patch… but i sent a patch to the poky ML for a denzil/danny backport
Nov 01 18:23:58 <msm> its against bitbake, so it seemed not to belong on oe-core
Nov 01 18:24:42 <hollisb> what's the difference between Denzil and Danny, anyways? I thought 1.3 was going to be Denzil, then suddenly it was called Danny
Nov 01 18:25:41 <zenlinux> hollisb, no, 1.2 is Denzil, 1.3 is Danny, and 1.4 will be named close to when it gets released
Nov 01 18:25:49 <hollisb> ahh
Nov 01 18:25:51 <hollisb> my mistake
Nov 01 18:26:42 <zenlinux> msm, bitbake patches can send to the bitbake-devel ML - same rules, mention stable releases in the subject line and I'll catch them
Nov 01 18:26:55 <hollisb> why name them at all then? :) usually codenames are used during development, so nobody needs to settle on a marketing version number until release
Nov 01 18:27:44 <msm> zenlinux: it looks like RP even just sent an email 12 hours ago talking about this
Nov 01 18:28:17 <zenlinux> I guess we find codenames are more user-friendly for users to refer to. RP also likes to make it hard for people to guess what the release names refer to (it's a common theme), so he likes to make them known as late as possible. :)
Nov 01 18:28:40 <msm> zenlinux: the annoying thing here is I don't have to use bitbake directly… ;/
Nov 01 18:29:02 <msm> is there a way to stripout a patch level when making a patch from poky?
Nov 01 18:29:38 <zenlinux> not sure what you mean by that "stripout a patch level"
Nov 01 18:34:47 <kergoth> msm: just use -p 2 when you apply it to bitbake, or —directory=bitbake when going the other direction
Nov 01 18:34:56 * zenlinux goes foraging for food
Nov 01 18:35:08 <kergoth> those args work for either git am or git apply
Nov 01 18:36:31 <msm> kergoth: heh, i recall this… would be nice to do that from git send-email ;)
Nov 01 18:37:08 <kergoth> just clone bitbake, apply it there, and send-email from the bitbake repo
Nov 01 18:37:21 <kergoth> but i'm not sure what the difficulty is here
Nov 01 18:37:27 <kergoth> the commit is already in the bitbake repo on the master branch
Nov 01 18:37:36 <kergoth> clone it, checkout the stable branch, cherry pick master, send email
Nov 01 18:39:44 <msm> kergoth: denzil required a few changes… but not much effort you are correct
Nov 01 18:55:00 <msm> is there even a stable branch for bitbake for denzil?
Nov 01 19:09:53 <mranostay> so tell again why i cannot extend a bbclass?
Nov 01 19:10:14 <mranostay> er append
Nov 01 19:12:30 <fray> you are expected to replace it (with your own from your own layer) --or-- add functionality by inheriting your own extension bbclass
Nov 01 19:12:42 <fray> so you -can- extend it, just not using bbappend
Nov 01 19:13:30 <fray> INHERIT += "myextension.bbclass"
Nov 01 19:54:50 <mranostay> fray: priority levels work for the classes as well?
Nov 01 19:56:06 <mranostay> ah order  of the layers in the conf file
Nov 01 21:00:47 <kergoth> so, I'm building with danny, using package_rpm, and the lttng2-ust rpm doesn't list the libraries it includes in its provides (according to -qp filename —provides, anyway), so lttng-tools fails to find its liblttng-ust-ctl.so.0 requirement
Nov 01 21:00:53 <kergoth> anyone seen this sort of thing?
Nov 01 21:01:11 <kergoth> the libraries are in the package, maybe something is wrong with the library files.. except, then it should have failed to build lttng-tools..
Nov 01 21:09:17 <kergoth> If i run bitbake -C package lttng2-ust, the recreated rpm will have the correct —provides
Nov 01 21:09:39 <kergoth> so it seems to be some sort of intermittent flaw in the rpm packaging, or a race of some sort
**** ENDING LOGGING AT Fri Nov 02 03:00:00 2012

**** BEGIN LOGGING AT Fri Nov 02 03:00:00 2012
Nov 02 08:19:49 <mckoan> good morning
Nov 02 08:50:10 <Zagor> is anyone working on adding config fragments to busybox? I found a mail question from may, but nothing further
Nov 02 09:20:17 <bluelightning> morning all
Nov 02 09:22:57 <Zagor> bluelightning: do you know if anyone is looking into adding config fragments to busybox? all I can find is a mail question from this spring
Nov 02 09:25:50 <bluelightning> Zagor: hmm, I definitely recall it being discussed a number of times but I'm not sure if anyone's actively looking at it and there doesn't appear to be anything in bugzilla
Nov 02 09:25:59 <bluelightning> I'll file a bugzilla entry now actually
Nov 02 09:29:27 <bluelightning> Zagor: done, bug 3379
Nov 02 09:29:36 <Zagor> excellent
Nov 02 10:57:13 <RP> Zagor: I don't think anyone has stepped up to work on that
Nov 02 10:57:27 <RP> Zagor: I think there is general agreement its  a good idea
Nov 02 11:05:59 <Noor> hi all
Nov 02 11:07:14 <Noor> there is a systemd layer in yocto and another one also exist in meta-oe as well https://github.com/openembedded/meta-oe/tree/master/meta-systemd
Nov 02 11:07:29 <Noor> can any body tell which is the better
Nov 02 11:35:54 <bluelightning> Noor: the meta-oe one is the preferred one
Nov 02 11:37:13 <Noor> bluelightning: thanks ... isn't it better to have one one thing out there
Nov 02 11:40:17 <bluelightning> Noor: I agree... I think there was some parallel development going on for a time
Nov 02 11:40:36 <bluelightning> the one on git.yoctoproject.org is clearly marked as deprecated
Nov 02 11:45:00 <Noor> ahhh Deprecated is written so small that it can easily be ignored :)
Nov 02 11:45:09 <Noor> thanks bluelightning
Nov 02 12:03:29 <erbo> How can I create a list of the packages in an image? I think I recall being able to do that using OE a couple of years ago
Nov 02 12:03:56 <erbo> (at the time of creation)
Nov 02 12:04:33 <bluelightning> erbo: enable buildhistory: https://wiki.yoctoproject.org/wiki/Buildhistory
Nov 02 12:06:31 <erbo> bluelightning: perfect, thank you!
Nov 02 12:08:07 <bluelightning> np
Nov 02 16:17:01 <mckoan> see you at ELCE
Nov 02 17:56:34 <mranostay> so any reason a initrd wouldn't be included in a hdddirect image?
Nov 02 22:23:49 <yocto644> Guys i am trying to see if there is a bitbake for libxcb_iccm?
Nov 02 22:24:11 <yocto644> i dont find any thing inside recipes-graphics
Nov 02 22:24:19 <yocto644> related to that
Nov 02 22:24:47 <yocto644> any idea if there is a package/bitbake for libxcb_iccm in oe-core?
Nov 02 22:38:27 <kergoth> i'd say try the 'find' command, or 'grep'
Nov 02 22:39:53 <yocto644> i di that before trying here
Nov 02 22:43:00 <kergoth> then you have your answer
Nov 02 22:55:02 <yocto644> :)
Nov 02 23:04:44 <mranostay> kergoth: friday? :)
Nov 03 00:53:49 <seebs> So, I know there's probably not a lot of on-target pseudo usage going on, but I'm curious: Has anyone tried it on 64-bit systems?
Nov 03 00:53:50 <ftonello> why cant I build valgrind for arm?!
Nov 03 00:54:23 <seebs> I ask because so far as I can tell, the --enable-static-sqlite feature has always been broken for 64-bit systems. Which is obviously not the case since it runs okay on hosts, but it does indeed blow up for me on 64-bit targets.
Nov 03 00:54:35 <seebs> (And it seems the issue may be: The 64-bit host I'm on has /usr/lib -> lib64.)
Nov 03 00:55:19 <seebs> ftonello: I don't know. At least some recentish valgrind claims to have "fairly complete" support for armv7.
Nov 03 00:58:50 <ftonello> seebs: When I try to compile valgrind, it says that no recipe provides that
Nov 03 00:59:26 <ftonello> valgrind was skipped: incompatible with host arm-poky-linux-gnueabi (not in COMPATIBLE_HOST)
Nov 03 00:59:33 <ftonello> this error message
Nov 03 00:59:49 <ftonello> this is in valgrind recipe: COMPATIBLE_HOST_armv7a = 'arm.*-linux'
Nov 03 01:00:03 <seebs> hmm. That seems odd.
Nov 03 01:00:52 <seebs> Well, what specific arm chip are you targeting?
Nov 03 01:01:18 <seebs> That line is an "override" -- if the string "armv7a" is in the list of overrides, then that'll overwrite the normal value for COMPATIBLE_HOST.
Nov 03 01:01:36 <seebs> If you were, say, targeting an armv5, that wouldn't happen, and arm* wouldn't be in COMPATIBLE_HOST.
Nov 03 01:03:37 <ftonello> i use armv7
Nov 03 01:03:49 <ftonello> not armv7a
Nov 03 01:04:02 <ftonello> i include the armv7 tune file in my machine conf
Nov 03 01:06:57 <seebs> Ahh. Then it may not work. You could try changing that line to _armv7 and see whether it works then, but it may not.
Nov 03 01:07:12 <seebs> But it certainly won't pick up that COMPATIBLE_HOST override for regular armv7, as it's written now.
Nov 03 02:52:12 <kergoth> what are these 'Matched in' lines with the files duplicated/overwritten in the sysroot?
Nov 03 02:52:31 <kergoth> it's not saying *what* it's matched in, theres' no info, just a ton of lines containing only 'matched in', and the lines with the filenames
**** ENDING LOGGING AT Sat Nov 03 03:00:01 2012

**** BEGIN LOGGING AT Sat Nov 03 03:00:01 2012
Nov 03 10:05:26 <eren> I could see a mailing list such as "yocto-commits"
Nov 03 10:06:16 <eren> I've already subscribed to "yocto" and "poky" lists. How can I track what is committed?
Nov 03 17:21:42 <eren> well, I guess I get an error while sourcing the init script
Nov 03 17:21:53 <eren> % source oe-init-build-env
Nov 03 17:21:56 <eren> cd:cd:10: string not in pwd: ..
Nov 03 17:22:09 <eren> I'm using zsh, with oh-my-zsh configuration
Nov 03 17:24:33 <eren> oh nice, it was caused by my zsh configuration, solved it :)
**** ENDING LOGGING AT Sun Nov 04 03:00:01 2012

**** BEGIN LOGGING AT Sun Nov 04 03:00:02 2012
Nov 04 09:25:53 <eren> is there a bitbake web ui to see build progress and stats?
Nov 04 09:29:46 <eren> I would like to track the build progress using the webpage if possible, rather than logging in to build machine and check the console output :)
Nov 04 15:27:54 <eren> I've builded core-image-minimal using a test BSP for a target board. Everything went fine and I now have a rootfs (core-image-minimal-LX800.ext3) and a kernel (bzImage-LX800.bin) seperately
Nov 04 15:28:32 <eren> when I mount the rootfs, the /boot directory is empty. Shouldn't bzImage reside in /boot and grup been installed?
Nov 04 15:31:31 <eren> so that I just dd the ext3 image to CF card and boot the board?
Nov 04 16:54:42 <syssi> Hi! I like to ask some newbie questions.
Nov 04 16:55:45 <RP__> syssi: I have a feeling a lot of people are travelling atm but ask and maybe someone will answer. If not, ask on the mailing lists
Nov 04 16:56:49 <syssi> :-) I own a logitech squeezebox and trying to implement some stuff.
Nov 04 16:57:10 <syssi> I'm able to build a squeezeos image. the build system looks like openembedded + poky.
Nov 04 16:58:02 <syssi> The build process builds a lot of ipk-files but my cramfs does not include any opkg-cl.
Nov 04 16:58:37 <RP__> syssi: The package management files are probably wiped out after the filesystem is constructed
Nov 04 16:58:44 <syssi> so I'm looking for the common OE-poky-bitbake way to include opkg into my distribution
Nov 04 16:59:21 <syssi> RP__: okay. in this case there is some "moment", when opkg can install additional packages. ;-)
Nov 04 16:59:38 <RP__> syssi: The OE-Core way of doing this is having package-management in IMAGE_FEATURES. I think squeezeos might be using something older though
Nov 04 16:59:46 <syssi> I ported pulseaudio to squeezeos and got a lot of *.ipk packages I want to deploy.
Nov 04 17:00:04 <syssi> where is the "central" poky-openembedded bootstrap configuration located? ;-)
Nov 04 17:00:08 <RP__> syssi: are you able to build a new rootfs or just want to update an existing one?
Nov 04 17:00:34 <syssi> RP__: i'm able to build a new one.
Nov 04 17:01:02 <RP__> syssi: Is there somewhere I can look at the metadata you're basing this off?
Nov 04 17:01:08 <syssi> RP__: I know some popy/build/conf/local.conf but canot identify any "package lists".
Nov 04 17:01:47 <RP__> syssi: You run bitbake xxx-image, right?
Nov 04 17:01:55 <syssi> RP__: right.
Nov 04 17:01:58 <RP__> syssi: So somewhere there should be a xxx-image*.bb file
Nov 04 17:02:13 <RP__> syssi: I'd start by finding that and seeing what it says
Nov 04 17:02:26 <syssi> jep! ./meta-squeezeos/packages/images/squeezeos-image.bb
Nov 04 17:02:26 <syssi>  
Nov 04 17:03:00 <syssi> http://pastebin.com/5UpNyai9
Nov 04 17:03:13 <syssi> this is a good place to start.
Nov 04 17:03:26 <syssi> there is can add my stuff ;-)   IMAGE_INSTALL += "stress"
Nov 04 17:03:39 <syssi>  
Nov 04 17:03:45 <RP__> syssi: yes, you can see it inherits some base image and then adds extra things
Nov 04 17:03:50 <syssi> wow. a very clean solution. thanks for your hint!
Nov 04 17:04:12 <syssi> I think I can handle it now. :-)
Nov 04 17:04:18 <RP__> syssi: :)
Nov 04 17:05:05 <syssi> RP__: assumed I like the IMAGE_FEATURE of opkg
Nov 04 17:05:44 <syssi> RP__: do you have some suggestion for enabling opkg?
Nov 04 17:05:52 <RP__> syssi: I guess something in the image it inherits is disabling that
Nov 04 17:06:00 <syssi> RP__: f.e. there are some opkg-native and opkg-utils.
Nov 04 17:06:19 <RP__> syssi: What does squeezeos-image-boot.bb have in it?
Nov 04 17:06:54 <syssi> http://pastebin.com/dvztNtcq
Nov 04 17:07:14 <RP__> syssi: ROOTFS_POSTPROCESS_COMMAND += "remove_packaging_data_files"
Nov 04 17:07:28 <syssi> you are good, man! :-)
Nov 04 17:07:29 <RP__> syssi: that is what removes the package management data
Nov 04 17:08:04 <RP__> IMAGE_FEATURES += "package-management" might add in opkg, or just install opkg
Nov 04 17:10:41 <syssi> RP__; cramfs is an read-only filesystem, right?
Nov 04 17:10:52 <RP__> syssi: yes, I think so
Nov 04 17:11:42 <syssi> RP__: ah, my device has some overlay. using opkg is not impossible. ;-)
Nov 04 17:18:41 <syssi> thanks again for your help!
Nov 04 17:43:16 <eren> RP__: you mean, yocto mailing list?
Nov 04 17:43:29 <eren> I need to try my chance on the list, no one is here :)
**** ENDING LOGGING AT Mon Nov 05 02:59:59 2012

**** BEGIN LOGGING AT Mon Nov 05 02:59:59 2012
Nov 05 08:04:35 <mckoan> good morning from ELCE 2012, Barcelona
Nov 05 09:09:11 <_Lucretia_> does gcc get built for native before gcc-cross?
Nov 05 09:15:05 <Zagor> _Lucretia_: no, they are built independently.
Nov 05 09:15:25 <_Lucretia_> eh?
Nov 05 09:15:56 <_Lucretia_> ok, does gcc-cross use a gcc built by poky?
Nov 05 09:16:20 <_Lucretia_> i.e. a poky built gcc is used to build gcc-cross?
Nov 05 09:16:39 <_Lucretia_> I'm trying to find the build dir if it does
Nov 05 09:19:23 <Zagor> hmm, I'm slightly confused. I'll let someone else answer to avoid spreading misinformation.
Nov 05 09:20:52 <_Lucretia_> so far I can only find the build dirs for the gcc-cross-* variants
Nov 05 10:34:02 <_Lucretia_> what is the difference between the various gcc's? cross-initial/intermediate/etc?
Nov 05 12:15:32 <_Lucretia_> hi, I've set up a new layer "meta-ada" which has recipes-devtools/gcc inside and then a gcc_4.6.bbappend file within that
Nov 05 12:15:44 <_Lucretia_> I'm trying to get ada added as a language using:
Nov 05 12:15:47 <_Lucretia_> ADA = ",ada"
Nov 05 12:15:47 <_Lucretia_> LANGUAGES_append = "${ADA}"
Nov 05 12:16:30 <_Lucretia_> I've also tried LANGUAGES += "${ADA}" but in the tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/gcc-cross-4.6.3+svnr184847-r29/temp/log.do_configure file, --enable-languages=c,c++ and ada is not there
Nov 05 12:18:46 <_Lucretia_> also, my layer's priority is the same as meta - dunno if that's a problem - which is 5
Nov 05 14:02:40 <Crofton> Jefro, we seem to lack a phone
Nov 05 14:03:38 <Jefro> Crofton so I heard
Nov 05 14:03:49 <Jefro> What kind of boardroom doesn't have a phone? or should I ask?
Nov 05 14:04:04 <Crofton> rofl
Nov 05 14:04:21 <Crofton> there is a phone, there is no speaker
Nov 05 14:04:29 <Crofton> ah, one has appeared
Nov 05 14:04:39 <Crofton> things fall apart when you are not here
Nov 05 14:06:09 <Crofton> Jefro, what time is it there?
Nov 05 14:06:27 <Crofton> now we are plugging the phon ein
Nov 05 14:07:01 <Crofton> now RP__ is doing the plugging
Nov 05 14:07:12 <Crofton> he may need to hold it in the entire meeting
Nov 05 14:07:28 <Jefro> um
Nov 05 14:08:05 <Crofton> I had beer at lunch
Nov 05 14:08:37 <Crofton> hi sakoman
Nov 05 14:09:56 <sakoman> Hey Crofton!
Nov 05 14:10:25 <Crofton> oops
Nov 05 16:20:43 <_Lucretia_> does anyone here know about the gcc-cross build?
Nov 05 19:32:18 <seebs> Just a sanity check of my understanding: If two files in different layers have the same path name within their layer, bitbake will usually only pick up one, but same file name in different relative paths is always unique, right?
Nov 05 19:32:44 <seebs> Trying to clean up some file naming in a layer and I want to be sure that my understanding of which parts are providing uniqueness is right.
Nov 05 19:50:00 <eren> hello there
Nov 05 22:34:05 <zibri> hum, did the rss feed for the yoctoproject.org blog disappear? (<http://www.yoctoproject.org/blogs/feed>)
Nov 05 22:43:38 <B4gder> possibly due to the site restructure...
Nov 05 22:45:08 <B4gder> I'll poke jefro about it and see
Nov 05 22:46:05 <zibri> b4gder: yeah, that's what i thought. thanks
Nov 05 23:06:11 <halstead> zibri, Yes. The upgrade has caused an issue there. I'll see about getting it back online.
Nov 05 23:09:12 <zibri> halstead: great, thanks!
Nov 05 23:19:21 <B4gder> "a known bug, supposed to be fixed this evening" he says...
Nov 05 23:21:18 <halstead> zibri, https://www.yoctoproject.org/tools-resources/blog now has RSS at https://www.yoctoproject.org/blogs/feed
Nov 05 23:22:35 <zibri> awesome, thanks!
**** ENDING LOGGING AT Tue Nov 06 02:59:58 2012

**** BEGIN LOGGING AT Tue Nov 06 02:59:58 2012
Nov 06 03:08:23 <JDuke128>  hello , i want to download all open embedded repository , is it possible ? i will make all operations offline on our lab
Nov 06 03:42:25 <sakoman>  
Nov 06 06:03:31 <seebs> This is probably one of those silly questions, but: If I want to suppress ${BASEDEPENDS} from being in a package's ${DEPENDS}, how do I do that? It's being added by a DEPENDS_prepend in base.bbclass, it seems.
Nov 06 06:03:56 <seebs> (Reason is, I am trying to do a separate thing which does some unpacking-and-shuffling before the recipe which extracts eglibc prebuilts runs.)
Nov 06 06:05:59 <JaMa> setting different thing in BASEDEPENDS does not work?
Nov 06 06:08:58 <seebs> Oh, hey, that's a thought.
Nov 06 06:09:18 <seebs> I was all focused on "but leave my ${DEPENDS} alone", but obviously a per-recipe override of ${BASEDEPENDS} would also work. Probably.
Nov 06 06:10:57 <seebs> Although come to think of it. It seems as though base.bbclass is being processed after my recipe.
Nov 06 06:13:45 <JaMa> I had simipar problem with DEPENDS_prepend with qt recipes and extra variable was only way to change it
Nov 06 06:27:49 <seebs> Thanks a million! That did indeed work.
Nov 06 10:20:59 <syssi> hi! can somebody give me a hint how to get a verbose output for "bitbake -c configure package" ?
Nov 06 10:21:25 <syssi> I like to the the output of ./configure. I have the impression there is failing something silently.
Nov 06 10:21:59 <syssi> The build aborts at the packaging step because there are no build results. do_compile reports: nothing to do. ;-)
Nov 06 10:25:04 <JaMa> syssi: there is temp/log.do_configure file in package workdir
Nov 06 10:27:05 <syssi> JaMa: just checking :-)
Nov 06 10:27:50 <syssi> hmm, it's empty.
Nov 06 10:29:37 <syssi> but thanks anyway. maybe I can find the problem now.
Nov 06 11:22:00 <jackmitchell> syssi: you do always run a devshell and do a manual configure if something is going wrong and you just want to see the full output
Nov 06 11:27:23 <syssi> "inherit autotools pkgconfig" was missing. :-)
Nov 06 11:27:29 <syssi> my fault...
Nov 06 11:28:43 <syssi> jackmitchell: I don't know poky/oe very well. I have to learn it atm to achieve my goal.
Nov 06 11:29:41 <syssi> jackmitchell: didn't know there is a devshell so far. :-)
Nov 06 11:30:20 <jackmitchell> syssi: bitbake -c devshell pakage-name
Nov 06 11:30:30 <syssi> nice to know!
Nov 06 11:30:53 <syssi> very helpful!
Nov 06 11:30:57 <jackmitchell> will open a terminal with all the environment variables set, which allows you to manual manipulate the building of a package on a 'one time' basis
Nov 06 11:31:53 <syssi> like some buildroot-jail-pbuilder thingy ;-)
Nov 06 11:32:43 <syssi> last newbie question: bitbake runs "do_patch" but my patch is not applied. there is no "temp/log.do_patch" file..
Nov 06 11:34:02 <syssi> found.
Nov 06 11:34:27 <syssi> the *.bb has hardcoded patch files.
Nov 06 11:35:02 <jackmitchell> hmm, tough to say if there is no error produced
Nov 06 11:37:00 <syssi> I don't understand when bb picks  up every file at "package/packagename" and when it just take some defined one.
Nov 06 11:37:52 <syssi> file -> i mean patches
Nov 06 11:46:35 <syssi> .bb modified, revision incremented, next try.
Nov 06 11:50:04 <jackmitchell> syssi: if you are using oe-core master or the new 'danny' release a change of the BB file in most cases should promt a re-compile
Nov 06 12:48:50 * mranostay waves to Crofton 
Nov 06 13:13:10 <mckoan> gm
Nov 06 14:38:24 <syssi> if I have some libraries (already build by bitbake) and a third package cannot find these by pkg-config. what is going wrong?
Nov 06 14:45:12 <syssi> hmm,.. looks like the staging-part is broken.
Nov 06 15:10:49 <syssi> new magic macro learned: autotools_stage_all
Nov 06 15:11:44 <kergoth> if you're running that, you're almost certainly doing it wrong
Nov 06 15:11:54 <kergoth> population of the sysroot from do_install is done automatically
Nov 06 15:12:00 <kergoth> you never want to stage anything yourself
Nov 06 15:17:59 <syssi> kergoth: maybe I need to use it because I'm working with an outdated revision.
Nov 06 15:18:33 <syssi> kergoth: I have to work with logitech squeezeos/poky... :-(
Nov 06 16:08:58 <walters> hm, any python3 recipes around?
Nov 06 16:09:45 <walters> the pile of patches in the current oe-core recipie is intimidating
Nov 06 16:10:29 <walters> as well as the replacement build system
Nov 06 16:14:07 <blloyd_> does the base yocto system have anything for AutoIP support?  I'm having trouble locating support for it.
Nov 06 16:16:28 <kergoth> if you're referring to zeroconf, then pretty sure the answer is yes. I have no idea what AutoIP even is
Nov 06 16:16:58 <jackmitchell> kergoth: from a quick search: http://lwip.wikia.com/wiki/AUTOIP
Nov 06 16:17:08 <blloyd_> AutoIP is whatthe specs for upnp refer to zeroconf as.
Nov 06 16:18:14 <jackmitchell> blloyd_: does Avahi support it maybe?
Nov 06 16:18:59 <blloyd_> that would do it!  The avahi package as built via avahi.inc is autoip.  Thanks.
Nov 06 16:20:10 <walters> i wonder if there are any flamewars to read from attempts to switch to automake
Nov 06 16:20:52 <blloyd_> almost gauranteed.  Which program is making the switch?
Nov 06 16:21:37 <walters> blloyd_, sorry, you missed the context - i was looking at python(3) and the replacement make invocations in oe's do_compile()
Nov 06 17:54:53 <nitink> khem: ping
Nov 06 20:00:06 <Crofton> yes?
Nov 06 20:22:08 <hollisb> kergoth: we have a layer that might or might not need to apply now-upstream patches. for example, maybe Yocto 1.2 was missing a patch, but it's present in 1.3. we'd like the same layer to work with both releases
Nov 06 20:22:29 <kergoth> use a branch, like everyone else
Nov 06 20:22:37 <kergoth> there's ar eason many layers have denzil/danny branches
Nov 06 20:23:18 <hollisb> hmm, I'm not sure that will cover the combinations. e.g. we have two patches: one to poky, one to meta-ti
Nov 06 20:24:09 <kergoth> meta-ti has a denzil branch, and i'm sure they'd be open to a danny branch
Nov 06 20:25:14 <hollisb> hmmm. I was thinking of oe_filter_out on FILES, but maybe we could solve the problem with branches
Nov 06 20:26:14 <kergoth> i assume you  mean on SRC_URI. that'd be doable too, but sounds like more trouble than its worth. that'd be just the first of many pains you could run into trying to support multiple versions of another layer
Nov 06 20:26:18 <kergoth> better to sidestep the issue entirely
Nov 06 20:26:29 <hollisb> mmm hmm
Nov 06 20:26:34 <hollisb> ok, thanks for the advice!
Nov 06 20:32:24 <denix> danny branch in meta-ti shouldn't be a problem, just didn't have time yet
Nov 06 20:32:48 <denix> but what's the issue?
Nov 06 20:36:08 <hollisb> denix: there are some tracing patches for ARM that are very slowly making their way into mainline
Nov 06 20:36:40 <hollisb> denix: but, since Mentor has a trace analysis tool for which we would like trace data to be available today, we have backports of those patches to some common BSP kernels
Nov 06 20:37:51 <hollisb> denix: right now we're providing those in a separate layer, since we need to respect the common "you can't add a feature to an old release" policies
Nov 06 20:39:00 <hollisb> so getting back to the original question, we want that same layer to work no matter what versions of other layers are in use (within limits, of course)
Nov 06 22:02:34 <ftonello> guys, is there any efforts started to port qt5?
Nov 07 00:42:06 <ftonello> guys
Nov 07 00:42:17 <ftonello> when running valgrind in armv7 arch im getting this error
Nov 07 00:42:19 <ftonello> http://paste.kde.org/598670/
Nov 07 00:42:25 <ftonello> does someone knows what it could be?
Nov 07 00:42:41 <ftonello> where can I find the ld-linux.so.3 not stripped?
**** ENDING LOGGING AT Wed Nov 07 03:00:02 2012

**** BEGIN LOGGING AT Wed Nov 07 03:00:02 2012
Nov 07 07:44:16 <BjornArnelid> Good morning, I get the following error when i try to start the HOB: "ERROR: cannot map 'INVALID' to a linux kernel architecture" What does that mean?
Nov 07 08:21:43 <mckoan> good morning
Nov 07 22:37:51 <linuxjacques> I see yocto is doing "wget -t 2 -T 30" - how do I change those values? I don't see them in conf/*
Nov 07 22:42:14 <linuxjacques> oh, I found it in meta/conf/bitbake.conf
Nov 07 23:18:07 <linuxjacques> I did "bitbake -c fetchall -k core-image-sato" but it's compiling things...
Nov 07 23:19:39 <hollisb> linuxjacques: native recipes?
Nov 07 23:19:56 <linuxjacques> hollisb, yes
Nov 07 23:20:21 <hollisb> I believe that's because yocto can't count on the host providing even the tools needed to pull sources
Nov 07 23:20:59 <hollisb> e.g. git has gained some features that Yocto uses, but the host might provide an old version of git that's missing those features
Nov 07 23:21:08 <linuxjacques> oh yeah that could be it
Nov 07 23:21:30 <linuxjacques> it only built a few packages
**** ENDING LOGGING AT Thu Nov 08 03:00:01 2012

**** BEGIN LOGGING AT Thu Nov 08 03:00:02 2012
Nov 08 08:33:28 <mckoan> good morning
Nov 08 08:34:13 <mckoan> Yocto project dev day in Barcelona has started
Nov 08 16:17:15 <jstashluk> I put gst-plugins-bad into the IMAGE_INSTALL part of my image recipe.  Makes it to sysroot, but not image?  What do I need to do?
Nov 08 16:29:22 <scottrif> halstead: ping
Nov 08 16:32:58 <halstead> scottrif, pong.
Nov 08 16:38:44 <scottrif> Hi Michael - Do you know anything about getting general internet working on my Belize system outside the firewall?
Nov 08 16:43:58 <halstead> scottrif1 Probably.  PM with your question.
Nov 08 17:26:33 <jstashluk> I added gst-plugins-bad to IMAGE_INSTALL in image recipe.  The .so makes it to sysroot, but not to the image.  What am I missing?
Nov 08 20:21:22 <scottrif1> halstead: ping
Nov 08 20:31:08 <halstead> scottrif1, here.
Nov 08 20:31:27 <scottrif1> halstead: going PM...
Nov 08 20:54:09 <msm> i suspect no one is here
Nov 08 22:01:03 <msm> hob does not appear to like my gtk, pygtk and pygobject
Nov 08 22:01:06 <msm> anyways to tell more?
Nov 08 22:01:12 <msm> $ hob
Nov 08 22:01:12 <msm> FATAL: Gtk+, PyGtk and PyGobject are required to use Hob,
Nov 08 22:01:12 <msm> You have Gtk+ 2.20.1 and PyGtk 2.17.0.
Nov 08 22:01:23 <msm> I've got pyobject installed
Nov 08 22:01:24 <kergoth> i'd read the code that does the check
Nov 08 22:01:39 <kergoth> also, verify that the pythonv ersion you have it installed for is the one you're using
Nov 08 22:01:49 <kergoth> e.g. on centos5 you could have both python24 and python27
Nov 08 22:01:50 <kergoth> or whatever
Nov 08 22:18:21 <msm> kergoth: ahhhh
Nov 08 22:19:15 <msm> i thought that might be it, since my centos machine has it's own python
Nov 08 22:19:23 <msm> but on this machine its usin the host python
Nov 08 22:19:24 <msm> i think anyway
Nov 08 22:19:25 <msm> s
Nov 08 22:20:15 <kergoth> run python --version, and do a rpm -ql or dpkg -L or whatever on the package you installed for pyobject, and see if it went into the correct site-packages for that python
Nov 08 22:22:34 <msm> mmmmph
Nov 08 22:22:34 <msm> $ rpm -qf `which python`
Nov 08 22:22:35 <msm> python-2.6.4-27.fc13.x86_64
Nov 08 22:24:22 <kergoth> if that's not it, i have no idea, like i said, i'd read the hob python code to see what it's looking for in the check
Nov 08 22:24:26 * kergoth shrugs
Nov 09 00:08:44 <edris> I recently inherited an OE based project that's a bit out of date, meaning it snapshotted OE about 3 years ago, and never updated.   I've been pondering alternatives.  Moments ago I read about Yocto
Nov 09 00:09:07 <edris> our OE thus far targets an ARM926 which is a v5
Nov 09 00:09:26 <edris> looking at Yocto, I don't see that as a supported target.  Can anyone confirm whether Yocto supports it?
Nov 09 00:11:53 <kergoth> metadata is granular now, broken up into many layers, rather than one giant repository
Nov 09 00:12:05 <kergoth> yocto includes poky, which is essentially bitbake+oe-core+meta-yocto
Nov 09 00:12:19 <kergoth> but many other layers exist, to support a variety of different devices
Nov 09 00:13:06 <kergoth> http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/conf/machine/include should give you an idea of the processors that we have configs for. the machien .conf includes the appropriate one
Nov 09 00:13:07 <edris> i suppose the one, closest relative would be sheevaplug.
Nov 09 00:13:14 <kergoth> see http://www.openembedded.org/index.php/LayerIndex
Nov 09 00:13:36 <edris> ahh... arm926 is there.  nice!
Nov 09 00:14:59 <kergoth> https://gist.github.com/3975974 has a script to clone all the layers in layerindex, which can be useful if you want to find/grep around to see what's available
Nov 09 00:36:35 <kergoth> damnit, I need a way to override meta-oe's layer priority to be lower than oe-core
Nov 09 00:36:48 <kergoth> i just don't trust meta-oe's recipe quality, yet it's nice to have around for the recipes that aren't in oe-core
**** ENDING LOGGING AT Fri Nov 09 02:59:58 2012

**** BEGIN LOGGING AT Fri Nov 09 02:59:58 2012
Nov 09 06:33:20 <msm> kergoth: i would think layer priority would be in the bblayers file
Nov 09 06:33:41 <msm> kergoth: we actually add BBFILE_PRIORITY_openembedded-layer = "1"
Nov 09 06:33:49 <msm> in our local.conf
Nov 09 08:51:32 <erbo> I'm trying to build a qt app in yocto, but when qmake is parsing the .pro file it doesn't have the QT_VERSION and QT_MAJOR_VERSION variable set. Any ideas?
Nov 09 09:57:02 <jackmitchell> erbo: are you using the qmake classes in your recipe?
Nov 09 09:58:51 <erbo> jackmitchell: yes, I inherit qmake2 and qt4x11
Nov 09 09:58:59 <jackmitchell> erbo: no matter, they don't specifiy QT_VERSION either, I'm no qt guru, sorry!
Nov 09 09:59:22 <jackmitchell> erbo: as it's ELC-E at the moment I would suggest posting on the mailing list
Nov 09 09:59:45 <jackmitchell> there are a few people around that have particularly good knowledge of the QT recipes
Nov 09 10:00:01 <erbo> jackmitchell: I'll do that, thanks!
Nov 09 10:41:42 <bilboed> are the slides from the various yocto day presentations going to be made public ?
Nov 09 10:41:47 <bilboed> (or maybe they already are ?)
Nov 09 11:15:45 <jnepel> hi, anybody using the gold linker (compiled using ld-is-gold) has had any issues with segfaults at __libc_csu_init ?
Nov 09 11:20:27 <JaMa|Off> what arch?
Nov 09 11:57:20 <jnepel> armv7
Nov 09 11:57:46 <jnepel> think I'll give it a try compiling the latest binutils and see how that goes
Nov 09 13:27:11 <erik_> I'm trying to build tracker which has a m4 test for checking that sqlite3 is built threadsafe. The check fails for some reason, even though sqlite is built thread safe. I can even start a devshell, compile the code used in the test and see that it returns the correct value for threadsafeness. Is there any known quirks with m4 tests in configure scripts?
Nov 09 14:26:46 <rburton> erik_: have a look at https://github.com/Guacamayo/meta-guacamayo/tree/master/meta-guacamayo/recipes-support/tracker
Nov 09 14:27:11 <rburton> there's a "quirk" with m4 tests that try and run stuff, because you can't run stuff when cross-compiling
Nov 09 14:31:44 <erik_> rburton: thanks, I just realized that is fails when trying to run the test on that it doesn't find libsqlite3. So it sounds just like what you say :)
Nov 09 14:31:55 <erik_> thanks for the link
Nov 09 14:32:21 <rburton> we should push that to meta-oe
Nov 09 14:43:23 <kergoth> i really hate debugging dependency loops
Nov 09 14:43:30 <kergoth> bitbake's inrfo about them really isn't that helpful
Nov 09 14:44:06 <kergoth> looks like a few hundred of this line: Aborted dependency loops search after 10 matches.
Nov 09 14:44:22 <kergoth> a bit worrisome when bitbake acts like the dependency loop search is stuck in a loop ;)
Nov 09 14:44:37 <kergoth> erm, hundreds was a low estimate
Nov 09 14:45:11 * kergoth digs into the previous output
Nov 09 15:27:42 * kergoth sighs
Nov 09 15:27:51 <kergoth> finding dependency loops is a giant pain in the ass
Nov 09 15:27:53 <kergoth> hmmm
Nov 09 18:56:17 <seebs> So, I am messing with rebuilds of eglibc, in a slightly unusual context -- using a prebuilt binary toolchain, and trying to just rebuild glibc.
Nov 09 18:56:38 <seebs> This is something we have done in the past, but not in Yocto. And so far, what's biting me is that there are things going wrong in code I can't even *find*.
Nov 09 18:56:58 <seebs> So, for instance, right now my build of glibc fails because make can't find generate_supported.mk.
Nov 09 18:57:15 <seebs> If I look in a standard oe-core build, there is such a file in the glibc build directory after the build completes.
Nov 09 18:57:20 <seebs> And... that's all I can find.
Nov 09 18:57:44 <seebs> I am pretty sure I have grepped the entire tree and found neither files named that, nor files containing that name.
Nov 09 18:57:54 <seebs> Presumably, I have overlooked something I should have been looking at.
Nov 09 19:09:36 <evanp> maybe it's not actually glibc? my locate db doesn't mention generate_supported.mk, and it's got a lot of glibc build trees in it....
Nov 09 19:09:55 <evanp> seebs: that was meant for you
Nov 09 19:10:01 <seebs> When it exists, it's definitely in the eglibc build directory, and that's the package which fails.
Nov 09 19:10:20 <seebs> I am pretty sure it's a yocto-specific eglibc thing, but I can't find it.
Nov 09 19:10:42 <evanp> seebs: I suppose I have to clairify that I actually do mean glibc, not eglibc
Nov 09 19:10:51 <seebs> I did finally track down that the reference to ld.so.conf was in libc-common.bbclass.
Nov 09 19:11:10 <seebs> In this case, it's eglibc, but I'm pretty sure it's specifically yocto/oe-core.
Nov 09 19:11:29 <seebs> But I have grepped my entire oe-core directory for this and found nothing. Unless I suck at grep. Or it's in a compressed file.
Nov 09 19:42:25 <kergoth> seebs: we do that
Nov 09 19:42:27 <kergoth> seebs: https://github.com/MentorEmbedded/meta-sourcery/blob/master/conf/distro/include/tcmode-external-sourcery-rebuild-libc.inc
Nov 09 19:42:46 <kergoth> seebs: https://github.com/MentorEmbedded/meta-sourcery/blob/master/recipes/eglibc/eglibc-sourcery.bb
Nov 09 19:42:50 <seebs> Oh, hey.
Nov 09 19:42:57 <seebs> Maybe stealing that would be less work than reinventing it.
Nov 09 19:42:57 <kergoth> not the prettiest, but it works
Nov 09 19:43:02 <kergoth> indeed
Nov 09 19:43:18 <kergoth> did it as a tcmode to make it a little easier to enable
Nov 09 19:43:38 <seebs> What I've been doing is reworking the external toolchain substantially.
Nov 09 19:43:56 <seebs> So in my tree, right now, I have a single tcmode for the external toolchain, and then the recipes are broken out into separate bits.
Nov 09 19:44:02 <kergoth> i'd be very interested to see what you guys are doing with it
Nov 09 19:44:28 <seebs> One recipe grabs the target-specific sysroot stuff, one does binaries like mklibs and prelink, one does target stuff that's unconditional, one does nothing but prebuilt eglibc...
Nov 09 19:44:33 <kergoth> oh, interesting. that'd make it easier to produce cross-canadian packages to redistribute into an sdk if you have the legal rights to do so
Nov 09 19:44:46 <seebs> And the theory is, another rebuilds eglibc from source, and then there's just a toggle.
Nov 09 19:45:04 <seebs> So I have PREFERRED_PROVIDER_virtual/libc = "${WRL_GLIBC_MODE}" or something to that effect.
Nov 09 19:45:07 <kergoth> I'm assuming your toolchain layer isn't public?
Nov 09 19:45:17 * kergoth nods
Nov 09 19:45:36 <seebs> It's in the product, I ... well, honestly, I can't imagine anyone thinking we can call this code proprietary, since it is all edits starting from last April's external_csl_toolchain.bb
Nov 09 19:46:23 <seebs> Basically, what happened was, I was gonna try to do this, and it looked nigh-impossible. It took me about a week of staring at it and muttering to conclude that the underlying issue is that the toolchain.bb recipe was doing too many things which weren't really that closely related except that they all wanted access to the prebuilts.
Nov 09 19:46:56 <seebs> So I now have a wrl-toolchain-binaries.bb which stashes a bunch of stuff in ${TMPDIR}/wr-toolchain-binaries-${DEFAULTTUNE}.
Nov 09 19:47:09 <seebs> And then the other recipes can copy the stuff they want from that directory.
Nov 09 19:47:20 <seebs> Slightly more work, but makes everything easy to separate out and turn on and off independently.
Nov 09 19:47:34 <kergoth> having one recipe confuses matters conceptually. is it target, cross, or native? what's its PACKAGE_ARCH? how will sstate interact with it? certain crosscompiler bits are excluded from the usual sstate bits, but thats only for internally built toolchains, etc
Nov 09 19:47:39 <seebs> Yeah.
Nov 09 19:48:01 <kergoth> i'd move it into a ssysroot the way the eglibc-locale bits do, rather than the root of tmpdir
Nov 09 19:48:05 <seebs> And we'd already sort of invented -cross and -cross-canadian packages.
Nov 09 19:48:05 <kergoth> but otherwise doesn't sound too bad
Nov 09 19:48:31 <seebs> That's a good idea; I was afraid to because I did not know what the rules were for who is allowed to make up names in the sysroot dir. :)
Nov 09 19:48:42 * kergoth nods
Nov 09 19:48:56 <kergoth> given its done there, and also done to split out the glibc scripts/binaries, its clearly becoming a pattern
Nov 09 19:49:02 <kergoth> copy one of those and you'd be safe enough, i'd think
Nov 09 19:49:08 <kergoth> heh
Nov 09 19:49:08 <seebs> The intent is to have a single tcmode that has whether to rebuild glibc or not as a parameter, but can still share all the rest of the code and settings.
Nov 09 19:49:39 <kergoth> thats basically what my tcmode for rebuilding glibc does, other than adding sane defaults for the variables which specify where to find the sources
Nov 09 19:49:48 <seebs> And it's really easy for me to fix the stash dir, I have a single variable that everyone's using. :)
Nov 09 19:49:57 * kergoth nods, figured as much, just wanted to note it
Nov 09 19:50:16 <seebs> I just started by copying the standard eglibc package and trying to fix it, which I am... not really succeeding at, I wouldn't say.
Nov 09 19:50:42 <seebs> The external toolchain's inputs and assumptions are too different. I don't need bootstrapping or any of that, I don't need -nativesdk, I just want to run configure and make. :)
Nov 09 19:52:43 <kergoth> our eglibc-sourcery may indeed be a more minimal starting point, other than the extra unpack bits to deal with the sourcery source archive
Nov 09 19:53:02 <kergoth> could probably trim it down further, actually
Nov 09 19:53:17 <seebs> Yeah. I'd just gone ahead and unpacked the source trees I had and shuffled them into the format used for the normal yocto eglibc source tarball.
Nov 09 19:53:39 <kergoth> ah
Nov 09 19:53:59 <seebs> Well, I'll have a look at that and see whether it improves my build situation. :)
Nov 09 19:54:15 <kergoth> i didn't want to host the sources somewhere directly, and didn't want to deal with matching src archive version with external toolchain version, and didn't want to check the tarballs into the git repo, so punting and making the user point at the src archive was the least painful route
Nov 09 19:54:21 <kergoth> heh
**** ENDING LOGGING AT Sat Nov 10 02:59:58 2012

**** BEGIN LOGGING AT Sat Nov 10 02:59:58 2012
Nov 10 15:45:55 <gotan> hi
Nov 10 15:46:10 <gotan> question about EXTRA_IMAGE_FEATURES
Nov 10 15:47:31 <gotan> when i enable them (tools-sdk tools-debug tools-profile tools-testapps dbg-pkgs dev-pkgs debug-tweaks), for some reason although my build does not use or need them, OE starts to build X and libogg etc. is there a way i can controll this?
Nov 10 16:30:39 <kergoth> gotan: if DISTRO_FEATURES contains x11, then when a piece of software can optionally enable support for x11 bits, those bits will be enabled. you can choose a distro that excludes them (e.g. poky-tiny instead of poky), or you could edit poky.conf or make your own distro
Nov 10 16:31:32 <kergoth> gotan: another option would be, get http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/tree/classes/user_features.bbclass, INHERIT += "user_features", USER_FEATURES += "~x11"
Nov 10 16:42:41 <gotan> thanks i'll check that out.
**** ENDING LOGGING AT Sun Nov 11 02:59:57 2012

**** BEGIN LOGGING AT Sun Nov 11 02:59:57 2012
Nov 11 20:55:39 <qu0ta> does anyone know if building for beaglebone works?
Nov 11 22:41:37 <qu0ta> how do I add multiple mirror sites? some kernel.org sites work and some do not??
Nov 11 23:06:05 <halstead> bug #2088
Nov 11 23:06:05 <yocti> Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=2088 janitors, Low, Q3, michael, ACCEPTED , Write a friendly IRC bot for the #yocto channel
Nov 11 23:10:20 <halstead> bug 2088
Nov 11 23:10:21 <yocti> Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=2088 janitors, Low, Q3, michael, ACCEPTED , Write a friendly IRC bot for the #yocto channel
Nov 11 23:15:27 <halstead> 2088
Nov 11 23:15:36 <halstead> bug 2088
Nov 11 23:15:37 <yocti> Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=2088 janitors, Low, Q3, michael, RESOLVED FIXED, Write a friendly IRC bot for the #yocto channel
Nov 11 23:15:51 <halstead> I think that one is done.
Nov 11 23:20:26 <Crofton|work> oh awesome
Nov 11 23:54:40 <xanium4333> bug 1
Nov 11 23:54:41 <yocti> Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=1 normal, High, ---, ross, RESOLVED FIXED, Should install stripped-down gnome-icon-theme
**** ENDING LOGGING AT Mon Nov 12 02:59:58 2012

**** BEGIN LOGGING AT Mon Nov 12 02:59:58 2012
Nov 12 06:16:52 <msm> yocti 1
Nov 12 06:16:54 <yocti> msm: Error: "1" is not a valid command.
Nov 12 06:16:58 <msm> yocti bug 1
Nov 12 06:16:59 <yocti> msm: Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=1 normal, High, ---, ross, RESOLVED FIXED, Should install stripped-down gnome-icon-theme
Nov 12 08:28:02 <mckoan> good morning
Nov 12 08:47:28 <RagBal> What is the best way setting up a multi distro project environment?
Nov 12 08:47:50 <RagBal> {oe-core}/projects/{project}
Nov 12 08:48:03 <RagBal> {oe-core}/projects/{TMPDIR}
Nov 12 08:48:10 <RagBal> {oe-core}/projects/{SSTATE}
Nov 12 08:48:25 <RagBal> {oe-core}/projects/{DOWNLOADS}
Nov 12 08:48:59 <RP__> RagBal: you probably need a TMPDIR per project
Nov 12 08:49:19 <RagBal> Ok, so it is not adviceable to make it generic?
Nov 12 08:49:36 <RP__> You can always do TMPDIR = "${TOPDIR}/build-${DISTRO}" or something
Nov 12 08:49:52 <RP__> RagBal: mixing different distros in TMPDIR will result in problems, its not supported
Nov 12 08:50:14 <RagBal> Ok your distro append seems nice
Nov 12 08:51:28 <RagBal> Why would you suggest a per project TMPDIR instead of a generic per distro?
Nov 12 08:51:36 <RP__> RagBal: check the default value of TMPDIR, I'm not sure I have it entirely right from memory above but the idea is to add DISTRO in
Nov 12 08:51:40 <RagBal> Does it have advantages over a generic
Nov 12 08:51:52 <RagBal> Yea I understand your suggestion
Nov 12 08:51:59 <RP__> RagBal: depends what changed yo make per project
Nov 12 08:52:43 <RP__> if the changes are invasive, it might be better to have one per project, if they are simple things, it could make sense to share them
Nov 12 08:53:10 <RagBal> I don't know yet =) Trying to setup a good environment for me to play with
Nov 12 08:55:45 <RagBal> TMPDIR = "${TOPDIR}/../build-${DISTRO}" seems to work nicely
Nov 12 10:19:14 <bluelightning> morning all
Nov 12 11:04:46 <RagBal> gzip: /lib/x86_64-linux-gnu/libz.so.1: version 'ZLIB_1.2.5.1' not found (required by gzip)
Nov 12 11:04:59 <RagBal> When I try to unpack the tar.gz manually it works perfectly...
Nov 12 11:05:08 <RagBal> What is wrong?
Nov 12 11:07:27 <bluelightning> RagBal: when do you recieve this error?
Nov 12 11:08:30 <RagBal> When bitbaking
Nov 12 11:08:42 <RagBal> Package expat_2.1.0
Nov 12 11:09:32 <RagBal> Hmm it is a python function
Nov 12 11:10:01 <RagBal> python function do_unpack
Nov 12 11:15:37 <RagBal> I think my system is broken lol
Nov 12 11:16:12 <bluelightning> RagBal: what host distro are you building on?
Nov 12 11:16:17 <RagBal> Ubuntu 12.04
Nov 12 11:18:28 <bluelightning> try: bitbake -c cleansstate gzip-native zlib-native
Nov 12 11:18:35 <bluelightning> then bitbake gzip-native
Nov 12 11:19:30 <RagBal> Same error
Nov 12 11:21:08 <bluelightning> what exact command are you running?
Nov 12 11:21:16 <RagBal> bitbake rpi-basic-image
Nov 12 11:22:42 <bluelightning> what version of the metadata are you building with?
Nov 12 11:23:05 <RagBal> Yocto 1.3 branch, meta-openembedded master, meta-raspberrypi master
Nov 12 11:25:01 <RagBal> I tries to find ZLIB_1.2.5.1 but 1.2.3.4 is installed
Nov 12 11:30:11 <bluelightning> I'm using ubuntu 12.04 as well, and I just did bitbake -c cleansstate zlib-native gzip-native expat-native and then bitbake expat-native and it worked...
Nov 12 11:30:43 <RagBal> Did you also get the error?
Nov 12 11:31:29 <bluelightning> no I didn't
Nov 12 11:32:12 <bluelightning> brb
Nov 12 11:42:38 <RP__> RagBal: is it building zlib-native? For some reason it sounds like its being built but not being found by the binary linking against it. It could be something like the relocation code is corrupting the rpaths of the gzip binary
Nov 12 11:42:48 <RP__> RagBal: nobody else has reported this though :/
Nov 12 12:28:31 <RagBal> RP__ sorry I was afk
Nov 12 12:28:42 <RagBal> I'll try to build zlib-native
Nov 12 12:31:02 <RagBal> zlib-native succeeded
Nov 12 12:32:53 <RP__> RagBal: was it already built or not?
Nov 12 12:33:01 <RagBal> I cleaned it before
Nov 12 12:33:09 <RagBal> bitbake -c clean zlib-native
Nov 12 12:33:18 <RagBal> And yes, it was built
Nov 12 12:34:12 <RagBal> I'll delete my sstate, download and tmpdir
Nov 12 12:35:19 <ant_work> just do  -c cleansstate
Nov 12 12:37:18 <ant_work> there is little point deleting the downloaded sources (-c cleanall if you really want). Just, dont' do it by hand :)
Nov 12 12:37:36 <RP__> RagBal: "objdump -x ./tmp/sysroots/x86_64-linux/usr/bin/pigz-native/gzip  | grep RPATH" is how you'd look at the RPATHs
Nov 12 12:38:16 <RP__> RagBal: I have a suspicion that something about your layout might have "upset" the relocation code
Nov 12 12:38:54 <RagBal> I already deleted it by hand, but the same error occurs now
Nov 12 12:39:03 <RagBal> I'll do the objdump sec
Nov 12 12:40:49 <RagBal> RPATH $ORIGIN/usr/lib:$ORIGIN/lib
Nov 12 12:46:12 <RagBal> Ugh, also moving the TMPDIR to the default location doesn't work
Nov 12 12:55:48 <RagBal> I just switched to poky master and it seems to be building now...
Nov 12 13:15:06 <RagBal> I only get some udev notes now
Nov 12 13:15:45 <RagBal> Preferred versuib 164 of udev not available (for udev udev-dev and udev-utils)
Nov 12 13:27:07 <RP__> RagBal: ok, that RPATH is wrong and the source of the problems
Nov 12 13:27:25 <RP__> RagBal: were you using something other than master before?
Nov 12 13:32:14 <RagBal> Yes, I was using Danny branch
Nov 12 13:33:45 <RP__> RagBal: did you change TMPDIR too?
Nov 12 13:33:57 <RagBal> Yes
Nov 12 13:34:12 <RP__> RagBal: I think that is what fixed it
Nov 12 13:34:33 <RagBal> No, before I switched to master it still gave me the error
Nov 12 13:34:39 <RagBal> After switching to master it worked
Nov 12 13:35:01 <RP__> RagBal: I'm not aware of any fix for this on master...
Nov 12 13:35:29 <RagBal> I'll change TMPDIR after this is built
Nov 12 13:35:33 <RagBal> And check again
Nov 12 13:35:39 <RP__> rburton, bluelightning: We should probably do a test build and see if we can reproduce this...
Nov 12 13:37:00 <bluelightning> RagBal: where was your TMPDIR before?
Nov 12 13:37:26 <RagBal> ${TOPDIR}/../build-${DISTRO}
Nov 12 13:37:42 <RagBal> Now it is ${TOPDIR}/tmp
Nov 12 13:38:28 <bluelightning> so, er... your TMPDIR was named build-something ?
Nov 12 13:38:39 <RagBal> build-poky
Nov 12 13:43:19 <RagBal> Ok I changed the TMPDIR to ${TOPDIR}/../build-${DISTRO} again
Nov 12 13:43:23 <RagBal> Clearing sstate
Nov 12 13:52:36 <RagBal> Hmm it does seem to be releted to the TMPDIR yest
Nov 12 13:53:12 <RagBal> It also gives an error now, but not the same file as before
Nov 12 13:54:05 <RP__> RagBal: what is the error?
Nov 12 13:54:07 <RagBal> kconfig-frontends now won't extract
Nov 12 13:54:28 <RP__> RagBal: symbol issues?
Nov 12 13:54:42 <RP__> RagBal: I'm pretty sure the relocation code can't cope with that TMPDIR
Nov 12 13:55:11 <RagBal> xz: /usr/lib/x86_64-linux-gnu/liblzma.so.5: version 'XZ_5.1.2alpha' not found (required by xz)
Nov 12 13:55:32 <RP__> RagBal: right, same issue
Nov 12 13:55:33 <bluelightning> RP__: yep, confirmed the issue here with TMPDIR set as above
Nov 12 13:55:56 <RP__> bluelightning: can you open a bug please?
Nov 12 13:56:07 <bluelightning> RP__: yes, will do
Nov 12 13:56:13 <RP__> bluelightning: thanks
Nov 12 13:56:34 <RagBal> Ok, so I'll have to use a 'normal' TMPDIR?
Nov 12 13:56:51 <RP__> RagBal: until that bug is fixed, yes
Nov 12 14:03:24 <bluelightning> RagBal: the /../ is the problem... use an absolute path or keep it under the build directory and you won't have the issue
Nov 12 14:03:34 <RagBal> Yes I was just typing it
Nov 12 14:03:36 <RagBal> =)
Nov 12 14:06:53 <RagBal> bluelightning Can you msg me the bugzilla number when you created it please
Nov 12 14:07:34 <bluelightning> sure
Nov 12 15:07:18 <bluelightning> RagBal: https://bugzilla.yoctoproject.org/show_bug.cgi?id=3408
Nov 12 15:07:19 <yocti> Bug 3408: normal, Undecided, ---, saul.wold, NEW , TMPDIR cannot contain ../
Nov 12 15:07:50 <RagBal> Thank you
Nov 12 16:49:07 <Crofton|work> RP__, davest is having too much fun, manufacture a crisis
Nov 12 17:00:23 <RP__> Crofton|work: I could do so very easily...
Nov 12 21:06:52 <msm> anyone see this build bash on recent master?
Nov 12 21:06:52 <msm> https://gist.github.com/4061894
Nov 12 21:17:29 <kergoth> yep, it's failing for me every time
Nov 12 21:17:38 <kergoth> i assume something related to the switch to CFLAGS_FOR_BUILD
Nov 12 21:19:35 <kergoth> when crosscompiling, mkbuiltins.c doesn't source config.h, it uses internally hardcoded defines
Nov 12 21:19:43 <kergoth> i'm assuming for some reason it thinks we dont' have open() or read()
Nov 12 21:19:45 <kergoth> as a result
Nov 12 21:20:08 <kergoth> so either we can cheat, as we probably did before, and make it not pass -DCROSS_COMPILING to the mkbuiltins build (either by patchign, or overriding CCFLAGS_FOR_BUILD)
Nov 12 21:20:16 <kergoth> or we can figure out what define is missing to convince it we have open/read
Nov 12 21:20:29 <kergoth> i'm digging through the autoconf manual right now in an attempt to figure it out
Nov 12 21:20:30 <kergoth> heh
Nov 12 21:33:00 <seebs> Wait, autoconf? Not doing exactly what you first accepted?
Nov 12 21:33:03 <seebs> SAY IT AIN'T SO!
Nov 12 21:33:06 <seebs> ... speaking of which.
Nov 12 21:33:34 <seebs> I have stolen the rebuild-glibc recipe from the mentor-embedded github. And I have apparently stolen it very poorly.
Nov 12 21:34:13 <seebs> The symptom is, when the time comes for configure to run add-on configure fragments, it does so with $* set to 'X' '$CXX' '-c' '$CXXFLAGS' ...
Nov 12 21:34:38 <seebs> So the configure fragments fail. It looks to me like this is leftover set -- from a conftest.$ac_ext test.
Nov 12 21:34:55 <kergoth> msm: workaround: CC_FOR_BUILD += "-U_FORTIFY_SOURCE"
Nov 12 21:35:02 <kergoth> msm: that gets it to build, here. no clue why, yet
Nov 12 21:35:09 <kergoth> heh
Nov 12 21:35:59 <msm> msm: awesome, thanks!
Nov 12 21:36:52 <seebs> It looks as though there are contexts in which configure does eval set x "$ac_configure_args"; shift
Nov 12 21:37:01 <seebs> and that the add-on configure fragment should maybe be one of them.
Nov 12 21:41:05 <seebs> Oh. I bet I know what's wrong.
Nov 12 21:41:52 <seebs> I bet I unpacked things in the wrong places. Because I had an unpacked-glibc structured the way that the normal yocto build works. And I would be unsurprised if I ended up with the localedef stuff in the wrong place. And possibly other stuff.
Nov 12 21:53:04 <kergoth> msm: k, wrote a script to iterate over every define in config.h and substitute that line into mkbultins.c and rerun make each time to find the one that fixes the build
Nov 12 21:53:06 <kergoth> hehe
Nov 12 21:53:17 <kergoth> simple and hackish, but got it
Nov 12 21:53:23 <kergoth> looks like defining HAVE_STRINGIZE also fixes it
Nov 12 21:54:00 <kergoth> which is interesting
Nov 12 22:03:17 <msm> seems like you are on top of this ;)
Nov 12 22:03:34 <msm> what the root cause though?
Nov 12 22:06:04 <kergoth> that's the question… googling for 'xread' or 'xopen' finds nothing. i'm guessing that one of the autoconf macros is causing read/open calls to be renamed, but in a generic way that's not yielding to my grep'ing
Nov 12 22:06:15 * kergoth shrugs, still digging
Nov 12 22:20:06 <msm> kergoth: i vote to bug RP ;)
Nov 12 23:14:39 <kergoth> msm: okay, so, unistd.h defines read(), and that read() calls read_alias(), and read_alias is renamed at the assembly level to read(), using a macro called __REDIRECT(). that macro calls down through a number of macros, eventually calling a __STRING() macro. in bash, include/stdc.h redefines __STRING() based on whether HAVE_STRINGIZE Is defined
Nov 12 23:14:59 <kergoth> the read_alias/read rename only happens, when using fortify sources
Nov 12 23:15:04 <kergoth> so this is why it only fails in that context
Nov 12 23:16:13 <msm> kergoth: madness
Nov 12 23:18:25 <kergoth> so, i think defining HAVE_STRINGIZE in mkbuiltins.c via a patch is the best fix — http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/commit/?id=da0ff91
Nov 12 23:19:31 <seebs> ...
Nov 12 23:19:41 <seebs> What bothers me about this is that I think I got bitten by that EXACT problem before.
Nov 12 23:20:09 <seebs> Well, not that manifestation. But I think this is closely tied to why pseudo has to have wrappers for a bunch of things with names like __xfoo.
Nov 12 23:20:31 <seebs> BTW, kergoth: With a couple little tweaks, I seem to have glibc rebuilding working using that recipe.
Nov 12 23:20:44 <kergoth> nice
Nov 12 23:22:10 <seebs> So I now have a local layer in which a configuration setting tells it whether to extract prebuilt glibc from sources, or rebuild from source.
Nov 12 23:23:07 <seebs> Next up: (1) Adding better tools for specifying alternative compilation options. (2) Adding some sanity-checks, like suppressing attempts to build glibc -O0. (3) Making the prebuilt-picker smarter about a new kind of variant, like libraries prebuilt with frame pointers for a particular profiler. (4) Lots of drinking.
Nov 12 23:23:51 <seebs> BTW, the current binary toolchain we're using has some tunings for which the sysroot directory under libc is more than one directory deep, and some of the existing stuff doesn't quite match that. Haven't finished cleaning it all up; it works, but I'm not happy with it.
Nov 13 01:07:17 <_Lucretia_> bluelightning: any chance you could take a look at https://lists.yoctoproject.org/pipermail/yocto/2012-November/012718.html ? thanks
Nov 13 01:12:47 <bluelightning> _Lucretia_: sorry, no idea what's going on there
Nov 13 01:13:24 <_Lucretia_> as in don't know why it's not working?
Nov 13 01:13:37 <bluelightning> no
Nov 13 01:15:01 <_Lucretia_> one thing I think I forgot to mention is because of the problems I was having trying to get yocto to change my gcc/c++ versions - on debian and have 2 system compilers - I set up some links for gcc, g++, cpp to point to the *-4.6 versions such that gnat would work with it
Nov 13 01:15:22 <_Lucretia_> also, in theory, should that have worked?
Nov 13 01:17:57 <bluelightning> I don't know anything about gnat I'm afraid, I'm really not in a position to advise...
Nov 13 01:19:11 <_Lucretia_> ok but do you know about the gcc build process in yocto?
Nov 13 01:19:29 <_Lucretia_> specifically gcc-cross* variants
Nov 13 01:19:29 <bluelightning> not specifically no
Nov 13 01:19:39 <_Lucretia_> is there anyone here who can advise me?
Nov 13 01:19:58 <_Lucretia_> or help me get to grips with understanding the whole mess
Nov 13 01:19:59 <_Lucretia_> ?
Nov 13 01:20:17 <bluelightning> khem perhaps
Nov 13 01:20:29 <bluelightning> it's 1:20 AM here I need to get some sleep
Nov 13 01:20:46 <_Lucretia_> aye, same here
**** ENDING LOGGING AT Tue Nov 13 02:59:57 2012

**** BEGIN LOGGING AT Tue Nov 13 02:59:58 2012
Nov 13 06:28:00 <blloyd> anyone have any ideas why large outgoing packets would get dropped?
Nov 13 07:31:50 <eren> is the meeting at 8:00 UTC?
Nov 13 07:33:21 <eren> of course, it was UTC (minus) 8 :)
Nov 13 07:33:56 <Bagder> right, so UTC 16:00
Nov 13 07:35:21 <eren> :(
Nov 13 07:35:32 <eren> 10 hours of difference here
Nov 13 07:35:52 <eren> is is possible to call toll free number via skype?
Nov 13 07:36:03 <eren> without a toll of course
Nov 13 07:40:57 <Bagder> 9 hours here... I hear google hangouts allow free outgoing calls to US numbers now, but I haven't tested that
Nov 13 07:41:16 <eren> Bagder: morning to you, then :)
Nov 13 07:42:31 <Bagder> hehe, morning!
Nov 13 07:42:56 <eren> https://support.google.com/chat/bin/answer.py?hl=en&answer=2520614
Nov 13 07:43:24 <eren> Bagder: all US and Canada numbers are free, but I don't know how it can be used to participate in Yocto meeting
Nov 13 07:43:40 <Bagder> they have dial-in numbers in the US
Nov 13 07:44:02 <eren> they = yocto?
Nov 13 07:44:04 <Bagder> yes
Nov 13 07:44:13 <Bagder> I mean, for all meetings
Nov 13 07:44:17 <eren> yeah, I see in the mail
Nov 13 07:44:33 <eren> so they gather in a meeting room face-to-face, and connect a phone to outside?
Nov 13 07:44:43 <Bagder> they're all on phone usually
Nov 13 07:44:48 <eren> hm
Nov 13 07:44:49 <Bagder> or "we" =)
Nov 13 07:45:02 <eren> well, it will be my first :)
Nov 13 07:45:51 <eren> if I succeed, of course
Nov 13 07:46:06 <Bagder> hehe, but as you see there are also a lot of local numbers for various countries
Nov 13 07:46:15 <Bagder> at least for the technical meeting
Nov 13 07:46:57 <eren> oh yeah, I see a number for Turkey
Nov 13 07:47:00 <eren> but it's unusual
Nov 13 07:47:16 <eren> 0811 288 0001
Nov 13 07:48:10 <eren> hm, it's AT&T's number, probably a swtich to US
Nov 13 07:48:58 <eren> and it's landline only, which I don't have :\
Nov 13 07:56:18 <eren> ah, I seem to call US toll free number via skype, it greets me as "Welcome to Texas Instruments Conference System"
Nov 13 07:56:39 <eren> I've made 3 calls, none of which affected my balance, I guess it's really free :)
Nov 13 07:56:42 <eren> nice
Nov 13 08:23:07 <blloyd> anyone have any suggestions how to troubleshoot why transmissions greater than MTU are dropped from a core-image-sato based disk (removed X11 added custom app)?  Program works perfectly (ok, acceptably) from a standard desktop system (Fedora), but packets are dropped when sending from a yocto system.
Nov 13 08:34:16 <eren> blloyd: seems like you are going to debug the kernel?
Nov 13 08:34:56 <eren> blloyd: is it specific to one app, or every app has the same problem?
Nov 13 08:50:04 <blloyd> eren: only one app on that box sending data larger than 1500.
Nov 13 08:51:38 <blloyd> and it only happens when real network devices are involved.  A local wget works flawlessly.
Nov 13 08:52:23 <eren> have you tried that app on a different machine (I mean, regular fedora etc)
Nov 13 08:52:46 <eren> it it persists, then you would want to look at your router?
Nov 13 08:54:18 <blloyd> see ^
Nov 13 08:54:37 <blloyd> yes, it works just fine from my desktop
Nov 13 08:55:24 <eren> oh
Nov 13 08:56:04 <eren> I would dig into some logs to see any anomaly, dmesg maybe? Other than that, I don't have an idea about the problem
Nov 13 08:56:29 <eren> sorry :\
Nov 13 08:57:39 <blloyd> yes, and I'm discovering how clean/bare an image can be.  None of my usual troubleshooting tools like iptables are on the image (nor do I really want them there when this goes live).
Nov 13 08:59:13 <blloyd> dmesg comes up empty (only two entries after the link came up).
Nov 13 09:00:58 <blloyd> actually, I think I just broke SSH to the box too.  It doesn't send large packets often, but the session has hung twice now.
Nov 13 09:52:32 <eren> .quit
Nov 13 09:52:36 <eren> ops sorry :)
Nov 13 09:53:11 <bluelightning> morning all
Nov 13 10:00:53 <bluelightning> morning all
Nov 13 10:01:04 <Net147> moin
Nov 13 15:14:44 <mckoan> good morning
Nov 13 15:15:20 <mckoan> reading meta/recipes-kernel/linux/linux-yocto_3.4.bb I wonder how is defined the actual kernel version which should be 3.4.11
Nov 13 15:15:45 <mckoan> maybe with branch=${KBRANCH} ?
Nov 13 15:21:33 <zeddii> mckoan, it's merged into all the branches.
Nov 13 15:21:50 <zeddii> I've got pending updates to the very latest  3.4 -stable as well, which I need to get organized and send.
Nov 13 15:22:53 <mckoan> zeddii: I still don't understand
Nov 13 15:23:15 <zeddii> I merge the -stable git tags into standard/base
Nov 13 15:23:21 <mckoan> zeddii: now Im cloning the git kernel repo to see al the branches
Nov 13 15:23:23 <zeddii> and update the version number in the recipe.
Nov 13 15:23:34 <zeddii> and then I merge standard/base into all branches you see in the tree.
Nov 13 15:23:50 <zeddii> so they are all up to date with the content you'd get from v3.4.x in the -stable kernel tree.
Nov 13 15:24:18 <zeddii> it will shortly be 3.4.18
Nov 13 15:25:00 <mckoan> zeddii: but in the recipe is still called 3.4.11
Nov 13 15:25:15 <zeddii> because that's the version that went out with 1.3
Nov 13 15:25:23 <zeddii> when I send my next pull requests its going to change.
Nov 13 15:25:40 <mckoan> zeddii: hmm now is clear thank you
Nov 13 15:26:43 <gizero> mckoan: I guess the kernel class is always checking out the tip of a branch from linux-yocto repo
Nov 13 15:26:58 <mckoan> zeddii: BTW great talk at YPDD ;-)
Nov 13 15:27:23 <mckoan> gizero: hi, thx
Nov 13 15:27:49 <zeddii> thanks. I need to break it into about three talks, I could have talked for ever :P this was a good test run though.
Nov 13 15:28:27 <gizero> mckoan: hi ;-) How was your trip back from Barcelona?
Nov 13 15:28:37 <zeddii> gizero. only if you have AUTOREV otherwise, even if I've merged newer support all the branches are put back to whatever we released with and where the SRCREVs point.
Nov 13 15:29:22 <mckoan> gizero: fine and you?
Nov 13 15:29:54 * zeddii swims in his email backlog ... sigh.
Nov 13 15:31:16 <gizero> zeddii: yep, I should have said SRCREV-pinned commit
Nov 13 15:31:24 <zeddii> right!
Nov 13 15:31:53 <zeddii> now I'm motivated to get my queue sent out for updates. I wonder if I can get it done before lunch.
Nov 13 15:31:55 * zeddii dives in
Nov 13 15:32:25 <gizero> mckoan: yes, I had nice time visiting the city!!
Nov 13 15:34:17 <mckoan> gizero: me too and I found linux people in each corner where I was :-D
Nov 13 15:36:05 <gizero> mckoan: ubiquitous people we are!
Nov 13 16:01:01 <sgw1> YTPM: Saul's on the call
Nov 13 16:01:01 <scottrif> YPTM: Scott Rifenbark joined the call
Nov 13 16:01:19 <tomz2> YPTM: Tom Z on the call
Nov 13 16:01:48 <Jefro> YPTM: Jefro is on the call
Nov 13 16:01:59 <dvhart> YPTM: Darren is on the call
Nov 13 16:02:04 <Song_Liu> YPTM: welcome to the Yocto Project Technical team Meeting, please let me know who's on the bridge.
Nov 13 16:02:11 <mihai> YPTM: Mihai Lindner on the call
Nov 13 16:02:12 <RP__> Song_Liu: YPTM - Richard is here
Nov 13 16:02:13 <bluelightning> YPTM: Paul Eggleton is on the call
Nov 13 16:02:15 <jmpdelos> YPTM: Polk is on
Nov 13 16:02:23 <zeddii> YPTM: bruce is here on IRC, but the entire office has no phones (I have proof, try and call me :P) so I can't dial the call.
Nov 13 16:02:31 <jzhang> YPTM: jzhang on call
Nov 13 16:02:33 <dvhart> zeddii, likely story
Nov 13 16:02:35 <nitink> YPTM: Nitin on the bridge
Nov 13 16:02:36 <dvhart> ;)
Nov 13 16:02:42 <zeddii> dvhart. 3 out of the last 4 days!!
Nov 13 16:02:48 <bramming> Brian Ramming on the bridge
Nov 13 16:02:54 <zeddii> I think our phones involve tin cans and strings.
Nov 13 16:03:01 <halstead> YPTM: Michael Halstead present.
Nov 13 16:03:18 <dvhart> zeddii, you'll have to unlock the doors and go outside at some point, then the IT guys can get back in and fix it ;-)
Nov 13 16:03:48 <eren> I'm in
Nov 13 16:04:07 <eren> yeah
Nov 13 16:04:27 <zeddii> dvhart, :) I could use my cell, but holding it to my head for an hour .. not so much fine. my bluetooth headset is safely at home.
Nov 13 16:04:40 <zeddii> if anyone really wants my input in voice, ping me here, and I'll dial via cell.
Nov 13 16:04:58 <bogdanm> YPTM: bogdanm is on the bridge
Nov 13 16:05:09 <AlexG> Song_Liu: I am on the call too :)
Nov 13 16:05:52 <eren> how is it moderated? should I mute the microphone?
Nov 13 16:05:53 <Song_Liu> YPTM: ANy opens?
Nov 13 16:06:10 <Ramana> Techincal conference passcode plz , 76994298 not working from India
Nov 13 16:06:25 <eren> it is 76994298
Nov 13 16:06:31 <RP__> eren: Since there are a lot of people, we handle some of the pieces like collecting the attendance via irc
Nov 13 16:06:40 <eren> RP__: okkie
Nov 13 16:07:02 <Ramana> ok This Ramana from Huawei
Nov 13 16:07:20 <RP__> Ramana: that is the correct code
Nov 13 16:07:52 <Song_Liu> YPTM: https://wiki.yoctoproject.org/wiki/Yocto_1.4_Features
Nov 13 16:08:24 <rburton> YPTM: ross burton here
Nov 13 16:09:04 <eren> YPTM: Eren Turkay here
Nov 13 16:13:28 <Song_Liu> YPTM: https://wiki.yoctoproject.org/wiki/Yocto_1.4_Schedule
Nov 13 16:21:14 <Jefro> Blimp video linked from here: https://www.yoctoproject.org/blogs/jefro/2012/news-elce-barcelona
Nov 13 16:22:50 <eren> Song_Liu: my fullname is "Eren Türkay", btw, if you write it on the logs, I would like to be written in that way :)
Nov 13 16:22:51 <Jefro> devday slides should be available on the website this week
Nov 13 16:23:05 <scottrif> very cool on the blimp... thanks for putting up the link Jefro
Nov 13 16:26:01 <Song_Liu> eren: thanks, sure will
Nov 13 16:31:39 <fray> I had to trace some of this loading for some internal presentations..
Nov 13 16:32:01 <fray> I'm not an expert.. but mostly it's controlled by configuration lines and/or the 'base.bbclass' which is the first one loaded
Nov 13 16:32:18 <eren> fray: yeah
Nov 13 16:32:26 <eren> fray: and package.bbclass, which gets inherited by default
Nov 13 16:32:30 <fray> Documenting this isn't a bad idea.. I touched on it in my introduction to yocto project presentation -- specifying the relative order and configuration files and their purposes..
Nov 13 16:33:04 <mckoan> tis is GREAT !!! https://bugzilla.yoctoproject.org/show_bug.cgi?id=2308
Nov 13 16:33:05 <yocti> Bug 2308: enhancement, Medium, 1.4, ross.burton, ACCEPTED , A small common BSP with graphics for as many platforms as possible (x86)
Nov 13 16:33:13 <sgw1> nice!
Nov 13 16:33:19 <eren> fray: I learned that all the files isntalled to ${D} are copied to staging dir (sysroots)
Nov 13 16:33:20 <sgw1> halstead: well done
Nov 13 16:33:23 <rburton> neat!
Nov 13 16:33:27 <eren> fray: I failed to see that on the documentation
Nov 13 16:33:36 <fray> yes, thats the sysroot setup..
Nov 13 16:33:53 <eren> fray: can you point the part that you touched on the documentation? I mean, the relative order
Nov 13 16:33:56 <halstead> bug 2308
Nov 13 16:33:57 <yocti> Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=2308 enhancement, Medium, 1.4, ross.burton, ACCEPTED , A small common BSP with graphics for as many platforms as possible (x86)
Nov 13 16:34:04 <rburton> halstead: stop reminding me of my bugs! :)
Nov 13 16:34:10 <Jefro> LOL
Nov 13 16:34:14 <fray> this is the intro presentation.. form the dev-day.. it hasn't been posted yet..
Nov 13 16:34:30 <eren> fray: oh okie
Nov 13 16:35:19 <mihai> wow, that's really nice
Nov 13 16:35:24 <fray> eren.. the general load order is:  meta/conf/bitbake.conf, and build/conf/bblayers.conf  those are loaded first..
Nov 13 16:35:35 <fray> the bblayers.conf then causes the <layer>/conf/layers.conf to be loaded in order..
Nov 13 16:35:35 <mckoan> I'm glad to see that many other people has been waiting for 'Bug'/enhancement 2308
Nov 13 16:35:42 <fray> followed by the build/conf/local.conf
Nov 13 16:35:58 <fray> after that everything loaded is controlled by the base.bbclass and various variables that trigger inbuilt inherit's..
Nov 13 16:36:10 <mihai> bug last
Nov 13 16:36:13 <mihai> :D
Nov 13 16:36:15 <fray> general order is distro configuration, followed by machine config, followed by tuning(s), followed by recipes
Nov 13 16:36:37 <eren> fray: thank you. EXPORT_FUNCTION was a bit tricky to get btw. Abstraction through namespaces, I guess
Nov 13 16:36:51 <fray> I still don't get EXPORT_FUNCTION.....
Nov 13 16:36:58 <fray> I know what it does.. but I don't 'get it'
Nov 13 16:37:06 <eren> hehe :)
Nov 13 16:37:37 <fray> from talking to RP, it sounds like many of the export_functions are historical and wrong.. there is still some use to it.. but in many places it's no longer needed..
Nov 13 16:37:44 <RP__> fray: say you have autotools_do_configure, you can then write a do_configure which can call it as a function
Nov 13 16:37:52 <eren> well, I've setup a basic build order into my "hello world" bitbake project. base.bbclass exports do_fetch, do_unpack, etc
Nov 13 16:38:01 <eren> in base.bbclass, I name them base_do_fetch, base_do_unpack ...
Nov 13 16:38:09 <RP__> fray: EXPORT_FUNCTION means there is a default do_configure which just calls autotools_do_configure
Nov 13 16:38:11 <fray> RP__ yes.. but why not just write 'autotools_do_configure' to begin with?  like I said.. I understand what it does.. but I don't 'get it'
Nov 13 16:38:27 <eren> and when a package inherits autotols.bbclass, somehow, autotools_do_configure gets called when I export it in EXPORT_FUNCTIONS do_configure
Nov 13 16:38:54 <eren> instead of base_do_configure, autotools_base_configure is called
Nov 13 16:38:56 <fray> eren, ya.. it's what RP just said.. it helps define defaults and renaming of functions
Nov 13 16:39:03 <RP__> fray: The key piece is the automatic map between do_configure and autotools_do_configure
Nov 13 16:39:39 <fray> RP, ya.. I see it.. but it's very confusing to me..  I'd almost prefer it to be less automatic so it's clearer when reading the code
Nov 13 16:39:58 <RP__> fray: everything would break if it didn't do this
Nov 13 16:40:04 <eren> RP__: when we inherit autotools, how does the mapping is done, btw?
Nov 13 16:40:12 <fray> but it's fine.. I don't usually have to play with that.. justw hen I have found it.. it seems that the export_functions were wrong.. :)  (i.e. all of the rootfs stuff)
Nov 13 16:40:14 <eren> RP__: last inherited piece gets called?
Nov 13 16:40:56 <RP__> eren: The mapping happens at the end of parsing. If do_configure doesn't exist, a mapping from do_configure to autotools_do_configure is added
Nov 13 16:41:22 <eren> but we also write EXPORT_FUNCTION do_fetch do_unpack, do_configure do_make ..... in base.bbclass and define them as base_do_configure() :
Nov 13 16:41:34 <eren> RP__: do_configure exists in base.bbclass, and autotools.bbclass
Nov 13 16:42:07 <eren> how does mapping happend then?
Nov 13 16:42:44 <RP__> eren: ah, autotools overrides that I believe
Nov 13 16:43:06 <eren> yeah, somehow, do_configure becomes autotools_do_configure
Nov 13 16:43:10 <RP__> eren: ah, base declares base_do_configure
Nov 13 16:43:18 <eren> yeah
Nov 13 16:43:27 <RP__> eren: so the last declared EXPORT_FUNCTION wins
Nov 13 16:43:32 <RP__> but only if do_configure is unset
Nov 13 16:44:39 <eren> hm
Nov 13 16:44:56 <Song_Liu> YPTM: thank you all for joining the meeting, you guys have a nice day or evening
Nov 13 16:45:08 <msm> kergoth: looks like RP fixed that issuse
Nov 13 16:45:18 <RP__> think about the problem like this - if you just have a single do_configure and you overwrite it, you can't call the original. This way the original functions are preserved and you can call them
Nov 13 16:46:11 <eren> so, foo.bbclass lastly gets inherited, it declares what functions it has and bitbake maps these functions to foo_some_function
Nov 13 16:46:14 <eren> RP__: right
Nov 13 16:47:08 <eren> thank you for clarification
Nov 13 16:54:07 <eren> it was good to talk to you all! see you later :)
Nov 13 17:25:38 <kergoth> hmm
Nov 13 17:39:08 <kergoth>   File "/scratch/mel/qemu/poky/bitbake/lib/bb/ui/knotty.py", line 302, in main
Nov 13 17:39:08 <kergoth>     time.sleep(event.sleep_delay)
Nov 13 17:39:08 <kergoth> UnboundLocalError: local variable 'time' referenced before assignment
Nov 13 17:39:11 * kergoth looks
Nov 13 17:40:04 * kergoth kills the extra time import in the exception handler
Nov 13 18:39:38 <dvhart> zeddii, hoping your memory is better than mine. I have a note in the linux-yocto documentation which reads "
Nov 13 18:39:38 <dvhart> # TODO: verify hardware, verify non-hardware (open bug)" right after the section where the fri2-standard.scc includes a few things that should really just be in standard.scc
Nov 13 18:39:51 <dvhart> zeddii, was that just to get those moved into standard.scc?
Nov 13 18:40:00 <dvhart> or do you recall if there was more to it?
Nov 13 18:40:02 <zeddii> yep.
Nov 13 18:40:12 * dvhart nods
Nov 13 18:40:18 <zeddii> it was that 'nocfg' has config as well IIRC.
Nov 13 18:40:34 <dvhart> that was maybe something else.... I saw that in there too
Nov 13 18:40:37 <dvhart> I'll open bugs for both
Nov 13 18:40:41 <dvhart> two to go
Nov 13 18:40:55 <dvhart> would you please review, size, and choose those you'll do for M2 ?
Nov 13 18:41:07 <zeddii> cool. I'll go on a bug blitz shortly, just finishing the test of the rt29 update and v3.4.18 now.
Nov 13 18:41:09 <dvhart> we need everything sized by the end of the week (per the call today)
Nov 13 18:41:15 <dvhart> nice
Nov 13 18:41:18 <zeddii> dvhart, will do. I'll do the sizing right away.
Nov 13 18:42:05 * zeddii goes to hunt coffee
Nov 13 18:42:18 <dvhart> zeddii, oh wait - remind me again what .scc stands for?
Nov 13 18:47:09 <zeddii> (s)eries (c)configuration (c)ontrol
Nov 13 18:49:33 <dvhart> thanks
Nov 13 18:49:36 <dvhart> zeddii, all bugs opened
Nov 13 18:49:56 <zeddii> I'd say 'thanks', but that that seems wrong. ;)
Nov 13 18:54:44 <dvhart> zeddii, ;-)
Nov 13 19:00:37 <fray> hey, is the blacklist class enabled by default, what I'm seeing seems to indicate it is -not- on by default
Nov 13 19:26:02 <sgw1> kergoth: can you take a quick look at bug 3382, this seemed to be introduced with your recent add error patch
Nov 13 19:26:03 <yocti> Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=3382 normal, Medium+, 1.4 M1, saul.wold, NEW , bug in hob or bitbake - bb.utils.mkdirhier?
Nov 13 19:27:53 <kergoth> sgw1: that was fixed by 4e2b5a59299610c06f9a5fb6fcd103d6946da41a
Nov 13 19:28:02 <kergoth> afaict anyway
Nov 13 19:29:02 <sgw1> kergoth: really, seems un-related, but I can check
Nov 13 19:29:11 <kergoth> it's not unrelated
Nov 13 19:29:47 <kergoth> the other code calls get_logfile(), which uses self.current_log or whatever, which called runCommand()
Nov 13 19:29:56 <sgw1> ok
Nov 13 19:30:18 <kergoth> the commit i mentioned fixed hob's acquisition of the logfile, and the above bug is just attempted use of that log file
Nov 13 19:37:32 <sgw1> kergoth: thanks, confirmed as fixed, I am lousy when it comes to the bitbake core and hob, thanks for the pointer.
Nov 13 19:42:27 <kergoth> np
Nov 13 19:55:35 <eren> huh, writing a documentation is time consuming
Nov 13 19:56:04 <kergoth> s/a documentation //
Nov 13 19:56:57 <eren> right
Nov 13 19:57:24 <eren> you write one sentence over and over and over again until it fits
Nov 13 21:08:33 <walters> anyone here with cmake-fu?  i'm hitting http://pastebin.mozilla.org/1939662 trying to build llvm from meta-java
Nov 13 21:10:42 <walters> some sort of combination of llvm requiring out-of-tree builds along with the cmake rules attempting to dynamically add a per-target subdirectory?  the original rules are from https://github.com/woglinde/meta-java/tree/master/recipes-core/llvm
Nov 13 21:16:50 <RP__> Me: "Do you know about the flood at X roundabouts" Water company: "we sent a lad out". I think the lad may need reinforcements as its a 15" main that's blown but I guess they'll figure that out shortly...
Nov 13 21:17:18 <dvhart> heh
Nov 13 21:17:38 <fray> eek!
Nov 13 21:18:43 <RP__> The roundabouts are underwater with a river starting to head downhill when I drove through there a few minutes ago...
Nov 13 21:19:11 <fray> ouch
Nov 13 21:20:19 <RP__> Last time the main went near there it was taking out lampposts around the burst
Nov 13 21:24:29 <nitink> khem: ping
Nov 13 21:27:22 <walters> ok, turns out it just blows up compiling for X86 because LLVM_TARGETS_TO_BUILD="X86;${LLVM_ARCH}", so it's specified twice, with the resulting poor consequences for cmake's sanity
Nov 13 21:29:20 <RP__> walters: cmake is a black box to me, I can never seen to get it to do what I need :/
Nov 13 21:29:37 * RP__ wishes libtool still was a black box
Nov 13 21:29:45 <RP__> I managed to avoid it for years...
Nov 13 21:30:04 <B4gder> you were lucky! =)
Nov 13 21:30:16 <walters> RP__, this is my first debugging-in-anger experience with it...so far, i can at least be happy that it's not m4
Nov 13 21:30:40 <RP__> walters: that is something at least :)
Nov 13 21:32:39 <B4gder> my main gripes with cmake tend to be that nobody knows it
Nov 13 21:32:52 <B4gder> libtool and autoconf are still used widely and thus known more
Nov 13 21:33:09 <B4gder> or perhaps that's just my dusty corner of the world
Nov 13 21:33:34 <walters> interestingly llvm ships with both autoconf and cmake
Nov 13 21:33:46 <B4gder> we do that in curl too
Nov 13 21:33:57 <B4gder> only to have the cmake side lag behind terribly
Nov 13 21:34:03 <walters> i pushed back hard against having two build systems in dbus
Nov 13 21:34:15 <B4gder> wise, I'd say
Nov 13 21:34:40 <walters> however, both of these are a lot better than the MSVC crap we carry in the gtk+ stack =/
Nov 13 21:35:16 <B4gder> oh yes
Nov 13 21:41:55 <RP__> walters: er, yes. I'm pleased I don't have to touch that...
Nov 13 21:42:54 <walters> i think the main issue is that cross-built binaries via mingw32 don't have adequate debugging information for whatever the windows debugger is
Nov 14 00:46:02 <evanp> apparently the D toolchain includes a DWARF to PDB converter. I guess everybody who's looked at doing that for mingw must have run screaming from the room, though....
**** ENDING LOGGING AT Wed Nov 14 02:59:59 2012

**** BEGIN LOGGING AT Wed Nov 14 03:00:00 2012
Nov 14 09:04:01 <mckoan> good morning
Nov 14 12:01:34 <otavio> Anyone going to work in alsa update?
Nov 14 12:01:36 <otavio> for 1.4
Nov 14 12:05:31 <bluelightning> otavio: Cristian Iorga is the maintainer for most of the alsa recipes according to meta-yocto/conf/distro/include/maintainers.inc
Nov 14 12:05:47 <otavio> And is he around?
Nov 14 12:06:12 <otavio> Fabio made two patches worth including during the update.
Nov 14 12:07:11 <otavio> http://git.alsa-project.org/?p=alsa-tools.git;a=commit;h=848e26d10e5d11e33727c318bd2f9eb5cf93e67f and http://git.alsa-project.org/?p=alsa-utils.git;a=commit;h=c6614dbdab1cbe541e7d6cd29f3922510e0b6981
Nov 14 14:12:39 * kergoth yawns and stretches
Nov 14 14:52:25 * kergoth tests out the latest console color patch.. looks nice, helps the eye jump to important bits
Nov 14 14:57:07 * bluelightning couldn't do without coloured diffs certainly, so I can see this being something worth having
Nov 14 14:57:25 <kergoth> it's amazing how much color helps your eye navigate
Nov 14 14:57:28 <kergoth> in general, that is
Nov 14 15:12:07 <kergoth> sigh, everything rebuilding from source for no apparent reason again, after making small changes. really need to nail down some of these
Nov 14 15:12:16 <kergoth> must need some more whitelisting/vardepsexclude
Nov 14 15:13:31 <JaMa> sstate bbclass change?
Nov 14 15:15:58 <RP__> We've had a lot of changes going into the core classes recently...
Nov 14 15:45:16 <fray> hey whats the bitbake command to figure out if something is going to rebuild -- and why?
Nov 14 15:49:08 <bluelightning> fray: you can only do it after the fact at the moment
Nov 14 15:49:21 <fray> ok.. so once it's done building, is the build history enough or?
Nov 14 15:49:26 <bluelightning> fray: robert wrote a script that was supposed to do it before, but it had some issues and never got merged
Nov 14 15:49:33 <fray> I added a layer and everything is rebuilding.. I'd like to know what changed..
Nov 14 15:49:39 <bluelightning> fray: the siginfo files are used
Nov 14 15:49:44 <bluelightning> (by bitbake-diffsigs)
Nov 14 15:50:19 <bluelightning> however, there is a limitation in master that prevents it from working to its full capability, see bug 3411
Nov 14 15:50:20 <yocti> Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=3411 normal, Undecided, ---, paul.eggleton, NEW , Preserve siginfo files
Nov 14 15:51:33 <fray> Hmm
Nov 14 15:54:54 <fray> bluelightning since the siginfo files are not preserved, how do you use it then?
Nov 14 15:55:50 <bluelightning> fray: it can check through the files in the shared state cache as well, but that only helps if the tasks you need to traverse are handled by shared state
Nov 14 15:56:15 <fray> I assume the reason it was rebuilt will be the same for all..
Nov 14 15:56:26 <bluelightning> fray: it worked until a change to clean out stamps for previous runs of a task got merged late in the 1.3 cycle :(
Nov 14 15:56:39 <fray> is there an example usage to show how to use it?
Nov 14 15:57:25 <bluelightning> bitbake-diffsigs help text is all that exists
Nov 14 15:57:37 <fray> ya.. I don't know what it means by 'sigdatafile'
Nov 14 15:57:55 <fray> the recipename/taskname is obvious.. but you said -t doesn't work
Nov 14 15:59:49 <bluelightning> by "sigdata file" it means the siginfo files in the sstate-cache dir or the sigdata files in the stamps dir
Nov 14 16:00:08 <bluelightning> -t was supposed to make this easy
Nov 14 16:00:11 <bluelightning> :/
Nov 14 16:00:29 <RP__> We need to stop it deleting the sig* files...
Nov 14 16:00:46 <bluelightning> RP__: or copy them out somewhere else before deleting
Nov 14 16:01:30 <bluelightning> at least the latter would make them easier to clear out
Nov 14 16:03:49 <fray> Hmm.. it was the definition of 'CXX_toolchain-example' (LD, CC< and CPP)
Nov 14 16:04:10 <fray> the recipe isn't using those though.. so why would that have affected the checksum?
Nov 14 16:28:32 <zecke> bluelightning: how are the names like edison? danny? picked
Nov 14 16:30:01 <bluelightning> zecke: actually I don't know... you could ask RP but I think he will decline to answer, it's supposed to keep things interesting
Nov 14 16:30:43 <RP__> bluelightning: "supposed"? :)
Nov 14 16:31:24 <bluelightning> RP__: I liked being one of the few who "got the reference" for the last series :)
Nov 14 16:31:59 <bluelightning> can't have everything I suppose
Nov 14 16:33:06 <zecke> RP__: did you consider increasing the first letter on the release (wrap around in ascii is fine)... I don't follow Yocto releases too closely and I always wonder if edison was before denzil and now danny is after denzil. :)
Nov 14 16:35:28 <mranostay> so does a Disk Full message from the hdddirect image step bad? :)
Nov 14 16:42:50 <fray> I figured out hte problem.. I had done 'export'.. which apparently means it always has to be available..
Nov 14 16:47:32 <fray> excellent.. the secondary toolchain is now working right and not killing the hash  ;)
Nov 14 16:48:06 <kergoth> best to only export anything when absolutely necessary. we actually export more than we should already
Nov 14 16:48:09 <kergoth> heh
Nov 14 16:55:08 <RP__> zecke: it was considered but wasn't possible by the time it ended up being considered :/
Nov 14 16:55:38 <RP__> fray: ah, yes. You don't want the export :)
Nov 14 16:56:07 <RP__> kergoth: what shouldn't we be exporting out of interest?
Nov 14 16:59:57 <kergoth> bindir, base_bindir, includedir, etc, TARGET_CXXFLAGS, etc. the pkgconfig vars could probably be safely moved into the wrapper. BUILD_* aren't consistently used in makefile based buildsystems, so i'm sure exporting those is of limited usefulness..
Nov 14 17:00:09 <kergoth> thats from a 3 minute look at bitbake.conf
Nov 14 17:00:11 <kergoth> heh
Nov 14 17:01:12 <kergoth> of course, if we were to add the ability to export vars on a per-task basis, we could reduce the export leakage greatly, since CFLAGS, etc are only needed in do_configure for autotools and do_compile for ordinary make
Nov 14 17:02:03 <bluelightning> surely there is the chance that you'd break existing recipes that are currently paying attention to any of those vars if you did remove them though...?
Nov 14 17:02:39 <kergoth> that's the difficulty in changing it, once its exported, trying to get rid of it is a giant pain
Nov 14 17:03:18 <kergoth> i doubt anyone used bindir, etc but autotools.bbclass and the like, though, and they use bitbake variables, not shell variables. still a risk, of course. buildhistory would probably help
Nov 14 17:03:43 <kergoth> ou're right though, definitely nontrivial. much of it is remnants from when we first populated bitbake.conf, i think
Nov 14 17:08:47 <kergoth> RP__: nice job on the python intermediate staging stuff, that's a great simplification. all the interpreter recipes are voodoo, but that's a step in the right direction :)
Nov 14 17:10:05 <kergoth> hmm, should probably update the bash recipe to use the latest 4.2 patches upstream, they're up to patch 039 now
Nov 14 17:10:18 <kergoth> forgot to push that
Nov 14 17:10:25 * kergoth mutters and wanders off
Nov 14 17:24:13 <RP__> kergoth: thanks, I wasn't happy with the hacks to sysconfig.py but its better than it was before...
Nov 14 17:27:29 * kergoth nods
Nov 14 17:36:57 <kergoth> getting the sstate rename failures here as seen on the list even with current poky master
Nov 14 17:37:02 <kergoth> heh
Nov 14 17:52:08 <bramming> Hello. I had a quick Yocto question and was hoping someone might be able to help answer it: Does Yocto save off the warnings and errors in a common directory ?
Nov 14 17:56:11 <kergoth> see the overall build log in tmp/log/
Nov 14 17:59:04 <bramming> oh excellent! found the log i was looking for
Nov 14 17:59:06 <bramming> thanks
Nov 14 17:59:50 <kergoth> and of course each task of each recipe has its own log as well, buried in tmp/work/<triplet>/<recipe - version - revision>/temp/
Nov 14 18:04:26 <bramming> has anyone encountered a warning about variables containing tabs? I just started to port my layer to Yocto 1.3 and noticed warnings like: WARNING: Variable pcbios contains tabs, please remove these (/home/remlab/yocto1.3/poky-danny-8.0/build/../meta/recipes-core/images/core-image-base.bb)
Nov 14 18:04:54 <bramming> i can easily go in there and remove them, just htought I would ask about them
Nov 14 18:06:55 <kergoth> yep, we require more indentation consistency than we used to
Nov 14 18:07:30 * kergoth ponders
Nov 14 18:09:10 <bramming> im actually looking at these files it mentions but not finding the variables it talks about. Guess is they are located in other files that are inherited?
Nov 14 18:09:34 <kergoth> check included/required/inherited files
Nov 14 19:40:41 <kergoth> gah, more sstate errors
Nov 14 19:40:44 <kergoth> hmm
Nov 14 20:24:39 <kergoth> wtf. i just completed a core-image-minimal, then kicked off a core-image-base and it's rebuilding tar-replacement-native
Nov 14 20:24:43 * kergoth sighs
Nov 14 20:48:47 <fray> odd, that is something I haven't seen
Nov 14 21:08:56 <blloyd_> is there a ntp client in the yocto repository I'm overlooking?
Nov 14 21:26:09 <mihai1> blloyd_: use ntpd of busybox
Nov 14 21:37:27 <blloyd_> i'd sort of found that, but going through busybox.inc I can't figure how to get it to install.
Nov 14 21:42:34 <mihai1> blloyd_: if there is not a symlink there somewhere with ntpd, you can call it with `busybox ntpd`, i guess busybox.inc doesn't make one for ntpd
Nov 14 21:48:40 <blloyd_> mihail: busybox ntpd ==> applet not found.  The busybox.inc has NTP support disabled.
Nov 14 22:10:08 <blloyd_> question about bitbake append files.  Is there a way to rename an existing function so it can be redifined and the redefined function call the original function?
Nov 14 22:13:53 <evanp> blloyd_: I'd bet anonymous python could arrange that. Maybe d.renameVar()
Nov 14 22:15:09 <fray> blloyd_ well functions may be interchangable with variables.. I'm not sure..
Nov 14 22:15:18 <fray> you could always try (in the .bbappend)
Nov 14 22:15:34 <fray> foo_do_configure := ${do_configure}
Nov 14 22:15:38 <fray> do_configure () {
Nov 14 22:15:39 <fray>  ...
Nov 14 22:15:40 <fray> }
Nov 14 22:15:47 <fray> it -might- do what you want..
Nov 14 22:15:55 <fray> otherwise I'd say the anon python is the best alternative
Nov 14 22:16:33 <fray> but usually you don't need (or want) to rename.. you'd rather prepend or append to the existing component.. so do_configure_prepend and do_configure_append is what you'd use in that example
Nov 14 22:44:41 <blloyd_> I think I'll do do_install_prepend and do_install_append then.  :)
Nov 14 22:44:49 <blloyd_> and thanks for that information fray
Nov 14 23:16:10 <yocto621> Hello Yocto
Nov 14 23:16:45 <yocto621> I was wondering, if any one knew the plans for webkit2 bb/recipe file?
Nov 14 23:18:50 <yocto621> any one?
Nov 14 23:25:15 <kergoth> i'd suggest looking at the meta-browser layer
Nov 14 23:25:22 <kergoth> http://www.openembedded.org/wiki/LayerIndex
Nov 14 23:33:45 <yocto621> kergoth: i dont see webkit2 in any of them
Nov 14 23:34:06 <yocto621> i think its still needs to be planned by some one
Nov 14 23:40:38 * RP__ wonders what will go wrong today next
Nov 14 23:41:24 <RP> In case anyone has been seeing nasty looking sstate errors, I just pushed a version change for sstate since I've managed to "break" the layout by fixing bugs
Nov 14 23:46:16 <JaMa> thanks
Nov 14 23:47:42 <JaMa> btw: it should also resolve those warnings about rewritting .ipk files from do_package no longer machine specific
Nov 14 23:48:07 <RP> JaMa: I'm not sure it will do that...
Nov 14 23:48:38 <JaMa> ah :/ dumping sstate-cache dir does resolve that
Nov 14 23:51:55 <yocto621> JaMa, RP, do u guys have any idea about Webkit2 bb file?
Nov 14 23:53:48 <JaMa> yocto621: no, webkit-efl, webkit-gtk only afaik
Nov 14 23:56:29 <yocto621> JaMa: ok, so no one in the community have plans for Webkit2?
Nov 14 23:57:38 <JaMa> I cannot speak for everybody, but some people want qt5 to be able to work on webkit2-qt
Nov 15 00:00:28 <yocto621> JaMa: I understand :), thanks for your time
Nov 15 00:32:26 <mranostay> *sigh* anyone have any ideas on why do_bootdirectdisk would be getting a "Disk full" message?
Nov 15 00:32:46 <mranostay> on the first run only
**** ENDING LOGGING AT Thu Nov 15 02:59:58 2012

**** BEGIN LOGGING AT Thu Nov 15 02:59:59 2012
Nov 15 09:32:18 <bluelightning> morning all
Nov 15 14:31:14 <halstead> OSU Open Source Lab is preforming network upgrades. Everything is working well but connections will be interrupted and will need to be re-established.
Nov 15 14:34:49 <kergoth> morning
Nov 15 14:36:50 <halstead> Good morning. :)
Nov 15 14:36:51 <ocallesp> morning here in Mexico
Nov 15 14:40:22 <bluelightning> morning
Nov 15 16:07:30 <kergoth> hmm, i wonder if images could remove their nostamp for BasicHash. you'd think any changes to packages, etc would flow down and cause a rerun of that task anyway
Nov 15 16:15:01 <kergoth> what the hell, i think i did something that broke the pysh dependency parsing
Nov 15 16:15:10 <kergoth> it didn't emit a shell function that's absolutely being called
Nov 15 16:15:14 * kergoth scratches head
Nov 15 16:15:39 <fray> kergoth, depending on how it's called, it doesn't always emit..
Nov 15 16:15:48 <fray> there is a simple workaround (used in many palces) to make it work
Nov 15 16:15:58 * fray finds an example
Nov 15 16:16:26 <kergoth> then that's a bug, and we should fix it
Nov 15 16:16:31 <kergoth> is there a bug in the bugzilla about this?
Nov 15 16:16:39 <fray> When I brought it up before, RP said it wasn't a bug because of the usage
Nov 15 16:16:51 <kergoth> hmm, an example would be helpful
Nov 15 16:16:55 <kergoth> no rush though
Nov 15 16:16:56 <fray> looking for it
Nov 15 16:17:02 <kergoth> thanks
Nov 15 16:17:30 <kergoth> in this case i'm just calling it from $(), which i explicitly handled when i did the original code.. :\
Nov 15 16:17:30 <fray>         # Workaround so the parser knows we need the resolve_package function!
Nov 15 16:17:30 <fray>         if false ; then
Nov 15 16:17:30 <fray>                 resolve_package_rpm foo ${RPMCONF_TARGET_BASE}.conf || true
Nov 15 16:17:30 <fray>         fi
Nov 15 16:17:30 <fray> }
Nov 15 16:17:34 <fray> from rootfs_rpm.bbclass
Nov 15 16:18:13 <RP> kergoth: its the case where you construct a function name from variables and call it
Nov 15 16:18:14 <fray> trying to remember the issue -- this might be obsolete though
Nov 15 16:18:20 <fray> there ya go
Nov 15 16:18:43 <fray>     # Workaround for broken shell function dependencies
Nov 15 16:18:43 <fray>     if false ; then
Nov 15 16:18:43 <fray>         get_split_linguas
Nov 15 16:18:43 <fray>     fi
Nov 15 16:18:43 <fray> }
Nov 15 16:18:46 <fray> thats from image.bbclass
Nov 15 16:18:55 <fray>         SPLIT_LINGUAS=`get_split_linguas`
Nov 15 16:19:03 <fray> thats the usage that doesn't 'work' w/o the if false
Nov 15 16:19:06 <kergoth> RP: doesn't look like it to me. it's just calling package_internal_install_rpm, which references resolve_package_rpm in a $() block
Nov 15 16:19:17 <kergoth> yeah, that's just a bug imo, that should be working
Nov 15 16:19:39 <RP> kergoth: it used to be constructed I think. The code has since changed and the workaround probably isn't necessary anymore
Nov 15 16:19:50 <fray> (the rpm case appears to be obsolete.. the iamge case though is a current example)
Nov 15 16:20:38 <kergoth> RP: well, i have an xample right here that's failing to spot the dependency in a simple call in a $()
Nov 15 16:20:41 <kergoth> heh
Nov 15 16:21:49 * kergoth digs
Nov 15 16:22:16 <fray> $(...) and `...` is the same theoretically
Nov 15 16:24:36 <kergoth> yeah, it should be identifying those calls, there's handling for it
Nov 15 16:24:45 <RP> kergoth: ok, I'm going off memory here so it could be I'm remembering incorrectly :/
Nov 15 16:29:32 <kergoth> I know how that is, all too well :)
Nov 15 16:29:47 <kergoth> will look into it, and open a bug if appropriate
Nov 15 16:33:38 * kergoth ponders
Nov 15 17:24:05 <bluelightning> http://www.burtonini.com/wordpress/2012/11/15/yocto-build-times/
Nov 15 17:28:33 <bluelightning> Crofton: ^
Nov 15 17:32:58 <bramming> Hello all. I am building my image with Yocto 1.3 and I notice a lot of warnings that state "Failed to fetch URL ftp..." However, i was able to use wget on them just fine.
Nov 15 17:33:17 <bramming> should i be concerned about these warnings?
Nov 15 18:14:00 <kergoth> there certainly is a lot of marketing / buzzwords in use on baserock.com. looks like the whitepaper is the only real detail anywhere on the site
Nov 15 18:18:51 <kergoth> "Baserock leverages the synergy of reproducible builds." .. haha
Nov 15 18:19:01 <kergoth> i think i'd win buzzword bingo, reading this
Nov 15 18:19:30 <kergoth> seems interesting, otherwise, though
Nov 15 18:50:17 <holgerwrs> can a layer apply to be Yocto compatible?  or just a Yocto Project based project?
Nov 15 18:56:20 <fray> AFAIK any layer can apply to be Yocto Project compatible..
Nov 15 18:56:32 <fray> it just has to meet the requirements for compatibility and be accepted by the board
Nov 15 18:57:38 <holgerwrs> what to put under "Project" then? <- https://www.yoctoproject.org/webform/yocto-project-compatible-registration
Nov 15 18:58:00 <holgerwrs> *project name
Nov 15 18:58:58 <holgerwrs> just the layer I assume
Nov 15 19:00:15 <holgerwrs> or maybe... are layer which are hosted on yoctoproject.org compatible by definition?
Nov 15 19:00:32 <holgerwrs> example: meta-ivi
Nov 15 19:00:56 <holgerwrs> asking myself if I shall register or not
Nov 15 19:10:27 <fray> not necessarily
Nov 15 19:11:37 <holgerwrs> that's a "its depends" in new English, isn't it ;)
Nov 15 19:11:44 <holgerwrs> *it
Nov 15 19:12:56 <holgerwrs> in which case wouldn't it be necessary?
Nov 15 19:22:10 <msm> can anyone suggest some reading wrt to GNU_HASH?
Nov 15 19:26:18 <B4gder> http://sourceware.org/ml/binutils/2006-10/msg00377.html
Nov 15 19:41:47 <msm> B4gder: thanks!
Nov 15 19:52:47 <kergoth> nice, i should read that too :)
Nov 15 20:16:27 <fray> Just got this:
Nov 15 20:16:27 <fray> update-alternatives: Error: cannot register alternative rmt to /usr/lib/tar/rmt since it is already registered to /usr/lib/cpio/rmt
Nov 15 20:17:44 <fray> ahh it's the libexecdir change! drat
Nov 15 20:19:37 <JaMa> all hail to FHS
Nov 15 20:20:17 <fray> I'd wager that int he cpio and tar case, the default libexecdir is now wrong..
Nov 15 20:20:22 <fray> I'm just not sure what it 'should' be
Nov 15 20:21:40 <fray> interesting.. Fedora puts it into sbin.. :P
Nov 15 20:23:42 <fray> or they don't install it at all.. nice
Nov 15 20:24:03 <fray> (not that Ir eally think we need rmt on most embedded systems.. but we need a fix)
Nov 15 20:25:42 <kergoth> probably best not to assume what will be and won't be used, too. people have added recipes for some crazy stuff :)
Nov 15 20:25:56 <fray> I'm breaking rmt into a sub-package..
Nov 15 20:26:05 <kergoth> good plan
Nov 15 20:27:23 <fray> does it make sense to move it out of /usr/lib?  say /sbin or /usr/sbin/
Nov 15 20:27:24 <fray> ?
Nov 15 20:47:08 * fray is going to assume /sbin is as good of a place as any
Nov 15 20:47:14 <evanp> Anybody ever seen target binaries (for me it's zypper) complain about R_X86_64_32 relocation overflows? maybe a year ago, or with a pre-release binutils? Pretty sure this has nothing to do with Yocto (rather my forked binutils), but wanted to tap the collective memory....
Nov 15 20:47:39 <fray> that sounds like a 'x32' issue
Nov 15 20:47:48 <fray> are you building x32 or x86-64?
Nov 15 20:49:25 <evanp> neither, it's k1om; closer to x86-64. I was thinking that too, but I was pretty certain my binutils was forked before x32 went in....
Nov 15 20:50:01 <fray> ok.. I don't know then...
Nov 15 20:50:14 <fray> zypper is C++ based..  (and uses boost).. so it's possible something went wrong there
Nov 15 20:51:43 <evanp> the relocations in question are all "typeinfo for blablahException", which is kinda interesting
Nov 15 20:52:19 <fray> sounds C++ to me
Nov 15 20:57:56 <evanp> yeah that's if I pipe stderr though c++filt, otherwise it's some mangled gobledygook
Nov 15 21:01:20 <RP> holgerwrs: to be clear, being on git.yp.org is no guarantee of yocto project compatible status
Nov 15 21:01:31 <RP> I can think of several things hosted there which are not
Nov 15 21:02:54 <kergoth> RP: not sure if you saw, but there's a README on meta-mentor now in master too
Nov 15 21:02:56 <kergoth> heh
Nov 15 21:03:11 * kergoth should have done that a long time ago
Nov 15 21:03:12 <RP> kergoth: I did notice and appreciate it, thanks :)
Nov 15 21:03:17 <kergoth> np
Nov 15 21:03:59 <kergoth> i added a review of all the content in the layer to it, I find it really helpful to be able to see *why* all this stuff exists without digging into the git history.. now to just keep it current, is the challenge..
Nov 15 21:04:04 <kergoth> heh
Nov 15 21:04:08 <kergoth> oh well
Nov 15 21:04:30 * kergoth kicks off a world build
Nov 15 21:05:33 <RP> kergoth: We face a few challenges like that but I think we're making good progress in general. Occasional speed bumps but such is life :)
Nov 15 21:06:01 <kergoth> indeed
Nov 15 21:06:10 * RP is playing with accelerated sstate (i.e. skipping some sstate tasks depending on context)
Nov 15 21:07:01 <RP> I should probably worry that the application of alcohol makes visualising the problems easier. I haven't had this feeling since I tried writing FORTRAN :/
Nov 15 21:07:37 <holgerwrs> RP: so I will go and get meta-ivi registered. thanks.
Nov 15 21:11:55 <jwessel> RP did you ever get the additional patches I sent you about that acceleration stuff?
Nov 15 21:12:15 <jwessel> I never heard back from you with our 3rd round on that particular topic.
Nov 15 21:14:59 <RP> jwessel: I'm looking at those patches again and there are some issues in there
Nov 15 21:15:39 <RP> jwessel: I've been working on ironing them out today, its not done yet though. I can at least now put my finger on what the problem is (missing information)
Nov 15 21:16:31 <jwessel> I had not heard back, so it was not clear to me if I needed to execute further work.
Nov 15 21:16:48 <kergoth> https://bugzilla.yoctoproject.org/show_bug.cgi?id=3449 - think I'll be diving into this one in the near future if there's no objection
Nov 15 21:16:49 <yocti> Bug 3449: normal, Undecided, ---, richard.purdie, NEW , archiver doesn't interact well with sstate
Nov 15 21:16:56 <kergoth> heh, cute
Nov 15 21:16:57 <RP> jwessel: I think I didn't have enough time to formulate a useful reply, sorry
Nov 15 21:16:59 <kergoth> didn't know about that bot
Nov 15 21:17:18 <jwessel> I'd like to roll the stuff into production on my end for our load testing and such, but wasn't going to do until we completed our next round of comments and cycling through corner cases between you and I.
Nov 15 21:17:50 <jwessel> RP: Things will only get better once we get it fixed the "right way" :-)
Nov 15 21:18:24 <RP> jwessel: as posted, those patches are simply broken and I've now found holes in the core dependencies :/
Nov 15 21:18:53 <RP> (do_rootfs is missing a rrecdeptask on do_package for example)
Nov 15 21:19:01 <jwessel> RP: You mean with what you have currently for example.
Nov 15 21:19:21 <jwessel> Yes, and that is the next round of problems beyond the ones that I sent you further comment about.
Nov 15 21:19:34 <RP> kergoth: If you're going to take that one on could you take ownership please? :)
Nov 15 21:19:44 <kergoth> will do
Nov 15 21:20:15 <RP> kergoth: thanks, makes it clearer who is doing what
Nov 15 21:20:23 <jwessel> RP: I assume I'll hear back from you on the next round some time in the near future then, and I'll take another crack at all the corner cases I know about.
Nov 15 21:20:44 <RP> jwessel: You will hear back from me, probably with a rewrite of the patch
Nov 15 21:21:04 <jwessel> I was debating about fixing the colorization patch further.   I must say I do like the colorization.
Nov 15 21:21:12 <jwessel> Enough so that I was willing to fix it ;-)
Nov 15 21:21:18 <RP> jwessel: I did warn you I wrote the original on a plane, jetlagged ;-)
Nov 15 21:21:37 <RP> jwessel: I don't think it should be hard to fix the logging issue with it
Nov 15 21:22:40 <jwessel> RP: There are two ways to fix it.  Either the knotty should colorize on its "console" handler that it attaches to the logfilter, or the file handler filter should strip it.
Nov 15 21:23:05 <RP> jwessel: or we subclass the handler
Nov 15 21:23:20 <jwessel> I don't know that the colorization code belongs with the msg.py for example.
Nov 15 21:23:25 <RP> jwessel: which is probably what you mean by knotty doing it I guess
Nov 15 21:23:31 <RP> jwessel: that bothers me too
Nov 15 21:23:54 <kergoth> agreed, that bugs me also
Nov 15 21:23:56 <jwessel> It is ok to have a general call back for colorizing a record, but doing it in msy.py really bothered me.
Nov 15 21:24:35 <kergoth> subclassing the formatter and constructing two formatters, one for each handler, should work well enough, would think
Nov 15 21:24:40 <jwessel> If I fix it, I was going to move that and have a different subclass that does the formatting.
Nov 15 21:25:10 <jwessel> kergoth: Yup, something like that was the general idea, since the python logger has a "formatter" which you can just inherit and change.
Nov 15 21:25:37 <kergoth> I rather dislike the way the levelname is bolded, also. hardcoded in the formatting code rather than being in a format string or something..
Nov 15 21:26:19 <RP> kergoth: agreed
Nov 15 21:26:42 * RP likes the general idea of colour, we just need to tweak the details
Nov 15 21:27:12 <jwessel> I don't know if I'll get to it, but if no one else does it, I'll probably work on it at some point because I like the end result.
Nov 15 21:34:34 <kergoth`away> does anyone ever remember the argument order for super()? that's the main reason I don't use it, actually.. well, that and never using multiple inheritence
Nov 15 21:35:58 <RP> kergoth`away: I never remember without looking it up :/
Nov 15 21:53:48 <kergoth`away> RP, jwessel: https://github.com/borntyping/colorlog/blob/master/colorlog/colorlog.py looks like a rather clean implementation, it just adds everything as additional record fields, so they can be used from the format string.
Nov 15 21:58:35 <jwessel> kergoth: That is the kind of implementation I was talking about, and it looks like someone put it together 90% of what we need.
Nov 15 21:59:04 <kergoth> that's one of the cleanest ones i've seen
Nov 15 21:59:29 <jwessel> The super thing was the part I was going to have to look up which stopped me from doing it outright this morning.
Nov 15 21:59:44 <jwessel> I didn't know how in python speak to call original routine with super.
Nov 15 22:00:09 * kergoth nods
Nov 15 22:00:26 <jwessel> And of course we need to do that, because of the whole "utf" format foo, and I wasn't about to "copy" code :-)
Nov 15 22:00:28 <kergoth> the args are self and the current class, but i can never remember which goes first, always have to pydoc it
Nov 15 22:01:18 <kergoth> i guess we could just pull in that colorlog module the way we do progressbar, as a dependency + local copy for direct in-scm use, if we want to be nice
Nov 15 22:01:52 <jwessel> kergoth: Thanks for the pointer, I'll probably go and fix the patch myself.
Nov 15 22:02:06 <jwessel> Well the colorlog as is doesn't fix the transparency issue.
Nov 15 22:02:32 <jwessel> But we could take it as the base version and modify it.
Nov 15 22:02:40 <kergoth> ah, but we could subclass it and add transparency to its map member
Nov 15 22:02:41 <jwessel> e.g. stack the changes we want on top.
Nov 15 22:02:41 * kergoth nods
Nov 15 22:03:09 <jwessel> That might work too.  I'll have a look see tomorrow.
Nov 15 22:03:12 <kergoth> it's a small thing to add a dependency for, but it also seems silly to duplicate it when it does the job
Nov 15 22:03:26 <kergoth> so doing waht we do with progressbar is a decent comprimise
Nov 15 22:03:30 <kergoth> compromise
Nov 15 22:32:48 <kergoth> just completed a mel-release and now it's re-running sstate tasks for things it already built earlier
Nov 15 22:32:53 * kergoth shakes head
Nov 15 22:33:06 <kergoth> (mel-release includes core-image-base, which pulled in the rest0
Nov 15 22:58:14 <halstead> sgw1, All of the builds failed except p1022ds which is still in progress due to corruption in bb_persist_data.sqlite3.
Nov 15 22:58:53 <halstead> sgw1, I've fixed the database. Shall I stop the build and start a new one or let p1022ds finish?
Nov 15 23:23:55 <scottrif> halstead: ping
Nov 15 23:24:09 <halstead> scottrif, pong.
Nov 15 23:24:37 <scottrif> halstead: has the https://wiki.yoctoproject.org/collab wike password been changed?
Nov 15 23:24:45 <scottrif> mine no longer work
Nov 15 23:24:54 <scottrif> s/wiki/wike
Nov 15 23:25:07 <halstead> One sec.
Nov 16 00:00:18 <mranostay> hmmm where does task-base get pulled in?
Nov 16 00:02:16 <bluelightning> mranostay: if your image inherits core-image, the default value of IMAGE_INSTALL includes task-base-extended (which pulls in task-base)
**** ENDING LOGGING AT Fri Nov 16 02:59:58 2012

**** BEGIN LOGGING AT Fri Nov 16 02:59:59 2012
Nov 16 04:41:30 <kergoth> ugh, WARN_QA and ERROR_QA are in do_package's hashes? I guess i can see the argument, but ugh
Nov 16 07:36:28 <RagBal> What is wrong when a package.tar.xz.lock is created in the download folder but the actuall package is not being downloaded. Build stops because it cannot find the package.tar.xz
Nov 16 07:36:55 <RagBal> It doesn't state the download fails or anything, cleaning the package doesn't help either
Nov 16 07:37:07 <RagBal> Manually removing the .lock file also doesn't help
Nov 16 07:37:25 <RagBal> This is about shared-mime-info
Nov 16 07:57:07 <RagBal> Hmm when I just place it there manually it works, but after a while it runs into another xz archive with the same error
Nov 16 08:10:08 <RagBal> Hmm it seems to be resolved by cleaning packagename-native
Nov 16 08:23:36 <gotan> hello again.
Nov 16 08:26:05 <gotan> I have a problem with my unit tests, they will not run under yocto. my target is an x86_64, my build machine is x86_64, so it should run. I've boiled it down to finding the appropriate LD_LIBRARY_PATH(s), but unsure at the moment as to what that should be. any pointers?
Nov 16 09:17:31 <RagBal> Why does Yocto default to RPM packages? What are the main benefits compared to ipk
Nov 16 09:18:58 <Daemon404> the fact that people have heard of rpm may help.
Nov 16 09:23:50 <RagBal> Daemon404: OE defaults to ipk, there must be a good reason Yocto does not imho
Nov 16 09:24:38 <Daemon404> i find it likely theyre just more comfortable with rpms, or it has to do with WRS
Nov 16 09:24:45 <Daemon404> but im speculating, so Don't Quote Me
Nov 16 09:26:01 <bluelightning> morning all
Nov 16 09:34:31 <drlota> Hi all. I am having a noob problem with Yocto build. I am unable to add Scandinavian keyboard layout to image. Anyone willing to guide me?
Nov 16 10:09:30 <bluelightning> drlota: I'm not entirely sure but I think you would need to install the kbd-keymaps package, then the keymaps should be installed in the standard system location
Nov 16 10:11:56 <drlota> bluelightning: Thanks for your respone. I will try that. I already tried package "keymaps" without any luck.
Nov 16 10:12:52 <bluelightning> right, I think the keymaps package is really only designed for hardware with an unusual keyboard layout
Nov 16 10:13:01 <bluelightning> (rather than i18n for standard keyboards)
Nov 16 10:15:31 <drlota> Oh, I see. Thanks for clarification.
Nov 16 11:03:52 <bluelightning> drlota: so did kbd-keymaps have what you needed?
Nov 16 11:27:57 <drlota> bluelightning: I am just creating a new image. I'll let you know once I have tested that.
Nov 16 11:30:16 <bluelightning> ok, thanks
Nov 16 11:49:09 <drlota> bluelightning: It works like a charm. After adding package kbd-keymaps, command "loadkeys fi" gives me a correct layout. Once again, thank you.
Nov 16 11:49:31 <bluelightning> drlota: no problem!
Nov 16 12:08:31 <Crofton|work> bluelightning, thans for pointing me at that blog entry
Nov 16 12:21:08 <bluelightning> np
Nov 16 12:49:13 <gotan> stillcannot get it working. Is there any way of getting a cross compiled x86 binary that requires share libraries running on the build host?
Nov 16 12:49:52 <gotan> I will look into  static linking.
Nov 16 12:51:21 <bluelightning> er, that is pretty unusual, most of the time you explicitly don't want that...
Nov 16 12:51:44 <bluelightning> presumably just a matter of ensuring the host paths are present
Nov 16 13:45:48 <gotan> I have unit tests i want to be able to run during the build.
Nov 16 13:46:00 <gotan> at the moment i have to turn them off
Nov 16 13:46:52 <gotan> i saw some mails in the list about this, but they were about explictly packaging unit tests for running later in a virtual machine or on the target.
Nov 16 14:11:05 <b737800> hi evry one
Nov 16 14:11:41 <b737800> i have a question on the post configuration of rootfs generated by yocto
Nov 16 14:12:44 <b737800> i generated an image and i want to do somme first launch configurations (ex configure the services launched by systemd, configure X server ...etc)
Nov 16 14:14:10 <b737800> I wonder what is the best place to do that :1-on yocto side ie on the image.bb i write rootfs_postprocess and do all the job here or 2-i write separate scripts that launches at first boot and does all the job ?
Nov 16 14:17:10 <b737800> any advice is welcomed
Nov 16 14:19:03 <RP> b737800: its really up to you and your needs. We tend to prefer to do things at build time and hence have faster first boot but its really up to you
Nov 16 14:19:34 <b737800> ok  thanks very mutch
Nov 16 14:54:32 <hrw> hi
Nov 16 15:15:31 <hrw> someone uses archive* classes with ipk packages?
Nov 16 15:35:43 <kergoth> not sure what the package manager would have to do with anything
Nov 16 15:37:06 <hrw> do_package_write_rpm[postfuncs] += "do_dumpdata_create_diff_gz "
Nov 16 15:37:23 <hrw> looks like rpm only to me
Nov 16 15:38:00 <kergoth> not all the archiver modes  even capture that data, but it's a valid point for the ones that do
Nov 16 15:38:49 * RP posts the setscene skip code, finally
Nov 16 15:39:21 <hrw> kergoth: I do not need that diff but logs would be lovely
Nov 16 15:40:39 <kergoth> so, last night i wrote a tiny script to dump all the varvals of all my sstae archives, then made a list of vars i expect should never end up in sstates, and then generated a grep -E to show any instances of them
Nov 16 15:40:49 <kergoth> this should be interesting to check basic sanity
Nov 16 15:46:32 <_Lucretia_> I've run into a problem, the logs aren't giving any info.
Nov 16 15:46:34 <_Lucretia_> readlib.c:28:19: fatal error: a.out.h: No such file or directory
Nov 16 15:46:38 <_Lucretia_> ldconfig-native
Nov 16 15:46:50 <_Lucretia_> the file does exist, I've checked
Nov 16 15:47:13 <_Lucretia_> it's inside /opt/gcc-4.6.3/lib/gcc/x86_64-unknown-linux-gnu/4.6.3/include-fixed/linux/
Nov 16 15:49:07 <_Lucretia_> any ideas?
Nov 16 15:54:39 <_Lucretia_> hmmm, seem readlib.c needs to include linux/a.out.h
Nov 16 15:55:39 <_Lucretia_> why this wouldn't fail before is strange
Nov 16 15:57:31 <ocallesp> can somebody explain me what 'QA Tests' does  in the yocto project workflow ...?
Nov 16 16:00:39 <bluelightning> ocallesp: checks such as ensuring the architecture of output binaries match the target architecture; ensuring there are no bad RPATHs that point to locations on the build host, etc.
Nov 16 16:02:29 <ocallesp> thanks bluelightning....now it is clear
Nov 16 16:22:10 <hrw> archiver also takes care of target only - native sources were not archived
Nov 16 16:24:38 <kergoth> archiver also doesn't behave well with sstate. it only archivfes stuff built from scratch
Nov 16 16:24:45 * kergoth is working on that particular issue
Nov 16 16:25:32 <hrw> cool
Nov 16 16:25:51 <hrw> in meantime I will revert to sharing DL_DIR/
Nov 16 16:26:22 <kergoth> you can also use copyleft_complmiance, that's what wer'e using until archiver is in a bit better shape
Nov 16 16:26:27 <kergoth> does the license filtering bit
Nov 16 16:27:49 <hrw> thanks
Nov 16 16:29:51 <_Lucretia_> what's the best way to create a new class for a build tool? i.e. where to look?
Nov 16 16:29:56 <kergoth> np
Nov 16 16:30:26 <kergoth> http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/tree/conf/distro/include/mel.conf#n123 - example usage of copyleft_compliance
Nov 16 16:32:27 <hrw> great
Nov 16 16:32:33 <bluelightning> _Lucretia_: a class is really just common definitions for recipes that inherit it, so whatever every recipe would need to use that tool would go into the class
Nov 16 16:34:17 <_Lucretia_> k
Nov 16 16:34:25 <_Lucretia_> seems that Ada patch I did works
Nov 16 16:35:17 <_Lucretia_> but 1) I've had to build a new version of GCC-4.6.3 with Ada support and placed that in the PATH at the start, 2) the failure above is weird, but changing the include to <linux/a.out.h> works
Nov 16 16:37:47 <_Lucretia_> any ideas why this would stop working when it works fine for other compilers?
Nov 16 16:43:43 <dvhart> is the host os and arch logged anywhere during a bitbake image build?
Nov 16 16:45:32 <kergoth> see the cooker log in tmp/log/, it'll be in the build summary at the start of the build
Nov 16 16:45:49 <kergoth> oh, host, you mean the build machine?
Nov 16 16:53:15 <_Lucretia_> ls tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/gcc-cross-4.6.3+svnr184847-r29/sysroot-destdir/home/laguest/src/others/koparo/poky/gumstix/build/tmp/sysroots/x86_64-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/
Nov 16 16:53:15 <_Lucretia_> arm-poky-linux-gnueabi-c++  arm-poky-linux-gnueabi-gcc-4.6.4  arm-poky-linux-gnueabi-gnatchop   arm-poky-linux-gnueabi-gnatlink  arm-poky-linux-gnueabi-gnatprep
Nov 16 16:53:15 <_Lucretia_> arm-poky-linux-gnueabi-cpp  arm-poky-linux-gnueabi-gcov       arm-poky-linux-gnueabi-gnatclean  arm-poky-linux-gnueabi-gnatls    arm-poky-linux-gnueabi-gnatxref
Nov 16 16:53:15 <_Lucretia_> arm-poky-linux-gnueabi-g++  arm-poky-linux-gnueabi-gnat       arm-poky-linux-gnueabi-gnatfind   arm-poky-linux-gnueabi-gnatmake
Nov 16 16:53:17 <_Lucretia_> arm-poky-linux-gnueabi-gcc  arm-poky-linux-gnueabi-gnatbind   arm-poky-linux-gnueabi-gnatkr     arm-poky-linux-gnueabi-gnatname
Nov 16 16:53:24 <_Lucretia_> Ada built
Nov 16 16:59:23 <kergoth> so, http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/tree/classes/isolated-sstate-dir.bbclass is pretty ugly, but can still be useful if/when you need to do anything with the sstates from the current build only, even when using a shared sstate dir
Nov 16 16:59:29 * kergoth thinks about how to improve it
Nov 16 17:11:16 <bluelightning> dvhart: Richard mentioned he thought it would be useful if we added it to the list of things printed at the start of the build
Nov 16 17:11:28 <bluelightning> I think we should do that as well
Nov 16 17:11:37 <dvhart> I was going to suggest the same
Nov 16 17:11:39 <dvhart> shall I open a bug?
Nov 16 17:11:43 <bluelightning> please
Nov 16 17:11:46 <dvhart> will do
Nov 16 17:12:07 <bluelightning> it should be pretty easy, we already have code to do distro identification (two separate bits of code in fact...)
Nov 16 17:13:31 <sgw1> halstead: thinks are looking a little better on the AB
Nov 16 17:19:49 <kergoth> maybe we should dro pTARGET_ARCH and TARGET_OS in favor of TARGET_SYS, and then add BUILD_SYS as well
Nov 16 17:19:55 <kergoth> (re: the build summary)
Nov 16 17:30:57 <bluelightning> kergoth: sounds good
Nov 16 17:37:58 <kergoth> hmm, anyone seen an autogen-native compile failure due to a missing guile/gh.h header?
Nov 16 17:38:11 <kergoth> afaict our guile doesn't provide that.. hmm
Nov 16 17:39:53 <kergoth> ugh, that header is guile 1.8, not 2.0
Nov 16 17:39:56 * kergoth mutters and digs
Nov 16 18:13:41 <mranostay> so if i'm inheriting core-image any reason task-base wouldn't be pulled in now?
Nov 16 18:17:04 <kergoth> setting IMAGE_INSTALL yourself?
Nov 16 18:17:15 <kergoth> use bitbake -e to verify it's what you think it is
Nov 16 18:28:02 <halstead> Thanks sgw_ . I'm curious do you know what the fix for http://autobuilder.yoctoproject.org:8010/builders/nightly-arm/builds/721/steps/shell_55/logs/stdio was?
Nov 16 18:28:34 <halstead> Was it related to me cleaning up sstate?
Nov 16 18:30:54 <sgw_> halstead: most likely
Nov 16 18:32:48 <halstead> sgw_, I'd like to know what the fix was. Do you know?
Nov 16 18:35:38 <sgw_> halstead: RP made a change to the sstate format, but did not update the version number, this causes the sstate task to fail and then run the real task, he has since updated the version number
Nov 16 18:36:09 <halstead> Great thanks!
Nov 16 18:36:50 <bullwinkle> hello yocto, I've created a layer with a kernel config fragment that says CONFIG_HAVE_OPROFILE=m, but it is being overridden to CONFIG_HAVE_OPROFILE=y by another layer (i think), and is reported as such in missing_required_cfg by kernel_configcheck
Nov 16 18:37:07 <bullwinkle> question is: can I cause the value in my layer to override ?
Nov 16 18:37:18 <kergoth> probably need to bump your layer priority above that of the other layer, so the bbappends run in a different order
Nov 16 18:37:49 <bullwinkle> ok will try
Nov 16 18:42:23 <bullwinkle> i should add that i can't find any layer recipe that is actually setting CONFIG_HAVE_OPROFILE=y ; but I'm not clear on where the setting would be picked up from otherwise... maybe whatever is the equivalent of the "defconfig" ?
Nov 16 18:48:18 <bullwinkle> is there a way to have kernel_configcheck or kernel_configme report where an overriden config setting has come from ?
Nov 16 18:58:24 <Crofton|work> dis the remote update stuff davest was going on about make it into the YP feature list?
Nov 16 19:13:51 <seebs> Hmm. I was gonna say, look at my variable tracking patches, but it occurs to me those almost certainly don't work on kernel config fragments.
Nov 16 19:15:09 <bullwinkle> the things I can find that seem most likely to be overriding the setting I want are under /linux/meta/patches/standard/default
Nov 16 19:15:22 <bullwinkle> for example /linux/meta/cfg/kernel-cache/bsp/routerstationpro/routerstationpro.cfg:CONFIG_HAVE_OPROFILE=y
Nov 16 19:16:10 <bullwinkle> that's under my /tmp/work/emenlow-poky-linux/linux-yocto-rt-3.2.18+git1+49f931bc29....
Nov 16 19:21:34 <seebs> Anyone have any benchmarks or numbers on how expensive pseudo is during builds? I know it's a source of some pain, but I haven't got any numbers I can quote at people.
Nov 16 19:21:57 <seebs> I am trying to make the case for an argument that it would be a rewarding use of my time if someone were to schedule me a couple-few weeks to try to speed it up.
Nov 16 23:47:29 <kergoth> sigh, the perf recipe
Nov 16 23:48:12 <kergoth> PV is 3.4, yet that's not necessarily the kenrel version it's built out of
Nov 16 23:48:36 <kergoth> doesn't even build on some older kernels.. and there's no variable to exclude inclusion of perf from core-tools-profile..
Nov 16 23:48:41 * kergoth rolls eyes
Nov 17 00:15:54 * kergoth sighs
Nov 17 00:22:00 <mranostay> kergoth: cheer up it is Friday!
Nov 17 00:22:06 <mranostay> almost beer time
**** ENDING LOGGING AT Sat Nov 17 03:00:00 2012

**** BEGIN LOGGING AT Sat Nov 17 03:00:00 2012
Nov 17 15:54:15 <_Lucretia_> is the tmp/sysroot/overo what ends up being in the final filesystem?
Nov 17 16:20:04 <_Lucretia_> ok, so I've added Ada support, I need to know where to put the GNAT, GNATMAKE, GNATBIND, etc variables to point to the cross tools
Nov 17 17:55:30 <gan_> Is BBMASK no longer supported?  I'm getting "ParseError"
Nov 17 17:57:23 <JaMa> it works here
Nov 17 17:58:00 <gan_> I'm on git master branch of poky
Nov 17 17:59:39 <JaMa> I don't use poky
Nov 17 18:00:07 <gan_> I add BBMASK=udev_173 to local.conf --> ParseError on that line.  Remove it -> no parse error (but problems with udev_173)
Nov 17 18:00:32 <gan_> JaMa: What do you use then?
Nov 17 18:00:35 <JaMa> yes that's wrong syntax, so ParseError is correct
Nov 17 18:00:51 <gan_> Care to tell me the right syntax?  :-)
Nov 17 18:00:59 <JaMa> oe-core and other layer
Nov 17 18:02:24 <gan_> OK. that's fine.  Even though this is #yocto... Seriously what do you think is the right syntax?
Nov 17 18:04:30 <JaMa> valid regexp in quotes
Nov 17 18:05:39 <gan_> Ah, yes of course quotes.  Strange I was sure I copied this from a previous project I had.  Thx.
Nov 17 18:45:48 <kergoth> gan_: quotes in vars weren't required in the old versions, now they are
Nov 17 19:06:30 <gan_> kergoth: Thankyou!  I thought I was going senile...
Nov 17 21:13:16 <gan_> If I suspect there is something wrong with a do_fetch (it just hangs, like forever) what would you suggest I do to debug it?
Nov 17 21:16:06 <gan_> Where can I track the progress of the download?  Do git fetches end up in build/downloads? Looks like tarballs mostly...  Appreciate any help...
Nov 17 21:19:55 <gan_> Too many directories... how are you supposed to know where stuff ends up during the build process...
Nov 17 21:21:02 <bluelightning> gan_: you may find the reference manual section on "The Build Directory" useful (5.2)
Nov 17 21:21:08 <bluelightning> http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#structure-build
Nov 17 21:21:35 <gan_> ok, thanks I'll rtfm for a while
Nov 17 21:21:37 <bluelightning> yes, git fetches should go into downloads/git2
Nov 17 21:21:55 <bluelightning> you may be able to find some info in the fetch log
Nov 17 21:22:24 <gan_> "git2". lol.  the naming of directories is the worst part of yocto...  there are a lot of good parts tho
Nov 17 21:23:04 <bluelightning> it's git2 as we previously had a different set of fetchers that used a different structure
Nov 17 21:23:05 <likewise> gan: Yocto does a lot of stuff, and there is a trade-off between showing what it is doing and hurting your brain.
Nov 17 21:23:20 <bluelightning> fetch log can be found in tmp/work/<triple>/recipe-version/temp/log.do_fetch
Nov 17 21:23:57 <likewise> gan: ls -ltr build/downloads/ helps for me, as does ls -ltr build/downloads/git2, or du -cks build/downloads/git2 to check if the fetch hangs.
Nov 17 21:24:37 <likewise> but bluelightning's advice is way better, if you suspect what package is not fetching (quickly enough)
Nov 17 21:24:59 <gan_> likewise: thanks. those are good reminders.  now that I know what dirs to monitor it should be easier
Nov 17 21:25:35 <bluelightning> FYI you can retrieve the logs location for a recipe using bitbake -e <recipe> | grep ^T=
Nov 17 21:32:50 <gan_> bluelightning: OK, that was useful. Seems there is lots to find out from bitbake -e
Nov 17 21:42:58 <gan_> OK, du -s on downloads/ shows there is no new data being written.
Nov 17 21:43:18 <gan_> The log only says: DEBUG: Executing python function do_fetch and DEBUG: Executing python function base_do_fetch
Nov 17 21:43:32 <gan_> so not that much.
Nov 17 21:44:03 <gan_> should I look in the recipe for src URLs or is the actual fetch (git fetch, whatever) logged somewhere?
Nov 17 21:46:39 <gan_> Hang on... downloads is increasing in size again.  But still would be good to know if there is a more descriptive log.  Right now only the 2 lines
**** ENDING LOGGING AT Sun Nov 18 02:59:58 2012

**** BEGIN LOGGING AT Sun Nov 18 02:59:59 2012
**** ENDING LOGGING AT Mon Nov 19 02:59:59 2012

**** BEGIN LOGGING AT Mon Nov 19 02:59:59 2012
Nov 19 07:20:32 <gotan> morning.
Nov 19 07:23:03 <gotan> I have coma across an unusual issue with my yocto build. I have had a BSP under test for a bit, and then for no reason i can as yet determine, after a reboot, the kernel or udev is not recognising eth0, or rather it has devices named eth2 and eth3 now. This may be a show stopper for the BSP if i cannot find out what is causing it. any ideas?
Nov 19 07:23:44 <gotan> the core poky has remained unchange.
Nov 19 09:29:25 <bluelightning> morning all
Nov 19 09:30:32 <florian> good morning
Nov 19 10:32:45 <schramae> hi. might there be (binary) compatibility problems when using software on yocto that was built with another GCC major release and linked against another (e)glibc? and if so, how advisable would it be to downgrade the GCC~/eglibc-versions from the current 1.3 release to older ones?
Nov 19 10:40:59 <mckoan> good morning
Nov 19 10:49:49 <ant_work> ciao mckoan
Nov 19 14:36:38 <ant_work> zeddii: is 3.6 in sight?
Nov 19 14:49:58 <zeddii> ant_work, not as an official linux-yocto, I'm already tracking 3.7 in linux-yocto-dev and we'll respin 3.4 on to of LSTI while 3.8 cooks (it or higher) would be a yocto 1.4 target. Will 3.7 work ? I was about to refresh it again today.
Nov 19 14:52:03 <ant_work> It looks like many new things will be stabilized in  3.8.
Nov 19 14:52:19 <ant_work> I think it's worth to wait for it
Nov 19 15:13:57 <abelloni> Hi, quick question
Nov 19 15:14:11 <abelloni> I received a FRI2 at ELCE
Nov 19 15:14:31 <abelloni> I'm trying to get it to boot on the internal microSD slot
Nov 19 15:15:12 <abelloni> How do I do that ?
Nov 19 15:20:10 <zeeblex> abelloni: what bios version do you have?
Nov 19 15:21:04 <zeeblex> abelloni: insert the microSD and press F7 at startup in order to choose the device
Nov 19 15:44:27 <abelloni> zeeblex: hum, would that work over serial ?
Nov 19 15:44:47 <abelloni> EFI SD Card Boot Failed.
Nov 19 15:44:47 <abelloni> EFI Shell version 2.30 [1.0]
Nov 19 15:44:47 <abelloni> Current running mode 1.1.2
Nov 19 15:44:52 <abelloni> that is what I get
Nov 19 15:49:41 <zeeblex> you should use the poky/scripts/contrib/mkefidisk.sh script file in order to write the image on microSD
Nov 19 15:50:15 <zeeblex> also make sure that FRI2 provides serial output (from BIOS settings)
Nov 19 15:50:21 <abelloni> Ok, I'll try
Nov 19 15:50:47 <abelloni> just to clarify thing, why would it boot from the external SD and not from the internal one ?
Nov 19 15:50:56 <abelloni> also, how to enter the bios ?
Nov 19 15:51:15 <zeeblex> I think F10 helps you enter BIOS
Nov 19 15:51:36 <zeeblex> maybe you don't have internal one or maybe there is no OS on it
Nov 19 15:52:31 <abelloni> I took the SD that is booting from the external slot and put it in the internal slot ...
Nov 19 15:59:30 <abelloni> hum, actually F10 is enumerating botable devices
Nov 19 15:59:44 <abelloni> seems to work, thanks !
Nov 19 16:01:39 <zeeblex> ok, great
Nov 19 16:01:47 <_Lucretia_> khem: hi, do you know about the gcc-cross build process?
Nov 19 16:13:56 <abelloni> ok, so, you have to press F10 to choose boot from SDcard every time you want to change SD slot.
Nov 19 16:14:21 <abelloni> then, it seems to remember which slot it booted from
Nov 19 22:25:08 <kergoth> Hmm, anyone have a link to richard's task time graphing stuff handy?
Nov 19 22:48:12 <sgw1> kergoth: you talking about the pybootchartgui?
Nov 19 22:48:27 <kergoth> probably
Nov 19 22:50:41 <kergoth> thanks for the pointer
Nov 19 22:52:18 <sgw1> kergoth: in the scripts dir
Nov 19 23:02:41 * kergoth nods
Nov 19 23:11:02 <phragment> how do i build a recipe/tool for the host? is this possible?
Nov 19 23:11:30 <kergoth> i assume you mean the machine you're running the build on? thats' waht -native recipes are
Nov 19 23:11:38 <evanp> phragment: is it something you'd want in the SDK?
Nov 19 23:12:05 <phragment> evanp: pretty much, it's about elftosb
Nov 19 23:12:36 <phragment> kergoth: i'll google that, thanks
Nov 19 23:12:39 <evanp> phragment: if it's an SDK tool, look into nativesdk.bbclass; if it's something only the build machine needs, look into native.bbclass
Nov 19 23:13:33 <phragment> evanp: i'll only need it for the build machine, thanks :)
Nov 19 23:13:50 <kergoth> ugh, i just noticed how badly assume_provided interacts with sstate. adding something there results in its removal from the task graphs,a nd the rerun of all the tasks that depended on it, indirectly or directly, afaict
Nov 19 23:22:57 <phragment> is there a good overview for path variables usable in bb recipes?
Nov 19 23:28:45 <evanp> phragment: "cd poky && git grep VARNAME -- documentation" is pretty effective
Nov 19 23:31:17 <bluelightning> phragment: if you mean datadir, sbindir etc - see meta/conf/bitbake.conf
Nov 19 23:34:09 <phragment> i'll take a look, thanks
Nov 19 23:56:26 <phragment> <rant>is meta-fsl-arm from freesclae basically borked, or am i the only one?</rant>
Nov 19 23:58:22 <Crofton|work> I am sure msm can answer that
Nov 19 23:58:46 <kergoth> borked how?
Nov 19 23:59:02 <kergoth> i do builds from it every day, but don't often test on real hardware
Nov 20 00:02:05 <phragment> elftosb doesn't deploy properly so the u-boot recipe can't find it
Nov 20 00:03:12 <kergoth> like i said, we build fine every day, including u-boot, but currently we're only building one machine, so perhaps your issues are machine specific
Nov 20 00:03:39 <kergoth> i'd suggest emailing the meta-freescale list
Nov 20 00:04:19 <phragment> ok
Nov 20 00:08:50 <Crofton|work> | -- Configuring the python interpreter...
Nov 20 00:08:50 <Crofton|work> | -- Could NOT find PythonInterp (missing:  PYTHON_EXECUTABLE)
Nov 20 00:08:50 <Crofton|work> | -- Python interpreter: PYTHON_EXECUTABLE-NOTFOUND
Nov 20 00:08:50 <Crofton|work> | -- Override with: -DPYTHON_EXECUTABLE=<path-to-python>| -- Configuring the python interpreter...
Nov 20 00:08:50 <Crofton|work> | -- Could NOT find PythonInterp (missing:  PYTHON_EXECUTABLE)
Nov 20 00:08:51 <Crofton|work> | -- Python interpreter: PYTHON_EXECUTABLE-NOTFOUND
Nov 20 00:08:53 <Crofton|work> | -- Override with: -DPYTHON_EXECUTABLE=<path-to-python>
Nov 20 00:08:55 <Crofton|work> any hints
Nov 20 00:25:44 <Crofton|work> never mind, I am a moron
Nov 20 01:29:39 <mranostay> heh
Nov 20 01:31:02 <mranostay> so would it be possible to have two hddimg images on separate paritions and somehow switch between them?
Nov 20 01:33:54 <ka6sox> mranostay, for rootfs images?
Nov 20 01:35:15 <mranostay> yes.. i feel i'll need three partitions... /boot  / (primary) and  / (backup)
Nov 20 01:35:24 <mranostay> have i mentioned how much i hate x86 :)
**** ENDING LOGGING AT Tue Nov 20 02:59:57 2012

**** BEGIN LOGGING AT Tue Nov 20 02:59:57 2012
Nov 20 09:13:08 <bluelightning> morning all
Nov 20 09:23:19 <drlota> Good morning.
Nov 20 09:34:26 <tavish> hi, i think there is a problem with either busybox recipe or that some packages are dependant on busybox. I tried to install usbutils using zypper, and busybox was a dependency and so it did update-alternatives and zypper was not able to function after that
Nov 20 09:35:25 <tavish> busybox did not support some commandline options to cp etc
Nov 20 09:35:39 <tavish> so it just failed
Nov 20 09:50:55 <rburton> sounds like zypper needs a dependency on coreutils
Nov 20 10:26:22 <mckoan> good morning
Nov 20 14:58:31 <BjornArnelid> Hi, is there any minimal hardware requirements for HOB/Bitbake? My old laptop will start to act very strange after a while before failing the build.
Nov 20 15:02:48 <kergoth> I don't know what the official recommendations are, but I wouldn't dare try building without at least a gig of ram and 20 gigs of space or so
Nov 20 15:03:55 <BjornArnelid> I have plenty of diskspace but only 2gig ram
Nov 20 15:04:13 <kergoth> 2 gigs should be plenty as long as you aren't using it all for something else :)
Nov 20 15:04:35 <BjornArnelid> And since im debugging the yocto plugin im running 2 instancesa of eclipse as well
Nov 20 15:04:39 <kergoth> ah
Nov 20 15:04:48 <kergoth> exactly how did the build fail?
Nov 20 15:05:28 <BjornArnelid> Well it fails differently every time - first during compile linux core, then during a fetch, then during writing rpm packages
Nov 20 15:05:42 <BjornArnelid> And i never got past that third one.
Nov 20 15:06:00 <rburton> but how did it fail?
Nov 20 15:06:14 <rburton> and two instances of eclipse is approx 16G of RAM
Nov 20 15:09:09 <BjornArnelid> ERROR: Function failed: do_compile (see /media/Lanedisk/poky/build/tmp/work/i686-linux/qemu-native-1.2.0-r4/temp/log.do_compile.30167 for further information)
Nov 20 15:09:09 <BjornArnelid> NOTE: recipe qemu-native-1.2.0-r4: task do_compile: Failed
Nov 20 15:09:09 <BjornArnelid> ERROR: Task 69 (virtual:native:/media/Lanedisk/poky/meta/recipes-devtools/qemu/qemu_1.2.0.bb, do_compile) failed with exit code '1'
Nov 20 15:10:21 <BjornArnelid> But the error message will be different any time i try
Nov 20 15:11:25 <bluelightning> BjornArnelid: you're not running out of disk space by any chance?
Nov 20 15:13:35 <BjornArnelid> bluelightning: No, I am using an external disk where I have 900 gig free
Nov 20 15:14:08 <BjornArnelid> For me eclipse in eclipse takes up 300 meg of ram
Nov 20 15:14:43 <BjornArnelid> But with other stuff running on my computer there is about 1 gig free when im about to start running
Nov 20 15:15:24 <bluelightning> I think we'd need to see a pastebin of the actual failure messages...
Nov 20 15:16:02 <BjornArnelid>  ok hang on
Nov 20 15:19:07 <BjornArnelid> Here is one http://pastebin.com/eYYRvr1e
Nov 20 15:20:45 <BjornArnelid> Here is another one http://pastebin.com/ex4ihG5K
Nov 20 15:21:44 <BjornArnelid> Im running on ubuntu 12.04 LTS by the way
Nov 20 15:22:10 <bluelightning> BjornArnelid: can we see /media/Lanedisk/poky/build/tmp/work/i686-linux/qemu-native-1.2.0-r4/temp/log.do_compile.30167 because that last error doesn't have any details in it...
Nov 20 15:22:57 <bluelightning> the first one kind of looks like a truncated/corrupted download
Nov 20 15:23:51 <BjornArnelid> Hold on.
Nov 20 15:27:30 <BjornArnelid> Here http://pastebin.com/XAbJ1rkK
Nov 20 15:27:45 <eren> ah,there is a team meeting today
Nov 20 15:35:58 <bluelightning> BjornArnelid: "gcc: internal compiler error: Segmentation fault (program as)"
Nov 20 15:36:47 <BjornArnelid> bluelightning: So what does that mean?
Nov 20 15:36:49 <bluelightning> BjornArnelid: either there is a genuine problem with gcc there, or your machine may be overheating / suffering from other CPU or memory issues
Nov 20 15:37:20 <BjornArnelid> Yes maybe.
Nov 20 15:38:15 <BjornArnelid> It is a fairly old computer so I guess that could be it.
Nov 20 15:38:24 <BjornArnelid> Thank you
Nov 20 15:38:41 <bluelightning> you could easily check that just by looking at the temperature readouts...
Nov 20 15:39:43 <bluelightning> (otherwise might be worth running memtest86+ or similar)
Nov 20 15:39:49 <bluelightning> if the problem is random then it's more likely to be a hardware issue
Nov 20 15:42:22 <BjornArnelid> I will do that.
Nov 20 15:42:38 <BjornArnelid> And maybe find another machine to try it on.
Nov 20 15:59:44 <eren> I'm on
Nov 20 15:59:55 <sgw1> YPTM: Sau! is here
Nov 20 16:00:03 <pidge> YPTM: Beth is here
Nov 20 16:00:03 <Song_Liu> YPTM: welcome everyone, Who's on the bridge?
Nov 20 16:00:08 <eren> YPTM: Eren is here
Nov 20 16:00:22 <strassek> YPTM: Kevin Strasser is here
Nov 20 16:00:36 <dvhart> YPTM: Darren is on
Nov 20 16:00:41 <jmpdelos> YPTM: Jeff Polk is on
Nov 20 16:00:50 <tomz2> YPTM: tom z here
Nov 20 16:01:47 <bluelightning> YPTM: Paul Eggleton is on the call
Nov 20 16:01:58 <kergoth> YPTM: Chris Larson here
Nov 20 16:02:00 <Zagor> YPTM: Björn Stenberg is on the call
Nov 20 16:02:00 <scottrif> YPTM: Scott Rifenbark joined the call
Nov 20 16:02:06 <davest> YPTM: davest in the house
Nov 20 16:02:07 <nitink1> nitin: YPTM: nitin is on the bridge
Nov 20 16:02:19 <mihai2> YPTM: Mihai Lindner is on the bridge
Nov 20 16:02:20 <rburton> going to be late to YPTM
Nov 20 16:02:26 <fray> YPTM: I'm on IRC, but I'm not on the call (vacation this week).. ping me if you need anything
Nov 20 16:02:26 <zeddii> YPTM: Bruce Ashfield here as well.
Nov 20 16:02:36 <eren> pretty many people, hehe
Nov 20 16:02:40 <eren> compared to last week
Nov 20 16:02:56 <fp> YPTM: Amit is here
Nov 20 16:02:57 <Song_Liu> YPTM: Any opens?
Nov 20 16:03:12 <eren> yeah, for the doc
Nov 20 16:03:32 <denix> YPTM: Denys is here
Nov 20 16:03:58 <eren> http://erenturkay.com/doc/from-bitbake-to-image/
Nov 20 16:05:06 * scottrif wondering if my call dropped.... no sound on the bridge
Nov 20 16:05:48 <zeddii> scottrif, likely. I can hear the call
Nov 20 16:06:04 <davest> YPTM: I seemed to get dropped too. But I'm back on now.
Nov 20 16:06:07 * scottrif redialing
Nov 20 16:06:13 <jzhang-laptop> YPTM: jzhang's on the call
Nov 20 16:06:36 <rburton> YPTM: RP is on the call (he can't get on IRC)
Nov 20 16:07:01 <scottrif> YPTM: Scott Rifenbark rejoined
Nov 20 16:11:12 * RP__ is in the YPTM
Nov 20 16:15:03 <rburton> YPTM: ross finally joined the call
Nov 20 16:15:25 <scottrif> eren:  There is a lot of good information in your document.  I can see some of this making its way into the revamped BitBake manual as it covers a lot of basic stuff for that flow.  There is also some fundamental information in there that could be worked into the mainstream YP documentation to add some detail in some already established topics (e.g. layers).  The 1.4 (latest) version of the YP Application Developer's Manual now has a detail
Nov 20 16:17:57 <eren> scottrif: thank you. I guess you are referring to "Layer" part in YP Application Developer's manual. I couldn't get which detail we are referring
Nov 20 16:18:27 * zeddii sees his queue is in and goes to prep a new one
Nov 20 16:18:57 * RP__ mentions https://wiki.yoctoproject.org/wiki/Profiling - some notes I've put together about profiling various aspects of the system
Nov 20 16:20:31 <scottrif> eren:  Layers are discussed in the YP BSP Manual in the "BSP Layers" section and also the "Understanding and Creating Layers" section in the YP Developer's Manual.
Nov 20 16:21:02 <scottrif> eren:  I would like to leverage off your information and use as much as it as possible.
Nov 20 16:21:11 * tomz2 also notes I just updated https://bugzilla.yoctoproject.org/show_bug.cgi?id=3413 and will be adding more as I go along
Nov 20 16:21:12 <yocti> Bug 3413: normal, Medium+, 1.4 M2, tom.zanussi, ACCEPTED , [Performance] Use the profiling and tracing tools to see where build performance might be improved
Nov 20 16:23:49 <eren> scottrif: of course. It's not finished though. The main idea behind writing this doc was that I had a hard time understanding bitbake, how image is created although I have a packaging background. I felt that the big picture was missing and so this is born.
Nov 20 16:24:51 <eren> scottrif: in the second part (openembedded) I will write which tasks are added in OE (some of them is defined in staging.bbclass, some of them packaging.bbclass) and lead my way towards creating an image.
Nov 20 16:24:56 <scottrif> eren:  Yes - I can see real value into getting this information in the BitBake Manual.  One of the tasks we are trying to do is a re-write of the BitBake Manual, which at the moment is not really being maintained as a separate doc.
Nov 20 16:27:59 <eren> scottrif: ok. You can use the information if you find useful :)
Nov 20 16:28:22 <scottrif> eren:  Awesome!  Thank you
Nov 20 16:28:34 <eren> but I need some feedback later. There are a few points that I miss (such as EXPORT_FUNCTIONS)
Nov 20 16:29:30 <eren> scottrif: maybe we should discuss when the draft (with openembedded part) is finished. There would be other information on openemedded part for explaining the "big picture"
Nov 20 16:29:54 <eren> afterwards, you can integrate it
Nov 20 16:30:19 <eren> scottrif: what do you think?
Nov 20 16:31:13 <scottrif> eren:  Yes - we can talk when more is there.  Just contact me.
Nov 20 16:32:42 <eren> scottrif: Okkie! Your email is scott.m... @ intel right?
Nov 20 16:33:04 <scottrif> eren: yes - I also work through srifenbark@gmail.com as well.
Nov 20 16:33:37 <eren> scottrif: roger. Thank you for your support
Nov 20 16:33:48 <scottrif> eren: np :)
Nov 20 16:33:52 <eren> I will let you know when I make progress worth mentioning :)
Nov 20 16:35:04 <RP__> halstead: thanks for the cgit fix! :)
Nov 20 16:38:08 <eren> I would like to ask security related question
Nov 20 16:45:42 <eren> eren  ..at..  hambedded.org
Nov 20 16:46:56 <Song_Liu> YPTM: thanks everyone for joining the meeting. Have a nice day/evening
Nov 20 17:29:01 <kergoth> gah, meta-oe hasn't caught up with the FILESPATH changes, getting a ton of missing file:// file errors now
Nov 20 17:29:05 * kergoth investigates
Nov 20 17:29:45 <rburton> kergoth: you might need to re-pull oe-core, gcc-cross-initial was bust for about 20 minutes
Nov 20 17:30:20 <kergoth> ah, will do, thanks for the pointer
Nov 20 17:34:33 <walters> is there a reason gcc isn't built with --enable-linker-build-id?
Nov 20 17:34:46 <walters> (it's hard to search the archives with google for it, since "build id" is pretty generic)
Nov 20 17:35:19 <walters> for various reasons i am looking at reducing the toolchain delta with RHEL, and this shows up as one
Nov 20 17:35:20 <fray> I'm guessing that it's historical.. i.e. that option is realitvely new..
Nov 20 17:35:37 <walters> ok, i'll do some more testing and send a patch
Nov 20 17:35:41 <fray> If 'khem' is around, he would be the one that knows..
Nov 20 17:35:54 <fray> It seems like it would be somewhat useful..
Nov 20 17:36:47 <fray> I -think- the tools that we have for debug splitting and remote debug are already capable of working w/ the build dis
Nov 20 17:36:49 <fray> ids
Nov 20 17:37:35 <rburton> so what does that do then?
Nov 20 17:38:29 <walters> rburton: https://fedoraproject.org/wiki/Releases/FeatureBuildId
Nov 20 17:39:33 <rburton> walters: useful!
Nov 20 18:21:00 <walters> sstate cache is really nice
Nov 20 18:24:25 <rburton> walters: yes :)
Nov 20 18:25:00 <rburton> walters: especially when you cron a build of origin/master at 5am to populate the state with anything new from overnight
Nov 20 18:25:49 <walters> sstate from autobuilder.yoctoproject.org ?
Nov 20 18:26:22 <rburton> nah, i do a build locally
Nov 20 18:26:27 <rburton> probably quicker than downloading
Nov 20 18:27:20 <rburton> i'm too far away and too slow a pipe for downloading from the US, really.
Nov 20 18:27:42 <walters> oh so this is like you're working on a branch, but when you rebase you'll have newer sstate already?
Nov 20 18:45:28 <peachj> Is there a good way to force all native packages to build as 32-bit on a 64-bit OS?
Nov 20 19:14:01 <kergoth> err, i just noticed that license.bbclass appears to be pulling the license from the packages wrong. it's doing d.getVar('LICENSE_' + pn + '-' + package, True)
Nov 20 19:16:47 <kergoth> hmm
Nov 20 19:22:02 <pidge> kergoth: that's right actually. some recipes might have the package level license field wrong however.
Nov 20 19:22:41 <pidge> kergoth: meta/recipes-devtools/e2fsprogs/e2fsprogs.inc is right for example. udev is wrong.
Nov 20 19:22:45 <kergoth> that's not the variable used
Nov 20 19:22:49 <kergoth> it's LICENSE_<pkgname>
Nov 20 19:22:56 <kergoth> not LICENSE_<pn>-<pkgname>
Nov 20 19:23:10 <kergoth> ${PN}-dev is the package name, it already includes PN as appropriate
Nov 20 19:23:38 <pidge> ahh. ok, I'll patch it.
Nov 20 19:24:35 <kergoth> so, I was just wondering, should we have a separate variable for the licenses under which the *source* is under? right now that's sort of the meaning of LICENSE, buti t's also the fallback for all the packages..
Nov 20 19:24:47 <kergoth> i'm looking at a recipe whose source has one gplv3 file, a m4 macro
Nov 20 19:24:57 <kergoth> i can't imagine that could flow into any of the binary packages
Nov 20 19:25:30 <kergoth> the packages end up just lgplv2.1+ or gplv2, even though there's both mit and gplv3 sources in the source tree (mit is linked to the gpl code, so is superceded)
Nov 20 19:25:44 <kergoth> in this particular case it probably doesn't matter whether we drop the knowledge about teh source licenses
Nov 20 19:26:09 <kergoth> but i could imagine cases where it might matter, or where the license restricts source distribution but not binary distribution..
Nov 20 19:26:16 * kergoth ponders
Nov 20 19:29:48 <pidge> kergoth: sgw brought that up this am with me. Right now there is no good way to do that. I can see use cases for it though and I've been thinking that we kind of need to do it, but the thing that kind of stinks about it is, it almost needs to be a per file license field (which makes me semi-sick to my stomach) in order for it to be really of use. if we had that, then we could infer license of binary distribution based on the license of e
Nov 20 19:29:49 <pidge> ach file included.
Nov 20 19:30:44 <kergoth> heh, once we're per-file, we might as well just make a spdx manifest for the tree and use that :)
Nov 20 19:30:53 <pidge> but it's a lot of work auditing each file and maintaining all of that metadata. if upstreams adopt spdx then this is solved.
Nov 20 19:30:56 <pidge> heh, exactly
Nov 20 19:30:58 * kergoth nods
Nov 20 19:31:39 <kergoth> I think I'll just add a bit of detail about the source license in comments in this recipe for now, just so a reader doesn't think the LICENSE applies to everything
Nov 20 23:45:30 <kergoth> this auto-dump of config.log is really kind of irritating
Nov 20 23:45:39 <kergoth> it makes BBINCLUDELOGS pretty useless, since the failure is never at the end
Nov 20 23:54:47 <bluelightning> kergoth: wasn't a patch just posted for that recently?
Nov 21 00:28:07 <Crofton|work> bluelightning, we should think about what to show at FOSDEM
Nov 21 00:28:25 <Crofton|work> a little more fcous on what we actually do would be good
Nov 21 00:38:45 <bluelightning> Crofton|work: what would you suggest specifically?
Nov 21 00:52:02 <Crofton|work> having a collection of devices with screens all running the same demo
Nov 21 00:52:06 <Crofton|work> is a visual one
Nov 21 00:52:16 <Crofton|work> with no screens, it is hard to see what we do
Nov 21 00:53:37 <kergoth> bluelightning: ah, yes, that does ring a bell now that you mention it
Nov 21 00:53:58 <Crofton|work> basically, we need a sato demo that looks like it was done in this decade
Nov 21 00:54:08 <Crofton|work> I think this is on the list of things we talk about
Nov 21 00:54:11 <bluelightning> Crofton|work: hmm... thing is, a large portion of the target devices we have don't have screens
Nov 21 00:54:19 <Crofton|work> yep
Nov 21 00:54:37 <bluelightning> I think it's enough just to have a range of different devices; if they are running a demo the same demo might be a good idea
Nov 21 00:54:43 <Crofton|work> yeah
Nov 21 00:55:00 <Crofton|work> it always boils down to what people show up with :)
Nov 21 00:55:05 <bluelightning> I have a few different things I can bring this time
Nov 21 00:55:08 <Crofton|work> but it would be nice to get some focus
Nov 21 00:55:47 <Crofton|work> koen is working with one of the hw vendors, but I am sure he can get us an example
Nov 21 00:57:32 <bluelightning> let's all keep thinking about it
Nov 21 00:57:47 <bluelightning> mean time I need to go get some sleep, night all
Nov 21 01:01:19 <kergoth> night
Nov 21 01:02:49 * mranostay pokes in
Nov 21 01:03:03 <kergoth> damnit
Nov 21 01:03:45 <kergoth> why are this recipe's files getting installed into the machine sysroot even though PACKAGE_ARCH isn't set to MACHINE?
Nov 21 01:04:22 <Crofton|work> magic
Nov 21 01:04:25 * kergoth sighs
Nov 21 01:04:30 <kergoth> it's completely hosing multi-machine builds
Nov 21 01:04:50 <mranostay> Crofton|work: it is all magic
Nov 21 01:14:21 <evanp> what does "multi-machine" mean exactly? run the bitbake command >= 2 times for different MACHINEs in the same build tree? or something else?
Nov 21 01:14:48 <Crofton|work> change machine name and rerun build
Nov 21 01:15:00 <Crofton|work> but arch stuff is not rebuilt, just machine stuff
Nov 21 01:15:49 * kergoth tries to bisect down the issue
Nov 21 01:16:10 <kergoth> anyone else noticed this behavior where setscenes are run for things that were already built in this very tmpdir?
Nov 21 01:16:26 <kergoth> as in do a build, interrupt, re-run the build, and it runs setscenes for things that were already built in the previous build
Nov 21 01:16:47 <kergoth> haven't nailed it down exactly, just keep noticing it
Nov 21 01:33:22 <ka6sox-away> I think I have seen this on our meta-webos builds but I thought that was normal.
Nov 21 01:33:29 <ka6sox-away> kergoth, ^^
Nov 21 01:33:46 <kergoth> hmm
Nov 21 01:34:00 <kergoth> k, thanks for the data point, will have to look into it or pester rp and see what he thinks
**** ENDING LOGGING AT Wed Nov 21 02:59:58 2012

**** BEGIN LOGGING AT Wed Nov 21 02:59:58 2012
Nov 21 07:49:30 <zibri> I have problems getting passed bitbake's sanity test check_connectivity. wget seems to be giving me "Cannot write to ‘/home/olof/.yocto.downloads/index.php’ (Resource temporarily unavailable)." when used with --continue. Doesn't matter if the destination exists beforehand or not. Any solutions? (except skipping the test and hoping for the best :-))
Nov 21 07:56:57 <zibri> i tested the same command with http://www.cpan.org/modules/by-module/XML/XML-Parser-2.41.tar.gz and https://eula-downloads.yoctoproject.org/index.php. cpan works, yocto fails as above.
Nov 21 08:00:25 <zibri> same problem on current master as well as danny. i'm on debian sid btw.
Nov 21 08:05:31 <mckoan> good morning
Nov 21 09:53:20 <bluelightning> morning all
Nov 21 10:13:22 <mckoan> bluelightning: hi
Nov 21 10:14:54 <bluelightning> hi mckoan
Nov 21 17:29:29 <walters> ooh, yellow warnings
Nov 21 17:29:52 * walters catches up with the latest oe-core
**** ENDING LOGGING AT Thu Nov 22 02:59:58 2012

**** BEGIN LOGGING AT Thu Nov 22 02:59:59 2012
Nov 22 09:06:48 <phragment> i've got a problem with hob, it waits forever on startup "Hob is checking for correct build system setup"
Nov 22 09:07:20 <phragment> last strace is:
Nov 22 09:07:20 <phragment> rt_sigaction(SIGINT, {0x439130, [], SA_RESTORER, 0x7f75f3bb2050}, {SIG_DFL, [], SA_RESTORER, 0x7f75f3bb2050}, 8) = 0
Nov 22 09:07:20 <phragment> wait4(-1,
Nov 22 09:49:09 <bluelightning> morning all
Nov 22 13:14:23 <JaMa> rburton: xf86-video-omap: wasn't dri header check separated so it was possible to explicitly disable dri and dri-devel?
Nov 22 13:22:35 <Crofton|work> gm
Nov 22 13:28:25 <JaMa> rburton: also --enable-neon copied from xf86-video-omapfb is invalid
Nov 22 14:06:10 <rburton> JaMa: the driver didn't actually have any conditionals for DRI
Nov 22 14:07:02 <rburton> it went through that crazy dance, used variables that didn't exist, and set variables that were never used
Nov 22 14:09:47 <JaMa> yes but at least it had test for $DRI, so added conditional for that would be *maybe* enough to disable DRI in that driver
Nov 22 14:10:42 <JaMa> we'll probably revert back to fbdev driver until this is resolved to work in runtime
Nov 22 14:10:46 <rburton> if it wanted to do that it should use AC_ARG_WITH to be deterministic
Nov 22 14:11:18 <rburton> but i'm not going to second guess design decisions, the driver source at the moment requires DRI
Nov 22 14:11:32 <JaMa> ok
Nov 22 17:52:07 <otavio> Who is taken care of danny patches?
Nov 22 17:57:23 <bluelightning> otavio: for OE-Core, rburton is the danny maintainer
Nov 22 17:58:38 <otavio> Ok
Nov 22 20:34:00 <halstead> LaurentiuSerban: sure, I have a moment.
Nov 22 20:35:27 <LaurentiuSerban> I sent you an e-mail
**** ENDING LOGGING AT Fri Nov 23 02:59:58 2012

**** BEGIN LOGGING AT Fri Nov 23 02:59:59 2012
Nov 23 08:18:02 <mckoan> good morning
Nov 23 09:13:21 <bluelightning> morning all
Nov 23 10:21:55 <eballetbo> There is somehow to build all recipes ?
Nov 23 10:22:39 <Zagor> eballetbo: bitbake world
Nov 23 10:22:53 <eballetbo> cool, thanks Zagor
Nov 23 11:32:16 <mckoan> eballetbo: are you updating to denny?
Nov 23 11:33:06 <eballetbo> mkoan:No,  I'm updating meta-igep layer to master
Nov 23 12:24:42 <JaMa> 3.7.0-rc6-00021-g3587b1b
Nov 23 12:24:45 <JaMa> ups
Nov 23 12:37:22 <martiert> I'm trying to get oe to build on mac. The issue I have now is that SRC_URI end " sign is transformed into ?. Any hint as to where the SRC_URI is split and transformed?
Nov 23 13:56:03 <mckoan> why Yocto pre-built images contain a 10-day timer?
Nov 23 13:59:10 <phragment> how do i tell bitbake to not strip a binary? INHIBIT_PACKAGE_STRIP = "1" didn't work
Nov 23 15:15:54 <dany1> Anyone seen any OpenStack layers laying around ?
**** ENDING LOGGING AT Sat Nov 24 02:59:58 2012

**** BEGIN LOGGING AT Sat Nov 24 02:59:59 2012
**** ENDING LOGGING AT Sun Nov 25 02:59:59 2012

**** BEGIN LOGGING AT Sun Nov 25 02:59:59 2012
**** BEGIN LOGGING AT Sun Nov 25 06:11:22 2012
**** ENDING LOGGING AT Mon Nov 26 02:59:58 2012

**** BEGIN LOGGING AT Mon Nov 26 02:59:59 2012
Nov 26 08:36:23 <mckoan> good morning
Nov 26 10:15:22 <bluelightning> morning all
Nov 26 11:29:01 <otavio> RP: Hi
Nov 26 11:29:23 <otavio> RP: I think you misunderstood me ...
Nov 26 11:29:51 <otavio> RP: My ideia was to make allarch to raise an exception if you inhirit it and change PACKAGE_ARCH
Nov 26 11:30:10 <otavio> RP: when you inherit it, you'd be forced to stick with it
Nov 26 11:30:56 <otavio> RP: however, in case I need to change something and wish this to be specific for a single machine, I'd have a problem ...
Nov 26 11:31:05 <otavio> RP: dunno if it is clear now.
Nov 26 11:31:08 <otavio> ?
Nov 26 11:45:17 <bluelightning> otavio: that won't work for packagegroups though because they often change PACKAGE_ARCH after inheriting packagegroup.bbclass
Nov 26 11:49:00 <otavio> bluelightning: yes; that's what I thought
Nov 26 11:49:08 <otavio> bluelightning: good; thx to clarify
Nov 26 12:02:11 <RP> otavio: right, my point is what we want to support changing PACKAGE_ARCH
Nov 26 13:43:24 <rburton> so why does adding meta-oe to a poky repo suddenly start building guile-native from meta-oe
Nov 26 13:43:55 <rburton> when there's a newer guile in oe-core
Nov 26 13:45:49 <bluelightning> rburton: meta-oe has a higher layer priority
Nov 26 13:46:02 <bluelightning> rburton: that trumps version number in bitbake's logic (by design)
Nov 26 13:46:26 <bluelightning> those overlayed recipes should just not be in meta-oe...
Nov 26 13:46:34 <bluelightning> (nor any bbappends)
Nov 26 13:46:53 <rburton> ffs
Nov 26 13:47:02 <rburton> the older guile also fails to build
Nov 26 13:47:16 <bluelightning> awesome
Nov 26 13:47:40 * rburton learns how to use bbmask
Nov 26 13:49:13 <JaMa> guile was introduced in oe-core Date:   Fri Jan 13 18:19:36 2012 -0800
Nov 26 13:49:26 <JaMa> in meta-oe it was forever
Nov 26 13:49:51 <rburton> guile-native is a dependency of autotools
Nov 26 13:49:56 <rburton> meta/recipes-devtools/autogen/autogen-native_5.12.bb:DEPENDS = "guile-native libtool-native libxml2-native"
Nov 26 13:50:01 <rburton> well, autogen
Nov 26 13:50:13 <rburton> close :)
Nov 26 13:50:49 <JaMa> as commit says it was imported to oe-core from meta-oe, but nobody sent followup patch to remove it from meta-oe
Nov 26 13:51:56 <rburton> JaMa: patch sent :)
Nov 26 13:53:17 <rburton> i'd have thought meta-oe would be the same priority as oe-core, so that just adding it has no impact directly
Nov 26 13:53:33 <rburton> and then you can cherrypick components with preferred_version
Nov 26 13:58:05 <JaMa> rburton: thanks
Nov 26 13:59:21 <rburton> wtf, its building fbset now - which is only in meta-oe
Nov 26 13:59:35 <rburton> all i did was add the layer to my poky
Nov 26 13:59:59 <rburton> oh maybe that's v86d confusion
Nov 26 14:00:39 <rburton> no its built fbset
Nov 26 14:00:48 <rburton> (which warns)
Nov 26 14:01:10 <rburton> ah i bet its the xserver in meta-oe
Nov 26 14:01:36 <bluelightning> bitbake-layers show-overlayed
Nov 26 14:02:54 <ant_work> rburton: remember you get differences: x11-common vs. xserver-common
Nov 26 14:03:20 <ant_work> fbset is in x11-common
Nov 26 14:03:33 <ant_work> er.. xserver-commom
Nov 26 14:03:37 <ant_work> what a mess!
Nov 26 14:04:41 <ant_work> diiffs coming from xserver-nodm-init
Nov 26 17:59:59 <eren> Apple mail is terrible at handling text wrapping and line spacing
Nov 26 18:00:40 <eren> I really feel sad as people generally do not know anything about netiquette
Nov 26 18:01:08 <eren> top posting, no text wrapping, 2 line spaces, it's terrible
Nov 26 18:08:27 <Nolaan> Hi all, can you help me with this issue, I try to rebuild a system inside a chroot
Nov 26 18:08:59 <Nolaan> i almost succeeded but the boot sequence stops after completion without droping me to a shell
Nov 26 18:09:06 <Nolaan> how can i reach it?
Nov 26 18:19:33 <mranostay> hello vagueness
Nov 26 18:32:14 <Nolaan> mranostay: You meant me?
Nov 26 18:46:13 <mranostay> yes probably
Nov 26 18:49:25 <Nolaan> you re here to help or comment?
Nov 26 21:21:43 <zibri> hum, i think the problems with wget i mentioned sometime last week may have been fixed with the patch Cristian Iorga just sent on the bitbake-devel list... nice :)
Nov 26 21:22:19 <Bagder> zibri: wget -c issues?
Nov 26 21:22:25 <zibri> yes, exactly
Nov 26 21:22:34 * Bagder spotted them on the wget list the other day
Nov 26 21:24:44 <zibri> ah, found the thread. interesting.
Nov 27 00:24:46 <_Lucretia_> yello charlie5 :D
Nov 27 00:25:16 <charlie5> 'lo luke
Nov 27 00:25:19 <_Lucretia_> :P
Nov 27 00:25:22 <_Lucretia_> bbiab
**** ENDING LOGGING AT Tue Nov 27 02:59:59 2012

**** BEGIN LOGGING AT Tue Nov 27 02:59:59 2012
Nov 27 08:40:26 <mckoan> good morning
Nov 27 09:17:34 <bluelightning> morning all
Nov 27 09:46:56 <dany2> Morning all, is it not a priority inversion problem with the default BBFILE_PRIORITY settings in meta-oe vs. poky/meta/ ?
Nov 27 09:48:36 <dany2> Usually, a user would select the poky repo as a basic set of recipes, and perhaps want to extend this with meta-oe. But when doing so, the default priority of meta-oe is higher than poky/meta/, and more things than expected will be rebuilt.
Nov 27 10:31:32 <jackmitchell> dany2: yes this is currently an issue which I believe a few people are looking into
Nov 27 10:31:58 <jackmitchell> dany2: for the time being I would either BBMASK the recipes causing issues, or lower the priority
Nov 27 10:32:13 <jackmitchell> dany2: of meta-oe is that ;)
Nov 27 11:45:29 <dany2> jackmitchell: OK, that for the info, good to know that someone is looking into the issues.
Nov 27 11:46:00 <dany2> *thanks
Nov 27 11:56:05 <otavio> rburton: I just sent two patches to oe-core ml; those initramfs-framework changes would be good to have in danny however the patch 1/2 depends on one from you done in master which might be backported too.
Nov 27 11:59:11 <rburton> otavio: ok, pls mail me so i don't forget :)
Nov 27 12:15:34 <otavio> rburton: want me to prepare a branch for it?
Nov 27 12:15:50 <rburton> otavio: that would be much appreciated
Nov 27 12:17:55 <otavio> rburton: sent to oe-core ml
Nov 27 12:17:58 <otavio> ;-)
Nov 27 12:21:26 <rburton> thanks
Nov 27 12:40:54 <thaytan> hmmm
Nov 27 12:41:01 <thaytan> is there a way to have multiple autoconf versions?
Nov 27 12:41:44 <thaytan> I added pcsc-lite and ccid recipes to my build, which need a newer autotools
Nov 27 12:41:51 <thaytan> which makes gcc-cross-initial fail
Nov 27 12:41:59 <thaytan> (this is with denzil)
Nov 27 12:42:15 <rburton> thaytan: danny released you know :)
Nov 27 12:42:42 <thaytan> I did not know
Nov 27 12:46:01 <thaytan> wow, a while ago even
Nov 27 12:46:22 <rburton> indeed
Nov 27 13:00:47 <otavio> thaytan: I use pcsc-lite and ccid without problem
Nov 27 13:02:02 <thaytan> otavio: with danny?
Nov 27 13:02:15 <otavio> thaytan: yes
Nov 27 13:02:38 <thaytan> ta
Nov 27 13:02:38 <rburton> thaytan: danny is great
Nov 27 13:02:40 <thaytan> I'll try updating
Nov 27 13:05:09 <otavio> thaytan: but in fact i used it in denzil as well
Nov 27 13:10:03 <thaytan> otavio: maybe different pcsc-lite versions
Nov 27 13:10:10 <thaytan> or I've done something silly
Nov 27 15:59:31 <bluelightning> YPTM: Paul Eggleton is on the call
Nov 27 15:59:52 <zenlinux> YPTM: Scott Garman is on the call
Nov 27 15:59:54 <Zagor> YPTM: Björn Stenberg is on the call
Nov 27 16:00:07 <Ramana_> YPTM: Ramana is on the call
Nov 27 16:00:11 <strassek> YPTM: Kevin Strasser is here
Nov 27 16:00:13 <tomz1> YPTM: Tom Z on the call
Nov 27 16:00:42 <eren> YPTM: Eren is on the call
Nov 27 16:00:43 <RP> Song_Liu: YPTM: RP is here
Nov 27 16:00:51 <AlexG> Song_Liu: AlexG here
Nov 27 16:00:56 <bramming> Brian R here
Nov 27 16:01:25 <Song_Liu> YPTM: Hi everyone, welcome to the technical team meeting, please let me know who's on the bridge.
Nov 27 16:01:29 * Jefro is on the call YPTM 
Nov 27 16:01:41 <laur> YPTM: Laurentiu Palcu is on the call
Nov 27 16:01:42 <adamian> Alex D in conference as well
Nov 27 16:01:52 <nitink> nitin is on YPTM call
Nov 27 16:01:52 <zeddii> YPTM: Bruce Ashfield on the call
Nov 27 16:01:54 <rburton> YPTM Ross is joining right now
Nov 27 16:02:04 <mihai1> YPTM: Mihai Lindner on the call
Nov 27 16:02:11 <scottrif> YPTM: Scott Rifenbark joined call
Nov 27 16:02:32 <fray> YPTM: Mark Hatle joined the call
Nov 27 16:02:35 <jmpdelos> YPTM: Jeff Polk
Nov 27 16:02:46 <cristianiorga> YPTM: Cristian Iorga is on the call and online
Nov 27 16:03:10 <Song_Liu> YPTM: Any opens?
Nov 27 16:03:35 <davest1> YPTM: davest is in the house, now
Nov 27 16:03:57 <jzhang-laptop> YPTM: jzhang's on
Nov 27 16:04:24 <fray> which Mark?
Nov 27 16:04:28 <adamian> YPTM: no opens on me
Nov 27 16:04:30 <dvhart> YPTM: Darren is on
Nov 27 16:04:35 <dvhart> fray, you most likely
Nov 27 16:04:41 <dvhart> there is some overlap with deployment tooling
Nov 27 16:04:47 <Jefro> YPTM I can touch on the website and wiki
Nov 27 16:04:48 <pidge> YPTM: Beth joined
Nov 27 16:04:58 <fray> dvhart.. ahh with the stuff that we were discussing?
Nov 27 16:05:05 <dvhart> fray, right
Nov 27 16:05:13 <fray> ok.. I'm clueful now.. :)
Nov 27 16:05:17 <fp> YPTM: Amit here
Nov 27 16:05:22 <dvhart> they are looking to do some post image configuration
Nov 27 16:05:26 * bluelightning is located in the UK
Nov 27 16:05:55 <fray> ok..  I know that is something we want as well, but it's not something that has been in the scope of the work I've proposed at this point
Nov 27 16:06:17 <eren> oh ok, so the team is spread across :)
Nov 27 16:06:21 <dvhart> fray, right, but since the overlap is there, good to make sure we aren't running in opposite directions
Nov 27 16:06:22 <eren> across the world*
Nov 27 16:06:28 <dvhart> eren, yes
Nov 27 16:06:47 <eren>  @intel.com mail does not mean that they are all from specific office in US, then
Nov 27 16:06:51 <fray> yup..  we've discussed it in the past at WR, and one of the things we -really- want for device configuration is to not have to run it on the device.. :)
Nov 27 16:07:50 <rburton> the devel teams are mostly, iirc, in europe and america - so this time is reasonably late for europe and reasonably early for the US
Nov 27 16:08:30 <fray> ya.. for WR our development teams are primarily in each of the North American timezones, as well as central Europe..
Nov 27 16:08:54 <fray> our test teams are primarily in China.. (note there are developers in China, and testers in North America and Europe as well)
Nov 27 16:10:52 <rburton> eren: @intel for yocto *generally* means west coast US, UK, Romania, those are where the big offices are. Apart from when it doesn't...
Nov 27 16:12:17 <eren> oh oke, thanks to all
Nov 27 16:12:38 <davest1> Poor Saul has a leaky roof too
Nov 27 16:13:15 <fray> ouch..
Nov 27 16:14:49 <davest1> yeah, we get a bit of rain in Oregon
Nov 27 16:17:16 <eren> ops, disconnected?
Nov 27 16:19:55 <fray> YPTM:  I will be reading and responding to it today...
Nov 27 16:20:15 <fray> As Darren said, this is similar to work we've already talked about..  I have thoughts I'll put in the email..
Nov 27 16:20:26 <fray> I do echo RP's concerns about -one- image creation infrastructure
Nov 27 16:20:37 <fray> I only want one set of bugs to fix.. :)
Nov 27 16:22:56 <eren> I had a connection problem, what's the current topic?
Nov 27 16:25:25 <bluelightning> eren: the open about building images external to the entire build process
Nov 27 16:25:45 <eren> bluelightning: thanks
Nov 27 16:28:22 <Jefro> I think I put everyone to sleep
Nov 27 16:28:32 <eren> :)
Nov 27 16:28:34 <fray> Zzzzzz
Nov 27 16:28:43 <Zagor> Jefro: :)
Nov 27 16:28:44 <eren> it even made me disconnect!
Nov 27 16:28:52 <Jefro> eren :)
Nov 27 16:30:38 <fray> dvhart --woohoo--
Nov 27 16:32:15 <dvhart> fray, :)
Nov 27 16:32:30 <adamian> guys
Nov 27 16:32:36 <adamian> ro team, please do share
Nov 27 16:32:41 <adamian> what have you been doing for the last week
Nov 27 16:32:50 <adamian> cristi, you go first, laur next
Nov 27 16:32:50 <rburton> dvhart: i was writing a commit message... - something about extfs?
Nov 27 16:33:35 <adamian> ioana, next :)
Nov 27 16:33:55 <dvhart> rburton, yes, adding a -d option to populate the fs after creation from a root dir
Nov 27 16:34:07 <rburton> dvhart: neat
Nov 27 16:34:28 <Jefro> davest1 Love Stinks!
Nov 27 16:34:39 <dvhart> rburton, this brings ext3/4 into feature completeness with the rest of the FSs in terms of initial dir
Nov 27 16:34:48 <dvhart> rburton, or it will when it's done :)
Nov 27 16:34:49 <davest1> Jefro: that's the song I was thinking of, but I couldn't cough it up
Nov 27 16:38:26 <Zagor> I won't harp on about ptest unless someone has a question.
Nov 27 16:39:47 <eren> Zagor: actually I would like to know what's the motivaton behind it. I've seen your RFC in the commit message
Nov 27 16:40:00 <eren> but a summary for it would be helpful
Nov 27 16:41:47 <Zagor> eren: the motivation is simply to use the large amount of tests that are included in the packages we build
Nov 27 16:42:51 <eren> so just seperate test code, build it, name it ${PN}-ptest, and run the tests later?
Nov 27 16:43:08 <Zagor> yes
Nov 27 16:43:23 <RP> Zagor: I did look at the patches and sent some replies
Nov 27 16:43:42 <RP> Zagor: I'm also contemplating ways of simplifying the -dbg package creation
Nov 27 16:44:20 <fray> RP, I'm interested in any ideas on that.. what is currently implemented is a combination of the older Poky way and the RPM style generation..
Nov 27 16:44:23 <rburton> eren: some packages - glib and dbus for example, have massive test scripts that we just can't run
Nov 27 16:44:25 <Zagor> RP: yes, thanks for that. I have some updates in the works based on them.
Nov 27 16:44:59 <RP> fray: I mean the FILES_${PN}-dbg = "xxx/.debug/" part
Nov 27 16:45:14 <RP> fray: perhaps just hardcode this in the packaging function
Nov 27 16:45:24 <Zagor> glib do_install is now down to "make install-ptest". updated patch coming tomorrow.
Nov 27 16:45:28 <RP> halstead: looking forward to autogenerated graphs! :)
Nov 27 16:45:35 <fray> Ahh.. so as it does it's work, add all of the .debug?
Nov 27 16:45:42 <RP> Zagor: great :)
Nov 27 16:45:46 <RP> fray: yes
Nov 27 16:46:06 <eren> DE TA1AET
Nov 27 16:46:07 <fray> ya, that seems reasonable.. ;)
Nov 27 16:46:17 <Jefro> I believe Crofton|work is a ham
Nov 27 16:46:22 <eren> who are the other hams? :)
Nov 27 16:46:29 <pidge> KF7ESD eren
Nov 27 16:46:55 <eren> oh pidge, I was going to send a mail to you about meta-hamradio
Nov 27 16:47:26 <pidge> eren: Oh good. It's horribly unmaintained.
Nov 27 16:54:41 <dvhart> https://wiki.yoctoproject.org/wiki/Kernel/1.4_Planning
Nov 27 18:48:10 <mranostay> so where does /etc/hostname get set for a image? i need to override it
Nov 27 18:52:17 <kergoth> mranostay: probably base-files
Nov 27 18:56:09 <msm> how does poky-buildhistory work?
Nov 27 18:56:17 <msm> there appears to be just one commit?
Nov 27 18:56:44 <msm> nevermind, things are on branches
**** ENDING LOGGING AT Wed Nov 28 02:59:59 2012

**** BEGIN LOGGING AT Wed Nov 28 02:59:59 2012
Nov 28 11:59:55 <eballetbo> what is the correct way to auto load kernel modules ? Is the module_autoload_* in use or is deprecated ?
Nov 28 12:46:18 <JaMa> eballetbo: it's still in use
Nov 28 12:46:57 <eballetbo> JaMa: Thanks for the answer, how can I use it ?
Nov 28 12:54:09 <JaMa> grep bsp layers for examples
Nov 28 12:54:28 <JaMa> and be extra carefull with dash/underscore difference
Nov 28 12:54:58 <JaMa> eballetbo: e.g. https://github.com/shr-distribution/meta-smartphone/blob/shr/meta-openmoko/conf/machine/om-gta02.conf
Nov 28 12:57:13 <eballetbo> JaMa: cool, thanks for the example.
Nov 28 13:11:41 <RP> JaMa: 3484 is an interesting bug. Explains a few things...
Nov 28 13:11:51 <RP> JaMa: not sure how to fix it mind ;-)
Nov 28 13:38:11 <JaMa> RP: btw this behavior is there for _long_ time
Nov 28 13:38:22 <JaMa> RP: maybe since I switched to oe-core
Nov 28 13:38:40 <RP> JaMa: since http://git.yoctoproject.org/cgit.cgi/poky/commit/bitbake/lib/bb/siggen.py?id=d485d0b0e875c9f5161645647472ce72af8d322e as far as I can tell
Nov 28 13:39:07 <JaMa> RP: but it was hidden by some other issues at first (rm_work removing more stamps then it should and different sstate checksums between machines)
Nov 28 13:39:24 <JaMa> RP: much longer for sure
Nov 28 13:39:48 <RP> JaMa: right. I have a fix for the issue and its related to that code. Whether there is some other issue I don't know
Nov 28 13:40:00 <JaMa> https://bugzilla.yoctoproject.org/show_bug.cgi?id=1916 is basically the same
Nov 28 13:40:01 <yocti> Bug 1916: normal, Medium, 1.2 M3, richard.purdie, RESOLVED FIXED, do_package* tasks are executed for all recipes after MACHINE change
Nov 28 13:43:03 <RP> JaMa: its a different cause
Nov 28 13:45:10 <JaMa> RP: true for different machine, but I was seeing do_package reexecuted at that time just when MACHINE was switched back and forth on exacly the same MACHINE config
Nov 28 13:45:45 <RP> JaMa: Lets get a fix for this issue in, then we can see if there are other problems
Nov 28 13:45:52 <JaMa> but I'll try to reproduce with your fix for that code to be sure it's still there
Nov 28 13:45:57 <JaMa> yes
Nov 28 13:48:02 <RP> JaMa: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t4&id=410992035cc5153ae058d65f0f8b9c4105f0f305 is the fix
Nov 28 13:48:16 <JaMa> RP: what do you think about removing --force-overwrite from package_ipk and rootfs_ipk? It was added by you in 2010, commit 8c3a7ebac8bed700bcc37f778d5a883cfeee8de8 but only conflicting files in my big images are now gst*
Nov 28 13:48:39 <RP> JaMa: if we don't need it, I'm ok with it
Nov 28 13:48:42 <JaMa> RP: so I think removing --force-overwrite would be good check for package sanity
Nov 28 13:49:02 <RP> JaMa: I thought there were issues  but yes, if it works ok...
Nov 28 13:49:25 <JaMa> ok, I'll send RFC for people to test their images too
Nov 28 13:49:57 <JaMa> and with that, one more proposal: few times I've mentioned world-image target
Nov 28 13:50:34 <JaMa> for my feed I'm using special image which installs all packagegroup-* to check that all packages can be installed by package manager
Nov 28 13:51:01 <JaMa> I've checked how bitbake generates list of build targets for "world"
Nov 28 13:51:44 <JaMa> and I haven't found way to add world-image.bb recipe which would IMAGE_INSTALL = "world"
Nov 28 13:52:06 <JaMa> I was thinking about saving that list in bitbake code to some variable and then reuse it from recipe
Nov 28 13:53:16 <JaMa> or better add another world-image set, which would gather not all PF, but sum of all PACKAGES unless some are excluded by EXCLUDED_FROM_WORLD_IMAGE = "runtime_package_foo"
Nov 28 13:53:47 <JaMa> but I'm not sure if bitbake code (cooker + cache) is right place to do this
Nov 28 14:07:42 <RP> JaMa: We probably do need to share some of that data somehow...
Nov 28 14:07:58 <RP> JaMa: Its figuring out a good api to do it that is hard
Nov 28 14:09:55 <JaMa> if we agree that world-image would be usefull at least for testing on jenkins/autobulder I'll fill feature request
Nov 28 14:13:14 <RP> JaMa: Feel free to file it but I'm not sure if/when we'll have time to do it :/
Nov 28 14:49:22 <schramae> hi. is there a bitbake cmd to clean/rebuild a specific recipe? the build of core-image-x11 fails because of glib-2.0, so i'm trying to just rebuild glib. i did " bitbake -C INVALIDATE_STAMP glib-2.0" and ran the image recipe again, but it still fails with a QA error.
Nov 28 14:51:20 <rburton> -c clean will clean the build away
Nov 28 14:51:33 <rburton> so bitbake -c clean glib-2.0
Nov 28 14:58:10 <schramae> thx, that worked, but now another one is failing - do i clean all those failing ones recursively until the image builds again or is there a better way?
Nov 28 14:59:18 <rburton> well, what's the problem?
Nov 28 14:59:55 <rburton> if your tmp got messed up you can blow away the tmp (assuming that your sstate is outside of tmp) and it will rebuild in a few minutes using the sstate
Nov 28 15:01:46 <schramae> libtool is missing some .la files (i enabled 32b multilibs on a cached 64b target, maybe that messed sth. up) and i don't want to do a complete clean/rebuild
Nov 28 15:02:42 <rburton> urgh, libtool
Nov 28 15:04:12 <rburton> following the libtool fails might be the easiest way
Nov 28 15:04:47 <rburton> deleting all .la files in the sysroot won't work as they'll be refered to in the generated makefiles
Nov 28 15:05:14 <rburton> (i think there was a patch to just nuke every .la before it reached sysroot)
Nov 28 15:08:47 <schramae> i manually cleaned/rebuilt 3 recipes now and get the same glib error again - maybe a complete rebuild will be best. but thanks anyway :)
Nov 28 15:09:25 <rburton> .la breakage is really infectious
Nov 28 15:10:09 <rburton> i shall make it my mission to get the patch that removes those files on stage integrated this week!
Nov 28 15:14:19 <schramae> sounds good - maybe i should consider working with the git version instead of the release tarball
Nov 28 15:15:11 <bluelightning> schramae: if you do switch I'd recommend sticking to one of the stable branches at least
Nov 28 15:15:18 <bluelightning> e.g. danny
Nov 28 15:16:26 <schramae> yeah, that stable argument lead me to 1.3. and i'm not a git wizard (yet), so...
Nov 28 15:16:33 <rburton> schramae: i'd say always work with a git checkout, even if its the stable branc
Nov 28 15:17:46 <schramae> do new changes/fixes get backported to the release branches?
Nov 28 15:18:59 <rburton> schramae: only critical ones, but yes (i'm the danny maintainer)
Nov 28 15:19:19 <rburton> speaking of which considering i just merged a cve, it's probably worth starting on a merge
Nov 28 15:20:32 <schramae> i see, thanks
Nov 28 15:20:54 <rburton> schramae: basic rule is no features, no upgrades
Nov 28 15:21:05 <rburton> but build fixes and security fixes are good
Nov 28 15:21:19 <schramae> ok
Nov 28 15:25:37 <schramae> another thing i haven't found a good answer to yet: were developing on CentOS 6, meaning older versions of GCC, libc(++) etc.. the GCC page says major releases may break the ABI, but acc. to the changelogs this should not be an issue between GCC 4.4 and 4.7 and libc is said to be backward-compatible. may there be any issues with using the CentOS binaries on yocto or would it be advisable to rebuild/cross-compile everything?
Nov 28 15:26:56 <rburton> schramae: depends on what you linked against, but assuming no abi changes the binaries will likely work.
Nov 28 15:27:12 <rburton> that said, best to cross-compile in yocto so your entire build is in one place, right?
Nov 28 15:27:36 <JaMa> RP: that bitbake patch seems to be fixing at least that simple test case I had in #3484, thanks
Nov 28 15:30:14 <RP> JaMa: np, pleased its working, at least so far and for the test case
Nov 28 15:30:28 <RP> JaMa: as you suspected it fixes a deeper problem
Nov 28 15:30:35 <schramae> rburton: i was afraid of that answer as it would mean rebuilding some tons of 3rd-party libs
Nov 28 15:57:25 <schramae> rburton: would it be an option to downgrade yocto's src pkgs of GCC/(e)glibc/... to the versions used by CentOS or can this cause other problems? i'm thinking of "In general host OS's with GCC 4.7 won't be able to build Edison" and such...
Nov 28 15:58:37 <rburton> schramae: you'll be on your own then.  if your worry is glibc/gcc then generally i think you'll be okay. (maybe less so with c++)
Nov 28 16:00:17 <schramae> i see, thanks
Nov 28 16:39:59 <kergoth> schramae: toolchain-layer in meta-oe has 4.6. we (mentor) use an external 4.6 toolchain, which fails to compile a target gcc 4.7, so had to use toolchain-layer to back that up to 4.6 to get it built successfully. not directly related to your question, but figured I'd throw it out there
Nov 28 16:46:24 <schramae> kergoth: thanks. i was just considering possibilities, but i think i'd rather prefer sticking to the stable and tested yocto toolchain instead of fiddling around with it and creating new problems. but now i'm wondering how hard it will be to integrate our build system (scons based), rebuild all 3rd libs, what to do if not all other required libs are yet present in yocto and so on...
Nov 28 16:49:58 <kergoth> heh, have fun :)
Nov 28 16:50:19 <schramae> ;)
Nov 28 17:29:52 <flihp> has anyone seen a vanilla danny build hang on noexec tasks before?
Nov 28 17:30:14 <flihp> I'm building danny from tgz straight off the yocto website on Centos 6
Nov 28 17:31:34 <flihp> core-image-minimal for qemux86 is hanging with a number of noexec do_build tasks
Nov 28 17:32:10 <flihp> I've got a number of bitbake processes which seem to be sitting around doing nothing
Nov 28 17:33:41 <bluelightning> can't say I have; I'm using danny on my build machine and that runs Centos 6.3
Nov 28 17:34:24 <bluelightning> flihp: even so I would recommend reporting it as a bug though as it shouldn't be doing that
Nov 28 17:36:33 <flihp> bluelightning: ack, opening bug tracker account
Nov 28 17:36:44 <bluelightning> thanks
Nov 28 17:44:17 <schramae> flihp: no problems here so far (core-image-minimal from tgz on CentOS 6.3), though i only used qemux86-64 so far
Nov 28 17:56:22 <b1gtuna> Anyone having problem fetching kmod? it looks like they moved repo to git://git.profusion.mobi/users/gustavo/kmod.git
Nov 28 17:57:18 <flihp> weird, none of my bitbake processes got zombied till I tried to kill one off (it had been running for 1.5 hours)
Nov 28 18:11:27 <flihp> killed build, restarted and it hung on fetch of glib-2.0, killed again and deleted glib files (including .lock) in downloads dir
Nov 28 18:11:36 <flihp> build seems to be happy now
Nov 28 18:12:28 <flihp> bluelightning: still think it's worth reporting? seems to have been caused by cruft kicking around in my downloads dir
Nov 28 18:13:10 <bluelightning> flihp: hmm... I think maybe it's still worth reporting in case we can handle that situation better
Nov 28 18:13:39 <flihp> will kick off a fresh build to see if it happens again after a successful one
Nov 28 18:13:52 <flihp> bluelightning: ack, I'm on it
Nov 28 19:13:24 <walters> hm, is there a reason there's no i686 tune in poky?
Nov 28 19:14:09 <walters> eh, guess i should just do atom = core2
Nov 28 19:27:32 <RP1> walters: no good reason i686 is missing, no and yes, core2 and atom are very similar tune wise
Nov 28 19:32:53 <Crofton> someone did omethign to make an image recipe spit out a toolchain
Nov 28 19:32:58 <Crofton> is this a true memory
Nov 28 19:33:37 <bluelightning> Crofton: we can produce an SDK from an image if that's what you mean
Nov 28 19:33:45 <bluelightning> bitbake -c populate_sdk <imagename>
Nov 28 19:34:10 <Crofton> ah OK
Nov 28 19:55:51 <b1gtuna> meta-oe's denzil branch contains kmod. The source has been recently moved to git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git
Nov 28 19:58:33 <yao_> I have a package which makefile will install realname and linker name shared library,  but not the soname library
Nov 28 19:59:03 <yao_> should I modify makefile to install soname library or I should use "USE_LDCONFIG" or the PACKAGE_SNAP_LIB_SYMLINKS
Nov 28 20:03:51 <otavio> rburton: Did you look at the patches I sent for danny?
Nov 28 20:04:01 <otavio> rburton: anything need from my side?
Nov 28 20:24:43 <yao_> any help?
Nov 28 20:43:06 <yao_> anyone helps on the soname library question?
Nov 28 20:52:50 <yao_> should I use the USE_LDCONFIG="1"
Nov 28 21:32:15 <seebs> yao_, I am not sure I am understanding the question. Why are you not installing the soname library?
Nov 28 21:32:37 <yao_> not me, it is a package
Nov 28 21:33:00 <yao_> makefile didn't install the soname library but a realname library+linker name library
Nov 28 21:33:30 <yao_> normally it should be job of ldconfig to create soname library link on target
Nov 28 21:33:50 <yao_> so makefile didn't install, I think it is normal
Nov 28 21:34:00 <yao_> just not sure normally what to do with bitbake
Nov 28 21:34:12 <yao_> any idea? seebs?
Nov 28 21:35:01 <seebs> I would change the package to create the soname library link because cross-development is different from normal Linux self-hosted development.
Nov 28 21:35:36 <seebs> The goal is to be able to create an image which is fully finalized and does not need to do special initialization tasks after boot.
Nov 28 21:36:01 <yao_> there is a special var called USE_LDCONFIG
Nov 28 21:36:43 <seebs> Huh. You could try setting it and see what it does, I guess. I've never used it. (I have only marginal experience with BB packaging, I'm afraid.)
Nov 28 21:37:04 <yao_> it can enable post_inst to run ldconfig. I was wondering why do_package doesn't do this default to create the soname library if there is no soname library?
Nov 28 21:37:51 <yao_> instead of patching makefile or write in recipe, not quite nice
Nov 28 21:38:07 <fishcooker> hello fellas
Nov 28 21:38:13 <kergoth> ldconfig is almost always unnecessary. where exactly are you installing files, and why?
Nov 28 21:38:13 <fishcooker> LoL
Nov 28 21:38:18 <kergoth> you should be putting things in the correct places
Nov 28 21:38:55 <kergoth> ldconfig is generally used to update /etc/ld.so.cache so the runtime linker can find the libraries
Nov 28 21:39:09 <kergoth> as far as i'm concerned, creating some sort of symlink is at best a side effect
Nov 28 21:39:16 <kergoth> make install should be doing it, always
Nov 28 21:39:27 <kergoth> (and it does, for autoconf/automake and plenty of other buildsystems)
Nov 28 21:39:34 <yao_> I have a package installed realname library libabc.so.1.0 and linkername library libabc.so but make install didn't install the soname lib
Nov 28 21:39:42 <kergoth> then make install is broken
Nov 28 21:39:56 * kergoth goes back to fighting bitbake
Nov 28 21:39:57 <seebs> My intuition is that a package should always install all the things it thinks it wants.
Nov 28 21:40:10 <yao_> It is pretty normal for most of distros
Nov 28 21:40:22 <yao_> ldconfig will install the soname lib link
Nov 28 21:40:30 <kergoth> no, actually, it's not, as I just pointed out, the most popular upstream buildsystems install the link themselves
Nov 28 21:40:40 <kergoth> as they should
Nov 28 21:41:03 <yao_> it is standard?
Nov 28 21:41:04 <mihai> make install errors in temp/log.do_install? on either the library or whatever package you are trying to install?
Nov 28 21:41:21 <kergoth> yao_: I really don't see why you'd want to install a library that your binaries won't be able to use
Nov 28 21:41:28 <yao_> mihai: no errors, I am bitbaking one package
Nov 28 21:41:34 <kergoth> producing a useless install is a bit silly
Nov 28 21:42:11 <yao_> kergoth: http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
Nov 28 21:42:34 <kergoth> people still read howtos? seriously?
Nov 28 21:42:43 <mihai> yao_: the errors might not reach your console, have you checked the packages logs?
Nov 28 21:44:06 <yao_> mihai: what kind of errors you mean? do_package no error
Nov 28 21:44:40 <kergoth> yao_: plenty of embedded distros don't even have, use, or need ldconfig.
Nov 28 21:45:24 <yao_> kergoth: do you know why do_package doesn't create the soname if make install didn't?
Nov 28 21:46:07 <yao_> it will save time as some packages rely on ldconfig to create it
Nov 28 21:46:10 <kergoth> why would it?
Nov 28 21:46:24 <kergoth> we have *thousands* of recipes that work just fine without it
Nov 28 21:46:32 <kergoth> those packages should get better buildsystems
Nov 28 21:47:15 <yao_> yes, they work fine but you have to patch makefile or hook do_install to make it, right? if the package didn't install the soname lib
Nov 28 21:47:40 <yao_> I mean upstream package
Nov 28 22:41:47 <kergoth> yao_: or contact upstream and get them to do it properly. most developers know almost nothing about buildsystems and blindly copy them from other people.
Nov 28 22:42:17 <yao_> thanks kergoth!
Nov 28 22:43:40 <kergoth> ldconfig can be used, but not for install, only for population of ld.so.cache at rootfs construction time or first boot time on the target
Nov 28 22:44:27 <yao_> yes, so I was considering the USE_LDCONFIG
Nov 28 22:44:41 <yao_> to workaround it:)
Nov 28 22:45:16 <yao_> thanks, I go fixing the makefile
**** ENDING LOGGING AT Thu Nov 29 02:59:59 2012

**** BEGIN LOGGING AT Thu Nov 29 02:59:59 2012
Nov 29 08:36:55 <mckoan> good morning
Nov 29 10:02:15 <bluelightning> morning all
Nov 29 12:26:31 <Guest31884> hello, i have stumbled over a problem in the python_setuptools recipe. A part of the installation with distutils, the recipe installs a shell script in /usr/bin/. This shell script contains the header line /usr/bin/python-native/python instead of the correct line /usr/bin/python.
Nov 29 12:29:39 <Guest31884> Has anyone seen this problem before?
Nov 29 13:02:51 <JaMa> RP: is bitbake supposed to parse recipes on filesystem again when it's already running runqueue or should it use only cached values?
Nov 29 13:04:04 <JaMa> RP: e.g. if you change PR in recipe between do_compile and do_install, when bitbake is running, should it use old PR value in both tasks or fail in do_install because WORKDIR with new PR does not exist?
Nov 29 13:27:10 <drlota> Hey all. Before I fail miserably I could ask is this valid way to add kernel modules to minimal yocto image: MACHINE_EXTRA_RRECOMMENDS = " kernel-modules" [in my local.conf]?
Nov 29 13:34:36 <drlota> I am currently testing that, but I would appreciate if someone could point me some guide/tutorial how to add individual kernel modules to image. All I need is usbnet and cdc_ncm modules so adding all feels stupid.
Nov 29 13:46:35 <bluelightning> drlota: that will indeed add all kernel modules; for individual modules you can add kernel-module-modulename
Nov 29 13:46:51 <bluelightning> drlota: in your case I would guess you need to add kernel-module-usbnet and kernel-module-cdc-ncm
Nov 29 13:48:29 <bluelightning> Guest31884: the script should probably be changing that to #!/usr/bin/env python
Nov 29 13:48:41 <bluelightning> Guest31884: or rather, the recipe should be changing it
Nov 29 13:52:27 <Guest31884> Thanks for your answer. Currently, I patch the resulting rpm file after running the recipe. The heart of the problem is somehow in the distutils.bbclass, because it does not set the executable correctly.
Nov 29 13:53:00 <rburton> Guest31884: well, it's using the python that it ran...
Nov 29 13:56:30 <Guest31884> yes, the distutils tool builds those scripts with the python that it ran, but it allows to overwrite the python-executable with --executable. I would expect that distutils.bbclass uses that option correctly.
Nov 29 13:57:06 <RP> JaMa: It will fail. It does parse whilst running
Nov 29 13:57:08 <Guest31884> but the distutils.bbclass (in poky-danny-8.0) does not.
Nov 29 13:57:27 <rburton> Guest31884: ah.  is that executable ever used at build time?
Nov 29 13:57:34 <JaMa> RP: ah, then ok
Nov 29 13:57:36 <rburton> Guest31884: otherwise that's a good fix
Nov 29 13:58:26 <Guest31884> In most cases, the scripts are not used at build time, but only afterwards in the image.
Nov 29 14:07:04 <Guest31884> rburton: If this fix sounds reasonable to you and others, I will continue adjusting the distutils class and send a patch to the mailing list with some motivation and rationale for the patch. Is that the common way to contibute?
Nov 29 14:09:41 <bluelightning> Guest31884: yes, that would be much appreciated
Nov 29 14:10:33 <bluelightning> Guest31884: patches/change discussions should be sent to the openembedded-core@lists.openembedded.org mailing list though
Nov 29 14:12:19 <Guest31884> Thanks for your help. I will be sending an email within the next days then to that mailing list.
Nov 29 14:16:22 <drlota> bluelightning: Yes, of course. I will try that. Thanks for the help
Nov 29 16:12:29 <kergoth> Hmm, wonder if postfuncs/prefuncs should be in function deps by default.. probably..
Nov 29 16:53:54 <kergoth> ugh, so many issues due to the removal of the '.' filespath fallback
Nov 29 17:13:21 <else58> I'm trying to add meta-oe/meta-oe at a lower priority than poky/meta-oe with 'BBFILE_PRIORITY_meta-oe = "4"' in conf/bblayers.conf, but it doesn't take: http://pastebin.com/NMEGwC0R
Nov 29 17:14:14 <else58> I also tried putting it in local.conf.  What am I missing?
Nov 29 17:17:33 <jchonig> How do I get grub2's attention during boot?
Nov 29 17:20:33 <kergoth> else58: meta-oe isn't the name of the layer. read meta-oe/meta-oe/conf/layer.conf
Nov 29 17:20:54 <kergoth> else58: BBFILE_PRIORITY_<foo> only works if <foo> is listed in BBFILE_COLLECTIONS
Nov 29 17:30:00 <else58> kergoth: thanks.  I see 'BBFILE_PRIORITY_openembedded-layer = "6"', so overriding it in local.conf works (but not bblayers.conf)
Nov 29 17:30:59 <else58> why doesn't meta-oe use ?= 6 so it can be overridden in bblayers.conf?
Nov 29 17:33:10 <kergoth> layer priority isn't something that's generally intended to be touched by the user
Nov 29 17:35:20 <lisandro> hi! I would like to know if there is a fix for the huge kernel that 1.3 does for the routerstationpro
Nov 29 17:38:12 <lisandro> mm, maybe I should be asking in #poky :-/
Nov 29 18:01:51 <sgw1> khem: did you see my email about the failure for oprofile?
Nov 29 18:11:12 <else58> thanks, qemux86 core-image-sato keyboard/mouse input had stopped working when I added the meta-oe layer
Nov 29 18:13:06 <else58> it turns out it needed the udev bb from poky since it installs /etc/init.d/udev and the one in meta-oe does not
Nov 29 18:13:21 <kergoth> ah, right
Nov 29 18:13:32 <kergoth> yeah, I trust oe-core quality more than meta-oe when somethign is in both..
Nov 29 18:13:39 <kergoth> meta-oe is nice as a pile of 'extra' recipes
Nov 29 18:18:06 <else58> yes, i'm trying to get emacs to build, but i'm having trouble with qemux86 crashing
Nov 29 19:42:43 <fishcooker> i've seen yocto tool chain .. what's the big deal of x86_64 and x86 for arm architecture?
Nov 29 19:43:13 <fishcooker> is there any pros for x86_64 rather than x86
Nov 29 19:43:43 <fishcooker> AFAIK X86 will run on everywhere
Nov 29 19:44:45 <mranostay> fishcooker: if you have compat libs
Nov 29 19:45:50 <fishcooker> my box x86_64 but im still on x86
Nov 29 19:46:17 <fishcooker> is that x86_64 too superior, mranostay?
Nov 29 19:49:53 <mranostay> don't know x86 is my last choice in a processor :)
Nov 29 19:53:13 <hollisb> fishcooker: 32-bit software on x86-64 hardware can't use a bunch of hardware registers, so it's typically slower than the equivalent 64-bit software
Nov 29 19:56:31 <fishcooker> LoL mrano.. is there no power consumption issue on x86_64 rather than x86 hollisb?
Nov 29 19:56:53 <hollisb> fishcooker: you'd have to compare specific chips
Nov 29 19:58:11 <lisandro> fishcooker: that was in the first series of x86_64 (aka amd64) processors
Nov 29 19:58:20 <lisandro> at least afaik
Nov 29 20:01:08 <fishcooker> well i will switch to x86_64 on my i3
Nov 29 20:01:25 <fishcooker> thanks for the info lisandro hollisb mranostay
Nov 29 20:01:36 <fishcooker> its something
Nov 29 20:01:40 <fishcooker> LoL
Nov 29 20:46:08 <kergoth> Anyone playing with read only rootfs nowadays? I haven't looked into that in *years*, but I know I've heard people bring it up from time to time
Nov 29 20:47:24 <walters> kergoth: for gnome-ostree, i have read-only bind mounts over everything except /var
Nov 29 20:48:29 <walters> but, i only use yocto to generate a toolchain...the core uses systemd, and some tweaks like symlinking /etc/resolv.conf to /run/resolv.conf, etc
Nov 29 20:48:37 * kergoth nods
Nov 29 20:48:38 <walters> er, except /var and /etc
Nov 29 20:49:00 <kergoth> I realize we don't yet have a convenient way to toggle the behavior, seems like everyone is using a custom layer to implement it themselves if they need it
Nov 29 20:49:14 <kergoth> and of course the 'behavior' varies
Nov 29 20:49:21 <kergoth> union mount vs bind vs whatever
**** ENDING LOGGING AT Fri Nov 30 02:59:58 2012

**** BEGIN LOGGING AT Fri Nov 30 02:59:58 2012
Nov 30 08:44:11 <mckoan> good morning
Nov 30 09:54:46 <bluelightning> morning all
Nov 30 12:44:00 <Ramana_> Hi Corneliux, r u online
Nov 30 12:44:38 <mihai> Ramana_: he's trying to join now
Nov 30 12:45:00 <Ramana_> ok thanks I will wait
Nov 30 12:46:23 <corneliux> hello
Nov 30 12:46:32 <Ramana_> hi
Nov 30 13:35:43 <zeddii> anyone else seeing binutils build errors on ubuntu 12.10 ?
Nov 30 13:35:46 <zeddii> http://pastebin.com/U1PkwJHx
Nov 30 13:36:01 <zeddii> I was trying to build the routerstation pro to debug a kernel issue and boom.
Nov 30 13:37:48 <ant_work> hi zeddii
Nov 30 13:38:06 <ant_work> I have one install of 12.4 which I plan to upgrad to 12.10
Nov 30 13:38:46 <zeddii> I've moved everything to 12.10, but I hadn't built this target in a bit .. so I'm not sure if it's new, or has been around.
Nov 30 13:38:54 <zeddii> part of the 'fun' .. I guess :)
Nov 30 13:39:01 <ant_work> heh
Nov 30 13:39:27 * zeddii fires off the same build on an old machine he just found
Nov 30 13:41:25 <ant_work> iirc I installed 32-bit, I'll have to check on the dark partitions of the disk...(tm)
Nov 30 13:42:08 <zeddii> binutils just built on my old ubuntu box. same routerstationpro build. my 12.10 was a 64 bit install. hmmm.
Nov 30 13:42:41 <ant_work> in one sense it's ok for you to build on Ubuntu x86-64 being it seems second only to Fedora in exposing new bugs :)
Nov 30 13:43:01 <ant_work> I build on Gentoo 32-b and have lost all this fun...
Nov 30 13:44:07 <ant_work> (enough issues already, no need for buildhost quirks ;)
Nov 30 13:44:32 <zeddii> :)
Nov 30 13:44:37 <zeddii> so true ..
Nov 30 13:48:40 <ant_work> zeddii: hmm.. isn't this?  http://comments.gmane.org/gmane.comp.gnu.binutils/56278
Nov 30 13:49:13 * zeddii reads
Nov 30 13:49:18 <zeddii> yep. that does look the same.
Nov 30 13:49:49 * zeddii tries out the fix and will owe ant_work!
Nov 30 13:50:28 <ant_work> we are 1 -1 with the beer I owed you in Barcelona and we couldn't drink together
Nov 30 13:50:40 <ant_work> ^_^
Nov 30 13:51:17 <zeddii> ant_work, you know what's funny .. I remembered that on my way out of the city. Hopefully another time!
Nov 30 13:57:08 <zeddii> woo. that does indeed fix the build.
Nov 30 14:03:42 <ant_work> btw I'm still unsure about the best way to override yocto-standard settings to reduce kernel size. I'm now adding the 'is not set' in one separate file and including it as last
Nov 30 14:04:13 <ant_work> still have to check how the redefinition outcomes
Nov 30 19:16:30 <lisandro> hi! what doc could I read to know how to add more modules in my kernel image?
Nov 30 19:34:25 <hollisb> lisandro: probably here: http://www.yoctoproject.org/docs/1.0/poky-ref-manual/poky-ref-manual.html#bsp-filelayout-kernel
Nov 30 19:35:03 <lisandro> thanks!
Nov 30 19:37:17 <hollisb> lisandro: important note: it matters which kernel/BSP you're using
Nov 30 19:37:33 <lisandro> linux-yocto, routerstationpro
Nov 30 19:37:44 <hollisb> ok, that's the right doc then
Nov 30 19:37:52 <lisandro> thanks :)
Nov 30 19:38:07 <hollisb> I tried to use the config file fragment approach with meta-ti's kernel, and found out that just doesn't work
Nov 30 19:38:46 <kergoth> heh, it'd be nice if the config fragment stuff didn't require teh linux-yocto git repo bits
Nov 30 19:40:15 <hollisb> sure would :-)
Nov 30 20:00:46 <kergoth> NameError: global name 'license_type' is not defined
Nov 30 20:00:55 <kergoth> when attemptting to use INCOMPATIBLE_LICENSE
Nov 30 20:00:57 * kergoth investigates
Nov 30 20:12:55 <mranostay> kergoth: Friday at least, right? :)
Nov 30 22:18:05 <buoyMan> Crofton told me to ask this here.  Following the steps in the Yocto quick start guide on Ubuntu 12.04
Nov 30 22:18:38 <buoyMan> doing bitbake and compilation stops whenever gcc produces warnings
Nov 30 22:19:20 <buoyMan> ldgeneric.c:288:21: error: variable 'prevp' set but not used [-Werror=unused-but-set-variable]
Nov 30 22:19:20 <buoyMan> cc1: all warnings being treated as errors
Nov 30 22:19:54 <buoyMan> Is there a config somewhere I need to allow a build with errors?
Nov 30 22:20:26 <Crofton> this is weird, because that stuff is supposed to work out of the box
Nov 30 22:20:34 <Crofton> can you post the link to the guide you are using?
Nov 30 22:21:51 <Crofton> also, what recipe is it building when this happens
Nov 30 22:22:39 <Crofton> buoyMan, welcome to life on left coast afternoon, everyone else quit working
Nov 30 22:41:12 <Crofton> buoyMan, I feel like you need to use what they call Danny, not Bernard
Nov 30 22:50:54 <buoyMan> ok. will try
**** ENDING LOGGING AT Sat Dec 01 02:59:58 2012

**** BEGIN LOGGING AT Sat Dec 01 02:59:58 2012
**** ENDING LOGGING AT Sun Dec 02 02:59:59 2012

**** BEGIN LOGGING AT Sun Dec 02 02:59:59 2012
**** ENDING LOGGING AT Mon Dec 03 02:59:59 2012

**** BEGIN LOGGING AT Mon Dec 03 02:59:59 2012
Dec 03 07:57:18 <veera_ramana> Hi Conrneliux, are you there?
Dec 03 09:05:52 <mckoan> good morning
Dec 03 10:02:15 <fireboot> hi everybody
Dec 03 10:02:50 <fireboot> I'm using the Freescale SDK on a p4080 system
Dec 03 10:03:01 <fireboot> it uses yocto
Dec 03 10:03:29 <fireboot> I would like to compile a kernel module but i can't. There is no build directory with the approriate Makefile
Dec 03 10:04:32 <fireboot> the linux-headers-dev package is already installed but it seems to contain just... headers.
Dec 03 10:04:38 <fireboot> any idea?
Dec 03 10:12:41 <mckoan> fireboot: are you using the meta freescale stuff?
Dec 03 10:15:10 <fireboot> yeah
Dec 03 10:15:15 <fireboot> I used the "full" image
Dec 03 10:15:35 <fireboot> the name made me think that it would install everything
Dec 03 10:15:37 <fireboot> apparently not
Dec 03 10:15:46 <fireboot> mckoan: but actually I think I found the problem
Dec 03 10:16:03 <fireboot> the package kernel-dev was not installed, I just opened it in Ark and it seems to contain everything needed to build a module
Dec 03 10:17:04 <fireboot> my 2 cents: it's a bit odd, on every (desktop) distro I have tried, the package linux-headers or kernel-headers is what is needed to compile a module
Dec 03 10:17:13 <fireboot> maybe yocto should follow this pattern?
Dec 03 10:18:03 <fireboot> it's also a bit odd that the required files are installed in /usr/src/kernel, usually it's somewhere in /lib/modules
Dec 03 10:26:39 <likewise> gm
Dec 03 10:27:08 <mckoan> likewise: hi
Dec 03 10:27:56 <likewise> fireboot: are you sure?
Dec 03 10:27:59 <likewise> lrwxrwxrwx 1 root root 40 2010-11-06 22:26 /lib/modules/2.6.32-25-generic/build -> /usr/src/linux-headers-2.6.32-25-generic
Dec 03 10:28:36 <likewise> fireboot: as you can see (this is on my Ubuntu 10.04.4 host), the header are in /usr/src/linux-headers/
Dec 03 10:29:41 <likewise> fireboot: I agree linux-dev may be strange if you are used to your host distro, but actually libraries use -dev for their headers (and other development related files) too, so I think OE/YP is doing it quite right.
Dec 03 10:29:56 <likewise> bluelightning: gm
Dec 03 10:30:04 <likewise> mckoan: hi
Dec 03 10:35:04 <bluelightning> morning mckoan, likewise, all
Dec 03 10:52:41 <mckoan> hi bluelightning
Dec 03 11:39:53 <fireboot> likewise: what I meant is that the usual build directory to build kernel modules is in /lib
Dec 03 11:40:49 <fireboot> likewise: on my host system (running archlinux) it is located in /lib/modules/3.6.8-1-ARCH/build/
Dec 03 11:41:36 <fireboot> and I'm almost sure it's something similar in pretty much every distro
Dec 03 11:43:01 <likewise> fireboot: yes, that's what I mean as well. I'm just saying it's often a symlink.
Dec 03 11:43:17 <fireboot> true
Dec 03 11:43:34 <fireboot> but I think that for compatibility reasons maybe yocto should actually add this symlink
Dec 03 11:44:22 <fireboot> it's pretty common to see something like that in a module Makefile: make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
Dec 03 11:45:01 <mckoan> fireboot: that sounds reasonable
Dec 03 11:46:58 <fireboot> :)
Dec 03 11:47:20 <fireboot> another question: so as said I finally fount it that the required stuff to compile a kernel module is provided by the kernel-dev package
Dec 03 11:47:35 <fireboot> so I copied the corresponding .rpm from my host system to the target
Dec 03 11:47:49 <fireboot> and when I try to install it using rpm -ivh it complains about a missing patch
Dec 03 11:48:25 <fireboot> so I found this patch in the host system, copied it to the target and tried to fool the rpm by creating the same directory structure that rpm is expecting
Dec 03 11:48:33 <fireboot> but it still complains about the missing file
Dec 03 11:48:36 <fireboot> any idea?
Dec 03 11:48:46 <fireboot> (tell me if I wasn't clear enough)
Dec 03 12:05:50 <jackmitchell> fireboot: just a guess, should the patch not be contained in the actual RPM rather than the filesystem?
Dec 03 12:07:14 <fireboot> jackmitchell: no clue, but if that was the case, why hasn't it been put into the rpm when it was created?
Dec 03 12:07:41 <jackmitchell> fireboot: yes, that was the pitfall in my logic ;)
Dec 03 12:08:05 <fireboot> :)
Dec 03 12:21:53 <fireboot> likewise, mckoan, any suggestion?
Dec 03 12:23:38 <likewise> fireboot: not sure what you are trying to do? You want to build on the target machine?
Dec 03 12:24:01 <fireboot> yep
Dec 03 12:24:12 <fireboot> and for that I need to install the package kernel-dev
Dec 03 12:24:27 <fireboot> but it refuses to install and complains about a missing dependency
Dec 03 12:24:41 <fireboot> and even if I actually provide this missing dependency (a simple patch) it still complains
Dec 03 12:25:06 <likewise> fireboot: I'm only familiar with the cross-compile workflow.  -- I do not see how a patch can be a dependency? Packages only have dependencies on other packages.
Dec 03 12:25:28 <likewise> fireboot: you installed the kernel-dev package from what source?
Dec 03 12:25:44 <fireboot> # rpm -ivh kernel-dev-3.0.48-r5.p4080ds.rpm  error: Failed dependencies:         /home/moncef/QorIQ-SDK-V1.3-20121114-yocto/meta-fsl-ppc/recipes-kernel/linux/files/0001-compiler.h-Undef-before-redefining-__attribute_const.patch is needed by kernel-dev-3.0.48-r5.p4080ds
Dec 03 12:25:48 <fireboot> that's the message I get
Dec 03 12:25:58 <rburton> oh yay rpm :/
Dec 03 12:26:06 <fireboot> likewise: I downloaded the SDK from freescale's webpage
Dec 03 12:26:42 <rburton> i suspect you'll need a package providing that file - looks like kernel-dev is broken tbh
Dec 03 12:26:47 <rburton> (on rpm at least)
Dec 03 12:26:55 <rburton> do the module build in poky :)
Dec 03 12:27:12 <fireboot> I tried to fool rpm by creating on the target the directory /home/moncef/QorIQ-SDK-V1.3-20121114-yocto/meta-fsl-ppc/recipes-kernel/linux/files/ and putting the patch in it
Dec 03 12:27:41 <fireboot> rburton: sure thing, do you have any ressource explaining how to do that?
Dec 03 12:27:52 <fireboot> (I'm new on yocto :P)
Dec 03 12:28:09 <rburton> fireboot: the docs probably have something, but i've never written packaging for a kernel module
Dec 03 12:28:45 <fireboot> :(
Dec 03 12:29:56 <jackmitchell> fireboot: there are examples for module compiling in the meta-demo layer I believe
Dec 03 12:30:56 <fireboot> thanks I will have a look
Dec 03 12:32:03 <fireboot> ls
Dec 03 12:32:26 <fireboot> oosp
Dec 03 12:35:47 <fireboot> http://software.intel.com/sites/default/files/m/4/d/8/5/8/42868-11__Developing_Kernel_Module_on_Yocto.pdf I will try to follow that
Dec 03 12:37:53 <dany1> Is Michael Halstead here ?
Dec 03 12:46:25 <bluelightning> dany1: it's a bit early in the morning for him yet (US West Coast)
Dec 03 12:52:05 <likewise> fireboot: I can send you an example recipe for module compilation.
Dec 03 12:52:23 <likewise> but there should be one in yocto, let me look
Dec 03 12:52:56 <likewise> fireboot: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb
Dec 03 12:53:24 <likewise> fireboot: that works if your Makefile is OK.
Dec 03 12:53:30 <dany1> bluelightning: Ah, thx
Dec 03 12:55:17 <likewise> fireboot: let me know if that works for you; it not then your module Makefile is probably not kernel compliant. Seen a lot of hardcoded Makefiles assuming x86 etc.
Dec 03 12:59:12 <fireboot> thanks a lot likewise!
Dec 03 12:59:18 <fireboot> I will check it out
Dec 03 13:05:44 <fireboot> if there is any linux newbie around
Dec 03 13:05:48 <fireboot> here is a lesson for you
Dec 03 13:06:12 <fireboot> when you use rm, make sure you delete the right thing
Dec 03 13:06:22 <fireboot> otherwise you can end up writing that:
Dec 03 13:06:24 <fireboot> [root@Hendrix /]# rm -rf boot/ usr/
Dec 03 13:06:48 <fireboot> and 10sec too late you will realize what you just did and hate yourself.
Dec 03 13:06:57 <likewise> fireboot: well, never run as root.
Dec 03 13:07:27 <likewise> fireboot: ^^^^^^ best lesson
Dec 03 13:07:43 <fireboot> true
Dec 03 13:07:47 <fireboot> but I needed to be root
Dec 03 13:07:52 <fireboot> god dammit.
Dec 03 13:08:22 <likewise> fireboot: I never need to be root when developing with OE/YP.
Dec 03 13:08:57 <bluelightning> fireboot: at least that won't have deleted non-restorable files
Dec 03 13:09:17 <likewise> fireboot: but I know your frustration - happened to me once.
Dec 03 13:09:35 <fireboot> well bluelightning I just wiped out my kernel, my grub config and pretty much every binary on my system
Dec 03 13:09:57 <likewise> fireboot: make backups while you are still in the system
Dec 03 13:10:16 <fireboot> I think I'm better off reinstalling the whole distro rather than trying to tape it
Dec 03 13:10:20 <likewise>  bin/ is still there I presume
Dec 03 13:10:29 <fireboot> well my /home is in a separate partition
Dec 03 13:10:43 <fireboot> oh true I have my nfs server and tftpd on the root filesystem
Dec 03 13:11:17 <likewise> fireboot: me too, but I have made some dirs user writable on /export /srv /tftpboot /nfsroot or whatever you need. Then from there, run as user.
Dec 03 13:13:24 <fireboot> (if you are curious as why I typed this command, I was trying to delete /tmp/boot and /tmp/usr, which have been created when I extracted the kernel-dev package to see what it contains
Dec 03 13:13:48 <fireboot> I thought I was in /tmp... big mistake :P
Dec 03 13:13:56 <fireboot> oh well, yet another day of work lost!
Dec 03 13:16:03 <mckoan> yocto-8-danny MACHINE="beagleboard" bitbake meta-toolchain fails, is it normal?
Dec 03 13:16:23 <mckoan> gcc-cross-canadian_4.7.bb, do_compile) failed
Dec 03 13:22:55 <fireboot> likewise: any suggestion on how to backup the system before reinstalling?
Dec 03 13:23:00 <fireboot> (it is still running)
Dec 03 13:23:17 <fireboot> I was thinking about booting on a live usb and simply mounting the partition and save what I want to keep
Dec 03 13:23:28 <fireboot> but if you have a better idea I'm interested
Dec 03 13:30:28 <bluelightning> mckoan: that's not normal no
Dec 03 13:36:23 <likewise> fireboot: with home on a separate partition you should be good. Just make sure you do not erase the home partition during reinstall. :)
Dec 03 13:36:48 <fireboot> :D
Dec 03 13:37:38 <fireboot> it still sucks balls though, it was painful to get this VM to work correctly :(
Dec 03 13:37:50 <fireboot> oh well.
Dec 03 13:39:53 <fireboot> how much I wish ZFS was mainstream on Linux :(
Dec 03 13:41:03 <mckoan> as far as you know may be any problem bulding a kernel-2.6.30 within YP-8-danny?
Dec 03 13:41:24 <mckoan> I get sed: can't read /home/koan/yocto-8-danny/poky/build/tmp/work/at91sam9g20ek-poky-linux-gnueabi/linux-2.6.30-r0/image/usr/src/kernel/tools/perf/Makefile: No such file or directory
Dec 03 13:41:50 <mckoan> perf ?
Dec 03 13:56:43 <mckoan> bluelightning: http://pastebin.com/aWtUExSd  maybe because I am using a 64bit ubuntu host?
Dec 03 13:57:33 <bluelightning> mckoan: no that won't be the cause
Dec 03 14:05:08 <mckoan> bluelightning: maybe it's a BBFILE_PRIORITY problem, still testing
Dec 03 14:33:33 <mckoan> bitbake meta-toolchain all succeeded
Dec 03 14:33:59 <mckoan> $ sudo tmp/deploy/sdk/poky-eglibc-x86_64-arm-toolchain-1.3.sh
Dec 03 14:34:13 <mckoan> Setting it up...find: `/opt/poky/1.3/sysroots/x86_64-pokysdk-linux/lib': No such file or directory
Dec 03 14:34:20 <mckoan> SDK could not be set up. Relocate script failed. Abort!
Dec 03 14:41:04 <mckoan> https://www.yoctoproject.org/search/node/meta-toolchain : Your search yielded no results :-(
Dec 03 14:42:41 <mckoan> I thought it was straightforward
Dec 03 15:07:17 <peachj> Has the functionality of recrdeptask changed such that you can no longer make a task run for all packages in a dependency graph?
Dec 03 15:07:32 <peachj> I saw the changes to recrdeptask, and compensated for those
Dec 03 15:07:43 <peachj> But I'm still running on many fewer packages than before
Dec 03 15:13:27 <mckoan> is bitbake -c devshell working in Yocto ?
Dec 03 15:14:42 <rburton> mckoan: worked when i last needed it
Dec 03 15:15:40 <mckoan> rburton: what did you set to get it work? I tried OE_TERMINAL = "auto"
Dec 03 15:16:00 <kergoth> i use it every day without difficulty
Dec 03 15:16:07 <kergoth> if it's failing for you, you should pastebin the failure
Dec 03 15:32:25 <mckoan> kergoth: for example http://pastebin.com/J6SbrdrJ
Dec 03 15:33:44 <mckoan> kergoth: in oe-classic I used TERMCMD TERMCMDRUN
Dec 03 15:43:56 <otavio> rburton: When do you plan to update danny branch?
Dec 03 15:44:07 <rburton> otavio: i was just battling combo-layer
Dec 03 15:44:10 <kergoth> mckoan: OE_TERMINAL = auto will try to use hte 'best' terminal available. you're free to choose one specifically
Dec 03 15:44:19 <rburton> otavio: and i was going to do a test run when the security patches landed in master
Dec 03 15:44:20 <kergoth> e.g. OE_TERMINAL = "screen" or OE_TERMINAL = "xterm"
Dec 03 15:44:30 <rburton> otavio: fwiw, i was just looking at your udev patch.  udevd didn't move in danny.
Dec 03 15:44:48 <otavio> rburton: it does when we use systemd
Dec 03 15:44:59 <otavio> rburton: not oe-core but meta-oe ;-)
Dec 03 15:46:18 <otavio> rburton: OE-Core:f9e3745d8eeef0df7e6dba3ba17d0b00645c92fa should go too (I don't recall if I asked for it before)
Dec 03 15:46:27 <rburton> otavio: well danny policy is master-first, so you'll need to get the try-many-udevd patch into master first
Dec 03 15:46:52 <otavio> rburton: it is in master
Dec 03 15:47:07 <rburton> oh, i thought i grepped
Dec 03 15:47:10 <otavio> rburton: udev patch: OE-Core:96daf1b3105e17a67acb5027d0418b2ac28b6820
Dec 03 15:47:12 * rburton will look again
Dec 03 15:47:35 <otavio> rburton: and the other for quiet boot: OE-Core:d7a8154d575f918a0a20cb0e3a8f65d02ed32f30
Dec 03 15:47:38 <rburton> $ git show 96daf1b3105e17a67acb5027d0418b2ac28b6820
Dec 03 15:47:40 <rburton> fatal: bad object 96daf1b3105e17a67acb5027d0418b2ac28b6820
Dec 03 15:47:54 <otavio> rburton: maybe you need to update?
Dec 03 15:48:38 <rburton> yes, rp must have merged today. i swear i pulled this tree this morning.
Dec 03 15:48:40 <mckoan> kergoth: OE_TERMINAL = "screen" works smoothly thank you
Dec 03 15:49:36 <otavio> rburton: so those three are the ones I'd like to have backported
Dec 03 15:49:46 <otavio> rburton: as they'd allow us to avoid the oe-core forking
Dec 03 15:50:18 <otavio> rburton: maybe I find some other minor fixes but  I prefer to go in small steps
Dec 03 15:52:00 <RP> rburton: I added it earlier this afternoon
Dec 03 15:52:51 <rburton> otavio: me too :)
Dec 03 15:57:29 <kergoth> mckoan: np. that error you got is a bit of a concern, though, it implies some sort of needed env var for that terminal wasn't included in the env whitelist, so got dropped
Dec 03 16:03:19 <schramae> is the wiki page on multilib outdated? MULTILIB_IMAGE_INSTALL seems to have been dropped and the dev-manual says to use IMAGE_INSTALL?
Dec 03 16:04:07 <mckoan> where are defined LDFLAGS settings for the generated arm-poky-linux-gnueabi-gcc ? Which recipe?
Dec 03 16:14:21 <dany1> halstead: Did you add my key, getting Permission denied.
Dec 03 16:14:46 <bluelightning> schramae: please disregard the wiki page in favour of the manual
Dec 03 16:15:50 <mckoan> basically I need to remove -W1 -O1 from LDFLAGS before building my kernel
Dec 03 16:18:27 <schramae> bluelightning: ok, thx. and i managed to break "bitbake world" with adding multilibs (Fetcher failure for http://downloads.sourceforge.net/project/libcg/lib32-libcgroup/v0.37.1/lib32-libcgroup-0.37.1.tar.bz2). for unknown reasons it includes the MLPREFIX to the SRC_URI, thus failing the download. can this be achieved by misconfiguration or is this a bug? havent found anything in bugzilla that matches so far
Dec 03 16:19:52 <bluelightning> schramae: that's odd, the SRC_URI value uses ${BPN} not ${PN} so that should not happen
Dec 03 16:20:49 <bluelightning> schramae: oh... that was a semi-recent fix
Dec 03 16:22:42 <bluelightning> schramae: http://cgit.openembedded.org/openembedded-core/commit/?id=9a97367038a1e2431bf94211dabbc5aedbbee3bb
Dec 03 16:27:11 <schramae> bluelightning: thx. looks good. will this be merged to the poky/danny git branch? i'm wondering what would be best to work with instead of the release tarball
Dec 03 16:28:29 <bluelightning> rburton: ^
Dec 03 16:28:54 <rburton> schramae: cherry-picking now :)
Dec 03 16:30:16 <schramae> thanks. if i didn't mention it today: i love FOSS (development) :)
Dec 03 16:30:44 <rburton> schramae: anything else you think should be in danny, ping/email me
Dec 03 16:31:02 <schramae> i'll do, thanks :)
Dec 03 16:31:09 <rburton> now if i could make combo-layer work, i'd have a poky/danny-next branch...
Dec 03 16:31:13 * rburton looks at bluelightning
Dec 03 16:31:34 <rburton> bluelightning: just kidding, i'll see if i can fix it (or at least hack out the test)
Dec 03 16:41:39 <otavio> rodgort: pulseaudio (disables xen): OE-Core: a0123b0168dc805e200ec47a04ebc764f89ee83d
Dec 03 16:42:04 <otavio> grr
Dec 03 16:42:10 <otavio> rburton: ^
Dec 03 16:42:54 <rburton> -PR = "r12"
Dec 03 16:42:56 <rburton> +PR = "r14"
Dec 03 16:42:57 <rburton> grrr
Dec 03 16:44:22 <rburton> otavio: merged
Dec 03 16:44:24 <otavio> rburton: yes; PR server will help in future ;-)
Dec 03 16:44:52 <otavio> rburton: where you make those patches available?
Dec 03 16:45:58 <rburton> otavio: oe-core-contrib, ross/danny-next
Dec 03 16:46:19 <otavio> rburton: And what is your ETA for a pull request?
Dec 03 16:46:38 <rburton> lots of beer for anyone with a solution to "how do i verify that a particular hash is on a particular branch" that doesn't involve git branch --contains
Dec 03 16:46:52 <rburton> otavio: once that patchbox of CVEs are in master
Dec 03 16:46:55 <rburton> (and its been built)
Dec 03 16:47:41 <kergoth> if git merge-base <hash> <branch> == <hash> then hash is included in the branch.
Dec 03 16:47:43 <kergoth> afaik
Dec 03 16:48:00 <rburton> oo
Dec 03 16:48:07 <rburton> and that's a useful command i didn't know of
Dec 03 16:48:15 <rburton> lets test that
Dec 03 16:48:19 <otavio> kergoth: I think it only if you use merge ...
Dec 03 16:48:21 <kergoth> you could also leverage git rev-list, check for wc -l == 0 or similar
Dec 03 16:48:30 <kergoth> otavio: nope, merge-base is useful in general
Dec 03 16:48:38 <kergoth> you can merge-base this-branch that-branch and see the point they share in common
Dec 03 16:48:39 <otavio> kergoth: for master x danny it does not work as all patches are cherry-picked
Dec 03 16:48:50 <kergoth> no, it checks for that *hash*
Dec 03 16:48:57 <rburton> kergoth: YOU WIN
Dec 03 16:48:59 <kergoth> he asked if this hash is on the branch, not that patch
Dec 03 16:49:02 <otavio> kergoth: when it forked?
Dec 03 16:49:12 <kergoth> if you want the patch, then you'd have to use git-cherry, probably :)
Dec 03 16:49:25 <kergoth> (or manually fiddle with git patch-id)
Dec 03 16:49:25 <rburton> its a sanity test - is this commit on the branch the configuration file says it is
Dec 03 16:49:29 <kergoth> otavio: yeah
Dec 03 16:49:35 <kergoth> rburton: ah, great, then merge-base is ideal, i think
Dec 03 16:50:01 <otavio> rburton: now you owe kergoth a box of beer ;P
Dec 03 16:50:08 * kergoth chuckles
Dec 03 16:50:43 <rburton> well, lots of subjective
Dec 03 16:50:47 <rburton> s/of/is/
Dec 03 16:52:55 <rburton> $ git merge-base 4cd0200e96fb282980a945b80af641a6e022e0b4 1.16
Dec 03 16:52:56 <rburton> fatal: Not a valid object name 1.16
Dec 03 16:52:59 <rburton> bah
Dec 03 16:53:03 <kergoth> otavio: of course, if that-branch wasn't forked off of this-branch, but they both forked off of a common branch (e.g. master),t hen merge-base will find the point they share in common
Dec 03 16:53:08 <kergoth> hmm, might need the full ref path?
Dec 03 16:53:15 <kergoth> refs/tags/1.16 or whatever?
Dec 03 16:53:17 <rburton> oh, typo
Dec 03 16:53:22 <kergoth> ah
Dec 03 16:53:57 <rburton> don't have a checkout of 1.16
Dec 03 16:54:54 <kergoth> if the hash comes after the branch, the merge base will be the branch. if the hash is on a different branch, then the merge base would be the fork point, the common commit in the history of both branches
Dec 03 16:55:07 <kergoth> sometimes I love that you can just run git plumbing commands directly
Dec 03 16:55:21 <rburton> bloody worked
Dec 03 19:34:29 <sgw1> andyross: Saw your email, very strange, it's not applying here against master same HEAD as you.  Did you save your email or apply the patch?
Dec 03 19:35:02 <andyross> Pasted it out of the parent email via "git am".  Let me try again to be sure...
Dec 03 19:36:45 <andyross> ... and of course it doesn't apply.  Sigh... not sure what I did wrong, but I'll fix and resend
Dec 03 19:36:58 <sgw1> Thanks!
Dec 03 19:37:03 <sgw1> biab
Dec 03 19:43:25 <peachj> How do you deal with LICENSE when a package is using its own custom license?  Is there a standard string to put in for that?
Dec 03 19:44:38 <andyross> sgw1: Uh... no actually.  It really does apply, the bug I hit was with thunderbird.  Copying to the clipboard from the message display works fine, but from the C-u "view source" window it munges whitespace.  But the patch seems fine AFAICT.  I checked the maildir file on the server for verification, I promise.
Dec 03 20:54:14 <msm> anyone see this before?
Dec 03 20:54:14 <msm> https://gist.github.com/4197937
Dec 03 20:56:02 <rburton> msm: no, have a look at the source
Dec 03 20:56:04 <rburton> might be obvious
Dec 03 20:56:15 <rburton> some expansion gone wrong, probably
Dec 03 20:56:22 * rburton -> dinner for real this time
Dec 03 22:04:47 <evanp> anyone ever seen zypper claim "nothing provides requested glibc"?
Dec 03 22:05:25 <evanp> I must have screwed something up...but what?
Dec 03 22:12:43 <msm> rburton: i dont have access ;(
Dec 03 23:15:13 <evanp> /etc/zypp/systemCheck says requires:glibc; if I change it to requires:libc6, everything's fine -- according to -e, my glibc recipe sets RPROVIDES_glibc="glibc rtld(GNU_HASH)", I would have thought that would appease zypper....
Dec 03 23:15:50 <fray> we're working on phasing out zypper due to problems like that
Dec 03 23:18:03 <evanp> fray: this doesn't seem to have anything to do with zypper itself though, since "rpm --provides -qp libc6*.rpm" doesn't say it provides glibc either, just libc6
Dec 03 23:18:34 <fray> that is correct..
Dec 03 23:18:53 <fray> libc6 does not 'provde' eglibc at all.. it shouldn't need to
Dec 03 23:19:05 <fray> very possible zypper is configured wrong
Dec 03 23:21:15 <evanp> /etc/zypp/systemCheck is verbatim what's in the upstream repo...I guess you're arguing Poky should patch it so it says requires:libc6 instead of requires:glibc?
Dec 03 23:21:52 <fray> zypper is dead.. we're killing it.. doesn't work right for embedded systems
Dec 03 23:22:02 <fray> but if you want to use Zypper, you will need to fix it..
Dec 03 23:22:17 <fray> the issue is though, you don't know the name of the 'libc' recipe..
Dec 03 23:22:31 <fray> it could be libc6, eglibc, uclibc, etc... since the system renames it as necessary
Dec 03 23:22:53 <evanp> I'm not on danny yet...has it always been broken in this way?
Dec 03 23:23:26 <fray> it worked for basic query, update, erase operations in 1.0 and 1.1.. it didn't get much testing in 1.2 and 1.3 (AFAIK).. and in 1.4 it will be replaced by smart..
Dec 03 23:24:30 <evanp> seems like it would have to have been (I'm on 1.2), since I think debian_package_name_hook would take no matter what the recipe name was and turn it into libc6, yet systemCheck says glibc....
Dec 03 23:25:37 <fray> the rename hook is something different..
Dec 03 23:26:03 <fray> for instance, in a multilib config...  the main library is libc6 (if eglibc), on uclibc it's soemthing else.. if you turn off the debian rename, then it's eglibc or uclibc...
Dec 03 23:26:29 <fray> if you switch to a multiple, say 'lib32' the package is then "lib32-eglibc" or "eglibc.....lib32_x86.rpm"
Dec 03 23:26:41 <fray> I don't know why it doesn't get renamed, but it doesn't..
Dec 03 23:27:44 <evanp> oh, so you're saying that debian rename only maps e?glibc to libc6 for non-multilib builds?
Dec 03 23:27:52 <fray> for some reason, yes
Dec 03 23:28:10 <evanp> huh. okay.
Dec 03 23:28:15 <fray> I've never figured it out either.. but I know I do a lot of builds w/ the debian rename disabled..
Dec 03 23:28:25 <fray> eliminates certain things which make it harder to debug problems..
Dec 03 23:33:30 <evanp> fray: are you familiar with the state of the smart recipes? think it'd be feasible to backport onto 1.3 and use in production?
Dec 03 23:34:04 <fray> bluelightning and I are finishing up the work for 1.4 right now.. HOPEFULLY it will be sent to the list this week..
Dec 03 23:34:21 <fray> I need to back port it for my employers products to 1.2.. so it should be fine to go back to 1.3
Dec 03 23:34:48 <fray> The only thing smart is lacking (AFAIK) that people have wanted is delta-rpm support..  Zypper and YUM both have it, but Smart doesnot
Dec 03 23:35:07 <fray> something I hope we (community) can add over the next 6-months or so....
Dec 03 23:38:33 <fray> woohoo.. I may have just fixed the final bug..
Dec 03 23:41:35 <bluelightning> fray: the architecture matching?
Dec 03 23:42:44 <fray> yup
Dec 03 23:42:54 <fray> working on putting it into a commit
Dec 03 23:44:56 <hollisb> "the last bug" huh? sounds likely ;)
Dec 03 23:48:21 <fray> ...the last bug preventing us from submitting the changes...
Dec 03 23:48:30 <fray> bluelightning poky-contrib  mhatle/smart
Dec 03 23:48:42 <fray> evanp -- thats the currenting work-in-progress stuff
**** ENDING LOGGING AT Tue Dec 04 02:59:59 2012

**** BEGIN LOGGING AT Tue Dec 04 02:59:59 2012
Dec 04 08:07:07 <mckoan> good morning
Dec 04 08:20:34 <mranostay> mckoan: gah it is
Dec 04 08:26:33 <mckoan> mranostay: snowy sky would not do it but I assume a positive thinking :-)
Dec 04 08:27:06 <mranostay> snow? in CA? :)
Dec 04 08:27:38 <mckoan> northern Italy :-D
Dec 04 08:29:07 <mranostay> i don't miss snow at all :)
Dec 04 08:29:29 <mranostay> <-- grew up in a place that got ~1 meters a winter
Dec 04 08:30:33 <RP> morning all
Dec 04 08:30:52 * mranostay hides
Dec 04 08:31:41 * mranostay peeks out and waves to RP
Dec 04 08:31:45 * mranostay hides again
Dec 04 08:32:38 <RP> lots of frost/ice here, not snow atm
Dec 04 08:33:14 <RP> taking back roads driving home last night in a rear wheel drive car was interesting
Dec 04 08:35:47 <mranostay> RP: uk iirc?
Dec 04 08:37:35 <RP> mranostay: yes, in the north, nearly Scotland :)
Dec 04 08:38:33 <mranostay> ah so close to Edidburgh?
Dec 04 08:38:42 <mranostay> *Edinburgh
Dec 04 08:40:17 <RP> mranostay: 100 miles south of there but close to the border
Dec 04 08:42:03 <mranostay> RP: but in Great Britain still right?
Dec 04 08:42:12 <RP> mranostay: yes
Dec 04 08:58:15 <likewise> gm
Dec 04 09:08:15 <mranostay> morning at leat
Dec 04 09:08:18 <mranostay> *least
Dec 04 09:48:41 <bluelightning> morning all
Dec 04 14:29:03 <JimNH3> Is there a way to tell bitbake that I've donwloaded the versions of the packages I want;   I never want you to go to the network to check for new versions of packages or kernels ??
Dec 04 14:34:32 <bluelightning> JimNH3: you can set BB_NO_NETWORK = "1"
Dec 04 14:35:01 <bluelightning> but if the system believes it does not have the current source for something it will then error out instead of trying to fetch it
Dec 04 14:35:54 <rburton> JimNH3: don't use autorev, and if the source cache is fine it won't hit the network
Dec 04 14:36:21 <JimNH3> blue: ah doh I thought I saw it somewhere but couldnt put my finger on it...    autorev.. hmm havent noticed that one
Dec 04 14:36:37 <rburton> JimNH3: also using git tag/branch names instead of commit sha's is one way that you'll get network access without intending it
Dec 04 14:36:48 <rburton> it has to look up the name to determine what it points at
Dec 04 14:38:30 <bluelightning> JimNH3: other useful info: http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#idp3748256
Dec 04 14:40:42 <JimNH3> ok thanks for the pointers...  thats what I think I wanted
Dec 04 15:29:37 <dany1> Where is PACKAGECONFIG documented ?
Dec 04 15:29:46 <dany1> the syntax that is ..
Dec 04 15:31:59 <rburton> dany1: in the documentation ;)
Dec 04 15:32:03 * rburton finds a link
Dec 04 15:32:07 <rburton> it may only be in git at present
Dec 04 15:32:58 <rburton> dany1: http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#var-P
Dec 04 15:36:32 <dany1> rburton: Ah, "latest", I was looking at 1.3. Thanks ..
Dec 04 15:36:54 <rburton> dany1: it got expanded a lot in the last week
Dec 04 15:37:15 <rburton> in fact, git may have a better explanation that that - no idea how often that is re-generated
Dec 04 15:38:51 <dany1> rburton: Found it in base.bbclass.
Dec 04 15:39:09 <rburton> oh i meant the proper documentaton - yocto-docs repo
Dec 04 15:39:26 <rburton> it took me about half an hour to figure what it does from the source :/
Dec 04 15:42:43 <dany1> hehe
Dec 04 15:43:38 <dany1> yes, keeping the code in the same order as the arguments would help.
Dec 04 15:44:40 <eren> The PACKAGECONFIG variable itself specifies a space-separated list of the features to enable.
Dec 04 15:44:49 <eren> how do you enable "the features" ?
Dec 04 15:45:20 <eren> "You can provide up to four arguments, which are separated by commas, to determine the behavior of each feature when it is enabled or disabled. "
Dec 04 15:45:28 <rburton> eren: you just said
Dec 04 15:45:37 <rburton> the variable is the list of functions to enable
Dec 04 15:46:06 <eren> ok, I mean how do you enable it when firing bitbake to build the package?
Dec 04 15:46:23 <eren> in distro.conf, local.conf?
Dec 04 15:46:30 <rburton> the recipe normally has a default, PACKAGECONFIG ??= "foo bar"
Dec 04 15:46:39 <rburton> or you can override it anywhere you'd override a variable
Dec 04 15:47:10 <eren> hm
Dec 04 15:47:17 <eren> I guess it's through bbappend file then
Dec 04 15:47:33 <eren> if I don't want croco in librsvg, I just need to specify PACKAGECONFIG = ""
Dec 04 15:47:38 <rburton> yes
Dec 04 15:47:44 <eren> then librsvg will not be built with croco
Dec 04 15:47:52 <eren> oh elegant, thank you
Dec 04 15:47:58 <rburton> well, PACKAGECONFIG_pn-librsvg or something, if in distro or local
Dec 04 15:48:12 <rburton> or just packageconfig in bbappend
Dec 04 15:48:48 <eren> nice
Dec 04 15:55:26 <fp> YPTM: Amit in, probably on a bad connection.
Dec 04 15:55:39 * fp redialing...
Dec 04 15:56:38 <rburton> YPTM: not attending today, i'll be out-of-office shortly
Dec 04 15:56:38 <eren> 4 minutes to go
Dec 04 15:56:52 <pidge> YPTM: In and hearing strange music.
Dec 04 15:57:07 <rburton> pidge: do TI have "interesting" hold music?
Dec 04 15:57:37 <eren> YPTM: Eren is connected, hearing strange music as well
Dec 04 15:57:48 <kergoth> strange indeed
Dec 04 15:57:53 <pidge> rburton: Yeah, it's got a nice beat. Not thrilled with the piano, but...
Dec 04 15:58:07 <kergoth> YPTM: Chris Larson here too
Dec 04 15:58:18 <kergoth> pidge: i think its a little early for such high pitches
Dec 04 15:58:23 <kergoth> but i'm ready to go back to bed..
Dec 04 15:58:40 <pidge> kergoth: Yeah, an octive lower would have been better
Dec 04 15:58:49 <eren> oh, strange echo
Dec 04 15:58:57 <eren> I cannot understand anything
Dec 04 15:59:09 <pidge> wow
Dec 04 15:59:17 <pidge> yeah, that echo is annoying
Dec 04 15:59:17 <eren> wow, it echoed 6 times
Dec 04 15:59:20 <kergoth> hah
Dec 04 15:59:24 <rburton> this is the remiiixxx
Dec 04 15:59:32 <eren> hahah
Dec 04 16:00:17 <rburton> yocto, as remixed by lee scratch perry
Dec 04 16:00:33 <eren> my mic is muted, btw
Dec 04 16:00:42 <bluelightning> someone isn't...
Dec 04 16:00:45 <scottrif> YPTM: Scott Rifenbark joined
Dec 04 16:00:47 <zenlinux> trippy
Dec 04 16:00:47 <pidge> muted.
Dec 04 16:00:52 <jmpdelos> YPTM: Polk joined
Dec 04 16:00:54 <scottrif> nice echo effect
Dec 04 16:00:55 <nitink> YPTM: nitin is on the bridge
Dec 04 16:01:00 <bluelightning> YPTM: Paul Eggleton is on the bridge
Dec 04 16:01:03 <strassek> YPTM: Kevin Strasser is here
Dec 04 16:01:10 <zenlinux> YPTM: Scott Garman is here
Dec 04 16:01:10 <Guest25593> YPTM: Tom Z here
Dec 04 16:01:20 <pidge> Song, this isn't your problem
Dec 04 16:01:25 <eren> it's definitely not related with Song
Dec 04 16:01:30 <pidge> think the bridge is toast
Dec 04 16:01:39 <zeddii> YPTM: Bruce Ashfield here
Dec 04 16:01:47 <eren> oh yeah
Dec 04 16:01:51 * zeddii hears voices (and you can quote me on that).
Dec 04 16:02:07 <bluelightning> zeddii: are they only in your head though is the question ;)
Dec 04 16:02:12 <Song_Liu> YPTM: Welcome to the Yocto Project Technical team Meeting, please let me know who's on the bridge
Dec 04 16:02:19 <eren> YPTM: Eren is here
Dec 04 16:02:28 * zeddii won't confirm or deny :P
Dec 04 16:02:31 <pidge> YPTM: Beth is here.
Dec 04 16:02:31 <cristianiorga> YPTM: Cristian Iorga present online and audio
Dec 04 16:02:36 <jzhang-laptop> YPTM: jzhang's on
Dec 04 16:03:15 <darknighte> YPTM: Sean Hudson dialed in...
Dec 04 16:03:51 <RP> YPTM: RP is here
Dec 04 16:04:00 <sgw1> YPTM Saul is here
Dec 04 16:04:04 * darknighte waves at Song_Liu 
Dec 04 16:04:29 * darknighte smiles
Dec 04 16:04:50 <darknighte> Song_Liu: YPTM: no opens from me
Dec 04 16:04:50 <Song_Liu> YPTM: Any opens?
Dec 04 16:04:54 <eren> yeah
Dec 04 16:05:23 <scottrif> OPEN:  adding doc alert to comments in Bugzilla when filing a bug that effects documentation
Dec 04 16:05:41 <fray> YPTM: I'm now on the call..
Dec 04 16:05:52 <fray> I may have to leave a bit early...
Dec 04 16:06:26 <eren> http://hambedded.org/blog/2012/11/24/from-bitbake-hello-world-to-an-image/
Dec 04 16:06:39 <corneliux> YPTM: I am also on the call (Romania QA)
Dec 04 16:07:43 <halstead> YPTM: Michael Halstead on the call.
Dec 04 16:07:50 <corneliux> YPTM: Corneliu
Dec 04 16:07:53 <corneliux> :)
Dec 04 16:08:58 <Song_Liu> YPTM: https://wiki.yoctoproject.org/wiki/Yocto_1.4_Overall_Test_Plan
Dec 04 16:10:22 <darknighte> Song_Liu: where are you again?  I looked away.
Dec 04 16:11:05 <walters> erbo, looks pretty nice
Dec 04 16:14:05 <fray> there is a build appliance failure I saw w/ pseudo on my own machine..
Dec 04 16:14:15 <fray> Is that what people are seeing?  (that was with oe-core)
Dec 04 16:14:29 <sgw1> fray no, that's a Autobuilder issue, what are you seeing?
Dec 04 16:14:51 <fray> pseudo won't build for the target.. which leads me to wonder "why are we building pseudo for the target"?
Dec 04 16:14:59 <Zagor_> YPTM: Björn Stenberg (enea) joined the call
Dec 04 16:15:05 <fray> I have a local fix.. (which I should be sending out sooner rather then later..)
Dec 04 16:17:18 <Ramana_> Ramana joined YPTM
Dec 04 16:19:26 <Ramana_> https://lists.yoctoproject.org/pipermail/yocto/2012-November/012867.html
Dec 04 16:19:51 <Ramana_> https://lists.yoctoproject.org/pipermail/yocto/2012-November/012973.html
Dec 04 16:20:09 <mckoan> eren: your post looks amazing!
Dec 04 16:20:32 <Ramana_> Looking forward for comments...thanks
Dec 04 16:25:53 <scottrif> eren: here is my email... srifenbark@gmail.com  or scott.m.rifenbark@intel.com
Dec 04 16:26:20 <eren> scottrif: thanks, got them
Dec 04 16:26:54 <sgw1> Zagor_: Do you have an update to your ptest based on comments?
Dec 04 16:27:47 <eren> mckoan: thank you! :)
Dec 04 16:28:00 <Zagor_> sgw1: I posted a revision to the glib patch addressing the installation comment. and I posted questions about the other comments.
Dec 04 16:28:15 <JaMa> sgw1: do you want me to send v2 for at with that VIRTUAL_RUNTIME in RDEPENDS?
Dec 04 16:28:56 <sgw1> JaMa: that would be great, you could update the branch and post when you have done that.
Dec 04 16:29:05 <evadeflow> David Wolfe of Magneti Marelli here.
Dec 04 16:29:34 <evadeflow> Can someone repaste the 'hello world' and blog URLs mentioned earlier?
Dec 04 16:29:47 <evadeflow> (Or... did I mis-hear that?)
Dec 04 16:29:47 <eren> evadeflow: http://hambedded.org/blog/2012/11/24/from-bitbake-hello-world-to-an-image/
Dec 04 16:29:51 <fray> I can mention the Smart stuff
Dec 04 16:31:08 <Zagor_> sgw1: if there's anything more I can do to help push ptest forwards, please let me know.
Dec 04 16:32:00 <sgw1> Zagor_: if you are on the call and needs some response, might be useful to ask.
Dec 04 16:32:11 <mckoan> eren: 73
Dec 04 16:32:22 <eren> mckoan: 73!
Dec 04 16:32:28 <fp> eren, your post looks great!
Dec 04 16:32:33 <eren> mckoan: qrz?
Dec 04 16:32:35 <Zagor_> sgw1: will do
Dec 04 16:32:46 <eren> fp: thanks! I appreciate it
Dec 04 16:34:16 * zeddii is afk for a second
Dec 04 16:34:32 <mckoan> eren: actually is my father :-)
Dec 04 16:35:04 <eren> mckoan: hehe :)
Dec 04 16:38:05 <eren> pidge: I'm waiting for server from my university to start building images and work on meta-hambedded layer. I only have 1.2GHz, amd cpu with 2GB of ram on my laptop, which is not a productive environment to hack oe
Dec 04 16:40:33 <mckoan> have a nice rest of the day
Dec 04 16:42:34 <fray> I ran out of time.. :(
Dec 04 16:42:37 <fray> I did read the email though
Dec 04 16:46:10 <RP> halstead: is the graph stuff going ok? need anything from me?
Dec 04 16:46:25 * zeddii fires up the delorean 
Dec 04 16:47:18 <Ramana_> https://lists.yoctoproject.org/pipermail/yocto/2012-November/012867.html  https://lists.yoctoproject.org/pipermail/yocto/2012-November/012973.html These are the links of my postings on offline configuration tool
Dec 04 16:48:02 <evadeflow> Yeah, eren your post is fantastic. Thanks for doing it.
Dec 04 16:48:02 <zeddii> ouch. don't be the last to hang up.
Dec 04 16:48:17 <pidge> eren: yeah, it's doable (I've done it on a core 2 with 2gb) but it takes a looong time.
Dec 04 16:48:34 <eren> pidge: yeah
Dec 04 16:48:44 <sgw1> zeddii: it's worse when wearing bluetooth or ear budz!
Dec 04 16:48:45 <evadeflow> eren: I'll go through it carefully when I have time and send any feedback I might have.
Dec 04 16:48:55 <eren> evadeflow: thank you, I appreciate it
Dec 04 16:50:21 <Song_Liu> YPTM: Thank you all for joining the call. Have a nice day/evening
Dec 04 16:52:12 <eren> pidge: I compiled core-image-minimal in 5-6 hours, it's now cached but the version is denzil :(
Dec 04 16:52:20 <eren> I need to re-compile it with new version
Dec 04 16:52:32 <eren> afterwards, I guess I can start playing with meta-hamradio
Dec 04 16:52:36 <zeddii> sgw1, indeed .. OUCH.
Dec 04 16:52:52 <eren> for image debugging, and BSP, I will definitely need a powerful machine
Dec 04 16:54:28 <sgw1> RP: SSTATE_MIRROR question for you, I am trying to figure out why it's not being used, and I see it having the premirror set but it attempts to fetch the file without the mirror setting (ie  SState using premirror of: file:///intel/sstate-cache, but shows: Unsuccessful fetch test for file://Fedora-18/49/...) Debug messages
Dec 04 16:56:01 <RP> sgw1: That messages is just showing the url unmanipulated , doesn't mean much
Dec 04 16:56:13 <RP> i.e. before application of mirrors
Dec 04 17:01:18 <sgw1> RP: Oh, ok, hmm, it seems to be failing to find the sstate file, but I know they exist and I used sigdiff and they are equal, any hints on tracking it down ?
Dec 04 17:05:41 <RP> sgw1: try -DDD and looking at the cooker logs, see what exactly happened
Dec 04 17:05:57 <sgw1> RP: thanks will do.
Dec 04 17:23:15 <halstead> RP, Okay. I'm running your code and I've added another hidden axis to make the legend show. (https://wiki.yoctoproject.org/wiki/images/graphresource/figure1.svg)
Dec 04 17:23:41 <halstead> RP, I think I need to make all of the IN PROGRESS statuses count toward open bugs as well.
Dec 04 17:24:18 <RP> halstead: yes, they count as open states
Dec 04 17:25:33 * halstead nods.
Dec 04 17:27:16 <sgw1> RP: the -DDD showed that it's not looking into the SSTATE-MIRROR it lists a largish search path and then defaults to the local sstate-cache
Dec 04 17:27:53 <RP> sgw1: care to post the log+config somewhere?
Dec 04 17:28:20 <sgw1> RP: sure hang on, pastebin coming up
Dec 04 17:30:55 <sgw1> RP: http://pastebin.com/LwfuaWvh
Dec 04 17:31:15 <sgw1> RP: I clipped just the sstate bits
Dec 04 17:33:20 <RP> sgw1: hmm, the premirror info from the fetcher isn't well reflected there :(
Dec 04 17:35:06 <RP> sgw1: what SSTATE_MIRRORS are you using exactly?
Dec 04 17:36:08 <RP> sgw1: Try SSTATE_MIRRORS = "file://.* file:///intel/sstate-cache/PATH"
Dec 04 17:38:41 <sgw1> RP: doing a lot more work!
Dec 04 17:41:13 <sgw1> That did the trick, my bad for not having the right syntax!
Dec 04 17:57:20 <RP> sgw1: wonder why it didn't error, might be worth a bug
Dec 04 17:57:28 * RP is seeing a lot of this kind of question
Dec 04 18:01:37 <bluelightning> did that change make it into the default template for 1.3?
Dec 04 18:02:30 <bluelightning> no it did not :/
Dec 04 18:04:51 <bluelightning> apparently it's queued in the danny branch however
Dec 04 18:22:19 <kergoth> i rather like the way we're doing it to do the host fallback -- no direct manipulation of SSTATE_MIRRORS, instead just space separated list of sites. less likelihood of screwing it up
Dec 04 18:22:23 <kergoth> heh
Dec 04 18:29:22 <sgw1> kergoth: you mean like I did!
Dec 04 18:40:54 <scottrif> halstead: ping
Dec 04 19:09:04 <mranostay> so what package does traceroute come in? it sure isn't iputils surprisingly
Dec 04 19:09:21 <Crofton> grep
Dec 04 19:09:33 <Crofton> maybe tracepath also
Dec 04 19:10:45 <mranostay> ah
Dec 04 19:11:23 <mranostay> any difference?
Dec 04 19:23:55 <kergoth> RP: https://github.com/kergoth/bitbake/commit/5cd408ad0b6d8f409970ce0149cd0d1aca1420f6 thoughts on this? dropped of my radar, didn't notice it never got merged
Dec 04 19:29:33 <zeddii> msm, around ?
Dec 04 19:29:37 <halstead> scottrif, back from the dentist now.
Dec 04 19:30:31 <scottrif> halstead: hi - hope that went well.  Wondering if you could set it up so that Bill Traynor can have an XMPP account access for the "yocto" room the team uses?
Dec 04 19:31:31 <msm> zeddii: hello
Dec 04 19:33:26 <halstead> scottrif, I'll send you an e-mail about how to request that.
Dec 04 19:38:11 <scottrif> halstead: ok
Dec 04 19:38:18 <scottrif> halstead: thank  you!
Dec 04 20:03:12 <walters> any python 3 recipes floating around?
Dec 04 20:03:28 <walters> there's a push to port stuff in gnome this cycle
Dec 04 20:04:08 <walters> the pile of patches in danny at least for python2 is kind of large
Dec 04 20:39:35 <RP> kergoth: hmm, that is a valid problem yes. It dropped off mine as well...
Dec 04 21:38:56 <evanp> Is it just me, or does the new yoctoproject.org design not link to git.yoctoproject.org _anywhere_...?
Dec 04 22:29:08 <wmat> evanp: it's definitely not front and center, but it is in the Release Notes page https://www.yoctoproject.org/download/yocto-project-13-poky-80
**** ENDING LOGGING AT Wed Dec 05 02:59:59 2012

**** BEGIN LOGGING AT Wed Dec 05 02:59:59 2012
Dec 05 08:31:02 <mckoan> good morning
Dec 05 08:32:16 <ant_work> hi mckoan
Dec 05 09:25:01 <bluelightning> morning all
Dec 05 09:48:46 <mckoan> bluelightning: makes it sense to use Yocto to create a system based on kernel-2.6.30 or is better to use an approach oe-core?
Dec 05 09:49:27 <bluelightning> mckoan: surely it makes little difference? the metadata is the same...
Dec 05 09:49:32 <mckoan> I understand that Yocto tends to encourage the use of its own kernel
Dec 05 09:50:33 <bluelightning> we recommend it yes, but you don't have to use all of it... i.e. you can use linux-yocto-custom which just provides the config fragment handling but doesn't require that you use the meta branch
Dec 05 09:51:21 <mckoan> and I can not find examples to start with an older kernel (2.6.x)
Dec 05 09:54:14 <bluelightning> mckoan: FWIW, we have 2.6.x kernels in meta-handheld but they use linux.inc
Dec 05 09:56:36 <mckoan> bluelightning: I have written a BSP but build fails, I'll give a try to a new one inheriting from linux-yocto-custom.bb
Dec 05 10:20:18 <_julian_> how can I force a complete rebuild of all packages in a yocto image?
Dec 05 10:28:45 <bluelightning> _julian_: the question is why do you need to do that?
Dec 05 10:29:28 <rburton> _julian_: delete your tmp?
Dec 05 10:35:23 <Zagor> bluelightning: he probably wants to test his new cpu fan ;-)
Dec 05 10:56:13 <mckoan> bluelightning: however linux-yocto-custom follows the ì'old school' style
Dec 05 10:56:23 <bluelightning> mckoan: what do you mean?
Dec 05 10:57:24 <mckoan> bluelightning: that there is nothing new :-)
Dec 05 10:57:57 <mckoan> bluelightning: compared to oe-classic kernel recipes
Dec 05 10:59:48 <bluelightning> mckoan: that's not true, you get config fragment support
Dec 05 11:00:18 <mckoan> bluelightning: yep
Dec 05 11:02:25 <ant_work> mckoan: I doubt the actual kernel-tools are working well with pre 3.x kernels. They are now targeting 3.4
Dec 05 11:02:50 <ant_work> neverthless you can just stick your defconfig and you're done
Dec 05 11:03:01 <mckoan> ant_work: that's exactly the pain I am experiencing in the last week
Dec 05 14:42:39 <mckoan> why there isn't meta/recipes-kernel/linux/linux-tools.inc in yocto-8-danny ?
Dec 05 14:50:09 <zeddii> mckoan: everything that was in it was moved to a standalone perf recipe,so it was removed.
Dec 05 15:01:01 <mckoan> zeddii: thx, but now I don't understand how to avoid a kernel to complain because it's missing
Dec 05 15:04:20 <zeddii> mckoan, which kernel is complaining ? the only solution is to remove the include, which is what we did for the ones that were known at the time. if I missed one that's in tree, let me know.
Dec 05 15:05:11 <mckoan> zeddii: thx, your one is ok, I'm trying to add a custom 2.6.30
Dec 05 15:15:41 <mckoan> zeddii: sorry but I don't understand which include and where
Dec 05 15:19:46 <zeddii> let me step back. you have a custom kernel, 2.6.30, and you are working on the danny branch ? somewhere you should have a require or include of that file that can simply be removed from the recipes to avoid the issue. the functionality it offered is now elsewhere.
Dec 05 15:24:58 <ant_work> zeddii: hi there
Dec 05 15:27:15 <mckoan> zeddii: i had yocto-7-denzil/poky/meta/recipes-kernel/linux/linux-tools.inc but if I remove it I have a build error
Dec 05 15:27:57 <mckoan> make: *** /home/koan/yocto-8-danny/poky/build/tmp/work/at91sam9g20ek-poky-linux-gnueabi/linux-2.6.30-r0/linux-2.6.30/tools/perf: No such file or directory.
Dec 05 15:32:05 <zeddii> mckoan. If I could see your recipes, I might be faster .. but are you sure your recipes don't have that .inc in their includes ? and if they have it in their includes are implicitly relying on what it used to provide ?
Dec 05 15:32:22 <zeddii> ant_work, hi! I'm attempting to task switch a bit fast this morning. packets are dropping.
Dec 05 15:32:47 <ant_work> zeddii: he he ... just a quick thing: yocto-tiny is not tiny enough so I have to unset some options.
Dec 05 15:33:13 <ant_work> now, it would be wonderful to do that manipulating KERNEL_FEATURES
Dec 05 15:33:13 <zeddii> ant_work, ok. yes, remember dropping that packet on Friday last week ?
Dec 05 15:33:32 <ant_work> there is more
Dec 05 15:33:39 <ant_work> http://paste.debian.net/214437
Dec 05 15:33:45 * zeddii checks
Dec 05 15:33:59 <ant_work> imho tiny/yocto.cfg adds weird options
Dec 05 15:34:21 * zeddii pulls it up.
Dec 05 15:34:44 <ant_work> and I'd expect less features as default
Dec 05 15:35:37 <ant_work> atm I'm including my undefine.cfg
Dec 05 15:37:03 <zeddii> right. we should start an email conversation with dvhart, in 1.4 we are going to drive some of tiny's config down to a base (i.e. really small) and you could inherit that rather than tiny. but if we are sensing some bloat and would rather turn them on via features, it's a discussion worth having.
Dec 05 15:37:17 <ant_work> afais kgdb,*trace,*probe,unionfs, cgroups should be  opt-out
Dec 05 15:37:58 <zeddii> aha!
Dec 05 15:38:04 <ant_work> through KERNEL_FEATURES
Dec 05 15:38:05 <zeddii> I have a bug for that. you are correct.
Dec 05 15:38:42 <zeddii> there's two things at play. opt out is doable,  but also, this file ktypes/standard/standard-nocfg.scc, has drifted from design.
Dec 05 15:39:32 <zeddii> the "nocfg" says. make the code changes available (i.e opt-in), but don't turn them on, and that's the part that has drifted. I'm working to fix it up and combine it with some new features.
Dec 05 15:40:05 <ant_work> I see, great
Dec 05 15:40:09 <ant_work> note that I'm targeting a linux-as-bootloader kernel so bare metal + filesystems (no net, usb, sound atm)
Dec 05 15:40:35 <ant_work> talking also with bluelightning it seems to us that an additive approach would be preferable
Dec 05 15:41:02 <zeddii> ah nice.
Dec 05 15:41:02 <ant_work> don't worry, we can live with that undefine.cfg for the moment
Dec 05 15:41:45 <zeddii> a small base config that you can re-use would be ideal for this. I'll make sure to solicit input when we get to it (i.e. soon or right after the holidays).
Dec 05 15:42:02 <ant_work> besides, we have the need for a 'classic' kernel thus we have linux-yocto-standard which is full additive atm
Dec 05 15:42:09 <ant_work> just a bit too big...
Dec 05 15:45:33 <ant_work> btw, we have finally committed 3.4 in OE  http://cgit.openembedded.org/meta-handheld/tree/recipes-kernel/linux
Dec 05 15:46:06 <ant_work> is on diet atm :)
Dec 05 15:46:48 <mckoan> zeddii: these are my experimental recipes ftp://support.koansoftware.com/public/meta-kaeilos-atmel/recipes-kernel/linux/linux_2.6.30.bb
Dec 05 15:48:23 <mckoan> zeddii: and this is my build log http://pastebin.com/1nR2qzis
Dec 05 15:48:41 <mckoan> zeddii, ant_work: any hint would be appreciated
Dec 05 15:54:50 <ant_work> bluelightning: no idea about PERF_FEATURES_ENABLE, maybe it is considered even if empty?
Dec 05 15:54:55 <ant_work> mckoan: ^^
Dec 05 15:55:59 <dv_> hello
Dec 05 15:56:25 <dv_> I stumbled upon an issue with the transition to yocto. although the rootfs is working fine, some binaries are _much_ slower than on angstrom.
Dec 05 15:56:47 <kergoth> current angstrom is yocto based, so you'd need to be more specific
Dec 05 15:56:52 <kergoth> (afaik, anyway)
Dec 05 15:57:19 <dv_> one of them being the gstreamer resampler plugin. looking at the ELF info of the two binaries, one difference I noticed was Tag_DIV_use = Not Allowed on yocto
Dec 05 15:57:40 <rburton> dv_: oe-core disables ORC
Dec 05 15:57:53 <dv_> that too I noticed. any reason why?
Dec 05 15:57:56 <rburton> no idea
Dec 05 15:58:05 <rburton> i've been meaning to kill that
Dec 05 15:58:05 <dv_> but how is ORC linked to this tag?
Dec 05 15:58:24 <rburton> dunno, but that will have an impact on math-heavy gst work
Dec 05 15:58:34 <rburton> potentially, you've hit license issues
Dec 05 15:59:01 <dv_> i actually raised a similar issue in the OE mailing list once
Dec 05 15:59:01 <fray> I know between gstreamer and general oe "basic" configurations.. there are issues that end users have to resolve..
Dec 05 15:59:20 <fray> dv_ it's possible that was missed with the oe-core transition
Dec 05 15:59:40 <dv_> possibly
Dec 05 15:59:49 <fray> the tuning files should select the basic compatible tunings.. and the recipes need to use that information to determine the best way to build within the limitations of a given tune..
Dec 05 16:00:09 * zeddii is back. he was out trying some thin ice for a minute
Dec 05 16:00:11 <fray> for some of the advanced math, the default tunes have things disabled by default because of either performance or known chipset bugs..
Dec 05 16:00:18 <zeddii> ant_work, cool. I'll look at your updates.
Dec 05 16:00:30 <zeddii> mckoan, I'll have a look at your recipes too.
Dec 05 16:00:30 <fray> (there are some math ops which are very slow when used individually, but very fast when hand-optimized)
Dec 05 16:01:00 <dv_> however, I also read the ELF info of libz.so, and it too says "Tag_DIV_use = Not Allowed"
Dec 05 16:01:32 <mckoan> zeddii: thx, sorry for bothering you
Dec 05 16:01:42 <dv_> thats why I think this tag thing and the disabled ORC are actually two different issues
Dec 05 16:02:00 <rburton> hm yeah
Dec 05 16:02:07 * rburton had to google tag_div_use
Dec 05 16:02:09 <fray> that may very well be a chipset/tune limitation..
Dec 05 16:02:27 <dv_> it actually isnt - we have been using div-enabled software on the exact same chipset
Dec 05 16:02:32 <dv_> (using a Cortex-A8)
Dec 05 16:02:46 <dv_> more specifically, an am3359 , the same SoC the beaglebone uses
Dec 05 16:02:59 <fray> which tune are you using?  it sounds a lot like the VFP isn't enabled properly
Dec 05 16:03:42 <dv_> checking
Dec 05 16:03:53 <fray> the package arch is likely enough (or bitbake -e)
Dec 05 16:04:08 <fray> also your cooker logs should give the tune features
Dec 05 16:04:47 <dv_> require conf/machine/include/tune-cortexa8.inc
Dec 05 16:04:56 <ant_work> zeddii: I'll have to gain more kern-tools adepts ;)
Dec 05 16:05:00 <dv_> ah
Dec 05 16:05:03 <fray> what does your cooker log say?
Dec 05 16:05:30 <fray> TUNE_FEATURES     = "armv5 thumb dsp"
Dec 05 16:05:31 <fray> TARGET_FPU        = "soft"
Dec 05 16:05:44 <fray> (thats from a qemuarm build I had laying around)
Dec 05 16:06:07 <dv_> TUNE_FEATURES     = "armv7a vfp neon cortexa8"
Dec 05 16:06:07 <dv_> TARGET_FPU        = "vfp-neon"
Dec 05 16:06:26 <fray> ya, based on that vfp is enabled adn such.. so you should be good..
Dec 05 16:06:39 <fray> no idea then why it's disabled..  I suspect either an optimization flag for the compiler -- or the compiler itself
Dec 05 16:08:34 <fray> from a couple of quick google searches.. it looks like, until recently, binutils didn't even support the div item without vendor hacks..
Dec 05 16:08:47 <fray> very possible the version of binutils you are using is old enough to not support using div
Dec 05 16:09:02 <dv_> ah, good point. I'll compare the versions
Dec 05 16:09:31 <fray> it also may be that that doesn't mean what we think it means?
Dec 05 16:09:59 <fray> OE-Core by default uses the standard ARM eabi calling sequence (does not use VFP floating point registers for passing info)
Dec 05 16:10:07 <fray> you can try to enable it, by switching your tune..
Dec 05 16:10:56 <fray> I'm guessing the tune you'd want is: armv7athf-neon
Dec 05 16:11:34 <fray> 'er.. wait..
Dec 05 16:11:55 <fray> it would be:  cortexa8hf-neon  or ...thf-neon  (if you want ot support thumb.. your list there idd not have thumb enabled)
Dec 05 16:12:45 <fray> the machine configuration file is most likely where your DEFAULTTUNE is defined.. if it's not defined there, then you should be able to do it in your local.conf
Dec 05 16:13:38 <zeddii> mckoan, I took at quick look at the recipe, in oe-core/danny, there isn't a require linux.inc, where are you getting it from ?
Dec 05 16:14:42 <mckoan> zeddii: it's mine, actually does nothing I think I could remove it
Dec 05 16:15:13 <mckoan> I'm trying PERF_FEATURES_ENABLE="False" unsuccessfully
Dec 05 16:15:43 <zeddii> aha. ok, I'll look more then.
Dec 05 16:34:46 <zeddii> mckoan. looking at your build log, and recipe, I can't see where you are getting do_compile_perf in the context of your linux recipe. that should be invoked from the dedicated perf recipe. So there's something else in your layer that I'm not seeing.
Dec 05 16:37:08 <mckoan> zeddii: i only do subtle code :-D
Dec 05 16:37:58 <mckoan> s/subtle/sneaky
Dec 05 16:38:36 <dv_> zeddii: well, the div issue is still a mystery, but enabling orc fixed the performance problems, so finding out about div isnt urgent anymore
Dec 05 17:22:25 <zenlinux> Hey folks, I'm having issues now building denzil on the autobuilders - qemu-native's configure is failing due to missing GL support.
Dec 05 17:22:51 <zenlinux> This isn't an issue for master builds anymore, because my understanding is that we've removed qemu GL support now?
Dec 05 17:22:59 <bluelightning> zenlinux: we have ys
Dec 05 17:23:01 <bluelightning> yes
Dec 05 17:23:14 <zenlinux> I'm wondering if I should do the same in denzil
Dec 05 17:23:38 <bluelightning> I'm not sure it's really appropriate for denzil
Dec 05 17:24:16 <zenlinux> ok, I'd prefer to avoid an invasive change like that anyway. Now trying to figure out why the autobuilder no longer works for denzil
Dec 05 17:24:34 <bluelightning> IIRC it wasn't that we removed it because it didn't work, it was that it wasn't able to be forward-ported easily and was unlikely to be accepted upstream I think
Dec 05 17:24:53 <bluelightning> and thus it was preventing an upgrade of qemu
Dec 05 17:25:40 <bluelightning> SDL/GL headers have been removed perhaps (or not installed on new ab machines)?
Dec 05 17:26:10 <zenlinux> that was my first suspicion, but consulting with michael I'm not seeing that. Going to poke around on the systems myself
Dec 05 18:56:29 <Crofton> halstead, do you make the lists for yoctoproject?
Dec 05 18:56:58 <halstead> Crofton, Yes. And Jefro manages them.
Dec 05 18:57:47 <Crofton> ok, did you see the latest on creating meta-zynq? or should I send you a copy direct
Dec 05 18:59:05 <halstead> Crofton, Please send me a copy. michael@yoctoproject.org
Dec 05 19:00:49 <Crofton> also, do you take care of adding gmane?
Dec 05 19:18:53 <Jefro> Crofton I manage the lists, but Richard controls the approval process. I haven't seen a request for meta-zynq but if you send it to me I can follow up.
Dec 05 19:21:02 <Jefro> In general, there would need to be a fairly obvious need for a list before we set one up (high visibility, high traffic, etc), otherwise the main mailing list is recommended
Dec 05 19:24:56 <Crofton> we'll see what RP says, but we have had one request from a user and zeddii also agrees it may be helpful
Dec 05 19:35:26 * zeddii nods. I can be pinged for whatever reasons we need. In theory this will hopefully expand the traffic as well.
Dec 05 19:47:58 <pidge> halstead: ping
Dec 05 19:48:44 <pidge> halstead: do was have any offline archival space? I'd like to archive a bunch of the stuff in http://downloads.yoctoproject.org/releases/yocto/milestones/
Dec 05 19:51:11 <halstead> pidge, I don't.
Dec 05 19:51:38 <halstead> pidge, Let me check a few things.
Dec 05 20:03:00 <pidge> halstead: ty. I want to solve some space concerns and getting that off will help a lot.
Dec 05 20:14:42 <halstead> pidge, How offline can these be? Is 1 day to restore fine?
Dec 05 20:49:18 <pidge> halstead: perfect
Dec 05 20:50:15 <halstead> pidge, I'll see what I can come up with.  BTW any progress on clearing sstate?
Dec 05 20:57:38 <RP> Crofton: We seem to be going from one extreme to another here...
Dec 05 20:57:51 <RP> I have no objection to the lists but would prefer we didn't create some with limited traffic
Dec 05 21:00:09 <Crofton> obviously we hope to grow traffic
**** ENDING LOGGING AT Thu Dec 06 02:59:58 2012

**** BEGIN LOGGING AT Thu Dec 06 02:59:59 2012
Dec 06 08:23:26 <mckoan> good morning
Dec 06 09:39:58 <bluelightning> morning all
Dec 06 11:37:05 <sujith> Hi all when I try to build udev version 182, I am getting an error saying http://pastebin.com/pymum2n8
Dec 06 11:37:21 <sujith> not able to figure out why its failing for variable SUMMARY
Dec 06 11:38:14 <sujith> any clue?
Dec 06 13:09:36 <otavio> rburton: Please, can you take a look in 0f872d91f400e64ab4a1bffb014970335ec37da2 for danny? It is in master.
Dec 06 13:10:04 <otavio> rburton: the OE-Core revision is: 715631e5b8d5fc7dbcc8b8cbca1948f9301e8d68
Dec 06 13:10:10 <otavio> rburton: I took the poky one, sorry.
Dec 06 13:12:39 <rburton> otavio: merged that about 20 seconds ago
Dec 06 13:12:53 <rburton> just battling combo-layer now
Dec 06 13:13:08 <rburton> otavio: http://git.openembedded.org/openembedded-core-contrib/log/?h=ross/danny-next
Dec 06 13:13:30 <otavio> rburton: :-) thx!
Dec 06 13:13:47 <rburton> otavio: anything else? :)
Dec 06 13:14:22 <otavio> rburton: I asked Beth about the license fix, in ml ... but I think this is not in master yet
Dec 06 13:14:40 <otavio> rburton: not for now then ;)
Dec 06 13:14:54 <otavio> rburton: I'll pester you if I find or notice something missing ;)
Dec 06 13:14:57 <rburton> sure
Dec 06 13:24:57 <rburton> otavio: poky-contrib:ross/danny-next pushed
Dec 06 13:25:15 <rburton> i'll get that running on the autobuilder tonight
Dec 06 14:44:21 <otavio_> rburton: good :)
Dec 06 14:55:42 <subodh> anyone used yocto for i.mx6q (Boundary Devices)? Otavio referred me here.
Dec 06 15:12:47 <mckoan> do you know if exist any BSP/metadata using linux LTSI ?
Dec 06 15:24:30 <zeddii> mckoan. not in the yocto kernel's at least, waiting for Greg to lock down the first -rc and I'll be making use of it then.
Dec 06 15:31:28 <ant_work> zeddii: hello. Lurking in the sources, I've found the hw/non-hw overrides are expected in the always_ files
Dec 06 15:32:40 <ant_work> what I don't get is "redefined_as_board_specific"
Dec 06 15:33:26 <zeddii> ant_work. those would be config options that were called non-hardware by a base layer, but a board config switches them to hardware to override and silence a warning.
Dec 06 15:34:13 <zeddii> it's a slow progression to optional/required, that I'm continuing to fix up in 1.4. Are you getting warnings you can't silence ? if so shoot me an email and I'll have a specific look.
Dec 06 15:35:02 <ant_work> ok, I'm planning to split the couple of fragments detected as non-hw
Dec 06 15:35:19 <ant_work> I'm still deciding the appropriate destination
Dec 06 15:35:32 <mckoan> zeddii: I still have the issue with perf, however I'd like to drop the 2.6.30 and start working on something more interesting like 3.4+LTSI patches
Dec 06 15:36:09 <mckoan> BTW this perf stuff is definitely puzzling
Dec 06 15:36:17 <ant_work> :/
Dec 06 15:37:44 <kergoth> subodh: the only i.mx6q support I know of is from freescale's public arm layer. http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm - http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/conf/machine
Dec 06 15:38:29 <kergoth> we build for the imx6qsabrelite machine on a regular basis, but I'm not very familiar with the others,the hardware, or with 'boundary devices'
Dec 06 15:38:48 <mckoan> however I wonder how would be worthwhile working in Danny rather than main
Dec 06 15:39:07 <mckoan> s/main/master
Dec 06 15:40:49 <mckoan> kergoth: but if Otavio pointed him here, I am afraid that is not supported
Dec 06 15:41:06 <kergoth> it's a good point
Dec 06 15:41:11 <kergoth> didn't notice that :)
Dec 06 15:41:19 * kergoth isn't sure how he missed that
Dec 06 15:54:22 * kergoth sighs, i really hate it when people send patches to mailing lists without [PATCH
Dec 06 16:01:42 <otavio_> Uh?
Dec 06 16:01:57 <otavio> kergoth: what is the problem with sabrelite?
Dec 06 16:02:12 <otavio> mckoan:  ^?
Dec 06 16:02:31 <otavio> subodh: ah!
Dec 06 16:02:34 <otavio> subodh: hi!
Dec 06 16:03:00 <otavio> subodh: meta-fsl-arm support most boards
Dec 06 16:03:27 <otavio> subodh: but it doesn't support the Nitrogen boards from Boundary as noone sent a patch for it and I don't have the board myself
Dec 06 16:04:19 <otavio> subodh: and you should use yocto and add meta-fsl-arm to add support for Freescale's ARM boards.
Dec 06 16:05:03 <otavio> mckoan: We'll be moving to master work shortly; we are working in danny so we can make a 'release' and work in 1.4 integration after it.
Dec 06 16:05:37 <otavio> mckoan: but we wanted to allow people to use imx6 with danny before doing more radical changes and move to 1.4 based work
Dec 06 16:10:03 <mckoan> otavio: ack, thank you fot the clarification ;-)
Dec 06 16:12:00 <otavio> mckoan: and we did not branch yet because when we do people start think we'll not break it anymore
Dec 06 16:25:29 <zeddii> mckoan. if all your layers and configs are availble somewhere, I can always try a build and see what's up with perf.
Dec 06 16:26:27 <mckoan> zeddii: is the same link as yesterday: ftp://support.koansoftware.com/public/meta-kaeilos-atmel-2012-12-05.tgz
Dec 06 16:27:07 <mckoan> zeddii: just to understand what's wrong there
Dec 06 16:27:38 <mckoan> zeddii: BTW since now I started working on linux-3.4.21-ltsi-1.0-r0
Dec 06 16:29:13 <zeddii> ok, maybe better to just hear if you see it on your new kernel then.
Dec 06 16:31:33 <subodh> Otavio: Sorry missed you. Boundary folks told me that their i.mx6q is based off of SabreSD with a few pin differences. I am waiting for a word from kkatyal about his progress. Will look into Yocto otherwise.
Dec 06 16:32:09 <mckoan> zeddii: I expect no perf problems with 3.x
Dec 06 16:33:56 <zeddii> mckoan. but you should be able to disable it's build or not see it build at all, since that's what you needed with 2.6.x
Dec 06 16:34:28 <otavio> subodh: sabresd and sabreauto are supported
Dec 06 16:34:51 <subodh> otavio: thankx
Dec 06 16:37:32 <Song_Liu> https://wiki.yoctoproject.org/wiki/File:1.4_M1Test_Summary.png https://wiki.yoctoproject.org/wiki/File:1.4_M1Issue_Summary.png
Dec 06 16:40:19 <otavio> subodh: so adding the nitrogen board shouldn't be hard. But someone needs to test it ...
Dec 06 16:41:57 <subodh> otavio: if you can share some ptrs/urls that would be great. I am going through website for building BSP right now.
Dec 06 16:42:11 <zeeblex> song: performance test result is now conducted only with the sources previously fetched....
Dec 06 16:43:39 <otavio> subodh: The easiest way to build something is using the fsl-community-bsp-platform I send you ...
Dec 06 16:43:52 <otavio> subodh: it makes all integration for you
Dec 06 16:44:01 <otavio> subodh: you just need to change the machine and build
Dec 06 16:49:09 <subodh> #otavio
Dec 06 16:49:25 <subodh> now downloading from github
Dec 06 16:49:40 <otavio> subodh: good
Dec 06 16:57:51 <mckoan> have a nice rest of the day
Dec 06 17:15:22 <b1gtuna> good morning everybody, is there a way to supply sstate cache URL to bitbake?
Dec 06 17:15:29 <b1gtuna> as a bitbake parameter?
Dec 06 17:19:48 <kergoth> no
Dec 06 17:19:57 <kergoth> it's a variable, like everything else
Dec 06 20:11:56 <evanp> b1gtuna: a trick like MACHINE="${@os.getenv('MACHINE')}" may work. or just 'sed' your site.conf.
Dec 06 21:45:50 <kergoth> evanp: env vars always flow into the metadata, its built in functionality. MACHINE in particular is by default included in the list of whitelisted variables (others can be added to BB_ENV_EXTRAHIWTE)
Dec 06 21:49:02 <evanp> right, I forgot that....
Dec 06 22:21:37 <ant_home> zeddii: hm.. do_validate_branches is failing today
Dec 06 22:22:08 <ant_home> must be " inform the fetcher if the meta branch changes"
Dec 06 22:26:45 <ant_home> ah, no
Dec 06 22:27:17 <ant_home> ERROR: SRCREV was set to "b13bef6377719a488293af196236cc290566fad3", but no branches contain this commit
Dec 06 22:29:02 <ant_home> seems introduced with  "linux-yocto/3.4: merge v3.4.19, v3.4.20"
Dec 07 00:04:06 <kergoth> http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/commit/?id=42d61f1 may be of interest, I think it's a bit cleaner than the way shr is implementing the lockdown right now
Dec 07 00:04:25 <ant_home> zeddii: somehow I had to remove the downloaded git tree. Refetched and working
Dec 07 00:17:20 <mranostay> kergoth: any reason bitbake would getting an DL_DIR override?
Dec 07 00:17:27 <mranostay> from the environment?
Dec 07 00:52:14 <kergoth> mranostay: unless it's listed in BB_ENV_EXTRAWHITE, nope. prettys ure it's not in the default whitelist
Dec 07 01:47:21 <mranostay> kergoth: thank you
Dec 07 01:50:08 <kergoth> np
**** ENDING LOGGING AT Fri Dec 07 02:59:59 2012

**** BEGIN LOGGING AT Fri Dec 07 02:59:59 2012
Dec 07 04:52:35 <seebs> Huh. Not sure who owns which of the pages involved, but the first search result I got for "yocto pseudo" on Google got me to a wiki that still pointed to the old github page, and also to /projects/pseudo on yoctoproject.org, neither of which is right anymore.
Dec 07 04:53:08 <seebs> Looks like https://www.yoctoproject.org/tools-resources/projects/pseudo is the new URL, but it should probably be updated to point to the Yocto project git repo.
Dec 07 08:44:34 <mckoan> good morning
Dec 07 09:13:29 <bluelightning> morning all
Dec 07 12:20:21 <rburton> I don't suppose anyone has packaged llvm for oe?
Dec 07 12:24:16 <rburton> ah its in oeclassic
Dec 07 12:46:11 <laur> seebs: ping
Dec 07 13:14:27 <RP> seebs: its a wiki ;-)
Dec 07 13:14:30 <RP> seebs: I've fixed it
Dec 07 13:15:37 <BjornArnelid> Hi, Im trying to use systemtap in the yocto eclipse plugin. It seems like it requires pre-compiled systemtap kernel modules. Does anyone knows how i go about creating one of those?
Dec 07 14:21:14 <Zagor> what is the bottleneck in pseudo? it seems to wait for neither i/o nor cpu
Dec 07 14:34:21 <RP> Zagor: that is a good question. IPC bound most likely
Dec 07 14:50:00 <Zagor> does someone here have mailman admin access and can check why that patch I mailed to poky@yoctoproject.org ~90 minutes ago is held?
Dec 07 14:58:46 <Zagor> it's a very minor patch but it's annoying if I can't mail the list
Dec 07 14:59:46 <Zagor> (From: bjst@enea.com)
Dec 07 15:08:33 <Zagor> RP: it feels like there might be room for optimisation there
Dec 07 15:09:46 <RP> Zagor: nothing in the moderator queue for poky?
Dec 07 15:10:01 <RP> Zagor: possibly, question is how/where
Dec 07 15:10:04 <Zagor> weird
Dec 07 15:10:10 <eren> Zagor: (off topic), I once used rockbox in my ipod, great firmware :)
Dec 07 15:10:19 <Zagor> eren: thanks :)
Dec 07 15:11:41 <Zagor> RP: I don't know, I haven't looked into pseudo at all (yet). it just feels suboptimal to spend so much time "doing nothing"
Dec 07 15:12:46 <RP> Zagor: pseudo is a complex thing :/
Dec 07 15:12:55 <Zagor> yeah, I can imagine
Dec 07 15:16:16 <RP> Zagor: FWIW I've been putting together https://wiki.yoctoproject.org/wiki/Profiling
Dec 07 15:16:26 <RP> Zagor: for pseudo, I've wondered if a path filter would help it
Dec 07 15:26:56 <Zagor> RP: I wish I had any good ideas :) the only thing I can think of is adding some profiling to pseudo to see where the time is spent.
Dec 07 15:37:51 <RP> Zagor: I think seebs has ideas
Dec 07 16:05:29 <mckoan> I don't understand why with Yocto (Danny) bitbake -c devshell virtual/kernel has a different behaviour that I am used with OE
Dec 07 16:05:55 <mckoan> with OE (classic) devshell presented me a fully opertional environment
Dec 07 16:06:08 <mckoan> so I was able to do make uImage inside it
Dec 07 16:06:37 <mckoan> OTOH with Yocto the same build is impossible because fails
Dec 07 16:07:04 <mckoan> I think you can try it by yourself with every kernel
Dec 07 16:11:41 <kergoth> 'because fails' isn't exactly informative
Dec 07 16:46:51 <mckoan> kergoth: let's say that I get this error :-)
Dec 07 16:46:53 <mckoan> arm-poky-linux-gnueabi-ld: unrecognized option '-Wl,-O1'
Dec 07 16:47:23 <rburton> -Wl is an option to gcc to pass to ld
Dec 07 16:47:34 <rburton> so your flags are going to the wrong place
Dec 07 16:48:11 <mckoan> rburton: but shouldn't devshell set all the variables properly?
Dec 07 16:48:32 <rburton> yes, and if it works outside of devshell then something odd is happening
Dec 07 16:53:08 <mckoan> rburton: ok thx, I have another item to verify then :-|
Dec 07 16:55:47 <mckoan> have a nice rest of the day
Dec 07 17:45:15 <schramae> hi. i'm trying to include the kernel (RPM) in the rootfs. i added IMAGE_INSTALL_append = " kernel kernel-modules" to the image recipe, but this only installs the modules, not the kernel. only hint i found so far is https://lists.yoctoproject.org/pipermail/yocto/2012-February/007144.html but this does not seem to be a reliable solution
Dec 07 17:46:26 <seebs> Zagor: Long story short, I think pseudo's main bottleneck is that any given pseudo environment is serializing all requests, so a ton of stuff ends up waiting idle -- which produces very low CPU utilization, and not all that much disk I/O.
Dec 07 17:46:51 <seebs> Because if it's not doing database I/O, everyone's waiting on the network messages and other processes getting a chance to send or receive messages...
Dec 07 17:48:22 <fray> I wonder if there is any way to avoid the serialization... I suspect locking will be painful
Dec 07 17:48:54 <fray> I suspect you also still end up serialized at the DB though
Dec 07 17:49:43 <seebs> Yeah.
Dec 07 17:50:02 <seebs> Well, the obvious first pass is my proposed protocol change to have messages that ignore responses not wait for responses, and not get them.
Dec 07 17:50:16 <seebs> So the clients would be spending less time waiting.
Dec 07 17:50:40 <seebs> The other thing is, switching sqlite to an in-memory database produces huge speedups on test code. Oddly, setting localstatedir to a tmpfs doesn't.
Dec 07 17:50:51 <fray> would the client still wait, but the server know no response, to it responses immediately as such?
Dec 07 17:51:00 <fray> or would the clients need to know which items to wait for?
Dec 07 17:51:34 <fray> with an in-memory DB, how do you dump the data to the disk at the end of a run?
Dec 07 17:52:04 <fray> (and reload it to an in-memory DB).. my concern also with memory required to build could increase dramatically
Dec 07 17:53:17 <seebs> My plan was that each message would have a flag for whether the client was waiting for a response. So you'd either send a message with FLAG_NORESPONSE, and not wait for a response, or send one without that flag, and wait.
Dec 07 17:53:56 <seebs> The size of the DB is pretty tiny, and the intent was to save/load the DB. In light testing, that appears to work; sqlite has nice features for that.
Dec 07 17:54:23 <seebs> Main thing is, I *think* that the filesystem is helpfully fully-flushing everything in sight when sqlite says "make sure this is fully synchronized".
Dec 07 17:58:10 <walters> yeah, it's carefully designed to not lose your data on things like system crashes
Dec 07 17:58:30 <seebs> Which is awesome, but in this case, we don't actually care much if we lose a pseudo database.
Dec 07 17:59:02 <seebs> My sort of notion would be to have pseudo create a file that says "I am not totally sure this database is in a valid state", and delete it once the database file is flushed and fsync'd.
Dec 07 17:59:15 <seebs> And if we find that, we assume the package needs to be cleaned and retried.
Dec 07 23:27:57 <martin_> hey guys
Dec 07 23:28:30 <martin_> im working with the current yocto rls(1.3) and try to include in my image only specific packagegroups
Dec 07 23:28:42 <martin_> so i only take some out of the packacgegroup receipt
Dec 07 23:28:45 <martin_> for example
Dec 07 23:28:58 <fray> sounds like you want a custom image..
Dec 07 23:29:04 <martin_>     packagegroup-core-lsb-perl \     packagegroup-core-lsb-python \
Dec 07 23:29:08 <martin_> but
Dec 07 23:29:18 <martin_> it includes allways packagegroup-core-lsb
Dec 07 23:29:21 <martin_> so the full package
Dec 07 23:29:28 <martin_> yes fray
Dec 07 23:29:49 <martin_> i checked it with hob and bitbake to build the dep tree
Dec 07 23:29:53 <fray> you have two 'easy' options.. the first is to use 'hob' to create your custom image.. or just create a layer, and do it that way
Dec 07 23:30:06 <martin_> perhaps i understand it worng, i thought i can include every of this listed packages
Dec 07 23:30:10 <fray> packagegroups-* are set containers of known functionality..
Dec 07 23:30:35 <fray> you don't want to 'remove' things from them.. instead you want to create your own sets and use those in your image. (at least that is the typical case I see)
Dec 07 23:30:49 <martin_> i want to include only some packages out auf the packagegroup packagegroup-core-lsb
Dec 07 23:31:02 <fray> thats fairly typical..
Dec 07 23:31:03 <martin_> hmm
Dec 07 23:31:20 <martin_> i tried hob and to click it together
Dec 07 23:31:31 <fray> there are two ways of looking at this.. you want to "remove" some packages from packagegroup-core-lsb or you want something that is similar to packagegroup-core-lsb, but that you control..
Dec 07 23:31:38 <fray> the 'remove' simply isn't an option..
Dec 07 23:31:39 <martin_> but even hob only list the main file under package groups so packagegroup-core-lsb
Dec 07 23:31:43 <fray> the similar to, is how you do it
Dec 07 23:31:53 <martin_> yeah
Dec 07 23:31:54 <fray> you copy the original, or simply define it yourself in your own layer and do it that way..
Dec 07 23:32:07 <fray> hob makes it easy to create custom images..
Dec 07 23:32:09 <martin_> well i dont want to overlay when its possible
Dec 07 23:32:19 <fray> you don't even have to use a packagegroup... you can do it by package
Dec 07 23:32:25 <martin_> yes i know
Dec 07 23:32:31 <martin_> worked long time with oe-classic
Dec 07 23:32:48 <martin_> but ypu understand my problem?
Dec 07 23:33:01 <martin_> the manual said i can add very listed package out of the ackagegroup
Dec 07 23:33:14 <martin_> but it seems only add the whole group file at all
Dec 07 23:33:20 <fray> You can do things like IMAGE_INSTALL = 'bash busybox blah blah blah'
Dec 07 23:33:39 <fray> or define your own packagegroup recipes
Dec 07 23:34:00 <martin_> IMAGE_INSTALL ?= "\     packagegroup-core-basic \     packagegroup-core-boot \     packagegroup-core-sys-extended \     packagegroup-core-db \     packagegroup-core-perl \     packagegroup-core-python \     packagegroup-core-tcl \     "
Dec 07 23:34:04 <martin_> why this isnt possible
Dec 07 23:34:34 <fray> maybe I'm not understanding
Dec 07 23:34:41 <martin_> when i use it liek this i get the full packagegroup-core-lsb
Dec 07 23:34:51 <fray> what image are you building?
Dec 07 23:34:58 <fray> what distribution have you enabled?
Dec 07 23:35:58 <martin_> yocto
Dec 07 23:35:59 <martin_> poky
Dec 07 23:36:05 <martin_> its a custom layer
Dec 07 23:36:09 <martin_> with a custom image file
Dec 07 23:36:18 <fray> the poky distro will not automatically add anything from the LSB.. "poky-lsb may though"
Dec 07 23:36:25 <martin_> i know
Dec 07 23:36:31 <martin_> its geta dded because of the above listed packages
Dec 07 23:36:35 <fray> your custom image recipe would only add things if it or something it depends on has that dep
Dec 07 23:36:45 <martin_> whicha re part of this packagegroup receipt
Dec 07 23:37:14 <fray> either don't use the particular packagegroup(s) that depend on the LSB configuration(s), or override them and define a custom version
Dec 07 23:37:27 <martin_> well you understand now my problem ?
Dec 07 23:37:35 <martin_> as far as i udnerstand it the behaviour is wrong
Dec 07 23:37:38 <martin_> perhaps a bug
Dec 07 23:37:56 <martin_> i know that i can solve it with overlaying or adding the packages manually
Dec 07 23:38:00 <fray> I'm not seeing the bug..
Dec 07 23:38:16 <fray> If you select something that depends on packagegroup-...lsb, then it's going to install that..
Dec 07 23:38:22 <martin_> in a apckagegroup receipt are packages listed right ?
Dec 07 23:38:34 <martin_> so the custom packages
Dec 07 23:38:43 <fray> the packagegroups are just binary --install time time packages with their own dependency sets---  these dependencies are what cause the other packages to be installed..
Dec 07 23:39:04 <fray> you need to either modify (.bbappend) or create custom packagegroup recipes that don't bring in the items you don't want
Dec 07 23:39:21 <fray> packagegroups recipes list dependencies.. these dependencies -may- be packages
Dec 07 23:39:27 <martin_> PACKAGES = "\     packagegroup-core-lsb \     packagegroup-core-sys-extended \     packagegroup-core-db \     packagegroup-core-perl \     packagegroup-core-python \
Dec 07 23:39:29 <martin_> i mean this
Dec 07 23:39:46 <martin_> out of the lsb packagegroup receipt
Dec 07 23:39:53 <fray> PACKAGES is what gets produced.. RDEPENDS_<packagename> is what gets depended on
Dec 07 23:40:01 <martin_> right
Dec 07 23:40:13 <martin_> why i cant use this produced PACKAGES
Dec 07 23:40:51 <martin_> packagegroup-core-python is a new package which got ofc other deps
Dec 07 23:40:56 <martin_> like python
Dec 07 23:41:19 <fray> I don't understand your question
Dec 07 23:41:34 <martin_> but why packagegroup-core-python seesm to install packagegroup-core-lsb
Dec 07 23:42:16 <martin_> http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#usingpoky-extend-customimage-customtasks
Dec 07 23:42:26 <fray> check the packagegroup..  if you are using rpm packages..
Dec 07 23:42:44 <fray> cd tmp/deploy/rpm/...   rpm -qp packagegroup-core-python --requires
Dec 07 23:43:24 <martin_> hm i think im using deb
Dec 07 23:43:25 <martin_> wait
Dec 07 23:44:00 <fray> then you can use "ar x ....deb" ... tar xvfz control.tar.gz
Dec 07 23:44:03 <fray> and inspect the control file
Dec 07 23:44:17 <fray> (ipk is the same AFAIK)
Dec 07 23:44:50 <martin_> but i understand the manual right ?
Dec 07 23:45:40 <fray> that section is telling you to device a new recipe..
Dec 07 23:45:58 <fray> and then following htrough it it defines two custom packagegroups.. ...custom-apps and ...custom-tools..
Dec 07 23:46:08 <fray> each of the two have their own unique dependencies or recommends..
Dec 07 23:46:45 <martin_> right
Dec 07 23:46:54 <martin_> but its possible to use only one of them
Dec 07 23:47:01 <martin_> liek i want to do on the lsb stuff
Dec 07 23:47:32 <fray> you have to 'build' everything listed in a packagegroup recipe (just like any other recipe).. but you don't need to include all of them in your IMAGE_APPEND
Dec 07 23:47:37 <fray> 'er.. IMAGE_INSTALL
Dec 07 23:48:06 <fray> so if you do, IMAGE_INSTALL = "packagegroup-custom-tools", it's still going to build packagegroup-custom-apps and everything it depends on.. you just are choosing to not install that..
Dec 07 23:48:18 <martin_> hmm
Dec 07 23:48:22 <fray> that is because the packagegroup-custom (example) defines all of those things as a unit
Dec 07 23:48:25 <martin_> wait that could explain soem stuff
Dec 07 23:48:49 <martin_> and both hob and bitbake only list the build depency ?
Dec 07 23:48:54 <fray> The build is in two pieces.. you first build all of the software to setup your package feed, and then you use the package feed to create your install image/rootfs
Dec 07 23:49:00 <martin_> and not the include depency
Dec 07 23:49:08 <fray> DEPENDS and RDEPENDS are both dependencies
Dec 07 23:49:11 <martin_> yes
Dec 07 23:49:23 <fray> they will both be evaluated at build time, to determine what has to be built for the recipe (as a whole) to be successful
Dec 07 23:50:27 <fray> back to the python one, packagegroup-core-python is defined within the packagegroup-core-lsb recipe.  So everything defined in packagegroup-core-lsb recipe has to be built to seed the packagefeed
Dec 07 23:50:27 <martin_> well i aborted all the time when it start to rebuild the qt crap
Dec 07 23:50:33 <fray> qt is required by the LSB
Dec 07 23:50:34 <martin_> but eprhaps it didnt get included at the end
Dec 07 23:50:55 <martin_> yeah so ofc it ash to be built
Dec 07 23:51:03 <martin_> has
Dec 07 23:51:08 <fray> everything defined in packagegroup-core-lsb is defined for LSB based distributions.. if you are not one of them.. then you probably shouldn't use packagegroup-core-python
Dec 07 23:51:21 <fray> instead actually specify the python modules your end device needs
Dec 07 23:51:25 <martin_> well i only thought its a clean base
Dec 07 23:51:40 <martin_> but you are right will build my own package group
Dec 07 23:51:45 <fray> I only use items from the LSB groups, when building LSB things..
Dec 07 23:52:04 <fray> for stuff that needs python, perl, etc.. I just generate custom image recipes and include them specifically
Dec 07 23:52:13 <fray> (or they come in automatically based on run-time dependencies
Dec 07 23:52:17 <martin_> soevery packages and not the packagegroups
Dec 07 23:52:36 <fray> yes..
Dec 07 23:52:49 <fray> but the goal is to list the minimum set you need.. and everything else will come in for you
Dec 07 23:52:56 <fray> packagegroups are just supposed to be starting points..
Dec 07 23:54:23 <martin_> i c
Dec 07 23:54:30 <martin_> ok will try this thx for your help
Dec 07 23:55:22 <martin_> is there a proper way to include the meta-oe layer
Dec 07 23:55:29 <martin_> it sucks because only this one got mysql
Dec 07 23:55:35 <martin_> and overlays a bunch of packages
Dec 07 23:56:37 <fray> add what you need to the bblayers.conf  --- that will then make those layer's recipes available to you
Dec 07 23:58:05 <martin_> well the priority of the meta-oe layer is higher then the one of the yocto
Dec 07 23:58:09 <fray> hopefully the meta-openembedded README as the right info to tell you how to ad it
Dec 07 23:58:20 <fray> yes.. that is because it replaces some components..
Dec 07 23:58:25 <Crofton> sounds like we should have an understand override in meta-oe and see if they can be handled differently
Dec 07 23:58:31 <martin_> but i dont want to repalce the yocto leayer...
Dec 07 23:58:45 <fray> you aren't replacing -all- of Yocto.. just the items that layer has specified
Dec 07 23:58:45 <martin_> it would be ncie if we can apply the priorities in the local conf
Dec 07 23:58:52 <martin_> and not on the conf n the sperate git...
Dec 07 23:58:57 <fray> you can override the priorites in your bblayers.conf
Dec 07 23:59:03 <martin_> ahh
Dec 07 23:59:04 <martin_> how
Dec 07 23:59:45 <fray> So looking the README file is 'lacking'
Dec 07 23:59:59 <fray> bblayers.conf:
Dec 08 00:00:10 <fray> BBLAYERS ?= " \
Dec 08 00:00:10 <fray>   /home/mhatle/git/oss/oe-core/meta \
Dec 08 00:00:24 <fray>   /home/mhatle/git/oss/meta-openembedded/meta-oe \
Dec 08 00:00:25 <fray> "
Dec 08 00:00:29 <fray> that enables it..
Dec 08 00:00:42 <fray> if you want a different priority.. just specify it here..
Dec 08 00:00:51 <fray> BBFILE_PRIORITY_openembedded-layer = "10"
Dec 08 00:01:08 <fray> and I believe it will override the one in the layer.. (if not there may be another way to 'force it')
Dec 08 00:01:16 <martin_> hmm
Dec 08 00:01:19 <martin_> yeah thats the question
Dec 08 00:01:39 <fray> but what in meta-oe are you worried about.. in the past there were issues w/ systemd, but that should be handled by now
Dec 08 00:01:55 <martin_> well i tried to stay as stable as possible
Dec 08 00:01:58 <fray> (for the company I work for, our commercial products don't include the raw meta-oe, the stuff is too wild-west for us)
Dec 08 00:01:59 <martin_> so on the 1.3 rls
Dec 08 00:02:08 <martin_> yeah its for comercial
Dec 08 00:02:11 <martin_> thats the problem
Dec 08 00:02:11 <fray> (instead we cherry pick specific items)
Dec 08 00:02:20 <martin_> we develop baords and want to add oe support
Dec 08 00:02:37 <martin_> and this as opena s possible becasue we dont want to mainatin complete oe for our customer
Dec 08 00:02:51 <martin_> supply the hw layer and a debian liek system which they are using at the moment
Dec 08 00:03:09 <fray> then my suggetion is stick with as stock of a Yocto Project as you can..
Dec 08 00:03:23 <fray> skip anything from meta-oe and let your customers worry about that (or find an OSV that will help them)
Dec 08 00:03:31 <martin_> right...
Dec 08 00:03:48 <martin_> i worked on another comapny where we extended oe-classic extremly
Dec 08 00:03:51 <fray> as a board vendor, creating an OS is usually not your expertise.. and cherry picking stuff, or including random layers does make it more difficult to support
Dec 08 00:03:55 <martin_> thats getting really problematic at some point
Dec 08 00:04:04 <martin_> right
Dec 08 00:04:05 <fray> ya.. the point of layers is to help stop a lot of that complexity..
Dec 08 00:04:15 <martin_> yeah i first liekd it
Dec 08 00:04:20 <martin_> at the moment i hate it ;)
Dec 08 00:04:20 <fray> the complexity is no longer managing the repositories, but instead managing the set of combined layers..
Dec 08 00:04:38 <fray> The goal is whenever you pull down a layer, you use it unmodified (or only fix bugs locally)
Dec 08 00:04:44 <martin_> right
Dec 08 00:04:55 <fray> if a layer does something you don't want, then don't use the layer.. create your own -- even if it means copying a few recipes form eslewhere
Dec 08 00:05:17 <martin_> hehe
Dec 08 00:05:17 <fray> that is how we develop our commercial product..  90% of it is Poky (bitbake, oe-core, meta-yocto and related)
Dec 08 00:05:37 <martin_> \yeah like i said when i start copy in the layer i have to maintain
Dec 08 00:05:39 <fray> the remaining 10% is our distribution configuration(s), custom packages, (stuff pulled from meta-openembedded), and wrapping
Dec 08 00:05:44 <martin_> and no i dont want to maintain mysql :)
Dec 08 00:05:49 <fray> :)
Dec 08 00:05:59 <fray> it does make you think twice.. (which is also part of the point of this)
Dec 08 00:06:08 <martin_> well for example apache get divided in meta-webserver
Dec 08 00:06:09 <martin_> make sense
Dec 08 00:06:12 <fray> and some of hte meta-openembedded layers are better then others..
Dec 08 00:06:14 <martin_> so this is no problem
Dec 08 00:06:23 <fray> like networking, webserver.. those are a lot more focused and controlled..
Dec 08 00:06:29 <martin_> right
Dec 08 00:06:31 <martin_> but meta-oe
Dec 08 00:06:33 <fray> meta-oe is, lack of a better term, the dumping group
Dec 08 00:06:33 <martin_> is wildwest
Dec 08 00:07:57 <fray> when I speak at events, I usually tell people meta-oe is a good place to look for recipes, but it's only a starting point..  I don't consider anything in there "finished" or at the quality level of YP
Dec 08 00:08:30 * kergoth still thinks its priority should be permanently lowered so as to not override anything from oe-core
Dec 08 00:09:02 <martin_> yeah
Dec 08 00:09:12 <fray> kergoth no argument here.. but I don't maintain it.. ;)
Dec 08 00:09:12 <martin_> but would be ncie if mysql get included to yocto
Dec 08 00:09:22 <martin_> i dont liek it on embedded
Dec 08 00:09:28 <martin_> but you can expect what customers want
Dec 08 00:09:30 <fray> I doubt you'll see it in the yocto project..  just because of it's size..
Dec 08 00:09:31 <martin_> liek apache ...
Dec 08 00:09:47 <fray> it's more likely someone will add a meta-db or meta-mysql
Dec 08 00:10:00 <martin_> yeah would be nice
Dec 08 00:10:02 <martin_> BBFILE_PRIORITY_openembedded-layer = "1"
Dec 08 00:10:08 <martin_> this shoudl fix it for me hopefully
Dec 08 00:10:49 <fray> the thing I keep telling my people when they propose any changes.. "are you willing to maintain this?" if not.. rethink the change, work on it within the community to lower the support burden... or simply choose to support it
Dec 08 00:10:55 <kergoth> martin_: yeah, that works, we do that in our distro .conf
Dec 08 00:11:13 <martin_> i did it on the local conf
Dec 08 00:11:17 <martin_> there it didnt work :(
Dec 08 00:11:32 <kergoth> fray: Yeah, I have to do that too. push them in the direction of minimal deviation from upstream. even in a bbappend, use oe_filteR_out, don't duplicate anything..
Dec 08 00:11:33 <martin_> yeah fray same here
Dec 08 00:12:03 <kergoth> heh
Dec 08 00:12:09 <martin_> soa dding this to bblayers dont help
Dec 08 00:12:25 <fray> ok..
Dec 08 00:12:51 <kergoth> use bitbake -e, sanity check the value
Dec 08 00:13:05 <fray> one of my cats is trying to say hi apparently.. :P
Dec 08 00:13:41 <fray> (she keeps pawing at the keyboard while I'm trying)
Dec 08 00:13:50 <fray> umm.. typing
Dec 08 00:14:45 <fray> kergoth, is there a list of python modules that bitbake needs anywhere?
Dec 08 00:15:07 <fray> I'm trying to run bitbake using the python build within the nativesdk part of the system, but working through it one module at a time is painful
Dec 08 00:15:31 <kergoth> fray: pretty sure setup.py's metadata is current, but that only covers external dependencies, not the ones used in the standard library
Dec 08 00:15:38 <kergoth> you could likely code something up with the ast module
Dec 08 00:15:45 <kergoth> parse each .py, search the tree for imports
Dec 08 00:15:55 <kergoth> probably wouldn't take too long to throw together
Dec 08 00:16:00 <fray> I may just bring in all of the python chunks...
Dec 08 00:16:37 <martin_> so the low priority should appear on bitbake-layers right ?
Dec 08 00:16:59 <fray> bitbake-layers is by the order you put it in the bblayers file AFAIK
Dec 08 00:17:01 <martin_> on bitbake -e i only find the entry of the other conf
Dec 08 00:17:41 <kergoth> martin_: have to remember that conf/class priority is different than recipe priority, as fray points out, the former is controlled by BBPATH order, which is controlled by BBLAYERS order
Dec 08 00:18:29 * fray remembers there is the special "python-modules" which brings in everything
Dec 08 00:18:40 <RP> kergoth: have you looked at the EXPORT_FUNCTION implementation recently?
Dec 08 00:18:52 <martin_> kergoth: yeah i think fromup to down on the conf class stuff right
Dec 08 00:19:09 <RP> kergoth: We're doing some nasty things with the classes variable in the ast :(
Dec 08 00:20:10 * RP tried making it use  __inherit_cache only to find that its also broken (duplicate classes/base.bbclass and <fullpath>/classes/base.bbclass for each and every class)
Dec 08 00:20:30 <RP> and even with that fixed, it doesn't work
Dec 08 00:22:55 <RP> fray: look at build appliance, that has a list iirc
Dec 08 00:24:03 <martin_> adding to local.conf works
Dec 08 00:24:03 <martin_> nice
Dec 08 00:30:50 <martin_> ok thx for the help see ya later guys
Dec 08 00:35:45 <kergoth> RP: ugh, no, that's all really old code from many years ago that we've pretty much left alone since
**** ENDING LOGGING AT Sat Dec 08 02:59:59 2012

**** BEGIN LOGGING AT Sat Dec 08 02:59:59 2012
Dec 08 15:09:19 <jonszy> Hey there. I've been running into an issue with bitbake's hg fetcher. Could I bounce this off anyone here?
Dec 08 15:09:43 <jonszy> I shot something off to the mailing list, but I think my message was way too long ;)
Dec 08 15:13:39 <jonszy> The tl;dr: specifying a tag in SRCREV fails in the update that follows the pull, because the tag exists in the revision after what is checked out.
Dec 08 15:14:57 <jonszy> Relevent lines of hg.py are 123-130 and 142-147, with the failure occurring in the second chunk.
Dec 08 15:31:53 <jonszy> sheesh, sorry about the connection dance.
Dec 08 20:38:16 <seebs> Simple question (I hope): If I want to specify a non-obvious file path for a given file in the SRC_URI list, do I do file:///${absolute_path}, or do I (somehow) change the search path and leave the name alone? I have a reason to want to specify a file which does not live in the recipe directory.
Dec 08 20:38:30 <fray> no, filepath is what you want
Dec 08 20:39:24 <fray> FILESEXTRAPATHS_prepend = "<full path to look in>:"
Dec 08 20:39:31 <fray> (note the ':' it works like PATH)
Dec 08 20:40:25 <seebs> Okay, cool.
Dec 08 20:40:49 <seebs> I was gonna do some stuff last night after a quick errand.
Dec 08 20:41:00 <seebs> The quick errand included spending more than an hour on a two-mile stretch of freeway.
Dec 08 20:41:29 <seebs> During part of this, I was going nearly four miles an hour and my car started swerving because of poor traction. So I think I know WHY that two-mile stretch had something in excess of five cars off the road complete with tow trucks and such.
Dec 08 20:41:55 <fray> sounds like fun.. I avoided driving last night
Dec 08 21:15:41 <seebs> I should have avoided driving, but I thought I could beat the worst of the weather. Wrong! The worst part was about the first half hour, then it was boring and normal after that.
Dec 08 22:12:05 <kaiserfarrell> hello
Dec 08 22:14:25 <kaiserfarrell> may i know why this happen
Dec 08 22:14:27 <kaiserfarrell> ERROR: Function failed: Fetcher failure for URL: 'git://dev.omapzoom.org/pub/scm/integration/kernel-ubuntu.git;protocol=git;branch=ti-ubuntu-3.1-1282'. Unable to fetch URL from any source.
**** ENDING LOGGING AT Sun Dec 09 02:59:58 2012

**** BEGIN LOGGING AT Sun Dec 09 02:59:58 2012
Dec 09 11:16:16 <_Lucretia_> is there a variable I can use to grab the gcc source directory?
Dec 09 15:19:18 <kaiserfarrell_> hello
Dec 09 15:19:57 <kaiserfarrell_>  I got error openjade/openjade-native_1.3.2.bb, do_compile .. how can i solve it? http://pastebin.ubuntu.com/1421160/
Dec 09 19:16:12 <mtimc> I'm looking for a quick hint about bootstrapping a development environment under qemu for 1.3: I cannot find the pre-built kernel images in the download directory. Can anyone help?
**** ENDING LOGGING AT Mon Dec 10 02:59:58 2012

**** BEGIN LOGGING AT Mon Dec 10 02:59:58 2012
Dec 10 08:24:09 <mckoan> good morning
Dec 10 09:43:17 <bluelightning> morning all
Dec 10 09:46:19 <zecke> shoragan: hey
Dec 10 09:46:31 <shoragan> hi zecke :)
Dec 10 09:58:11 <zecke> shoragan: I saw your patches on netdev. :)
Dec 10 09:59:18 <shoragan> i should have checked net-next earlier
Dec 10 09:59:41 <shoragan> -ETOOMANYBRANCHES
Dec 10 10:06:29 <zecke> shoragan: I like to blame others. So, changes do not get fast enough to other devs
Dec 10 16:16:52 <RP> kergoth: since you're probably one of the few who were around when EXPORT_FUNCTIONS was written, can you have a look at the email I've sent. I can't figure out the point in the intermediary function indirection (although I see the point in the end bits)
Dec 10 16:18:27 <kergoth> Will do
Dec 10 19:29:03 <scottrif> halstead: ping
Dec 10 19:29:11 <halstead> scottrif, pong.
Dec 10 19:31:04 <scottrif> Halstead: I have Bill Traynor working with me on docs.  Do I have to go through something special to have him able to push commits to a temporary branch in yocto-docs?
Dec 10 19:32:34 <halstead> scottrif, Yes. I will need his public key in order to grant those permissions.
Dec 10 19:33:04 <halstead> scottrif, Have him e-mail it to me as an attachment to prevent whitespace issues.
Dec 10 19:33:54 <scottrif> halstead: what email address.. happypunch?
Dec 10 19:34:06 <halstead> scottrif, michael@yoctoproject.org
Dec 10 19:35:04 <wmat> halstead: key sent
Dec 10 19:35:27 <scottrif> wmat:  Nice... thanks
Dec 10 19:39:44 <scottrif> halstead: Let me know when permissions are in place.  Or let Bill (wmat) know and one of us can create the branch
Dec 10 19:47:27 <halstead> scottrif, wmat all ready. e-mail sent.
Dec 10 19:48:54 <seebs> We recently got bit by a bit of code in a do_install() which was using cp -a, and a (probably broken) host environment in which this produced strange behaviors. And looking around, I don't see a lot of cp -a. But I see a lot of various copying going on, and some tar|tar copies, and some things which are probably losing timestamps when they shouldn't be.
Dec 10 19:49:24 <seebs> And it occurs to me that if I can find three or four different solutions to what is almost certainly the same problem, it may be that there is call for a canonical solution.
Dec 10 19:50:06 <seebs> Which is to say, something which, for instance, probably expands to something like "cp -dR --preserve=mode,timestamps" in most Linux environments, but which could be adapted for specific hosts if there were a reason to (say, someone using a non-coreutils cp).
Dec 10 19:50:39 <seebs> And then this is made available to all bitbake shell tasks, and we encourage people to use it.
Dec 10 19:50:54 <seebs> But I'm not sure whether this would actually be any sort of win. I do know that I really don't want to have to retype that cp command a whole lot.
Dec 10 19:51:33 <kergoth> bbcopy? :)
Dec 10 19:52:20 <seebs> I think our previous build system used ${CP} which was very likely to do what you mean.
Dec 10 19:53:28 <kergoth> that's one nice thing about buildsystems that don't use raw shell commands, they tend to provide commands/functions in their DSL for such things, hiding the implementation details. of course we can still do that with shell, just less commonly seen
Dec 10 19:56:48 <kergoth> could roll our own —preserve= implementation in the script on platforms without gnu cp, or just rely on coreutils-native, though there could be circular dep issues there.. or for darwin, just make the user have 'gcp' available as via homebrew
Dec 10 19:57:28 <seebs> Yeah. I actually wrote a shell function named tarcp which was doing most of what I want, but... not quite all. Whoops.
Dec 10 20:24:10 <gjohnson_> I created a raspberry-pi build.  To cross compile do I just need to use the tools in rpi-build/tmp/sysroots/i686-linux/usr/bin/armv6-vfp-poky-linux-gnueabi and the sysroot rpi-build/tmp/sysroots/raspberrypi?
Dec 10 20:30:22 <seebs> gjohnson_: Probably, yes.
Dec 10 20:30:36 <seebs> ... Wait, does that imply that yocto's targetting the pi reasonably well? I am very interested in this.
Dec 10 20:31:07 <seebs> I have a couple of pis and I'm talking to some folks about doing some technical writing showing off cool things they can do. Yocto would be an EXCELLENT thing to write about.
Dec 10 20:33:16 <_Lucretia_> can you pass two git repos for 1 recipe?
Dec 10 20:34:09 <gjohnson_> seebs, https://github.com/djwillis/meta-raspberrypi works great.  I am just new to yocto and not sure what the best way to us it is.
Dec 10 20:34:34 <seebs> ooooh
Dec 10 20:47:35 <mranostay> _Lucretia_: ah yes
Dec 10 21:35:52 <martin___> hey guys
Dec 10 21:37:07 <martin___> i have the following porblem when i try to build my custom image
Dec 10 21:37:09 <martin___> http://pastebin.com/QJfL58xN
Dec 10 21:37:19 <martin___> seems to be a circular depency problem with dbus
Dec 10 21:37:47 <mranostay> is there some option to set the default password and shell for root?
Dec 10 21:38:17 <martin___> mranostay: perhaps about adding the stuff to the base-files receipt ?
Dec 10 21:38:23 <martin___> http://lists.linuxtogo.org/pipermail/openembedded-core/2011-December/014906.html
Dec 10 21:38:30 <martin___> error look simislar to this regression bug
Dec 10 21:38:41 <martin___> but i dont see there any solution for it :/
Dec 10 21:39:16 <mranostay> martin___: yeah i was hoping not to do that
Dec 10 21:39:30 <martin___> hehe
Dec 10 21:39:45 <martin___> hmm perhaps there is an option for it like this serial console option
Dec 10 21:39:51 <martin___> crawled the reference for it ?
Dec 10 22:05:45 <_Lucretia_> and is there a variable to grab the gcc source location from?
Dec 10 23:33:14 <kergoth> RP: https://gist.github.com/4254324
Dec 10 23:50:15 <RP> kergoth: hmm, not good :/
Dec 10 23:50:33 <kergoth> it's not critical, but it's an inconsistency in behavior based on context, which is unpleasant
Dec 10 23:50:44 <kergoth> opened a bug on it for tracking purposes
Dec 10 23:54:05 <RP> kergoth: sounds good
Dec 11 00:21:35 <JaMa> sgw1: ping
Dec 11 00:32:05 <sgw1> JaMa: replied to your pm
**** ENDING LOGGING AT Tue Dec 11 03:00:00 2012

**** BEGIN LOGGING AT Tue Dec 11 03:00:00 2012
Dec 11 09:09:09 <mckoan> good morning
Dec 11 09:11:19 <bluelightning> morning all
Dec 11 09:11:58 <RP> morning all
Dec 11 09:12:24 <JaMa> morning
Dec 11 09:14:06 <bluelightning> hi RP, JaMa
Dec 11 11:14:55 <eren> when is 1.4 planned to be released?
Dec 11 11:16:20 <JaMa> https://wiki.yoctoproject.org/wiki/Yocto_1.4_Schedule
Dec 11 11:18:36 <eren> JaMa: thanks
Dec 11 11:18:43 <eren> I will base my bsp and packages on danny, then
Dec 11 11:20:03 <eren> oe git HEAD seems appealing but I have limited cpu power. I will try bleeding edge tech later :)
Dec 11 15:51:41 * sgw1 reminds YPTM in about 10 minutes: 1.972.995.7777 Passcode: 76994298
Dec 11 15:51:48 * sgw1 forgot to send out email
Dec 11 16:00:48 <Crofton|work> bad sgw1
Dec 11 16:01:00 <bluelightning> YPTM: Paul Eggleton is on the call
Dec 11 16:01:03 * mihai1 Lindner is on the call
Dec 11 16:01:18 <tomz2> YPTM: Tom Z on the call
Dec 11 16:01:33 <scottrif> YPTM: Scott Rifenbark joined the call
Dec 11 16:01:52 <cristianiorga> YPTM: Cristian Iorga is online and on audio
Dec 11 16:02:14 <jmpdelos> YPTM: Polk is on
Dec 11 16:02:21 <fray> YPTM here
Dec 11 16:02:31 <fray> hi
Dec 11 16:02:46 <RP> sgw1: YPTM - here
Dec 11 16:02:47 <halstead> Yptm, Michael Halstead present.
Dec 11 16:04:17 <RP> jmpdelos: we've even had snow here in the UK, albeit briefly. Enough to gridlock the roads
Dec 11 16:04:37 <jzhang-laptop> YPTM: jzhang's here
Dec 11 16:05:36 * RP has a danny update 
Dec 11 16:05:45 <RP> (from Ross)
Dec 11 16:06:36 <nitink1> YPTM: nitin joining the bridge
Dec 11 16:06:37 <jmpdelos> RP: it snowed on me on one of my trips to London about this time of year.  I was lucky; I was almost on one of the trains that ended up stranded at the Chunnel
Dec 11 16:08:11 <RP> jmpdelos: stranded on eurostar isn't fun. I've had the experience for a few hours before :/
Dec 11 16:09:40 <eren> YPTM: Eren is on the call. Battery is dying though
Dec 11 16:09:45 <fray> can you force mute?
Dec 11 16:09:46 <bluelightning> eren: please mute :)
Dec 11 16:09:57 <eren> oh I'm so sorry
Dec 11 16:10:03 <eren> :)
Dec 11 16:10:06 <bluelightning> np :)
Dec 11 16:12:43 <eren> I can't talk right now, there are a lot of noise and my battery is dying. I just want to inform you that I'm working on BSP for ALIX 3D3 board, which has AMD Geode LX CPU
Dec 11 16:12:53 <eren> http://pcengines.ch/alix3d3.htm
Dec 11 16:13:14 <eren> after that, I will work on meta-hamradio
Dec 11 16:13:57 <RP> eren: sounds good :)
Dec 11 16:14:05 <Ramana_> Ramana joined YPTM
Dec 11 16:15:17 <Crofton|work> eren, what will you put in meta-hamradio?
Dec 11 16:15:22 <eren> oh, I need to go :( Run out of battery
Dec 11 16:15:30 <eren> Crofton|work: svxlink, aprx, fldigi
Dec 11 16:15:38 <Crofton|work> cool
Dec 11 16:15:48 <eren> and probably a logging tool
Dec 11 16:15:50 * fray won't be here.. :(
Dec 11 16:15:59 <fray> (or :)  )
Dec 11 16:16:01 <eren> I don't know the status of hamlib
Dec 11 16:16:15 <eren> I will look at it
Dec 11 16:16:15 <eren> Crofton|work: I can let you know :)
Dec 11 16:16:25 * eren has seconds before battery dies
Dec 11 16:16:35 <Crofton|work> thanks
Dec 11 16:16:50 <eren> Crofton|work: there is some work on ax25 side on kernel
Dec 11 16:17:05 <eren> it may be a distro feature
Dec 11 16:17:06 <evadeflow> David Wolfe of Magneti Marelli is lurking here... :-}
Dec 11 16:17:41 <eren> I will discuss it on mailing list
Dec 11 16:20:52 <eren> see you all! take care :)
Dec 11 16:47:31 <seebs> I have just been reminded: Are people aware that pseudo has the option of creating searchable logs of operations?
Dec 11 16:47:48 <seebs> "pseudo -l" will write logs into logs.db, "pseudolog" then searches it.
Dec 11 16:55:37 <RP> seebs: where is that documented? :)
Dec 11 16:55:46 <seebs> I think it's in the man page.
Dec 11 16:56:01 <RP> seebs: ah, so likely nobody knows then :)
Dec 11 16:56:23 <seebs> pseudolog is surprisingly powerful. It was my attempt at making a reasonably-usable subset of likely queries, and I think it actually works.
Dec 11 16:56:24 <RP> seebs: seriously, its good if it is there
Dec 11 17:01:27 <seebs> pseudo documents the -l option, and there is a pseudolog man page.
Dec 11 17:02:47 <seebs> Which is actually pretty usable. Except for the part where one of the bits in pseudolog.1 formats wrong in at least one version of man.
Dec 11 17:25:06 <otavio> Hello
Dec 11 17:25:20 <otavio> Is it possible for meta-freescale to use bugzilla from Yocto?
Dec 11 17:42:11 <mihai1> otavio: what layer?
Dec 11 17:44:08 <sgw1> otavio: there is a bsps/bsps-meta-fsl-ppc product/component in bugzilla for msm
Dec 11 17:44:44 <otavio> mihai1: meta-fsl-arm
Dec 11 17:45:05 <sgw1> otavio: Ah we don't have one for arm yet
Dec 11 17:45:12 <otavio> sgw1: can we add one for arm too?
Dec 11 17:45:13 <sgw1> otavio: who's the owner
Dec 11 17:45:20 <otavio> sgw1: currently me
Dec 11 17:45:47 <sgw1> otavio: hmm, I am on the phone and can't multitask right now.
Dec 11 17:45:55 <otavio> sgw1: hehe ok
Dec 11 17:46:04 <otavio> sgw1: take your time
Dec 11 17:51:13 <jstashluk> otavio: how do you get/create the GPU/VPU binary blob that yocto wants?
Dec 11 17:51:38 <otavio> jstashluk: what do you mean?
Dec 11 17:51:40 <jstashluk> Is it available now that i.MX6 is released?
Dec 11 17:51:47 <otavio> jstashluk: yes
Dec 11 17:51:56 <otavio> jstashluk: everything is there
Dec 11 17:52:05 <otavio> jstashluk: vpu, gpu and codecs
Dec 11 17:52:38 <jstashluk> otavio: I assume one must start from the master branch rather than denzil?
Dec 11 17:52:45 <otavio> jstashluk: yes
Dec 11 17:52:53 <otavio> jstashluk: denzil won't be updated for it
Dec 11 17:53:07 <otavio> jstashluk: we're about to branch the danny branch in the layer
Dec 11 17:53:19 <otavio> jstashluk: we just wish to finish some Qt issues we're looking at
Dec 11 17:53:31 <jstashluk> otavio: last time I checked there was a reference to a "freescale mirror".
Dec 11 17:53:47 <bluelightning> seebs: hey... do you by chance have a non-mangled version of this patch? http://www.eglibc.org/archives/patches/msg00671.html
Dec 11 17:53:48 <otavio> jstashluk: it is all in the mirror
Dec 11 17:53:55 <otavio> jstashluk: and also at ossystems mirror
Dec 11 17:54:09 <seebs> bluelightning: I probably do, actually.
Dec 11 17:54:21 <seebs> Since I think we had a local copy of it in our tree for a while.
Dec 11 17:54:27 <bluelightning> ah ok, cool
Dec 11 17:54:37 <seebs> If not, I can regenerate it easily enough.
Dec 11 17:54:58 <bluelightning> well, if you had to go to that length I can probably just carry on beating it into submission ;)
Dec 11 17:54:58 <seebs> Huh. Maybe I don't have one. I totally thought we were patching that in glibc for a while.
Dec 11 17:55:35 <bluelightning> I think we might end up applying this in our tree to fix bug 3551
Dec 11 17:55:36 <yocti> Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=3551 normal, Medium, 1.4, laurentiu.palcu, NEEDINFO , bitbake -c populate_sdk core-image-minimal fails due to missing dependency of bash
Dec 11 17:56:05 <seebs> I originally wrote the select replacement specifically for tzselect, because our small filesystem didn't have bash, and glibc was blowing up for us.
Dec 11 17:56:21 <seebs> I think actually our first pass was just to change it to /bin/sh and say "yeah, tzselect's broken, suck it up princess".
Dec 11 17:56:29 <seebs> ... I think the support reps may have altered the wording slightly from that.
Dec 11 17:56:33 <bluelightning> heh
Dec 11 17:56:38 <bluelightning> ok the patch now applies
Dec 11 17:56:40 <bluelightning> :)
Dec 11 17:57:26 <seebs> Okay. I have a copy of the message as it was originally sent, I think. Apparently I sent that out in September '08 originally.
Dec 11 17:57:55 <bluelightning> seebs: did you ever send it upstream in the end? I can't find reference to the title via google at least
Dec 11 17:57:58 <seebs> Heh. "As soon as I get things untangled a bit, I want to send in my beautiful, beautiful, tzselect patches."
Dec 11 17:58:29 <bluelightning> the issue came up more recently but they elected to just require /bin/bash
Dec 11 17:58:37 <seebs> I don't remember. I think that, back when I did this, the consensus was that if I tried to suggest that there was ever a reason not to use bash, Ulrich Drepper would show up at my house with a bunch of football hooligans.
Dec 11 17:58:52 <seebs> So I don't think I ever submitted it to upstream glibc.
Dec 11 17:58:52 <bluelightning> haha
Dec 11 17:59:11 <seebs> Thing is, if you don't know about the hack of replacing select, it SEEMS like it would be a huge amount of work to fix the script.
Dec 11 18:00:15 <seebs> Credit for the full form of that hack has to be shared with Gary V. Vaughan, who did the technical editing for my shell book.
Dec 11 18:00:20 <seebs> It was not as pretty when I started.
Dec 11 18:28:59 <sgw1> otavio: I am available for the bugzilla
Dec 11 18:29:27 <otavio> sgw1: so, can you make one "group" for us? meta-fsl-arm
Dec 11 18:31:13 <sgw1> otavio: yes, I see that there is a git.yoctoprojet.org/meta-fsl-arm also, is that the same one?
Dec 11 18:31:37 <sgw1> halstead: I am going to add a component for this to bugzilla
Dec 11 18:32:44 <otavio> sgw1: yes it is
Dec 11 18:34:18 <sgw1> perfect, thanks.
Dec 11 18:35:01 <sgw1> otavio: give me a minute or 5 to remember how to add it!
Dec 11 18:36:14 <sgw1> otavio: do you have a component description ?
Dec 11 18:36:52 * otavio check what has been included by ppc team
Dec 11 18:36:54 <sgw1> otavio: generically "Defects within the meta-fsl-arm (Freescale) BSP layers "
Dec 11 18:37:00 <pidge> otavio: If this is ready for the autobuilder, I can get it in. Have most of the target work done, just need the images you want produced and the git repo location.
Dec 11 18:37:00 <otavio> so we can be more or less in same wording
Dec 11 18:37:21 <sgw1> otavio: done!
Dec 11 18:37:52 <otavio> pidge: I need to fix the udev issue we have
Dec 11 18:37:58 <otavio> pidge: I am working on that
Dec 11 18:38:20 <otavio> pidge: currently we have a bbappend for udev and we need to get rid of it
Dec 11 18:38:30 <pidge> otavio: ok, well, when you're ready if you want ab support, it's easy to get in.
Dec 11 18:38:44 <otavio> pidge: sure; I will ask for it  really soon
Dec 11 18:39:29 <halstead> Thanks sgw1 I'll make sure it is mirrored to the Dev site.
Dec 11 18:39:43 <sgw1> halstead: thanks
Dec 11 18:44:06 <otavio> pidge: well, thinking better on it, I think we could add it in autobuilder ...
Dec 11 18:44:24 <otavio> pidge: it will fail to parse now ... and then will push pressure on us to fix it
Dec 11 18:44:31 <otavio> pidge: what do you think?
Dec 11 18:59:47 <Jartza> hallo
Dec 11 19:02:06 <Jartza> could someone help a beginner? :)
Dec 11 19:04:00 <Jartza> I have a imx53 board (our "own" hardware, not any starter kit etc) and I'm trying to figure out Yocto, but the learning curve is quite high
Dec 11 19:04:09 <Jartza> I followed instructions here: https://github.com/Freescale/fsl-community-bsp-platform
Dec 11 19:04:27 <Jartza> everything seems to compile ok, I get a lot of .deb -packages, but rootfs-creation fails
Dec 11 19:05:48 <Jartza> or actually, it works for core-image-minimal
Dec 11 19:06:19 <Jartza> but core-image-sato for example fails, the problems seems to be some dependency-problem.
Dec 11 19:07:31 <Jartza> xserver-nodm-init "is not going to be installed", but some x11 task depends on that
Dec 11 19:07:44 <Jartza> (I'm waiting for bitbake to finish again to get the full error)
Dec 11 19:09:53 <Jartza> | The following packages have unmet dependencies:
Dec 11 19:09:53 <Jartza> |   task-core-x11-base: Depends: xserver-nodm-init but it is not going to be installed
Dec 11 19:09:56 <Jartza> |                       Depends: xf86-video-imxfb but it is not going to be installed
Dec 11 19:09:59 <Jartza> | E: Broken packages
Dec 11 19:10:01 <Jartza> that's the error
Dec 11 19:10:20 <Jartza> how to solve this kind of problems?
Dec 11 19:12:40 <Jartza> or is core-image-sato broken for freescale?
Dec 11 20:57:36 <mSilVah> yocto noob here.  got it building a basic Linux image to the beagleboard.  Now i'm trying to find the recipe that builds the i686 (host) to ARM (target) cross compilers.  I want to see if I can get the cross compilers to support objective-c.
Dec 11 20:57:54 <mSilVah> how (or where) can i find the cross compiler recipe?
Dec 11 20:58:00 <rburton> "gcc-cross"
Dec 11 20:59:18 <mSilVah> thanks, i'll try to dig in.
Dec 11 20:59:58 <Jartza> hmm
Dec 11 21:00:49 <Jartza> I think I can live without X for a while, I'll just try the core-image on the device
Dec 11 21:01:04 <Jartza> I have to compile a custom kernel anyway, so that's a good starting piont
**** ENDING LOGGING AT Wed Dec 12 02:59:58 2012

**** BEGIN LOGGING AT Wed Dec 12 02:59:58 2012
Dec 12 08:25:59 <mckoan> good morning
Dec 12 09:38:57 <bluelightning> morning all
Dec 12 09:41:26 <JaMa> morning
Dec 12 10:31:37 <eballetbo> I can't access to the login with default core-image-sato. Any issue related to this ? OTOH with core-image-minimal works.
Dec 12 15:58:09 <gjohnson_> Good Morning, Once I have built the cross tools and sysroot can I just copy the build directory to other machines for use with cross compiling?
Dec 12 16:02:54 <bluelightning> gjohnson_: the way to handle that is to copy the sstate-cache directory to a shared location and then point to it from the other machines
Dec 12 16:03:07 <bluelightning> (point to it using SSTATE_MIRRORS I mean)
Dec 12 16:04:47 <bluelightning> (see the "Shared state" section of the reference manual)
Dec 12 16:05:20 <gjohnson_> bluelighting: Thanks for the information
Dec 12 16:05:24 <bluelightning> for the current release: http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#shared-state
Dec 12 16:07:30 <gjohnson_> bluelightning: I just want to figure out how to build on a nice 8 core machine but then use the build on my 2 core laptop.
Dec 12 16:10:14 <bluelightning> in that case you can just copy the sstate-cache from one machine to the other and you'll get the same result
Dec 12 16:10:44 <bluelightning> (you'd want to copy the conf/* directory under the build directory as well of course)
Dec 12 16:22:13 <Crofton|work> any clues on running webex in chrome on linux?
Dec 12 16:26:58 <davest1> Crofton|work: I'm running it on Chrome on Windows, it's a pain though because sometimes the browser setup is delecate
Dec 12 16:27:04 <davest1> delicate?
Dec 12 16:27:19 <Crofton|work> heh
Dec 12 16:27:21 <Crofton|work> googling
Dec 12 16:27:29 <Crofton|work> what is the date of the dev day?
Dec 12 16:29:54 <Crofton|work> I need to give up on webex on pay attention
Dec 12 16:30:11 <Crofton|work> davest, if that one guy on tehpanel didn't talk so much
Dec 12 16:31:54 <otavio> sgw1: Can you change meta-fsl-arm component description replacing ppc by arm?
Dec 12 17:06:18 <sgw1> otavio: Done
Dec 12 17:07:23 <otavio> sgw1: thx
Dec 12 17:15:50 <michael_e_brown> bluelightning, while getting things together to ask this intelligently, jason found that the issue was addressed in 1.3 apparently. we are backporting now to see if that fixes apr build for us.
Dec 12 17:20:42 <bluelightning> michael_e_brown: great!
Dec 12 19:11:37 <_Lucretia__> I keep getting a checksum mismatch on a git repo, how do I get the md5 or sha?
Dec 12 19:13:45 <JaMa> _Lucretia__: you're doing something wrong, SRC_URI checksums are not checked for git:// fetcher
Dec 12 19:14:12 <_Lucretia__> so why did it tell me to add one?
Dec 12 19:15:06 <_Lucretia__> ERROR: Fetcher failure for URL: 'http://git.scm.ada.cx/cgi-bin/cgit.cgi/common.git;protocol=git'. No checksum specified for /home/laguest/src/others/koparo/poky/gumstix-new/build/downloads/common.git, please add at least one to the recipe:
Dec 12 19:15:07 <_Lucretia__> SRC_URI[md5sum] = "3c2a0d1723bfa6875100dd8e3001a7b4"
Dec 12 19:15:07 <_Lucretia__> SRC_URI[sha256sum] = "9f163d16e513488f5c277933ee727a802489a3738507dea5afc7a6793ea42145"
Dec 12 19:15:40 <JaMa> because you're doing something wrong... in this case http:// in SRC_URI doesn't use git:// fetcher
Dec 12 19:16:14 <JaMa> you're probably downloading some HTML page from cgit and http:// fetcher is asking you to provide checksums for that
Dec 12 19:16:55 <JaMa> some bitbake versions should warn people when they try to use http://.*;protocol=git IIRC
Dec 12 19:18:04 <_Lucretia__> so you saying that you can't use http:// with git in yocto?
Dec 12 19:18:28 <JaMa> no, just that you should read some documentation
Dec 12 20:08:34 <seebs> argh
Dec 12 20:09:08 <seebs> laur, I believe there has been a misunderstanding. The "it's user error" policy I adopted for pseudo bug reports is intended to be a requirement on the reporter.
Dec 12 20:09:15 <seebs> Reporting something I actually have to *fix* is frowned upon.
Dec 12 20:12:32 <jstashluk> how do you set up SRC_URI for use with gitorious "git clone git@server:repository.git"?
Dec 12 20:34:00 <jstashluk> I've tried: git://git@dekaseemore.deka.local:linux-imx6.git
Dec 12 20:34:08 <jstashluk> with protocol=ssh and protocol=git
Dec 12 20:35:53 <JaMa> and?
Dec 12 20:41:18 <jstashluk> It tries to run a "git clone -s -n ..." from a local directory
Dec 12 20:45:35 <kergoth> it clones into the download directory from upstream, then clones from the download directory to S when unpacking, iirc
Dec 12 20:45:40 <kergoth> make sure you're looking at the right logs
Dec 12 20:50:20 <jstashluk> kergoth: I'm not sure if the unpack doesn't like the ':' in the URI?
Dec 12 20:59:04 <jstashluk> ssh: Could not resolve hostname /home/username/fsl-community-bsp/downloads//git2/server: Name or service not known
Dec 12 21:00:38 <jstashluk> If I run the "git clone" part with a 'file://' before the path, it works. Is there a way to get poky to figure this out?
Dec 12 21:22:51 <kergoth> jstashluk: ah yes, the : is a problem. use a / for that. let the fetcher translate the url syntax appropriately based on protocol=
Dec 12 21:27:23 <jstashluk> kergoth: protocol=git doesn't work, trying protcol=ssh....
Dec 12 21:32:49 <jstashluk> kergoth: protocol=ssh worked. Thanks!
Dec 12 21:45:39 <kergoth> the url scheme (git://) determines which git fetcher to use, and hence, what underlying tool to use. then protocol= controls the url passed to that tool
Dec 12 21:45:45 <kergoth> s/git fetcher/bitbake fetcher/
Dec 12 21:50:45 <PortaLu> where does the lib*.a stuff and includes get installed to?
Dec 12 21:54:36 <jstashluk> Is there a way to tell poky to leave a root fs around for NFS to pick up?
Dec 12 21:59:47 <sgw1> JaMa: you around?
Dec 12 22:00:25 <JaMa> y
Dec 12 22:01:23 <sgw1> Hi just saw your email, probably best to copy only if it exists. Are you building from clean tmp or a populated one with sstate?
Dec 12 22:01:38 <JaMa> clean
Dec 12 22:01:54 <sgw1> sstate?
Dec 12 22:02:06 <JaMa> clean tmp
Dec 12 22:02:59 <JaMa> and without sstate yes
Dec 12 22:03:15 <sgw1> So I am building in an existing tmp area with some things coming in from sstate and many things rebuild becuase of the change to autotools.
Dec 12 22:03:48 <sgw1> Maybe the check before copy will help, but I suggest you test in an existing build also.
Dec 12 22:04:20 <JaMa> but in your log it looks like source remove-*sin is missing
Dec 12 22:04:32 <JaMa> which doesn't make sense unless you're using different gettext-native
Dec 12 22:06:22 <JaMa> hmm maybe your build is using only gettext-minimal-0.18.1.1
Dec 12 22:06:28 <JaMa> where it's missing
Dec 12 22:06:45 <sgw1> JaMa: I will have to rebuild with your patch and let you know, yes it's gettext-minimal
Dec 12 22:07:55 <JaMa> mmt I'll send v2 with remove-*sin moved from gettext-native to gettext-minimal-native
Dec 12 22:08:34 <sgw1> JaMa: thanks
Dec 12 22:08:46 <otavio> jstashluk: you need to extract the tarball
Dec 12 22:08:53 <otavio> jstashluk: and then you can export it
Dec 12 22:10:34 <jstashluk> otavio: is there any tar magic for the /dev directory, etc? or do I just ignore the errors?
Dec 12 22:11:38 <otavio> jstashluk: you can use runqemu-extract-rootfs script
Dec 12 22:15:19 <otavio> bbl ... :)
Dec 12 22:26:15 <seebs> FWIW, I have a patch for the linkat() thing in pseudo. Assuming it tests out okay, I expect to make a 1.4.2 for that.
Dec 12 23:34:48 <JaMa> sgw1: I don't get your last reply on autotools.bbclass
Dec 12 23:40:05 <sgw1> JaMa: better commit message is needed as to why you are moving that file, I know you mention in the other commit, but needs to be mentioned there also.
Dec 12 23:46:13 <JaMa> ok
Dec 13 00:52:45 <scottrif1> halstead: ping
Dec 13 01:08:01 <halstead> scottrif1: pong.
Dec 13 01:08:48 <scottrif1> halstead: I am setting up .ssh on my new laptop in Belize
Dec 13 01:09:11 <scottrif1> halstead: can I just copy my .ssh folder from my desktop here and run with that?
Dec 13 01:09:20 <scottrif1> halstead: or do I need to generate a new key
Dec 13 01:11:48 <halstead> scottrif1: it's considered better for security to generate a new one. But coping it over will work.
Dec 13 01:13:21 <scottrif1> halstead: I can generate a new one if you tell me how
Dec 13 01:14:46 <halstead> Sure one sec.
Dec 13 01:18:29 <halstead> scottrif1: follow these https://wiki.yoctoproject.org/wiki/AccessingAutobuilders
Dec 13 01:19:05 <scottrif1> halstead: ok - will do
Dec 13 01:24:49 <scottrif1> halstead: the instructions are not too clear about the ssh-keygen command.  for "name@domain.tld" and HOSTNAME do I provide "scott.m.rifenbark@intel.com.tld"?  For HOSTNAME is that the name of my machine?
Dec 13 01:26:59 <halstead> Just your email no TLD.
Dec 13 01:28:02 <scottrif1> halstead: what about HOSTNAME?  Is that literal or specific to me?
Dec 13 01:31:21 <halstead> Scottrif1 that is what you named the laptop.
Dec 13 01:31:47 <scottrif1> halstead: it is named scott-lenovo
Dec 13 01:32:35 <scottrif1> halstead: this ssh-keygen gives me a prompt now wanting more input from the terminal
Dec 13 01:33:04 <halstead> scottrif1: that's a fine name. By naming all your keys trouble shooting later is easier.
Dec 13 01:33:40 <scottrif1> halstead: what about the ">" prompt in the shell now?
Dec 13 01:34:07 <halstead> scottrif1: to generate entropy? Or for a password?
Dec 13 01:34:48 <halstead> scottrif1: that looks like an unmatched quote.
Dec 13 01:34:50 <scottrif1> halstead: I don't know what generate entropy means... remember I am older than 50 :)  It is not asking for any password
Dec 13 01:35:00 <scottrif1> halstead: oh.. you are right :)
Dec 13 01:38:10 <scottrif1> halstead: ok - it is generated
Dec 13 01:39:38 <scottrif1> halstead: no create my .ssh/config file per the wiki?
Dec 13 01:39:52 <scottrif1> s/now/no'
Dec 13 01:39:53 <scottrif1> no
Dec 13 01:40:13 <scottrif1> halstead: not used to this keyboard
Dec 13 01:41:29 <halstead> scottrif1: send it to me via email and I'll install it shortly.
Dec 13 01:42:21 <scottrif1> halstead: what email?
Dec 13 01:42:43 <scottrif1> halstead: new machine... it didn't remember you
Dec 13 01:44:53 <halstead> Michael@Yocto project. Org
Dec 13 01:47:01 <scottrif1> halstead: sent
Dec 13 02:08:53 <ka6sox> halstead, we are moving the server power now...
Dec 13 02:08:59 <ka6sox> can't wait to get off that server ASAP
Dec 13 02:24:31 <halstead> ka6sox, Let me know if I can help.
Dec 13 02:26:05 <ka6sox> we just need to verify things got back up...
Dec 13 02:26:31 <ka6sox> we moved the back end switch and the dom0 that Opal runs on to a different power bus
Dec 13 02:26:54 <ka6sox> Opal is back up and the back end switch should be too.
**** ENDING LOGGING AT Thu Dec 13 02:59:58 2012

**** BEGIN LOGGING AT Thu Dec 13 02:59:58 2012
Dec 13 08:10:19 <JaMa> sgw1: I'm sorry, but are you sure that you have that autotools.bbclass patch in v2?
Dec 13 08:11:04 <JaMa> I've started another world build from scratch yesterday (this time with qemuarm) and it built bash fine (http://paste.debian.net/215940/)
Dec 13 08:11:43 <BjornArnelid> Good morning!
Dec 13 08:13:33 <mckoan> good morning
Dec 13 08:22:32 <BjornArnelid> Does anyone know how i go about compiling a systemtap kernel module for an Yocto image? Is there a way to tell stap to just compile the script?
Dec 13 08:53:33 <dany1> BjornArnelid: have a look at http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/tree/recipes-kernel/linux/linux-yocto_3.4.bbappend
Dec 13 08:53:33 <dany1> config fragments are under: files/
Dec 13 08:57:40 <Guest68187> hi, i am writing a recipe and I need librt in my sysroot for the installation step. I already tried to add eglibc to DEPENDS, but that did not help. Does anyone else know how to get librt added to the sysroot?
Dec 13 09:10:51 <bluelightning> morning all
Dec 13 09:19:08 <BjornArnelid> dany1: Thank you!
Dec 13 10:00:19 <lukas_> hi, i am writing a recipe and I need librt in my sysroot for the installation step. I already tried to add eglibc to DEPENDS, but that did not help. Does anyone else know how to get librt added to the sysroot?
Dec 13 10:09:55 <lukas_bulwahn> hi, i am writing a recipe and I need librt in my sysroot for the installation step. I already tried to add eglibc to DEPENDS, but that did not help. Does anyone else know how to get librt added to the sysroot?
Dec 13 10:20:52 <jackmitchell> lukas_bulwahn: hi lucas, I'm not a eglibc expert but I think that some features of it are set in distro policy
Dec 13 10:22:25 <jackmitchell> lukas_bulwahn: the eglibc recipe seems to have librt in it's "basepackage" config
Dec 13 10:22:30 <jackmitchell> so it seems as though it is being build
Dec 13 10:23:13 <BjornArnelid> dany1: Would i run stap -k on the target after including that or what do i need to do? Youre probably going to need to use small easy words with me.. :)
Dec 13 10:24:18 <dany1> BjornArnelid: Dont know the details about stap usage, haven't used it. Any Yocto specific question I'll gladly handle :)
Dec 13 10:24:58 <dany1> Hi All, has anyone taken a loo at python packaging automation stdeb/strpm/stopkg integration into bitbake, it seems cumersome to create python recipes manually, when most of the packaging information really could be autogenerated.
Dec 13 10:25:33 <rburton> dany1: isn't python packaging mostly a case of "import distutils"
Dec 13 10:25:50 <lukas_bulwahn> jackmitchell: but then it should be in the sysroot directory when i add eglibc to DEPENDS. When calling bitbake with -c devshell, i cannot find the librt files anywhere.
Dec 13 10:27:16 <dany1> rburton: Well, it make a neat little package, but some python eggs are split into subpackages, which distutils ignores, and puts everything in the same package afact.
Dec 13 10:28:19 <rburton> dany1: i've just kicked at the egg stuff - --single-version-externally-managed means it stops doing the egg stuff
Dec 13 10:28:29 <jackmitchell> lukas_bulwahn: it may be an egibc package
Dec 13 10:28:44 <jackmitchell> lukas_bulwahn: as I say i'm not fully in the know on eglibc
Dec 13 10:28:46 <rburton> dany1: as we're a package manager, we don't need eggs
Dec 13 10:28:59 <jackmitchell> lukas_bulwahn: you could possibly look in your tmo directory under glibc
Dec 13 10:29:07 <jackmitchell> s/glibc/eglibc
Dec 13 10:29:17 <rburton> lukas_bulwahn: my sysroot has librt, /data/poky-master/tmp/sysroots/atom-pc/lib/librt.so.1
Dec 13 10:29:19 <jackmitchell> and look in packages split and see if you can find it in there
Dec 13 10:30:25 <jackmitchell> lukas_bulwahn: I can confirm it is also in my armv7 sysroot too
Dec 13 10:31:13 <dany1> eggs or not, the manual work of splitting a python packages manually in the recipe, when the metadata could be automated might be something to look into.
Dec 13 10:35:20 <lukas_bulwahn> I see. my recipe searches in sysroot/x86_64-linux/, but not in sysroot/qemux86-64/ where librt is actually located. how do i have to modify the recipe to get these pathes right?
Dec 13 10:36:00 <rburton> lukas_bulwahn: your recipe is doing it wrong, by the sound of it.
Dec 13 10:36:09 <rburton> lukas_bulwahn: you might want to share the recipe and error
Dec 13 11:03:56 <lukas_bulwahn>  rburton: thanks for the hint. Due to business rules I first have to check some things before "distributing it", but then I can give more concrete pointers to my problem.
Dec 13 11:11:27 <eren> hello all
Dec 13 11:18:23 <eballetbo> hi all, have anyone build core-image-sato from scratch latest git tree and tried to log into via serial port ? I've problems to login with root account.
Dec 13 11:27:11 <bluelightning> eballetbo: is the serial port you're logging in via in /etc/securetty ?
Dec 13 11:30:06 <eballetbo> bluelightning: yes it is.  (ttyO2)
Dec 13 11:39:00 <bluelightning> eballetbo: are you using dropbear or openssh?
Dec 13 11:40:09 <eballetbo> bluelightning: I'm trying to access via serial console. I don't tried with openssh, let me test ...
Dec 13 11:40:40 <bluelightning> right, it would be worth verifying that you are able to log in as root via another channel
Dec 13 11:50:10 <eballetbo> bluelightning: I can't but seems I have a problem with rw permissions, don't worry. Thanks for the help
Dec 13 11:59:44 <bluelightning> eballetbo: np
Dec 13 12:01:42 <eren> i386 support has been removed from the latest kernel. I have KARCH=i386 in my kernel configuration now. Will it be changed with latest version of yocto kernel? Or, is it unrelated?
Dec 13 12:01:46 <eren> http://www.phoronix.com/scan.php?page=news_item&px=MTI0OTg
Dec 13 12:05:48 <bluelightning> well, we haven't yet updated to 3.8 (which is as yet unreleased)
Dec 13 12:08:00 <bluelightning> I'm not close enough to how our kernel config works to know if that will affect your setting
Dec 13 12:08:50 <eren> yeah, I'm fine with 3.4 right now
Dec 13 12:10:25 <bluelightning> is your machine actually an i386 or something newer?
Dec 13 12:10:33 <eren> it's i586
Dec 13 12:10:52 <eren> I only saw i386 in yocto-bsp, and i386 was the only available one that made sense
Dec 13 12:11:29 <bluelightning> ah ok... it could be that that means something different from the i386 machine support that has been removed then
Dec 13 12:13:36 <eren> I'm progressing with i386 setting from yocto-bsp then? I'm new to yocto kernel configuration, still reading docs
Dec 13 12:16:34 <eren> I couldn't find where *.scc files are within kernel :)
Dec 13 12:16:48 <eren> include cfg/boot-live.scc, include cfg/boot-live.scc etc
Dec 13 12:21:32 <bluelightning> eren: some of the configuration is in a separate git branch which is fetched at the same time
Dec 13 12:24:07 <eren> hm, I guess they are in: http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.4/tree/meta/cfg/kernel-cache/cfg?h=meta
Dec 13 12:29:45 <eren> oh no, it's in yocto-kernel-cache git repository
Dec 13 12:46:41 <eren> ok, so *.cfg files are created from *.scc
Dec 13 12:48:26 <eren> scc files have statements which include a specific configuration fragment e.g "cfg/vesafb.scc, cfg/fs/ext3.scc, features/crypto/crypto.scc"
Dec 13 12:49:28 <eren> I guess the statement "kconf hardware crownbay.cfg" produces this cfg file out of scc files (configuration fragments)
Dec 13 12:51:18 <eren> I also may be wrong, of course :)
Dec 13 13:40:46 <rburton> is there a chrpath that's configured for the host? a cross-chrpath if you will.
Dec 13 14:23:52 <likewise> gm all
Dec 13 15:35:44 <sgw1> otavio: you around?
Dec 13 16:12:20 <kergoth> Would anyone else find a class to do license-filtered sstate mirror population useful?
Dec 13 16:12:41 <kergoth> haven't written such a thing yet, just curious
Dec 13 16:50:39 <jstashluk> kergoth: that sounds interesting, this allows me to archive all of my sources, and review them by licence?
Dec 13 16:52:10 <kergoth> we already support it for sources. there's patterns you can specify in the metadata to control which licenses to include and which to exclude
Dec 13 16:52:17 <kergoth> copyleft_compliance class does that for a source mirror
Dec 13 16:52:22 <kergoth> but we don't have an equivalent for sstate
Dec 13 16:52:35 <kergoth> which means you could end up with sstate archives on your server without the corresponding sources on the source mirror
Dec 13 16:52:39 <kergoth> potential license concern there
Dec 13 16:53:55 <jstashluk> kergoth: thanks, can you point me to the relevant documentation for the source mirror stuff?
Dec 13 16:56:35 <kergoth> jstashluk: the variables that contrl it are documented in archiver.bbclass, around line 20. not sure if its in the proper docs or not
Dec 13 16:56:51 <kergoth> long term archive-*.bbclass will replace copyleft_compliance, so not much work is going into the latter
Dec 13 16:57:42 <jstashluk> kergoth: great, thanks!
Dec 13 17:00:00 <kergoth> jstashluk: so if you want to enable it, just INHERIT += "copyleft_compliance", optionally set the variables, then do a build and check deploy, there'll be a directory that looks like DL_DIR, but was filtered according to the vars
Dec 13 17:18:23 <jstashluk> kergoth: the INHERIT goes in local.conf?
Dec 13 17:19:20 <kergoth> that would work, sure
Dec 13 17:20:52 <jstashluk> kergoth: is it meant to go somewhere else? like the image recipe?
Dec 13 17:22:18 <kergoth> no, it must be int eh configuration metadata. it adds a new task for all the recipes
Dec 13 19:42:04 <mSILVa> noob question:  I am trying to make a recipe for a tool that is to be built only on the host.  I see how to build the tool for the target (IMAGE_INSTALL).  but how do I specify the recipe is for the host?
Dec 13 19:42:28 * mranostay pokes challinan 
Dec 13 20:06:01 <jstashluk> otavio: ping
Dec 13 20:08:50 <jstashluk> Does anyone know what package is supposed to provide the OpenGL EGL and GLES headers?
Dec 13 20:14:55 <jstashluk> I think I found it...
Dec 13 20:15:50 <rburton> jstashluk: depends on the machine
Dec 13 20:39:36 <otavio> jstashluk: Hi!
Dec 13 20:39:43 <otavio> jstashluk: depends on hw
Dec 13 20:39:57 <otavio> jstashluk: for imx6 it is the gpu-viv
Dec 13 20:40:42 <jstashluk> otavio: thanks, I found it.
Dec 13 20:41:05 <jstashluk> otavio: i should have gst-plugins-gl for you sometime soon...
Dec 13 20:48:43 <sgw1> otavio: you around?  We need to touch base on the meta-fsl-arm bugs
Dec 13 20:53:53 <JaMa> sgw1: btw I know about icu-50 patches, ChenQi sent me some v2, but for world build I decided to revert it instead, because world takes 20+ hours on garnet
Dec 13 20:54:06 <otavio> jstashluk: awesome!
Dec 13 20:54:11 <otavio> sgw1: Uh?
Dec 13 20:54:30 <sgw1> JaMa: Ok, he did not send me the v2 version, glad to know he is making progress
Dec 13 20:55:31 <sgw1> otavio: yeah, we triage the bugs to assign milestones and importance, I figured we needed your input on the meta-fsl-arm bugs that were just filed.
Dec 13 20:56:39 <otavio> sgw1: Ahh good
Dec 13 20:56:49 <otavio> sgw1: sure; you mean for 1.4
Dec 13 20:56:51 <otavio> ?
Dec 13 20:58:15 <sgw1> otavio: yes, if you look at the bugs we have 1.4 and 1.4 milestones, as well as setting the priority (high, med+, med, low)
Dec 13 21:25:39 <JimNH> Is there a way to run centos 6.3 built executables on yocto-denzil or danny; (or vice versa)?  I get  /lib/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory, trying to run a yocto danny executable on centos; I know I may need shlibs, but didnt expect elf to block me..
Dec 13 22:56:18 <RP> JimNH: that is a little surprising :/
Dec 13 22:58:18 <walters> JimNH, RP: it's because of multilib
Dec 13 22:59:04 <RP> this is a multilib configured build?
Dec 13 22:59:44 <RP> or you mean it should be using /lib64/ld-linux-x86-64.so.2 ?
Dec 13 23:02:05 <walters> to run 64 bit binaries on RHEL6, yes
Dec 13 23:02:14 <walters> gotta run
Dec 13 23:03:07 <RP> JimNH: symlink /lib64 to /lib and they'll probably work
Dec 14 00:25:07 <agherzan> Hello
Dec 14 00:25:32 <agherzan> Anybody with a new fresh build of poky master? (don't care what)
Dec 14 00:30:01 <agherzan> I need a ldd on the perl.real from sysroot (host).
Dec 14 01:16:23 <JimNH> RP <facepalm> thank you.. now its whining about the shlibs which I expected :)
Dec 14 01:43:59 <notespace> hello...
Dec 14 01:44:16 <notespace> is there an easy way to get gcc 4.5 compiling with danny?
Dec 14 01:47:02 <notespace> i am building for an omap3730, and the default gcc 4.7 results in a kernel hang, and 4.6 has USB issues on OMAP
Dec 14 01:48:19 <notespace> or has anyone used a codesourcery toolchain with danny?
Dec 14 02:13:22 <agherzan> sgw1, around?
Dec 14 02:18:22 <agherzan> sgw1, sent a patch to fix master. right now it fails while running native binaries (ex. perl).
Dec 14 02:18:56 <agherzan> this is because of this commit 50327f2bba9f479dd209cdc54646b9d551e84c59
Dec 14 02:19:15 <agherzan> sgw1, hope to have it soon merged
Dec 14 02:47:51 <lostincake> harro
Dec 14 02:48:24 <lostincake> I'm using yocto with my gumstix and a caspa camera. So far I have an image compiled with TI modules and gstreamer and such and everything loads / runs fine.
Dec 14 02:48:38 <lostincake> The issue comes when I try to access the caspa camera, which usually sits at /dev/video0
Dec 14 02:49:30 <lostincake> the gstreamer output is here: http://pastebin.com/jgtWJp5D
Dec 14 02:49:37 <lostincake> anyone have any ideas?
Dec 14 02:49:58 <lostincake> if I look at my /dev folder, there are like 6 video entries, which is weird... never seen that before
Dec 14 02:50:08 <lostincake> (i.e. I have a /dev/video0, /dev/video1, etc.)
Dec 14 02:53:54 <sgw1> agherzan: timing is!! guess what I was working on this afternoon!  I have the exact same patch, but with a comment.
**** ENDING LOGGING AT Fri Dec 14 02:59:35 2012

**** BEGIN LOGGING AT Fri Dec 14 03:00:19 2012
Dec 14 03:31:04 <lostincake> any ideas? anyone?
Dec 14 04:10:29 <notespace> did you try all of the other /dev/video devices? look in dmesg to see where the camera comes in?
Dec 14 04:10:53 <notespace> maybe look into some custom udev rules?
Dec 14 04:14:40 <notespace> lostincake: maybe you could look in /sys for some camera-related entries for that driver?
Dec 14 04:49:08 <seebs> Who gets requests to add new tarballs to the distribution servers these days? I have a pseudo 1.4.2 (addresses Yocto bug #3500).
Dec 14 04:49:09 <yocti> Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=3500 normal, Medium, 1.4, laurentiu.palcu, WaitForUpstream , Host user not recognized when building meta-toolchain-sdk
Dec 14 05:54:33 <seebs> Got a pseudo change mostly ready, but a heads up: The computation of $(LIB) is "improved", and that actually does mostly work, but it does require a tweak to the recipe, which was relying on what turned out to be a bug.
Dec 14 06:25:28 <lostincake> notespace, you think it's permission problems?
Dec 14 06:25:31 <lostincake> cause I'm running as root
Dec 14 06:25:42 <lostincake> shuldn't that override w/e permissions?
Dec 14 06:25:43 <notespace> hey
Dec 14 06:25:58 <notespace> no, I don't think it's a permissions prob
Dec 14 06:26:18 <notespace> it sounds like its just coming up as a different device than /dev/video0
Dec 14 06:26:45 <notespace> i'm not very familiar with the v4l2 setup, but you could look through dmesg for some clues
Dec 14 06:28:42 <lostincake> hmm
Dec 14 06:28:59 <lostincake> it's recognizing the right sensor
Dec 14 06:29:27 <lostincake> but maybe I need to use the modules from gumstix themselves
Dec 14 06:36:44 <notespace> if you rmmod the module, do any of the /dev/video* modules go away?
Dec 14 06:38:32 <notespace> er /dev/video files
Dec 14 06:39:06 <notespace> also, vice versa, when you insmod, does anything appear... or any trace from dmesg?
Dec 14 06:52:09 <lostincake> hmm.. module is apparently in use... what the hell... force removing it also fails
Dec 14 07:06:26 <notespace> good luck , sorry i g2g...
Dec 14 07:07:20 <lostincake> thanks much anyway, willdigg around more
Dec 14 07:45:56 <iwamatsu> hi, I have a problem by fixup_perms  (http://pastebin.com/QxSSvPxd)
Dec 14 07:46:22 <iwamatsu> please teach me how I fix this.
Dec 14 07:47:15 <iwamatsu> I am using poky/HEAD and meta-openembedded/HEAD. MACHINE is set beagleboard.
Dec 14 09:08:57 <bluelightning> morning all
Dec 14 10:16:07 <agherzan> sgw1, i will take a loot on those other broken locations - indeed frustrating - spent o a lot of time on this ...
Dec 14 10:56:28 <BjornArnelid> Hi, still having problem with systemtap running the command stap -r /path/to/yocto-fs/lib/modules/3.2.11-yocto-standard hello-world.stp -m Hello results in ERROR: kernel release isn't found in "path/to/yocto-fs/lib/modules/3.2.11-yocto-standard"
Dec 14 10:57:06 <BjornArnelid> should not the Yocto kernel module be in that directory?
Dec 14 12:34:02 <BjornArnelid> Does anyone know where the  kernel cross-compilation directory would be located on the build server? Somewhere in the build directory i would assume?
Dec 14 12:38:44 <ant_work> Yes, in  build/tmp-eglibc/YOURMACHINE*/linux-yocto/
Dec 14 12:39:01 <ant_work> or alike
Dec 14 12:39:25 <BjornArnelid> Ill try that, great thanks!
Dec 14 12:40:05 <ant_work> I'm not on host, can't be precise
Dec 14 12:40:15 <ant_work> is under /work/yourmachine
Dec 14 12:42:07 <ant_work> pl try this:  oe/oe-core/build/tmp-eglibc/work/MACHINE-oe-linux-gnueabi/linux-yocto-3.4/
Dec 14 12:42:08 <BjornArnelid> could this be it? build-qemuppc/tmp/work/qemuppc-enea-linux/linux-yocto-3.2.11+git1+b14a08f5c7b469a5077c10942f4e1aec171faa9d_1+92de4e2f3c6b397c8b363e079cc4d5e9bcadf877-r1
Dec 14 12:42:26 <ant_work> yup
Dec 14 12:54:53 <BjornArnelid> could not find any oe directory
Dec 14 13:10:41 <ant_work> BjornArnelid: that was just one example
Dec 14 13:11:27 <ant_work> you're there :)
Dec 14 13:12:29 <BjornArnelid> yes im here
Dec 14 13:15:46 <ant_work> have you found the kernel tree inside that dir?
Dec 14 13:16:15 <BjornArnelid> Im just hopelessly lost in the build directory. is there a file i could do as find for to find the directory?
Dec 14 13:16:41 <ant_work> it's the link you gave me
Dec 14 13:17:03 <ant_work> s/link/path/
Dec 14 13:19:26 <BjornArnelid> Strange - systemtap does not recognise it
Dec 14 14:18:14 <BjornArnelid> I was able to look at the crosstap script and figure out how to do it, thanks for all help!
Dec 14 14:45:50 <gjohnson_> Good Morning,  How do I find out what packages are created when I bitbake, for example bitbake rpi-basic-image vs rpi-hwup-image?
Dec 14 14:46:54 <jstashluk> gjohnson_: bitbake-layers show-recipes
Dec 14 14:47:12 <gjohnson_> jstashluk: Thanks!
Dec 14 14:48:34 <bluelightning> I don't think that's really going to answer the question
Dec 14 14:49:01 <bluelightning> you can't really determine the full list of packages in the final image until the image is actually built
Dec 14 14:49:45 <bluelightning> you can get a list of the recipes that are going to be built however using bitbake -g <target>
Dec 14 14:49:57 <bluelightning> then look at pn-buildlist
Dec 14 14:50:37 <gjohnson_> bluelightning:  ok, I will try that.  So I will be able to see the packages built but that won't mean that all of those packages will be installed in the image?
Dec 14 14:50:58 <bluelightning> that will tell you the recipes that are going to be built, but not the runtime packages
Dec 14 14:51:34 <jstashluk> gjohnson_: sorry, i thinkg bluelightning is right
Dec 14 14:51:59 <bluelightning> not all of the packages produced from the recipes will be installed that is correct
Dec 14 14:52:55 <gjohnson_> bluelightning: pn-buildlist is what I was looking for, thanks.
Dec 14 14:55:00 <jstashluk> gjohnson_: you may want to read about the bitbake '-g, --graphviz' option
Dec 14 14:55:58 <kergoth> jstashluk: that's what bluelightning just told him to use :)
Dec 14 14:56:01 * kergoth yawns
Dec 14 14:56:40 <gjohnson_> jstashluk: thanks for the message anyways
Dec 14 14:57:56 <jstashluk> kergoth: it must be coffee time.
Dec 14 15:02:08 <gjohnson_> If I wan't to figure out how to modify the target packages that are built and installed will I find that information in the BSP Developer's Guide?
Dec 14 15:04:32 <bluelightning> gjohnson_: not really - it's pretty simple
Dec 14 15:04:45 <bluelightning> gjohnson_: whatever the image sets IMAGE_INSTALL to determines what gets installed
Dec 14 15:05:08 <kergoth> jstashluk: indeed
Dec 14 15:05:18 <bluelightning> (plus whatever is needed to satisfy dependencies of what is in IMAGE_INSTALL, of course)
Dec 14 15:06:23 <gjohnson_> where is IMAGE_INSTALL set?
Dec 14 15:09:55 <bluelightning> gjohnson_: in whatever image recipe you build
Dec 14 15:11:30 <gjohnson_> bluelightning: I think I found it.
Dec 14 15:12:12 <bluelightning> FYI, if you're not sure where to look for a recipe you can use: bitbake -e recipename | grep "^FILE="
Dec 14 15:13:19 <gjohnson_> bluelightning: so how do change what packages will be built?
Dec 14 15:13:59 <bluelightning> that's determined by working back from whatever is specified in IMAGE_INSTALL
Dec 14 15:14:18 <bluelightning> you can trim things down by changing the build-time configuration of some recipes (to disable features)
Dec 14 15:14:37 <gjohnson_> bluelightning: k, that is what I thought might be the case.
Dec 14 15:14:38 <bluelightning> some of these can be controlled by setting DISTRO_FEATURES
Dec 14 15:16:27 <gjohnson_> is using BBMASK also good for helping trim things down?
Dec 14 15:19:14 <rburton> BBMASK is a bit heavy-handed - DISTRO_FEATURES is a good place to start
Dec 14 15:19:17 <bluelightning> not really, BBMASK is a very blunt instrument, it just tells bitbake not to parse certain files
Dec 14 15:19:42 <rburton> otherwise you'll mask out stuff like ALSA, but still be attempting to build stuff that depends on alsa (and that will fail)
Dec 14 15:19:51 <bluelightning> indeed
Dec 14 17:26:16 <mSILVa> can anyone point me to a good resource to help debug an issue w/ porting an open source project into yocto?  it's auto tools based, but fails in:
Dec 14 17:26:17 <mSILVa> config/objc-con-autoload.m4:1: error: AC_LANG_COMPILER: unknown language: _AC_LANG
Dec 14 17:35:52 <fray> If this is an objective c app, I don't believe anyone has enable that compiler..
Dec 14 17:36:20 <fray> as far as a resource though, I'm really not sure.  I know most people just pick up auto tools over time dealing with problems like this..
Dec 14 17:36:33 <fray> (there are some good o'reily books on auto tools..)
Dec 14 17:37:16 <mSILVa> thanks.  i tried enabling objc. i edited gcc-configure-common.inc and added objc and obj-c++ to the LANGUAGES definition.
Dec 14 17:37:54 <fray> Khem is the one who is the toolchain maintainer.. he might have some pointers on that part..
Dec 14 17:38:00 <fray> but I doubt it's well tested in OE.. sorry
Dec 14 17:39:04 <mSILVa> thanks
Dec 14 18:01:16 <rburton> would be useful if objc/ada/etc were easy to enable
Dec 14 18:01:26 <rburton> a few people have wanted to enable "other" languages and had trouble
Dec 14 18:06:57 <fray> rburton ya, there are definitely folks who need it... but it'll take someone to invest the time to enable it and maintain it
Dec 14 18:07:55 <rburton> sure
Dec 14 18:08:23 <fray> I also get confused at requests for Fortran on embedded systems.. then I find they're being used in industrial automation..
Dec 14 18:08:48 <rburton> i'm confused by obj-c :)
Dec 14 18:09:35 <fray> I'm amazed that industrial processes coded in Fortran 30 years ago are still being used "unmodified" on new devices..
Dec 14 18:09:52 <fray> (or at least that is the intent)
Dec 14 19:23:03 <jstashluk> I want to use gst-plugins.inc from poky/meta/recipes-multimedia/gstreamer/ in a different layer. How should I do that?
Dec 14 19:23:56 <jstashluk> My recipe is in meta-fsl-arm/recipes-multimedia/gstreamer/recipe.bb
Dec 14 19:28:35 <ftonello> I'm getting this in my distro (based on poky)
Dec 14 19:28:39 <ftonello> ERROR: Unable to parse poky-sanity: ParseError in configuration INHERITs: Could not inherit file classes/poky-sanity.bbclass
Dec 14 19:29:07 <ftonello> and its because of INHERIT += "poky-sanity"
Dec 14 19:29:51 <ftonello> ok, i found out
Dec 14 19:32:17 <JaMa> jstashluk: include/require it with path relative to layer root
Dec 14 19:32:50 <JaMa> jstashluk: "require recipes-multimedia/gstreamer/gst-plugins.inc"
Dec 14 20:18:22 <jstashluk> I have a recipe for gst-plugins-gl where should I try to put it? poky or meta-fsl-arm?
Dec 14 22:39:19 <ftonello> how do I make a recipe that will always rebuild a program based on the last commit?
Dec 14 22:40:03 <ftonello> i know that if I use ${AUTOREV} it selects the last commit, but I would like to see some kind of way to check if there is a new commit and redo all the process of a recipe
Dec 14 22:40:26 <ftonello> similar to add a new recipe with a new version
Dec 14 22:40:32 <ftonello> is it possible?
Dec 14 22:59:37 <kergoth> ftonello: that's what autorev is for. it sounds like you set srcrev to autorev but forgot to put srcpv in PV
Dec 14 23:00:10 <kergoth> hmm, might also need to set the srcrev policy to clear, but i think thats default
Dec 15 00:06:41 <seebs> If there was a response previously, I missed it: If I want to upload a new pseudo tarball, how do I do it or whom do I ask?
Dec 15 00:08:58 <fray> you need to find Beth
Dec 15 00:17:07 <seebs> Hmm. I have her email address from a few months ago; should that have changed?
Dec 15 00:17:14 <fray> nope
Dec 15 01:24:35 <_Lucretia_> hi, I'm trying to add a patch to my meta-ada/recipes-devtools/gcc/file but it's failing to "download"
Dec 15 01:25:17 <_Lucretia_> I added it with the following line inside my gcc-cross_4.6.bbappend SRC_URI += "file://arm-linux-gnat.patch"
Dec 15 01:25:22 <_Lucretia_> what am I doing wrong?>
Dec 15 01:25:38 <fray> your bbappend needs to include the path to your patches..
Dec 15 01:25:39 <seebs> Where did you put that file?
Dec 15 01:26:13 <fray> example:
Dec 15 01:26:14 <fray> http://git.yoctoproject.org/cgit/cgit.cgi/meta-selinux/tree/recipes-core/initscripts/initscripts_1.0.bbappend
Dec 15 01:26:16 <_Lucretia_> fray: erm, must've missed that bit, ?
Dec 15 01:26:23 <fray> you need to specify the FILESEXTRAPATHS_prepend
Dec 15 01:26:39 <fray> http://git.yoctoproject.org/cgit/cgit.cgi/meta-selinux/tree/recipes-core/util-linux/util-linux_2.22.1.bbappend
Dec 15 01:26:44 <fray> better example
Dec 15 01:27:09 <_Lucretia_> still fails
Dec 15 01:28:17 <fray> use bitbake -e <recipe>  look for the FILESEXTRAPATHS and see if it includes the path to your patch or not
Dec 15 01:29:30 <_Lucretia_> FILESEXTRAPATHS_prepend := "${THISDIR}/file:" <- no s
Dec 15 01:29:44 <fray> you need the space.. no :"
Dec 15 01:29:59 <fray> I THINK this one is space separated.. but I may be wrong
Dec 15 01:30:15 <fray> no I'm wrong
Dec 15 01:30:23 <fray> it's : separated like what you have
Dec 15 01:30:45 <_Lucretia_> yay thanks
Dec 15 01:31:06 <_Lucretia_> nope, the above, no s
Dec 15 01:31:15 <_Lucretia_> it's patched it
**** ENDING LOGGING AT Sat Dec 15 02:59:58 2012

**** BEGIN LOGGING AT Sat Dec 15 02:59:58 2012
Dec 15 05:15:32 <Daemon404> [A7
Dec 16 00:25:16 <ka6sox-away> is git.yoctoproject.org down for some reason?
Dec 16 00:25:37 <Daemon404> ka6sox-away, looks up from here
Dec 16 00:26:10 <ka6sox-away> rats
Dec 16 00:58:41 <mranostay> ka6sox-away: your tube is broken
Dec 16 01:11:19 <ka6sox-away> yes, it appears to be so
Dec 16 01:21:49 <mranostay> works for as well
Dec 16 01:21:52 <mranostay> *me
**** ENDING LOGGING AT Sun Dec 16 02:59:58 2012

**** BEGIN LOGGING AT Sun Dec 16 02:59:58 2012
Dec 16 20:50:21 <ericben> are you aware of bandwidht problem on git.yoctoproject.org ? git clone is down to around a few KiB/s here ...
Dec 16 21:03:39 <mbroadst> I apologize if this the wrong place for this question, but does anyone here know how to tell bitbake to retry (infinitely, or a certain number of times) to fetch from a repo before stopping the build? It seems that it tries once, if that fails it looks for mirrors, and if that fails it just stops the whole build
Dec 16 21:16:25 <ericben> mbroadst: retrying the fetch : I'm not sure that's possible, not breaking the whole build if one task fails : bitbake -k
Dec 16 21:17:05 <ericben> mbroadst: -k, --continue        continue as much as possible after an error. While the target that failed, and those that depend on it, cannot be remade, the other dependencies of these targets can be processed all the same
Dec 16 21:20:31 <mbroadst> ah yeah, we have that enabled, but these git/svn checkouts failing are really killing me
Dec 16 21:20:47 <mbroadst> you can't just walk away from a build, and github seems to have issues checking out all the time
Dec 16 21:20:48 <mbroadst> :)
Dec 16 21:39:05 <ericben> mbroadst: here I get a very low bandwidth from git.yoctoproject.org (despite a good download bandwidth) so the user experience for a build from scratch for qemu is quite bad as cloning linux-yocto takes several hours :-(
**** ENDING LOGGING AT Mon Dec 17 02:59:58 2012

**** BEGIN LOGGING AT Mon Dec 17 02:59:58 2012
Dec 17 08:20:31 <mckoan> good morning
Dec 17 12:08:57 <dany1> rburton: Hi, yuo previously said you kicked at the distutils stuff with: --single-version-externally-managed, where can I find this ?
Dec 17 12:09:54 <rburton> dany1: just sent a patch to oe-devel actually, for python-mako.  need to work out how to do that in a class.
Dec 17 12:32:34 <BjornArnelid> Does anyone know if oprofileui is an abandoned project or if there is any development/bugfixing going on there?
Dec 17 12:33:59 <rburton> mostly abandoned
Dec 17 12:34:01 <rburton> use perf
Dec 17 12:34:21 <rburton> BjornArnelid: git never lies: http://git.yoctoproject.org/cgit.cgi/oprofileui/
Dec 17 12:35:13 <dany1> rburton: OK, I get a feeling that the current state of distutils* needs improvement, since most of the packaging metadata is already available in setuptools. We should be able to automate alot of this in bitbake via an improved distutils bbclass setup.
Dec 17 12:36:42 <rburton> dany1: the layer of classes does seem a bit overkill
Dec 17 12:41:22 <dv_> I like how yocto displays the list of currently running tasks, and how it expands and shrinks. any idea on how this is done? is bitbake using ncurses for this?
Dec 17 12:42:04 <rburton> dv_: yes, curses
Dec 17 12:42:26 <dv_> is this a yocto specific patch? i dont remember bitbake doing that originally
Dec 17 12:42:31 <rburton> dv_: it does not
Dec 17 12:42:34 <rburton> "now"
Dec 17 12:43:09 <rburton> commit b97d50618b2187bcfd7d25f64d1444482ca62ef7
Dec 17 12:43:11 <rburton> Author: Richard Purdie <richard.purdie@linuxfoundation.org>
Dec 17 12:43:13 <rburton> Date:   Wed Aug 15 17:50:22 2012 +0100
Dec 17 12:43:17 <rburton>     knotty: Fold knotty2 into knotty and make it the default
Dec 17 12:45:48 <BjornArnelid> rburton: thanks for the reply
Dec 17 12:48:47 <rburton> BjornArnelid: afaik it should still work though
Dec 17 12:49:20 <rburton> if you know a good client/server profiling ui that's maintained we can swap
Dec 17 12:49:25 <rburton> or you can adopt it :)
Dec 17 12:54:39 <BjornArnelid> rburton: It seems to work ok, though i was getting alot of missing dependencies when i tried to build.
Dec 17 12:55:08 <rburton> huh
Dec 17 12:55:17 <rburton> BjornArnelid: feel free to file bugs, it should still work
Dec 17 12:55:31 <BjornArnelid> And im not able to get any data out of it, but that is probably due to me not knowing what im doing :)
Dec 17 12:56:07 <rburton> heh
Dec 17 12:56:11 <rburton> maybe oprofile changed :/
Dec 17 12:57:18 <BjornArnelid> Maybe - ill file a bug about the dependencies.
Dec 17 13:06:10 <rburton> BjornArnelid: cc me pls, ross.burton@intel.com
Dec 17 13:15:05 <ericben> hi rburton about python : On denzil, when updating pyserial to 2.6, I get : 'error: option --single-version-externally-managed not recognized ERROR: python setup.py install execution failed.' at do_install. Is it the same problem you fixed in python-mako ?
Dec 17 13:16:12 <rburton> ericben: no
Dec 17 13:16:22 <ericben> rburton: ok no luck ;)
Dec 17 13:16:41 <rburton> ericben: that option only exists for setuptools so maybe they stopped using that?
Dec 17 13:18:05 <ericben> rburton: I didn't see the change in setup.py. From memory by hacking setup.py I managed to get install working. I'll prepare a patch to get comments
Dec 17 13:20:55 <subodh> noob on yocto here
Dec 17 13:21:01 <ericben> rburton: you're right http://pastebin.com/UDMPN1MS I'm not experienced in python : what is the best way to workaround this ?
Dec 17 13:22:04 <rburton> ericben: just drop --single-version... and see what the install layout is like. that option drops the "egg" packaging which setuptools does and distutils doesn't.
Dec 17 13:22:12 <ericben> rburton: just did that ;)
Dec 17 13:22:13 <rburton> i endorse buildhistory here
Dec 17 13:24:40 <ericben> rburton: stupid me, now I understand. I need to switch inherit setuptools to inherit distutils , thanks for telling "that option only exists for setuptools so maybe they stopped using that" ;-)
Dec 17 13:25:33 <ericben> when I say "I'm not experienced in python" that's quite true as you can see ;-)
Dec 17 13:25:42 <rburton> :)
Dec 17 13:33:18 <subodh> trying to add my hello (under meta-subodh), created hellosubodh.c, LICENSE file. bitbake throws up error saying it can't find LICENCE file. Under build/tmp/work/...../hello directory, I see hellosubodh.c, but no LICENCE file. My debug output is at http://pastebin.com/4GPsvb7W  and my .bb file is at http://pastebin.com/iq7XANGk Can some one here help me? Or am I in wrong place? Thanks a bunch on a beautiful Monday morning ;-)
Dec 17 13:34:57 <rburton> subodh: the LIC_FILES_CHKSUM normally points at files in the tarball
Dec 17 13:35:31 <rburton> as you only have a source file, it's easiest to point it at the source file and add an in-line license
Dec 17 13:35:40 <rburton> alternatively, you need to add LICENSE to the SRC_URI
Dec 17 13:35:53 <subodh> Great..
Dec 17 13:35:56 <ericben> subodh: if you want MIT then you can do LICENSE = "MIT" and LIC_FILES_CHKSUM = "file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58"
Dec 17 13:36:27 <subodh> Wonderful. :-)
Dec 17 13:37:56 <rburton> isn't that not the point?  LICENSE says the license of the source, and LIC_FILES_CHKSUM is the sanitycheck
Dec 17 13:38:06 <rburton> so pointing it at the top-level meta-data license doesn't really sanity check it
Dec 17 13:39:03 <rburton> you want to checksum the license of the source, so either ship the license (add to src_uri) or inline the license in a comment (and use the options to just checksum the comment)
Dec 17 13:39:15 <ericben> rburton: many recipe needing MIT are doing this way
Dec 17 13:39:25 <ericben> rburton: no idea if that's right
Dec 17 13:39:30 <rburton> sounds wrong to me
Dec 17 13:40:02 <rburton> ericben: that's fine for a metapackage
Dec 17 13:40:19 <ericben> even in openembedded-core some recipes have that (grep -rn 3f40d7994397109285ec7b81fdeb3b58 . | wc -l -> 22)
Dec 17 13:40:34 <ericben> understood
Dec 17 13:40:55 <subodh> ericben and rburton thanks a bunch for educating me :-)
Dec 17 13:41:21 <ericben> subodh: you should better choose what rburton said
Dec 17 13:41:25 <rburton> ericben: most of which are images or packagegroups
Dec 17 13:41:28 <rburton> the rest are Wrong
Dec 17 13:41:52 <ericben> rburton: after reading COREBASE/LICENSE I agree totally that's not a MIT license file
Dec 17 13:41:59 <subodh> ericben thanks will choose rburton's approach
Dec 17 13:42:37 * rburton will make a note to validate everything that cites that file
Dec 17 13:44:56 <subodh> ericben and rburton I added LICENCE file to SRC_URI and that worked.
Dec 17 13:45:08 <rburton> good stuff
Dec 17 13:45:50 <subodh> So, my next question (while this image is compiling) how do I deal with complex code (mulitple directory structures etc?) or a tarball like you refered to?
Dec 17 13:47:11 <subodh> sorry.. monkeyed my keyboard in a hurry.. so I may have missed eric/rburton's response
Dec 17 13:47:42 <rburton> subodh: if you have a tarball, you'd have a license file inside that tarball
Dec 17 13:48:24 <rburton> i tend to checksum the top-level license and a selected in-source license comment just to make sure
Dec 17 13:48:31 <subodh> so, if SRC_URI points to a tarball, do_configure will copy, unzip it in the right place? And if SRC_URI points to a directory then do_configure will cp -r on that?
Dec 17 13:48:53 <rburton> never tried src_uri on a directory
Dec 17 13:49:18 <subodh> rburton.. thanks. will stick with tarballs :-)
Dec 17 13:49:25 <rburton> but the task that runs before do_configure will extract it
Dec 17 13:50:01 <subodh> I see..
Dec 17 15:36:22 <jstashluk> otavio: ping
Dec 17 15:38:31 <otavio> jstashluk: pong
Dec 17 16:02:45 <ericben> is debian 6.0.6 a distribution tested for yocto 1.3 danny release ?
Dec 17 16:04:35 <rburton> ericben: yes
Dec 17 16:05:53 <ericben> rburton: OK strange, then. I managed to build danny but when installing adt_installer I found that autoconf and libtool were not installed (I followed the instructions in the quickstart in the packages section and took the line for Ubuntu) and thus adt_install was failing.
Dec 17 16:06:30 <rburton> never tried the adt, sounds like you should file a bug
Dec 17 16:07:02 <ericben> I'm taking time to read the manual and discover things I never used before with OE and chose to install a VM with a light robust distro so I chose debian
Dec 17 16:09:49 <rburton> why did adt_installer fail with libtool missing?
Dec 17 16:58:28 <ericben> rburton: don't know but the doc says "The ADT Installer requires the libtool package to complete. If you install the recommended packages as described in "The Packages" section of the Yocto Project Quick Start, then you will have libtool installed" and that's not true when using a bare debian 6.0.6 (LXDE live version used as the base system in my case)
Dec 17 16:59:04 <rburton> ericben: heh.  please file a docs bug :)
Dec 17 17:16:23 <ericben> rburton: I put that on the todo list for the end of this week
Dec 17 17:19:37 <JaMa> rburton: is fix for gst-openmax somewhere in your queue?
Dec 17 17:19:49 <rburton> JaMa: actually, testing it now
Dec 17 17:19:59 <rburton> JaMa: turns out the real fix is "don't use that, use gst-omx"
Dec 17 17:20:02 <JaMa> great, thanks
Dec 17 17:22:54 <rburton> JaMa: sent
Dec 17 17:34:49 <ericben> anyone using ADT here ?
Dec 17 17:34:56 <ericben> with eclipse plugin.
Dec 17 17:35:33 <ericben> I follow the manual. adt install is OK, eclipe plugin seems OK, project "Hello World ANSI C Autotools Project" created fine
Dec 17 17:35:52 <ericben> then "Select Project -> Reconfigure Project" : this menu doesn't exist here ...
Dec 17 17:36:21 <ericben> " Project -> Build Project" : fails with configure: error: C compiler cannot create executable
Dec 17 17:36:24 <ericben> target is qemuarm
Dec 17 17:38:00 <halstead> jzhang, Do you happen to know about ericben's question above?
Dec 17 17:40:56 <ericben> hi jzhang bascialy I followed http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#application-development-workflow
Dec 17 17:52:26 <jzhang> ericben: so which version of eclipse you're using? 1.3? if so, there's some menu changes in upstream cdt, so if you bring up the project Yocto setting, the toolchain and sysroot are the correct ones that you want to use?
Dec 17 17:53:05 <ericben> jzhang: eclipe : 4.2.1 (juno I think)
Dec 17 17:53:15 <ericben> jzhang: yocto : danny branch
Dec 17 17:53:24 <ericben> jzhang: eclipse plugin : 1.3
Dec 17 17:53:50 <jzhang> ok, so can you tell me your project toolchain and sysroot location?
Dec 17 17:53:54 <ericben> jzhang: I created adt-installer and it installed fine in /opt/poky
Dec 17 17:54:38 <ericben> jzhang: ok : toolchain root location : /opt/poky/1.3 - sysroot location : /opt/poky/1.3/sysroot/i686-pokysdk-linux (not sure of this one)
Dec 17 17:55:16 <ericben> adt created ~/test-yocto/arm and ~/test-yocto/arm.pseudo_state
Dec 17 17:56:22 <scottrif> halstead: ping
Dec 17 17:56:34 <halstead> scottrif, pong.
Dec 17 17:57:21 <ericben> jzhang: and for target option I have Kernel : ~/adt-installer/download_image/zImage-qemuarm.bin , and no custom option for Qemu
Dec 17 17:57:50 <jzhang> ecricben: if you use adt-installer, the sysroot should be the location where you extract your target rootfs, the default should be $HOME/test-yocto/arm, you are pointing your sysroot to the host setting, which is wrong, after change that, rigth click on the project you should see a reconfigure option
Dec 17 17:59:00 <ericben> jzhang: OK you're right, right click has the reconfigure option (but not menu Project as stated in the doc)
Dec 17 17:59:23 <ericben> jzhang: but it still fails on "C compiler cannot create executables"
Dec 17 17:59:54 <rburton> C compilers are over-rated
Dec 17 17:59:56 * rburton runs
Dec 17 18:00:57 <ericben> jzhang: btwx I tuned adt-installed.conf to only install minimal ROOTFS and minimal TARGET_SYSROOT_IMAGE : this may be wrong as I may need a sdk for the TARGET_SYSROOT_IMAGE ? If yes which image do you recommend me here ?
Dec 17 18:01:28 <ericben> jzhang: seems sato-sdk is the right one ?
Dec 17 18:03:12 <jzhang> ericben: for development, we recoment sdk image since it contains the development header and libraries and minimal is not sufficient enough
Dec 17 18:03:36 <ericben> jzhang: ok, which sdk image ? sato-sdk ? or is there a smaller one (without gtk & co) ?
Dec 17 18:06:47 <ericben> jzhang: stupid question for confirmation : does adt only works with images named core-image-xyz ?
Dec 17 18:06:49 <jzhang> ericben: we normally tell people to use sato-sdk then after they're familiar with the process, they can customize an image base on their needs...
Dec 17 18:07:15 <ericben> jzhang: ok thanks building sato-sdk now ... 4000 tasks to run :-(
Dec 17 18:07:39 <jzhang> ericben: you don't have to build, adt-installer will download for u
Dec 17 18:08:00 <ericben> jzhang: in fact I tried a full home made configuration else that's too easy ;-)
Dec 17 18:08:22 <ericben> but your right to got fast I'll use the download method for the moment and then I'll rebuild it once I get the downloaded one running
Dec 17 18:09:29 <ericben> jzhang: thanks I download that and come back to you if I meet a problem (should have started by this ... i was to confident :-(
Dec 17 18:09:54 <jzhang> ericben: adt-installer currently will download the image based on core-image-arch, but if you have customized adt-repo, it's easily can be changed the adt-installer script to match your image name convention
Dec 17 18:10:28 <jzhang> ericbe: np at all, just ping me if you still run into issues
Dec 17 18:11:42 <ericben> jzhang: yes I created my own adt-repo but with only minimal image and no sdk image which is I believe the error which explains why cross compiler doesn't works : it hasn't a sysroot ... thanks for the support and sorry for the stupid questions ;-).
Dec 17 18:12:51 <ericben> still getting very low badnwidth when downloading from yoctoproject.org .... it would be great to have a mirror in Europe or to understand what is eating all the bandwidht of your servers (one time a few months ago that was the backup server)
Dec 17 18:19:18 <ericben> is there someone here who has access to the bandwidth informations of yoctoproject.org infrastructure ?
Dec 17 18:20:02 <franzkromer> hey quick question - are the angstrom feeds the only available opkg repository?
Dec 17 18:36:31 <bramming> Hello. I had a quick question for fellow Yocto developers/users. I am trying to build my image on CentOS 6.3 and when I try to source oe-init-build-env i get this error: scripts/oe-setup-builddir: Permission denied
Dec 17 18:36:38 <bramming> do i need to run as root?
Dec 17 18:37:05 <bramming> permissions on the file scripts/oe-setup-builddir look sound
Dec 17 18:37:59 <halstead> bramming, What is the full path to the script?
Dec 17 18:42:36 <bramming> its home/remlab/dev/yocto/yoctoBuild/scripts/oe-setup-builddir
Dec 17 18:43:57 <bramming> im in the yoctoBuild directory where I run the source command: source oe-init-build-env build
Dec 17 18:46:41 <bramming> oh i am using Yocto 1.2
Dec 17 19:12:22 <Crofton|work> zeddii, http://git.xilinx.com/?p=linux-xlnx.git;a=tag;h=e575af841d09a81fa9360fe97e16ad011ab14f82
Dec 17 19:24:19 * zeddii nods. indeeed.
Dec 17 19:42:04 <creber> Hello #yocto
Dec 17 19:42:51 <creber> One question about development for a project. Today our application / hmi developers work on their x86 Linux machine, compile & test on this host and sometime, before the delivery, they cross compile & test on target. This is working quite fine but add extra charge to make sure the libraries used for host side development are the same (filesystem location, version, configuration, ...) than the one on the rootfs.
Dec 17 19:43:35 <creber> Do you know if we could easily instruct yocto to create an x86 sdk to be used when compiling on the host. This sdk would be the exact same rootfs configuration than what is available on the target, just update the variable MACHINE in local.conf.
Dec 17 19:44:00 <creber> Is this something you would recommend, or a qemu based solution remin the best ?
Dec 17 19:46:58 <Crofton|work> with the populate sdk task, you coudl change the machine to an x86 one for compiling, but not sure how testing would go
Dec 17 19:48:18 <Crofton|work> must get the meta-zynq forks under control
Dec 17 19:52:34 <blloyd_> anyone able to tell me what the syntax is to put something like --myoption="an option with spaces" into EXTRA_OECONF?
Dec 17 19:55:44 <blloyd_> bramming: is execute permission possibly turned off on the yoctoBuild file system?
Dec 17 19:58:08 <subodh> ??
Dec 17 19:58:53 <subodh> while rebuilding my yocto project, the build/tmp bulged to more than 57GB.. what's the best way to clean up ?
Dec 17 19:58:53 <blloyd_> and my first attempt to add quotes was --option=\"prog --arch test-arch --prefix ...\"   I get an error from the configure script, where it tries to parse the --arch.
Dec 17 20:00:29 <subodh> ericben / rburton any idea about how to clean up build/tmp area ? TIA.
Dec 17 20:11:39 <blloyd_> sbodh: If you are space constrained, there is an option http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#structure-build-tmp.  Also there is an option (can't find at this time) where it will delete the working directory after each item is built so it uses less space.  It can take a while to get an answer, be patient.
Dec 17 20:12:04 <blloyd_> subodh: ^
Dec 17 20:12:10 <subodh> blloyd thanks a bunch
Dec 17 20:12:22 <subodh> I am not terribly constrained.
Dec 17 20:12:45 <subodh> I would rather keep the working directory so I can go back and understand.
Dec 17 20:14:02 <subodh> I just got rid of the tmp, then based on the manual I guess I need to get rid of the sstate-cache as well. Is that correct?
Dec 17 20:14:04 <blloyd_> I suggest leaving it around, so later builds go faster.  I often go through 100G when playing (building for 2 different CPUs).
Dec 17 20:14:22 <subodh> got it.
Dec 17 20:14:33 <blloyd_> I suggest it.  I have had wierd results when I don't.
Dec 17 20:16:30 <blloyd_> I've also had wierd results with SSTATE when changing patterns without incrementing INCPR.  Which incrementing that every 5 mins during development can be painful.  A bitbake -c cleansstate "package" can be helpful.  Then you are just losing and redoing what you are working on, and not the entire list of dependencies.
Dec 17 20:17:04 <subodh> thanks blloyd. May be I should get a TB hard drive for yocto :-) What's in the name, said who??
Dec 17 20:17:05 <blloyd_> patterns==recipes.
Dec 17 20:18:05 <blloyd_> I manage to work just fine with a 256GB partition for yocto.  :)  I care much more that it is FAST.  Builds take way to long from scratch as is.
Dec 17 20:18:27 <rburton> subodh: define "clean up".  clean-workdir might do something useful.  big disks help, as disks are (relatively) cheap.
Dec 17 20:19:15 <blloyd_> I have an external 1GB disk.  The external means too slow for building.  :(
Dec 17 20:19:24 <rburton> subodh: you can always wipe out tmp if you need and it will reconstruct from sstate.
Dec 17 20:19:39 <rburton> i guess you can cleanup sstate periodically to remove files that haven't been accessed for a while
Dec 17 20:19:49 <subodh> no doubt that disks are cheap. something went wrong when I modified (added just a few debug lines in libgcc-4.7.bb)
Dec 17 20:20:17 <subodh> I am working on an m17x with 125GB solid state drive.
Dec 17 20:20:19 <rburton> sstate-cache-management looks useful
Dec 17 20:20:20 <subodh> can
Dec 17 20:20:49 <rburton> subodh: change libgcc -> rebuild compilers -> rebuild almost everything?
Dec 17 20:20:58 <blloyd_> that's pretty constrained.  Bet it's faster than my setup though.
Dec 17 20:21:15 <rburton> subodh: for <$1000 you can get a quad i7 with 16gb ram and 1tb+ of disk.
Dec 17 20:21:25 <rburton> for a company that's almost nothing.
Dec 17 20:21:49 <subodh> yup.. It is fast, but rburton: I didn't realize the rebuild everything issue. and like the idea of getting quad i7 with 1tb+ disk
Dec 17 20:22:18 <subodh> I have a quick question for you guys..
Dec 17 20:22:19 <rburton> subodh: my machine (that spec) does a core-image-sato from totally clean in 70 mins
Dec 17 20:22:24 <blloyd_> Problem is that is prob a 5400 RPM disk...
Dec 17 20:22:46 <subodh> blloyd.. sorry to hear that.
Dec 17 20:22:47 <blloyd_> I'm impatient: I like my 30 min build of everything.  :)
Dec 17 20:23:06 <subodh> rburton what machine is that?
Dec 17 20:23:31 <rburton> subodh: built by pcspecialist.co.uk
Dec 17 20:23:51 <rburton> blloyd_: 7200rpm
Dec 17 20:24:19 <subodh> rburton: or blloyd: here's what I was trying to get at
Dec 17 20:24:43 * rburton has to go cook
Dec 17 20:24:50 <blloyd_> faster than 5400.  I should look at that.  I couldn't get a machine for sub 1000 with the HD I wanted.  I hit the sub $2K for mine.
Dec 17 20:25:20 <subodh> Since my machine is not super-fast, I wanted to build some small test utilities on the arm platform itself.
Dec 17 20:26:02 <subodh> my image currently doesn't install g++ etc.
Dec 17 20:26:35 <blloyd_> yocto means building everything.  Basically nothing from the host is used for making the host image.  Even making a simple program has a lot of dependencies when you get down to it.  After all, gcc is not small.
Dec 17 20:27:19 <rburton> blloyd_: just add tools-sdk to image features, and you'll get the toolchain in your image
Dec 17 20:27:32 <subodh> otavio pointed me to meta-toolchain-sdk. I saw that meta/recipes-devtools probably does the same. Otavio dissuaded me from putting in meta-toolchain-sdk in my bblayers.
Dec 17 20:27:35 <rburton> then you can build whatever you want directly
Dec 17 20:27:50 <subodh> rburton: should I add that to bblayers?
Dec 17 20:27:56 <rburton> no, its an image feature
Dec 17 20:28:09 <rburton> #  "tools-sdk"      - add development tools (gcc, make, pkgconfig etc.)
Dec 17 20:28:17 <subodh> which file?
Dec 17 20:28:18 <rburton> then your image has gcc, make, etc installed in it
Dec 17 20:28:20 <rburton> local.conf
Dec 17 20:28:32 <subodh> got it sir.. now you go cook ;-)
Dec 17 20:28:34 <rburton> then you can compile what you want how you want on the target
Dec 17 20:28:37 <otavio> rburton: subodh is learning fast :)
Dec 17 20:28:49 <rburton> easier to just do everything in yocto though
Dec 17 20:29:06 <rburton> if you find yourself patching gcc, then you can do tricks to stop it rebuilding the world afterwards
Dec 17 20:29:09 <blloyd_> do, any suggestions what I am doing wrong on my EXTRA_OECONF usage?
Dec 17 20:29:33 <subodh> otavio :) learning fast by burning fingers :)
Dec 17 20:30:00 <subodh> I will report back to you guys on my next build
Dec 17 20:30:15 <blloyd_> been there myself subodh:  oh, wait, what is cookign?  My fingers?
Dec 17 20:31:09 <subodh> why do I see some names in red sometimes?
Dec 17 20:35:13 <blloyd_> subodh: you see your name in red.  Someone tells you something.
Dec 17 20:35:16 <blloyd_> ^
Dec 17 20:36:36 <subodh> nah.. for example your name showed you red <blloyd_> on the first line. then black on the second. something odd. I thought it was a private msg or something. may be not. may be a bug waiting to be killed or may be a wise feature :-)
Dec 17 20:37:04 <blloyd_> I just told you.  And that is what happened.  Look at all the red lines.  This line is blank for you.
Dec 17 20:37:14 <blloyd_> This line has your name subodh in it.  It is red.  :)
Dec 17 20:37:22 <otavio> subodh: when someone say your name it is red
Dec 17 20:37:31 <otavio> without your name, it is not
Dec 17 20:37:38 <otavio> subodh: see?
Dec 17 20:38:14 <subodh> wow.. really cool feature. I am learning :-)
Dec 17 20:38:29 <blloyd_> so not so wierd. :)
Dec 17 20:38:45 <otavio> subodh: so it catches your attention when someone is talking to you
Dec 17 20:39:02 <otavio> or about you! ;-)
Dec 17 20:39:08 <subodh> got it :) little late as usual ;-)
Dec 17 20:40:38 <blloyd_> so, any suggestions how I can get EXTRA_OECONF to honor my extra quotes?  Amusingly it shows them when it does the RUNNING message.  Cut and paste that running message into a devshell and it configures properly.  Let OECONF run it, and seems the real command is missing the quotes.  :(
Dec 17 20:43:54 <otavio> \\\"
Dec 17 20:44:06 <otavio> blloyd_:
Dec 17 20:48:47 <otavio> blloyd_: try \\\"
Dec 17 20:52:25 <blloyd_> nope.  :(
Dec 17 21:06:54 <mranostay> \\\o///
Dec 17 21:13:33 <blloyd_> anyone able to tell me what ${CACHED_CONFIGUREVARS} is?
Dec 17 21:14:04 <kergoth> it's a mechanism to pass cached test values on a per recipe basis
Dec 17 21:14:18 <blloyd_> is it a script?
Dec 17 21:14:35 <blloyd_> -e doesn't show it being set.
Dec 17 21:20:15 <kergoth> ?
Dec 17 21:20:18 <kergoth> look at where its used
Dec 17 21:20:41 <kergoth> shell scripts support setting env vars when executing something.
Dec 17 21:20:41 <sgw1> seebs: you around?  Your recent update seems to be getting somekind of host contamianation issue
Dec 17 21:20:46 <kergoth> FOO=BAR ./baz
Dec 17 21:21:01 <kergoth> if you look at where CACHED_CONFIGUREVARS is used, you see it preceding the ./configure
Dec 17 21:21:08 <kergoth> so you should see that it's intended to be used in this manner
Dec 17 21:21:12 <blloyd_> starting a search through all poky for it.  Looks like it is just "X=Y A=B" when done.
Dec 17 21:21:19 <kergoth> yep
Dec 17 21:21:42 <kergoth> but it's specifically intended for use in setting autoconf test result variables
Dec 17 21:21:48 <kergoth> ac_cv_foo=bar
Dec 17 21:21:50 <kergoth> or whatever
Dec 17 21:23:10 <blloyd_> thank you.  I'm having fun where ..../configure --x="a --auto" works when done in devshell, but fails with --auto is unknown parameter when doing a build directly in bitbake.
Dec 17 21:23:29 <kergoth> i'd suggest quoting it this way
Dec 17 21:23:47 <kergoth> EXTRA_OECONF += "'--x=a --auto'"
Dec 17 21:23:57 <kergoth> i've found that works most often
Dec 17 21:26:51 <blloyd_> :(  Pretty sure '--opt=PROG --auto --prefix ${STAGING_EXECPREFIXDIR}' " won't work
Dec 17 21:27:27 <blloyd_> guess I'll try escaped/unescaped string concatonation next.
Dec 17 21:29:25 <blloyd_> and thank you very much kergoth for the information.
Dec 17 21:30:15 <kergoth> that'll work just fine, assuming you want all of that passed to --opt
Dec 17 21:30:21 <kergoth> it'll get passed to teh child as a single argument
Dec 17 22:41:42 <seebs> sgw1: I'm around. If there are host contamination issues, I am indeed interested in that. The library directory thing is a sort of sore point, it's not entirely well-considered.
Dec 17 22:42:41 <seebs> The assumption that $(LIB) for purposes of libpseudo.so and $(LIB) for purposes of libsqlite3.{so,a} are likely the same thing is probably not entirely safe, although I think bitbake's the only build environment I've used where they are likely to differ.
Dec 17 22:48:35 <seebs> Hmm. You know, it just occurs to me: I only checked the pseudo-native build.
Dec 17 23:16:02 <blloyd_> kergoth: will ${STAGING_EXECPREFIXDIR} get expanded?
Dec 17 23:28:55 <sgw1> seebs: just got back from the chiro, let me give you a pastebin
Dec 17 23:29:21 <seebs> Well, quickly looking at it, I'm pretty sure target pseudo is indeed broken, I just hadn't thought about it yet.
Dec 17 23:29:32 <blloyd_> thanks Kergoth.  Looks like bitbake has different expansion rules than bash or sh.  Seems it works fine with '${VAR}'.  Yippee, simpler syntax.
Dec 17 23:29:36 <kergoth> blloyd_: variables are always expanded when used
Dec 17 23:29:45 <kergoth> ${} is expanded by bitbake when the var referencing it is used
Dec 17 23:29:58 <sgw1> seebs: http://pastebin.com/PeDHjmPZ, it is with pseudo-native (I am running FC18)
Dec 17 23:30:05 <seebs> Huh. That's odd.
Dec 17 23:30:09 <kergoth> the only time the shell gets to expand a reference in shell code is if the var is unset in the metadata, or $foo syntax
Dec 17 23:30:34 <kergoth> In retrospect, we should have used something other than ${}
Dec 17 23:30:41 <fray> ;)
Dec 17 23:30:48 <seebs> sgw1: Something Is Wrong. Because the --with-static-sqlite= was only introduced with a new version of pseudo -- 1.4.2.
Dec 17 23:30:58 <seebs> You should not be seeing that with any reference to pseudo 1.4.1.
Dec 17 23:31:34 <seebs> If you have the new pseudo.inc that uses with-static-sqlite, you should also have pseudo-1.4.2.bb, not pseudo-1.4.1.bb. I think.
Dec 17 23:31:47 <sgw1> seebs: I know that might have happened here, did you make the change to .inc file, I was trying to debug this and set DEFAULT_PREFERENCE for the 1.4.2
Dec 17 23:31:56 <sgw1> but I can get it to happen with 1.4.2 also
Dec 17 23:32:14 <seebs> Huh. It shouldn't with 1.4.2, because 1.4.2 has the with-static-sqlite. I think.
Dec 17 23:32:43 <seebs> If I did the patch I sent out to the list right, it replaces 1.4.1.bb with 1.4.2.bb, and also changes the .inc file.
Dec 17 23:33:03 <seebs> So the new .inc file should only exist with 1.4.2, and if you have an unpack of the 1.4.2 tarball, it should recognize the with-static-sqlite option. I think.
Dec 17 23:33:22 <blloyd_> oh, well.  Another burnt finger.  Someday I'll learn not to play with things I don't understand.  But it looked safe and confortably familiar.  ;)
Dec 17 23:33:50 <sgw1> seebs:  ttp://pastebin.com/MyPCJkNB Updated withthe 1.4.2 failure
Dec 17 23:33:59 <sgw1> seebs look at the botton.
Dec 17 23:34:26 <seebs> Huh, that's odd.
Dec 17 23:34:55 <kergoth> blloyd_: yeah, that's why we should have used something else -- using something familiar means people expect it to behave a particular way, and when it doesn't... :)
Dec 17 23:35:05 <seebs> What's the configure line in run.do_compile look like?
Dec 17 23:35:16 <sgw1> seebs: since I am just getting that into devshell now
Dec 17 23:35:20 <seebs> ohhh
Dec 17 23:35:22 <seebs> I bet I know.
Dec 17 23:35:29 <sgw1> seebs: awesome!
Dec 17 23:35:52 <seebs> I took out the --with-sqlite= because "--with-sqlite=... --enable-static-sqlite" calculated the wrong path.
Dec 17 23:36:10 <seebs> So now it only works if it can find include files naturally, but then it uses our library.
Dec 17 23:36:20 <seebs> And my host happened to have compatible-enough headers.
Dec 17 23:36:28 <sgw1> do_configre dopes nothing, why do you have it in the do_compile?
Dec 17 23:36:53 <seebs> Long story short: Because if you're on a 64-bit host and *must* have 32-bit binaries, you have to run two separate configures and builds.
Dec 17 23:37:17 <seebs> I didn't actually write the bitbake recipe originally.
Dec 17 23:37:24 <sgw1> seebs: got it
Dec 17 23:37:46 <seebs> Anyway, I'll try to fix this, and also have a look at the target case, because it occurs to me that I probably need to do something smarter.
Dec 17 23:38:15 <seebs> I'm thinking something like PSEUDO_LIBDIR = "${base_libdir}" and PSEUDO_LIBDIR_virtclass_nativesdk = "lib"
Dec 17 23:38:49 <sgw1> seebs:  /home/sgw/yocto/builds/buildapp/tmp/work/x86_64-linux/pseudo-native/1.4.2-r14/ps
Dec 17 23:38:49 <sgw1> eudo-1.4.2/configure --prefix=/home/sgw/yocto/builds/buildapp/tmp/sysroots/x86_64-linux/us
Dec 17 23:38:49 <sgw1> r --libdir=/home/sgw/yocto/builds/buildapp/tmp/sysroots/x86_64-linux/usr/lib/pseudo/lib64
Dec 17 23:38:49 <sgw1> --with-static-sqlite=/home/sgw/yocto/builds/buildapp/tmp/sysroots/x86_64-linux/usr/lib/lib
Dec 17 23:38:49 <sgw1> sqlite3.a --cflags="-isystem/home/sgw/yocto/builds/buildapp/tmp/sysroots/x86_64-linux/usr/
Dec 17 23:38:50 <sgw1> include -O2 -pipe" --bits=64 --without-rpath
Dec 17 23:38:52 <seebs> because we need to override the normal behavior ("libsqlite will be in a directory with the same name we would store libpseudo.so in") with bitbake-specific behavior of "the library directory is always lib".
Dec 17 23:39:06 <sgw1> seebs: hope you can made sense of that.
Dec 17 23:39:11 <seebs> yup
Dec 17 23:39:15 <blloyd_> ok, looks like I get to play with making a -cross package.  Once I make it, what is the correct way to have a package use the cross tools?
Dec 17 23:39:25 <sgw1> Ok, will look for an update late.
Dec 17 23:39:27 <sgw1> later
Dec 17 23:44:33 <kergoth> blloyd_: if you mean cross recipe, not cross package, just write a normal recipe and ad BBCLASSEXTEND += "cross"
Dec 17 23:47:52 <blloyd_> so add that BBCLASSEXTEND to the existing non cross recipe or make another one?
Dec 17 23:57:45 <blloyd_> ok, I'm taking suggestions: I have an existing program that uses the wxWidgets library.  I got wxWidgets to compile, but it provides a wx-config script.  That script gives full options (there are a LOT) to compile against the library.  That script is polluting the build by using /usr/include instead of the install directory (which gets missed by sanity checks btw).  Should I be using NATIVE, CROSSES, or something else to build wx-config, an
Dec 17 23:57:45 <blloyd_> d then where I should I have my real program look for that script at?
Dec 17 23:57:54 <ericben> is there a reason for rm_work to not remove package and packages-split directories in WORKDIR ?
Dec 17 23:59:55 <kergoth> blloyd_: have you seen the binconfig class? it's specifically to handle this, including any necessarily mangling of paths in the -config script
Dec 18 00:00:11 <kergoth> just inherit binconfig and call it a day
Dec 18 00:00:12 <blloyd_> no, I missed that.
Dec 18 00:05:52 <blloyd_> oh, boy.  wx-config is a symbolic link.  It is to /usr/include/...   Should I be redoing that symbolic link so it is relative?  It uses a non-relative path to the --prefix directory.  And so sed on the file doesn't work.
Dec 18 00:07:24 <hollisb> is there a "create tarball" command that will smash in all the patches and extra files referenced in the recipe?
Dec 18 00:11:10 <ericben> ok, rm_work.bbclass says "The package and packages-split directories are retained by sstate for do_package so we retain them here too. Anything in sstate 'plaindirs' should be retained. Also retain logs and other files in temp"
Dec 18 00:13:29 <ericben> qt-embedded's package dir is around 1.6G ... fighting for space in a too small VM :-(
Dec 18 01:14:59 <blloyd_> I seem to remember there is a syntax that lets you add before or after a function (for instance run additional code after do_install).  But I can't find it now that I'm looking.  Any hints?
Dec 18 01:17:48 <fray> do_install_prepend () { ... }
Dec 18 01:17:53 <fray> do_install_append () { ... }
Dec 18 02:39:29 <blloyd_> thank you fray: did the append earlier didn't seem to work.  Now I'm finding I may not need it.  There is symbolic link fixup code in place already, but it is causing me grief because I obviously don't understand something.
Dec 18 02:40:32 <blloyd_> have a file, say ${libdir}/a/x, which has a symbolic link to it from ${bindir}/lnk
Dec 18 02:42:52 <blloyd_> now, these are development files, so I do a FILES_${PN}-dev += "${libdir}/a/x ${bindir}/lnk".   When I add that line, I get a QA Failure because ${PN} references ${PN}-dev.  But I don't understand why, when I asked for both symbolic link and file to be in -dev.
**** ENDING LOGGING AT Tue Dec 18 02:59:58 2012

**** BEGIN LOGGING AT Tue Dec 18 02:59:58 2012
Dec 18 09:04:20 <bluelightning> morning all
Dec 18 09:09:03 <rburton> hi bluelightning
Dec 18 09:10:44 <bluelightning> hi rburton
Dec 18 12:55:50 <wmat> darn, my over night build of core-image-sato failed with 1 error :(
Dec 18 12:57:57 <Crofton|work> what error?
Dec 18 13:00:22 <wmat> Crofton|work: /home/wmat/dev/poky/build/tmp/sysroots/x86_64-linux/usr/include/glib-2.0/glib/giochannel.h:268:25: error: expected '=', ',', ';', 'asm' or '__attribute__' before '^' token
Dec 18 13:02:34 <Crofton|work> weird, syntax error in code
Dec 18 13:02:41 <Crofton|work> weird arch?
Dec 18 13:03:46 <wmat> build machine is x86_64, and build is bitbake -k core-image-sato, right out of the Quick Start Guide
Dec 18 13:04:02 <Crofton|work> seriously odd then
Dec 18 13:05:42 <wmat> this is on the git version, not danny
Dec 18 13:07:02 <Crofton|work> still
Dec 18 13:33:39 <_Lucretia_> what's the best way to rename a downloaded file?
Dec 18 13:33:55 <otavio> _Lucretia_: what do you mean?
Dec 18 13:34:07 <otavio> _Lucretia_: I'd say 'mv orig dest' ;)
Dec 18 13:34:39 <_Lucretia_> I need to download an archive but the url is a hash, but it brings down an archive, so i want to rename it afterwards so 1) tar can unpack it and 2) so it makes sense
Dec 18 13:35:04 <_Lucretia_> ideally, would be nice to be able to pass the new name to the fetcher so wget can rename it
Dec 18 13:36:34 <otavio> _Lucretia_: You can change DL_DIR and mangle it
Dec 18 13:36:47 <otavio> _Lucretia_: check meta-browser as we did it for i18n packages
Dec 18 13:37:13 <otavio> _Lucretia_: it is a hack but it works
Dec 18 13:37:29 <_Lucretia_> I don't seem to have that...where is it?
Dec 18 13:37:36 <otavio> _Lucretia_: github
Dec 18 13:39:15 <_Lucretia_> https://github.com/OSSystems/meta-browser ??
Dec 18 13:39:48 <_Lucretia_> ah goti it
Dec 18 13:41:02 <_Lucretia_> ta
Dec 18 13:41:48 <otavio> yes
Dec 18 13:49:01 <bluelightning> there is a parameter for the name of the downloaded file...
Dec 18 13:49:55 <bluelightning> the parameter is downloadfilename
Dec 18 13:50:01 <bluelightning> _Lucretia_: ^
Dec 18 13:50:45 <_Lucretia_> ah, even better thanks...SRC_URI="http://blah;downloadfilename=wah.tgz" ??
Dec 18 13:50:52 <_Lucretia_> I looked in the bitbake manual, doesn't say
Dec 18 13:52:01 <otavio> bluelightning: oh really? so this is new!
Dec 18 13:52:14 <otavio> bluelightning: when I looked for it I read the fetcher code and found nothing
Dec 18 13:52:42 <bluelightning> otavio: relatively new yes
Dec 18 13:53:19 <otavio> bluelightning: good!
Dec 18 13:53:35 <bluelightning> _Lucretia_: I would recommend using the yocto project reference manual instead, that does mention this option
Dec 18 13:54:49 <_Lucretia_> which distros do you people use?
Dec 18 13:54:53 <_Lucretia_> to build on
Dec 18 13:54:58 <_Lucretia_> your host machine
Dec 18 13:55:12 <_Lucretia_> we're setting up a new machine and want as few problems as possible...
Dec 18 13:55:23 <_Lucretia_> I had tons with debian
Dec 18 13:55:32 <otavio> I use Debian
Dec 18 13:55:37 <_Lucretia_> 64 bit?
Dec 18 13:55:42 <_Lucretia_> it will be 64 bit
Dec 18 13:55:42 <otavio> sure
Dec 18 13:56:17 <rburton> debian 64 bit for yocto works perfectly
Dec 18 13:56:32 <_Lucretia_> my main problem was the split of normal gcc/g++ and the gnat versions as I need to build Ada in yocto, couldn't get yocto to pick up the other versions properly
Dec 18 13:56:33 <otavio> rburton: Debian works perfectly for everything
Dec 18 13:56:39 <rburton> otavio: truth
Dec 18 13:56:51 <otavio> :)
Dec 18 14:03:01 <Crofton|work> _Lucretia_, as long as he distro is fairly "popular" it should work well with OE
Dec 18 14:03:46 <_Lucretia_> well, i'm on debian testing...had to build a custom gcc with gnat and set the PATH before building yocto
Dec 18 14:03:53 <_Lucretia_> even then it wasn't smooth at all
Dec 18 14:04:04 <Crofton|work> weird
Dec 18 14:04:09 <Zagor> _Lucretia_: huh? I'm on debian testing too and never had to do that
Dec 18 14:04:19 <_Lucretia_> Zagor: do you build ada?
Dec 18 14:04:24 <_Lucretia_> in yocto
Dec 18 14:04:26 <Zagor> _Lucretia_: no
Dec 18 14:04:29 <_Lucretia_> I do
Dec 18 14:04:44 <_Lucretia_> grab the meta-ada layer and try it
Dec 18 14:05:14 <_Lucretia_> will fail, because there are 2 sets of compilers installed, gnat and stock gcc
Dec 18 14:05:16 <Zagor> that sounds buggy, yes
Dec 18 14:05:42 <_Lucretia_> the stock gcc knows all compilers but ada, the separate gnat install knows ada, c, c++
Dec 18 14:05:48 <_Lucretia_> probably fortran
Dec 18 14:07:27 <_Lucretia_> and yocto removes a lot of environment vars when it starts...and no matter what I did, I could not get it to use gnatgcc instead of gcc
Dec 18 14:07:48 <_Lucretia_> would love to know how to do it with that layer if someone fancies trying it
Dec 18 14:30:03 <ant_work> _Lucretia_: we do use a 'different compiler' for some recipes, klcc, don't know if you can grab some ideas
Dec 18 14:38:38 <Zagor> I've never dabbled with ada. what more is required other than adding ada to --enable-languages?
Dec 18 14:44:03 <Zagor> i.e. we already have support for java and fortran in gcc, so why not just add similar support for ada?
Dec 18 14:52:02 <_Lucretia_> ant_work: k thanks
Dec 18 14:57:30 <ant_work> _Lucretia_: check out klibc.bbclass in meta-initramfs
Dec 18 14:57:48 <_Lucretia_> ok, will do
Dec 18 15:23:28 <subodh> rburton: or ericben: or otavio: I am trying to fetch, config, compile and install a package. so far, I understand how to write do_configure()
Dec 18 15:24:01 <subodh> is there a better way to fetch a package before do_configure() ? another do_fetch() or something like that?
Dec 18 15:24:02 <subodh> thanks
Dec 18 15:27:12 <rburton> well, setting SRC_URI will do the fetch for you
Dec 18 15:27:33 <rburton> for configure, see if any of the existing classes will do it for you
Dec 18 15:28:02 <rburton> ditto for compile - the default is to run "make" but if that isn't what you want then there are classes to do something else
Dec 18 15:28:11 <rburton> subodh: so much easier if you tell us what you're actually trying to do though
Dec 18 15:28:19 <subodh> sure..
Dec 18 15:28:47 <subodh> rburton: trying to install chromium following otavio: recipe of meta-chromium
Dec 18 15:29:07 <subodh> unfortunately I have to stick with an older version so trying to understand how to do that.
Dec 18 15:29:41 <subodh> chromium is a beast (in a good way :-)) needs its own gclient / depot_tools to be installed
Dec 18 15:29:51 <rburton> yes, horrific :)
Dec 18 15:29:53 <subodh> I don't think yocto has those hooks
Dec 18 15:30:52 <subodh> to hide (and perfect :) that gclient stuff in something after SRC_URI but before do_configure, I was looking for a hook like that
Dec 18 15:32:04 <subodh> rburton: I have to go heat up my mini-lunch.. will be back here in 10 mins max.. then got to leave this thread and switch onto higher priority task
Dec 18 15:32:06 <rburton> can't you just add a new recipe to do those?
Dec 18 15:32:15 <rburton> fetch / build / install into sysroot
Dec 18 15:32:19 <rburton> depot-native or something
Dec 18 15:40:34 <wmat> Crofton|work: fwow, I reran bitbake -k core-image-sato and all succeeded
Dec 18 15:40:52 <subodh> rburton: will do_configure_prepend() get invoked before do_configure()? I am not comfortable enough to do depot-native recipe, but eventually may do that.
Dec 18 15:41:33 <bluelightning> subodh: you should just do it now, trying to do otherwise is just going to be painful and messy
Dec 18 15:42:11 <subodh> ok.. willing to do it if I can learn about it in less than 4 hrs..
Dec 18 15:42:47 <subodh> unfortunately, I need to leave now, will be back here at 2 pm EST. bluelightning or rburton if you are here, I will ping you
Dec 18 15:43:11 <subodh> make it 2:30 EST to be safe
Dec 18 15:43:47 <subodh> any pointers you have would be good.. TIA
Dec 18 15:52:29 * sgw1 reminds: Tech Call in about 10 minutes: Dialing: 1.972.995.7777 | Code: 76994298
Dec 18 15:58:30 * sgw1 YPTM: Saul is on and Leading
Dec 18 15:58:48 <eren> TPYM: Eren is connected
Dec 18 15:58:51 <eren> ops
Dec 18 15:58:52 <darknighte> YPTM: Sean Hudson from Mentor Graphics dialed in
Dec 18 15:58:58 <eren> YPTM: Eren is connected from hambedded linux :P
Dec 18 15:59:11 <darknighte> eren: cool
Dec 18 15:59:17 <eren> darknighte: thanks
Dec 18 15:59:36 <eren> it's not commercial, though :)
Dec 18 16:00:00 <darknighte> eren: I read a bit about it a little while back. sounds interesting
Dec 18 16:00:07 <tomz1> YPTM: Tom Z in the meeting
Dec 18 16:00:16 <darknighte> eren: iirc, you wrote some information up about bitbake, as well, right?
Dec 18 16:00:20 <eren> darknighte: right
Dec 18 16:00:30 <bluelightning> YPTM: Paul Eggleton is on the call
Dec 18 16:00:31 <strassek> YPTM: Kevin Strasser dialing in
Dec 18 16:00:32 <eren> that was my way of learning bitbake and oe
Dec 18 16:00:43 <darknighte> sgw1: you sound SOOOO excited and awake!  ;)
Dec 18 16:00:53 * darknighte grins
Dec 18 16:01:03 * eren is like a rocket
Dec 18 16:01:03 <zeddii> YPTM:  Bruce Ashfield in the meeting
Dec 18 16:01:11 * eren 18:01 here
Dec 18 16:01:23 <darknighte> better than laying in bed
Dec 18 16:01:26 <eren> southpark silence
Dec 18 16:01:35 <darknighte> only marginally… ;)
Dec 18 16:01:49 <scottrif> YPTM: Scott Rifenbark joined call
Dec 18 16:01:52 <mihai3> YPTM: Mihai Lindner joined the call
Dec 18 16:01:55 <eren> zeddii: oh, I have some kernel related question
Dec 18 16:02:03 <eren> good to see you here!
Dec 18 16:02:15 * darknighte goes to hack up a lung
Dec 18 16:02:16 <darknighte> brb
Dec 18 16:02:44 <cornel__> I have an open about Testopia
Dec 18 16:02:46 <eren> OPEN: alix3d3 BSP status
Dec 18 16:03:49 <fp> YPTM: Amit is on the call
Dec 18 16:04:09 <jzhang-laptop> YPTM: jzhang's on
Dec 18 16:05:38 <rburton> YPTM: ross is joining now
Dec 18 16:06:50 <scottrif> ross: what month does 1.3.1 release?
Dec 18 16:10:38 <mihai3> sgw1: https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team
Dec 18 16:10:53 <nitink> YPTM: nitin joining the bridge
Dec 18 16:11:06 <darknighte> mihai3: well done!
Dec 18 16:11:23 <mihai3> darknighte: thanks :)
Dec 18 16:11:37 <eren> https://github.com/hambedded-linux/meta-alix3d3/
Dec 18 16:20:40 <darknighte> nitink: so you
Dec 18 16:20:48 <cornel__> Testopia WIKI: https://wiki.yoctoproject.org/wiki/Testopia (work in progress at the monent)
Dec 18 16:20:55 <darknighte> said what form factor?
Dec 18 16:21:20 <cornel__> Testopia access: www.bugzilla.yoctoproject.org (click on Product Dashboard)
Dec 18 16:21:24 <eren> cornel__: wow, what's your screen resolution?
Dec 18 16:21:28 <nitink> darknighte: http://www.intel.com/content/www/us/en/motherboards/desktop-motherboards/next-unit-computing-introduction.html
Dec 18 16:21:38 <darknighte> nitink: thx
Dec 18 16:21:48 <cornel__> eren:: it's work in progress :) I will resize it
Dec 18 16:21:55 <eren> cornel__: the image is too big for my screen :)
Dec 18 16:22:04 <eren> okkie
Dec 18 16:22:15 <mihai3> bug 3272
Dec 18 16:22:16 <yocti> Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=3272 enhancement, Medium, 1.4, paul.eggleton, NEW , Implement web interface for indexing OpenEmbedded layers
Dec 18 16:22:39 <nitink> darknighte: the box size is 4.5 x 4.5 x 2 , with core i3
Dec 18 16:22:45 <rburton> me want!
Dec 18 16:22:56 <darknighte> yocti: thx, I was loking for it
Dec 18 16:22:58 <yocti> darknighte: Error: "thx," is not a valid command.
Dec 18 16:23:11 <darknighte> rburton: me too!
Dec 18 16:23:20 <rburton> everyone wants nuc
Dec 18 16:23:24 <cornel__> eren: CTL + mowse scroll :D
Dec 18 16:23:35 <darknighte> bluelightning: would you share more details (in iRC)?
Dec 18 16:23:39 <cornel__> eren: I will resize it I promise!
Dec 18 16:24:34 <bluelightning> darknighte: there's not a lot more to say beyond what's in the bug
Dec 18 16:24:34 <Crofton|work> halstead, try using meetbot with the bot
Dec 18 16:24:36 <darknighte> bluelightning: in particular, discovery mechanism, or is it all manual
Dec 18 16:24:45 * darknighte scans bug
Dec 18 16:25:11 <eren> cornel__: okkie! :)
Dec 18 16:25:47 <bluelightning> darknighte: it's manual - if a new layer is ready to be published, it would be submitted via the interface and then a group of people should be able to approve it to be published
Dec 18 16:26:09 <eren> is the room silenced?
Dec 18 16:26:09 <halstead> Crofton|work: I'll look into it.
Dec 18 16:26:29 <nitink> rburton: it is one of the hot item on sale, it was bit hard to find a place which has not exhausted it's NUC inventory for ordering.
Dec 18 16:26:33 <darknighte> bluelightning; makes sense
Dec 18 16:26:37 <darknighte> +1
Dec 18 16:26:53 <mihai3> darknighte: yocti is your friend
Dec 18 16:26:55 <mihai3> watch
Dec 18 16:26:57 <eren> I cannot hear anything :\
Dec 18 16:26:57 <mihai3> yocti: bug 1
Dec 18 16:26:59 <yocti> mihai3: Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=1 normal, High, ---, ross, RESOLVED FIXED, Should install stripped-down gnome-icon-theme
Dec 18 16:27:11 <bluelightning> eren: the call is finished I think
Dec 18 16:28:03 <eren> oh
Dec 18 16:28:14 <eren> okie
Dec 18 16:28:29 <rburton> mihai3: hell yeah
Dec 18 16:32:28 <darknighte> mihai3: cool.
Dec 18 16:33:29 <mihai3> rburton: :))
Dec 18 16:33:34 <mihai3> proud enough? :P
Dec 18 16:33:40 <darknighte> mihai3: what commands does it understand?
Dec 18 16:34:37 <mihai3> darknighte: well "bug" keyword for bugzilla, i think "seen" is there also
Dec 18 16:34:52 <darknighte> yocto: seen mihai3?
Dec 18 16:34:59 <darknighte> yocti: seen mihai3?
Dec 18 16:34:59 <yocti> darknighte: Error: 'mihai3?' is not a valid nick.
Dec 18 16:35:06 <mihai3> some channel logging maybe and channel commands if it had op access
Dec 18 16:35:17 <mihai3> seen RP
Dec 18 16:35:31 <eren> yocti: ' OR 1=1
Dec 18 16:35:32 <mihai3> hm, sorry RP for the highlight
Dec 18 16:35:32 <yocti> eren: Error: "'" is not a valid command.
Dec 18 16:35:34 <eren> :P
Dec 18 16:35:54 <eren> yocti: yocti
Dec 18 16:35:55 <yocti> eren: Error: "yocti" is not a valid command.
Dec 18 16:36:06 <eren> she doesn't recognize herself :(
Dec 18 16:37:19 <darknighte> identity issues....
Dec 18 16:37:33 <mihai3> yocti: seen yocti
Dec 18 16:37:33 <yocti> mihai3: I have not seen yocti.
Dec 18 16:37:47 <mihai3> and with no mirror around apparently
Dec 18 16:37:48 <mihai3> :D
Dec 18 16:37:50 <eren> darknighte: identity is a big problem, even for a bot
Dec 18 16:37:55 <mihai3> yocti: seen mihai3
Dec 18 16:37:55 <yocti> mihai3: mihai3 was last seen in #yocto 6 seconds ago: <mihai3> :D
Dec 18 16:38:03 <eren> singularity is near, we need to take it into account :P
Dec 18 16:38:12 <darknighte> yocti: who's a silly bot?
Dec 18 16:38:13 <yocti> darknighte: Error: "who's" is not a valid command.
Dec 18 16:38:43 <mihai3> praise darknighte for invalid command
Dec 18 16:38:46 <mihai3> hm
Dec 18 16:38:49 <mihai3> yocti: praise darknighte for invalid command
Dec 18 16:38:49 <yocti> mihai3: Error: There are no praises in my database for #yocto.
Dec 18 16:39:02 <darknighte> hehe
Dec 18 16:39:16 <darknighte> well this is a good way to kill some time.
Dec 18 16:39:19 <darknighte> yocto: help
Dec 18 16:39:31 <halstead> mihai3++
Dec 18 16:39:36 <eren> yocti: praise yocti
Dec 18 16:39:36 <yocti> eren: Error: There are no praises in my database for #yocto.
Dec 18 16:39:51 <eren> yocti: halt -p
Dec 18 16:39:52 <yocti> eren: Error: "halt" is not a valid command.
Dec 18 16:39:53 <eren> yocti: exit
Dec 18 16:39:55 <yocti> eren: Error: "exit" is not a valid command.
Dec 18 16:39:55 <eren> :P
Dec 18 16:40:21 * eren that's enough for me. Thank you yocti, it was fun to talk to you
Dec 18 16:40:57 <mihai3> halstead: yes? :D
Dec 18 16:41:07 <halstead> yocti: karma
Dec 18 16:41:07 <yocti> halstead: Highest karma: "bluelightning" (4), "halstead" (4), and "zeddii" (3).  Lowest karma: "dvhart --woohoo" (-1), "sgw: evadeflow <<<<-" (-1), and "msm:  recipes-append/libxml/libxml2_2.7.8.bbappend |    3 +++  recipes-append/libxml/libxml2_2.8.0.bbappend |    3 ---    recipes-append/netbase/netbase_4.47.bbappend |   10 ++++++++++   recipes-append/netbase/netbase_5.0.bbappend  |   10 --------" (-1). (1 more message)
Dec 18 16:41:48 <mihai3> yocti: kara
Dec 18 16:41:49 <yocti> mihai3: Error: "kara" is not a valid command.
Dec 18 16:41:50 <mihai3> yocti: karma
Dec 18 16:41:50 <yocti> mihai3: Highest karma: "bluelightning" (4), "halstead" (4), and "zeddii" (3).  Lowest karma: "dvhart --woohoo" (-1), "sgw: evadeflow <<<<-" (-1), and "msm:  recipes-append/libxml/libxml2_2.7.8.bbappend |    3 +++  recipes-append/libxml/libxml2_2.8.0.bbappend |    3 ---    recipes-append/netbase/netbase_4.47.bbappend |   10 ++++++++++   recipes-append/netbase/netbase_5.0.bbappend  |   10 --------" (-1).  You (1 more message)
Dec 18 16:41:56 <halstead> mihai3: just giving you karma.
Dec 18 16:41:58 <bluelightning> hmm, looks like maybe its parsing could do with refinement
Dec 18 16:42:15 <darknighte> indeed
Dec 18 16:42:50 * darknighte cheers for yocti karma
Dec 18 16:43:11 <kergoth> heh, i did a quick prototype of a patch to bitbake to make use of unefined variables raise an error in any context but signature generation... already found like 5 bugs in metadata
Dec 18 16:43:14 * darknighte may have taken too much cold medicine
Dec 18 16:43:30 <halstead> bluelightning: Yeah, I think there is a setting so only users in channel qualify for auto karma. Might turn that one on.
Dec 18 16:43:39 <darknighte> kergoth: nice
Dec 18 16:43:42 <kergoth> typos, use of removed variables, etc
Dec 18 16:44:00 <kergoth> meta-oe has 5 recipes using layout_exec_prefix which no longer exists
Dec 18 16:44:04 <kergoth> heh
Dec 18 16:44:08 <blloyd_> that wil be helpful.
Dec 18 16:44:57 <kergoth> i'd like for that behavior to be default in the long term, but might be something useful to add as an opt-in function. make it warn instead of be fatal, perhaps
Dec 18 16:45:01 * kergoth thinks
Dec 18 16:45:27 <ant_work> kergoth: +1 for fatal
Dec 18 16:45:52 <blloyd_> I like the fatal by default, allow warn by option.  :)
Dec 18 16:46:13 <kergoth> it's not that hard to define default values, after all..
Dec 18 16:46:14 <kergoth> heh
Dec 18 16:46:23 * JaMa +1 for warn
Dec 18 16:47:09 <darknighte> if I ever needed confirmation about what a hoss my work laptop is, I now have it.
Dec 18 16:47:19 <darknighte> I just upgraded the memory to 32 GB.
Dec 18 16:47:25 <blloyd_> or how easy would it be to do warn by default, and allow local.conf or a command switch to set fatal as default?
Dec 18 16:47:48 * darknighte shakes head
Dec 18 16:48:28 <blloyd_> ok, command switch wouldn't be default but anyways...
Dec 18 16:48:35 <ant_work> if it's only for 5 recipes why bother? it's a severe bug
Dec 18 16:48:59 <kergoth> well, 5 *so far*. its fatal, so i haven't seen them all yet :)
Dec 18 16:49:06 * kergoth turns it into a warning to gather up a total
Dec 18 16:49:10 <ant_work> ahh
Dec 18 16:49:15 <ant_work> right
Dec 18 16:49:52 <darknighte> kergoth: +1 on fatal long term, but depending on what you find, we may want warning for short term
Dec 18 16:49:54 <blloyd_> ant_work: user is using a repository from a third party.  Said repo missed an update that removed variables.  That user may not have the expertise to fix the problem, and an error stops them from building at all.
Dec 18 16:50:39 <darknighte> blloyd_: how valid will their build be in that case?
Dec 18 16:50:53 <blloyd_> depends if it works or not....
Dec 18 16:51:08 <ant_work> that's a case of subtle breakages
Dec 18 16:51:18 <kergoth> better to fail outright than potentially produce something broken
Dec 18 16:51:32 <darknighte> blloyd_: I would argue that, as ant_work says, it's a recipe for subtle issues that don't show until way down the line.
Dec 18 16:51:57 <blloyd_> I'm assuming this would be it breaks during build of item, not on parsing.  Then you could have a recipe you don't use stop you from building...
Dec 18 16:52:19 <blloyd_> Then, -> otherwise
Dec 18 16:53:35 <ant_work> the warnings have sense about the sources, like Gentoo does, not about the metadata which is supposed to be sane
Dec 18 16:54:31 <kergoth> speaking of metadata sanity, we should think about deprecating use of unqualified 'RDEPENDS'
Dec 18 16:55:28 <rburton> kergoth: yes
Dec 18 16:56:47 <blloyd_> and the subtle issues is why I review warnings.  Which reminds me: can anything think of a reason I shouldn't be able to add ${bindir}/FILE to FILES_${PN}-dev?  I originally thought I might not have been overriding the variable correctly, but the files in other directories are being placed in -dev.
Dec 18 16:59:32 <ant_work> maybe the recipe redefines PACKAGES ?
Dec 18 17:01:30 <blloyd_> ant_work, that would be why.  Now to find what does.
Dec 18 17:01:41 <blloyd_> seems -dev has been moved behind ${PN}
Dec 18 17:04:51 <blloyd_> so metadata problems shouldn't produce warnings?  Package QA is metadata checks, and it produces warnings (several of which not correcting made for broken builds).
Dec 18 17:09:57 <ant_work> blloyd_: I meant QA on compile
Dec 18 17:10:11 <ant_work>  * QA Notice: Package has poor programming practices which may compile
Dec 18 17:10:12 <ant_work>  *            but will almost certainly crash on 64bit architectures.
Dec 18 17:10:12 <ant_work>  *
Dec 18 17:10:12 <ant_work>  * Function `ldap_get_values' implicitly converted to pointer at gq-browser-node-dn.c:389
Dec 18 17:10:18 <ant_work> ...
Dec 18 17:10:53 <ant_work> *  Please file a bug about this at ...
Dec 18 20:31:23 <blloyd_> I thought that the PACKAGES line was done where ${PN} is last on purpose so that programs could be easily moved out of it into alternate packages.
Dec 18 20:43:41 <blloyd_> Final line that gets expanded is # PACKAGES=${PN}-dbg ${PN}-staticdev ${PN} ${PN}-doc ${PN}-dev ${PN}-locale   (so out of order).  But the package doesn't redine PACKAGES, and I can't see where autotools or binconfig does.  Can anyone give me any suggestions on how to find where this line is coming from and/or being mangled from?
Dec 18 20:47:50 <fray> the default is specified in the meta/conf/bitbake.conf
Dec 18 20:47:59 <fray> the recipes -usually- do things like PACKAGES += or =+...
Dec 18 21:06:36 <blloyd_> all right.  Added .conf files to my searches to find code.  Might be able to find things I keep missing.
Dec 18 23:40:31 <msm> is anyone on the advisory board around?
**** ENDING LOGGING AT Wed Dec 19 02:59:59 2012

**** BEGIN LOGGING AT Wed Dec 19 02:59:59 2012
Dec 19 07:34:27 <iwamatsu> hi, where can we use ltsi kernel recipe from?
Dec 19 09:04:50 <JaMa> sgw1: ping?
Dec 19 09:19:20 <bluelightning> morning all
Dec 19 11:23:58 <Crofton|work> gm
Dec 19 12:03:15 <_julian_> hi
Dec 19 12:40:34 <otavio> Hi!
Dec 19 12:40:45 <otavio> Who is reponsable by autobuilder addition?
Dec 19 12:48:18 <mihai> otavio: hi
Dec 19 12:48:19 <mihai> add what?
Dec 19 12:48:40 <otavio> mihai: hi
Dec 19 12:48:45 <otavio> mihai: meta-fsl-arm
Dec 19 12:49:04 <otavio> mihai: we fixed the udev requirement of meta-oe and now it should be fine
Dec 19 12:49:10 <mihai> otavio: either way, for autobuilder stuff, you could talk to sgw1, RP or eflanagan, whenerve you catch them online
Dec 19 12:49:21 <mihai> otavio: oh, i see
Dec 19 12:49:23 <otavio> mihai: master only for now (targeting 1.4)
Dec 19 12:49:46 <otavio> mihai: and please give me a short introdution where I find and check the logs
Dec 19 12:51:20 <mihai> otavio: for adding stuff to AB you should talk to Saul, sgw1 here, he'll be online later today
Dec 19 12:51:43 <rburton> http://autobuilder.yoctoproject.org/
Dec 19 12:53:54 <mihai> ah!
Dec 19 12:54:42 <mihai> suddenly a link!
Dec 19 12:54:46 * mihai jumps
Dec 19 12:55:24 <rburton> all the autobuilder mails have a link :)
Dec 19 12:55:34 <rburton> otavio: there's also a mailing list which the autobuilder sends mail to
Dec 19 12:56:22 <otavio> rburton: where?
Dec 19 12:57:18 <rburton> otavio: https://www.yoctoproject.org/tools-resources/community/mailing-lists
Dec 19 12:58:23 <otavio> got it
Dec 19 12:58:49 <otavio> mihai: I will be out for an hour but please leave any information I should know about the setup and where to check i
Dec 19 12:58:52 <otavio> it
Dec 19 14:21:34 <otavio> mihai: so I am back
Dec 19 14:22:04 <otavio> mihai: I didn't see where it has been add
Dec 19 14:23:26 <mihai> otavio: i didn't say I can add it :)
Dec 19 14:23:42 <otavio> ah!
Dec 19 14:23:48 <mihai> otavio: we need to wait for Saul
Dec 19 14:24:01 <otavio> mihai: sorry, I missunderstood it
Dec 19 14:24:05 <otavio> mihai: no problem
Dec 19 14:24:24 <mihai> otavio: it's ok, np :)
Dec 19 14:25:35 <otavio> :-)
Dec 19 15:32:51 <sgw1> Hi folks, looks like JaMa and otavio where looking for me while I slept, what's up?
Dec 19 15:34:29 <mihai> sgw1: morning
Dec 19 15:36:09 <mihai> sgw1: otavio was asking about adding meta-fsl-arm to AB, and quote:
Dec 19 15:36:16 <mihai> "(14:48:59) otavio: mihai: we fixed the udev requirement of meta-oe and now it should be fine"
Dec 19 15:38:50 <JaMa> sgw1: in last consolidated PR you've included change of modules.tgz filename but not the KERNEL_IMAGE change, so it won't be "same versioning schema" as commit says
Dec 19 15:39:04 <sgw1> mihai: right, you pointed him to myself or pidge, she will be able to take care of that.
Dec 19 15:39:21 <otavio> :)
Dec 19 15:39:44 <otavio> pidge: the ball is with you now then :) please let me know if I need to do anything
Dec 19 15:40:22 <sgw1> otavio: not sure if pidge (Beth) will be able to do it before break or not, but please send her email with details and branch repo (meta-fsl-arm) locations.
Dec 19 15:40:51 <otavio> sgw1: before break means?
Dec 19 15:40:52 <otavio> :)
Dec 19 15:40:58 <sgw1> JaMa: ah, so I should drop the modules.tgz change?
Dec 19 15:41:21 <sgw1> otavio: pidge will take some vacation between xmas and new years
Dec 19 15:41:44 <otavio> sgw1: ah I see
Dec 19 15:42:52 * sgw1 has to bail back in a few hours, need to drive to Portland for meetings
Dec 19 15:43:29 <JaMa> sgw1: I would prefer to include that other change :)
Dec 19 16:30:20 <subodh> query otavio
Dec 19 16:30:42 <rburton> subodh: /query :)
Dec 19 16:31:04 <subodh> Noob :-)
Dec 19 16:41:56 <blloyd_> I am still trying to figure out why files in /usr/bin are not placed in sysroot-destdir (and the build sysroot after that).
Dec 19 16:44:54 <kergoth> blloyd_: if it's a target recipe, that makes perfect sense. putting target binaries in the sysroot would be useless at best
Dec 19 16:45:04 * kergoth shrugs
Dec 19 16:46:58 <blloyd_> and I need a little help understanding the cross and native tools.  I am trying to get a framework built with bitbake, and it includes some build time tools (source parsers).  Should I be looking at making the package have a native flavor?  What exactly is the difference between cross and native?
Dec 19 16:48:23 <blloyd_> kergoth: binaries I would agree with.  Scripts are the problem.  I've already figured out I am going to have to do my own little binconfig type item as that file is a bit limited when it comes to multiple scripts with radically different names.
Dec 19 16:49:55 <kergoth> cross == stuff that runs on the build machine but targets the target, e.g. the crosscompiler, the cross-gdb , etc
Dec 19 16:50:03 <kergoth> native == stuff that runs on the build machine, for the build machine
Dec 19 16:50:10 <kergoth> (e.g. autoconf-native, which ha zero knowledge of the target)
Dec 19 16:50:28 <rburton> blloyd_: you'll probably want -native, cross is generally specific to the toolchain itself
Dec 19 16:52:29 <blloyd_> makes sense.  How should I reference a tool in another script so it find this custom one instead of the one installed on the host?
Dec 19 16:52:40 <blloyd_> bitbake recipe?
Dec 19 16:53:13 <rburton> blloyd_: if it just searches $PATH then that Just Works, once you've installed it (via a depends, ie DEPENDS=mytool-native
Dec 19 16:54:34 <blloyd_> ok, that's easy enough.  Will double check something stupid like is file in /bin/ no is in /usr/bin no  ....   Sometimes I hate the code I inherited.
Dec 19 16:55:29 <rburton> and this is why i love autotools - it has a function to find a tool, which searches $path, and can be overridden with an environment variable
Dec 19 16:55:55 <kergoth> I think that may be the first time i've ever had somene say they love autotools
Dec 19 16:55:59 <kergoth> s/had/heard/
Dec 19 16:56:18 <rburton> kergoth: it's a funny relationship
Dec 19 16:56:26 <rburton> kergoth: we've come to an understanding
Dec 19 16:56:53 <rburton> kergoth: but considering 90% of software in oe builds using autotools, its the 10% that doesn't which involves all the shouting
Dec 19 16:56:57 * eren is amazed to find someone who actually loves autohell
Dec 19 16:57:07 <kergoth> my view on the matter is, i hate it, but at least it's consistent
Dec 19 16:57:10 <kergoth> it's a known quantity
Dec 19 16:57:16 <blloyd_> kergoth: I love autotools.  I've switched my stuff from custom scripts to autoconf based builds.  I can generally follow the automake make files too.  Needless to say, the framework doesn't use automake and bastardized autoconf.
Dec 19 16:57:19 <kergoth> i'd rather have that than 47 custom homerolled make-based systems
Dec 19 16:57:37 <kergoth> but i still think it sucks :)
Dec 19 16:57:41 <rburton> kergoth: its known and the compexity that newcomers hate is actually required when cross-building :)
Dec 19 16:57:50 <eren> isn't CMake a better alternative?
Dec 19 16:58:02 <kergoth> ugh, you know what i hate about cmake, and it seems petty, but i don't care
Dec 19 16:58:07 <kergoth> having its shit use the .txt extension
Dec 19 16:58:09 <kergoth> UGH
Dec 19 16:58:10 <kergoth> :)
Dec 19 16:58:20 <rburton> eren: cmake makes it far too difficult to use pkgconfig
Dec 19 16:58:33 <eren> kergoth: which build system do you like? :)
Dec 19 16:58:35 <blloyd_> I've heard a lot of people like cmake, but I've seen it make a mess of cross built tools.
Dec 19 16:58:41 <kergoth> eren: I haven't found one yet :)
Dec 19 16:58:59 <eren> I guess there is one option left: start building one :P
Dec 19 16:59:34 <kergoth> i'm not that much of a masochist
Dec 19 16:59:36 <rburton> blloyd_: in my limited experience, cmake gets very verbose very quickly
Dec 19 16:59:43 <kergoth> though you wouldn't think that to look at the bitbake code
Dec 19 16:59:48 <blloyd_> personally, I would rather enhance automake.  Specifically the documentation.  Lots of people misuse/do things the hard way because it is not well documented.
Dec 19 17:00:09 <rburton> blloyd_: you've seen the autotools book?
Dec 19 17:00:55 <kergoth> i think one of the biggest problems isn't the build tool itself, but the fact that we have so very few configuration management folk contributing to open source projects, and a ton of coders who know nothing about buildsystems copying and pasting terrible stuff
Dec 19 17:00:56 <rburton> ooh ther'es a new book (C) 2010
Dec 19 17:00:59 <blloyd_> yes I have.  It needs to be better advertised.  I've referenced that book often enough.
Dec 19 17:01:30 * kergoth thinks the emphasis on 'show me the code' in open source over the years was a mistake, and is so very glad yocto has documentation people
Dec 19 17:02:01 * kergoth could rant about such things for some time, so goes back to work
Dec 19 17:02:01 <blloyd_> I agree kergoth.  One problem with show me the code is it shows what it DOES, not what it SHOULD do.
Dec 19 17:04:42 <kergoth> okay, this amuses me
Dec 19 17:04:44 <kergoth> "-std=gnu99 -pipe -DANOTHER_BRICK_IN_THE -Wall -W"
Dec 19 17:04:52 <kergoth> admittedly, i'm easily amused
Dec 19 17:05:28 <blloyd_> btw, what you call configuration management you might have better luck finding the kind of people you want looking for integration management personnel.  Configuration management is traditionally book-keeping...  And software configuration to use other libraries is a case of integration management.  :)
Dec 19 17:10:48 <otavio> cmake and autotools, both has pros and cons ... I've been moving Qt apps and cross libraries to cmake as we've been working in Windows embedded OS too and cmake is nicer for it (autotools can be done but... not that easy)
Dec 19 17:11:17 <otavio> but in fact I think autotools are easier to use than cmake
Dec 19 17:11:20 <kergoth> one thing i dislike about autotools is the tendency for heavy recursive make use
Dec 19 17:11:22 <blloyd_> yes, non-unix is autotools drawback.
Dec 19 17:11:22 <otavio> cmake you need to be too verbose
Dec 19 17:11:42 <blloyd_> kergoth: that isn't autotools fault.  I have non-recursive projects.  I hate recursive make.
Dec 19 17:11:50 <otavio> and another con of cmake is that many things are not done yet
Dec 19 17:12:38 <blloyd_> it was actually fairly easy and autoconf/automake has had non-recursive make well supported for close to a decade.
Dec 19 17:12:46 <otavio> blloyd_: by this you say like: make SRCDIRS ; and this make -C <dir> foo and so on?
Dec 19 17:13:15 <blloyd_> as in my makefile does not have a SRCDIRS variable....
Dec 19 17:13:36 <blloyd_> (and that is Makefile SINGULAR)
Dec 19 17:13:56 <otavio> blloyd_: so you do all in a topdir makefile.am?
Dec 19 17:14:18 * otavio like to have makefile.am per lib or app
Dec 19 17:14:25 <eren> blloyd_: can you paste the url for the book?
Dec 19 17:14:30 <eren> I need a good autotools documentation
Dec 19 17:14:35 <blloyd_> yes, but source files exist in subdirectories just fine.
Dec 19 17:15:24 <otavio> blloyd_: yes
Dec 19 17:15:28 <blloyd_> I tend to do one and only one makefile for an app.  I have several apps that are broken down into convenience libraries so we don't exceed the 1024 character limit on command lines.
Dec 19 17:16:15 <otavio> blloyd_: I can see the benefit of a single makefile but I try to have build modular, as the source
Dec 19 17:16:51 <blloyd_> and so that Makefile has the static libraries for the app and the app in a single makefile.  Stupid things takes me 10 minutes to build (on a system that builds core-image-sato in 70ish minutes on a slow day).
Dec 19 17:19:05 * eren brb
Dec 19 17:19:30 <blloyd_> http://www.sourceware.org/autobook/ is one I use.  Not sure about rburton's 2010 version.
Dec 19 17:19:48 <otavio> blloyd_: well, it is a matter of taste i think
Dec 19 17:19:48 <otavio> hhehehe
Dec 19 17:20:09 <blloyd_> but it is probably this one http://www.amazon.com/Autotools-Practioners-Autoconf-Automake-Libtool/dp/1593272065
Dec 19 17:20:59 <blloyd_> (oh, said project should take about 2 minutes to compile, and took me 30 minutes using my predecessors build system)
Dec 19 17:25:37 <eren> blloyd_: did you refer this book, which seems to be released in 2010? http://nostarch.com/autotools.htm
Dec 19 17:31:59 <blloyd_> That looks like same book I pointed to on Amazon.  I didn't use it.  I have been using autoconf for 10+ years now, so the hard copy books I own are a bit dated.  :)
Dec 19 17:32:16 <eren> oh okkie :)
Dec 19 17:34:07 <blloyd_> btw, about the yocto project having documentation:  anyone want to count the times I've been sent to read the code.  :)
Dec 19 17:35:24 <blloyd_> otavio: my simple solution for supporting windows.  Use autoconf for 99.9% of systems out there (POSIX).  Do a visual c++ project for windows, and support one and only one set of dependencies for windows.
Dec 19 17:37:32 <Crofton|work> blloyd_, thats because most of us still haven't read the docs :)
Dec 19 17:38:00 <blloyd_> otavio: all current versions of make support include, allowing for one makefile in practice but several physical makefiles on disk.  I've not bothered doing this.  I am also a big proponent of when I change a header, I want to know EVERYWHERE I just potentially broke.
Dec 19 17:38:55 <blloyd_> oh,well.  My ability to read bitbash files has gone way up.  Now it's more a chore to find which one I care about.
Dec 19 17:58:17 <blloyd_> erin: http://miller.emu.id.au/pmiller/books/rmch/ can be helpful on automake.  It also discusses how to do non-recursive if you are trying to understand autotools.
Dec 19 17:58:30 <blloyd_> eren: ^
Dec 19 18:02:07 <eren> oh, thanks
Dec 19 19:58:58 <gjohnson> Hello all, Is there a way to determine what package a file came from in the sysroot?  I used ipkg package manager in the build.
Dec 19 20:02:16 <mranostay> opkg search
Dec 19 20:02:25 <mranostay> er wrong channel :)
Dec 19 20:07:49 <gjohnson> what do you mean wrong channel?  I am trying to do this within the cross root directory.
Dec 19 20:09:21 <subodh> where do I see what features like toochain-sdk and populate-sdk do?
Dec 19 20:11:52 <subodh> anyone here?
Dec 19 20:14:48 <mranostay> nobody
Dec 19 20:18:06 <Crofton|work> holidays coming up
Dec 19 20:26:23 * mranostay puts some coal in Crofton|work socking
Dec 19 20:28:28 <gjohnson> My sysroot contains a library that is missing in my image.  What is the best way to determine what package I need to add to my image?
Dec 19 20:34:04 <Crofton|work> what is the library?
Dec 19 20:34:18 <Crofton|work> also, look at buildhistory
Dec 19 20:34:23 <Crofton|work> that can be really handy
Dec 19 20:34:59 <gjohnson> Crofton: thanks, I need to have libstdc++.so.6
Dec 19 20:35:31 <Crofton|work> if you install a binary that uses it, it should be there
Dec 19 20:35:54 <blloyd_> btw, thanks kergoth for pointing me to binconfig.bbclass.  I couldn't use it as is, but it was a great resource to copy to get what I did need.
Dec 19 20:38:23 <gjohnson> Crofton: I built qt5 and copied the libraries over to my rasp-pi.  When I tried to run an example application I found that the basic-image doesn't have very many libraries.
**** ENDING LOGGING AT Thu Dec 20 02:59:59 2012

**** BEGIN LOGGING AT Thu Dec 20 03:00:00 2012
Dec 20 10:05:41 <lukas_bulwahn> hi, does anyone know how to write a recipe that can fetch sources from multiple git repositories? Simply providing two urls strangely does not work.
Dec 20 11:02:25 <dv_> hello. I am running my own python code in a custom populate_packages_prepend() function. I understand the contents of this function is directly prepended to populate_packages, as in, the lines are copied into it.
Dec 20 11:03:31 <dv_> however, I now see an indentation error happening in the new populate_packages() function. I already checked for tabs, there are none. is it somehow possible to extract the populate_packages() function with the prepended code, to see what it actually looks like?
Dec 20 11:12:54 <rburton> dv_: the standard is four space indentation, so check that and for any blank lines that could be destroying scope.
Dec 20 11:13:13 <dv_> the odd thing is, it works with one image, but not with another
Dec 20 11:13:27 <rburton> bitbake -e will show you the enviironment, which should include the python fragments
Dec 20 11:13:29 <dv_> which is why I would like to see the generated populate_packages() function
Dec 20 11:13:34 <dv_> ah nice, thanks
Dec 20 11:15:56 <dv_> here is a snippet of the error and the last bits of my prepend function: http://pastie.org/5556628
Dec 20 11:16:15 <dv_> do I have to insert a space before the end of the _prepend scope?
Dec 20 16:01:27 <kergoth> damnit
Dec 20 16:05:04 <Crofton|work> that bad?
Dec 20 16:10:46 <kergoth> discovered parted can't use custom partition alignments
Dec 20 16:10:58 <kergoth> which means you can't control that when using it to create disk images
Dec 20 16:11:13 <kergoth> it can only obey the device, but of course a file won't provide any useful info for that
Dec 20 16:11:28 <kergoth> tried using pyparted, but then realized that pyparted is GPL-2.0, which would infect a bbclass trying to use it
Dec 20 16:11:31 * kergoth mutters
Dec 20 16:13:39 <kergoth> guess could make a standalone tool and have the bbclass run that, though thats getting a little iffy
Dec 20 16:13:51 <kergoth> maybe should just try patching parted proper to provide more options
Dec 20 16:19:02 <otavio> kergoth: the optimal alignment doesn't work?
Dec 20 16:20:07 <otavio> kergoth: and is it gpt or mbr?
Dec 20 16:26:30 <kergoth> it's operating against a file, i doubt 'optimal' has any real meaning without a backing disk
Dec 20 16:26:46 <kergoth> but *shrug*, i'm new at this
Dec 20 16:27:22 <kergoth> maybe i'm misinterpreting and alignment isn't my issue, but i have one panda sd card image that works which uses the old chs 63 sector aligned partitions, and one that doesn't which uses 2048 sector aligned
Dec 20 16:32:47 <otavio> kergoth: you can pass exact sizes if you calculate the sectors
Dec 20 16:33:02 <otavio> kergoth: and also if you give kB sizes
Dec 20 16:47:54 <kergoth> hmm, good point. specify no alignment, align manually..
Dec 20 17:11:03 <dv_> is there a way to disable a part of a recipe if it is not parsed by Yocto, but for example by Angstrom or Arago?
Dec 20 17:11:18 <dv_> something like #ifdef YOCTO ... #endif  in C
Dec 20 17:11:30 <rburton> you can mark all variables with distro-specific overrides
Dec 20 17:11:53 <rburton> i.e. EXTRA_OECONF_poky
Dec 20 17:12:13 <dv_> this is unfortunately not about variables, but about a prepend() function
Dec 20 17:12:24 <dv_> Yocto uses 4 spaces to indent in python, Arago uses tabs
Dec 20 17:12:33 <dv_> and we have to support Arago as well :/
Dec 20 17:12:59 <rburton> doesn't arago work on top of oe-core?
Dec 20 17:13:22 <dv_> yes, but something very old
Dec 20 17:13:30 <rburton> oh
Dec 20 17:13:32 <rburton> fun
Dec 20 17:13:36 <dv_> you have to use ubuntu 10.10 to build, nothing else will work
Dec 20 17:13:39 <blloyd_> I'm positive this has been done before: are there any samples I can look at for how to configure a yocto based device to run a gui (X) program at startup where it is the only program available via console?
Dec 20 17:13:41 <rburton> oh god its oe-classic
Dec 20 17:14:03 <dv_> yeah, it does not have the progress bar at the beginning, but that spinning line character instead
Dec 20 17:14:53 <kergoth> heh, that sucks, parsing time was horrendous back then
Dec 20 17:15:03 <rburton> blloyd_: there's a meta-kiosk somewhere
Dec 20 17:15:08 <dv_> can I attach a distro override to function names as well?
Dec 20 17:15:15 <dv_> like, populate_package_prepend_yocto?
Dec 20 17:15:16 <kergoth> yes
Dec 20 17:15:24 <dv_> will this also work with OE classic?
Dec 20 17:15:31 <kergoth> yocto isn't a distro, though :)
Dec 20 17:15:32 <rburton> blloyd_: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=emac/meta-web-kiosk
Dec 20 17:15:38 <dv_> so, populate_package_prepend_arago?
Dec 20 17:15:44 <kergoth> thats standard overrides use, been that way for years
Dec 20 17:15:45 <dv_> err, I meant _poky, not _yocto
Dec 20 17:15:45 <rburton> blloyd_: that starts just a browser on startup
Dec 20 17:15:50 <dv_> cool, will try that
Dec 20 17:16:12 <rburton> blloyd_: basically just change the x init script, which currently starts matchbox desktop etc, to start mbwm and your app
Dec 20 17:19:52 <denix> dv_: why not use meta-arago? Which is a new version of arago for oe-core?
Dec 20 17:20:19 <dv_> because this is a separate infrastructure for a specific set of boards
Dec 20 17:20:38 <dv_> and we are not the maintainers, we just develop software for these
Dec 20 17:21:47 <denix> Other than that, I don't understand the issue with spaces vs. tabs - it didn't matter with Classic OE
Dec 20 17:22:15 <kergoth> that's not precisely true. you still would hit issues append/prepending to python functions
Dec 20 17:22:21 <kergoth> had to matcht he indentation of what you appended to
Dec 20 17:22:29 <kergoth> and he's appending to populate_packages..
Dec 20 17:22:33 <denix> then why are you asking question related to oe-core?
Dec 20 17:23:06 <kergoth> that's a good question, there's no way you can reasonably expect to have metadata work both in oe classic and oe core. use branches or something
Dec 20 17:23:23 <denix> kergoth: exactly
Dec 20 17:24:24 <dv_> you mean, two versions of the script, one for classic, one for core
Dec 20 17:27:14 <blloyd_> rburton: thank you very much.  Basically doing the same thing, so that will be a great example
Dec 20 17:27:36 <rburton> blloyd_: i thought that repo was more obvious
Dec 20 17:27:40 <rburton> i'll see if we can fix that
Dec 20 17:28:15 <blloyd_> probably my fault.  Not enough sleep recently.  I probably read right over it and it didn't click.
Dec 20 17:28:31 <rburton> blloyd_: you didn't, its one of hundreds of branches in poky-contrib
Dec 20 17:28:41 <rburton> i only found it as i knew who created it
Dec 20 17:35:04 <blloyd_> btw, it used to be easy to find poky-contrib repo on the website.  I seem to be going blind, as now I would have to read the documentation to find it.  The site itself seems to have removed information about the repos.
Dec 20 17:36:12 <rburton> blloyd_: fourth down on http://git.yoctoproject.org/...
Dec 20 17:36:45 <blloyd_> yoctoproject.org doesn't mention git.yoctoproject.org....
Dec 20 17:37:31 <dv_> ok, the _poky and _arago idea works
Dec 20 17:38:45 <rburton> blloyd_: well, downloads->danny has a link to it
Dec 20 17:39:38 <blloyd_> ok, I'm on downloads page was looking for it.  BTW, how easy is it to move from denzil to danny?
Dec 20 17:41:47 <blloyd_> found that.  I like that for grabbing from git instead of downloading a tarball, but the general information of we have a git repository server that may be browsed here is missing from the site.
Dec 20 17:42:29 <rburton> blloyd_: it's not massively tricky.  the most annoying bit is fixing the whitespace
Dec 20 17:42:41 <rburton> porting guaca from denzil to danny took a few days
Dec 20 17:44:22 <blloyd_> thanks rburton.  I'll wait a little longer then.  Maybe hop on the bandwagon when 8.1 comes out.  Also why is there two version numbers (1.3 and 8.0) for danny?
Dec 20 17:44:36 <rburton> blloyd_: oe-core 1.3 / poky 8
Dec 20 17:44:43 <blloyd_> oh.
Dec 20 17:44:49 <blloyd_> that makes sense.
Dec 20 17:44:58 <rburton> early poky pre-dates oe-core
Dec 20 17:45:18 <rburton> and now we sync poky to oe-core
Dec 20 18:01:14 <seebs> Quick question: Has anyone done anything with arm BE8 on Yocto? I ask because I'm about to try to add configuration knobs for it, and if someone else has already picked spellings, I'd rather not clash.
Dec 20 18:09:23 <seebs> I note that machine/include/arm/README already refers to ARMPKGSFX_ENDIAN, but it seems to be unimplemented.
Dec 20 18:10:29 <seebs> Oh, wait. It's defined, it's just not used in TUNE_PKGARCH.
Dec 20 18:10:41 <seebs> And I see no distinction between be8 and be32.
Dec 20 18:13:44 <seebs> Anyone have opinions on that? My preference would be to define be8 as a distinct TUNEVALID, and then have be8 targets define both that and bigendian. The reason is, I have experienced an issue wherein people who are told that they are getting big-endian ARM demand high-level conference calls in which there is Great Drama because they have no interest in big-endian, what they need is BE8.
Dec 20 18:33:28 <sgw1> seebs: any news on the pseudo update?
Dec 20 18:38:50 <seebs> ... I think it basically summarizes my mental state at the moment to observe that I have completely lost all recollection of that.
Dec 20 18:39:15 <seebs> I've been tracking down bugs, and the bugs that they were covering for, and I've sort of lost all other state. Hmm.
Dec 20 18:39:31 <seebs> This was related to the libdir/sqlite stuff, right?
Dec 20 18:43:02 <sgw1> seebs: yes, it seemed to be host contamination for sqlite
Dec 20 18:43:59 <seebs> Oh!
Dec 20 18:44:01 <seebs> I remember.
Dec 20 18:44:09 <seebs> I haven't got the cycles to usefully help, but:
Dec 20 18:44:21 <seebs> It used to be --with-sqlite=A --enable-static-sqlite
Dec 20 18:44:35 <seebs> I changed it to --with-static-sqlite=A/usr/lib/libsqlite3.a
Dec 20 18:44:47 <seebs> It should be --with-sqlite=A --with-static-sqlite=A/usr/lib/libsqlite3.a
Dec 20 18:45:17 <seebs> The --with-static-sqlite argument just overrides attempts to computer the path to libsqlite3.a.
Dec 20 18:45:24 <seebs> It doesn't hint at where to look for headers.
Dec 20 18:47:03 <sgw1> seebs: you want me to test that out?
Dec 20 18:47:20 <seebs> If you could. Sorry to drop the ball on this one, I'm overscheduled right now.
Dec 20 18:48:59 <sgw1> seebs: no problem, later today or tomorrow I will report back
Dec 20 18:56:31 <Crofton|work> I would like to complain
Dec 20 18:56:39 <Crofton|work> >>> from gi.repository import GObject
Dec 20 18:56:48 <Crofton|work> fails on th emy rootfs from oe-core
Dec 20 18:57:05 <Crofton|work> and I can't find how to install the python magic to fix this
Dec 20 18:57:20 <Crofton|work> seems like it comes from python-gobject, but not in the build
Dec 20 18:57:50 <Crofton|work> since this does not work, the simple-agent script you need to pair bt stuff will not run
Dec 20 18:58:10 <Crofton|work> needless to say, this is annoying
Dec 20 19:08:44 <sgw1> seebs: fixed it, you want me to patch your work?
Dec 20 19:09:15 <seebs> That would be awesome, yes.
Dec 20 19:12:26 <seebs> ...
Dec 20 19:12:52 <seebs> So, about 8 lines in arch-armv7a.inc use PACKAGE_EXTRA_ARCHS_tune-armv6* as their basis, and the rest use ...-armv7.
Dec 20 19:13:00 <seebs> Is that a typo? Because it sure seems like one.
Dec 20 19:28:36 <seebs> On further study: No, it's not, I'm just being bitten by an unrelated issue.
Dec 20 20:27:38 <kergoth> ugh, meta-ti's u-boot.inc doesn't properly use deploy.bbclass, so u-boot doesn't come back into DEPLOY_DIR_IMAGE when building from sstate
Dec 20 20:27:42 * kergoth rolls eyes
Dec 20 20:30:55 <blloyd_> rburton: do you know much about the poky-contrib for the browser?  Like what version of poky it was for?
Dec 20 20:46:50 <halstead> pidge, Got it.
Dec 20 20:47:08 <halstead> sgw1, Let me check I still have a monitor running.
Dec 20 20:49:15 <_julian_> hi
Dec 20 20:49:40 <_julian_> I try to build vlc from a devshell, but run into some trouble. configure runs fine with these args http://pastebin.com/HSPyRh2A
Dec 20 20:50:16 <halstead> sgw1, The libowl download has completed successfully the last 6310 times or for almost 8 days. I think increasing the connection count on the router fixed it. I'll update the bug.
Dec 20 20:50:22 <_julian_> but when I run make I immediately see this: http://pastebin.com/u8dADdVE
Dec 20 20:50:47 <_julian_> any thoghts what might be wrong there?
Dec 20 20:51:44 <sgw1> halstead: thanks I will have to check with the QA team for if/when they got the latest failure.
Dec 20 20:52:08 <_julian_> ah there it should use arm-poky-linux-gnueabi-libtool...
Dec 20 20:52:41 <halstead> sgw1, I see Laurentiu posted a problem 7 days ago. I'll ask him for his proxy settings.
Dec 20 20:59:22 <halstead> pidge, Why does autobuilder.yoctoproject.org:9989 need to be exposed to the public Internet?
Dec 20 21:00:12 <pidge_> halstead: actually, it shouldn't be public.
Dec 20 21:00:38 <halstead> Does anything outside the cluster connect there?
Dec 20 21:01:45 <pidge_> no, ignore my request. the ab slaves were just being slow to connect.
Dec 20 22:59:11 <blloyd_> is there an easy way to have a package create an empty directory?  For instance /usr/share/myapp?
Dec 20 23:00:40 <mranostay> blloyd_: mkdir -p /blah/blah
Dec 20 23:00:46 <mranostay> in a do_install_append()
Dec 20 23:01:09 <ant_home> FILES_${PN} += " ${bindir}/blah /init /proc /mnt /dev /sys"
Dec 20 23:01:49 <ant_home> afterwards
Dec 20 23:01:54 <mranostay> ah yes
Dec 20 23:01:59 <blloyd_> so it will place a directory with nothing in it?  It looked to be stripping them out.  I'll try again.
Dec 20 23:02:22 <ant_home> first hack do_install then package th eempty dir
Dec 21 00:21:11 <EddyLaiTw> Hi , I'm Eddy , a newbie to yocto and use yocto 1.3 on jasperforest BSP
Dec 21 00:21:32 <EddyLaiTw> have build the USB flash drive and boot on target h/w
Dec 21 00:23:36 <EddyLaiTw> but after trying to add "igb" for 82580DB network controller support in jasperforst.conf "KERNEL_FEATURES_append" = "features/igb"
Dec 21 00:24:07 <EddyLaiTw> build done but after the target boot, there's no etho port present
Dec 21 00:25:21 <EddyLaiTw> how can I check if the igb driver is inclued and loaded in the target?
Dec 21 00:40:09 <EddyLaiTw> anybody here?
Dec 21 00:56:03 <EddyLaiTw> hi himamura
Dec 21 01:04:32 <EddyLaiTw> IRC bots?
Dec 21 01:05:11 <wmat> EddyLaiTw: sometimes on IRC, questions are not responded to immediately
Dec 21 01:05:19 <EddyLaiTw> ok
Dec 21 01:05:34 <EddyLaiTw> I just just port the question on the list
Dec 21 01:05:36 <EddyLaiTw> hope that works
Dec 21 01:05:39 <EddyLaiTw> thank you
Dec 21 01:06:25 <wmat> can you access a console on the target?
Dec 21 01:06:36 <EddyLaiTw> do you use web IRC interface? or use a client app?
Dec 21 01:06:45 <wmat> i use irssi
Dec 21 01:06:50 <EddyLaiTw> yes, the console is working
Dec 21 01:06:59 <wmat> what does lsmod show?
Dec 21 01:07:11 <EddyLaiTw> so I can see the output of "ifconfig -a"
Dec 21 01:08:00 <EddyLaiTw> lsmod says "Not tainted"
Dec 21 01:14:46 <wmat> that's it?  it doesn't list the kernel modules in use?
Dec 21 01:15:02 <EddyLaiTw> no
Dec 21 01:15:43 <wmat> try modprove igb
Dec 21 01:15:50 <EddyLaiTw> how can I know if the igb driver built as a single "kernel module" or just inside the kernel?
Dec 21 01:15:51 <wmat> sorry, modprobe igb
Dec 21 01:16:18 <EddyLaiTw> "modprobe: module igb not found in modules.dep"
Dec 21 01:17:49 <wmat> dmesg | grep eth
Dec 21 01:18:14 <EddyLaiTw> nothing
Dec 21 01:20:35 <EddyLaiTw> there are "e100", "e1000", "e1000e" in the dmesg, but no "igb" or related found
Dec 21 01:30:53 <EddyLaiTw> hi , how can I connect to this channel with Irssi?
Dec 21 01:31:23 <EddyLaiTw> connect freenode.net then join #yocto ?
Dec 21 01:33:43 <EddyLaiTw> got it
Dec 21 01:49:18 <EddyLai> hi
Dec 21 01:51:54 <himamura> @EddyLaiTw hi, I'm not bot w
Dec 21 02:04:47 <EddyLaiTw> :-p
Dec 21 02:06:24 <EddyLaiTw> it's 10:00am my time in Taiwan, is it dinner time yours?
Dec 21 02:07:21 <himamura> no I'm Japanese, So 11:00 am
Dec 21 02:07:21 <wmat> it's 9:07pm EST
Dec 21 02:07:49 <blloyd> EddyLaiTw: try KERNEL_FEATURES += "igb"
Dec 21 02:08:12 <EddyLaiTw> ok
Dec 21 02:08:19 <blloyd> or KERNEL_FEATURES += "features/igb"
Dec 21 02:08:21 <EddyLaiTw> thanks
Dec 21 02:09:19 <blloyd> KERNEL_FEATURES_append (without quotes I hope) = "features/ibg" will be problematic.  Namely, say KERNEL_FEATURES = "myfeature" before.  After it would be "myfeaturefeatures/igb"
Dec 21 02:09:25 <EddyLaiTw> if I have something type wrong after the +="... , will there be any error messages?
Dec 21 02:09:53 <blloyd> possibly a warning that file not found when building the kernel.
Dec 21 02:10:18 <EddyLaiTw> thanks, trying...
Dec 21 02:10:31 <blloyd> basically, _append doesn't add spacing or anything.
Dec 21 02:11:03 <blloyd> += adds spacing between what is added and what was there.
Dec 21 02:27:53 <EddyLaiTw> use KERNEL_FEATURES += "features/igb" can build
Dec 21 02:28:07 <EddyLaiTw> but same no eth0 after boot, and not able to use "modprobe igb"
Dec 21 02:29:31 <EddyLaiTw> how can I check how the [KERNEL_FEATURES += "features/igb"] effect the build source tree?
Dec 21 02:40:30 <EddyLaiTw> according to  ch.4.1.2.2 of "Development Manual", I can use "yocto-kernel config list jasperforest"
Dec 21 02:40:38 <EddyLaiTw> but how can I use "menuconfig"?
**** ENDING LOGGING AT Fri Dec 21 02:59:59 2012

**** BEGIN LOGGING AT Fri Dec 21 02:59:59 2012
Dec 21 03:05:03 <EddyLai> believe himamura is a BOT!
Dec 21 03:05:23 <himamura> noooo!
Dec 21 03:05:28 <EddyLai> haha
Dec 21 03:06:33 <blloyd> what package do I need to force built to get tunctl in the native build sysroot?
Dec 21 03:26:11 <EddyLai> how to cofig yocto include ethtool?
Dec 21 03:29:41 <blloyd> do you want it in an image or just your sysroot?
Dec 21 03:38:15 <EddyLai> what's the different?I can try both
Dec 21 03:38:52 <EddyLai> just want to see what ethtool says on the target
Dec 21 03:41:29 <Eddy> please tell me how to make it inside the image, and just build single app in sysroot
Dec 21 03:44:22 <blloyd> in your local.conf file, add CORE_IMAGE_EXTRA_INSTALL += "ethtool"
Dec 21 03:44:38 <blloyd> then bitbake core-image-WHICHEVERONE
Dec 21 03:46:56 <Eddy> thanks, blloyd
Dec 21 04:04:04 <blloyd> got my problem figured out.  BTW, it's annoying that qemu-ifup wouldn't run when the base system's tunctl supported the needed functionality.
Dec 21 04:27:50 <Eddy> hi blloyd, how can I add sshd to target
Dec 21 04:28:06 <Eddy> or how can I uplaod my testing apps into target
Dec 21 04:29:54 <Eddy> just hope not to build and re-make the bootable image for single app testing
Dec 21 04:32:21 <Eddy> have you tried telnetd, ftpd, sshd or smbd in yocto?
Dec 21 04:33:02 <Eddy> same configure method as ethtool?
Dec 21 06:06:33 <Biao> hello
Dec 21 06:07:08 <Biao> import sys         sys.__stdout__.write("I am the python output\n")
Dec 21 06:07:29 <Biao> where does the sys._stdout__.write goes?
Dec 21 06:07:49 <Biao> It is not in my terminal, not in task log either
Dec 21 08:23:22 <mckoan> good morning
Dec 21 08:52:57 <ant_work> JaMa: any comment about 40021 ?
Dec 21 08:53:26 <ant_work> (I've ordered a collie on ebay fwiw)
Dec 21 10:28:13 <peachj> I'm trying to build systemd from meta-systemd and I'm hitting the error here: http://pastebin.com/3EeHMTtG
Dec 21 10:28:58 <peachj> Thoughts as to why?  I'm not sure how to fix it.
Dec 21 13:15:26 <rburton> JaMa: erm, yeah, actually conflicting with vala would be a good move wouldn't it ;)
Dec 21 13:17:40 <JaMa> rburton: why?
Dec 21 13:18:17 <rburton> well, they do conflict
Dec 21 13:18:21 <rburton> they share a file
Dec 21 13:18:25 <rburton> adding missing depends now
Dec 21 13:18:31 <JaMa> breaking everything which depends on vala-native already..
Dec 21 13:18:49 <rburton> JaMa: well they both provide it, so meta-oe just needs a preferred provider
Dec 21 13:19:14 <JaMa> I don't think so
Dec 21 13:19:21 <rburton> why not?
Dec 21 13:19:23 <JaMa> vala-stub and vala-native does not provide the same
Dec 21 13:19:46 <JaMa> some packages need valac to build
Dec 21 13:20:32 <JaMa> and using vala-stub provider will break them (not something I would expect from P_P)
Dec 21 13:20:57 <rburton> JaMa: got an alternative that doesn't involve pulling vala into oe-core?
Dec 21 13:21:36 <rburton> bloody m4 macros, why can't people just use pkgconfig :/
Dec 21 13:21:48 <JaMa> hack it in recipes where it's really optional?
Dec 21 13:22:19 <rburton> that isn't also a hack, would be nice
Dec 21 13:22:28 <rburton> we used to hack gtk-doc around and that turned into a right mess
Dec 21 13:23:13 <JaMa> yes but in that case there wasn't working gtk-doc-native, required by some recipes
Dec 21 13:25:01 <rburton> JaMa: hacking a stub vala.m4 doesn't let someone swap it for a real vala and get the vapi stuff
Dec 21 13:27:49 <rburton> in gupnp the vala stuff is conditional on g-i existing
Dec 21 13:28:10 <rburton> maybe for now i'll sed it out of the configure
Dec 21 14:13:23 <eren> rburton: are you English? :)
Dec 21 15:28:35 <rburton> eren: i am
Dec 21 15:29:21 <eren> rburton: oh okkie. Whenever I see someone using "bloody", I immediately think that he/she is English
Dec 21 15:29:47 <rburton> and you'd be right :)
Dec 21 15:39:15 <schramae> how does one clean the image files in the deploy directory? "bitbake -c clean(all)" doesn't do the job and the txt files says not to delete them manually
Dec 21 15:39:47 <rburton> it only says don't delete them as they won't get magically rebuilt
Dec 21 15:39:50 <JaMa> delete them manually if you don't need them
Dec 21 15:39:51 <rburton> if you don't need some, delete them
Dec 21 15:40:08 <schramae> i see, thx
Dec 21 16:06:18 <cristianiorga> A Happy New Year! to everyone celebrating it.
Dec 21 16:06:53 <cristianiorga> Merry Christmas! to everyone celebrating it.
Dec 21 16:36:09 <ant_work> JaMa: collie is here. I'll test armv4 runtime finally
Dec 21 16:50:00 <rburton> wow, collie
Dec 21 16:50:06 <rburton> i wonder if i still have my akita somewhere
Dec 21 16:55:18 <ant_work> rburton: you know what's the most disturbing thing testing on this old hw? The lack of xinput-calibrator in oe-core.
Dec 21 16:56:19 <ant_work> We already discussed the opportunity to pull it from meta-oe and there are some contrasts
Dec 21 16:57:12 <rburton> ant_work: yeah, i'm trying to find something convenient and useful for testing touchscreens
Dec 21 16:57:17 <ant_work> maybe the matter is worth a rebump in the ML
Dec 21 16:57:32 <rburton> ant_work: the office lenovo netbook+touchscreen has been stolen by the IVI people
Dec 21 16:57:53 <rburton> ant_work: certainly do rebumb - this is something i want to get fixed for 1.4
Dec 21 16:58:13 <rburton> dropping the bits of X that are kdrive specific and making sure the xi calibration stuff actually works
Dec 21 16:58:54 <ant_work> yes, I'm lazy and avoided to provide my .pointercal files
Dec 21 16:59:49 <ant_work> yours sounds a good plan
Dec 21 17:00:10 <ant_work> we dropped kdrive long ago, isn't?
Dec 21 17:00:15 <rburton> yes
Dec 21 17:00:20 <rburton> tscal got left behind
Dec 21 17:00:39 <ant_work> iirc I've seen it in the qt-demo images
Dec 21 17:01:13 <ant_work> they're still using tslib if I'm not wrong
Dec 21 17:01:43 <ant_work> but we should really rely on xinput
Dec 21 17:02:01 <ant_work> for the X images
Dec 21 17:02:04 <rburton> yes
Dec 21 17:02:25 <rburton> ant_work: pulling xinput-calibrator into oe-core makes perfect sense
Dec 21 17:03:22 <ant_work> that way you can test with oe-core + bsp layer only, avoiding extra-issues
Dec 21 17:04:02 <ant_work> well, to be fair, potential extra issues
Dec 21 17:12:55 <schramae> i updated the danny branch today and after deleting the deploy images and rebuilding, the image does not boot anymore. suspect seems to be "initrdscripts: fix udevd in the live boot init scripts", when mounting the rootfs there is no "/lib/udev/udevd", but "/sbin/udevd". i already cleaned/rebuilt udev and the image, but that did not help.
Dec 21 17:15:11 <rburton> huh
Dec 21 17:15:23 <rburton> schramae: using meta-oe?
Dec 21 17:15:36 <rburton> i tested that before pushing the branch :/
Dec 21 17:16:05 <ant_work> omg, again
Dec 21 17:16:17 <schramae> no, just a clone of danny with a custom layer
Dec 21 17:16:36 <rburton> gnar
Dec 21 17:16:40 <ant_work> this udev is hard to die
Dec 21 17:17:20 <rburton> schramae: quick fix is to fixup that commit to use the right path
Dec 21 17:17:24 <rburton> schramae: hddimg?
Dec 21 17:18:17 <rburton> schramae: i'll be disappearing shortly but i'm the danny man - feel free to file a bug and mail ross.burton@intel.com with fixes/thoughts/moans.
Dec 21 17:18:44 <schramae> yes, hddimg. i just cleaned initramfs-framework and am rebuilding the hddimg right now
Dec 21 17:18:52 <schramae> rburton: ok, thanks
Dec 21 17:19:35 <rburton> schramae: i could believe its got the wrong paths - there was utter confusion with the udev paths moving . i'm sure i tested it though but maybe it picked up the wrong initramfs or something :/
Dec 21 17:20:53 <schramae> maybe a switch to eudev would help *g*
Dec 21 17:21:15 <rburton> haha
Dec 21 17:21:30 <rburton> just devtmpfs will do
Dec 21 17:27:53 <schramae> ok, clean and rebuild of initramfs/hddimg did not help. i already tried mounting the img and set up a symlink in /lib/udev before, but then it complained about the img being corrupt. will changing "/lib/udev/udevd" in init-live.sh do the trick or do i have to revert the whole commit?
Dec 21 17:29:25 <rburton> schramae: fixing the paths will do the job
Dec 21 17:30:03 <schramae> i'll try, thanks
Dec 21 17:36:15 <schramae> yap, that did the trick :)
Dec 21 17:39:06 <rburton> schramae: feel free to sent a patch to oe-core with "danny" in the subject somewhere
Dec 21 17:41:01 <schramae> is this a bug for sure or may it be related to some fuckup because of the update and incremental building?
Dec 21 17:41:20 <rburton> schramae: i'll compare your patch to what i have locally and test a build myself
Dec 21 17:41:39 <rburton> schramae: but i wouldn't be surprised if it regressed in the chaos of udev locations
Dec 21 17:51:56 <blloyd> anyone know if the matchbox desktop project has died or been moved?
Dec 21 18:02:21 <schramae> blloyd: looks like the intel nameserver is broken, it does not return an A record
Dec 21 18:03:15 <blloyd> intel who hosts it?
Dec 21 18:05:51 <schramae> $ whois matchbox-project.org | grep 'Registrant Organization'
Dec 21 18:05:52 <schramae> Registrant Organization:Intel Corporation
Dec 21 18:26:03 <blloyd> well, I like that whois tool.  Thanks for pointing me to it.  :)
Dec 21 18:29:00 <schramae> np. do "host -av matchbox-project.org" in the console and look at the answer section. there are only NS records, but no A records, thus the IP to the domain name is not resolvable
Dec 21 18:33:01 <blloyd> host is a nice change from nslookup, which just told me no authoritative answer.  Thanks for the pointers.
Dec 21 18:34:55 <blloyd> hey, I remember a RREQUIRES and REQUIRES keywords, couldn't remember the difference.  Went to the "wonderful" documents (where I have seen it before.  Current documents don't seem to have either.  Where did they go?
Dec 21 18:37:53 <blloyd> or can I short circuit it?  What do I need to add to a recipe that requires program X including in package Z-X, so that the required package is installed when the package needing it is?  Libraries may be handled automatically, but programs are not.
Dec 21 18:39:04 <schramae> do you mean RDEPENDS?
Dec 21 18:39:45 <blloyd> probably.  My memory can do tricks on me.  Searching for wrong term helps me not at all.  :(
Dec 21 18:39:58 <blloyd> so DEPENDS and RDEPENDS.
Dec 21 18:40:16 <blloyd> that I can find.  Thanks
Dec 21 18:40:25 <schramae> np
Dec 21 19:19:27 <blloyd> anyone have any suggestions on ways that do_rootfs can be sped up?  Or is it just one of those things where that step does a lot more than most steps?
Dec 21 19:24:12 <schramae> blloyd: https://wiki.yoctoproject.org/wiki/Build_Performance
Dec 21 19:30:47 <martin3> hey guys
Dec 21 19:30:56 <martin3> i want to remove a patch from a package
Dec 21 19:31:02 <martin3> but not by overriding
Dec 21 19:31:10 <martin3> best would be with a bbappend
Dec 21 19:31:44 <martin3> but its not so easy to manipulate the src_uri list
Dec 21 19:33:17 <blloyd> martin3: don't remove it.  Add your own version of the patch that is empty in the .bbappend and have bbapped prepend that directory to the search path for files.  Basically, mask the previous patch.
Dec 21 19:34:55 <martin3> ah
Dec 21 19:34:58 <martin3> thats a good idea
Dec 21 19:35:08 <martin3> anyway perhaps someone should have a deeper look on it
Dec 21 19:35:10 <martin3> its findutils
Dec 21 19:35:39 <martin3> this one patch cause segmentation fauls on this specific hardware
Dec 21 19:35:51 <martin3> because its produces unaligned code
Dec 21 19:36:02 <martin3> and even i dont see the benefit of this patch
Dec 21 19:36:10 <martin3> seems to fix only some dbeugging stuff?
Dec 21 19:36:25 <martin3> 01-27017.patch
Dec 21 20:42:50 <sgw1> seebs: you around still?  I found another issue with pseudo and the sqlite3 when build nativesdk
Dec 21 20:43:07 <seebs> noooooo
Dec 21 20:43:22 <sgw1> yes, I think it's related to your usage of prefix
Dec 21 20:43:29 <seebs> *closes eyes* it's user error, it's user error, it's u... dammit
Dec 21 20:43:33 <sgw1> seebs: did you intend to use sysroot instead?
Dec 21 20:43:40 <seebs> I... Hmm.
Dec 21 20:44:11 <seebs> You know, that is a heck of a question. I suspect I didn't *intend* to, but if you have to bet on whether I remembered the relations between various bitbake variables, bet "no".
Dec 21 20:44:47 <sgw1> seebs: Yeah, well I have the setup, so I will do a quick test here, but wanted to check with you first.
Dec 21 20:45:00 <sgw1> I can tweak it again if I get it rigth
Dec 21 20:45:29 <seebs> Thanks. I have a really hard time keeping all the directories straight in my head. Well, technically that's not true. That would imply that I was able to do it, and it was requiring effort. No, I just can't do it.
Dec 21 23:25:19 <subodh> a quick question about build
Dec 21 23:25:59 <subodh> I am trying to build chromium under yocto. I know, ugly task.. but got to do it.. near xmas :-)
Dec 21 23:26:43 <subodh> so, I see that my compile command gets passed following options.. anyone familiar about how mpentium4 sneaks in there?
Dec 21 23:26:50 <subodh> -fvisibility=hidden -m32 -march=pentium4 -msse2 -mfpmath=sse -fno-strict-aliasing -O2 -fno-ident -fdata-sections -ffunction-sections -fno-rtti -fno-threadsafe-statics -fvisibility-inlines-hidden
Dec 22 01:20:20 <Eddy_> hi
Dec 22 01:26:01 <Eddy_> do you use "yocto list"?
Dec 22 01:26:22 <Eddy_> can't find how to "search" in the list
Dec 22 02:50:54 <Eddy_> hi
**** ENDING LOGGING AT Sat Dec 22 02:59:58 2012

**** BEGIN LOGGING AT Sat Dec 22 02:59:58 2012
Dec 22 13:06:14 <EddyLai> Hi
Dec 22 13:06:29 <EddyLai> all you ready for xmas holiday now?
**** ENDING LOGGING AT Sun Dec 23 02:59:59 2012

**** BEGIN LOGGING AT Sun Dec 23 03:00:00 2012
**** ENDING LOGGING AT Mon Dec 24 02:59:58 2012

**** BEGIN LOGGING AT Mon Dec 24 02:59:58 2012
Dec 24 07:14:21 <JF_Worker> hi
Dec 24 10:32:10 <eren> hello there
Dec 24 14:14:30 <EddyLai7> ls
Dec 24 19:43:23 <bsmucker> I have what I hope is a quick question (I'm a newbie).  Using danny, when I bitbake virtual/kernel, my .config file gets CONFIG_UNION_FS=y.  Where does that come from and how can I turn it off?
Dec 24 20:18:17 <Jin^eLD> hi, has anyone tried building uclibc for armv7 / cortexa9 lately?
Dec 24 20:20:27 <Jin^eLD> fails with http://pastebin.mozilla.org/2017041
Dec 24 20:37:27 <eren> Jin^eLD: which branch are you using?
Dec 24 20:38:20 <eren> I'm not experienced on uclibc stuff but the stable branches should work without a problem
Dec 24 20:43:41 <Jin^eLD> eren: I tried danny, that failed, then tried master
Dec 24 20:43:55 <Jin^eLD> I thought danny should be one of the stable branches?
Dec 24 20:44:13 <Jin^eLD> which would should I try?
Dec 24 20:45:46 <Jin^eLD> s/would//g ;)
Dec 24 20:46:00 <eren> Jin^eLD: yeah, danny is the latest stable branch
Dec 24 20:46:13 <JaMa|Off> I don't remember any uclibc related patch which would be only in master
Dec 24 20:46:24 <JaMa|Off> so will fail the same in both branches probably
Dec 24 20:46:47 <Jin^eLD> only thing I did was create a custom machine, same as qemuarm but with DEFAULTTUNE = "cortexa9-neon"
Dec 24 20:46:53 <Jin^eLD> and require conf/machine/include/tune-cortexa9.inc
Dec 24 20:46:59 <Jin^eLD> instead of the arm9ejs
Dec 24 20:47:08 <Jin^eLD> was trying to build meta toolchain
Dec 24 20:47:16 <Jin^eLD> but wanted one with uclibc
Dec 24 20:47:48 <JaMa|Off> uclibc has much smaller test coverage then eglibc
Dec 24 20:51:59 <eren> JaMa|Off: what do you think about linker problem?
Dec 24 20:52:23 <JaMa|Off> which one
Dec 24 20:52:47 <JaMa|Off> and I'm going to play with kids.. bbl
Dec 24 20:52:57 <eren> oh okkie
Dec 24 20:53:03 <eren> JaMa|Off: oe-devel list
Dec 24 20:53:19 * eren tired, gone to sleep
Dec 24 20:53:25 <eren> good night all!
Dec 24 22:57:51 <Crofton> sgw1, take a rebak :)
Dec 24 22:57:55 <Crofton> break damn it
Dec 24 23:23:36 <mranostay> Crofton: fingers not working? :)
Dec 24 23:29:56 <sgw1> Crofton, why?  Not my holiday!
Dec 24 23:32:03 <vicom> hi
Dec 24 23:32:14 <sgw1> vicom: hi
Dec 24 23:32:16 <jf-worker> hello
Dec 24 23:33:13 <jf-worker> I have configured to add "igb" driver in the build , and the igb.ko did found in the tmp/work/linux...
Dec 24 23:33:27 <jf-worker> but not included in the binar image
Dec 24 23:34:58 <jf-worker> how can I add this .ko file into target binary image?
Dec 24 23:36:45 <sgw1> sounds like a kernel issue, not too conversant with module building
Dec 24 23:36:55 <jf-worker> ok, thanks
Dec 24 23:37:43 <jf-worker> do you know how to add "sshd" feature?
Dec 24 23:38:15 <sgw1> jf-worker: yes, you can either use dropbear or opensshd
Dec 24 23:38:16 <jf-worker> or how to add feature to transfer files into the target
Dec 24 23:38:27 <jf-worker> how can I add opensshd feature?
Dec 24 23:38:47 <jf-worker> in the local.conf ?
Dec 24 23:39:21 <sgw1> yes: IMAGE_FEATURES += "ssh-server-openssh"
Dec 24 23:39:27 <jf-worker> thanks
Dec 24 23:39:38 <sgw1> biab
Dec 24 23:39:54 <jf-worker> after this added, I can transfer files to the target system, right?
Dec 24 23:40:02 <jf-worker> IMAGE_FEATURES += "ssh-server-openssh"
Dec 24 23:41:08 <jf-worker> or what's the preferred one? to transfer files into target system thru network?
Dec 24 23:41:28 <jf-worker> sshd or smbd or nfs?
Dec 24 23:43:18 <jf-worker> sgwl, are you still working today?
Dec 24 23:43:31 <jf-worker> not in a xmas holiday?
Dec 24 23:46:14 <Crofton> sgw1, :)
Dec 25 00:52:27 <sgw1> jf-worker: It's officially xmas holiday for my employer, we just don't celebrate so I have available time! I will be in and out over this week.
Dec 25 01:15:14 <jf-worker> hi
Dec 25 01:16:05 <sgw1> jf-worker: back to your earlier question, you should be able to transfer with scp
Dec 25 01:16:06 <jf-worker> what package can I use to transfer files to yocto target system?
Dec 25 01:16:16 <sgw1> timing :-)
Dec 25 01:16:21 <jf-worker> scp? how?
Dec 25 01:17:10 <sgw1> jf-worker: have you not used scp before?  scp <file> <user@hostmachine>:<path>
Dec 25 01:17:29 <jf-worker> OK, I'll try
Dec 25 01:17:48 <jf-worker> cause I still can't have the ethernet driver working on the target
Dec 25 01:18:22 <jf-worker> so, can't transer .ko into target system with scp, I think
Dec 25 01:19:39 <jf-worker> I did configure the "igb" ethernet driver to be added, and the build did generate igb.ko in /tmp/work/xxx working folder
Dec 25 01:20:09 <jf-worker> just the igb.ko not "compress-into" the /tmp/deply/images file
Dec 25 01:22:44 <sgw1> Ok, so I am not sure about what you are doing, best suggestion I have would be to somehow copy it into the rootfs before creating the image.  What target?
Dec 25 01:23:05 <sgw1> It's dinner time here, so I need to leave now, not sure how much help you might get this evening.
Dec 25 01:28:55 <jf-worker> jasperforest
Dec 25 01:29:02 <jf-worker> x86_64
**** ENDING LOGGING AT Tue Dec 25 02:59:58 2012

**** BEGIN LOGGING AT Tue Dec 25 02:59:59 2012
Dec 25 05:36:13 <mranostay> whoa
Dec 25 05:36:20 <mranostay> thaytan: fix your connection :)
Dec 25 05:56:04 <jf-worker> hi
Dec 25 05:56:43 <jf-worker> hello
Dec 25 05:56:44 <jf-worker> hola
Dec 25 05:56:59 <jf-worker> kon.ni.gi.wa
Dec 25 10:11:07 <jf-worker> hi
Dec 25 10:11:25 <jf-worker> sleep time?
Dec 25 15:46:58 <eren> will there be YPTM?
Dec 25 15:47:06 <eren> ops, it's christmas
Dec 25 15:47:25 <eren> :\
Dec 25 19:19:35 <otavio> where should I send a poky distro patch?
Dec 25 19:31:09 <wmat> otavio: to the Poky mailing list
Dec 25 19:32:02 <wmat> otavio: see http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#how-to-submit-a-change
Dec 25 19:37:31 <Daemon404> depending on the patch, oe-core may be more relevant
Dec 25 19:57:10 <otavio> Daemon404: no, it is poky.conf distro
Dec 25 19:58:18 <Daemon404> ah ok.
Dec 25 20:03:20 <otavio> wmat: sent; thx
Dec 25 20:03:55 <otavio> sgw1: sent the poky.conf change to add new Debian to the known distros
Dec 25 20:45:33 <bluelightning> merry christmas all :)
Dec 25 22:44:25 <jf-workder> hi
Dec 25 22:50:48 <jf-workder> hello
Dec 26 00:12:23 <jf-workder> merry xmas
Dec 26 00:12:26 <jf-workder> everybody
Dec 26 01:07:25 <jf-workder> hi
Dec 26 01:25:32 <EddyLai> hi
Dec 26 01:46:05 <EddyLai> hi
Dec 26 02:53:41 <Crofton> jf-workder, merry Christmas to you to
**** ENDING LOGGING AT Wed Dec 26 02:59:59 2012

**** BEGIN LOGGING AT Wed Dec 26 02:59:59 2012
Dec 26 07:40:33 <EddyLaiTW> hi thaytan....\\
Dec 26 09:13:13 <jf-workder> hi
Dec 26 09:13:37 <EddyLaiTW> hello jf-worker
Dec 26 22:32:18 <EddyLaiTW> hi
Dec 26 22:44:43 <EddyLaiTW> hello
Dec 26 22:46:06 <EddyLaiTW> I have a kernel module driver that have done testing on desktop PC and Ubuntu.11 & FC.16,
Dec 26 22:46:21 <EddyLaiTW> how can I add that driver package into yocto?
Dec 26 22:47:11 <EddyLaiTW> should I add my own my_Driver.bbxxx or just modify some kernel config file?
Dec 26 22:48:14 <EddyLaiTW> so that I can use 'bitbake core-image-basic' to build the target image including my own driver
Dec 26 22:57:48 <EddyLaiTW> I have read the developer manual, reference manual, and  BSP manual, not round how I can I this yet
**** ENDING LOGGING AT Thu Dec 27 02:59:58 2012

**** BEGIN LOGGING AT Thu Dec 27 02:59:59 2012
Dec 27 04:20:42 <EddyLaiTW> hi
Dec 27 05:49:41 <EddyLaiTW> ..
Dec 27 16:17:49 <sgw1> JaMa: thanks for the holiday gift, I was just about to start work on that back port!
Dec 27 16:18:22 <JaMa> webkit-gtk?
Dec 27 16:18:29 <sgw1> JaMa: yes
Dec 27 16:18:53 <JaMa> ah I've fixed it day before for webkit-efl so it was easy to use in webkit-gtk too :)
Dec 27 16:19:07 <JaMa> can you check remaining 3 pending patches (in contrib/jansa/pull)?
Dec 27 16:19:47 <sgw1> looking
Dec 27 16:20:09 <JaMa> now there are 5, but 3 are old
Dec 27 16:20:37 <sgw1> I count 4, guess you have not pushed the webkit-gtk one yet.
Dec 27 16:21:15 <JaMa> I did few minutes ago
Dec 27 16:21:51 <sgw1> JaMa: The 2 scripts are pending on RP, I think he had some concern with them, I thought the PE one had some comments on the list, did it get acked by zedd?
Dec 27 16:22:19 <sgw1> JaMa: the omap one is pending in my queue, I am working to get a green AB before sending the next request to RP
Dec 27 16:22:40 <sgw1> JaMa: just got up here, need to review the build
Dec 27 16:23:15 <JaMa> scripts had some comments from iirc eric and that was resolved already in some previous version
Dec 27 16:23:48 <JaMa> and PE was refused before branching 1.3 but only concern was that some tools can reference old name (and no -latest link)
Dec 27 16:24:52 <JaMa> and PE in modules.tgz file name was already merged
Dec 27 16:25:16 <sgw1> JaMa: so that's been resolved, I will include it in my next go around, not today's
Dec 27 16:25:34 <JaMa> thanks
Dec 27 16:35:19 <kergoth> ugh, wtf, i just got version GLIBC_2.4 not defined in file libc.so.6 with link time reference in a freshly built qemu image
Dec 27 16:35:22 * kergoth mutters
Dec 27 16:35:56 <sgw1> kergoth: host contamination?
Dec 27 16:36:21 <kergoth> i'd guess so, though i have no idea how.. very strange
Dec 27 16:36:23 * kergoth investigates
Dec 27 18:40:26 * mranostay waves
Dec 27 18:56:57 * sgw1 waves back!
Dec 27 18:58:34 <JaMa> waves with empty beer bottle
Dec 27 18:59:04 <sgw1> JaMa: that's not good, you need a refill then, I just shipped some "yeast samples" to a friend of mine
Dec 27 18:59:59 <JaMa> :)
Dec 27 19:01:08 <JaMa> hmm something is installing libxvmc to sysroot and bypassing sstate, but it's not libxvmc recipe
Dec 27 19:02:15 <JaMa> and only for qemux86-64
Dec 27 19:12:59 <mranostay> sgw1: why the quotes? should i be scared? :)
Dec 27 19:13:34 <sgw1> mranostay: I can't ship beer to some states, but I can ship "yeast samples"
Dec 27 19:13:51 <mranostay> which buzzkill states?
Dec 27 19:14:11 <mranostay> sgw1: yeast or brewed yeast samples?
Dec 27 19:14:23 <sgw1> Minnesota is where a friend lives, but there are others, strong industry lobbies
Dec 27 19:15:26 <sgw1> mranostay: I guess you would call it fermented yeast samples, suspended in alcohol (beer in particular)
Dec 27 19:15:53 <mranostay> heh how you manage that loophole?
Dec 27 19:16:22 <mranostay> put the beer in lab beakers :)
Dec 27 19:16:45 <sgw1> mranostay: just tell the shipper it's yeast samples they don't open the box.
Dec 27 19:17:11 <mranostay> nice ORM-D sticker needed?
Dec 27 19:17:22 <sgw1> ORM-D?
Dec 27 19:17:38 <sgw1> I guess not!
Dec 27 19:17:49 <mranostay> http://en.wikipedia.org/wiki/ORM-D
Dec 27 19:18:27 <mranostay> i think i've had 3 of those items ship to me with that label... guess  which ones :P
Dec 27 19:18:33 <sgw1> It's not hazardous, if the box get's soggy it's just a mess to clean up!
Dec 27 19:18:57 <mranostay> hmm i thought alcohol was on that
Dec 27 19:20:34 <sgw1> Does not look like it also not flammable
Dec 27 20:50:16 <mtimc> can anyone point me at how the link.txt files get generated by cmake- I've got some bugs and fixes to link.txt for llvm when building meta-java for ARM on Fedora17, but I cannot work out where the sources for the link.txt are, so I cannot create meaningful patches
Dec 27 21:01:24 <abelloni> anyone with some experience with a FRI2 ?
Dec 27 21:01:33 <abelloni> mine is not boting anymore
Dec 27 21:01:38 <abelloni> booting
Dec 27 21:22:41 <kergoth> you know what i hate about PRINC? you essentially can never remove a bbappend from any layer, otherwise the package version will go backwards. not an issue when using PR .=
Dec 27 21:27:09 <mranostay> kergoth: ouch
Dec 27 21:29:48 <mranostay> really no easy way to work around that
Dec 27 21:32:42 <bluelightning> surely PRINC will go away with the introduction of the PR server?
Dec 27 21:35:24 <kergoth> true
Dec 27 21:35:38 <eren> off topic: when does christmas holiday end?
Dec 27 21:35:53 <eren> I mean, for yocto team, of course :)
Dec 27 21:46:10 <mranostay> xmas never ends it just dies down
Dec 27 22:04:13 <zenlinux> Hi eren, most of the team will be back the first week in January
Dec 27 22:05:05 <eren> zenlinux: thanks
Dec 27 22:06:04 <eren> zenlinux: speaking of freetype update, should I add relavent patches for danny branch?
Dec 27 22:06:33 <zenlinux> eren, funny you should ask, I'm literally right in the middle of testing a recipe upgrade for freetype for denzil
Dec 27 22:06:54 <eren> or update the version? It's usually better to stick with the same version in stable branches and add relavent patches.
Dec 27 22:06:56 <zenlinux> yes, I'm thinking a version bump would be worthwhile for danny as well
Dec 27 22:06:59 <eren> oh, what a coincidence :)
Dec 27 22:07:37 <zenlinux> eren, unless you have backported patches
Dec 27 22:08:01 <eren> well, they are mentioned in the commit log
Dec 27 22:08:15 <zenlinux> yeah, they look pretty minimal
Dec 27 22:08:25 <eren> they should cleanly apply to 2.4.10
Dec 27 22:09:01 <zenlinux> hmmm
Dec 27 22:09:10 <eren> however, after I sent the patch, 23e6431 has been committed which adds CC_BUILD var in EXTRA_OECONF
Dec 27 22:09:19 <zenlinux> I should really do the right thing and try to get them working for denzil's 2.4.9
Dec 27 22:09:40 <eren> I'm not sure if I should send a new patch based on the latest commit
Dec 27 22:09:56 <eren> http://cgit.openembedded.org/openembedded-core/commit/?id=23e6431687a5602a7e579c546a69008954f64620
Dec 27 22:10:34 <zenlinux> eren, yes, you'll be asked to rebase the commit
Dec 27 22:10:57 <zenlinux> annoying, but collisions like this are fairly rare to deal with
Dec 27 22:11:50 <eren> oh, okkie
Dec 27 22:15:33 <eren> zenlinux: patches clenaly apply for 2.4.9
Dec 27 22:15:47 <eren> zenlinux: I've stripped ChangeLog from the diff file
Dec 27 22:16:13 <eren> I can send you the patches. Don't bother with opening freetype cgit page to grab the patches :)
Dec 27 22:19:25 <eren> zenlinux: check your inbox please
Dec 27 22:21:45 <zenlinux> eren, sweet - thanks so much!
Dec 27 22:22:33 <eren> my pleasure
Dec 27 22:26:48 <eren> I'm rebasing my change to new maser
Dec 27 22:26:51 <eren> s/maser/master
Dec 27 22:59:15 <zenlinux> eren, I'm adding Upstream-Status and SOB lines to those patches you sent me. You okay with me adding your SOB line with your hambedded.org email address?
Dec 27 23:00:43 <eren> zenlinux: yeah sure
Dec 27 23:00:53 <zenlinux> k
Dec 27 23:04:34 <eren> zenlinux: I guess it's not a problem to write SOB line for patches grabbed from git?
Dec 27 23:05:03 <eren> the original author is mentioned in the patch, and I acknowledge that I grabbed them from git and stripped ChangeLog parts
Dec 27 23:06:02 <zenlinux> eren, while I suppose you can infer the source correctly from the mail headers you included, I know our yocto policy is to include SOB lines, so we can trace how they got into yocto
Dec 27 23:06:25 <eren> oh okkie, no problem
Dec 27 23:06:26 <zenlinux> in any case, sgw will ask for it, so I'm covering my bases. :)
Dec 27 23:06:53 <eren> I will just say "I grabbed them from mailing list and git" and they will continue tracking the chain :)
Dec 27 23:10:25 <eren> I'm wondering why git-send-email did not append [0/1], [1/1] in mail subject
Dec 27 23:12:20 <eren> zenlinux: how do you send patches to ML?
Dec 27 23:12:57 <zenlinux> eren, I always use the create-pull-request and send-pull-request scripts from the oe-core scripts/ subdir
Dec 27 23:13:38 <zenlinux> As for patches to our upstream sources, I'll literally create two project dirs and run diff -urN against them once I've made my changes
Dec 27 23:14:37 <eren> the latter is same for me. For Oe, I create a branch, make changes, commit and run "git send-email"
Dec 27 23:15:22 <eren> as written in wiki. It does not include the number of patches, and the order in subject though. I should look at create-pull-request script
Dec 27 23:30:47 <eren> good night all!
Dec 27 23:30:53 <eren> zenlinux: have a good day :)
Dec 27 23:31:14 <EddyLaiTW> goo nite
Dec 28 01:33:38 <kergoth> there we go. did a quick patch to the chkconfig update-alternatives to have sysroot support, got recipes, and verified that an image that uses it instead of update-alternatives-cworth (and instead of opkg-native) works
**** ENDING LOGGING AT Fri Dec 28 02:59:58 2012

**** BEGIN LOGGING AT Fri Dec 28 02:59:59 2012
Dec 28 04:50:28 <EddyLaiTW> hi
Dec 28 15:15:26 <kergoth> morning
Dec 28 15:15:36 <yzhao2> morning
Dec 28 15:15:51 * kergoth yawns
Dec 28 15:43:32 <Jin^eLD> btw in relation to poky and yocto - in which channel should one ask quetions? :>
Dec 28 15:43:46 <Jin^eLD> rather in #poky or in #yocto?
Dec 28 15:44:36 <kergoth> technically probably depedns on the questions :)
Dec 28 15:45:23 <Jin^eLD> I am not sure how to differentiate, tried in #poky but seems quite silent there
Dec 28 15:45:42 <Jin^eLD> I was asking about SDKIMAGE_FEATURES += "staticdev-pkgs", I would expect to see libc.a in the resulting meta-toolchain build
Dec 28 16:03:16 <yzhao2> question: if a package can not be built for a specific arch, what I should use?
Dec 28 16:25:56 <kergoth> yzhao2: can you elaborate?
Dec 28 16:32:11 <Jin^eLD> kergoth: any idea regarding the staticdev thing, or is it a misconfiguration on my part?
Dec 28 16:32:18 <yzhao2> kergoth: I have a package which needs kernel supports a syscall to build, but this syscall is not supported by like arm
Dec 28 16:38:16 <yzhao2> so I should avoid these unsupported arch for this package in the recipe
Dec 28 16:42:28 <kergoth> yzhao2: it's just one package, or the whole recipe? if the latter, use COMPATIBLE_HOST to indicate what you're compatible with. If the former, you could use an arch specific override to adjust PACKAGES
Dec 28 16:42:42 <kergoth> Jin^eLD: don't know, unfortunately I don't have much experience with the meta-toolchain stuff, sorry :\
Dec 28 16:43:11 <Jin^eLD> :( if I understand the poky docs correctly SDKIMAGE_FEATURES should do it
Dec 28 16:43:17 <Jin^eLD> I'll poke around a bit more
Dec 28 16:43:23 <kergoth> does sound like it should
Dec 28 16:45:08 <kergoth> hmm, i wonder if we ever run out update-alternatives in the sysroot to generate symlinks in the sysroot itself rather than on the target.. hopefully not
Dec 28 16:45:57 <kergoth> arguably all our update-alternatives which are native should perhaps be cross, as the paths relative to the sysroot should be of the target, not the sysroot
Dec 28 16:48:09 <yzhao2> kergoth: the whole recipe, I will try COMPATIBLE_HOST. Thanks kergoth
Dec 28 16:48:47 <kergoth> np
Dec 28 16:49:13 <kergoth> you should be able to grep around for examples, there are a lot of recipes which use such things, e.g. bootloaders, or things like valgrind w hich need specific host support
Dec 28 17:23:41 <kergoth> https://github.com/kergoth/oe-core/compare/chkconfig-alternatives seem reasonably sane?
Dec 28 17:46:28 <Jin^eLD> hmm, if I have a poky.conf in my own layer in order to override some defaults, why isn't it being picked up, layer has a higher prio and is included in my bblayers.conf; this works with stock OE, what am I missing?
Dec 28 17:47:19 <kergoth> config files and classes are found in BBPATH order, which reflects BBLAYERS order, not the order defined by BBFILE_PRIORITY
Dec 28 17:47:23 <kergoth> unfortunately
Dec 28 17:47:28 <kergoth> change the layer order in BBLAYERS
Dec 28 17:48:21 <kergoth> in mentor's setup-environment script, we actually reorder BBLAYERS based on defined layer priority, to ensure it matches up.. but of course that doesn't affect layers the user adds after the fact..
Dec 28 17:48:25 <kergoth> heh
Dec 28 17:49:09 <Jin^eLD> hmm, that did not help
Dec 28 17:49:33 <Jin^eLD> I must be missing something else then
Dec 28 17:50:02 <Jin^eLD> "else" as in addition to reordering, because I did have the order wrong
Dec 28 17:50:40 <Jin^eLD> BBLAYERS is not printed with bitbake -e ?
Dec 28 17:51:15 <kergoth> BBPATH is searched beginning to end, and the first found is used
Dec 28 17:51:22 <kergoth> this means BBLAYERS needs to be highest priority to lowest priority
Dec 28 17:51:24 <kergoth> not the other way around
Dec 28 17:51:31 <kergoth> bitbake-layers may be informative, also
Dec 28 17:51:35 <kergoth> (possibly)
Dec 28 17:53:20 <Jin^eLD> ok, it's my BBPATH then, thanks
Dec 28 17:53:58 <Jin^eLD> although I am not sure who resets it
Dec 28 17:54:11 <kergoth> again, its the BBLAYERS order
Dec 28 17:54:16 <Jin^eLD> I do not use the environmnt script, have something simplier for my needs, but still something or someone puts meta-yocto in the first place
Dec 28 17:54:18 <kergoth> bblayers controls the parse order of the layer.conf files
Dec 28 17:54:23 <kergoth> and the layer.conf files are what add to BBPATH
Dec 28 17:54:29 <kergoth> so BBLAYERS controls the BBPATH order
Dec 28 17:54:31 <Jin^eLD> my layer is on top of BBLAYERS
Dec 28 17:54:37 <Jin^eLD> so that should have worked?
Dec 28 17:54:40 <kergoth> then verify its also first in BBPATH
Dec 28 17:54:54 <kergoth> could also be that you have a layer that's prepending to bbpath instead of appending
Dec 28 17:54:57 <kergoth> (not nice)
Dec 28 17:55:29 <Jin^eLD> like that? BBPATH := "${LAYERDIR}:${BBPATH}"
Dec 28 17:55:38 <Jin^eLD> that'd be meta-yocto then ;)
Dec 28 17:55:54 <kergoth> right, so its injecting itself ahead of everyone else, forcing the matter
Dec 28 17:56:10 <Jin^eLD> is that desired or shall I submit a bug or something?
Dec 28 17:56:13 <kergoth> you could do the equivalent in your layer as well, though thats spreading the badness, it would at least work around your issue
Dec 28 17:56:16 <Jin^eLD> ..since you said "its not nice"
Dec 28 17:56:24 * kergoth shrugs, he isn't a yocto/poky maintainer, just contributer
Dec 28 17:56:33 <kergoth> it's probably worth sending an email to at least inquire about it
Dec 28 17:56:42 <kergoth> and explain that it's cuasing you issues overriding its files
Dec 28 17:57:20 <Jin^eLD> will do
Dec 28 17:57:26 <Jin^eLD> thanks for the pointers, at least now I know what's going on
Dec 28 17:57:56 <kergoth> no problem, happy to help
Dec 28 17:58:15 * kergoth isn't particularly happy about this disconnect in priority responsibility, part in layers, part the user
Dec 28 18:00:14 <Jin^eLD> yeah it's somewhat confusing...
Dec 28 18:00:28 <Jin^eLD> gotta run, l8r
Dec 28 18:20:28 <kergoth> erm, buildhistory-diff appears to be broken
Dec 28 18:22:37 * kergoth scratches head
Dec 28 18:27:48 <kergoth> found it, it breaks if you have multiple bitbakes in your path, or a bitbake installed on the host, because it appends to sys.path rather than prepends
Dec 28 18:50:21 <wmat> kergoth: is the definitive bitbake home at http://www.openembedded.org/wiki/Bitbake or is it still http://developer.berlios.de/projects/bitbake/?
Dec 28 18:52:47 <kergoth> wmat: berlios isn't used for much of anything anymore
Dec 28 18:53:13 <wmat> kergoth: thx
Dec 28 19:02:18 <sgw1> kergoth: every figure out your issue from yesterday?
Dec 28 19:39:54 <kergoth> sgw1: nah, got pushed onto the backburner, haven't had a chance to dig into it. i suspect its an intermittant thing too :
Dec 28 19:39:57 <kergoth> \
Dec 28 19:40:17 <sgw1> Yeah, I know those
Dec 28 19:52:13 <kergoth> IRC sure is dead between christmas and new years, feels like i'm the only one that didn't take the rest of the week off :)
Dec 28 19:57:19 <mranostay> kergoth: HEY THERE!
Dec 28 19:57:30 <mranostay> less quiet now :)
Dec 28 19:59:46 <kergoth> heh :)
Dec 28 19:59:49 <kergoth> mranostay: how's it going?
Dec 28 20:00:31 <mranostay> it's going :)
Dec 28 20:01:32 <kergoth> heheh
Dec 28 20:01:43 <kergoth> I haven't been particularly productive this week..
Dec 28 20:02:39 * sgw1 is sort of around also, equally non-produtive, got some bugs dealt with mostly keeping pull requests moving
Dec 28 20:02:55 * kergoth sanity checks performance of the C chkconfig update-alternatives when building images
Dec 28 20:04:57 <kergoth> sgw1: you happen to know the state of the prserver bits? i'm assuming they're functional, as local testing with the local automatically spawned prserver seems to show good results, but i'm curious about who's started using it so far
Dec 28 20:05:16 * kergoth is thinking about enabling the local one by default for mentor's distros
Dec 28 20:09:05 <Crofton|work> I am sort of trying to work
Dec 28 20:09:12 <Crofton|work> but mostly dealing with oterh stuff
Dec 28 20:10:15 <kergoth> i'm fighting procrastination
Dec 28 20:11:40 <Crofton|work> yeah
Dec 28 20:11:57 <Crofton|work> I am procrastinating dealing with a home heating issue
Dec 28 20:12:06 <Crofton|work> I keep hoping it will just get better
Dec 28 20:21:06 <mranostay> Crofton|work: get a RTG :)
Dec 28 20:21:38 <Crofton|work> heh
Dec 28 20:21:54 <Crofton|work> I need to call the guys that did the original upgrade
Dec 28 20:22:11 <Crofton|work> about replacing the oil part, but I am not so impressed with their work
Dec 28 20:34:31 <kergoth> ah, on average it looks like the C alternatives cuts image creation time by a whopping 7 seconds. hehe. i care more about the loss of the shell dep, and having someone other than us maintaining the thing, more than that, but was worth checking..
Dec 28 20:34:39 * kergoth moves on to the next task
Dec 28 23:01:38 <jimvv> hello world
Dec 28 23:02:04 <jimvv> I'm looking for pointers on adding files to rootfs
Dec 28 23:25:55 <jimvv> like "merge-files"?
**** ENDING LOGGING AT Sat Dec 29 02:59:58 2012

**** BEGIN LOGGING AT Sat Dec 29 02:59:59 2012
Dec 29 21:17:45 <otavio> jimvv: you should include a new recipe which install those
Dec 29 21:17:48 <otavio> jimvv: and add it in the image
Dec 29 21:21:48 <otavio> I am wondering what : "Please verify which package should provide the above files." with a list of files in target sysroot means ... any clue?
Dec 30 00:16:21 <eren> quit
Dec 30 00:16:23 <eren> ops
Dec 30 00:16:34 * eren forgot to add slash :)
**** ENDING LOGGING AT Sun Dec 30 02:59:59 2012

**** BEGIN LOGGING AT Sun Dec 30 02:59:59 2012
**** ENDING LOGGING AT Mon Dec 31 02:59:59 2012

**** BEGIN LOGGING AT Mon Dec 31 02:59:59 2012
**** ENDING LOGGING AT Tue Jan 01 02:59:57 2013

**** BEGIN LOGGING AT Tue Jan 01 02:59:58 2013
Jan 01 05:00:12 <jchonig1> Happy New Year!
**** ENDING LOGGING AT Wed Jan 02 02:59:58 2013

**** BEGIN LOGGING AT Wed Jan 02 02:59:59 2013
Jan 02 05:32:08 <EddyLaiTW> hi
Jan 02 05:32:21 <EddyLaiTW> may I ask what hardware are you using with yocto project?
Jan 02 05:33:29 <EddyLaiTW> anyone use the TI - Beagle bone board?
Jan 02 05:35:04 <EddyLaiTW> I have 3 hardware board now, beagleboard  and gumstick TI h/w, plus one JasperForest SBC with 82580 ethernet
Jan 02 08:49:27 <mckoan> good morning and Happy New Year
Jan 02 09:08:20 <ant_work> hi mckoan
Jan 02 16:23:45 <dvhart> good morning all
Jan 02 16:27:53 <fray> happy new year
Jan 02 16:28:04 <kergoth> morning, happy new year
Jan 02 16:31:10 <fray> ohh new copier/printer for the office just arrived.. late office "present"  ;)
Jan 02 16:31:31 <fray> (considering the old one was almost 10 years old.. and the power supply/board fryed itself a couple months ago)
Jan 02 16:31:48 <fray> scortch marks are on the board were quite obvious.. :P
Jan 02 16:34:32 <kergoth> yikes
Jan 02 16:53:22 <scottrif> halstead: ping - public key issues
Jan 02 17:50:48 <waynr> question about creating BSPs compatible with a yocto release: is it possible to create custom images for a BSP in that BSP layer? also, i am looking at other BSP layers such as meta-intel...can these BSPs be used interchangeably between different distribution layers?
Jan 02 17:55:33 <dvhart> You want to keep hardware support independent from distro policy, but I suspect image definition is reasonable to include in a BSP layer.
Jan 02 17:55:58 <dvhart> waynr, if the BSPs break with other distribution layers, then there is a bug somewhere
Jan 02 17:56:01 <dvhart> so "yes"
Jan 02 18:16:47 * mranostay waves
Jan 02 18:21:42 * sgw1 waves happy new year back! (maybe I need to semaphore that)
Jan 02 18:24:43 <mranostay> another year another dollar?
Jan 02 18:32:25 <scottrif1> halstead: ping
Jan 02 18:43:22 <waynr> thanks dvhart
Jan 02 19:29:13 <waynr> <3 sed
Jan 02 19:29:37 <waynr> whoops wrong window. oh well, i'm not ashamed of my love for sed.
Jan 02 19:47:27 <mranostay> waynr: not sure that is legal in all states
Jan 02 20:06:26 <JaMa> pidge: Hi, any update on that license text in PN we talked about?
Jan 02 20:27:16 <pidge> JaMa: Could you remind me what we were talking about? I have a vague memory of it :)
Jan 02 20:46:35 <JaMa> pidge: http://bpaste.net/show/67782/
Jan 02 20:49:05 * kergoth ponders
Jan 02 20:50:50 <kergoth> JaMa: i'd say just add a new function to PACKAGEFUNCS which checks either license or license flags and adjusts PKG_<pkg> appropriately
Jan 02 20:53:07 <JaMa> kergoth: can you explain a bit more?
Jan 02 20:53:31 <kergoth> packagefuncs is a space separated list of functions that get run during the packaging process, see package.bbclass
Jan 02 20:54:11 <JaMa> kergoth: ah I see
Jan 02 20:54:14 <kergoth> and PKG_<package> is a variable used to alter the name of a package. its what debian.bbclass uses to implement shlib renaming
Jan 02 20:54:23 <JaMa> kergoth: I meant include them in FILES_${PN} not in PN itself
Jan 02 20:54:58 <kergoth> ahh, i see
Jan 02 20:55:02 <kergoth> misread
Jan 02 20:55:28 <JaMa> kergoth: to get something like /usr/share/licenses/${PN}/files in FILES_${PN}
Jan 02 20:55:30 <kergoth> so you want license text included in the package?
Jan 02 20:55:32 * kergoth nods
Jan 02 20:55:44 <JaMa> kergoth: without duplicating license texts if it's common license
Jan 02 20:56:08 <JaMa> license texts + LIC_FILES_CHKSUM parts
Jan 02 20:56:20 <kergoth> interesting idea
Jan 02 20:56:44 <kergoth> guess would need to emit the license package if it doesn't already exist, then rdep on it, or so
Jan 02 20:56:51 <kergoth> rrec, rather
Jan 02 20:57:48 <JaMa> yes that was one way, but for shared licenses it's a bit more complicated
Jan 02 20:58:09 <JaMa> e.g. foo-license would rdep on license-gpl-2.0
Jan 02 20:58:20 <pidge> JaMa: no, I haven't had a chance to look at it yet. Did we ever open a bug on it (it's probably why it got sidelined)
Jan 02 20:59:03 <kergoth> of course, debian just ships the text in docdir and doesn't bother trying to reduce duplication
Jan 02 20:59:07 <JaMa> and foo-license would contain /usr/share/licenses/foo/GPL-2.0 symlink to /usr/share/licenses/common/GPL-2.0 and /usr/share/licenses/foo/bar.c (from LIC_FILES_CHKSUM)
Jan 02 20:59:32 <JaMa> and foo would only rrec foo-license if configured to do so
Jan 02 21:00:10 <JaMa> pidge: no I haven't opened a but about it yet
Jan 02 21:01:16 <JaMa> pidge: I can try to prepere something for you to review, because some other devs are working on something like package manager for extra packages where they need this feature...
Jan 02 21:01:26 <JaMa> soonish
Jan 02 21:02:46 <pidge> JaMa: Yes, please. I'm playing holiday catchup but I'll have time this week/next for review.
Jan 02 21:38:15 <blloyd_> anyone have any suggestions where to look for an example out of tree device driver?
Jan 02 21:39:15 <blloyd_> (or how to search for one)
Jan 02 21:49:36 <kergoth> check for recipes that inherit module
Jan 02 21:56:09 <dvhart> blloyd_, see meta-skeleton/recipes-kernel/hello-mod
Jan 02 21:56:23 <dvhart> blloyd_, that's what it is meant to demonstrate
Jan 02 21:57:25 <blloyd_> thank you dvhart.  I figured there was one.  I missed it.  didn't think to search for mod.   Dumb me.
Jan 02 21:57:48 <dvhart> blloyd_, could be we need a better mechanism - you aren't the first to ask after it
Jan 02 21:58:01 <dvhart> blloyd_, let me know if you have an idea for a better name or README
Jan 02 21:58:52 <dvhart> blloyd_, also, there is new kernel documentation being edited currently which has a section on this. Hopefully that will also help.
Jan 02 21:58:54 <blloyd_> perhaps add to documentation where to find some samples.  There is lots about CUSTOMIZING a kernel.  Not so much about adding custom mods (which I figured was somewhat common in industrial embedded systems)
Jan 02 21:59:06 <dvhart> http://www.yoctoproject.org/docs/hart/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules
Jan 02 21:59:18 <dvhart> ^
Jan 02 21:59:21 <blloyd_> I'll proof read that!
Jan 02 21:59:24 <dvhart> the manual isn't done
Jan 02 21:59:32 <dvhart> it's being edited as we speak
Jan 02 21:59:41 <dvhart> so keep that in mind whilst reviewing
Jan 02 22:00:01 <dvhart> please CC myself and scott rifenbark on any email
Jan 02 22:03:23 <blloyd_> okie.  :)  It's helpful even in this state.  Thatt will be a nice addition.
Jan 02 22:03:39 <dvhart> blloyd_, very glad to hear it
Jan 02 22:03:49 <dvhart> please be free with feedback as that is how we improve docs
Jan 02 22:03:58 <blloyd_> have been in the past.
Jan 02 22:04:04 <dvhart> thx
Jan 02 22:04:40 <blloyd_> I'll happily (well maybe not happily) complain when I can't find what I know should be there or else can't follow it once I find it.  :)
Jan 02 22:04:50 <dvhart> ;-)
Jan 02 22:04:59 <blloyd_> (sorry, not so good at the praising part)
Jan 02 22:06:26 <dvhart> few people are, especially with docs. Not to say we wouldn't appreciate a shout out now and then ;-)
Jan 02 22:07:03 <blloyd_> well, I did say it would be a nice addition.  :)
Jan 02 22:15:55 <blloyd_> question, is the name kernel-module-MYNAME the recommended syntax for modules?
Jan 02 22:16:32 <blloyd_> (part of the documentation seems to indicate that)
Jan 02 22:20:19 <dvhart> yes
Jan 02 22:20:41 <dvhart> well. hrm.
Jan 02 22:20:44 <dvhart> that is for the built-ins
Jan 02 22:21:02 <dvhart> I don't know that there is a recommended naming scheme for the external modules
Jan 02 22:21:09 <dvhart> that one would be as good as any
Jan 02 22:24:14 <blloyd_> it follows well for non-built-ins too.
Jan 02 22:24:33 <blloyd_> the doc line MACHINE_EXTRA_RRECOMMENDS += "kernel-module-mymodule"  seems to suggest it.
Jan 02 22:24:50 <blloyd_> But then the sample hello-mod doesn't follow it.  (consistency?)
Jan 02 22:26:33 <blloyd_> another dumb question: hello-mod itself requires manual loading at start to do anything.  But it doesn't show the recommended way in yocto to do that.  Am I missing something (non-pnp device here.  :( )
Jan 02 22:28:34 <blloyd_> trying to decide between a sed edit of modprobe's configuration or else a init.d startup file.
**** ENDING LOGGING AT Thu Jan 03 02:59:59 2013

**** BEGIN LOGGING AT Thu Jan 03 02:59:59 2013
Jan 03 05:11:28 <waynr> dang, "minimal" image ends up being 110 MB
Jan 03 05:14:06 <khem> waynr: what do you mean
Jan 03 05:16:31 <waynr> well the stable-2009 images i usually work with are around 31 MB
Jan 03 05:16:51 <waynr> the core-image-minimal image i just built is 110MB
Jan 03 05:26:13 <khem> waynr: ok, did you add any extra image features
Jan 03 05:30:32 <waynr> khem: i may have uncommented something in layer.conf
Jan 03 05:38:09 <waynr> sorry, i mean local.conf
Jan 03 08:31:33 <erbo> I'm suspecting a recipe might use the wrong pkg-config-native binary, but I can't really find where the path to pkg-config is set up. Any hints?
Jan 03 09:45:10 <Corneliu> happy new year everybody!
Jan 03 09:45:54 <Corneliu> tarting today we at Yocto QA are going to use Testopia for master branch testing of the Yocto Project
Jan 03 09:46:04 <Corneliu> starting today we at Yocto QA are going to use Testopia for master branch testing of the Yocto Project
Jan 03 09:46:23 <Corneliu> you can find more info on this in the wiki I created hee: https://wiki.yoctoproject.org/wiki/Testopia
Jan 03 09:47:58 <Corneliu> we look forward for your involvment and support, as this new tool is aimed at the community of the Yocto Project
Jan 03 09:49:35 <Corneliu> please note that new branches will be added over time and anyone can also add their own branch provided they commit at using it
Jan 03 14:19:33 <subodh> my recipe (which is similar to meta-browser)  depends on nspr and nss. It fails to install nss properly i.e. nss.pc is not staged under sysroot/nitrogen6x/usr/lib. Any one here who can tell me why nspr installs correctly but nss doesn't? Thanks and a happy new year to all :-)
Jan 03 15:41:47 <blloyd_> subodh: you mean in the pre-build sysroot or final sysroot?
Jan 03 15:42:04 <blloyd_> and that path doesn't look right for either.
Jan 03 15:43:14 <blloyd_> back in about 30 mins
Jan 03 15:59:41 <kergoth> https://github.com/kergoth/bb#readme - work in progress, comments welcome
Jan 03 16:00:38 <rburton> kergoth: oo
Jan 03 16:01:03 <kergoth> up next is fleshing it out so it really shows all the different types of dependency
Jan 03 16:01:13 <rburton> kergoth: any plans for an "interactive" mode where the parsing is done once
Jan 03 16:01:30 <kergoth> that'd be trivial to add, i'll put it on the todo
Jan 03 16:04:08 <kergoth> added, https://github.com/kergoth/bb/blob/master/TODO.md
Jan 03 16:04:12 <kergoth> thanks for the suggestion
Jan 03 16:05:03 <rburton> i always means to make depexp more useful like that
Jan 03 16:06:22 <kergoth> pretty much only 'show' is very useful right now (it's bitbake-env), but it's a step in the right direction
Jan 03 16:06:36 * kergoth goes to get breakfast
Jan 03 16:18:07 <zenlinux> *sigh*. apparently it won't be the year I have a reliable network connection in the office :-
Jan 03 16:23:07 <subodh> blloyd pls ping when you comeback here
Jan 03 16:36:05 <kergoth> hmm, maybe i should either change behavior or add an argument to interpret the specified value as a pn rather than just a provider, so e.g. bb show -r eglibc -n would actually show the metadata from the 'eglibc' recipe rather than whatever provider of eglibc is currently selected (my external toolchain)
Jan 03 18:20:59 <mranostay> zenlinux: year of the linux desktop at leat
Jan 03 18:21:01 <mranostay> *least
Jan 03 22:40:43 <otavio> sgw1: did you see the patch for Debian 7.0 addition in poky.conf?
Jan 03 22:44:02 <sgw1> otavio: yes, it's pending RP returning from break, I sent it in a C-PULL for Poky, but he has not merged everything yet.
Jan 03 22:46:02 <otavio> sgw1: good; thx! just ensuring it has not been missed! :)
Jan 03 22:46:08 <otavio> bbl! :)
Jan 03 22:46:13 <otavio> (dinner)
Jan 03 22:47:49 <sgw1> otavio: not missed
**** ENDING LOGGING AT Fri Jan 04 02:59:58 2013

**** BEGIN LOGGING AT Fri Jan 04 02:59:58 2013
Jan 04 03:24:00 <EddyLaiTW> hi
Jan 04 03:25:10 <EddyLaiTW> how can I add a new kernel module driver into my currently successfully build yocto project on my own PC?
Jan 04 03:25:40 <EddyLaiTW> add the driver source code/folder into the "tmp/work" forder?
Jan 04 03:35:46 <khem> EddyLaiTW: u have two options
Jan 04 03:36:08 <khem> EddyLaiTW: you could add it as external module
Jan 04 03:36:23 <khem> for  that you would write a separate recipe for your module
Jan 04 03:36:47 <khem> and then include this new package via EXTRA_IMAGE_INSTALL
Jan 04 03:36:53 <khem> into your final image
Jan 04 03:37:17 <EddyLaiTW> a .bb or a .bbappend?
Jan 04 03:37:29 <khem> see meta/recipes-kernel/lttng-2.0/lttng-modules_2.0.5.bb
Jan 04 03:37:41 <khem> you can model your module recipe like that
Jan 04 03:37:52 <EddyLaiTW> ok, thanks khem!
Jan 04 03:38:19 <khem> other option is to create a patch for kernel
Jan 04 03:38:27 <khem> and add it as in kernel module
Jan 04 03:39:18 <EddyLaiTW> this option is easy and fast  , but seems will have problem if I want this config/recipe share with my dev-team
Jan 04 03:39:26 <khem> yes
Jan 04 03:39:43 <khem> its your module so however you want its upto you
Jan 04 03:39:52 <khem> do you use linux-yocto for kernel ?
Jan 04 03:39:54 <EddyLaiTW> thank you very much, khem
Jan 04 03:39:59 <khem> np
Jan 04 03:40:28 <EddyLaiTW> yes, I am new to yocto, but have build my first USB boot image running on my target in 7days
Jan 04 03:40:36 <EddyLaiTW> it's really nice
Jan 04 03:50:03 <EddyLaiTW> after I have the kernel module driver build done, how can I make the myDriver.ko put into the target binary image?
Jan 04 03:50:16 <EddyLaiTW> so that I can use "insmod myDriver.ko" to load it
Jan 04 03:56:19 <EddyLaiTW> not sure "do you use linux-yocto for kernel ?" now... I use "bitbake core-image-basic",
Jan 04 03:56:28 <EddyLaiTW> will this use "linux-yocto"?
Jan 04 04:02:49 <kergoth> depends on what machine you're building for
Jan 04 04:03:00 <kergoth> bitbake -e virtual/kernel | grep '^FILE='
Jan 04 04:04:37 <EddyLaiTW> fce84x0dev@ub1204-UX31E:~/poky-danny-8.0/build$ bitbake -e virtual/kernel | grep '^FILE='
Jan 04 04:04:38 <EddyLaiTW> FILE="/home/fce84x0dev/poky-danny-8.0/meta/recipes-kernel/linux/linux-yocto_3.4.bb"
Jan 04 04:05:32 <EddyLaiTW> so this mean I'm using linux-yocto kernel 3.4 right?
Jan 04 04:07:02 <EddyLaiTW> thanks kergoth
Jan 04 04:30:09 <EddyLaiTW> how can I add "lttng-2.0" into my target binary? add in the conf/local.conf?
Jan 04 11:33:54 <schramae> happy new year everyone
Jan 04 11:35:20 <schramae> rburton: i'm currently working with the danny stable branch. what do i need to do to get the fix for bug #3634 and/or where do i find danny-next?
Jan 04 11:35:20 <yocti> Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=3634 critical, Medium+, 1.3.1, ross.burton, IN PROGRESS IMPLEMENTATION , Udev broken in Danny branch (0140519ba15bfb27ccbfb3d41c7e678a1118fc5c)
Jan 04 11:36:15 <rburton> schramae: danny-next is in openembeded-core-contrib
Jan 04 11:36:58 <rburton> schramae: http://cgit.openembedded.org/openembedded-core-contrib/log/?h=ross/danny-next
Jan 04 11:38:01 <schramae> thanks
Jan 04 11:39:54 <rburton> i verified that danny-next boots from hddimg too
Jan 04 11:40:10 <rburton> *really* need to merge the initramfs logic, duplicated is bad
Jan 04 12:29:37 <eFfeM_work> hi, gm all
Jan 04 12:29:54 <eFfeM_work> what is the simplest way to find out which layer (if any) provides inotify-tools ?
Jan 04 13:01:02 <schramae> eFfeM_work: $ bitbake-layers show-recipes | grep -A1 inotify-tools
Jan 04 13:01:44 <eFfeM_work> schramae: hm: bitbake-layers: command not found
Jan 04 13:02:24 <eFfeM_work> and is this only for installed layers? actually I want to find out which layer to download to get this recipe (it used to be in oe classic, it is not in danny nor in meta-oe)
Jan 04 13:03:13 <schramae> you need to source oe-init-build-env before. and yes, this only for installed layers AFAIK
Jan 04 13:05:19 <eFfeM_work> schramae: ah ok, indeed did this in a window where I did not source
Jan 04 13:05:36 <eFfeM_work> and indeed it only seems for installed layers,
Jan 04 13:05:47 <eFfeM_work> ported the recipe I had from classic and ge the layer that one is in
Jan 04 13:06:25 <schramae> http://packages.yoctoproject.org/ provides a web search, but there is no inotify-tools either
Jan 04 13:07:16 <JaMa> eFfeM_work: http://lists.linuxtogo.org/pipermail/openembedded-core/2012-November/031593.html
Jan 04 13:08:40 <eFfeM_work> schramae: i don't think they have all layers
Jan 04 13:08:50 <eFfeM_work> JaMa: hi!
Jan 04 13:09:03 <eFfeM_work> JaMa: thanks for the link, saw that mail but forgot about it
Jan 04 13:09:32 <schramae> nice, didn't know that either
Jan 04 13:14:10 <eFfeM_work> JaMa: I can probably port/update the recipe (it is pretty straightforward) but no idea on which recipes_* dir it should go, also not too sure on the procedure to submit recipes for oe-core (i prefer mail)
Jan 04 13:21:30 <eFfeM_work> ls
Jan 04 13:22:52 <eFfeM_work> hm, tried to port the recipe, but not sure how to get rid of the patch that htere is to check for headers and if they really work
Jan 04 13:26:18 <eFfeM_work> should I be able to get rid of this: http://pastebin.com/mbkRCE3X
Jan 04 13:38:56 <ant_work> JaMa: hello. Do you think there are still tolchain issues for armv4? I can compile the kernel but the initramfs seems not found or maybe the init binary is miscompiled :/
Jan 04 13:43:19 <JaMa> ant_work: I don't have any armv4 device and I had issues only with armv4t after --fix-v4bx was added for armv4
Jan 04 13:43:50 <JaMa> and that is now fixed in master and patch pending for danny
Jan 04 13:45:07 <ant_work> about that, I imported khem's patch to use the same CC for kernel
Jan 04 14:09:23 <schramae> rburton: ok, i reverted my working copy, added danny-next as remote, cherry-picked 002ef4aaa5fc207a0b8541f4cd468a2ac410f433, rebuilt and it works/boots again. :) was this correct git workflow? haven't done this before...
Jan 04 14:36:16 <Crofton|work> I'm trying to update the fftw recipe and can't get the checksum test to fail
Jan 04 14:38:28 <rburton> schramae: that's an acceptable workflow.
Jan 04 14:39:35 <schramae> rburton: "acceptable" as in "there are better ways"?
Jan 04 14:40:10 <rburton> schramae: an alternative would be to merge danny-next into your danny branch, but that's more intrusive
Jan 04 14:41:28 <schramae> rburton: yes, i wanted to keep it stable / only do minimal changes. gonna update the bugzilla entry - thanks again
Jan 04 17:37:01 <peterdev> hello all
Jan 04 17:37:29 <waynr> howdy
Jan 04 17:38:08 <peterdev> I would like to have a question about yocto + pandaboard deployment. Is this the right place ?
Jan 04 17:41:05 <schramae> basically yes. just ask, maybe sb. is awake who's got an answer... ;)
Jan 04 17:42:53 <peterdev> I've got my pandaboard. Managed to follow some wiki and successfully deployed linaro android on it.  Next step I try is to deploy minimal yocto image on it. I've hooked in the meta-ti layer and built my custom image but I'm stucked at this point. Since I did not find valuable infos about how to populate SD card properly with the given yocto image.  Does anybody knows something in this regard ? Any piece of information would be handy
Jan 04 17:47:30 <schramae> what kind of image format do you have? a hddimg?
Jan 04 17:48:30 <peterdev> I did compile to tar.bz2
Jan 04 17:48:33 <kergoth> i'd just copy the kernel/u-boot to the sd card with the appropriate names, like any other image
Jan 04 17:48:49 <kergoth> same for the filesystem piece (dd, whatever)
Jan 04 17:50:48 <schramae> yes, manual copying + GRUB install should work for all kinds of media (USB, SD, ...). see https://wiki.yoctoproject.org/wiki/How_do_I#Q:_How_do_I_put_Yocto_on_a_hard_drive.3F
Jan 04 17:51:42 <schramae> if you got a .hddimg file ("inherit image-live"), you could simply deploy it via dd
Jan 04 17:51:58 <kergoth> no, panda is arm, grub is out of th equestion. panda has its own sd card format, and its bootloader will look there for files if the card is partitioned correctly
Jan 04 17:52:03 <kergoth> hddimg won't be of any use
Jan 04 17:52:34 <schramae> i see, i just used x86 so far
Jan 04 17:53:43 <peterdev> I suspected to simply copy it over despite I did read not to do it many times. I had a successfull linaro android installation which is running perfectly on the board. populated the SD card from 3 tarballs (boot.tar.bz2, rootfs... , userdata..) ---- with an automated script. It was working like a charm.
Jan 04 17:54:23 <peterdev> After this I placed the SD back to the host machine and manually deleted the boot folder content on it then manually copied the same stuff to that partition (as the automation script does) .. placed back to the board and it did not boot any more
Jan 04 17:54:50 <peterdev> I think this proves that manually populate the SD card (copy stuff over) is not the solution
Jan 04 17:55:56 <kergoth> well, i boot my panda on a regular basis with yocto produced content
Jan 04 17:55:59 <kergoth> so don't know what to tell you
Jan 04 17:56:12 <kergoth> i partition my card and put the content there directly
Jan 04 17:56:54 <peterdev> I did not directly try that with a yocto image so I'll give it a try now :)
Jan 04 17:59:23 <peterdev> The other problem? I spoted with the yocto output is , that it produces an image what I untar and use the boot folder content to drop it over to the SD boot partition. Someone mentioned that simplu the u-boot.img is not enough on pandaboard.  Must have 3 component in the boot, -> u-boot, MLO,  uImage ... the last 2 piece has not been created by yocto build
Jan 04 18:01:10 <peterdev> https://lists.yoctoproject.org/pipermail/yocto/2012-July/010532.html
Jan 04 18:14:42 <schramae> i'm on x86 as said, so i'm not sure if this works for all platforms. i created a .bbappend file for core-image-minimal and simplay added "inherit image-live" to it. this then automatically created a .hddimg file that contains everything and can be deployed via dd. https://groups.google.com/forum/?fromgroups=#!topic/meta-fsl-arm/TtRA17_QzY8 claims that there might be such a thing like .sdcard file, serving the same purpose as .hddimg
Jan 04 18:15:46 <peterdev> I will look after this, the .bbappend info is new to me. Thanks for this
Jan 04 18:17:07 <schramae> check out the dev manual for this, it is used to customize predefined recipes in your custom layer instead of changing the original .bb/recipe file
Jan 04 18:26:23 <kergoth> meta-ti has a sdcard image type, but it's not nice, it requires modifying /etc/fstab on the build machine
Jan 04 18:26:55 <kergoth> i'm working on a replacement for that at work, but it's on the back-burner right now
Jan 04 18:28:24 <schramae> i see
Jan 04 18:29:32 <peterdev> is it worth using the hob to build content  or is there any drawbacks with it ?
Jan 04 18:30:29 <kergoth> personal preference
Jan 04 18:30:50 <dvhart> kergoth, would be good to coordinate with myself and fray on that as we are also working on some larger scope deployment tooling which includes image types, partitioning, etc.
Jan 04 18:31:13 <dvhart> (or us with you)
Jan 04 18:35:11 <peterdev> okay so I do the following right now. Building a core-image-minimal from hob meta-ti included and pandaboard targeted. I noticed that I have to include u-boot-2011.12-r8 manually otherwise it will not take place in the final image by default. does anybody know if I have to include something else for pandaboard deployment ?
Jan 04 18:36:12 <dvhart> peterdev, hrm, that sounds like a bug in the pandaboard machine definition if the u-boot recipe is indeed required
Jan 04 18:36:52 <dvhart> MACHINE_ESSENTIAL_EXTRA_RDPENDS
Jan 04 18:37:06 <dvhart> http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#var-MACHINE_ESSENTIAL_EXTRA_RDEPENDS
Jan 04 18:37:43 <peterdev> thanks !
Jan 04 21:52:59 <seebs> Is there a reasonably simple way to suppress package_do_filedeps for a specific package? Background: I want to install a bunch of bits and pieces that might or might not be used with a toolchain, and this can result in some bits and pieces being present on a filesystem that has no use for them.
Jan 04 21:53:57 <seebs> It might make more sense to try to split out the pieces in an arch-specific way, but for Sound Technical Reasons it would be preferable (for me) to just have one RPM containing "all those bits over there" without any attempt to figure out what they do or otherwise regard them as anything but raw typeless bits.
Jan 04 21:55:10 <kergoth> heh, we've had someone hit issues with something similar. they tried to package a self contained app + deps in /opt, and it eneded up depending on all sorts of stuff it shouldn't have
Jan 04 22:07:48 <seebs> That is pretty much exactly my situation.
Jan 04 22:08:07 <seebs> ... With the self-contained app, as it happens, being "a prebuilt binary toolchain and its support files". This may sound eerily familiar to you.
Jan 04 22:08:19 <seebs> I think we got it from some company called "Mentor Graphics"; you may have heard of them. :)
Jan 04 22:09:53 <seebs> I'm going to try the really naive and probably stupid approach, which is python do_package_filedeps() {\n\tpass\n}
Jan 04 22:10:01 <seebs> Er, package_do_filedeps.
Jan 04 22:10:27 <seebs> On my to do list: Get screened for dyslexia. I should not have this much trouble not randomly rotating the orders of words.
Jan 04 22:35:00 <ftonello> guys
Jan 04 22:35:16 <ftonello> a kernel recipe should do a PROVIDES += "virtual/kernel" right?!
Jan 04 22:35:32 <ftonello> so I have a kernel recipe, which doesnot inherit kernel.bbclass
Jan 04 22:35:38 <ftonello> and bitbake always says this:
Jan 04 22:35:46 <ftonello> ERROR: Multiple .bb files are due to be built which each provide virtual/kernel (/home/felipe/projects/metadata-poky/meta-g2/recipes-kernel/linux/linux-g2_2.6.36.bb /home/felipe/projects/metadata-poky/poky/meta/recipes-kernel/linux/linux-dummy.bb).
Jan 04 22:36:07 <ftonello> even though I have a PREFERED_PROVIDER_virtual/kernel = "my-kernel"
Jan 04 22:36:14 <ftonello> linux-g2 in that case
Jan 04 22:36:25 <ftonello> any thoughts?
Jan 04 22:44:53 <dvhart> ftonello, maybe something with kernel-base?
Jan 04 22:45:16 <dvhart> ftonello, I'd just compare the PROVIDES and RPROVIDES of the recipes using the bitbake -e command and gather some info that way
Jan 04 22:45:33 <dvhart> that and reviewing the .inc and .bbclasses you are not using that others do
Jan 04 22:45:45 <dvhart> ftonello, or you could use linux-yocto-custom and use your own sources
Jan 04 22:46:08 <dvhart> and take advantage of all the recipe work that has been done in support of the Linux kernel
Jan 04 22:46:44 <dvhart> ftonello, see http://www.yoctoproject.org/docs/hart/kernel-dev/kernel-dev.html#working-with-your-own-sources
Jan 04 22:47:20 <dvhart> ftonello, those docs are under active development, but I think you'll find that will let you do what you want without having to do a ton of duplicate work with the actual recipe.
Jan 04 22:51:36 <ftonello> dvhart: i cant do that because i use other toolchain for this kernel
Jan 04 22:51:54 <ftonello> i dont use any bbclass for the kernel
Jan 04 22:51:57 <ftonello> is just a recipe
Jan 04 22:52:58 <dvhart> Well, without seeing it I obviously can't say for sure, but the use of the toolchain is fairly well parameterized. I believe you could override it relatively easily without having to rewrite everything.
Jan 04 22:53:25 <ftonello> dvhart: i dont think so
Jan 04 22:53:36 <dvhart> ftonello, what you can do is use the dependency explorer to figure out what is pulling in the other linux recipe
Jan 04 22:53:36 <ftonello> i tried before and its a pain to change the toolchain just for one recipe
Jan 04 22:53:49 <ftonello> yes
Jan 04 22:53:51 <dvhart> bitbake -g u depexp IMAGENAME
Jan 04 22:53:57 <dvhart> bitbake -g -u depexp IMAGENAME
Jan 04 22:54:09 <dvhart> that will tell you which recipe pulled in the extra kernel
Jan 04 22:54:30 <dvhart> you can then dig in and see what it DEPENDS on and what your recipe is not PROVIDing
Jan 04 22:54:44 <ant_home> ftonello: we solved this issue (is not a real error) setting PROVIDES = "" in the custom kernel
Jan 04 22:54:49 <ant_home> http://kexecboot.org/documentation/crosscompiling/oe-yocto
Jan 04 22:55:19 <dvhart> ant_home, how does that solve it?
Jan 04 22:55:34 <dvhart> ant_home, the typical packagegroups still DEPEND on kernel-base
Jan 04 22:55:38 <ant_home> dvhart: hello. We'll have to clean -tiny once 3.8 is out
Jan 04 22:55:59 <dvhart> ant_home, is it not building for you?
Jan 04 22:56:21 <ant_home> it is not tiny enough
Jan 04 22:56:26 <dvhart> ah :-)
Jan 04 22:56:38 <dvhart> yes, well, there is definitely room for improvement there
Jan 04 22:56:55 <ant_home> talking with zeddii we aim to have a full-addictive recipe
Jan 04 22:57:09 <ant_home> now I have to add some unset.cfg frags
Jan 04 22:57:29 <dvhart> agreed
Jan 04 22:57:30 <ant_home> i.e. subtracting stuff
Jan 04 22:57:34 <dvhart> just let us know what they are
Jan 04 22:57:54 <ant_home> sure, I have done that for 3.4 but I'd wait for 3.8
Jan 04 22:58:02 <ant_home> Bruce has that
Jan 04 22:58:13 <dvhart> if you send it earlier we can incorporate
Jan 04 22:58:18 <ant_home> it's not only -tiny
Jan 04 22:58:19 <dvhart> OK, please CC me on anything tiny related
Jan 04 22:58:23 <ant_home> sure
Jan 04 23:05:19 <ant_home> dvhart: now I'm atm on 3.2 / armv4 but you'll see in the top lines lot of features whic are nor necessary for our LAB kernel
Jan 04 23:05:25 <ant_home> http://paste.debian.net/221765/
Jan 04 23:07:28 <ant_home> oh, I found a 3.4.20
Jan 04 23:07:30 <ant_home> http://paste.debian.net/221766/
Jan 04 23:10:07 <ant_home> mot notable mismatch (only for armv4) is Requested value: "CONFIG_ARM_THUMB=y"
Jan 04 23:11:53 <ant_home> oh, and Requested value: "CONFIG_PHYSICAL_ALIGN=0x1000000"
Jan 04 23:12:07 <ant_home> I'll send you the /meta tarballs
Jan 04 23:12:16 <dvhart> yeah, that one should be BSP specific
Jan 04 23:12:20 <dvhart> but... email please - yes, thanks :-)
Jan 04 23:28:06 <ftonello> ant_home: why? so how the machine will know which kernel to choose?
Jan 04 23:29:33 <ant_home> standard kernel is defined in machine.conf as PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
Jan 04 23:29:47 <ant_home> custom kerrnel is just a recipe
Jan 04 23:30:43 <ftonello> yes, but does this will impact on anything else?
Jan 04 23:30:55 <ftonello> because it doesnt make sense, at least i didnt see
Jan 04 23:30:56 <dvhart> ant_home, kernels are special and you should PROVIDE virtual/kernel
Jan 04 23:31:11 <dvhart> and then set the provider to your own
Jan 04 23:31:21 <ant_home> well, it depends if thio sis your replacement kernel or a special purpose one
Jan 04 23:34:55 <ant_home> once you inherit kernel.bbclass then your recipe is getting PROVIDES += "virtual/kernel"
Jan 04 23:44:35 <EddyLaiTW> hi, sorry to interrupt your talk, I'm using yocto 1.3 with meta-jasperforst BSP, want to add a new configuration fragment "myNetDev.cfg" , should I put this in "meta-intel/meta-jasperforest/recipes-kernel/linux-octo" or "in "met-intel/meta-jasperforest/recipes-kernel/linux"?
Jan 04 23:44:59 <EddyLaiTW> there's only "recipes-kernel/linux" exist in the original BSP
Jan 05 00:11:33 <EddyLaiTW> and, after I add the new configuration fragment file, can I do "bitbake -k core-image-basic" directly? or should I do "bitbake -k linux-yocto" first?
**** ENDING LOGGING AT Sat Jan 05 02:59:59 2013

**** BEGIN LOGGING AT Sat Jan 05 02:59:59 2013
Jan 05 12:56:26 <peterdev> Hello All, I would like to have a question about yocto deployment images.  I am trying to deploy a minimal image on pandaboard , included the meta-ti layer. Unfortunately the only output file in the tmp/deploy/images folder is a rootfs image without the boot section. Anybody could help me with this ?
Jan 05 13:43:42 <Crofton|work> so hard to help people that ask questions and leave .....
Jan 05 23:52:19 <alexhairyman> any reason why I would be getting an error like this? mkdir: cannot create directory '/../../var/pseudo': Permission denied
Jan 05 23:52:19 <alexhairyman> /home/alexhairyman/stuff/distromakers/yocto/poky-danny-8.0/scripts/bitbake: line 178: /pseudo: No such file or directory
Jan 05 23:52:38 <alexhairyman> can't run with sudo
Jan 06 00:27:06 <alexhairyman> nevermind, I just disabled sanity checking with the network test stuff
**** ENDING LOGGING AT Sun Jan 06 02:59:59 2013

**** BEGIN LOGGING AT Sun Jan 06 02:59:59 2013
Jan 06 09:01:52 <peterdev> hello all
Jan 06 09:05:20 <bmb> hi. is the source code behind this site http://packages.yoctoproject.org/upgradepkgname available somewhere?
Jan 06 09:10:05 <peterdev> Does anyone know why x-load_git.bb, do_compile failing when I build core-image-minimal
Jan 06 09:11:21 <JaMa> your log file probably
Jan 06 09:12:12 <peterdev> I'm checking the log file but unfortunately it does not meen too much to me
Jan 06 09:13:40 <peterdev> I was hoping to find out some minor fix with the meta-ti layer x-load setup which could potentially solve this issue
Jan 06 09:15:58 <peterdev> log showing the following : make: *** No rule to make target `pandaboard_config'.  Stop.
Jan 06 09:16:13 <peterdev> any idea about the fix ?
Jan 06 09:26:03 <peterdev> in more details
Jan 06 09:26:03 <peterdev> NOTE: make CROSS_COMPILE=arm-poky-linux-gnueabi- CONFIG_HEADER= pandaboard_config make: *** No rule to make target `pandaboard_config'.  Stop.
**** ENDING LOGGING AT Mon Jan 07 02:59:58 2013

**** BEGIN LOGGING AT Mon Jan 07 02:59:59 2013
Jan 07 06:43:43 <evilwombat> Hello. I am trying to compile a custom kernel for this device: https://www.yoctoproject.org/product/fish-river-island-2-board
Jan 07 06:44:10 <evilwombat> Is there a clearly documented guide somewhere that explains how to bring up 'make menuconfig' for the kernel that is selected by the current machine / layer configuration ?
Jan 07 07:40:03 <roxell> quit
Jan 07 07:41:50 <roxell> exit
Jan 07 07:41:53 <roxell> ?
Jan 07 08:29:13 <mckoan> good morning
Jan 07 11:10:11 <pdv> hello all
Jan 07 11:10:30 <pdv> silly question. does anybody know how to apply a patch in yocto project ? such as http://permalink.gmane.org/gmane.linux.embedded.yocto.meta-ti/8
Jan 07 11:14:38 <mckoan> pdv: patch -p1 < patchname.diff
Jan 07 11:14:54 <pdv> thanks !
Jan 07 11:15:38 <Crofton|work> that is an old patch though
Jan 07 11:15:51 <Crofton|work> RP, you back to work yet?
Jan 07 11:17:28 <RP> Crofton|work: sadly, yes
Jan 07 11:17:34 <Crofton|work> yay!
Jan 07 11:17:46 <RP> no more craziness like http://www.rpsys.net/avrpi.jpg
Jan 07 11:18:00 <Crofton|work> did you see my email about checksum checking being broken in the .inc/bb file case
Jan 07 11:18:10 <Crofton|work> cool
Jan 07 11:18:11 <RP> Crofton|work: not yet
Jan 07 11:18:14 <Crofton|work> does t work?
Jan 07 11:18:18 <JaMa> Crofton|work: btw I haven't seen this behavior
Jan 07 11:18:35 <RP> the above? yes, communicates with the avr via i2c. Think I found the bugs
Jan 07 11:18:43 <RP> including one kernel patch for the pi we're missing
Jan 07 11:18:52 <Crofton|work> JaMa, for fftw, upadte one recipe version
Jan 07 11:19:06 <Crofton|work> does it make lights blink?
Jan 07 11:19:13 <JaMa> Crofton|work: did you check bitbake -e if it really has old checksums?
Jan 07 11:19:34 <Crofton|work> I am not so good at checksum
Jan 07 11:19:49 <Crofton|work> but it seemed like it would pass the test with about anything in the lines
Jan 07 11:20:11 <Crofton|work> I could very easily make cases that should fail
Jan 07 11:20:30 <Crofton|work> try changing the checksum in one recipe and rebuilding it
Jan 07 11:20:45 <JaMa> you have to remove .done files as someone said
Jan 07 11:20:49 <Crofton|work> yeah
Jan 07 11:21:01 <Crofton|work> I am prettty sure I went through that path also
Jan 07 11:21:22 <Crofton|work> basically, there are ways for it to completely skip the checksum test
Jan 07 11:22:08 <RP> Crofton|work: the lights were blinking in that photo. I had it doing ceylon impressions
Jan 07 11:22:13 <Crofton|work> RP, are those boards lying on your anti static mat?
Jan 07 11:22:27 <RP> Crofton|work: clearly ;-)
Jan 07 11:22:48 <Crofton|work> in the upper right hand corner, is that a flying chip?
Jan 07 11:22:54 <rburton> cunningly disguised as carpet
Jan 07 11:23:04 <RP> Crofton|work: the location of the parallel port for the avr programmer proved the limiting factor
Jan 07 11:23:48 <Crofton|work> why do you need to use a microcontroller with the rpi? rpi not powerful enough? :)
Jan 07 11:23:55 <RP> Crofton|work: its a 20 pin AVR bodged into a 40 pin connector since the stk200 dev board is over a decade old and doesn't have a socket for 20 pin analog avr chips
Jan 07 11:24:09 <RP> Crofton|work: The avr has 11 adc pins
Jan 07 11:24:40 <pdv> sorry guys, does anbody know in which file the XLOAD_MACHINE=... located in meta-ti layer ?
Jan 07 11:24:44 <RP> Crofton|work: think of the avr as an i2c controlled multiple channel adc
Jan 07 11:24:53 <Crofton|work> yeah
Jan 07 11:25:09 <RP> obviously the sensors aren't attached yet
Jan 07 11:25:10 <Crofton|work> pdv grep -i XLOAD -r *
Jan 07 11:25:21 <Crofton|work> what are you going to sense?
Jan 07 11:25:24 <pdv> thank you
Jan 07 11:26:38 <RP> Crofton|work: first up is a current probe to monitor energy usage, followed by mains voltage monitoring to make it more accurate. I'll then start on more boring things like door sensors, PIR, lighting control and other stuff
Jan 07 11:26:48 <RP> take control of the heating system
Jan 07 11:26:58 <RP> need to find something with an rtc for that
Jan 07 11:27:33 <RP> I only blew up one opto isolator so far...
Jan 07 11:29:06 <Crofton|work> just do not blow yourself up :)
Jan 07 11:30:20 <RP> Crofton|work: only the isolator and odd resistors so far. I took the resistor out a bag marked 100k. Basically, it wasn't and I didn't check.
Jan 07 11:30:46 <Crofton|work> can't you read the colour code?
Jan 07 11:32:35 <RP> Crofton|work: yes, didn't think to actually check that :/
Jan 07 11:32:42 <Crofton|work> heh
Jan 07 11:32:51 <RP> I checked every other one :/
Jan 07 11:34:48 <rburton> presumably someone's written an app to read it on a smartphone
Jan 07 11:36:01 <Crofton|work> that would be interesting
Jan 07 11:37:08 <RP> rburton: You mean you can't do it just by looking at resistors?
Jan 07 11:37:23 * RP used to be able to, rather rusty atm :(
Jan 07 11:37:36 <rburton> RP: i think its been about 15 years since i last decoded a resistor
Jan 07 11:41:44 <ant_work> JaMa: as it is, the toolchain is ok for armv4, apart some border cases (klibc). Note I've used patch #36399
Jan 07 12:01:57 <Jin^eLD> RP: are you in charge of the poky ml? I tried to subscribe but never received a mail for subscription request
Jan 07 12:03:01 <RP> Jin^eLD: you should talk to halstead
Jan 07 12:03:09 <Jin^eLD> ok, thanks
Jan 07 12:04:59 <JaMa> RP: hi, there are 2 old patches, sgw said it's waiting for your review http://patchwork.openembedded.org/project/oe-core/list/?submitter=Martin+Jansa&q=scripts
Jan 07 12:06:49 <RP> JaMa: Hi, I've merged them. sorry about the delay
Jan 07 12:07:18 <JaMa> RP: thanks
Jan 07 12:30:42 <otavio> :)
Jan 07 12:30:55 <otavio> A great new year for everybody! :)
Jan 07 12:51:35 <Crofton|work> thanks otavio and the same to you
Jan 07 13:18:16 <RP> otavio: HNY! :)
Jan 07 15:21:00 <JaMa> hmm wasn't AUTOINC proposed to provide upgrade path?
Jan 07 17:24:32 <rburton> booyah, building gtk3 without needing anything but gdk-pixbuf-native
Jan 07 18:07:56 <otavio> RP: around?
Jan 07 18:09:36 <otavio> RP: Eric and I send a patch to fix the libnl build ... it fail to build due the force use of lex (instead of flex)
Jan 07 18:10:08 <otavio> RP: Please review both patches but I think mine is more in line of upstream so I'd take this one. Your call.
Jan 07 18:26:01 <nine_pt> is there a way to generate automatic  a file with all licenses of the packages that are on the image I build ?
Jan 07 18:33:27 <ftonello> anyone having problems to compile gstreamer from poky 8.0?
Jan 07 18:33:38 <ftonello> im having a problem in configure step
Jan 07 19:16:43 <rburton> ftonello: helps if you say what the problem is
Jan 07 19:29:08 <RP> otavio: merged
Jan 07 19:30:10 <otavio> RP: I just finished the update to 3.2.17
Jan 07 19:30:24 <otavio> RP: it has some fixes for build with old kernel headers
Jan 07 19:30:59 <otavio> RP: but I send the proper fix upstream so I will wait him to ack and merge it
Jan 07 19:31:23 <otavio> RP: I have asked for a new release with my fix so we can avoid another patch
Jan 07 19:31:30 <otavio> RP: let's see if they do
Jan 07 19:31:32 <RP> otavio: ok
Jan 07 19:32:32 <otavio> The 3.2.16 also has a segfault with network manager fixed in git ... so 3.2.18 would be a good release I think
Jan 07 19:52:33 <ftonello> rburton: actually the gst_plugin_base failed in the configure step saying that packagekit didnt find gstreamer
Jan 07 19:52:44 <ftonello> i built gstreamer manually before and it worked
Jan 07 19:52:58 <ftonello> buts its wired since gst_plugins.inc has DEPENDS = "gstreamer"
Jan 07 20:14:07 <JaMa> ant_home: have you seen meta-initramfs/recipes-devtools/mtd/ubi-utils-klibc_1.5.0.bb failing to build with latest oe-core? fails to find all kernel headers now
Jan 07 20:14:28 <ant_home> I did a pull today
Jan 07 20:14:34 <ant_home> I'll try now
Jan 07 20:14:40 <ant_home> saturday was working
Jan 07 20:26:45 <JaMa> ant_home: here you can see full log http://logs.nslu2-linux.org/buildlogs/oe/oe-shr-core-branches/qemuarm/20130107094659.log and it was before linux-libc-headers upgrade was pushed
Jan 07 20:27:03 <ant_home> ah, ok...
Jan 07 20:27:11 <JaMa> ant_home: and it was working yesterday too
Jan 07 20:34:51 <ant_home> JaMa: ok, I'll check later. Right now I'm abusing of Khem's time and patience to debug klibc/armv4 on #oe
Jan 07 20:37:51 <aarias> Hi all. I'm a newbie using Yocto. I have been doing some tests during the last 4 months, and now I have a problem I don't know how to solve. I've cloned the openembedde-core repo and I have included the openembedded-core/meta layer in my bblayers.conf file, and I get a problem while parsing the openembedded-core/meta/recipes-gnome/gnome/gnome-icon-theme_2.31.0.bb recipe.
Jan 07 20:39:33 <aarias> If any of you can help me, and if it's needed I can copy&paste the error
Jan 07 20:39:58 <RP> aarias: please do pastebin the error you're seeing
Jan 07 20:40:09 <RP> aarias: there isn't enough info above to help
Jan 07 20:41:23 <aarias> here you can see the pastebin: http://pastebin.com/Du3E8ZCF
Jan 07 20:41:46 <aarias> I have copied the whole output
Jan 07 20:42:12 <aarias> I'm copiling to ARM target
Jan 07 20:42:29 <aarias> just uncommenting the default configurations in the local.conf file
Jan 07 20:45:52 <gjohnson> hello all, I have a 64bit build machine but I want to build i686 cross toolchain.  How can I force yocto to create i686 cross toolchain on a 64bit system?
Jan 07 20:46:14 <kergoth> see SDKMACHINE and the sdk generation recipes
Jan 07 20:47:24 <aarias> in this pastebin you can find my bblayers.conf file: http://pastebin.com/etf4TuFm
Jan 07 20:47:47 <RP> aarias: That error means STAGING_LIBEXECDIR_NATIVE isn't set
Jan 07 20:47:53 <gjohnson> kergoth: I tried setting SDKMACHINE ?= "i686" so in my sysroot directory I have i686-nativesdk-eldk-linux-tcbootstrap and i686-nativesdk-eldk-linux but they don't contain powerpc-linux-gcc.
Jan 07 20:48:13 <RP> aarias: why that isn't set, I'm not sure, it should be
Jan 07 20:48:47 <RP> aarias: Why are you mixing openembedded-core/meta and poky-danny-8.0 ?
Jan 07 20:48:59 <RP> aarias: you want one or the other but not both
Jan 07 20:49:40 <kergoth> gjohnson: sdkmachine only affects the output of the sdk toolchain recipes. the sysroot is somehting else.
Jan 07 20:49:47 <kergoth> (and the -c populate_sdk task of images)
Jan 07 20:49:51 <kergoth> afaik, anyway
Jan 07 20:50:21 <aarias> RP: I tried using openembedded-core because I needed gkt+3 and I found that it was in meta-openembedded/meta-gnome, and this one needs openembedded-core
Jan 07 20:50:44 <kergoth> aarias: meta-oe requires oe-core/meta, which is poky/meta
Jan 07 20:50:49 <RP> kergoth: well, the sysroot he wants is being created. nativesdk does have its own sysroot
Jan 07 20:51:16 <RP> aarias: you have oe-core in poky-danny-8.0/meta already
Jan 07 20:51:34 <RP> aarias: whether its a new enough for meta-oe master I'm less sure about
Jan 07 20:51:58 <RP> aarias: is gtk3 in meta-oe's danny branch?
Jan 07 20:52:49 <RP> gjohnson: did the meta-toolchain output contain the compiler though?
Jan 07 20:53:34 <gjohnson> RP: what do you mean?
Jan 07 20:53:36 <JaMa> yes gtk+3 is in meta-gnome for long time
Jan 07 20:53:50 <aarias> RP: it has gtk+2
Jan 07 20:53:58 <RP> gjohnson: Presumably you did "bitbake meta-toolchain" to run the build?
Jan 07 20:54:14 <aarias> gtk+ 2.24.8
Jan 07 20:54:37 <gjohnson> RP: I did bitbake meta-toolchain-sdk
Jan 07 20:54:52 <gjohnson> RP: should I instead do bitbake meta-toolchain?
Jan 07 20:54:57 <RP> gjohnson: and did the tmp/deploy/sdk/*.tgz not contain what you need?
Jan 07 20:55:17 <aarias> RP: I'm looking in poky-danny-8.0/meta/recipes-gnome/gtk+ and there there is only gtk+ 2.24.8
Jan 07 20:55:23 <RP> aarias: I suspect JaMa knows what he is talking about here. So use the danny branch of meta-oe with poky-8.0 and get rid of that oe-core checkout
Jan 07 20:55:39 <RP> aarias: look in meta-oe
Jan 07 20:55:52 <JaMa> aarias: meta-openembedded checkout to be more precise
Jan 07 20:55:55 <gjohnson> RP: the tmp/deploy/sdk directory only contains eldk-eglibc-i686-powerpc-toolchain-gmae-5.3.sh
Jan 07 20:55:59 <JaMa> aarias: and you need 2 layers from that
Jan 07 20:56:05 <JaMa> aarias: meta-oe and meta-gnome
Jan 07 20:56:27 <RP> gjohnson: which sounds like an archive containing a powerpc toolchain that runs on i686?
Jan 07 20:56:54 <aarias> JaMa: that's what I'm trying, and I found that I needed something from openembedded-core
Jan 07 20:57:05 <gjohnson> RP: Ah, I get it, so that script will install the tool chain on my i686 targets?
Jan 07 20:57:11 <RP> gjohnson: yes
Jan 07 20:57:16 <JaMa> aarias: as kergot said openembedded-core = poky/meta
Jan 07 20:58:04 <gjohnson> RP: Thank you for your help, I am still trying to understand how to use Yocto and how to get the tools pushed out to my developers.
Jan 07 20:58:06 <aarias> JaMa: let me try again, but as far as I remember I got an error
Jan 07 20:58:15 <RP> gjohnson: np
Jan 07 20:59:18 <JaMa> aarias: errors happen when you don't know what you're doing :)
Jan 07 21:00:56 <aarias> JaMa: yes, I know, I am too new in this matter... :(
Jan 07 21:01:30 <JaMa> RP: should I change that dropbear patch somehow or just wait for someone to resolve that bug?
Jan 07 21:02:16 <JaMa> RP: in one layer which is still using dropbear I've added DISTRO_TYPE setting in .bbappend to get it at least consistent across images
Jan 07 21:02:23 <bluelightning> I think I should be able to fix it pretty quickly
Jan 07 21:02:25 <bluelightning> bbl
Jan 07 21:02:40 <bluelightning> (fix it when I get back to work next week, I mean)
Jan 07 21:02:42 <aarias> JaMa: with this bblayers.conf file: http://pastebin.com/3q6A1zvR I get this error: http://pastebin.com/YFx5Py5r
Jan 07 21:03:24 <RP> JaMa: I'm tempted to wait for a proper fix...
Jan 07 21:03:42 <RP> JaMa: I've effectively cleared bluelightning to work on it
Jan 07 21:03:42 <JaMa> aarias: did you checkout danny branch of meta-openembedded?
Jan 07 21:03:44 <aarias> JaMa: and I found that the class gtk-immodules-cache.bbclass is in the openembedded-core repo, and I tried, but as you explained to me it has no sense
Jan 07 21:03:50 <JaMa> RP: ok, thanks
Jan 07 21:04:11 <JaMa> RP: I'll keep that .bbappend because it's for danny anyway
Jan 07 21:04:13 <aarias> JaMa: meta-openembedded
Jan 07 21:04:28 <kergoth> aarias: it sounds like you're comparing master branch meta-oe and oe-core to danny branch poky. they are not compatible. use the same branch everywhere
Jan 07 21:04:44 <aarias> JaMa: ok, I keep mixing things
Jan 07 21:05:40 <aarias> kergoth: I'm using Yocto danny from the tarball, not from the repo, perhaps that's is part of my error
Jan 07 21:06:15 <JaMa> aarias: just checkout right branch of meta-openembedded from repo
Jan 07 21:06:35 <JaMa> it's not important if you have poky in danny version from tarball or repo
Jan 07 21:10:05 <aarias> JaMa: thanks a lot, it works fine
Jan 07 21:10:39 <aarias> I think this time I have learnt the lesson ;)
Jan 07 21:11:24 <aarias> Thanks all for your help, I have still a lot of basic things to learn about this subject
Jan 07 21:11:54 <otavio> Do someone have a build failure in perl?
Jan 07 21:12:06 <otavio> | cp: cannot stat 'lib/XS/{APItest,Typemap}.pm': No such file or directory
Jan 07 22:06:20 <ftonello> you that the recipe xcursor-transparent-theme can be replaced with a -nocursor argument on xorg server
**** ENDING LOGGING AT Tue Jan 08 02:59:58 2013

**** BEGIN LOGGING AT Tue Jan 08 02:59:59 2013
Jan 08 08:45:12 <maxin> fa
Jan 08 09:44:54 <plfiorini> hi
Jan 08 10:21:49 <ant_work> JaMa: hi. Do you have the ubi-utils-klibc log offhand?
Jan 08 10:28:09 <ant_work> JaMa: I guess is like debian 3.7.1.1 linux-headers-common: Include the include/uapi/asm-generic directory
Jan 08 10:28:09 <ant_work>      (Closes: #696664)
Jan 08 10:36:05 <JaMa> no, but I have irc logs
Jan 08 10:37:42 <JaMa> #yocto/2013-01-07.log:21:14 < JaMa> ant_home: have you seen meta-initramfs/recipes-devtools/mtd/ubi-utils-klibc_1.5.0.bb failing to build with latest oe-core? fails to find all kernel headers now
Jan 08 10:37:46 <JaMa> #yocto/2013-01-07.log:21:26 < JaMa> ant_home: here you can see full log http://logs.nslu2-linux.org/buildlogs/oe/oe-shr-core-branches/qemuarm/20130107094659.log and it was before linux-libc-headers upgrade was pushed
Jan 08 10:37:50 <JaMa> #yocto/2013-01-07.log:21:27 < JaMa> ant_home: and it was working yesterday too
Jan 08 10:40:51 <ant_work> ok, thx
Jan 08 10:42:22 <ant_work> ka6sox: the irclog of #yocto ends with yocto.20120126.txt. Any reason?
Jan 08 10:53:16 <otavio> sgw1: Hi
Jan 08 10:53:28 <otavio> sgw1: can you take a look at https://bugzilla.yoctoproject.org/show_bug.cgi?id=3667 ?
Jan 08 10:53:28 <yocti> Bug 3667: normal, Medium, 1.4 M3, otavio, NEW , [Autobuilder] avahi fail on nightly-fsl-arm
Jan 08 10:54:04 <otavio> sgw1: it is not related to the BSP; it try to find a host library, it seems ...
Jan 08 10:54:13 <otavio> sgw1: anyway it is working fine here
Jan 08 10:54:54 <otavio> RP: I sent a perl build fix yestarday. It fixes some bashims
Jan 08 10:55:05 <RP> otavio: and I merged it?
Jan 08 10:55:17 <RP> otavio: 12 hours ago
Jan 08 10:55:18 * otavio checks
Jan 08 10:55:45 <otavio> RP: :-) you are too fast now :-D
Jan 08 10:55:55 <RP> otavio: ;-)
Jan 08 11:00:42 <JaMa> yes, patches are now being merged super fast, thanks! :)
Jan 08 11:01:42 <RP> Sadly the builds are also broken :/
Jan 08 11:03:22 <Crofton> I must take this up with the AB
Jan 08 11:03:24 <Crofton> no more vacations for RP
Jan 08 11:03:36 * Crofton needs coffee
Jan 08 11:04:19 <otavio> RP: I sent the libnl update I told you yestarday; it fixes build with older kernels and has a fix for a callback issue in networkmanager
Jan 08 11:04:34 <RP> otavio: that also merged?
Jan 08 11:04:48 <otavio> RP: no; just send it
Jan 08 11:05:00 <RP> Crofton: That would be an interesting discussion
Jan 08 11:05:29 <otavio> RP: yestarday I patched 3.2.16 to fix the lex failure... now I updated to 3.2.17 plus fixes
Jan 08 11:05:51 <RP> otavio: ok
Jan 08 11:06:21 <RP> I really need to get the autobuilders green before I push much more in...
Jan 08 11:06:29 <RP> Avoid digging a bigger hole
Jan 08 11:07:09 <otavio> RP: What is the build errors?
Jan 08 11:07:19 <RP> otavio: kernel headers failures
Jan 08 11:07:34 <RP> http://autobuilder.yoctoproject.org:8010/builders/nightly-arm/builds/791/steps/shell_29/logs/stdio
Jan 08 11:11:32 <ericben> interesting : "make: arm-poky-linux-gnueabi-gcc: Command not found"
Jan 08 11:12:06 <ericben> in the autobuilder's log
Jan 08 11:13:06 <ericben> and then "make[2]: execvp: /bin/sh: Argument list too long"
Jan 08 11:35:49 <daniel> what is yocto project?
Jan 08 11:36:10 <Guest36155> what is yocto project?
Jan 08 11:36:22 <Guest36155> that is very tiny os project?
Jan 08 11:37:04 <ericben> Guest36155: https://www.yoctoproject.org/ can be tiny or not :)
Jan 08 11:37:59 <Guest36155> thank you for your answer. Maybe I guest that.
Jan 08 11:38:14 <Guest36155> that is for very tiny gadget.
Jan 08 11:38:22 <ericben> what do you mean by "tiny" ?
Jan 08 11:38:34 <Guest36155> very small.
Jan 08 11:38:58 <Guest36155> the OS for very very small devices.
Jan 08 11:39:19 <ericben> that can be a definition of tiny but what is your CPU ?
Jan 08 11:39:25 <Guest36155> yocto is very very very small .
Jan 08 11:39:42 <ericben> yocto is not an OS
Jan 08 11:39:59 <Guest36155> I don't have any CPU. I just want to know what yocto project means.
Jan 08 11:40:57 <ericben> sorry I thougnt your tiny gadget had a CPU to run an a very tiny os. To learn more about yocto you can start here : https://www.yoctoproject.org/about
Jan 08 11:41:07 <Guest36155> Ok, I guest that. that is the software package for very very small devices?
Jan 08 11:41:36 <ericben> Guest36155: read the page first then you will be able to see if that fit your needs
Jan 08 11:41:54 <Zagor> Guest36155: it's a project for embedded linux. it can be small or large. not really "very very small" though
Jan 08 11:41:59 <Guest36155> ok. I visited there. but I coud'nt understand that. so I'm here.
Jan 08 11:42:24 <Guest36155> I'll try to understand the guide there. thanks. :-)
Jan 08 11:42:42 <ericben> Guest36155: if you expect an os like ecos or FreeRTOS : then no that's not the right tool. If you are looking for building and embedded Linux system then that's the right tool
Jan 08 11:44:26 <Guest36155> I want the OS for very very very small devices. so I googled 'yocto'. but, that doesn't match to my needs. thank you :-)
Jan 08 11:45:33 <ericben> Guest36155: if you give numbers for the small device (CPU, MHZ, MB) then you may get detailed answers. But what is very small for you can be very large for someone else (and the reverse is also possible ;-)
Jan 08 11:45:52 * Zagor too wonders what "very very small" means
Jan 08 11:46:02 <ericben> Zagor: ;-)
Jan 08 11:46:34 <Zagor> "oh, just a celeron"
Jan 08 11:46:55 <B4gder> I find it amusing that he searched for yocto as for a small thing
Jan 08 11:47:26 <Zagor> I can't decide if that's a success or a failure :)
Jan 08 11:51:39 <Corneliu> first step: denial
Jan 08 11:51:44 <Corneliu> he will be back :)
Jan 08 11:52:04 <B4gder> 10... 9...
Jan 08 11:59:41 <Corneliu> If you got a little time on your hands, please check out  https://wiki.yoctoproject.org/wiki/Testopia
Jan 08 12:07:41 <Corneliu> feedback is welcome ;)
Jan 08 12:19:48 <Zagor> Corneliu: heh, I was just looking at that page
Jan 08 12:21:13 <Corneliu> Zagor: great! :)
Jan 08 12:22:10 <Corneliu> Zagor: I need to make sure as many people as possible know about Testopia without spamming
Jan 08 12:22:37 <Corneliu> >.<
Jan 08 12:26:48 <Zagor> Corneliu: since I'm working with ptest, I'm trying to see how/if it fits together with Testopia
Jan 08 12:27:23 <Zagor> I can see a product "Automated Runtime Testing". is that close? :)
Jan 08 12:29:38 <Corneliu> Zagor: ptest is for package testing?
Jan 08 12:29:42 <Zagor> yes
Jan 08 12:31:07 <Corneliu> give me a few minutes to read about it a little
Jan 08 12:31:43 <Zagor> I am about to create a new wiki page about it. currently it has only been discussed in the mailing list.
Jan 08 12:35:04 <Corneliu> well because these are runtime tests, you can put them in Runtime - runtime
Jan 08 12:41:02 <Corneliu> Zagor: But Automated Runtime Testing seems right
Jan 08 12:41:38 <Corneliu> Zagor: you can use the Community test plan and play around
Jan 08 12:43:48 <Corneliu> I personally hope that we will rework the names of some products, and also add new ones.. but it needs to be discussed
Jan 08 12:44:12 <Corneliu> they are imported from bugzilla so we have to make due with them atm.
Jan 08 12:46:25 <Corneliu> Zagor: also we might be able to merge ptest with the autobuilder similar to sanity tests
Jan 08 12:46:52 <Corneliu> Zagor: please give me the link to the wiki once it's done so we can look at it
Jan 08 12:47:16 <Zagor> yes, we run ptest in our autobuilder
Jan 08 14:08:08 <otavio> RP: The libnl upstream has released 3.2.18; I will send a patch soon
Jan 08 14:08:15 <otavio> RP: so ignore 3.2.17 please
Jan 08 14:08:40 <RP> otavio: ok
Jan 08 14:15:52 <otavio> RP: done.
Jan 08 14:34:28 <qt-x> hello
Jan 08 14:35:48 <qt-x> dose enaybody kow somthing about:          ERROR: Multiple .bb files are due to be built which each provide udev (/home/test/fsl-community-bsp/sources/meta-openembedded/meta-oe/recipes-core/udev/udev_173.bb /home/test/fsl-community-bsp/sources/meta-openembedded/meta-oe/recipes-core/systemd/systemd_git.bb).
Jan 08 14:37:16 <JaMa> qt-x: define PREFERRED_PROVIDER
Jan 08 14:37:46 <JaMa> and read this https://bugzilla.yoctoproject.org/show_bug.cgi?id=3622
Jan 08 14:37:46 <yocti> Bug 3622: normal, Medium, 1.4, richard.purdie, NEW , select preferred provider for multiple runtime providers
Jan 08 14:38:06 <JaMa> and https://bugzilla.yoctoproject.org/show_bug.cgi?id=3645
Jan 08 14:38:06 <yocti> Bug 3645: normal, Medium, 1.4, richard.purdie, NEW , Using wrong data when 2 recipes provide same runtime package
Jan 08 14:57:27 <Zagor> Corneliu: first version: https://wiki.yoctoproject.org/wiki/Ptest
Jan 08 14:59:22 <Corneliu> Zagor: ty
Jan 08 15:28:06 <agherzan> Hello.
Jan 08 15:28:53 <agherzan> update-alternative is used only at rootfs generation right?
Jan 08 15:29:05 <agherzan> not while writing in the sysroot too.
Jan 08 15:29:08 <agherzan> AM i right?
Jan 08 15:30:19 <kergoth> afaik that's correct, yes
Jan 08 15:30:25 <kergoth> postinsts are never run in sysroot context
Jan 08 15:30:51 <agherzan> kergoth, well... just wanted to be sure. What to do to avoid some useless warnings if a package installs a binary already in sysroot
Jan 08 15:30:54 <agherzan> for example
Jan 08 15:31:02 <agherzan> coreutils and shadow - groups binary
Jan 08 15:32:40 <agherzan> in a normal build coreutils-native is not triggered. But in a GPLv3-free build we use another recipe version which needs coreutils-native. In this way in my build i get coreutils-native too and associated warnings.
Jan 08 15:33:19 <agherzan> how to you guys see the fix for this?
Jan 08 15:35:36 <agherzan> i can obviously patch coreutils to skip kill and groups...
Jan 08 15:57:45 <Corneliu> is the meeting canceled?
Jan 08 15:58:00 <rburton> Corneliu: saul sent out an agenda earlier
Jan 08 16:00:56 <sgw1> YPTM: Is a happening
Jan 08 16:01:01 <jmpdelos> YPTM: Jeff Polk is on
Jan 08 16:01:03 <kergoth> YPTM: Chris Larson here
Jan 08 16:01:06 <sgw1> Participant passcode: 76994298
Jan 08 16:01:06 <sgw1> Dial-in number: 1.972.995.7777
Jan 08 16:01:10 <tomz1> YPTM: Tom Z here
Jan 08 16:01:13 <scottrif> YPTM: Scott Rifenbark dialed in
Jan 08 16:01:27 <Zagor> YPTM: Björn Stenberg here
Jan 08 16:01:55 <rburton> YPTM: ross joining
Jan 08 16:02:02 <scottrif> sgw1: Happy NY
Jan 08 16:02:02 <jzhang-laptop> YPTM: jzhang's on
Jan 08 16:02:09 <belen> belen just joined
Jan 08 16:02:15 * sgw1 asks for opens
Jan 08 16:02:21 <Corneliu> YPTM: Cornel
Jan 08 16:02:34 <strassek> YPTM: Kevin Strasser is dialing in
Jan 08 16:02:46 <dvhart> YPTM: Darren is on
Jan 08 16:02:54 <Ramana_> Happy New Year...This is Ramana joined YPTM
Jan 08 16:02:54 * scottrif has open: BitBake manual
Jan 08 16:03:15 <RP> YPTM: RP is on the call
Jan 08 16:03:44 <zeddii> YPTM: Bruce Ashfield on the call.
Jan 08 16:04:16 <fray> YPTM: Mark is on the call
Jan 08 16:04:28 * sgw1 asks for any opens
Jan 08 16:04:35 <davest> YPTM: davest just joined
Jan 08 16:04:58 * scottrif has open
Jan 08 16:06:02 <darknighte> YPTM: Sean Hudson from Mentor Graphics is on the call
Jan 08 16:06:42 <scottrif> BitBake Manual rewrite in progress and the latest developments can be found in the yocto-docs Git repository in the 'wmat' branch.
Jan 08 16:06:59 <sgw1> zenlinux: are you on the call?
Jan 08 16:12:12 <sgw1> scottrif: can you put a full URL
Jan 08 16:14:08 <scottrif> sgw1: sure - http://git.yoctoproject.org/cgit/cgit.cgiyocto-docs/log/?h=wmat
Jan 08 16:14:59 <scottrif> sgw1:  Also, Bill (the person working on the BB manual) has set up a wiki page where people can comment or provide input on how this manual develops at https://wiki.yoctoproject.org/wiki/BitBake/UserManual
Jan 08 16:20:51 <darknighte> dvhart: when would this become available to yocto?
Jan 08 16:22:19 <darknighte> dvhart: thx.
Jan 08 16:22:30 * darknighte has lost his voice today
Jan 08 16:24:25 <RP> scottrif: You mean http://git.openembedded.org/bitbake/log/?h=wmat right?
Jan 08 16:26:11 <scottrif> RP:  Yes - my mistake.  there is a 'wmat' branch in yocto-docs as well.  sorry for the confusion
Jan 08 16:26:49 <scottrif> sgw1:  Branch where BB manual is being done - http://git.openembedded.org/bitbake/log/?h=wmat
Jan 08 16:27:05 <kergoth> side note: parted's scripting language doesn't support specifying partition alignment in a useful way (it relies on it what it gets from the device, which is squat for an image file). should patch that in, as some devices expect particular alignment (panda seems unhappy if the first partition isn't aligned at 63 sectors)
Jan 08 16:28:25 <fray> I was under the impression if you used libparted or otherwise you could declare things on a byte boundry.. then you just had to determine the sector type config..
Jan 08 16:28:38 <fray> but this is the kind of thing that we need to go through to figure out exactly how and what is needed..
Jan 08 16:28:53 <fray> the technical bits are fairly simple, the documentation, command and control aren't..
Jan 08 16:28:56 <kergoth> yeah, if you use libparted or pyparted, you can control it, its just the commandline/interactive interface that's limited
Jan 08 16:29:04 * kergoth nods
Jan 08 16:29:21 <dvhart> kergoth, thanks! I think pyparted is a likely/appropriate mechanism for this
Jan 08 16:30:12 <Corneliu> https://wiki.yoctoproject.org/wiki/Testopia
Jan 08 16:30:21 <b737800> hello evry one
Jan 08 16:30:43 <otavio> kergoth: you can do the partitions using sectors directly
Jan 08 16:31:18 <otavio> fray: yes; it can have or not constraints
Jan 08 16:31:26 <otavio> fray: but only when using the lib
Jan 08 16:31:38 <kergoth> dvhart: https://gist.github.com/4388948 - not the best code around, but i started playing with it to produce an sdcard image for my panda, but i found there was a limited amount of pyparted example code around
Jan 08 16:31:38 <otavio> fray: I used to be the RM of GNU Parted :)
Jan 08 16:31:51 <otavio> fray: I might be able to help if need.
Jan 08 16:31:53 <kergoth> nice
Jan 08 16:31:54 <fray> nice..
Jan 08 16:32:02 <fray> ya, we'll definitely need help on that..
Jan 08 16:32:21 <fray> declaring the (disk) image and partition settings is my biggest concern..
Jan 08 16:32:47 <dvhart> kergoth, excellent - thanks
Jan 08 16:33:04 * dvhart adds to his deployment notes
Jan 08 16:33:45 * sgw1 asks again for final opens 
Jan 08 16:33:57 <otavio> fray: just as a side note for research later; it would be good to learn about parted_server, the bridge between shell script and libparted used in Debian Installer. It might help on it as well
Jan 08 16:34:21 <kergoth> otavio: oh, that does sound interesting
Jan 08 16:34:35 <otavio> kergoth: it is, and it is quite powerful
Jan 08 16:34:50 <otavio> kergoth: check partman-base source package in Debian
Jan 08 16:35:09 <otavio> kergoth: :-)
Jan 08 16:35:16 <dvhart> otavio, thanks
Jan 08 16:35:20 <walters> incidentally, has there been any discussion of libguestfs?  i'm using it in my oe-based project now
Jan 08 16:35:38 * otavio never used guestfs
Jan 08 16:35:48 <walters> it's quite a large host dependency is probably the main downside
Jan 08 16:35:56 <RP> sgw1: http://www.rpsys.net/avrpi.jpg
Jan 08 16:35:57 <dvhart> walters, yes, I looked at guestfs very closely
Jan 08 16:36:07 <walters> the fuse bits are also slightly buggy (e.g. https://bugzilla.redhat.com/show_bug.cgi?id=892834 ) but, such is life
Jan 08 16:36:07 <yocti> Bug 892834: was not found.
Jan 08 16:36:09 <dvhart> it would add something lke 10+ minutes to build times
Jan 08 16:36:23 <dvhart> walters, the problem is needing to generate the guest OS image
Jan 08 16:36:52 <walters> dvhart, right, that's what my scripts are doing, and yeah, it is a lot slower than a loopback mount =/
Jan 08 16:37:07 <dvhart> so after talking about that for a bit, I managed to get a couple of the various FS maintainers (Ted and Chris) to agree to better support for initial directory support.
Jan 08 16:37:28 <darknighte> RP: nice.
Jan 08 16:37:29 <walters> but the genext2fs thing is not really sustainable i don't think
Jan 08 16:37:44 <dvhart> walters, right, it's already broken honestly.
Jan 08 16:38:10 <darknighte> RP: did you build out the yellow board? or what?
Jan 08 16:38:19 <dvhart> walters, I'm patching support into e2fsprogs (libext2fs, debugfs, and mke2fs) directly
Jan 08 16:38:51 <dvhart> all the others already have something in place for an initial directory
Jan 08 16:39:15 <dvhart> you still need pseudo in order to intercept the stat syscall and remap the uid/gid etc
Jan 08 16:39:17 <walters> dvhart, interesting.  So not fuse-based, something fixed-function like "import this tarball" into / ?
Jan 08 16:39:48 <dvhart> mke2fs -i /my/target/root/dir rootfs.img
Jan 08 16:39:53 <dvhart> like that
Jan 08 16:39:58 <walters> right
Jan 08 16:41:25 <walters> i guess vs libguestfs then you lose out on the ability to do things like LVM/mdadm/luks, but if your main goal is just "runqemu" for testing purposes, should be fine
Jan 08 16:41:54 <RP> darknighte: its a development board from 12 years ago, I'm just using it as an interconnect between the other pieces
Jan 08 16:41:58 <dvhart> walters, that is an advantage of guestfs. I haven't looked at how to address those yet.
Jan 08 16:42:17 <dvhart> walters, do you use those in your embedded system deployment?
Jan 08 16:42:22 <RP> darknighte: Ultimately there is a chunk of interface board the AVR will be connected to, this was just debugging the interface
Jan 08 16:42:26 <dvhart> walters, if so - fray and I would like to hear more about that
Jan 08 16:42:45 <dvhart> tomz1, zeddii dialing
Jan 08 16:43:07 <b737800> i have a question on recipe versions can some one help ?
Jan 08 16:43:09 <darknighte> RP: looks like something from my college years. ;)  what's the socketed DIP on the baby board?
Jan 08 16:43:19 <walters> dvhart, well I use OE to bootstrap a buildroot for a somewhat more general purpose system - of those things, long term LUKS is pretty important to me
Jan 08 16:43:46 <rburton> b737800: just ask, don't ask to ask
Jan 08 16:43:48 <RP> darknighte: there is a SRAM on there from a previous project but I'm not using it
Jan 08 16:43:49 <dvhart> b737800, just ask - someone will help if they can :-)
Jan 08 16:44:10 <RP> 12 years ago I built a kart data logger with an ATMega8515 and 256 kb external ram
Jan 08 16:44:17 <walters> but the other way to go about this is to just use genext2fs to make an *installer* image, and then automate the installer in qemu
Jan 08 16:44:44 <RP> the 8515 can only address 64kb you might think from the specs but I added in some extra bits...
Jan 08 16:44:53 <darknighte> heh. what were you collecting data on?
Jan 08 16:45:21 <darknighte> from your kart?  surely not mileage!  ;)
Jan 08 16:45:37 <b737800> ok i have two recipes which build two component A and B . both A ad b DEPNDS in LIBX, however A depends on V1 of LIBX and B DEPENDS on V2 of LIBX i tried to use PREFERED_VERSIOn_LIBX on each recipe but this does not seems to work
Jan 08 16:45:56 <b737800> any siggestions ?
Jan 08 16:45:56 <RP> darknighte: revs, temperature and acceleration
Jan 08 16:46:12 <RP> darknighte: wanted to so software track mapping from the acceleration data
Jan 08 16:46:37 <darknighte> heh.  wow, that's a whole different level of geeky and "gearhead" all put together.
Jan 08 16:46:37 <dvhart> zeddii, poke poke
Jan 08 16:46:41 <RP> Sadly I only had a *1*86 laptop and development didn't work well trackside
Jan 08 16:46:52 <RP> laptop being tabletop
Jan 08 16:46:55 <rburton> b737800: you can generally only build one version of a recipe. if both versions can be installed at the same time - and most libraries can't do that - then you can put the version in the recipe name. i.e libx-1_1.0.bb and libx-2_2.0.bb
Jan 08 16:47:00 <otavio> b737800: package both libraries with verion in package name and use those.
Jan 08 16:47:06 <darknighte> RP: I imagine
Jan 08 16:47:17 <RP> that and electrical noise from the kart destroying electronics
Jan 08 16:47:44 <b737800> how do i package both libraries with verion in package name ?
Jan 08 16:47:44 <RP> 120kV from the ignition enjoyed finding the microcontrollers
Jan 08 16:48:02 <rburton> b737800: rename the recipe like i told you
Jan 08 16:48:02 <darknighte> ouch.
Jan 08 16:48:21 <darknighte> so, what type of AVR are you connecting to?
Jan 08 16:48:56 <RP> darknighte: here? attiny861. I want the ADCs
Jan 08 16:49:18 <darknighte> yes
Jan 08 16:49:21 <RP> well, 11 input mux and ADC
Jan 08 16:49:33 <b737800> ok i will test that ... thanks
Jan 08 16:49:51 <rburton> b737800: big assumption is that both versions co-exist. trust me, that's rare.
Jan 08 16:50:30 <darknighte> I missed the goal of the project.
Jan 08 16:50:51 <RP> darknighte: home automation is probably as good a description as any
Jan 08 16:51:05 <walters> random question while the channel is active: is python3 on anyone's radar?
Jan 08 16:51:19 <darknighte> heh.  so, really, "just for fun", but might be useful too?
Jan 08 16:51:27 <rburton> walters: erm patches welcome? :)
Jan 08 16:51:42 <RP> darknighte: I need some real world things from this, it will see deployment
Jan 08 16:51:53 <walters> rburton, the patch set on top of python2 is intimidating
Jan 08 16:52:11 <rburton> walters: yes
Jan 08 16:52:11 <RP> walters: we've talked about it. Its a lower priority than some other things atm
Jan 08 16:52:29 <RP> walters: if python cross compiled safely it would be a help. It doesn't
Jan 08 16:52:33 <walters> RP, yeah, makes sense
Jan 08 16:52:55 <darknighte> RP: sound like fun.  let me know what yo uend up using it for.
Jan 08 16:53:04 * darknighte leaves for early lunch
Jan 08 16:53:20 <RP> darknighte: I'll probably blog something eventually, assuming I find the time
Jan 08 17:10:05 <dvhart> zeddii_home, https://wiki.yoctoproject.org/wiki/Kernel/1.4_Planning
Jan 08 18:16:24 <hollisb> is it a good idea to mount /tmp noexec? do people actually do that?
Jan 08 18:28:42 <mranostay> hollisb: seems kinda tin foil hatty
Jan 08 18:29:43 <hollisb> well, there's plenty of discussion about doing it to mitigate damage from insecure web apps... I just can't tell if it's actually common or recommended
Jan 08 18:30:04 <hollisb> Ubuntu doesn't seem to do it for x86/desktop...
Jan 08 18:30:15 <rburton> many people don't mount /tmp as a separate filesystem, which makes it tricky
Jan 08 18:30:26 <hollisb> yeah
Jan 08 18:30:27 <rburton> you do need to vet your stuff to make sure that nothing assumes /tmp is executable
Jan 08 18:31:10 <hollisb> rburton: that's the assertion I'm trying to validate :-)
Jan 08 18:31:31 <mranostay> rburton: kinda dumb if you running binaries from /tmp though :)
Jan 08 18:31:36 <mranostay> *you're
Jan 08 18:31:52 <rburton> mranostay: random apps are pretty dumb
Jan 08 18:32:30 <mranostay> does noexec apply even to root?
Jan 08 18:37:57 <mranostay> so anyone else get their FRI2 yesterday?
Jan 08 18:42:21 <fray> Ohh they're shipping?
Jan 08 18:42:51 <mranostay> yeah have mine
Jan 08 18:44:23 <fray> I have one, but havn't had time in the last few weeks to make it do anything more then run YP code..
Jan 08 18:44:50 * fray wants to get the 3g modem -- and create some UI software so it can be an infotainment unit in my car...
Jan 08 18:47:28 <mranostay> i do like the "lease" terms in box... basically don't let us catch you listing this on ebay :)
Jan 08 18:48:57 <fray> Well, I work for WR.. so I'm not allowed to sell it.. :)
Jan 08 18:55:29 <mranostay> fray: i'm sure there is a huge black market  for dev boards :P
Jan 08 18:56:03 <fray> for cool devboards there may be.... the FRI2 is pretty cool for form factor and function..
Jan 08 18:56:07 <fray> the dual HDMI is interesting..
Jan 08 18:56:28 <fray> I need to figure out if they make 7" touchscreens that are HDMI or DVI-D.. ;)
Jan 08 18:57:09 <mranostay> overkill :)
Jan 08 18:57:41 <fray> not for the auto infortainment that I want..
Jan 08 18:58:01 <fray> dual touch screens.. over a HDMI/USB cable would be ideal for cable management..
Jan 08 18:58:09 <fray> then the unit itself could live in the trunk of elsewhere..
Jan 08 19:01:03 <mranostay> i assume this has audio over HDMI right?
Jan 08 19:02:59 <jstashluk> otavio: ping
Jan 08 19:03:09 <otavio> jstashluk: hi
Jan 08 19:03:37 <jstashluk> hi, is gpu-viv-bin-mx6q meant to provide libGL (not GLES)?
Jan 08 19:03:50 <otavio> jstashluk: no; just GLES
Jan 08 19:04:04 <otavio> jstashluk: well, GLES EGL and OpenVG IIRC
Jan 08 19:06:47 <jstashluk> otavio: ok, the recipe has libgl-mx6 libgles-mx6 and libgles2-mx6 in PACKAGES, so I was confused.
Jan 08 19:07:53 <otavio> jstashluk: Sorry; you're right. Vivante has GL ... AMD does not. Sorry.
Jan 08 19:16:00 <otavio> jstashluk: but are you having any problem?
Jan 08 19:16:43 <jstashluk> otavio: I am trying to figure out how to get yocto to build vanilla gl
Jan 08 19:17:09 <otavio> jstashluk: you want mesa-dri than
Jan 08 19:18:12 <jstashluk> otavio: so I simply add that to the package recipe RDEPENDS?
Jan 08 19:18:30 <otavio> jstashluk: no; to depends
Jan 08 19:18:36 <otavio> jstashluk: well what you wish?
Jan 08 19:19:14 <otavio> jstashluk: you wish your board to not use vivante drivers?
Jan 08 19:20:58 <jstashluk> otavio: i would like to experiment with PBOs GLES does not have them
Jan 08 19:21:37 <otavio> PBOs?
Jan 08 19:21:55 <jstashluk> otavio: pixel buffer objects
Jan 08 19:23:57 <otavio> Oh I see
Jan 08 19:24:15 <otavio> jstashluk: but you'll need to use th vivante drivers or it won't talk to the gpu
Jan 08 19:25:05 <jstashluk> otavio: glReadPixels takes 28ms for 960x720, so I need to render in parallel with the read.
Jan 08 19:25:34 <jstashluk> otavio: i only have 33.3ms to work with, so 28 is a killer.
Jan 08 19:26:19 <jstashluk> otavio: ah, then I still have a problem
Jan 08 19:27:58 <jstashluk> otavio: there is a libGL.so.1.2 in the gpu-viv-bin-mx6q. Is that what I want?
Jan 08 19:28:18 <otavio> jstashluk: I think so
Jan 08 19:30:27 <jstashluk> otavio: so I was able to build with mesa-dri.  here goes nothing?
Jan 08 19:40:50 <jstashluk> otavio: do you ever get "FEC: Link is down 7949" when using BOOTP for NFS?
Jan 08 19:41:46 <otavio> jstashluk: humm
Jan 08 19:41:50 <otavio> jstashluk: which board?
Jan 08 19:42:19 <otavio> jstashluk: people at Bondary has fixed some network issues
Jan 08 19:43:43 <jstashluk> otavio: nitrogen6x
Jan 08 19:44:38 <otavio> jstashluk: right ... We have fixed the kernel with those patches but they might have did something in U-Boot as well; did you upgrade their u-boot in the SPI NOR?
Jan 08 19:45:16 <jstashluk> otavio: no, I haven't. Thanks. I'll take a look.
Jan 08 19:46:56 <otavio> jstashluk: np
Jan 08 19:59:57 <jstashluk> otavio: is smoke supposed to come out of the SPI NOR when I access it?
Jan 08 20:00:10 <otavio> Uh?
Jan 08 20:00:53 <jstashluk> otavio: I think Eric is getting an email here pretty soon.
Jan 08 20:01:17 <otavio> jstashluk: what do you mean?
Jan 08 20:01:40 <otavio> jstashluk: ah; the upgrade did not work?
Jan 08 20:01:58 <jstashluk> jstashluk: I just tried to run one of the u-boot scripts, and a wisp of smoke came up from the board.
Jan 08 20:02:16 <jstashluk> otavio: the sd card was too hot to touch.
Jan 08 20:02:53 <otavio> ouch!
Jan 08 20:03:13 <kergoth> yikes
Jan 08 20:05:24 <mranostay> yeah i'm pretty sure that isn't suppose to happen
Jan 08 20:07:21 <jstashluk> I have a non-standard device hanging off of the SPI lines, I bet something got overdriven because of the bit antenna.
Jan 08 20:07:28 <jstashluk> *big
Jan 08 20:12:44 <mranostay> so silly question is there a package feed anywhere for poky?
Jan 08 20:45:09 <kergoth> anyone know wh at LIMIT_BUILT_LOCALES is in poky.conf? as far as i cna see that isn't referenced anywhere. perhaps it was intended to be GLIBC_GENERATE_LOCALES, which is obeyed by libc-package.bbclass?
Jan 08 21:08:59 <evanp> kergoth: I see it in glibc.inc back in 1.1
Jan 08 21:12:53 <kergoth> heh, remnant i guess. thanks
Jan 08 22:05:06 <sgw1> kergoth: the mkbuiltins patch  1fd9a16d2a4594a4e9179dc7353ac51ce32eb712 seems to be causing problems on Ubuntu hosts, we are seeing failures like bug 3646
Jan 08 22:05:06 <yocti> Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=3646 normal, Medium+, 1.4 M3, saul.wold, NEW , non GPLv3 build failure with core-image-basic
Jan 08 22:13:58 <kergoth> sgw1: that failure is what that patch *fixed*
Jan 08 22:14:51 <kergoth> sgw1: that fix wasn't applied to the non-gplv3 bash (3.2.48), only 4.2.
Jan 08 22:15:25 <sgw1> kergoth: just figured that out, make and testing that patch right now!
Jan 08 22:15:55 <kergoth> cool
Jan 08 22:16:38 <kergoth> it should probably be fixed in a different way for upstream, should look at that one of these days
Jan 08 22:17:05 <sgw1> I saw your patch upstream for 4.2 was that rejected?
Jan 08 22:31:42 <kergoth> indirectly, they seemed to agree with the need for the fix, but not the particular method. haven't had time to revisit
**** ENDING LOGGING AT Wed Jan 09 02:59:59 2013

**** BEGIN LOGGING AT Wed Jan 09 02:59:59 2013
Jan 09 08:54:12 <eFfeM_work> hi, anyone any experience building danny with uclibc?
Jan 09 08:54:15 <eFfeM_work> got this: | ../libblkid/src/.libs/libblkid.so: undefined reference to `my_llseek'
Jan 09 08:56:13 <mckoan> good morning
Jan 09 09:34:37 <b737800> hello evry one
Jan 09 09:38:23 <b737800> I'm working on a project where we have defined custom images, and we want to be able to generate both production images and dev-images containning dev versions
Jan 09 09:38:32 <b737800> of packages present in production images
Jan 09 09:39:24 <b737800> i fiound that IMAGE_FEATURES+="dev-pkgs" may solve the problem
Jan 09 09:39:37 <b737800> however this does not semms to work
Jan 09 09:39:43 <b737800> any suggestion ?
Jan 09 10:20:40 <JaMa|off> rburton: Hi, can you please update meta-oe patches with review comments, so I can merge them?
Jan 09 10:21:24 <rburton> JaMa|off: what ones in particular :)
Jan 09 10:21:59 <JaMa|off> gst*
Jan 09 10:22:17 <rburton> righto
Jan 09 10:22:38 <JaMa|off> Paul's comment in "[oe] [meta-multimedia PATCH V2 1/6] gssdp: add 0.12.2.1 and 0.13.2"
Jan 09 10:23:08 <JaMa|off> and koen's in "[meta-multimedia PATCH V2] gst123: add package"
Jan 09 10:24:12 <rburton> oh i'd done gst123 in the branch already
Jan 09 10:26:45 <rburton> JaMa|off: happy with branch pointers, or do you want patches in mails?
Jan 09 10:27:11 <rburton> all pushed to meta-oe-contrib now
Jan 09 10:28:20 <ant_work> JaMa|off: I could not reproduce the build error yesterday for ubi-utils-klibc / armv4, fresh pull
Jan 09 10:29:47 <JaMa|off> rburton: branch is fine
Jan 09 10:30:08 <JaMa|off> ant_work: other klibc failed today in build from scratch too
Jan 09 10:30:30 <rburton> JaMa|off: meta-oe-contrib, ross/gst for gst123, ross/dleyna (first half) for the gupnp packages.  i'll submit the media service bits shortly to the list.
Jan 09 10:30:45 <ant_work> JaMa|off: which target?
Jan 09 10:31:25 <JaMa|off> ant_work: qemuarm
Jan 09 10:32:50 <ant_work> ok, I've fixed klibc right yesterday wrt missing FIX_V4BX
Jan 09 10:33:08 <ant_work> I'm working on that recipe. I hope I'll fix that soon
Jan 09 10:33:09 <JaMa|off> rburton: btw why aren't you using openembedded-core/scripts/create-pull-request? it would be a bit easier to show URL and branch of pull
Jan 09 10:33:27 <JaMa|off> maybe I've asked this before
Jan 09 10:34:59 <rburton> JaMa|off: because sometimes i'm lazy and just use send-email
Jan 09 10:45:29 <eFfeM_work> anyone familiar overriding/adding uclibc config in danny ? (need lfs support, this is default off)
Jan 09 11:01:50 <JaMa|off> ant_work: http://logs.nslu2-linux.org/buildlogs/oe/oe-shr-core-branches/20130109012500.log shows kexec-tools-klibc kexecboot-klibc ubi-utils-klibc failing
Jan 09 11:52:55 <rburton> right that's it i'm wiping my tmp
Jan 09 11:53:06 <rburton> now opkg is insisting it can't find the packages it just built :/
Jan 09 11:58:43 <thaytan> rburton: um, yay
Jan 09 11:58:45 <thaytan> sstate?
Jan 09 12:36:50 <rburton> thaytan: more likely the deploy tree being massively confused from me switching branches, adding and removing meta-oe, etc
Jan 09 13:40:29 <panda84kde> hi rburton
Jan 09 13:43:12 <rburton> hi panda84kde
Jan 09 13:45:30 <panda84kde> i've seen your patch: http://comments.gmane.org/gmane.comp.handhelds.openembedded.core/31677
Jan 09 13:46:42 <rburton> right
Jan 09 13:47:29 <panda84kde> I understand the small change, but it looks like it's giving me problems: I get a lot of http://pastebin.com/9srUFbHx and then "Segmentation fault (core dumped)"
Jan 09 13:48:18 <rburton> panda84kde: i saw that once, hoped it was spurious, and meant to retest it again.  can you reply saying its broken?
Jan 09 13:48:23 * rburton -> lunch
Jan 09 13:48:31 <rburton> panda84kde: i guess a better fix would be to rm build-native first
Jan 09 13:48:36 <rburton> as it clearly doesn't like rebuilding
Jan 09 13:49:01 <panda84kde> ok, I'll do that.
Jan 09 13:49:10 <panda84kde> Moreover (but this is unrelated to your patch) I get this building error: http://pastebin.com/Qa7GLzwz
Jan 09 13:49:19 <panda84kde> do you have this too?
Jan 09 13:49:26 <panda84kde> rburton: have a good lunch!
Jan 09 13:49:41 <rburton> actuall i didn't get a segfault, i got a make forkbomb
Jan 09 13:49:54 <rburton> never seen that failure though
Jan 09 13:50:41 <panda84kde> ok, thank you anyway
Jan 09 13:52:21 <panda84kde> I think I got the segfault as a result of an hour of forkbomb
Jan 09 14:38:03 <rburton> JaMa: oh you merged my dleyna stuff too - that saves some work :)
Jan 09 14:38:58 <JaMa> rburton: looks good on world build and for new recipes I think it's better then nothing
Jan 09 14:39:20 <JaMa> rburton: if someone finds some issues with them in runtime I belive you'll promptly fix it in follow up
Jan 09 14:39:31 <rburton> sure
Jan 09 14:39:51 <rburton> i'm not using them directly but looking after them on behalf of the team here that wrote all that
Jan 09 14:45:05 <ant_work> JaMa: I'll take care of the 3 in meta-initramfs
Jan 09 14:52:43 <JaMa> ant_work: ok, khem took care of obexd
Jan 09 14:56:43 <otavio> RP: Can you apply libnl 3.2.18 please? This fixes a build failure of meta-fsl-arm as it uses old Kernel headers for i.MX2[38] and i.MX5
Jan 09 15:01:21 <RP> otavio: I'm holding off more patches until I can get the ones we've merged fixed
Jan 09 15:02:26 <otavio> RP: right; but libnl is broken (for my case). Anyway ... that's fine.
Jan 09 15:08:09 <otavio> RP: the build failure is still in linux-headers?
Jan 09 15:08:20 <RP> otavio: yes. zeddii is looking into it
Jan 09 15:47:52 <rburton> panda84kde: i switch libmusicbrainz to rm -rf and now it won't configure at all
Jan 09 15:48:23 <rburton> CMake Error at src/CMakeLists.txt:19 (INCLUDE):
Jan 09 15:48:25 <rburton>   include could not find load file:
Jan 09 15:48:27 <rburton>     /data/poky-master/tmp/work/core2-poky-linux/libmusicbrainz/5.0.1+gitAUTOINC+0749dd0a35b4a54316da064475863a4ac6e28e7e-r0/git/build-native/ImportExecutables.cmake
Jan 09 15:48:30 <rburton> which is a lie, it's there
Jan 09 15:49:06 <panda84kde> how weird. I switched to rm -rf and worked for me :)
Jan 09 15:50:09 <rburton> yeah its when rebuilding
Jan 09 15:50:21 <rburton> force do_configure to run and it will break
Jan 09 15:51:30 <kergoth> it kind of annoys me that machines add tar.gz/tar.bz2 to their image fstypes. if its nfs only, okay, otherwise i'd think it should either be something the distro would add or something that would be added based on the user indicating they want nfsroot capability
Jan 09 15:51:34 <panda84kde> I'm not really into this "bb" thing. I just tried what you suggested me.
Jan 09 15:54:43 <khem> kergoth: FS_TYPES should be a distro/image policy not machine policy IMO
Jan 09 15:55:17 * kergoth nods
Jan 09 15:56:30 <kergoth> hmm, obviously not all types make sense for all machines, depends on the hardware (nand vs disk vs sd/mmc/cf), but the machine could identify those things and let that affect the pool of available fs types for the distro to choose, or something..
Jan 09 15:56:35 * kergoth shrugs
Jan 09 15:56:55 <kergoth> regardless, we should definitely think about changing this up a bit.. course, with the image/deployment changes it may become moot
Jan 09 16:01:14 <khem> kergoth: IMO if a distro supports a machine then it should set it accordingly for machine but I see your point
Jan 09 16:01:45 <khem> but I think my thought line is in line with what you said
Jan 09 16:01:51 <rburton> walters: AS_IF is not just a way of writing more [][][][][]?!
Jan 09 16:02:06 <walters> rburton, nope
Jan 09 16:02:18 <walters> rburton, it does solve problems
Jan 09 16:02:33 <khem> ah autoconf crap early in morning :) my day is tough ahead I guess
Jan 09 16:02:35 <walters> if you want the full story, see https://bugzilla.gnome.org/show_bug.cgi?id=674483
Jan 09 16:02:36 <yocti> Bug 674483: was not found.
Jan 09 16:03:16 <kergoth> khem: true, but we've always intended distro/machine to be largely orthogonal, and that any distro should be able to build for any machine, even if it doesn't support it officially.. so best to keep both aspects in mind
Jan 09 16:03:31 * kergoth ponders
Jan 09 16:04:03 <khem> kergoth: for that to happen we can not cross the features across both
Jan 09 16:04:24 <khem> or may be create a third list which is outcome of MACHINE and DISTRO policies
Jan 09 16:04:31 <kergoth> we already hve such a third list
Jan 09 16:04:34 <kergoth> it's called COMBINED_FEATURES
Jan 09 16:04:38 <khem> COMBINED
Jan 09 16:04:38 <kergoth> and base_both_contains ;)
Jan 09 16:04:45 <khem> yes I know but thats static
Jan 09 16:05:02 <khem> oh base_both_contains is one I was lookijng for
Jan 09 16:05:14 <khem> so that can do stuff dynamically
Jan 09 16:05:17 <kergoth> also have to consider that the machine controls the kernel, and the kernel might not support all the filesystems that *could* be run on the hardware
Jan 09 16:05:21 * kergoth nods
Jan 09 16:05:27 <kergoth> task-base uses it for some things
Jan 09 16:05:32 <khem> right
Jan 09 16:05:33 <kergoth> packagegroup-base, whatever :)
Jan 09 16:05:47 <khem> tasks are do_* :)
Jan 09 16:28:11 <rburton> panda84kde: tested musicbrainz patch sent.  builds faster too! :)
Jan 09 16:29:41 <panda84kde> rburton: great!
Jan 09 16:31:47 <Crofton> RP, should the poky@ list be meta-yocto@ :)
Jan 09 16:32:47 <khem> Crofton: you mean the ml ?
Jan 09 16:33:04 <rburton> crofton: no, meta-yocto should be called meta-poky
Jan 09 16:33:07 <Crofton> yes :)
Jan 09 16:33:51 <Crofton> btw I ran into an oe user at this sdr conference who admits that OE has grown on him
Jan 09 16:33:54 <Crofton> and they like it now
Jan 09 16:34:13 <Crofton> usual steep learning curve, but couldn't live without it now
Jan 09 16:36:14 <Crofton> bbl
Jan 09 16:39:44 <sgw1> khem: Morning and Happy New Year
Jan 09 16:40:55 <sgw1> khem: I am reviewing some of the build failures on the AB with eglibc2.17, there is one more in the poky-tiny build, elf_get_dynamic_info is getting _dl_debug_mask undeclared
Jan 09 16:45:46 <zenlinux> gm all
Jan 09 16:48:32 <khem> sgw1: HNY to you as well
Jan 09 16:48:44 <khem> sgw1: hmmm ok, i guess we need to patch that
Jan 09 16:49:10 <khem> sgw1: can you point me to poky-tiny logs
Jan 09 16:49:13 <khem> on ab
Jan 09 16:50:19 <khem> sgw1: there is one class of failures where you might see ssize_t not being defined
Jan 09 16:50:36 <khem> I have plugged it in few of them on oe-core and few in meta-oe
Jan 09 16:50:48 <khem> but the fix will be same
Jan 09 16:50:54 <rburton> in case anyone is interested, my gtk+3 series was just mailed to oe-core
Jan 09 16:51:59 <khem> oh 3 reminds me that I have python3 recipes to submit :)
Jan 09 16:52:18 <khem> but one at a time
Jan 09 16:52:22 <sgw1> khem, here are the tiny logs: http://autobuilder.yoctoproject.org:8010/builders/nightly-tiny/builds/399/steps/shell_43/logs/stdio
Jan 09 16:53:02 <walters> khem, nice!
Jan 09 16:53:05 <sgw1> khem: I also just added you to an email about systemd build failure (world) not finding mq_getattr()
Jan 09 16:53:54 <khem> sgw1: add -lrt to LDFLAGS
Jan 09 16:54:28 <khem> but where do you get systemd from ?
Jan 09 16:56:06 <sgw1> khem, it's pending in the MUT branch from radu
Jan 09 16:56:41 <khem> hmmm meta-oe one does not fail so I wonder
Jan 09 16:56:47 <khem> what Radu has done
Jan 09 16:57:01 <khem> is he merging meta-openembedded layer into oe-core or what
Jan 09 16:57:24 <sgw1> yes
Jan 09 16:58:45 <khem> sgw1: is MUT tree available on cgit
Jan 09 16:59:10 <sgw1> khem, yes: right now it's sgw/mut
Jan 09 17:00:07 <khem> ok its poky-contrib I believe
Jan 09 17:00:08 <sgw1> khem: I also use poky-contrib/stage/master_under_test, but right now it's a little older (without the systemd stuff yet)
Jan 09 17:00:18 <sgw1> khem: yes poky-contrib
Jan 09 17:02:04 <khem> I see
Jan 09 17:03:51 <khem> sgw1: there are more fixes that went into meta-systemd since
Jan 09 17:04:04 <khem> so Radu should sync his patchset once again and update
Jan 09 17:05:14 <sgw1> khem: Ok, maybe you can follow up on my email regarding the systemd failure
Jan 09 17:11:41 <sgw1> khem: seems valgrind does not like eglibc 2.17, I am going to look at patching it.
Jan 09 17:15:38 <khem> sgw1: possible I havent built world with it
Jan 09 17:15:45 <khem> so I might not have seen it yet
Jan 09 17:16:05 <khem> I have been more dug into running the system with it
Jan 09 17:16:28 <khem> time to take shower bbl
Jan 09 17:48:19 <sgw1> khem: I have a patch based on updating your 2.16 patch for valgrind, will send it to the list shortly.
Jan 09 17:56:42 <sgw1> khem: patch sent for valgrind
Jan 09 18:17:41 <kergoth> what the hell. my image fstypes doesn't contain live, yet for this machine do_build of core-image-base deps on do_bootimg, even though bootimg.bbclass was never inherited, which means it tries to run a nonexistent task
Jan 09 18:17:45 * kergoth is confused
Jan 09 18:19:35 <kergoth> ah, until i manually wiped tmp/cache
Jan 09 18:19:51 <kergoth> clearly a bug in the caching/hashing
Jan 09 18:19:52 <kergoth> lovely
Jan 09 18:26:05 <ftonello> im adding packagegroup-core-x11 to IMAGE_FEATURES but my image has no xorg server
Jan 09 18:29:10 <ftonello> I got it
Jan 09 18:29:14 <ftonello> now its just x11
Jan 09 19:14:12 <ftonello> when compiling xorg, its required a dri package
Jan 09 19:14:20 <ftonello> "configure: error: Package requirements (glproto >= 1.4.10 dri >= 7.8.0) were not met:"
Jan 09 19:14:30 <ftonello> does someone knows which package is this one?
Jan 09 19:14:35 <ftonello> or which recipe provides that
**** ENDING LOGGING AT Wed Jan 09 19:52:32 2013

**** BEGIN LOGGING AT Wed Jan 09 19:54:19 2013
Jan 09 19:54:36 <ant_home> ka6sox-away: :)
Jan 09 19:54:53 <ka6sox-away> thank scoutcamper for fixing
Jan 09 19:55:03 <ant_home> thanks guys!
Jan 09 19:57:55 <ant_home> why now  NATIVELSBSTRING   = "Unknown" ? Was Gentoo2.1
Jan 09 19:58:01 <ant_home> not long ago...
Jan 09 19:58:48 <msm> so is there any central place to go / community for the elc boards everyone is just now getting?
Jan 09 19:59:00 <kergoth> ant_home: sounds like you don't have lsb_release available
Jan 09 19:59:44 <ant_home> hm, I build distro-less and I was surprised to see Gentoo recognized. It was end-2012
Jan 09 20:00:25 <kergoth> it just asks lsb :)
Jan 09 20:00:44 <ant_home> is Gentoo lsb now? never been...
Jan 09 20:01:52 <kergoth> i dont know or care anything about gentoo, nor will i ever
Jan 09 20:02:00 <kergoth> most distros have a package for the lsb tools
Jan 09 20:02:05 <kergoth> not all install it by default
Jan 09 20:02:19 <ant_home> I couldn't care more for that 'Unknown' ;)
Jan 09 20:51:52 <khem> sgw1: I think I have fixed the poky-tiny issue
Jan 09 20:52:21 <khem> sgw1: I have refreshed the patches on the contrib tree. So please repull them and retry
Jan 09 20:54:19 <JaMa|Off> ant_home: lsb still works correctly here in Gentoo-2.2
Jan 09 20:59:35 <khem> JaMa|Off: Did you see any eglibc 2.17 specific breakages that need my attention ?
Jan 09 20:59:49 <agherzan> join #chromium
Jan 09 21:00:05 <agherzan> :)
Jan 09 21:01:17 <JaMa|Off> khem: I think only obexd was caused by that and you've already fixed that :)
Jan 09 21:05:52 <seebs> So, a lot of this is just my amazing talent for innovative ways to screw up simple configurations, but...
Jan 09 21:06:15 <seebs> The error messages you get if MACHINE isn't set are long, complicated, and unrelated to it.
Jan 09 21:07:03 <seebs> I wonder if there shouldn't be a first stage of Very Basic Checks which produce specific and meaningful errors and then abort all the other processing, expansion errors, and so on. Because pages of "You can't add NoneType to str" do not help you realize that the quick hack BSP you threw together to test something is dutifully setting MAHCINE to x86.
Jan 09 21:10:19 <kergoth> seebs: that sort of thing can be difficult, in part because OVERRIDES is used extremely early, by bitbake itself doing a config metadata finalize.
Jan 09 21:10:37 <kergoth> it's tough to inject early enough to do such a sanity check from the metadata
Jan 09 21:10:38 <seebs> Yeah.
Jan 09 21:10:59 <seebs> Well, two questions: (1) would it be desireable? (2) If so, would it be practical?
Jan 09 21:11:02 * kergoth still thinks bitbake needs a plugin mechanism that would be used to control behavior and sanity checks and such, and let the metadata just define variables and functions, no task adding, etc
Jan 09 21:11:20 <seebs> What I found from variable tracking is that "very hard" and "not worth it" were, for me, very different things.
Jan 09 21:11:24 <kergoth> would shift 90% of the imperative bits into actual separate code
Jan 09 21:11:30 * kergoth nods
Jan 09 21:11:40 <seebs> I have no idea how much time I've spent on that, but I'm pretty sure it's been a net win in my total time spent.
Jan 09 21:12:00 <kergoth> anything that'd avoid horribly ugly errors would probably be seen as a good thing
Jan 09 21:12:06 <kergoth> users should ahve some idea of what they did wrong
Jan 09 21:17:09 <ant_home> JaMa|Off: strange, gentoo-release didn't change format
Jan 09 21:17:44 <seebs> ERROR: package qa determined that your user name is "seebs". You made a typo. Stop bugging me.
Jan 09 21:17:51 <ant_home> JaMa|Off: I have DISTRO_VERSION    = "oe-core.0"
Jan 09 21:18:07 <ant_home> i.e. distroless
Jan 09 21:18:49 <kergoth> again, it runs lsb_release -ri. something must have changed on your machine so that doesn't work
Jan 09 21:18:52 <kergoth> it's that simple
Jan 09 21:19:09 * kergoth gets caffeine
Jan 09 21:20:09 <ant_home> khem: I'm rebuilding now from scratch, seems after uapi header changes
Jan 09 21:20:19 <ant_home> klibc need one more patch
Jan 09 21:22:30 <ant_home> khem: I'm now confused anout --fix-vb4x and --fix-vb4x-interworking
Jan 09 21:22:55 * ant_home is typing in the dark
Jan 09 21:23:02 <ant_home> sry
Jan 09 21:25:40 <ant_home> JaMa|Off: python 2.7 or 3.2 ?
Jan 09 21:28:47 <JaMa|Off> ant_home: both
Jan 09 21:28:49 <ant_home> JaMa|Off: fwiw I've built from scratch klibc, kubi-utils-klibnc, kexecboot-klibc for armv4
Jan 09 21:28:53 <ant_home> right now
Jan 09 21:29:12 <ant_home> meta              = "master:0cfec10c4c7b0597f0e0c8f85539d901861a2f83"
Jan 09 21:29:12 <ant_home> meta-initramfs    = "master:c9a18a88456bd459b34de4e9a7f4f8c0b9d669b1"
Jan 09 21:29:12 <ant_home> meta-handheld     = "master:87af587c623f59f5e244b7d771dbf25a7bea74a5"
Jan 09 21:29:43 <ant_home> I'll change target now
Jan 09 22:03:51 <sgw1> khem: ACK on updated patches
Jan 09 22:03:55 <khem> ant_home: all you need is --fix-vb4x
Jan 09 22:04:03 <khem> sgw1: cool ok
Jan 09 22:04:12 <ant_home> khem: hi
Jan 09 22:04:25 <ant_home> khem: ok, debian wiki is too dense for me :)
Jan 09 22:04:41 <khem> sgw1: I need may halstead 's help so we can upload the eglibc source tars
Jan 09 22:05:23 <ant_home> khem: afais we fall in case #7  http://wiki.debian.org/ArmEabiPort#Choice_of_minimum_CPU
Jan 09 22:06:33 <ant_home> khem: but I know you're on bleeding edge ;)
Jan 09 22:07:44 <khem> ant_home: you dont care so much for running exact same binaries on a newer core do you ?
Jan 09 22:07:52 <khem> if not dont read too much into that doc
Jan 09 22:08:18 <ant_home> I just aim to Narcissus/Angstrom feeds
Jan 09 22:08:50 <khem> yes
Jan 09 22:09:14 <khem> and moreover in OE we do not support --fix-vb4x-interworking option
Jan 09 22:09:42 <khem> since we dont have usecases where you have binaries that you are then running on later EABI supported cores
Jan 09 22:09:57 <khem> so we dont want to beat the hell out of mole like debian
Jan 09 22:10:39 <sgw1> khem: just ping halstead and he can help you out with that.
Jan 09 22:10:48 <ant_home> ok, so  mov pc,lr  is not an issue :)
Jan 09 22:10:51 <khem> if you had used gcc driver to do linking and passeed march=armv4 to linking cmdline all would be fine
Jan 09 22:11:08 <khem> but since you are mucking with compiler defaults all bets are off
Jan 09 22:11:42 <khem> similarily all thats needed is when you call naked ld to do linking then you need to pass --fix-vb4x
Jan 09 22:13:32 <ant_home> hm..klcc docs did suggest 'do not set flags'. maybe things changed in the meanwhile
Jan 09 22:16:46 <khem> ant_home: hmmm actually you might have tripped me into a bug here
Jan 09 22:17:05 <ant_home> uh oh
Jan 09 22:17:14 <khem> gcc should have passed --fix-v4bx-interworking to ld when called with march=armv4
Jan 09 22:17:40 <khem> can you show me the output of cross-gcc -march=armv4 -xc /dev/null -o a.out
Jan 09 22:20:02 <ant_home> http://paste.debian.net/223264/
Jan 09 22:20:49 <khem> ant_home: add -v
Jan 09 22:20:51 <khem> as well
Jan 09 22:22:47 <ant_home> hard to format..
Jan 09 22:25:29 <ant_home> http://paste.debian.net/plain/223265
Jan 09 22:26:17 <ant_home> hm..it's only apart...
Jan 09 22:28:47 <ant_home> that http://paste.debian.net/plain/223266
Jan 09 22:33:51 <khem> ok thats fine
Jan 09 22:33:59 <khem> now pass -mthumb-interwork as well to cmdline
Jan 09 22:34:03 <khem> and paste
Jan 09 22:34:55 <ant_home> k
Jan 09 22:35:40 <ant_home> http://paste.debian.net/223267/
Jan 09 22:37:36 <khem> ok I see an issue here but its minor
Jan 09 22:37:43 <khem> or lets say doesnt impact OE
Jan 09 22:37:45 <khem> so much
Jan 09 22:40:32 <ant_home> I'll retry today, but it seems ${FIX_VB4X$} was empty in the recipe.. I added a patch defined in the recipe by export FIX_ARMV4_EABI_V4BX = "${FIX_V4BX}"
Jan 09 22:41:09 <ant_home> the recipe = klibc.inc
Jan 09 22:42:19 <ant_home> so +KLIBCLDFLAGS  += --fix-v4bx works but +KLIBCLDFLAGS  += $(FIX_ARMV4_EABI_V4BX) won't
Jan 10 00:24:57 <seebs> Okay, that is mysterious.
Jan 10 00:25:10 <seebs> I have a package; without loss of generality, call it foo.
Jan 10 00:25:18 <seebs> FILES_foo = "/opt/something"
Jan 10 00:25:51 <seebs> This ends up having no effect, because it is renamed-over with something else, which reassigns it as FILES_${PN}
Jan 10 00:26:22 <seebs> And that then ends up being expanded to pick up a default value.
Jan 10 00:26:38 <seebs> Given that ${PN} == "foo", this is a pretty surprising behavior. To me.
Jan 10 00:27:20 <kergoth> yeah, my old recipe_sanity class used to detect and warn on any instances of that happening
Jan 10 00:27:56 <seebs> My inclination would be to say that this should either be a fatal error, or should do what the user presumably intended, which is actually override the values.
Jan 10 00:28:00 <kergoth> http://git.openembedded.org/openembedded/tree/classes/recipe_sanity.bbclass
Jan 10 00:28:16 <kergoth> there's no way to know what the "user" intended
Jan 10 00:28:28 <kergoth> from bitbake's perspective it has two variables defined that eventually have the same name
Jan 10 00:28:48 <kergoth> making it fatal would probably be a good idea
Jan 10 00:28:53 <seebs> Hmm. I would think an explicit FILES_foo should win, but I see the point; it's not obvious how to handle that.
Jan 10 00:29:23 <kergoth> and if a .inc i included defined the explicit one, and i defined the nonexplicit in the .bb, which is used?
Jan 10 00:29:27 <kergoth> or a bbclass, for that matter?
Jan 10 00:29:34 <seebs> Hmm, point.
Jan 10 00:29:57 <seebs> I suppose the distinction I probably want is between the default FILES_${PN} from bitbake.conf, and anything more explicit.
Jan 10 00:30:05 <seebs> But that's really hard to express right. Ugh.
**** ENDING LOGGING AT Thu Jan 10 02:59:59 2013