**** 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